Building Blocks

Introduction

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.

Interfaces

Here are a couple of crazy questions for you

Have you ever licked a 9v battery to determine how much juice/power it still has in it? I do it all the time, in actual fact every time I pick up my guitar and connect it into an amp
Have you ever tried doing the same thing with car battery when your car doesn't start, i.e. getting two pieces of wire and connecting them to the battery poles and then putting the other ends on your tongue?
What about interfacing with a computer directly by sticking your tongue on the address bus and feeling the ones and noughts flowing through you?
What about spinning a CD whilst it's in a CD player in the same that way we used to spin vinyls with our hands?

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.

Now let's look at the other side of the contract, the consumers.

We have used browsers to demonstrate the design. We have drawn four browsers all consuming the Media Transporter interface. This is shown as a stick with half a circle attached, like a clasping hand. What the diagrams represent are browsers that will work with any component that implements/supports the Media Transporter Interface.

This highly structured approach to the design of systems leads to loosely coupled systems, with a strong emphasis on a stable design philosophy. These systems can interchange components easily which means consumers are not coupled to the implementations but to interfaces (which should be stable or far more stable than implementations).

Building Blocks

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 of the following is allowable behaviour, in actual fact which one of the following gives you access to that information

you turn up at the door of the HR department, punch open the doors, try and gain access to their computers, pull open filling cabinets looking for the information you require
you send an email or make a phone call to the HR department informing them that you need to know what information they hold on and would like to see it

So which of the two techniques would yield the desired results.

Version 2 off course. The HR department has set of protocols that you must follow, and that set of protocols represent the interface to the HR department. So we can clearly see from this example that the HR department is a building block with a clear set of interfaces i.e. the protocols.

Architecture and Solution Building Blocks (ABB and SBB respectively)

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