Enterprise patterns: AGA

Enterprise pattern – Architecture Governance Anchor (AGA)

This pattern addresses a typical problem – where to start Enterprise Architecture (EA) governance in a practical way without “boiling the ocean”.

Illustration below is used as an anchor. It considers that a typical EA function has to have an EA tool which is populated with various EA artefacts to provide the EA knowledge repository to its “users”. It is supposed that the EA knowledge repository will improve the decision-making related to all modifications within an enterprise. For example:

• Formal project management process.
• Informal project delivery practices.
• Corporate-wide strategic programmes, business strategy and its execution.
• Continual process improvements.

Governance challenges

The typical architecture governance challenges are at the interfaces as shown in illustration below.

1 The EA function may be involved in some “very important” projects but the EA engagement into all IT-related projects is not systematic neither systemic. As the result, some IT solutions and tools are unknown to the EA function or the EA function is dealing with them in the post-factum manner not up-front.

2 Although the EA is a unique corporate function which, potentially, must holistically covers the breath (all business units) and the depth (strategy to execution from the business to IT) of the enterprise, the potentials of the EA may be not unleashed yet. Usual practices in the IT-related decision-making do not take into account the EA function, especially in “shadow IT” and some IT tool-centric groups.

3 Being a guardian for the coherent transformation of the enterprise, the EA function should be an entry point for any IT-related changes now and an entry point for all business and IT changes soon. All changes, ranging from strategy to BAU projects should involve the EA function to guarantee the feasibility of changes and their optimal execution.

4 Is the EA function equipped with tools that are adequate to its current challenges (primarily the undesired complexity of the IT landscape)? Can an EA tool handle the following:

• complete nomenclatures of the EA artefacts (solutions, processes, business functions, applications, services, roles, rules, data, capabilities, etc.);
• validated dependencies between the EA artefacts (e.g. which business functions used in a particular business process);
• established procedures to maintain the EA repository (e.g. it is updated at the end of a project) and
• descriptions for proven and ready-to-use solutions.

Without this information, it is impossible to estimate the impact of changes. Also reference architecture and available solutions are not known to project teams.

5 The efficient delivery of the EA function is about making the EA knowledge:

• available (complete, up-to-date, and logically organised),
• understandable (detailed instructions and expert support on demand),
• actionable (linked to change processes to be used by the business and the IT department without systematic involvement of the EA staff members).

Thus, the EA function will be perceived as a facilitator of changes.

6 Gartner recommends that the EA team should be about 1-2% of whole IT staff (for IT organisation of 1 000 – 5 000 people). Estimate if the EA team is adequately staffed.

7 The set of available competencies in the EA function may be at its initial level. In particular, typical missing competences are: business architecture, process architecture, cross-domain architecture and SOA (see as well http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-patterns-ear.html ).

8 If the users are not happy with the typical IT deliverables (develop something unformed and impose it to everyone) then maybe EA can offer something more adaptable to various needs of different users to make the diversity efficient.

Example of work items to improve the governance

The mentioned above governance challenges have to be analysed and prioritized. Potential work items to address some governance challenges are shown on illustration below (those work items are labelled stars).

The work item A is about obtaining the better input from projects. This allows avoiding duplications in the development (potential technique - http://improving-bpm-systems.blogspot.ch/2013/02/linking-business-strategy-and-it.html ).

The work item B starts to handle various EA artefacts (primarily processes, business functions, applications and capabilities) and relationships between them.

The work item C is adding some missing expertise into the current EA team.

The work item D is the selection of an EA tool which can handle all EA artefacts and produce various views (e.g. project, business unit, application portfolio, etc.)

The work item E is about improving the interface between the EA function and the project management processes. EA provides some tools and techniques to simplify project execution, for example:

• evaluation check-lists,
• templates for mandatory documentation (business case, architectural dossier, etc.),
• “as-is” EA artefacts and relationships between them,
• macro-planning,
• clear rules for approval gates.

The work item F may combine diversity and uniformity (potential technique -http://improving-bpm-systems.blogspot.ch/2013/09/enterprise-patterns-anisotropically.html ).

Evolution of the EA function

Logically, the EA function has to “expand” its influence step-by-step.

1. Staring from the IT domain and making it in order (EA is under the CIO)
2. Moving up-stream and helping to address operational issues (EA is under the COO)
3. Ideally, reaching the strategy level, EA function is enabling the execution of the corporate strategy (EA is under the CEO).

     

Thanks,
AS