Establishing Enterprise Architecture Governance

Introduction

The intent of the Enterprise Architecture is to define how to build systems and capabilities for the greater good of the enterprise. Architecture governance is the process by which IT projects are reviewed in terms of their alignment with a defined architecture, and corrective changes made.

John Zackman, in a recent article (DM Review, December 1999) called architecture a 'countercultural' activity. What he meant by this was that IT's attention has been focused on producing running code, not on design for intangible future benefits. Architecture without governance is trying to promote this countercultural activity upon project teams that are goaled and measured by other, often conflicting criteria. In any reasonably large size IT organization, projects are identified and executed in a distributed manner. It is difficult for these projects to align with any sort of 'master plan'. Without a master plan, the overall IT environment; platforms, components and applications, is difficult to understand, let alone manage. The difficulties many organizations had in effectively preparing for Y2K attests to the dangers of developing and maintaining applications in the absence of such a plan.

If Enterprise Architecture is the basis for this 'master plan', architecture governance is the means by which the benefits of enterprise architecture in terms of flexibility, cost-effectiveness and overall ability to support business change are realized through projects. Governance is anchored on project reviews and checkpoints at the appropriate points of the lifecycle.

This article discusses the issues around implementing architecture governance, and what constitutes viable approaches to establishing effective governance processes.

Enterprise Architecture

The IT environment: applications, platforms, technology, changes as the business it supports changes. IT is now central to the business strategy, instead of being a supporting player. In the new world of e-business business management respond by increasing the pressure to 'deliver the goods': new applications, new ways of utilizing existing applications, increased integration.

To ensure that the investments the enterprise makes today will continue to have value in the future, companies develop rules to constrain diversity and to channel resources into developing competencies that can be applied across programs and projects. These rules comprise the enterprise architecture and in most large organizations there is a specific function in the IS organization, enterprise architecture, that takes the leadership role in identifying, formalizing and publishing the architecture

Typically an enterprise architecture will address the following areas;

• Technical standards. These are the foundation of every architecture program. Technical standards may be fairly general: "TCP/IP", "Oracle", or very specific: "Solaris 2.6", "Netscape Enterprise Server 2.5.1", "NT 4.0sp6a". Technical standards are essential means to control the diversity of the IT infrastructure.
  
  
• Technical architecture or technical design architecture. These are the definitions for how applications should utilize the technical standards. Again, they can be fairly general: "Databases should be on separate servers from application code", or very specific: "applications that require complex transaction support, and are used by more than 100 users, should utilize net-centric designs with an Enterprise Java Bean-based transaction management". Sometimes the term "application patterns" is used to describe this level of architecture. Technical design architecture controls the diversity of the types of applications that are developed, deployed and supported. They may also reduce project risk by steering them towards "tested designs".
  
  
• Application architecture or business application architecture. This architecture focuses on how business functionality is provided across the portfolio of business applications; which functions are common, how they are shared, the designs for these functions, and how the data that these functions use is managed in a way to ensure quality and availability. The benefit of architecture at this level is achieved during the planning of new IT initiatives.

Each of these architecture areas potentially constrains the choice of solution for individual functions. If the process is working well the synergies created from building on a shared infrastructure, and the accelerated implementation possible from designing around standardized components will more than offset any local sub optimization.

However, is important to realize that while the architects tend to see these as clearly articulated, appropriately layered, and justifiable choices, each project grapples with decisions across these layers only touching pieces of the whole solution set. To a project team, there are no clean demarcations, only points in the project lifecycle where different decisions are made.

System Architecture

Within a project some sort of system architecture will be generated early in the process. This is becoming so much a part of best practices that there is now an IEEE standard for system architecture. A system architecture should show how the proposed design satisfies the user requirements. This system architecture is typically owned by the project team and is one of the building blocks, along with the project plan, for controlling scope and quality.

We can think of enterprise architecture as adding a second set of requirements based on management policy and decisions and so creating a superset of requirements to be fed into the system architecture process. However, requirements often conflict: low project cost vs. application extensibility, for example.

Conflict between requirements can be resolved by one of the following techniques:

• Innovation and creative design that leads to radically new and better solutions.
  
  
• An ugly compromise that leads to no one's needs being met effectively.
  
  
• Optimizing to some requirements while ignoring or paying lip service to others.

Breakthrough solutions are desirable, but cannot be realistically expected from most projects while compromise probably needs to be avoided. In practice, judgement is required to determine which of the requirements for this project have priority and, in the absence of opposing forces, that decision is usually decided in favor of the client who holds the budget or the manager who writes the project manager's review.

Governance

The purpose of the governance process is to create intervention points in the technology acquisition and development processes that force reasoned consideration of how the totality of requirements is being addressed.

The pressures to not honor the enterprise architecture are many.

1. Culturally, IT are "doers". The planning horizon is tactical - 'the next phase'. This is a response to business pressures to deliver applications. IT operations staff are conservative - while acknowledging the business need, every new system makes optimizing the operational environment more difficult.
   
   
2. Project success is measured in terms of schedule, cost and functionality as defined by the business sponsor. 'Improving the overall IT environment' does not appear as a project requirement.
   
   
3. The need for greater delivery speed. Rapid development methodologies are superceding structured project lifecycles. Deliberative approaches to planning don't fit this model.
   
   
4. While budgets have been freed up post-Y2K, there is a tremendous pent-up demand for application overhaul. IT organizations are being asked to "do much more with a little more budget".
   
   
5. "Buy before build" brings in application packages which must be fit into the existing IT environment.
   
   
6. Outsourced application development brings the outsourcer's view of architecture at the project level into the environment.
   
   
7. Business acquisitions, where the initial imperatives are first, to connect systems and second, extract costs.

These challenges become opportunities to sell business and IT management on the benefits of architecture governance. Without any review process, these challenges are addressed one-off and the result is greater chaos. Governance becomes the means to balance the impact of these challenges and use them for the optimization of the whole environment.

Architecture governance should be a single end-to-end process, although with different types of reviews and checkpoints to evaluate the different types of decisions being made.

Pre-requisites for Effective Architecture Process

Governance works best when it is a collaborative process. In some organizations this is not possible and the tension between the enterprise architects and the project teams is resolved through political power. Typically though, this is not sustainable and formal enterprise architecture is abandoned.

For collaborative approaches to work there has to be some alignment of goals, and effective, frequent, and open communication. Factors that help institute these include:

• Clear goals that align with the interests of the organization. For example, if there is a single group that provides infrastructure services, they have a natural interest in projects utilizing standard technologies in standard configurations. Senior management with budget authority over many development areas and projects will be interested in design standards and supporting review processes that minimize redundant project expenses.
  
  
• An understanding by stakeholders of the purpose of architecture review. These stakeholders include project sponsors, project managers, shared infrastructure management and IT management with operating budget authority.
  
  
• Availability to project teams of documentation, or more importantly, people who understand what is trying to be achieved - the goals, and the current state of the architecture specification. There should be "consulting architects" available to project teams. These consulting architects balance the goals of the project team with the interests of the overall IT function in 'conformant' project designs.
  
  
• A consistent project lifecycle process (SDLC). This is important for the timing of review checkpoints. For illustration in the next section, a 4 phase project lifecycle: planning, design, construct and implementation, is used.
  
  
• Along with a consistent SDLC is the need for consistent project documentation. The start of a project should generate a project initiation document providing a high level view of project scope, goals, approach. This triggers the start of the review process. During the early phases, the factors that direct the design, and the design itself, need to be documented with increasing degree of specificity. All these documents must be available and shared outside of the project team.

Designing the Process

The heart of a governance process is presentation and review with the purpose of discovering gaps in the project scope, approach and technology selection.

An analogy for governance is often the building permit process for construction projects. There is certainly an element of checking for conformance to standards, but good design requires more than conformance to standards. Enterprise architects are often uniquely positioned, through their exposure to all the projects in the enterprise, to identify opportunities for reuse of existing technology and improving delivery against service levels

Some of the key decision points in designing a governance process are:

The review and governing body

The issue with establishing the review and governing body is how centralized or decentralized it is, and who performs this function. A centralized body provides better control; a decentralized body, better responsiveness to specific area issues. Participation by a broader range of stakeholders may be easier with a decentralized group, although again, this can lead to more compromises and less control. Some of the factors going into this decision are 1) how significant local issues are to the overall organization, 2) the scope of architecture definition, and 3) the need for buy-in by the project teams and their management. On this last point, take a lesson from democratic forms of government, that to get people's willingness to be governed, you must include them within the governing organization. What this means to architecture governance is that all parts of IT organization must be represented. Identify who should be the architectural evangelist within each area, and bring them into the governing body.

More than one governing body, or a single body with different subgroups, may be needed. Different types of architecture: technology or application, require different representatives in the architecture governance. Business relationship managers should participate in application architecture review. Infrastructure services should be very involved with technical architecture review.

Determining which projects get reviewed

Should all projects get reviewed, or only the large ones? While it may be appealing to reserve architecture review for projects deemed "significant", in practice this can get messy. Defining the threshold is difficult (and can be political). All projects should have some level, if only to determine their impact, and need for a complete review process. Thresholds may be used to drive the types and depth of review. Criteria in the threshold could include project size/cost, whether it is 'introducing something new that will be lived with for a long time', whether project is part of multi-phase program, and if so, is it the first phase.

Timing and content of reviews

As a project progresses from inception through design and into construction, the project team will make many decisions of architectural significance. The purpose of a review is to check their decisions before they've progressed too far to change them, or to check their thinking before they've made a decision. Timing requires a balancing between "too early" - options are still being identified and sorted out, and "too late" - the team is acting upon a design decision. A way to address this conundrum is to have a consulting architect who can provide frequent checkpoints and guidance, backed up by project phase-based reviews by committee. The existence of these phased-based reviews provides authority to the consulting architect whenever a project is grappling with "the quick way vs. the right way" decisions.

The content of a review is a function of where in the lifecycle a project is, and the purpose or type of review. Using a four-phase lifecycle; planning, design, construction and implementation, and the three types of architecture discussed earlier, each type of architecture can be mapped to a review during a phase. The purpose of each type of architecture will be used to determine what information is presented, and what are possible outcomes. The following table is one example of how this could map.

[1] Application Architecture review, instead of making approve/deny decisions, may alternately provide directions that must be reflected in designs reviewed as part of technical architecture.
[2] Operations Model and Implementation Readiness reviews, while not specifically architecture-oriented, provide opportunity for additional value to shared service functions.

When an organization is implementing an architecture review process for the first time, three reviews may be a lot to implement at once. Which review to start with has to be decided based on the circumstances in the organization.

Qualitative or Quantitative?

It is the comment of the relative immaturity of the architecture process that most companies have limited architecture governance to qualitative reviews of designs. However, companies that have adopted strong system engineering methodologies are also developing metrics based processes for estimating TCO, maintainability, availability, and the ability to meet performance goals as part of the review.

Escalation process

There will be many circumstances where a project isn't conforming to architecture standards. Some deviations may be of small consequence: a different version of software, or a non-standard configuration of a dedicated server. Others may have much larger impact, ranging from creating a need for dedicated support resources to violating a strategy for customer data management.

1. The heart of the governance process is how these "variances" are resolved or mitigated. Governance cannot become inflexible (just as it can't be too flexible) without degrading effectiveness. The key is to establish a policy on managing variances. Some companies have developed formal scoring for variances, with a threshold score for re-evaluating or denying project approval.
   
   
2. Variances may result in a higher implementation or support cost - a "tax".
   
   
3. Variances may trigger "executive level review" - even as a "heads-up" to senior management.
   
   
4. Variances may mean that a project cannot use certain parts of a common infrastructure. - shared servers, system management and monitoring, shared staff, and therefore must incur the expense of its own infrastructure.
   
   
5. Variances could require that the project team does extra work - verifying and assessing impact on the environment, the overall budget, the stability and manageability of the infrastructure.
   
   
6. Psychological - a big red "V" on a project, with peer and management pressure to "not have this happen again". How well this works over time is a function of culture and management objectives.

Tips on Implementing

Do you need to wait until the architecture is all defined to move forward with a proactive governance process? Logic would suggest yes. However, fully defining an enterprise architecture takes a long time, and in many ways, due to change, is never complete. A more workable approach is "just enough architecture to direct projects along critical dimensions". These dimensions arise from the interests of the IT organization in architecture governance in the first place. Governance requires a change in culture, and tackling the culture change; establishing a norm of design reviews for projects, may best be decoupled from architecture definition. Critical factors may be establishing:

• The criteria that projects are being measured against, and
  
  
• Value of reviews even when they are "informational" in identifying issues and opportunities.

A key success criteria, often overlooked by 'introverted architects', is "Communications, communications, and more communications". The review goals and process must be widely understood. The rules around the conducting of reviews, and how the review results are expected to be reflected in a project deliverables, should be documented and communicated. Discussions minutes should be documented and made available to everyone associated with a project or with a need to know. Training should be provided to project managers. The process should be 'open and fair' - not a mysterious process with some winners and losers.

Don't overlook the need to measure and communicate the value of the governance processes. Identify what should be measured based upon the interests of the organization, and also the interests of the project team. Some potential metrics are:

• The number of projects reviewed as a portion of the overall project portfolio, or of IT spending.
  
  
• Categorized results: projects approved, approved with conditions, approval pending or denied.
  
  
• Types of architectural issues raised and reviewed.
  
  
• The relative frequency of different types of architecture variances being requested or allowed.

Quis custodiet ipsos custodes? ("Who watches the watchers?")

This article has concentrated on how to gain compliance with an enterprise architecture. However, it is important to acknowledge the need to keep the architecture relevant and useful. How does management know that architecture is practical, well-defined and appropriately focused?

Unfortunately there are no generally accepted standards for an enterprise architecture. The authors of this paper have seen very few enterprise architectures supported by hard numbers for cost savings, improved quality, or reduced time to deliver. In the absence of these metrics support for enterprise architecture depends upon the perceived quality of the architecture process.

The governance process defined here provides some feedback on these issues and the information collected from the project reviews should be an input into the next evolution of the architecture. However, there also needs to be a formal governance process for the development, adoption, and maintenance of the architecture itself.

Conclusion

IT application development projects often are faced with 'the quick way versus the right way' decisions. Project teams are all too familiar with the results of years of application implementation without a master plan, as the results have made their current task more difficult. The pressures to deliver do not give them the time or scope to consider overarching architecture considerations. A review and governance process is essential as a counterbalance to these pressures in the short term, even as the architecture 'master plan' is an enabler of longer term development benefits.

If enterprise architecture is to be effective it has to be integrated with project management through a governance process that is consistent with the management culture. Governance has to build upon the interests of the IT organization, and application development processes in use. It should be constructed as an end-to-end process, starting at the initiation of a project, and sensitive to the design decisions that are made throughout the project lifecycle. To achieve organizational buy-in, broad participation should be sought. Rules on the implications of non-conformance should be clear.

Defining an Enterprise IT Architecture, whether at the Application Architecture level, or Technical Standards, is a significant investment of time and energy. The value from this investment is realized through application development projects. Enterprise Architecture Governance is an essential complement to Architecture definition.

The Authors

Alex Cullen is the Director of Application Architecture at John Hancock Financial Services.

Jon Blunt is the Executive Director of The Information Architects Cooperative (TiAC), an association of enterprise architects from a variety of large corporations.

Comments on this article can be sent to Alex at acullen@jhancock.com, or Jon at jblunt@infoed.com.

Editor's Note:
This article has been modified from its original form since the original publication date.