The Essential EA Toolkit Part 3 - An Architecture Governance Process

The Essential EA Toolkit is a four-part blog on some recommended tools for Enterprise Architecture Teams. By "tools" I mean a few well-executed deliverables or processes that contribute enormous value to the organization (read Enterprise). These are not technologies; they require only standard office productivity software and perhaps a collaboration application such as SharePoint.

The Essential EA Toolkit (Part 1) identified the following four items:

• A Business Capability Model (see Part 1)
• A Standards Repository based on a Reference Architecture (see Part 2)
• An Architecture Governance Process
• A Strategic Blue Print and an Enterprise Roadmap.

This post examines the third - an Architecture Governance Process. In last week's posting I presented a definition of IT Governance:

"Specifying the decision rights and accountability framework to encourage desirable behavior in the use of IT."
- Weill, P. & Ross, J. W., 2004, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results", Harvard Business School Press, Boston.

Governance is an essential function of Enterprise Architecture. An Architecture Governance Process is the set of activities an organization executes to ensure that decisions are made and accountability is enforced during the execution of it's architecture strategy. An effective EA Governance process institutionalizes decision making and ensures accountability for decisions related to this. The Enterprise Roadmap, lays out the strategy, while the standards establish the building blocks used in execution.

The extent to which this definition differs from IT Governance depends on the role of EA in the organization. For most, the term "Enterprise Architecture" still implies "Enterprise Technology Architecture", therefore EA Governance is tactical and narrowly applied to conformance checking against technology standards. In a growing number of companies, EA is gaining ground as a strategic activity and therefore EA Governance is broad and approaches or exceeds the scope of IT Governance.

Here are two examples -

Example 1 - Tactical EA: An organization has established an Architecture Standards Repository and filled it with content specifying technology product configuration, application development and data management standards. The governance process specifies how projects and infrastructure services are checked for conformance, how they are approved, who gets to make exceptions decisions and under what conditions.

Example 2 - Strategic EA: An organization has just completed delivery of an Enterprise Roadmap in partnership with the business. The roadmap lays out the technology investment strategy for the next 18 months, identifying the programs and projects the business intends to invest in and how those investments build out the enterprise's architecture.

Governance process establish the checks, accountability and decision points to ensure that investment dollars execute against this roadmap and the future architecture is achieved. How will the organization identify deviations? How will they be handled? Who approves these? How will changes be communicated? Who is accountable if changes lead the organization astray?
Both examples are valid approaches and depend on how an organization defines Enterprise Architecture; it is therefore critically important to effective governance that an organization have a definition.

Here are  three components of effective EA Governance. The first two are commonly recognized as being part of "EA", while the third is an EA function in a strategic sense but is not solely owned and executed by traditional EA teams.

• An Architecture Review Process
• A Standards Management Process
• A Roadmap Management Process

An Architecture Review Process -

This process establishes periodic reviews of solutions at various points in the technology delivery lifecycle and proposes changes to the body of architecture standards. It is tactically focused; with the objective of ensuring conformance to strategy and standards, identifying exceptions, and documenting issues with enterprise impacts.

Most mature architecture organizations have some form of architecture review, however some overlook a fundamental benefit - review provides a chance to educate and seek consensus.
In these organizations, review is conducted purely by a team of "architects" who scrutinize the documentation and pass or fail it via an Architecture Review Board (ARB). This practice, while it can be effective, promotes an ivory tower perception and estabishes an "us/them" relationship between architects and the rest of IT.

A better practice is to have broadly attended Architecture Review Meetings to communicate, promote understanding of and answer questions about a proposed architecture. Invite managers and working level technologists from infrastructure, development, security, testing, and of course architecture. Out of the meetings document issues such as potential deviations from or gaps in standards; also identify enterprise dependencies.

With plans to resolve issues in place, architecture approval can then be sought by an ARB consisting of executives from the various IT departments - not just architecture. Since these executives and their subordinates were invited to the Architecture Review Meetings, there is no need to rehash details of at ARB. Instead, only the issues are discussed and approval is sought to move forward if items remain unresolved or exceptions exist.

In addition to being more collaborative, this approach promotes ownership of the architecture broadly across the IT organization and establishes clear accountability for proceeding via an executive-level ARB. In addition, it improves participation in the process because people's time is more effectively used. Working technologists can attend the review meetings, then brief their executives on issues at the ARB prior to vote.

Since a primary purpose of the Architecture Review Process for most technology-oriented EA practices is evaluation of solutions against enterprise standards, the next governance process manages those standards.

A Standards Management Process -

The Standards Management Process establishes change control over architecture standards (see The Essential EA Toolkit Part 2 - A Reference Architecture and Standards Repository). It defines how an organization tracks deficiencies and gaps in its body of enterprise standards and methodically works toward improvement.

While the Architecture Review Process is about review of solutions and changes in the standards; the Standards Management Process is about controlling the change process and communicating the impacts.

A good standards management process -

• Identifies and documents enterprise standards that need or present an opportunity for improvement.
• Assigns accountability and responsibility for improving the standards.
• Takes input from and proposes changes to technology and business components of an Enterprise Roadmap.
• Measures and reports against changes to determine effectiveness.

A Roadmap Management Process -

A final element of effective EA Governance is managing change against the Enterprise Roadmap. I consider this an EA process even though it is not entirely owned and executed by the EA group (depending on the organization's definition of EA.) In many IT shops, management against strategic assets such as a roadmap is the function of a business strategy and planning group. This team is, in a broad sense, part of the organization's EA function, whether so named or not.

I tweeted recently, "Having a roadmap is only half the battle. Executing to it and managing change against it is equally as tough!" I was surprise at the number of retweets, indicating that this is on people's minds.

An effective roadmap management process has several elements. First, a clear definition of what the roadmap is and is not is essential; creating this definition can be tough. Is the roadmap a PowerPoint presentation? Is it the underlying data about the proposed investments and technology landscape? Is it statements about strategy and desired outcomes made in other communications?

Once the contents of the roadmap have been defined, components that will be controlled, Rules about how changes are made and who approves them must be clearly documented. The Roadmap Management Process helps set expectations, promoting continued business and IT partnership through transparency. Without it, the benefits of the roadmap quickly vanish as uncontrolled changes make the roadmap irrelevant and governance impossible.

In conclusion, governance is an essential EA function. It ensures strategic alignment of projects and assists in achieving technology goals by enforcing and managing exceptions to standards. Two essential elements of Architecture Governance that are traditionally viewed as EA functions are an Architecture Review and a Standards Management Processes. Roadmap Management is a crucial part of governance as well. I assert that developing and managing the roadmap is an Enterprise Architecture function, even though it may be owned and executed outside of the traditional EA team, hopefully in partnership with IT strategy/planning and the business.

Next I will conclude this series with the final, and in my opinion, most important tool - an Enterprise Blueprint and Roadmap.