TOGAF®: The Governance Balancing Act - Good e …€¢ EA governance doesn’t work in isolation – EA governance works best when it works in conjunction with all the other relevant

TOGAF®: The Governance Balancing Act by Roger Evernden

TOGAF® talks a lot about governance. Here are some of the big sections that cover this topic:

• Chapter 50. Architecture Governance

• Chapter 15. Phase G: Implementation Governance

• Chapter 48. Architecture Compliance

• Section 36.2.15 Implementation Governance Model

• Section 41.5 Governance Log

• Section 34.4.1 Governance Extensions [to the EA metamodel]

• Chapter 49. Architecture Contracts

If you look at this material it all looks very formal, and maybe a bit rigid.

Many EA teams that I work with feel that governance is a chore – an administrative overhead that they’d rather be without.

In my experience, governance doesn’t have to be a nightmare!1 So, what is the truth about enterprise architecture governance? Does it need to be stiff and stuffy? And what can you do to make it easier and more relaxed?

A key point is that for a successful EA practice you do need to have a clearly-defined governance framework and an effective governance process in place. But clearly-defined doesn’t mean swamped with bureaucracy. And effective doesn’t mean that the EA team should police every single decision and action across the enterprise.

HERE ARE A FEW SIMPLE SUGGESTIONS TO MAKE YOUR EA GOVERNANCE MORE OF A BLESSING THAN A CURSE:

• It helps if you have a simple definition of governance. My simple definition is: doing things properly. So, it makes life a lot easier if things are done properly in the first place! In EA, this means things like – explaining how the architecture constraints or enables the needs of the enterprise; making the architecture explicit; and involving all the relevant stakeholders in a debate about the various architectural options that are available. When everyone is engaged in the decision-making process it is less likely that

TOGAF Series #67 | ATL002:67

© Copyright 2016 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any other comments relating to the material contained in this document may be submitted to: [email protected]. Good e-Learning is a trading name used by

Educational Systems Ltd. The Open Group® and TOGAF® are registered trademarks of the Open Group in the United States and other countries

1. I’ve researched this in detail for one of my Executive Reports for Cutter Cohnsortium: https://www.cutter.com/article/ea-governance-administrative-nightmare-or-bureaucratic-dream-468346

© Copyright 2016 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any other comments relating to the material contained in this document may be submitted to: [email protected]. Good e-Learning is a trading name used by

Educational Systems Ltd. The Open Group® and TOGAF® are registered trademarks of the Open Group in the United States and other countries

there will be compliance problems.

• Remember that ultimately the EA role is not about enforcement. The EA team can make the architecture explicit; they can explain the costs, benefits, risks and consequences of the various future architectural options; and they can suggest, recommend, advise, encourage, inform, and influence decision-makers. But in the end, it is not the EA team that make the decisions – that is the role of executives and management. When the EA team is good at raising discussion to the architectural level, then they are better able to influence decision-makers, which results in decisions with a strong architectural foundation. Which makes governance easier!

• EA governance doesn’t work in isolation – EA governance works best when it works in conjunction with all the other relevant governance processes. So, EA needs to consider strategy and planning processes, day-to-day business operational processes, investment and budgetary processes, project and change management processes, and the development and implementation processes.

• In an ideal world, EA would define the long-term context and strategic vectors to guide all enterprise changes, so that they were sustainable and served the common good, and delivered a holistic and synergistic architecture that met all stakeholder needs. In practice, the EA team needs to balance these ideals against tactical and short-term initiatives. Some of these might be beneficial in the long-term, but others might be unnecessary or even contradict the long-term direction. There will always be duplication and redundancy, and governance will often need to address partisan interests at the expense of the greater good. Governance is a balancing act.

• The governance material in TOGAF covers all the basics:

• Chapter 50. Architecture Governance provides a framework and guidelines for architecture governance.

• Chapter 15. The objectives of Phase G: Implementation Governance are to ensure conformance with the target architecture by implementation projects and to perform

the appropriate architecture governance functions for the solution and any implementation-driven architecture change requests.

• Chapter 48. Architecture Compliance provides guidelines for ensuring project compliance to the architecture.

• Section 36.2.15 – the Implementation Governance Model ensures that a project transitioning into implementation smoothly transitions into appropriate architecture governance. The documentation points out that “within organizations that have established architecture functions, there is likely to be a governance framework already in place, but specific processes, organizations, roles, responsibilities, and measures may need to be defined on a project-by-project basis.”

• Section 41.5 the Governance Log provides a repository area to hold shared information relating to the ongoing governance of projects.

• Section 34.4.1 the Governance Extensions to the EA metamodel is intended to allow additional structured data to be held against objectives and business services, supporting operational governance of the landscape.

• And Chapter 49. Architecture Contracts provides guidelines for defining and using architecture contracts.

Supplement these formal guidelines with some common sense and practical wisdom: keep in mind the simple explanation of governance as “doing things properly”; remember governance is about influence, rather than enforcement; make sure that EA governance integrates with other key enterprise processes; and be prepared to make compromises, but always aim for the best archi-tectures in the long-run.