Functional Building Blocks
Products each have one of more operational functions, and each function itself is made up of smaller functional parts. Benefits arise when each of these smaller parts has one distinct purpose and is capable of being built and maintained by a small team.
Technology allows people to follow a process at scale and at distance. As ever-evolving technology has permeated business, what at first was simply automating manual activity in one location became a realisation that there were new and innovative ways to deliver the same functionality (or better outcomes) at lower cost, and since then business has become ever more digital.
In service industries technology systems underpin nearly all capability, and the functions of business are provided by people following processes that are brought to life by technology. For example, consider the different functional parts to matching an invoice against the 'goods received note' and then against the purchase order which authorises that expenditure. Or the process by which a real-time auction takes place to win the right to place an advert on the web-page you are browsing, and the follow-on activities of the winner providing the advert copy, and then its inclusion at the relevant point in the page as it is built for you - all in around 0.5 seconds. Each requires a different functional capability to be specified, built and tested. And then constantly improved upon.
An aviation analogy
The same product creating and evolving process had been with us since the dawn of mankind when crude tools were fashioned into more effective tools. In the 1770s, the Montgolfiere brothers' hot-air balloon was considered an astonishing sight, the 'technology' of its day. Each of its functional building blocks - the cloth and paper balloon, the restraining cords, the burner and the passenger basket - had a particular purpose and a specification which arose from the application of knowledge and physical effort to solve a problem and to create new value. And the Montgolfiers only had themselves and a few trusted assistants to try out and then perfect their invention.
In the early 1900s, the US Government chose Samuel Langley, a renowned scientist and a professor of astronomy who wrote books about aviation and was the head of the Smithsonian to be given taxpayer money to invent the first aeroplane. Invest in the person with proven credentials and the right connections and they’ll work it out for us, and payback with interest. For all the investment, Langley’s machine never got airborne. With little fanfare and $2,000 of their own money, on December 17, 1903 the Wright brothers launched the first powered heavier-than-air machine to achieve controlled, sustained flight with a pilot aboard. Something the War Department, Langley, the Smithsonian, and all of that government investment could not.
Why did the Wright brothers succeed where Langley had failed? Langley and his large team saw flight as a problem of power, and thought that money could solve it. The Wrights pursued balance and pilot control. Their small team and the limits on their financial resources compelled them to spend wisely what little they had. Since they couldn’t absorb the costs of repeated flight tests, they developed a wind tunnel to test aerodynamic designs. This saved them not only money but time. From those simulations they repeatedly changed parts of the design (their functional building blocks), quickly tested each amendment and kept adding value until their honed airplane flew.
These days we're still faced with the same challenges as those easly aviation pioneers. It is the small teams who are focused on the opportunity at hand who push the boundaries and create new value. Small teams who work on functionality that has visible boundaries. Small teams who are not afraid to use feedback loops to quickly learn what works and what doesn't and to do that on components that are small enough to be immediately aware if a change has worked or not. It's these small cross-functional teams who are the key to creating your agile and customer-centric business. Langley died in obscurity a man who persisted in the thought that he could have beaten the Wright brothers if only he’d had more time, a bigger budget and the best resource. Don't let that outcome be the fate of your company.
Configuration Items
These days many of our challenges are to do with software engineering. Many traditional business have invested in systems over time that are impenetrable structures of legacy code. These systems have an architecture (if it ever was architected) that is so inflexible that it can’t accommodate new feature requests. Changes to this monolithic coding structure require extensive regression tests of the entire system. In short, the business takes a deep breath if ever such a system needs amending, with no guarantee that any change will work - putting revenue, reputation and regulation at risk.
Modern engineering breaks products into separate components, each with a specific functional purpose. These functional building blocks are broken down further, into configuration items. Each configuration item may consist of further configuration items. Each configuration item has a known specification and has a specific purpose. It is a small enough unit to be capable of being created and maintained by a small team, with a certainty of outcome and operational behaviour. Configuration management, the parent term, is an engineering discipline for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.
In software engineering, functional building blocks are made up of configurable items too. At a granular level these microservices have one specific purpose and have well-defined interfaces to communicate with other services.
The great benefit of a microservices architecture is that each microservice can quickly be built and tested by a small team.
The principle of breaking each product down into its components, each contributing to the product's functionality, these components themselves are made up of one or more layers of smaller components, until at the lowest level of granularity, each item has one specific purpose.
Next: The Law of the Small Team
Each configuration item / microservice is a candidate for assignment to an engineering team to be built or maintained. As we've seen, small teams are the key to creating your agile and customer-centric business. You can read more on small teams in The Law of the Small Team, one of our Three Laws.
David Seacombe