discipline banner.gif (11841 bytes)

 

Other Columns

i. Architecture Teams

ii. Architectural Requirements

Related White Papers

i. Software Architecture (.pdf)

ii. Visual Architecting Process (.pdf)

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

 

For more on Architecture Action Guides see

i. Downloads

ii. Software Architecture Workshop

For more on Architecting see

Architecting Process

Book List

Enterprise Architecture: 
Balancing Centralization and Decentralization

Two forces have played a substantial role in shaping organizational histories. These are centralization, to create efficiencies and synergies, and decentralization, to foster innovation and put business entities closer to the customer. Countless companies (and groups within large companies) have swung like a pendulum between these two polarities, generally moving from one to the other with each new change of leadership. This is because there are real advantages to each--and real disadvantages to each.

Business units, working together towards some desired outcome, can get better individual (and hence better overall corporate) outcomes from this collaboration than the units working independently and competing with each other for resources and customers.

Nonetheless, the experience of business is that small teams working with considerable autonomy and independence are the lively font of innovation. In a competitive world that is constantly shaken up by innovation after innovation, the mantra is innovate or die.

Anyone who dares to venture that strategic advantage makes any sense in a world where innovation through small teams and customer intimacy is critical to survival, had better have a good story to tell about integrating aspects of the two forces that have been seen as alternatives or polarities.

By Ruth Malan and Dana Bredemeyer, April, 2004

Leverage Here, Innovation There

The key is enterprise architecture as business capabilities architecture, in conjunction with the minimalist architecture principle (Malan and Bredemeyer, 2002). The business capabilities architecture identifies the systems of capabilities required to execute the business strategy. Business capabilities, then, become the highest-level unit of architectural design in the enterprise setting. It is at this level that key decisions are made, identifying those areas that will be tackled at the enterprise level of scope, and leaving all other decisions well enough alone! This is the minimalist architecture principle or MAP.

Applying the MAP means that a critical few frontiers of capability will be addressed by the business as a whole, and the rest will be left to business units, teams or individuals to make their own, affording them the authority and challenge to innovate freely. Even where the enterprise architecture impacts them, only those decisions that must be made at the enterprise level to achieve the overall business strategy, will have been made.

Business capabilities architecture plus the MAP, then, form the key to the integration of the best of both worlds. There are centralized decisions to create leverage and synergy by creating a forum for prioritizing and then collaborating on the creation or enhancement of capabilities critical to the business strategy. It also creates the context for decentralized decisions that are made in heart of the innovation engine--small teams operating with sufficient autonomy not to be stifled by the corporate blanket.

Business Capabilities Architecture: identifies the systems of capabilities required to execute the business strategy. 

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.

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:

 

Copyright © 2003 Bredemeyer Consulting
URL: http://www.bredemeyer.com
Last Modified: April 4, 2003