Simplify Architecture Governance to derive value from Enterprise Architecture
As rightly pointed out by a Forrester report, “improving perception of EA” is the key challenge and the common goal of Enterprise Architects. While developing an Enterprise Architecture Blueprint itself is a commendable job, it is only part of the job done. The real uphill task is to make the blueprint a useful one and this is where, “Architecture Governance” that has become the byword for ensuring effectiveness of Enterprise Architecture comes in. Today, there are multiple definitions, frameworks and tools available for establishing Architecture Governance.
Of the available definitions, the Open Group definition is quite comprehensive. “Architecture governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. It includes the following:
- Implementing a system of controls over the creation and monitoring of all architectural components and activities, to ensure the effective introduction, implementation, and evolution of architectures within the organization
- Implementing a system to ensure compliance with internal and external standards and regulatory obligations
- Establishing processes that support effective management of the above processes within agreed parameters
- Developing practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization”.
While it is good to have detailed frameworks, in my opinion, in most organizations lots of effort is spent on establishing the hierarchy, roles, responsibilities, reporting structure, communication structure, periodical meetings and of course debates. In effect, while it started as a way for EA management, “Establishing Architecture Governance” has become a full-fledged project by itself.
I am sure that most would agree that the “typical Enterprise Architecture Governance Framework” sounds more like a “wish list” especially in terms of its expectation of roles to be played by the Senior Management and CxOs. The ambiguity of the metrics that get listed as the means to measure effectiveness of EA is another thought-provoking area. For example, the metrics of “number of changes made to the EA blueprint” – can be negative in the sense that the EA blueprint originally created was not up to the mark or really positive that the EA blueprint is being widely used and hence the large number of feedback and/or that the EA team is open-minded enough to accept comments and make changes.
In any case, in trying to establish “The Right EA Governance Framework”, we seem to be losing sight of the original intent namely “Getting Value out of Enterprise Architecture” (this is not about establishing the benefits of EA, but about actually reaping these benefits).
Simplifying the EA governance is the key to realizing its purpose and some of the points to be noted are:
- It is rightly said that EA Governance is about “Communication, Communication and Communication”. Establishing a simple, open, communication channel (easily done in today’s collaborative world) is the first step.
- Involve the right set of people – the ones who are actually impacted – in evolving (or better still, creating) the Enterprise Architecture. Creating the blueprint, and then coming up with governance to enforce it, is the sure recipe to failure.
- EA Blueprint should lend itself to make Governance easier. Governance should not be an after-thought. Simple steps like prioritizing the EA principles, considering the situations when the principles could contradict each other, listing out the ways in which the contradictions can be managed, providing alternatives (and not trying to enforce “one-size-fits-all” kind of standards), visualization exceptions where the principles could be waived etc. during the evolution of EA would come a long way in making governance easier.
- Saving details of the alternatives discussed, rationale for choosing an option, briefing the “second-best”, including conditions when an EA principle becomes invalid etc. would make managing and controlling EA easier. Though it sounds like a difficult task, the amount of time, effort and thinking that goes in creating an Enterprise Architecture justifies it. This is where the tools – covered in blog http://itknowledgeexchange.techtarget.com/enterprise-IT-tech-trends/using-modeling-tools-to-ensure-enterprise-architecture-governance/ would be of real help.
- The goal of EA governance should be two-way: “Enforcing EA wherever it makes the most sense” and also “Having EA flexible enough to avoid it becoming a thorn during project executions”. It should be understood by all parties that it is not the question of “a single right answer” but what is most relevant at this point in time in the given context (external factors like recession play a role in deciding whether time-to-market takes precedence over cost effectiveness).
- The exception handling should be well thought of and most practical. It is to be accepted that, not all exceptions need long debates or senior management involvement. Again open communication, rationale behind decisions, use of hard data etc. would help in achieving smooth handling of exceptions.
- Senior management intervention should be considered only in case where the exception or decision involves “Enterprise-wide” and/or “Significant Financial” impact.