One of the most important and often overlooked architecture outcomes is the opportunity to provide effective Architecture Governance of an organisations change program.
By: Andrew Swindell, firstname.lastname@example.org | This article previously published here.
Deploying an effective Architecture governance structure is a very public display of architecture guidance and oversight allowing Architects to come together and influence current and target state environments and articulate how change will impact and improve the way an organisation does business.
As Architects, we are all acutely aware of the need to provide a consolidated set of architecture guidance to our stakeholders as it builds credibility, trust and acceptance of the partnership role that Architecture should and can provide. Some definitions are important to ensure we are all talking the same language as follows:
“EA Governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level”.
Enterprise Architecture and associated efforts are only of value if the EA team maintains its relevance, and drive the organisation towards the agreed future state. Therefore, Architecture Governance must ensure that:
- The Architecture representation of proposed concepts and strategies matches the future needs of the organisation
- The Architecture role is clear in governing the architecture alignment of projects
I will use the term “Architecture” generically to represent both Enterprise and Solution Architecture as both disciplines should be joined at the hip to influence strategic direction and delivery through building collaborative working relationships with stakeholders and project teams.
Where are you on your Architecture Governance journey
An understanding of your current maturity and positioning of Architecture in your organisation is critical to developing and maturing your Architecture Governance capability. What is also critical is the level of acceptance and understanding of Architecture value from your stakeholders.
I have been involved in environments where Architecture has a poor reputation and Architects are actively disengaged by Project Teams / Business and Technology teams and also seen environments where Architecture has a strong voice and a seat at the business and technology strategy table. Both require a different Architecture Governance response and the experience levels and Architecture exposure of your stakeholders and your Architecture Leaders will dictate the strength of Architecture Governance outcomes achieved.
There are a number of Architecture Maturity Models outlining the various levels of Architecture Governance Capability, however I like the one below as it is a simple model relating time, outcomes and expectations to guide the planning and development of your Architecture Governance capability.
Undertaking an Architecture Audit of your environment enables a consistent view of Architecture positioning and outcomes and is another opportunity to engage stakeholders in a discussion on your Architecture journey. The ultimate goal for the Architecture function is to proactively support and align business and technology strategy with delivery and execution, however it is fair to say very few organisations have achieved all of the milestones above.
Starting your Architecture Governance journey
A number of critical elements of governance are required to manage and control an organisation’s Architecture and enable the Architecture Department to improve Governance outcomes from “Reactive” to “Managed” including:
- Establishing the core Architecture Team and cross-functional Architecture Review Board with the backing of top management to oversee the implementation of the future Architecture vision and roadmap.
- Establishing a comprehensive set of Architecture Principles, Standards, and Reference Architectures to guide, inform, and support the way in which your organisation sets about fulfilling its strategic objectives and priorities through the use of IT.
- Implementing an Architecture Review and Approval Process to ensure individual projects and procurement decisions comply with the Architecture.
The Architecture models and modelling standards are one of the first steps to gaining traction in your Architecture Governance journey. In many environments multiple architecture methodologies have been deployed which only serves to confuse your stakeholders and unless you have a baseline agreement within your Architecture community you will forever be seeking clarification and hamstrung in your Governance efforts.
Essentially the choice of Architecture modelling frameworks is more about making one choice and deploying it consistently as most of the Architecture modelling frameworks are evolving and do not address the full gamut of Architecture requirements and opportunities.
Definition of Architecture Roles
Another important contributor to your Architecture Governance outcomes is the clear definition of roles and the matching of experienced Architects to those roles. If you ask Business Analysts or Project Managers to perform the Architect role, expect a time lag in Architecture outcomes and negative impact on your Project timelines. Project Management has PMBOK and Prince2 methodologies to drive consistent project outcomes and it is critical that a consistent Architecture methodology is deployed in your organisation to support consistent Architecture outcomes.
A summary of the key Architecture Roles and governance activities to be deployed in your organisation is as follows:
Architecture Manager / Head of Architecture
- Own EA Strategy and provides Architecture leadership
- Liaise with IMT Committee regarding strategic direction and priorities
- Establish Architecture framework and methodology
- Initiate/Influence a program of work
- Assign a Program Architect
- Identify projects in collaboration with Program Architects
- Communicate EA Principals, Standards and Architecture Vision
- Communicate program outcomes and business value to Architecture Review Board
- Communicate Application Principals and Standards (Examples: SOA / WOA / BPM / JEE / Dot Net )
- Govern solution outputs
- Identify synergies between projects
- Facilitate and co-ordinate collaboration between projects
- Communicate Program Architecture , including Architecture Decisions to Architecture Review Board
- Communicate solution options to stakeholders (e.g. Custom build vs COTS)
- Define Conceptual Architecture for business case
- Define Logical Architecture for system design (e.g. Service Model, Rules and Policy Model, Business Intelligence Model, UI Component Model, Canonical Data Model)
- Communicate the Solution Architecture , including Architecture decision to Architecture Review Board
Definition of Architecture Principles
Architecture Principles provide the guiding lights for how Architecture is deployed and how Architects should behave in delivering Architecture Governance outcomes. Apart from your organisational values, they are critical hooks for ensuring that Architects and Architecture Governance decisions are aligned and enable a consistent message to be portrayed with stakeholders.
An example of high level Architecture Principles is as follows:
- All IT changes are subject to Architecture Governance using a common risk based approach.
- The Architecture Governance profile is dependant on the scope and type of IT change.
- Architecture Governance will be applied to the following types of changes:
- Business Unit Roadmaps and Target Architecture;
- IT Asset Roadmaps and Target Architecture;
- Small IT enhancements.
- At the point of initiation;
- In an ongoing manner that supports actively ensuring.
- Changes with new development that does not fit with the natural progression of the asset;
- Changes that effect multiple applications;
- Changes across multiple platforms;
- Major version upgrade of vendor software or applications.
- At any logical time leading into critical milestones in the Project lifecycle;
- At any time a significant change in scope or nature of the IT change occurs;
- At any stage significant deviation from agreed Architecture is identified.
Deploying your Architecture Forums
If you have your Architecture methodology defined, a set of Architectural Principles and your Architecture Roles created and resourced then a logical next step is to create a formal review and governance environment to support the deployment of Architecture Governance.
There are a number of critical components for your Architecture Forums including a Terms of Reference (ToR), processes for engaging the Architecture forum, a clear statement of value and intent of the forum and a strong mix and agreement from stakeholders to deliver on those outcomes. The Architecture Chair and Secretary perform the critical functions that ensure the ToR are followed, cross unit issues are addressed, exemptions are managed and the Architecture outcomes are achieved.
Below is a summary of some of the key inputs required for your Architecture Forums:
An example model for using Architecture Governance forums that has been successfully deployed is based on the following diagram:
Here the key Architecture value and governance is delivered by the Architecture Advisory Group to senior stakeholders and the Design / Domain specific Authorities provide oversight on the Solution Architectures being produced by each project.
Another model supporting Architecture Governance below enables a holistic assessment of what domains Architecture should govern and influence and at what level of detail.
In the above example the Architecture Governance requirements can be plotted on the model and the appropriate Governance structures and response can be established to address the organisations greatest challenges. If business or technology strategy is unclear or not aligned then an Architecture Advisory Group will bring stakeholders together to discuss strategy and govern the portfolio. If projects are out of control or Program scope is unclear then an Architecture governance forum focusing on Projects / Solution Architecture would be more appropriate.
Architecture Governance Processes
Strong Architecture Governance processes support communication and understanding of the value provided by Architects and the Architecture function and consistent messages to be portrayed with your stakeholders. Some critical governance activities include clearly defined processes, roles, regular training and communication newsletters, communication of governance minutes and outcomes, clarification of Architecture principles and a chase for opportunities to highlight Architecture value to your stakeholders.
Final say on Architecture Governance
Architecture Governance and oversight can claim Executive careers, enhance Executive careers, realise CEO strategies and align Portfolio, Program, Projects and Business and Technology teams. But whatever governance outcomes you are chasing the value of Architecture Governance is a critical input to delivering Architecture value to your stakeholders.
All articles are © 2015 by the authors.
The views and opinions expressed by our authors are those of our authors and do not necessarily reflect the official policy or position of IRM UK.
This article was featured in IRM UK’s Monthly E-newsletter. To subscribe please visit http://www.irmuk.co.uk/usefulinfo/enewsletter.cfm. Please note we are always on the look-out for new contributors so if you have an article you would like published please forward it to email@example.com for consideration.
IRM UK Strategic IT Training Ltd. 2nd Floor, Monument House, 215 Marsh Road, Pinner, Middlesex, HA5 5NE, Tel: +44 (0)20 8866 8366 E-Mail: firstname.lastname@example.org Web: http://www.irmuk.co.uk