As we discussed last time, sharing your Enterprise Architecture with stakeholders in other areas of the business is a natural activity. However, when sharing your repository with stakeholders outside the Enterprise Architecture team, it’s a good idea to consider what the concerns of that particular group of stakeholders are, because what those concerns are will (or at least should) influence the design decisions that you take in how you share the repository with them.
Today I’m going to consider the topic of governance and review. By governance and review, I mean - what the concerns are of those stakeholders who are involved in the governance and review of the content within the EA repository itself?
In practice, there are two groups of stakeholders that fall under this category, and they have slightly different needs that have to be met. These are:
- The department that is responsible for IT governance in general (usually this has a name like the quality office, the program management office or suchlike).
- The staff members tasked with actually reviewing, commenting on, and approving content. Usually this will be the architecture review board (which tends to have a fixed membership), but other stakeholders can become involved.
While they both get involved with Enterprise Architecture in the same content (in other words, governance and review), these two different groups will have somewhat different concerns that need to be addressed independently.
The ‘IT governance department’ is primarily concerned with ensuring that governance processes exist, are available, can be consulted, and can be audited. Implicit in this is that they will have reviewed and approved these processes.
What this means in terms of sharing the EA repository is two things. First, it means that the enterprise architecture governance processes need to be easy to locate and view. Second, it means that the records of review meetings need to be easy to locate and view (for audit purposes). Both of these two requirements are best met by structuring the repository with a clear governance section, divided up into quasi-static content (meaning standards and processes) and review meeting records. In a perfect world documents would also be tagged with project codes, but I’ve not yet seen a repository that can automate this.
Meanwhile reviewers will want the ability to consult architectures in their time and at their own convenience; the ability to consult architecture principles; the ability to raise questions of the author; and the ability to log comments.
So what works to accomplish this? Technically all of these activities can be accomplished manually; but the purpose of an EA repository is to facilitate the work of the department – so what functionality can a repository offer to ease these activities?
First, if possible, documents should be capable of being consulted remotely (ideally via mobile devices such as tablets). Secondly, the repository should have some kind of ‘favorites’ link to the architecture principles to enable quick access. The online access should also have a way to contact the author with comments and questions seamlessly.
Some of these recommendations might seem trivial. However, ease of use is an important factor in buy in and uptake. Since governance and EA are inseparable, how you share your EA repository with governance and review stakeholders becomes an important factor in the successful usage of the repository.