How Many Architects Does it Take to Change a Light Bulb?

Looking at the Problem of Responsibility and Alignment

This is how changing the light bulb situation would pan out at a large corporation.

The business, or the Product Owner, would come and say that it was made clear that a light bulb in the living room had burned out. They engage a Solution Architect, who will suggest that the light bulb should be replaced, the BA would validate the voltage and size of the bulb, and the Infrastructure Architect would say that we need to turn off the power before attempting this operation.

But just as you are about to estimate, the Enterprise Architect will show up and say that they do not want any of these light bulbs to be used anymore — they want these new light bulbs that are energy efficient. The Solution Architect complies, does the analysis, and determines that we will have to replace the socket if we are to use these new energy efficient light bulb. The Infrastructure Architect will have to asses the ability to support this new type of socket, and once he has, we can estimate.

A new estimate is generated, the team adjusts and starts working again. Just about 80% of the way through, the Security Architect, who should have been consulted a long time ago, comes in and says that while the new type of light bulb has been approved by security, they have not yet analyzed the new socket and therefore cannot provide security sign off.

The Enterprise Architect feels offended, but the Security Architect doesn’t budge, and the Infrastructure Architect has a chuckle claiming this was the reason he never modernized his infrastructure.

The solution goes back to the original light bulb, but now the project is 30% over budget and the development team is tasked with finding any corners that can be cut.

Finally, a month after the light bulb is changed, security approves the new type of socket, but this light bulb will not burn out for years — and so the room will have an outdated light source and an inflated electricity bill for years to come.

The Problem of Alignment

When I was at a talk by Fred Kofman he suggested that lack of alignment is the biggest detriment to corporate success. He provided the example of a soccer team where the defender is pre-occupied only with preventing attacks, and the striker's only interested in scoring goals. Instead, the whole team should be aligned and focused on winning. That means that defenders look forward to making the right play, and strikers drop back to put pressure on opponents. It means that, even as strikers get the glory, defenders are recognized as key contributors.

In the above example, Enterprise, Security, Infrastructure, and Solution Architects were all playing to win on their own terms. Organizations need to align along the direction of serving customers. Serving customers better is the only real win.

Enterprise Architecture should not inject requirements that stand in the way of serving the customer, Security needs to espouse a dynamic view of security practice, and business should look for timing that allows the other two to happen and not be so reactive.

Before doing some work we need to align on why — and often there is no expert. We need conversations about what is possible and how that can benefit the user.

The Problem of Responsibility

You spend a few years doing menial tasks and you stop seeing the horizon. Corporations need to have bottom-up responsibility and accountability. Software Engineering and Digital Transformation do not live well with Taylorism. As digital transformation accelerates, complexity becomes abstracted, and specialists non-existent. You have a technologist who can dive deep into the problem or a technologist who needs to stay on the shallow end: you don’t get a technologist who knows the ocean floor.

Alex Petland and Nathan Eagle differentiate between 20th-century organizations and 21st-century organizations. The former, structured around physical infrastructure, works around ‘physical separation’ and focuses on carrying out well-described processes repeatedly and changes slowly. The latter, structured around cognitive infrastructure, works by tying together ideas, knowledge, and an awareness of what can be accomplished. Flexibility and adaptation are hallmarks of the latter and change comes easier. In the former, Security and Enterprise Architects sit far removed, researching their own concerns; in the latter, conversations are tying everyone together, forcing customer-centric, continuously evolving ideas to emerge.

With digital ] so rapidly changing, we need to embrace bottom-up ideation and organize around cognitive infrastructure. What we need are conversations, not declarations.