Enterprise Architecture Governance
Posted on 12. Dec, 2010 by vbrown in Enterprise Architecture, Governance
In a recent LinkedIn discussion, I offered the following definition of Enterprise Architecture (EA)
EA is the logical framework that links and aligns business strategy and organizational structures, processes, information, and technologies.
What I find fascinating is that EA as a business function whose intent and benefits seem so obvious to me (based on many years of experience and empirical evidence) is apparently so difficult to define! In that same LinkedIn discussion hundreds of alternative definitions were offered with an amazing range. In many cases you wouldn’t even think that people were defining the same thing.
One thing is increasingly obvious. The practice of Enterprise Architecture is maturing, along with the recognition that its scope and its contribution to the business goes far beyond technology. Its success as an integrated business function requires a well-defined governance framework.
Based on my experience working with numerous clients to help create their EA practices, I’ve found that a sustainable framework for EA Governance is characterized by certain key criteria and deliverables. In part one of this two-part series I cover foundational aspects, Capability Assessment, Architecture Principles, and Architecture Vision. In part two, I cover key deliverables that guide realization of a robust EA Governance.
Governance Principle 1: Effective governance, at any level, requires round-trip management – consistent, comprehensive communication and feedback cycles.
Capability Assessment
Prior to developing an architecture governance vision and roadmap, it is essential to understand the current baseline, organizational goals, and capabilities. Capabilities should be assessed on several levels:
- The capability level of the enterprise as a whole? Where does the enterprise wish to increase or optimize capability? What are the architectural focus areas that will support those goals?
- What is the capability or maturity level of the IT organization within the enterprise? What is an appropriate style, level of formality, and amount of detail to ensure that the governance framework will fit with the culture and capability of the IT organization?
- What is the capability and maturity of the architecture function within the enterprise? What architectural assets are currently in existence? Are they maintained and accurate? What standards and reference models need to be considered? Are there likely to be opportunities to create re-usable assets during the architecture project?
- Where capability gaps exist, to what extent is the IT organization ready and able to transform in order to reach the target capability? What are potential impacts and risks to be addressed beyond the basic capability gap?
Architecture Principles
Architecture principles are a subset of, and must support business principles. They reflect consensus across the enterprise, and embody the spirit and views of the enterprise architecture organization. They can be defined as:
- Principles that govern the architecture process — the development, maintenance, and use of the enterprise architecture
- Principles that govern the implementation of solutions, establishing the first tenets and related guidance for designing and developing information systems
Architecture Vision
The Architecture Vision provides a high-level, aspirational view of the target architecture (target state). The purpose of the Vision is to gain consensus about what the architectural outcome should be so that architects can focus on the critical areas to ensure successful outcomes. Providing an Architecture Vision also supports stakeholder communication by clearly communicating the Vision.
A typical Architecture Vision statement will include:
- Current state (brief highlights):
- Stakeholders and their concerns
- List of issues/scenarios to be addressed
- Detailed goals and objectives
- Competitive advantage
- Cost reduction
- Greater efficiency
- Business agility
- Environment and process models (business architecture):
- Process description
- Process steps mapped to environment
- Process steps mapped to people
- Definition of services
- Information flow
- Actors and their roles and responsibilities:
- Human actors and roles
- Computer actors and roles
- Requirements
- Resulting architecture model;
- Constraints
- IT principles
- Architecture supporting the process
- Technical architecture mapped to business processes
- Requirements mapped to architecture
One note on closing Choices of EA Governance scope and style, like any corporate governance framework, are “situational” to some degree. Although there are proven best practices and a minimum set of criteria for guidance, existing corporate culture, operating models and patterns, and organizational structure will constrain and guide the framework.







Erik Haahr
13. Dec, 2010
Very good input indeed. I like it very much.
In one you jumped in with both feet in my opinion – Architecture Principles is not a subset of IT Principles!
Architecture Principles is a subset of Business Management Principles – or should be.
That one glitch doesn’t spoil a brilliant input to improving the practice of EA
Vic
13. Dec, 2010
Good catch Erik! Thanks. I’ve fixed it.
And thank you for the kind words.
Vic
Enterprise Architecture Governance – Part 2 | Strategic IT Architecture
24. Dec, 2010
[...] In part one of this two-part series I talked about some foundational aspects of EA Governance – Capability Assessment, Architecture Principles, and Architecture Vision. In this second installment, I talk about some key deliverables that guide and sustain a robust EA Governance program. [...]