Governance: The Elephant in the Room
The often unspoken EA issue: Is a new streamlined definition or governance necessary for effective management discipline?
by Mike Dunham
February 14, 2006
For enterprise architecture (EA) to be effective as a management discipline, it must be agile and flexible in addressing a multitude of issues. It must be able to identify and develop enterprise solutions within the confines of external institutional boundaries. It must harmonize and integrate the artifacts it develops with those of related management disciplines, such as capital planning and investment control, strategic planning, performance management, and security. At appropriate times, it needs to be a strategy tool and, at others, a tactical device.
However, the most important component of EA is frequently overlooked—the importance of stakeholder relationships and ensuring that the stakeholders are integral players in the design and implementation of enterprise solutions. EA boils down to the management of stakeholder relationships in order to effectively advance enterprise solutions.
The essential component and the one that is most often neglected is governance—establishing the rules of engagement to "lubricate" these processes. Governance is the "elephant in the room," or the obvious ingredient that no one wants to discuss, much less take on. It is essential to the successful transformation of theoretical EA concepts into measurable results. All too often, EA does not transcend the conceptual level, and as a result, practitioners are unable to translate the concepts into day-to-day requirements and deliverables. Including key stakeholders in the process—from concept to tangible result—is crucial to the success of EA.
In the absence of a universally accepted definition, business managers often define EA in terms of solutions to their current tactical needs. Like any other management discipline, they view EA as a tool to solve their business needs and characterize it in terms of the management disciplines with which they are most familiar. The result is multiple interpretations of the meaning and purpose of EA. Until EA matures, multiple definitions will persist.
The absence of a universal definition hinders the discipline from advancing and potential breakthrough performance from occurring. The key to defining EA is to develop a definition that is broad enough to incorporate governance and theoretical EA concepts, while focusing on delivery of tangible, measurable results. Hence, I propose the following: Enterprise architecture is about relationship management.
EA is about managing two types of relationships: artifact and stakeholder relationships. In order to identify and develop effective enterprise solutions, it is important to understand the relationship between those artifacts generated by the technical architecture and those produced by the business architecture. This is the traditional concept of EA embraced by most practitioners. This component of EA comes in many flavors and shades, from the technical architecture through data and service architectures. Artifact relationships, however, represent only 25 percent of EA.
Not surprisingly, the owners of the technical and business artifacts are among the stakeholders. These key stakeholder relationships are where the "rubber meets the road," and they represent 75 percent of the discipline. In addition, for an enterprise initiative to be successful, the business managers who have a stake in the new initiative must become fully involved in developing the rules of engagement that will govern implementation of the initiative. All of these activities fall under the general term "governance."
Strong stakeholder involvement and effective management of the stakeholder relationship will tend to eliminate traditional barriers to successful implementation of enterprise solutions, such as:
- Failure to develop strong business cases that provide incentives for stakeholders to participate.
- A history of major systems failure in connection with implementation of past enterprise solutions.
- Poorly documented artifacts that hinder stakeholder implementation.
- Resistance to new initiatives that are perceived as disruptive to standard operating procedures.
- Risks involved in incorporating a new enterprise solution that might expose the organization to failure in achieving its mission.
- Managers who feel that they are losing control of their operations or fear being dependent upon other organizational entities to provide mission-critical services through a new enterprise solution.
Faced with such issues, managers will inevitably find ways to avoid implementing a new enterprise solution. Governance processes provide the lubricant to help key stakeholders address the friction points and assist them in successfully managing the new initiatives. Again, it is the elephant in the room. It is the issue that many EA practitioners pass along for someone else to handle, or they assume the issues will somehow take care of themselves.
Based on this definition of EA, initiatives become more than the identification of potential solutions. Once identified, an enterprise governance body must be developed and nurtured to ensure that rules for data and resource exchanges are appropriately managed. EA governance must ensure that unambiguous dispute resolution procedures are in place to handle the inevitable disagreements that will arise:
- How are services delivered?
- Who delivers them?
- Who pays for them?
Rather than trying to define EA in all its complexity, it may help to start with this simple definition and let individual practitioners leverage it to their own needs. Perhaps by using this simpler definition, practitioners can avoid arguments as to whose view of EA is more relevant and stop the ongoing debate on whether EA is about configuration management, portfolio management, data normalization, or none of the above.
About the Author
Mike Dunham is Chief Enterprise Architect at Thomas & Herbert Consulting LLC.
Back to top
|