My Understandings on ABB, SBB, Standards and Solutions Architecture

Introduction

Being a architect for couple years, I met with lots of these 3-letter acronyms and various terminologies. And in different occasions and engagements, I also discussed with other experienced and senior architects on their understandings on these bust words.

Since I did build some Frameworks for architects and development teams in the past and certified on the TOGAF, in this article I would try to illustrate my own understanding on these terminologies and how they relate to each other.

My Understandings …

Starting from a diagram with the acronyms.

Then my understandings on these acronyms. Note that not any formal definitions but just my understandings.

Enterprise Reference Architecture

A set of Architecture Principles guides and scopes the architecture boundary and objectives.

Architecture Building Block (ABB)

What or the Architecture Principles we want to achieve like Data Security, Service Reusability. It may contains child ABB to depict more granular objectives. Ideally, every leaflet ABB should be realized by a SBB.

Solution Building Block (SBB)

How the ABB is realized and implemented. Similar to ABB, SBB can also contain child SBBs to address more detailed technical know-how. The SBB would describe the use cases, assumptions, rationale and detailed know-how. Sometimesm it may trigger a Proof of Concept (POC) exercise. The framework and artefacts produced should be detail enough and able to directly referenced or reused by development and systems implementations. The major focus here is Reusability.

Standards

The designated software, versions, tools, naming conventions, guidelines and procedures used to build the SBB. Or on the angle of opposite side, SBBs depict how these Standards should be used by designers and developers.

Solutions Architecture

For each project or implementation, we would develop a solution architecture with these reusable SBBs. By that, it would much simplify the architecture specifications and improve communications among stakeholders by referring the SBBs utilized as the common ground. On the other hand, designers can now easily build the detailed designs with the artefacts included in the referenced SBBs.

And final note,

I perceive that ABB to SBB is a top-down specialization approach while SBB to ABB as bottom-up generalization. In other words, SBB can also capitalize from development and implementation experiences. The harvesting process can be initiated either from ABB, SBB or project implementations. I also consider it as a tool to validate the IT consistency across the architecture and actual implementations in a corporate.