Page Comparison

Introduction

 

Excerpt
A commonly used term in the architecture space is a building block. This is simply a thing with well defined boundaries. From a TOGAF® perspective a BB is typed by an element within the TOGAF® metamodel i.e. a BB could be a process, role, function, service, location, software or hardware element etc. in other words if it is typed in the TOGAF® metamodel it can be specified as a BB.

 

...

They all seem a little extreme I know and I would agree with you if you are saying to yourself "what is this guy on?"  In actual fact apart from the first example I wouldn't attempt any of the others.  If I wanted to do the others I would use devices with well defined interfaces to communicate with these devices.  The figure below is that of of something known in media (TV and music) industry as a media transporter, use these links on delicious for a bit history behind the symbols

If I were to ask you where have you seen these symbols as a collective group, you would likely say; CD players, cassette players, remote controls, Windows Media Player, VLC, QuickTime, Winamp etc. you might even say your washing machine (actually a few of those buttons are on my washing machine lol).  As a user of any off the listed devices or software, you pay no attention to how any of the buttons work, you simply know if you press the play button that the device/software will begin to play (whatever play means for the component).  As a user of these components your only concern is that each component does what you believe the buttons represent, you don't concern yourself with how it does what you think it should do.  Collectively the buttons form what is called an interface.  An interface is simply a collection of operations, not a collections of methods/implementations.  An interface is a contract between a consumer of a service and the implementer of the service.  It separates the two concerns.  It allows for full decoupling between the consuming and provider.  A consumer can use any component as long it implements the same interface.  

Consider the following set of images

These are UML diagrams, each component is shown with the lollipop stick protruding from them, this implies that they implement/realize an interface.  In this case it is the Media Transporter interface.  So what the diagrams show is that it doesn't matter which of these components you work with, if they all support the same interface, you as a consumer should be able to work with any of them.

...

So a building block is a package of functionality with well-defined boundaries with access to their functionality restricted to the interfaces that they implement.  So should you ever access the functionality of a building block directly without going through its interface. ?  The answer is NO.  All access is always through a predefined set of interfaces. 

Let's look at more softer examples.  The HR department in the company that you work for, holds information about you.  You want to know what information they hold about you.  So which off of the following is allowable behaviour, in actual fact which one off of the following gives you access to that information

...

There is clearly some relationship between ABBs and SBBs.  An ABB is simply the specification of a solution building block.  An SBB is the implementation of an ABB (the specification).  But is it always one to one?  Let's look at a few examples to help bring some clarity to the discussion.

In this example we have a specification (the ABB) for a web server.  If the ABB is written in a clear and concise manner, it should be possible to identify any number of possible web servers on the market that will meet the ABB.  In our example we have an ABB specification for a web server and there are a number of available SBBs (Apache web server, MS IIS, tomcat webserver etc).

But what about the following SBB examples

Both SBBs (JBOSS and Glassfish) have web server functionality, but they also have a lot more functionality.  In actual fact, they have the functionality of a web server, application server, and messaging broker.  Surely these extra bits are distinct pieces of functionality that could and should be described using specific ABBs?  So are these SBBs really implementations of several ABBs or are they composite SBBs (in other words are these SBBs really several SBBs bundled together under a single composite SBBs which acts as a facade to them)?  The SBBs are the latter.  Essentially the SBBs such jboss and glassfish are in actual fact composite/aggregate components exposing other components through well defined interfaces.  Each of these sub-components have their own associated ABBs.  So the model really looks like this

So the relationship between ABBs and SBBs is always as follows