Federated Enterprise Architecture

I've come to the conclusion that architecture (as a profession) is about managing quality risks. Taking that as a basis, we can come up with a nice model for federating enterprise architecture in a complex company.

If we're managing risks, it helps to recognize that not all risks are the same. This is why I love the picture above. In defense of an invading army, you need to build high stone walls with narrow windows that your archers can shoot out of without making themselves a target. You need enough space inside for your citizens and their flocks. Getting this wrong spells disaster, so you spare no expense; the safety and security of your populace is at stake.

On the other hand - if you're just trying to protect your grass from being trampled by tourists, perhaps a walkway with a polite sign will do the job.

The reality is that in any organization there are levels of risk that range from existential to bothersome, and levels of risk appetites that vary from conservative to aggressive. If you don't take those factors into account when you start defining how to manage those risks, you cannot effectively manage architecture in a complex company.

Risk Levels

Just like in the picture above, there are levels to quality risks - how much the enterprise is exposed if the risk controls fail. Exposing customer private information could truly be an existential risk - between loss of reputation and regulatory fines your company takes a big hit. Ensuring code is readable through consistent formats - aka coding standards - on the other hand might marginally decrease internal costs but generally don't have as much impact to the company as a whole.

Most enterprise architecture programs fail to recognize this distinction. They treat all quality attributes as being kind-of-the-same and try to manage them all with the same approach. This might mean centralizing coding standards - creating a big-brother bureaucracy that wastes everyone's time on trivial matters. Or you might federate security standards - resulting in a hodge-podge approach to information security that results in gaps and attack points.

This is the underlying problem that leads to the "enterprise architecture pendulum swing". Anyone who's worked in enterprise architecture within large companies for any period of time has seen the pendulum swing at least a few times between a federated and a centralized approach. Typically this swing happens when the current approach to architecture isn't providing enough controls for the quality risks, or causing the costs of those controls to be more than the risk exposure they control against.

Information security having challenges? We need consistency in architecture - centralize EA! Architecture becoming a slow moving bottleneck? We need to reduce the cost of developing our systems - federate EA!

Neither extreme really works.

The right approach is to understand the potential risk impact and figure out whether to centralize or federate based on that. Since there is a high level of risk to the company for information security qualities, the policies surrounding information security should be centralized. Since there is a very low risk footprint for coding standards, federate those. Don't try to manage them monolithically. They are not equivalent and they need different approaches.

In complex companies, there may even be three levels: enterprise, cross-business unit, and team. The cross-business unit ones are those that impact the ability of business units to work together, such as performance and availability SLAs. Enterprise level is reserved for those rare things that impact all business units, even those that aren't integrated with each other. Think regulatory, response time, and coding standards (in decreasing levels of impact).

Accountability & Responsibility

If you take this risk level approach, then one of your main jobs as an enterprise architect is to define the risk quality taxonomy - the mapping of risks to risk levels, and risk levels to organizations. This clarifies which architectural qualities teams have autonomy on, and for which teams need to follow centralized standards. Be aggressive on federating out accountability; in general the overall program will be most effective when the centralized role is focused on the things that really, really matter.

There are actually two aspects to each quality: a policy and a procedure. This is probably a topic for another day, but the TL;DR for this is that the taxonomy defines who is accountable for both, but the accountable team can delegate the definition of procedures. For example, a centralized team might own the policies and procedures for availability. As such they might set a policy that at least two data centers are required for business continuity. Each business unit, however, has a different technology stack, business model,, and other factors that influence how those data centers should be used. (This is especially true in acquisitive companies). The individual business units define the procedures for using those data centers based on their individual risk appetites, technologies, business models and external commitments. It usually isn't a once-size-fits-all problem, so it's appropriate that the centralized team delegate the procedural work.

This approach is hierarchical. At the business unit level, the business unit architects might delegate a quality to individual domain teams. Domain architects might delegate to implementation teams. This is normal and healthy but it does not change the accountability. Delegate passes responsibility, not accountability, from one party to another. The ultimate accountability still remains with whoever the taxonomy says is the accountable party, and part of their job is making sure the responsibility party is doing the right thing. (Hint: that is what to focus on in code & design reviews.)

Delegation doesn't have to be to another individual. You might have a quality defined as "keeping up to date with security patch releases". If you automate the patching as part of a platform offering, then that platform is delegated the responsibility. The accountability party still needs to do checks to make sure they patching is actually happening.

A risk taxonomy approach

Thinking of architecture as managing quality risks and being thoughtful about the realistic exposures that each risk brings gives organizations and ability to create an enterprise architecture practice that's immune to the swinging pendulum. Each part of the organization understands what they are accountable for - and why - and what the limits of their autonomy are in the overall architecture. This means we don't have to try to manage protecting our customer data and protecting our developers from the misplaced semi-colon with the same rigor and approach.