Building Blocks

In Enterprise Architecture by IRM UKLeave a Comment

Print Friendly, PDF & Email
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 off something known in media (TV and music) industry as a media transporter, use these links on delicious for a bit history behind the symbols:

selvyn-1

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:

1

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:

2

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 off the following is allowable behaviour, in actual fact which one off 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:

3

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:

4

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:

5

So the relationship between ABBs and SBBs is always as follows:

6

About the Author

selvyn-wrightSelvyn Wright Is a professional trainer with over 17 years of experience teaching technology and analysis, design and architecture methodology.  He has taught TOGAF for over 5 years.  During this time he has taught over 450 students with a certification pass of approximately 99%. 

His clients include Barclays Capital, Atos, Network Rail, Logica, Ericson, BAE and MBDA.  Previous to this, Selvyn was a Graduate Training Programme Lecturer at Morgan Stanley Investment Management and a Technical CORBA Architect at NATS.

Selvyn will be presenting the following TOGAF Seminar for IRM UK in London:

TOGAF™ 9 Certification Level 1 and 2
21-24 April 2015; 9-12 November 2015

Overview
TOGAF 9 provides an Architecture Development Method, Content Framework and Capability Framework that can be used as the basis for creating an organisation’s enterprise architecture. It has been built up over several years through open participation and collaboration between leading industry practitioners. In addition, TOGAF 9 provides a variety of tools, building blocks and resources that facilitate the process and enable the design and development of enterprise architecture across four domains; Business, Data, Applications and Technology.

TOGAF is an industry standard EA framework that is available free of cost to any organisation wishing to develop an enterprise architecture for use within that organisation. More than 60 percent of the Fortune 50 and 80 percent of the Global Forbes 50 use TOGAF to reduce time, costs and risks associated with developing an EA and improve overall business agility. TOGAF certification programs exist for individuals, trainers, professional services, and tool support.

These programs enable organisations to standardise on an open method for IT architecture and avoid lock-in to the proprietary methods of major vendors.

Learning Objectives
Upon completion of this four-day course, delegates will understand the TOGAF 9 framework and how to practically apply it in support of the design and implementation of enterprise architecture.  They will also learn how to apply TOGAF to create well-designed enterprise architectures through the use of practical scenarios and case study working.

The course prepares delegates for The Open Group’s Level 1 and Level 2 TOGAF 9 certification examinations.

All articles are © 2015 by the authors. 

Leave a Comment