How Do You Apply Architecture Governance?

What actually is Architecture Governance?

Architecture governance is the process of considering all material technology changes and guiding or directing projects to make the best decisions for the organisation.

What’s your organisations context?

Depending on your organisation, how Architect Governance occurs can vary.  Factors like:

  • Size of technology changes in your organisation

  • The complexity of your technology

  • Number of specialised architects eg. infrastructure, security, integration, solutions architects etc. 

For smaller organisation there may not be much change, complexity or specialisation.  Your Architect Governance could be decided by your one architect (or most senior technologist) and the IT Manager. For much bigger organisations, it should involve representatives from your architecture disciplines, IT support, Programme office and head of Architecture. 

What does good Architecture Governance look like?



Again, it depends on the context, for smaller organisation project level Architecture Governance may occur at the project steering committees where the broader consequence of technology decisions are considered. Future or infrastructure (ie. non business driven) Architecture Governance could occur in meetings between the IT manager and the most senior technologist.

Assuming you’re a larger organisation, the Architecture Governance is more complex and should be more formalised. There should be Architect Governance committee that meets regularly (weekly / fortnightly) to direct projects and initiatives.

Roles Objectives and Principles

Like any successful committee, there should be a charter that defines the roles, processes and objectives. Roles in terms of decision making authority and responsibilities. Objectives that ensure the committee is aligned with the business strategy and objectives.

Principles remove a level of subjectively in solution decisions and create consistency.  Principles should be technology agnostic, stand the test of time, and define “the spirit of the law”. They should be discussed and agreed early in the life of the Architect Governance committee. Not all projects will align to the principles, nor should they, so you just need to explain why an exception should be granted.

Standing Agenda

If the committee is going to meet regularly, there should be a standing agenda that supports the required processes. Something along the lines of:

  • Review actions and status from previous meetings

  • Review new or changed initiatives or projects not assigned to an architect

  • Architecture Governance (bulk of session) requiring discussion & decisions

  • Enterprise Architecture Practice - big picture stuff in terms of frameworks, tools or missing roadmaps

Solution submission process

Decision Making 

Decision Making 

The Architect Governance committee meetings should be limited to discussing the more controversial decisions or receiving early visibility of what’s coming.  Lower level reviews and decision making occurs outside of the meeting. At the relevant points in an initiatives or project’s lifecycle (there may be some prescriptive gates, or the assigned architect may use some discretion) a submission is made to the Architect Governance committee.

That submission could be early and just a high-level diagram, or later in the lifecycle following a defined solution template. The submitted documents should be sent (a week?) in advance of the meeting to give the busy attendees time to review and provide direct feedback to the author prior to the meetings. Often it’s a good idea to have a central record of feedback so everyone can see the points already raised. The author should have already socialised any key decisions with the relevant specialists eg. security, infrastructure architects, application support.

For the meeting itself, there should be a short set of slides giving the attendees sufficient context (eg. project overview and high-level diagram) and call out key architecture decisions.  Those decisions and the associated pros and cons are what gets discussed / debated.

Not all submissions are for approval, so it needs to be clear if formal approval is being sought, or more guidance, or some discussion to achieve a level of consensus for the time being.

Decision Making Process

The outcomes of the submitted projects and initiatives needs to clear and be documented.  Typically projects are on tight timelines, so those decisions sometime need to be pragmatic. The outcome could be approval of the solution, rejection with changes needed identified, or approval to proceed on some basis / conditions which are followed up in a later meeting.

The Business Value of Architecture Governance?

Good Architecture Governance should identify and advise on:

  • the use of existing technologies where appropriate

  • solutions that aren't consistent with the existing environment, projects or technology direction (roadmaps)

  • hidden costs or dependencies that will create delays

  • hidden security risks

  • solutions that will be difficult support

The Architect Governance committee need to be more than just another gate the business needs to get past.  Architecture Governance needs to be seen to be adding business value and ensure it fights the right battles. Business context needs to be applied to what gets reviewed and the actual decision making eg. is this an easily reversible decision, what are the business imperatives and timelines?  Technical debt is not necessary a bad thing, so long as it’s acknowledged and ideally planned for.
At the end of day, the business (or project steering committee) needs to make the final decisions re their projects considering more factors that just technology, they just need to ensure they are fully informed.


Cyma Logo