April 28, 2004

Hot Spot Columns

BHAGs and Complexity

Pragmatic EA

Models and Communication

Role of the Architect Columns

Architect: What's in a name?

Architect as the Ultimate Design Authority

Architect's Role in Dealing with Complexity

Quest for Great Architects

Other Columns

i. Architecture Teams

ii. Architectural Requirements

Related White Papers

i. Software Architecture (.pdf)

ii. Visual Architecting Process (.pdf)

For more on Architecture Action Guides see

i. Downloads

ii. Software Architecture Workshop

Enterprise Architecture is reaching the mainstream. It has moved through its share of identity crises and growing pains. An early one that quickly became problematic was bloat. Sold as the elixir to a range of corporate ills from lack of integration to the perception that IT is chronically unable to align with the business, Enterprise Architecture took off. Corporate standards were the first terrain to conquer, and enterprise architects sought to bring everything from programming language to computing environment under enterprise control.

By Ruth Malan and Dana Bredemeyer, May, 2004

Minimalist Architecture Principle

Essentially, the Minimalist Architecture Principle says “if a decision can reasonably be made by someone with a more narrow scope of responsibility, defer the decision to that person or group.” This means that architects only make decisions that require the overall perspective and authority that the architect has. If a decision has local impact, then the architect has no need to mess with it. If the decision has broad impact, and the impact has highly strategic consequences, then the decision fits the minimalist architecture criterion.

Minimalist Architecture Principle: Make only those decisions that have to be made at this level of scope to achieve the business strategy and meet the architecture objectives and vision.

Decisions With Teeth Principle

Another way of pruning the Enterprise Architecture decision set is to apply the Decisions with Teeth Principle. Decisions that have teeth are those that are both enforceable and enforced. They can and will be adhered to, and if not, there will be consequences. This means that the decisions must be well-formed. They have to be unambiguous and have a clear scope of applicability. And there must be a governance process that allows for discovery of breaches and determines consequences, rather than simply granting exceptions.

Too often, architects and their deployment communities treat enterprise architecture decisions as statements of “general good.” These decisions are treated like guidelines or suggestions, which other architects, designers or implementers choose whether or not to follow. Such decisions have no teeth.

This may highlight a need to improve your governance process, but even with a strong governance process in place, objections raised in the name of customer advocacy have a powerful shield. That is, arguments in favor of the “general good” are susceptible to counter-arguments made in the name of a customer or immediate concern.

The reason to avoid making decisions that are likely to be dismissed is simple: you do not want the whole Enterprise Architecture to be tarred with the failure brush for the sake decisions that will be ignored and/or cannot be enforced. Further, it is a waste of time for the architect to make, and for others to think about and then ignore, such decisions.

Decisions With Teeth Principle: Only include decisions in your Enterprise Architecture that you, and the governance organization, are willing and able to enforce.

For more on Architecting see

Architecting Process

Book List

The Rub

Now here’s the rub: each decision in a truly minimalist architecture is there because it could not be made by someone with local scope of responsibility—if they did, they would compromise the overall goals of the architecture. In other words, everyone else either does not have the perspective and knowledge to make the decision, or they would make a decision that maximizes their local interests at the expense of the architecture goals. By their nature, decisions in a minimalist architecture are going to have detractors who, from their local perspective, see the decisions as sub-optimal. In short, the decisions that are worth making part of the Enterprise Architecture are exactly the ones that will be controversial in some quarters.

Connect-the-Dots Principle

This presents a conundrum which is resolved by applying another principle, which we call Connect-the-Dots. According to this principle, each architecture decision must be rationalized in terms of business goals, architecture requirements, or higher-level architecture decisions. You see, the only voice that stands any chance of holding its own against the voice of the customer is the voice of the business. Business strategy represents the voice of the business, and connect-the-dots creates a compelling chain that links business strategy to architecture goals to architecture decisions.

At its best, business strategy is well grounded in the voice of the customer and it is grounded in the voice of the business telling the story of competitive differentiation. It takes into account the competitive environment, the value network, internal capabilities and financial goals. Enterprise Architecture that takes business strategy as its starting point, and shows how each architecture decision is necessary to achieve the business strategy, expresses the voice of the business, and follows the connect-the-dots principle.

When the case has been made that the enterprise architecture decisions satisfy these three principles, then that set of decisions can be described as the technical expression of the business strategy. When such a decision, clearly driven by the business strategy, is ignored, we need to realize that it is not the architecture that is being brought into question, but the strategy itself. This focuses discussion where it belongs. The overall business strategy, like the enterprise architecture, optimizes across the organization. We need to not get distracted by debate about technology questions when the real issue is clarifying and enforcing what is strategic to the business.

Connect-the-Dots Principle: There must be a traceable connection from business strategy to each enterprise architecture decision.

Conclusion

Now, if a decision that is clearly driven by the business strategy is nonetheless doomed to be brushed aside by some or other group then we either have to compromise on the decision by:

• setting the scope of the architecture decision so that it out-frames that group or
• leaving the decision out of the architecture decision set (perhaps adding it as a guideline instead)

or we have to be willing to enforce it, and the governance process and supporting governance roles have to rise to the occasion.

With a minimalist architecture, and connected dots, we can turn to the governance process to provide the teeth that will make the architecture stick. Hopefully, though, we can rely less on the teeth, and more on persuasion, relying on the goodwill of those whose immediate interests are somewhat compromised because the overall benefit of achieving the business strategy makes it all worthwhile.

With a bloated architecture, no matter how well intentioned, it all comes unraveled. A bulky architecture is just too expensive and hard to give teeth to. It is expensive to read, expensive to execute on, and your governance process will get locked in interminable exception requests allowing no bandwidth to catch deviations from the architecture and no defense against outright defiance.

References

Malan, Ruth, and Dana Bredemeyer,  "Less is More with Minimalist Architecture", (MinimalistArchitecture.PDF, 47 kb), published in IEEE's IT Professional, September/October 2002. 
© 2002 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE. (ArchitectureDefinition.PDF, 124kb), May 2002.

Malan, Ruth, and Dana Bredemeyer,  "Software Architecture: Central Concepts, Key Decisions" (ArchitectureDefinition.PDF, 124kb) published on the Resources for Software Architects web site at http://www.bredemeyer.com/pdf_files/ArchitectureDefinition.PDF, May 2002.

Malan, Ruth, and Dana Bredemeyer,  "Architecture Strategy", published on the Resources for Software Architects web site at http://www.bredemeyer.com/ArchitectingProcess/ArchitectureStrategy.htm, April 2003.

Malan, Ruth, and Dana Bredemeyer,  "The Visual Architecting Process" (VisualArchitectingProcess.PDF, 65kb), February 2002.

See also:

• Our Software Architecture Action Guide and Architecting Process Action Guides
• Our talk titled "Action Guides for the Enterprise Architect" given at the Enterprise Architecture Conference in San Diego, 2001
• The books and papers listed under "How: The Architecting Process" in our Bibliography.
• Our classes, including

• Software Architecture Workshop

• Modeling Software Architectures Using UML and Action Guides 

• Architecture Vision Workshop

• Role of the Architect Workshop

• Fundamentals of Software Architecture Class

• Software Architecture Primer for Managers

• Our Recommended Books.