© 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: marketing@goodelearning.com. 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

Transformational Change: PART 1 Customizing and Expanding TOGAF® for Integrated Governmentby Roger Evernden

TOGAF emphasizes the need to tailor its documentation to meet the individual needs of each enterprise architecture project. Every enterprise and every project is unique, so it is impossible to provide a generic enterprise architecture framework that would work for everyone.

In this four-part article, I’m going to discuss two inter-related things you need to consider as you tailor TOGAF®:

1. How to tailor TOGAF to meet your needs?

2. How to keep everyone up-to-date with the customized approach?

As every situation is going to be different, I’m going to use an example which will be familiar to most readers – the use of enterprise architecture to produce greater integration across government bodies. Everyone has their own personal experience in using government services. We all live in countries that are managed and run by government services, which affect us every day of our lives. In EA terms, we all have our personal viewpoints and views of the government architecture.

PART 1Adapting TOGAF for a complex and mature EA initiative

How do you go about tailoring TOGAF® to meet your needs? There is, of course, no single way to adapt TOGAF to your needs, so here are some observations drawn from government enterprise architecture projects.

Government and Public-Sector EA Projects – Maturity Makes a Difference

The first point is that Government and Public-Sector EA projects are frequently ahead of the curve when it comes to the effective use of EA techniques. This is partly because government comes under direct public scrutiny, and is therefore extremely sensitive to keeping costs low, reducing waste and inefficiency, and finding effective ways to share resources and infrastructure. Consequently, the benefits and value from EA are more visible and obvious than it might be in a big company with largely autonomous business units and divisions.

TOGAF Series #86 | ATL002:86

© 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: marketing@goodelearning.com. 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

In a government context, the value and benefits of EA may be already assumed, so there may not be a need to persuade sponsors that EA is the right discipline to use. For example, in some countries EA compliance is a pre-requisite ahead of project funding. As with any EA practice with an average or higher level of maturity, TOGAF might not be needed to establish EA governance, or to establish a process for developing architectures. The value of TOGAF is therefore arguably higher for an organization or individual starting out with EA; if you are working in an enterprise where EA is already an established practice, then you will have less need to spend time tailoring the basics of the Architecture Development Method (ADM) or the Architecture Capability Framework.

If you are basing your practice around TOGAF then you will still need to revisit these parts of the documentation - Part II – ADM, Part III - ADM Guidelines and Techniques, and Part VII - Architecture Capability Framework – during the Preliminary Phase of each initiative. But in effect this will be to refine a version of TOGAF that you have already tailored, possibly on many occasions for many other projects. When you are at the Initial or Under Development stages of maturity you need to spend a lot of time and effort in establishing the most appropriate EA process and governance. When you are at the Defined, Managed or Measured levels of maturity the amount of effort to tailor these parts of TOGAF will be much reduced.

Some government architecture frameworks are more advanced than others. For example, architectural compliance is mandatory for U.S. federal government projects, so there has been much investment and effort spent on developing the Federal Enterprise Architecture. A growing number of countries are following this trend; for example, in India with the IndEA initiative1. You can get some idea of the importance of these developments by the fact that the United Nations updates its survey on e-government every two years2.

EA compliance is becoming accepted as a fundamental principle in many other organizations, and as this happens a large proportion of the documentation in TOGAF will become embedded in these enterprise cultures.

The maturity level of an EA practice makes a big difference to the parts of TOGAF that are relevant, and that need to be customised. Many nations or states have already produced reference models and architecture frameworks. Holistic e-governance programmes are being pioneered in countries such as Australia, Singapore, Denmark and Norway, and architecture frameworks include the Government Enterprise Architecture for New Zealand (GEA-NZ) Framework3 and the Federal Enterprise Architecture in the USA4.

Figure 1 gives an indication of the parts of the TOGAF documentation that are relevant at each level of maturity. Remember there are no hard and fast rules here – this is a heuristic based on my experience of how organizations use TOGAF:

FIGURE 1 - Use of TOGAF at different levels of maturity

5 - Measured

3 - Defined

1 - Initial

4 - Managed

2 - Under Development

0 - None PART I - Introduction

PART II - ADMPART VII - Architecture Capability Framework

PART IV - Architecture Content FrameworkPART III - ADM Guidelines and Techniques

PART V - Enterprise Continuum and ToolsPART VI - Reference Models

PART IV - Architecture Content FrameworkPART III - ADM Guidelines and TechniquesPART II - ADMPART VII - Architecture Capability Framework

Non-TOGAF EA

Concepts,

Guidelines,

Techniques,

Frameworks,

Reference Models,

Etc...

1 | https://www.linkedin.com/pulse/catalysing-one-nation-government-indea-saha-chief-architect 2 | https://publicadministration.un.org/egovkb/en-us/reports/un-e-government-survey-2016 3 | https://www.ict.govt.nz/guidance-and-resources/architecture/government-enterprise-architecture-for-new-zealand-framework 4 | https://en.wikipedia.org/wiki/Federal_enterprise_architecture

© 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: marketing@goodelearning.com. 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

Figure 1 also shows that TOGAF needs to be supplemented by additional material that comes from non-TOGAF sources. Although TOGAF is well established as a de facto “standard” EA approach, it should be a baseline or start point. Enterprise Architecture covers a lot more than that which is described in TOGAF. Becoming competent as an enterprise architect takes time and effort, and can only be achieved through practice, experience, and learning from others. This point is illustrated in Figure 2 – Going beyond TOGAF.

In effect, tailoring TOGAF is a process of adapting its documentation to extend beyond Levels 1 and 2 in the TOGAF certification program. The TOGAF exams test knowledge of the terminology and basic concepts (level 1) and the ability to analyse and apply knowledge of TOGAF in pre-defined scenarios (level 2). The next step is becoming a competent enterprise architect, and this requires the ability to tailor TOGAF so that it works in a specific situation or context. Necessarily this means going beyond TOGAF by reaching out into the wider world of enterprise architecture. It is through the experience and practice of applying EA in many different contexts that an architect moves beyond TOGAF to become an EA expert.

In Part 2 of this article I’ll look at what else integrated government programs have in common, and how does it change their use of TOGAF.

LEVEL 4 - Expert

LEVEL 3 - Competence

LEVEL 2 - Certified

LEVEL 1 - Foundation

Knowledge of the terminology & basic concepts of TOGAF

How to be an Enterprise Architect using TOGAF

Ability to analyze & apply knowledge of TOGAF

How to be an Enterprise Architect

TOGAF