Building Block Architecture – Part 2

Background

In Part 1, I proposed developing a Building Block Architecture (BBA) activity to break down complex programmes involving IT delivery, before procurement, with delivery by small, independently managed teams.  This approach, along with rigorous Programme Management and the use of a consistent development methodology, will reduce the risk of poor outcomes and overrun on IT delivery projects.

This post provides more detail on thinking and including feedback since the initial post. 

Why Now?

While improved development approaches are delivering huge benefits every day, government IT is still experiencing too many failures.  As discussed in my earlier post, the reason that these benefits can be achieved now is that APIs are more than ever fundamental to the way that systems are developed.

In addition, there are a wide range of mature tools and services to help develop this Building Block Architecture approach:

• Cloud Computing / SaaS – allowing fast purchase of out of the box components immediately;
• Improved security capabilities and authentication methods for APIs which allow different suppliers of cloud solutions to allow their systems to talk to each other, while meeting security and GDPR requirements;
• Procurement Frameworks, including dynamic purchasing systems, which allow faster procurement for commonly used components;
• Open Source technologies – most of what needs to be implemented in large programmes can be done with open source technology – databases, programming languages, reporting tools, operating systems;
• Open Source Application Programming Interfaces – APIs developed with “open source” standards such as REST, Web Services;
• Tools such as Jira and Trello to support management of the delivery of large software  development projects.

Benefits of the Building Block Approach

The Building Block approach has the following benefits compared to current practices:

1. Simplifying the solution architecture, allowing a better understanding of complex processes.  (I have seen situations where incumbent suppliers have deliberately obfuscated a system to scare off new bidders!);
2. Purchasing a number of components is exponentially simpler than purchasing as a single solution – and increasingly, the components can be COTS and SaaS based, which can be procured in a number of weeks, rather than years;
3. Change management, is less likely as more work will have been done up front to understand the business requirements;
4. Reducing delivery risk by splitting delivery across a number of organisations, rather than putting all the risk with a single company;
5. Sharing the work out amongst specialist companies – a single company may not have the expertise in all the technologies required.  Bids are often so complex that a small number of shortlisted suppliers (the usual suspects) are selected. A Building Block Approach would allow more, and smaller specialist suppliers to bid for work and establish a more cost-effective solution market place;
6. For high risk / new development areas, procuring services from  two companies or teams (if in house) can be used to deliver the same component – so that if one project fails, then the other can deliver.  (This is the way that complex engineering solutions such as an Aeroplanes are designed, with multiple fail safes.) The Soul of a New Machine by Tracy Kidder describes how this approach was adopted for developing a new operating system.  Each team would of course have an incentive to deliver first or the optimum solution, as there would be ongoing maintenance revenues from any solution component delivered;
7. Minimizing the risk associated with upgrading software i.e. any upgrade would only impact a single “Building Block”;
8. Leveraging new technology such as codeless or Low Code programming within individual Building Blocks;
9. Simpler components are more likely to be reusable – in a large delivery, it is almost impossible to unpick components that can be reused by other departments or projects.

Principles of Building Block Architecture

In order to kick start this approach, I propose the following principles should be adopted:

• Appropriate and robust Programme and Project Management should be in place to ensure that work is broken down into Building Blocks before procurement;
• An agreed development approach within each Building Block e.g. Agile, Waterfall;
• Appointment of a Building Block Architecture group for major programmes;
• Building Blocks Architecture approach
  • Each Building Block should use a discrete set of technology architecture and can be replaced without impacting other Building Blocks;
  • Major software upgrades during the delivery of a single Building Block are not permitted (e.g. upgrading a framework), if it requires significant rewrites;
  • Size of Building Blocks is limited (e.g. cost, duration, number of staff);
  • Building Blocks are identified before procurement, together with an outline API set required;
  • Building Blocks are aligned with available off the shelf components e.g. SaaS, PaaS, IaaS services.
• Procurement should be via mini competitions, wherever possible, to avoid lengthy procurement delays;
• Inventories of building blocks (and their interfaces) are shared within  departments and between departments, to allow reuse and learning.

What needs to happen

Clearly, any major change in approach will take time.  Here are some thoughts how different groups could help enable this change.   

• Acknowledge the problem – Business Leaders and stakeholders to recognise the challenge when delivering large and complex IT Systems;
• Shape the delivery – Programme and Project Managers to design delivery using Building Blocks and adopt the BBA approach and recommendations above;
• Use the EA skills available – The Enterprise Architecture community to recognise the opportunity and influence Procurement decision making and programme design and align with major programmes;
• Pass the process down through the Supply Chain – Suppliers to gear up for efficient delivery using a Building Block Architecture approach.