Enterprise Transformation Governance - A Pragmatic Approach Using Transformation Debt™ by Pragmatic EA Ltd

1 02 v2

A Pragmatic Approach Using Transformation Debt™ $30,000,000

$20,000,000

$10,000,000

$20,000,000

$30,000,000

Transformation Costs (ED Hidden) Enterprise Debt (ED Hidden) Transformation Costs Saved (Excluding ED)

Transformation Costs (ED Managed) Enterprise Debt (ED Managed) Transformation Costs Saved (Including ED)

Cumalative Amount of. Transformation Costs, Enterprise Debt and Savings

$40,000,000

Time

Kevin Lee Smith The Pragmatic Thinker

Part of the Pragmatic Family

Enterprise Transformation Governance A Pragmatic Approach Using Transformation Debtâ&#x201E;˘

v2021 Kevin Lee Smith

First published: May 2017 Last updated: January 2021

ISBN 978-1-908424-47-1 (hardback) ISBN 978-1-908424-48-8 (paperback) ISBN 978-1-908424-49-5 (ebook) Published by:

Pragmatic365 Ltd 25 Buttermere Great Notley, Essex CM77 7UY England

The right of Kevin Lee Smith as author of this work has been asserted in accordance with the Copyright Designs and Patents Act 1988.

Currently Available Reference Books

The Pragmatic Family of Frameworks A Pragmatic Introduction

Enterprise Fundamentals

ISBN 978-1-90842442-6 978-1-90842442-6

A Pragmatic Approach Using PEFF

Enterprise Transformation A Pragmatic Approach using POET

Enterprise Architecture A Pragmatic Approach using PEAF

Currently Available Focus Books PEAF 4 TOGAF

978-1-90842407-5

PEFF

978-1-90842410-5

POET

ISBN

Pre-requisites

978-1-90842425-9

Kick-start Your TOGAF Adoption. Pragmatically

Transformation Governance

A Pragmatic Approach using Transformation Debt™

Enterprise Architecture Tools

A Pragmatic Approach to EA Tool Selection and Adoption

978-1-90842448-8 978-1-90842454-9

What is EA

978-1-90842457-0

A Pragmatic Explanation

Transformation Culture

978-1-90842459-4

The Inconvenient Pragmatic Truth

Transformation Maturity Assessment A Pragmatic Approach using the PTMC

Connecting the DOTS™ The Death of “The Business” & “IT”

Coming Soon

Enterprise Direction

A Pragmatic Approach using POED

Enterprise Operation

A Pragmatic Approach using POEO

Enterprise Support

A Pragmatic Approach using POES

Enterprise Engineering A Pragmatic Approach using PEEF

Pre-requisites

978-1-90842463-1 978-1-90842468-6

ISBN

Pre-requisites

978-1-90842416-7

PEFF

978-1-90842419-8

PEFF

978-1-90842422-8

PEFF

978-1-90842413-6

POET

This work was inspired by all those who seek to make the world a better place, rather than those who seek to own it.

“We cannot solve our problems, with the same thinking we used when we created them.” Albert Einstein

“Sometimes it is the people who no one imagines anything of, who do the things that no one can imagine.” Alan Turing

“Computers are useless. They can only give you answers” Pablo Picasso.

“You cannot ‘cost justify’ Architecture” J. A. Zachman

“We have seen the enemy, and the enemy is us (management).” W. E. Deming

“If I have seen further, it is by standing on the shoulders of giants.” Isaac Newton

Acknowledgements

The author would like to acknowledge the extensive help and advice provided by Murphy to get this book to market, particularly for the constant companionship and irritating interruptions (which provided much needed relief although I didnâ&#x20AC;&#x2122;t know it at the time) and a chance for mutual tummy tickles. I would also like to thank my wife, Virginia, for her moral support and the constant supply of Marmite on toast. Please note that, to preserve commercial and personal confidentiality, any stories and examples in this book will usually have been adapted, combined and in part fictionalised from experiences in a variety of contexts, and do not and are not intended to represent any specific individual or Enterprise. Registered trademarks such as PEAF, Zachman, TOGAF, ITIL, COBIT etc are acknowledged as the intellectual property of the respective owners.

Contents

Foreword ................................................. 1 Introduction............................................. 5 Companies ................................................................................................... 7

Overview ............................................................................................................................................... 7 Pragmatic EC....................................................................................................................................... 10 Licensing............................................................................................................................................... 13

Training ...................................................................................................... 16 Certification Courses ....................................................................................................................... 16 Focused Workshops ......................................................................................................................... 21 Options ................................................................................................................................................ 31

Pragmatic Publishing Platform ................................................................. 33 Overview ............................................................................................................................................. 33 Design ................................................................................................................................................... 36

Language ................................................ 41 Basics .......................................................................................................... 43 I Didnâ&#x20AC;&#x2122;t Mean What You Heard! ................................................................................................... 43 What is a System? .............................................................................................................................. 46 What is an Enterprise? ..................................................................................................................... 49 What is Transformation? ................................................................................................................. 52 What is a Framework ....................................................................................................................... 54 Theory or Practice ............................................................................................................................ 57 Colours ................................................................................................................................................ 60

Ontologies ............................................. 63 Structural ................................................................................................... 65 MAGIC ................................................................................................................................................. 65

Relationships......................................................................................................................................................................... 67

Transformational ....................................................................................... 69 MAGMA ............................................................................................................................................... 69

Relationships......................................................................................................................................................................... 71

Enterprise ................................................................................................... 73 DOTS ................................................................................................................................................... 73

Relationships......................................................................................................................................................................... 76

Methods ................................................. 79

Phases ........................................................................................................ 81

Basics..................................................................................................................................................... 84 Resource Utilisation .......................................................................................................................... 87 Pattern .................................................................................................................................................. 90 Models .................................................................................................................................................. 93

Disciplines .................................................................................................. 95 Governance & Lobbying Discipline................................................................................................ 95 Governance & Lobbying ................................................................................................................... 98

Transformation Synchronisation..................................................................................................................................... 98 Technical Debt .................................................................................................................................................................. 101 Technical Debt vs Transformation Debt™ ............................................................................................................. 103 Transformation Debt™ ................................................................................................................................................. 106 The Perfect World ........................................................................................................................................................... 106 Transformation Debt™ ................................................................................................................................................. 108 Enterprise Debt ................................................................................................................................................................ 108

Phases ...................................................................................................... 117 Roadmapping .................................................................................................................................... 117

Process ................................................................................................................................................................................. 117

Governance & Lobbying.......................................................................... 122

Process .............................................................................................................................................. 124 Strategic vs Tactical ........................................................................................................................ 126 Transformation Debt™................................................................................................................. 129

Ratio ..................................................................................................................................................................................... 133

Artefacts............................................... 137 Overview .................................................................................................. 139 Levels ................................................................................................................................................. 139

Basics ................................................................................................................................................................................... 141

Ontology .................................................................................................. 144 Detail.................................................................................................................................................. 144

Structural & Transformational .................................................................................................................................... 144

Meta-models ............................................................................................ 146 Transformational ............................................................................................................................. 146

Principles ............................................................................................................................................................................. 146 Debt Agreement ............................................................................................................................................................... 149

Culture ................................................. 155

Guidance .............................................. 159 Principles.................................................................................................. 161 Overview .......................................................................................................................................... 161 Types.................................................................................................................................................. 163 Universal Principles ........................................................................................................................ 164

WHAT We Want to Achieve........................................................................................................................................ 167

Method Principles ............................................................................................................................ 167 Artefact Principles ........................................................................................................................... 170 Items (Technology) Principles....................................................................................................... 173 Culture Principles ............................................................................................................................ 177

HOW We Will Achieve It .............................................................................................................................................. 179

Method Principles ............................................................................................................................ 179 Artefact Principles ........................................................................................................................... 187 Items (Technology) Principles....................................................................................................... 190 Cultural Principles ........................................................................................................................... 191

Appendix .............................................. 203 Background .............................................................................................. 205 Why Were They Created?............................................................................................................ 205 When Were They Created? ......................................................................................................... 205 Where Did They Come From? .................................................................................................... 205 How Were They Created?............................................................................................................ 208 What Was Used to Create Them? ............................................................................................. 209 The Author........................................................................................................................................ 211

Keypoints .................................................................................................. 215 Sources & Resources ............................................................................... 233

Foreword - 1

FOREWORD

OO F

2 - Foreword

Why Should I Read This Book? Many Enterprises already have some kind of governance with respect to Enterprise Transformation. Sadly, many of the Methods (and Artefacts) employed are deeply flawed. Governance tends to be either a tick in the box exercise or a policing exercise. Having witnessed the failure of many Transformation/change initiatives over 35 years, I have created a new way of effecting Governance, with addition of the crucial Lobbying component that is missing in most Enterprises. The changes required to utilise Enterprise Debt™ are small but the effects can be truly game changing. If the Management decides to control (manage) Transformation Debt™, then this book sets out all that is required to do so. Pragmatically. Enterprises (Public Companies, Private Companies, Government Agencies) spend Billions of Dollars year on year Transforming and changing themselves. With widely accepted figures of 70% of all projects fail (McKinsey, September 2013) the amount of money (and more importantly time) that is lost cannot continue, especially in a world that is changing faster and faster while demanding that all this Transformation must be done with less resource. Identifying and managing Transformation Debt™ (that is created when Transformation work deviates from accepted Roadmaps and Principles) is the key to keeping your Transformation projects aligned with your Strategy and identifying when any deviations occur at the point when that deviation occurs so that sound business decisions can me made to either accept the deviation with a plan of how to deal with the resulting issues and risks, or to act to stop the deviation. Who Should Read This Book? Anyone who wants to stop wasting time and money and reduce the number of project failures. E.g. CIOs, Head of PMO, Head of Business Analysis, Head of S&A, Head of Solution Delivery, Enterprise Architects, Solution Architects, Business Analysts, Project Managers, Developers, Testers, Configuration Managers, Change Managers, etc, etc. Why Should I attend a Workshop? Pragmatic Approach to Enterprise Transformation Governance. Run over 1 day and using this book, the first part of the workshop presents the concepts required to understand Transformation Debt™ and provides a detailed method for defining, measuring and managing it. The remainder of the day is a hands-on workshop where you will think about the principles that are applicable to your Enterprise, practise defining the Transformation Debt™ when those principles are violated, and making decisions to accept the debt created or provide the resources required.

Transformation Debt™ is a fact. Your Transformation efforts are creating it every day.

Either you will control it. Or it will control you.

Foreword - 3

PR The Pragmatic Family of Frameworks (PF2) is defined by its Mission Statement: â&#x20AC;&#x153;To provide Enterprises with Pragmatic frameworks to enable them to increase their maturity in how they fulfil their Missionâ&#x20AC;? This introduction to the PF2 sets out the companies involved, the Licensing terms and what Training there is available. It also set out what frameworks are part of PF2, how they relate to each other, and how they relate to other frameworks,

4 - Foreword

KEYPOINT:

PF2 introduces the Companies and Frameworks that are part of the Pragmatic Family.

ADOPTION:

Management: Instigate a project to ensure everyone related to

OO Transformation is trained in

Pragmaticâ&#x20AC;&#x2122;s Family of Frameworks.

Questions to Ponder

â&#x2122;Ś What Frameworks does your Enterprise Use?

PR INTRO DUCT IO N

Introduction

Introduction - 5

OO F

Introduction

6 - Introduction

KEYPOINT:

The Introduction section of PF2

introduces the companies that are part of the Pragmatic Family.

Questions to Ponder

♦ Do you think fundamental terminology is useful to your Enterprise? ♦ What fundamental terminology does your Enterprise use? ♦ If none, what fundamental terminology do you think would be appropriate?

OO F

PR F

Pragmatic 365 is a non-profit research company (hereinafter referred to as Pragmatic) dedicated to developing Best Practice in relation to the structure and transformation of Enterprises. All profits are poured back into the continuous evolution and creation of best practice. This best practice, contributes to the existing best practice in the marketplace, such as PRINCE2, MSP, TOGAF, etc. Pragmatic is tracking over 900 frameworks currently in the marketplace. Pragmatic EC is a consulting company which uses any appropriate Best Practice (whether developed by Pragmatic or not) to help Enterprises mature any or all parts of their Transformation Capability (from Strategy to Deployment). This is done by consulting, training, mentoring and publishing. Pragmatic EC is unique, because itâ&#x20AC;&#x2122;s domain of excellence is, HOW Enterprises effect Transformation not the doing Transformation. That is, our mission is to help Enterprises mature their Transformation capability, not their Operations capability. This contrasts with almost all other consultancies, which concentrate on improving the Operations part of Enterprises, and as such have people who are experts in various business verticals such as Financial, Pharma, Energy, Health, etc. Pragmatic EC can work with Enterprises in any business vertical, since the fundamentals of an Enterprises Transformation capability, is not dependant upon the type of Business they are in. The way that HR or Finance is carried out, is fundamentally the same in all Enterprises. So, the way Transformation is carried out (or rather should be carried out) is the same in all Enterprises. The output of HR, Finance and Transformation may be directed towards a specific business vertical, but the fundamentals of HR, Finance and Transformation are the same for all. Our centre of excellence is thereforeâ&#x20AC;Ś The Transformation of Transformation.

Introduction

Introduction - 7 Companies Over view

Introduction

8 - Introduction

KEYPOINT:

Pragmatic 365 is a non-profit

research company. Pragmatic EC is a consulting company.

ADOPTION:

Management: Engage Pragmatic EC to assess and help you to mature your

Enterprise's Transformation capability.

Questions to Ponder

â&#x2122;Ś What Companies do you know of, that create best practice relating to Enterprise Transformation?

â&#x2122;Ś What Consultancies do you know of, that are focussed on the Transformation of Transformation, rather than the Transformation of Operations?

Introduction

Introduction - 9

Introduction

10 - Introduction Pr agmatic EC

PR Most consultancies won't tell you what Pragmatic will tell you. Most consultancy’s revenue streams, are inversely proportional to how mature their client’s Transformation Capability is. Most consultancies are therefore motivated, NOT to mature an Enterprise’s Transformation Capability. The more immature an Enterprise’s Transformation Capability is, the more money the consultancy is likely to make, in fixing all the problems that will arise. Have you ever wondered why the "70% of all project fail" statistic hasn't changed for 40 years? Now you know! Because most Enterprises primary function and expertise is NOT in relation to Transformation, they tend to live in the Red area depicted on the graph. Their Transformation capabilities are barely mature enough to effect the transformation they require, and the result is missed deadlines, blown budgets, unfulfilled customer expectations, and as a result, large consultancy bills. The green area illustrates a “perfect world” where the Enterprise is supremely mature in its Transformation capability. There is little reason to try to attain such levels of maturity as the law of diminishing returns applies. The yellow area indicates the sweet spot, where the level of maturity is both appropriate and attainable.

Pragmatic is different from almost all other consultancies. We concentrate on enabling Enterprises to move from the Red area to the Yellow area. This is achieved by:

1) Utilising POET and the PTMC to orchestrate Best Practice… 2) To move an Enterprise's Transformation capability from the red to the yellow… 3) Which is accomplished by increasing the maturity of an Enterprises Transformation capability… 4) Which results in a large decrease in the time and money spent on Consultancies.

We believe that anything that can be done to reduce an Enterprise’s reliance on external consultancies (and their associated costs and risks) is a good thing. Pragmatic’s Mission is…

“To provide Enterprises with Pragmatic frameworks to enable them to increase their maturity in HOW they effect Transformation/Change”

Pragmatic’s Vision is…

“The Transformation of Transformation. ”

Introduction

Introduction - 11

OO F

Introduction

12 - Introduction

KEYPOINT:

Most consultancies only want to sell you fish.

Pragmatic will teach you how to fish.

ADOPTION:

Management: Engage Pragmatic EC to help you reign in the budget spent on

OO consultancies and therefore Transformation.

Questions to Ponder

â&#x2122;Ś Which consultancies do you know of, which help you improve HOW you do Transformation vs those that just want to help you DO Transformation?

â&#x2122;Ś How much could you reduce your annual Transformation budget by, if you matured HOW you do Transformation?

PR Non-Commercial (Internal) If you wish to use any of Pragmatic's Ontologies, Frameworks or materials (in whole or in part) internally, that is, to improve the Transformation Capability of your Enterprise, then your Enterprise, and the people that use them, only require a Non-Commercial License. The Pragmatic Non-Commercial license is issued FREE and is automatically renewed for FREE on an annual basis. The license is issued with the following terms:

♦ Any use must be attributable to Pragmatic 365. ♦ Details of the license issued will be posted on the Pragmatic 365 website. ♦ Pragmatic’s Ontologies, Frameworks or materials cannot be used for profit externally. ♦ The Licensee is entitled to use the Licensee Logo on promotional materials. ♦ When used on a website the logo must link back to www.Pragmatic365.org ♦ Licensees agree to be contacted by Pragmatic 365 periodically with updates. Applications for a license can be made at http://www.Pragmatic365.org/licensing-noncommercial.asp

Introduction

Introduction - 13 Licens ing

Introduction

14 - Introduction

Commercial (External) If you wish to use any of Pragmatic’s Ontologies, Frameworks or materials (in whole or in part) externally, that is, to improve the Transformation Capability of your clients Enterprises (not your own) (e.g. Consultancies, Training Providers and Tool Vendors), then your Enterprise, and the people that use them, must possess a Commercial License. NOTE: Contractors who operate their own one-man-band companies and provide services through recruitment agencies to End-User Organisations and Government Bodies are not considered to be consultancies and therefore only require a NonCommercial License. If you wish to evaluate any of Pragmatic’s Ontologies, Frameworks or materials internally for commercial use, you can do so under a free Non-Commercial License. If you wish to evaluate any of Pragmatic’s Ontologies, Frameworks or materials for external commercial use (by using it with an external client) this is possible by contacting Pragmatic first and obtaining written permission to do so. The license is issued with the following terms:

♦ The Licensee is entitled to use the Licensee Logo on their websites and other promotional materials.

♦ When used on a website the logo must link back to www.Pragmatic365.org ♦ Licensees agree to be contacted by Pragmatic 365 periodically with updates. ♦ It is expressly forbidden to pass on any Pragmatic Commercial Licensing Fees to clients of the commercial Enterprise, either directly or indirectly. ♦ The Standard Commercial License specifically prohibits the production of derivative frameworks, however, if you wish to create derivative frameworks this is possible by contacting Pragmatic 365 and obtaining explicit written consent. To apply for a license, please see http://www.Pragmatic365.org/licensing-commercial.asp

KEYPOINT:

Use Pragmatic Frameworks (for free) to improve your Enterprise.

ADOPTION:

Management: Apply for a Pragmatic Commercial or Non-Commercial license depending on your

OO circumstances.

Questions to Ponder

â&#x2122;Ś Which License is best for you?

Introduction

Introduction - 15

Introduction

16 - Introduction Tr aining Cer tification Cour s es

PR There are three levels which build toward PEAF Certified status. PEAF Fundamentals training is a pre-requisite for PEAF Foundation training is a pre-requisite for PEAF Certified training, because PEAF inherits and builds on the Pragmatic Operating model for Enterprise Transformation defined by POET which in turn inherits and builds on the Pragmatic Enterprise Fundamentals Framework. These courses educate individuals and Enterprises in a vendor and technology neutral Pragmatic approach to improving their Transformation capability in general and the Enterprise Architecture part of that domain, in particular. You can choose from Self-Study or Instructor led formats.

â&#x2122;Ś Self Study Training is FREE and is split into three modules. Each module

corresponds to the content taught in the classroom. You can stop and start whenever you like. To move on to the next Module, you must pass all preceding exams. How long you take to study and how often you take the exams is completely up to you. You only pay for certification exams if you want to take them. â&#x2122;Ś Instructor led Training and Certification is fee based, and run by a Pragmatic 365 Certified Trainer. Each day consists of 6 hours of presentation and discussions, finishing with a 1 hour Exam.

In addition, Pragmatic also offers various 1 day workshops targeted at specific subject areas.

Certification Courses

♦ PEAF Fundamentals (1 day) sets out the basic language and ontologies used

throughout all Pragmatic's Frameworks. ♦ PEAF Foundation (1 day) sets out an Operating Model for the whole of the transformation domain (from Strategy to Deployment) and the common patterns of methods and artefacts that allow an organisation to tactically improve parts of it while preserving the effectiveness and efficiency of the whole. It sets the context for Enterprise Architecture in terms of where it fits in, and where it doesn’t. ♦ PEAF Certified (1 days) concentrates on the specifics of the EA domain and sets out the fundamental pieces to be put in place to be successful.

Certification Exams • Exams are marked dynamically in real-time, and so if you get an answer wrong or partially wrong, you will receive feedback for example “Correct but you need to give a little more detail”. • The pass mark for all exams is 100%. The reason for this is that we want to make sure that people understand 100% of the things an exam is asking (which is only a small proportion of the entire content). • Most people complete each exam in 45-60 minutes, and although there is no hard time limit as such, we will close each exam after 2 hours. • If you fail an exam, you are welcome to re-sit the exam (maximum of 3 times) at a later time for no additional cost Target Audience The course is suitable for anyone who is interested in maturing how Transformation and change is effected within an Enterprise and how Enterprise Architecture fits in and helps with that. Prior Knowledge No prior knowledge of Enterprise Architecture is required, although it is useful if the attendees have worked as part of the Transformation capability of an Enterprise.

Introduction

Introduction - 17

Introduction

18 - Introduction

Relevant Industries. Learning the fundamental discipline of Enterprise Architecture (and the wider Transformation domain) and how to mature it in an Enterprise is not dependent upon any business industry knowledge. Previous Customers Experian, Hasbro, Freshfields Bruckhaus Deringer, California Franchise Tax Board, California Department of Health Care Services, Aspen Re, Dunn & Bradstreet, California State Board of Equalization. Private/On Site Courses Can be run and tailored to the challenges of your Enterprise. Certification Body The certificating body is Pragmatic 365 Ltd. A Non-Profit. Previous comments We have a 100% positive feedback from the course. Some comments below but all comments (unedited and unabridged) can be read at www.pragmatic365.org/credibilitycomments-training.asp “Excellent, thought provoking and well laid out” - Global Automation Manager, UK

“Energizing and invigorating -- helps put the passion back in EA efforts” - VP Marketing & Business Development, USA “It was fantastic course - very insigthful and valuable. Thank you.” - Architect, UK “A refreshing approach to EA, focused on *helping* the business develop an approach and strategy, rather than telling them what to do. The course was very logical and easy to follow.” - Executive Director, USA

Do people recommend PEAF? 92% of people would recommend PEAF to others. Some comments are show below but all comments (unedited and unabridged) can be read at www.pragmatic365.org/credibilitycomments-survey.asp “I would recommend PEAF because PEAF has a down to earth holistic enterprise approach that makes EA goals and approach understandable by stakeholders, management and practitioners” - EA, Independent EA, Greece

“I would recommend PEAF because It is a great straight forward place to start looking into EA. The concept are straightforward and both easy to apply and understand.” - ICT Architect, Australia

“I would recommend PEAF because of it's logical and Pragmatic approach to EA. I find it less academic than some of the other frameworks.” - Enterprise Solution Architect, South Africa

“I would recommend PEAF because a) Provides a good roadmap for transformation b) Vendor and technology neutral c) Simplifies the EA artefacts d) Most comprehensive framework” - Consultant, India

Introduction

Introduction - 19

Introduction

20 - Introduction

KEYPOINT:

PEAF Certified training, provides

everything to enable you to adopt PEAF.

ADOPTION:

Management: Engage Pragmatic EC to deliver PEAF Certified

Transformation Best Practice training. Questions to Ponder

♦ ♦ ♦ ♦ ♦

Have you read any of these books? If so, what did you like? What did you not like? Have you been on any of these courses? If so, what did you like? What did you not like? Which course would interest you the most?

PR Various workshops are available based on specially selected content from the base PEFF/POET/PEAF material, which focuses on particular areas of concern. You can choose from Self-Study or Instructor led formats.

â&#x2122;Ś Self Study Training is FREE although obviously does not provide people with the workshop type of environment that allows for specific issues to be discussed. However, Self Studying this content does work towards your PEAF certification if you decide to go that way in the future. â&#x2122;Ś Instructor Workshops are fee based, and run by a Pragmatic 365 Certified Consultant. As well as covering the content, there is also time for discussions about applying the content to your specific context.

Introduction

Introduction - 21 Focus ed Wor ks hops

Introduction

22 - Introduction

PEAF 4 TOGAF Why Should I Read This Book? TOGAF® is a well known and "popular" Framework… "CERTIFICATION PASSES 100,000 MILESTONE" - blog.opengroup.org/2020/06/23/togaf-9-certification-passes-100000-milestone

But while there are many thousands of people certified in it, the number of people and Enterprises that actually use it, is much much lower. A lot of that has to do with the "badge appeal" in that it is something that people like to see on a CV, but a lot of it also has to do with the difficulty in adopting it. While TOGAF's strength lies in its detail, so does its weakness. PEAF strengths lies in its Pragmatism. Who Should Read This Book? Anyone who has taken TOGAF training and wants to use PEAF to Pragmatically adopt it, from CxO’s and Directors to Database Support technicians. From Project Managers to Business Analysts. From Management Consultants to Programmers, and any one of a thousand other job titles that are (in whole or in part) concerned with the Transformation of Enterprises. Why Should I attend a Workshop? Run over 1 day and using this book, this Workshop introduces you to the parts of PEAF that can most pragmatically aid your adoption of TOGAF. Each part is mapped to the TOGAF sections and ADM allowing attendees to easily move between PEAF and TOGAF and vice versa.

If you have been on a TOGAF® workshop and are now wondering what to do, This workshop can help you.

This Workshop will provide you with the context and approach to give you that best chance of success.

Enterprise Transformation Assessment Why Should I Read This Book? Enterprises (Public Companies, Private Companies, Government Agencies) spend a lot of time and money on Transformation initiatives, however, most spend very little (if any) time and money on the MAGIC used. This lack of Transformation focus contributes to the widely accepted figures that 70% of all projects fail. In the 21st Century, it is no longer enough just to be able to change. What matters now is how effective and efficient an Enterprise is at planning and executing that change. How an Enterprise effects Transformation has become a Strategic Strength where massive business opportunities can be gained, or a Strategic Weakness where massive business problems will result. The Pragmatic Transformation Maturity Canvas (PTMC) Workshop is designed to enable Enterprises to effectively and efficiently perform a very Pragmatic maturity assessment of their Enterprise Transformation Capability. Who Should Read This Book? Anyone and everyone that is involved (in whole or in part) in the Transformation of Enterprises, from CxOâ&#x20AC;&#x2122;s and Directors to Database Support technicians. From Project Managers to Business Analysts. From Management Consultants to Programmers, and any one of a thousand other job titles that are (in whole or in part) concerned with the Transformation of Enterprises. Why Should I attend a Workshop? Run over 1 day and using this book, the first part of the workshop presents the concepts required to understand the PTMC and why considering the maturity of your Enterprise Transformation capability is strategically important to its continued survival. The remainder of the day is a hands-on workshop attendees use the PTMC to begin to consider and then expose the maturity of their Enterprise Transformation capability, and to develop overall findings and recommendations for its maturation.

Your Enterprises Transformation capability is strategically important to its survival.

This Workshop will provide you with an approach to assess it, and give you the best chance of maturing it in a Pragmatic way.

Introduction

Introduction - 23

Introduction

24 - Introduction

The Death of the Business and IT Why Should I Read This Book? Most Enterprises organise themselves around the tried and tested “Business” and “IT” way of thinking, and their departments and CxOs. This is understandable and has served us well over the years. However, this paradigm is no longer appropriate. Who Should Read This Book? Anyone and everyone that is involved (in whole or in part) in the Transformation of Enterprises, from CxO’s and Directors to Database Support technicians. From Project Managers to Business Analysts. From Management Consultants to Programmers, and any one of a thousand other job titles that are (in whole or in part) concerned with the Transformation of Enterprises. Why Should I attend a Workshop? In the 21st century, the “IT” of an Enterprise is so inextricably linked to “The Business” of an Enterprise, it is impossible to decide where “The Business” stops and “IT” begins. In fact for many Enterprises today, “IT” is the business to a large extent. So, does this mean handing over the management and direction of the Enterprise to “IT”? No. that would be ludicrous, but so is thinking in terms of “The Business” and “IT”. So what do we do? How can we square this circle? How can we think and organise enterprises in the 21st Century? The answer is to think in terms of Connecting the DOTS™ Run over 1 day and using this book, this workshop presents and defines DOTS. It discusses why thinking in terms of “The Business” and “IT” is no longer appropriate, and why adopting DOTS can ensure an Enterprise concentrates on, and be driven by, the core strategic capabilities of any Enterprise.

If you wish to make sure your Enterprise can excel in the 21st century, it is imperative that it focusses on its key strategic capabilities.

This workshop will provide you with the context and approach to give you that best chance of success.

Enterprise Transformation Governance Why Should I Read This Book? Many Enterprises already have some kind of governance with respect to Enterprise Transformation. Sadly, many of the Methods (and Artefacts) employed are deeply flawed. Governance tends to be either a tick in the box exercise or a policing exercise. Having witnessed the failure of many Transformation/change initiatives over 35 years, I have created a new way of effecting Governance, with addition of the crucial Lobbying component that is missing in most Enterprises. The changes required to utilise Enterprise Debt™ are small but the effects can be truly game changing. If the Management decides to control (manage) Transformation Debt™, then this book sets out all that is required to do so. Pragmatically. Enterprises (Public Companies, Private Companies, Government Agencies) spend Billions of Dollars year on year Transforming and changing themselves. With widely accepted figures of 70% of all projects fail (McKinsey, September 2013) the amount of money (and more importantly time) that is lost cannot continue, especially in a world that is changing faster and faster while demanding that all this Transformation must be done with less resource. Identifying and managing Transformation Debt™ (that is created when Transformation work deviates from accepted Roadmaps and Principles) is the key to keeping your Transformation projects aligned with your Strategy and identifying when any deviations occur at the point when that deviation occurs so that sound business decisions can me made to either accept the deviation with a plan of how to deal with the resulting issues and risks, or to act to stop the deviation. Who Should Read This Book? Anyone who wants to stop wasting time and money and reduce the number of project failures. E.g. CIOs, Head of PMO, Head of Business Analysis, Head of S&A, Head of Solution Delivery, Enterprise Architects, Solution Architects, Business Analysts, Project Managers, Developers, Testers, Configuration Managers, Change Managers, etc, etc. Why Should I attend a Workshop? Pragmatic Approach to Enterprise Transformation Governance. Run over 1 day and using this book, the first part of the workshop presents the concepts required to understand Transformation Debt™ and provides a detailed method for defining, measuring and managing it. The remainder of the day is a hands-on workshop where you will think about the principles that are applicable to your Enterprise, practise defining the Transformation Debt™ when those principles are violated, and making decisions to accept the debt created or provide the resources required.

Transformation Debt™ is a fact. Your Transformation efforts are creating it every day.

Either you will control it.

Or it will control you.

Introduction

Introduction - 25

Introduction

26 - Introduction

Enterprise Transformation Culture Why Should I Read This Book? Enterprises (Public Companies, Private Companies, Government Agencies) spend a lot of money on Transformation initiatives, and in trying to mature how they plan and execute those initiatives. A lot of time and money is spent on processes and IT tools to help an Enterprise plan and run projects better. However, after all this time and money is spent, processes are changed, new tools are bought and installed, still the overall numbers are that 70% of all projects fail. How can this be? The simple answer is that the culture at large in most Enterprise Transformation capabilities (the unwritten rules and regulations) are perfectly engineered to produce a 70% failure rate. So put away your tools, and start thinking about culture today. Culture trumps Everythingâ&#x201E;˘ is much much more than just a saying. It is a very cold hard fact, which if ignored, literally has the capacity to destroy civilisations. Who Should Read This Book? Anyone and everyone that is involved (in whole or in part) in the Transformation of Enterprises, from CxOâ&#x20AC;&#x2122;s and Directors to Database Support technicians. From Project Managers to Business Analysts. From Management Consultants to Programmers, and any one of a thousand other job titles that are (in whole or in part) concerned with the Transformation of Enterprises. Why Should I attend a Workshop? Run over 1 day and using this book, the workshop exposes the culture that exists in many enterprises. It gets the attendees thinking in terms of culture, different ways to think about it, the role psychology plays, how the two tribes of "the business" and "IT" contrast, and over 40 keypoints to help focus the mind.

Your Enterprise is already spending a lot of money on Transformation initiatives, and so it is imperative that your Enterprise stands the best chance of reducing the 70% failure rate.

This Workshop will provide you with the context and approach to give you that best chance of success.

Enterprise Architecture Tools Why Should I Read This Book? Many Enterprises already have some kind of EA Modelling Tool, that are being actively used for the purpose of Enterprise Architecture, aka creating and maintaining Structural (Capability) and Transformational (Portfolio) Roadmaps. But those Enterprises are in the minority. Many, many more have either no EA Modelling Tool at all, or they have one but have found that it has not lived up to expectations and sits gathering dust on the shelf or being used as glorified reporting tool and generally providing questionable (if any) returns. Having witnessed many failures, this book sets out the Methods, Artefacts and Environment required to effectively choose and operate an EA Modelling Tool. It covers the key things that must be done to effectively and efficiently choose a tool, and then to operate it in a sustainable way. If the Management decides to choose (or replace) and operate an EA modelling tool effectively, then this book sets out all that is required to do so. Pragmatically. Who Should Read This Book? Anyone involved in making sure their investment in an EA Modelling Tool is sound. E.g. CIOs, Head of PMO, Head of Business Analysis, Head of S&A, Head of Solution Delivery, Enterprise Architects, Solution Architects, Business Analysts, Project Managers, Configuration Managers, Change Managers, etc, etc. Why Should I attend a Workshop? Run over 1 day and using this book, the first part of the workshop presents the concepts required to understand an EA Modelling Tool, what it used for, what information must be modelled, and Pragmatic methods for adoption and use. The remainder of the day is a hands-on workshop where you will formulate your own tailored approach for selection, define which requirements are key to you, and develop a shortlist. Enterprises (Public Companies, Private Companies, Government Agencies) spend a lot of time and money on tools. But many of these tools sit on the shelf or are used in only small ways. The most common reasons are that: The tool they selected is not is not appropriate for their Enterprise. The way the tool is being used is not appropriate for their Enterprise.

If you are going to be spending a lot of money on a tool, it is imperative that the project stands the best chance of success.

This Workshop will provide you with the context and approach to give you that best chance of success.

Introduction

Introduction - 27

Introduction

28 - Introduction

What is Enterprise Architecture Why Should I Read This Book? Enterprises (Public Companies, Private Companies, Government Agencies) spend a lot of money on Enterprise Architecture. But the world is so full of myths, half-truths and misinterpretations, they rarely get to understand what it actually is, much less how to use it. EA has the capacity to massively increase the effectiveness, efficiency, agility and sustainability of an Enterprises transformation portfolio. Enterprise Architecture has existed (in many forms) for a long time, and there are many “experts” around to educate others. However, EA is currently at the same point in time, as Chemistry was when Chemists were Alchemists. So perhaps a better term for Enterprise Architecture is Enterprise Alchemy and a better term for Enterprise Architects is Enterprise Alchemists. (It is perhaps serendipitous that the acronym is the same!)) The parallels between what EA claims and what alchemy claimed are intriguing. That may see flippant or a pathetic attempt at humour, however, in admitting that, as a profession, EA is about as mature as alchemy was hundreds of years ago, we have made the most important step of all. The first step. We have stopped being unconsciously incompetent and we are now concisely incompetent. Admitting that EA is as mature as Alchemy is big thing. Many people will not agree (mostly the Alchemists!). Many people have a vested interest in presenting themselves and their companies as “experts” even when their expertise just turns out to be “whatever we think”. The time has come for a change. The time has come for Enterprise Alchemy to grow up and Become Enterprise Architecture. This book presents information to define Enterprise Architecture, and Architects in a Pragmatic fashion. It does not purport to be the end of the road. But it does try to be the beginning. Who Should Read This Book? Anyone and everyone that is involved (in whole or in part) in the Transformation of Enterprises, from CxO’s and Directors to Database Support technicians. From Project Managers to Business Analysts. From Management Consultants to Programmers, and any one of a thousand other job titles that are (in whole or in part) concerned with the Transformation of Enterprises. Why Should I attend a Workshop? Run over 1 day and using this book, the workshop presents what EA is (the noun and the verb), what EA is not (the noun and the verb), how EA fits into the wider Transformation domain, how the popular frameworks such as Zachman, TOGAF, POET, PEAF, COBIT and ITIL fit in, the fundamental differences between Architecture & Engineering, the two types of Enterprise Architect (the role) and over 50 keypoints to help focus the mind.

If you are going to be spending a lot of money on EA, it is imperative that your Enterprise stands the best chance of success.

This Workshop will provide you with the context and approach to give you that best chance of success.

Introduction

Introduction - 29

PR F

Introduction

30 - Introduction

KEYPOINT:

PEAF Focused Workshops, allow you to focus on specific areas.

ADOPTION:

Management: Engage Pragmatic EC to deliver Focussed training.

Questions to Ponder

♦ ♦ ♦ ♦ ♦

Have you read any of these books? If so, what did you like? What did you not like? Have you been on any of these workshops? If so, what did you like? What did you not like? Which course would interest you the most?

PR The progression from Fundamentals through Foundation to Certified is the same for people opting for Self Study or Instructor Led training. In addition, Enterprises that have completed the Instructor Led course are also able to buy (as an option) the Pragmatic Publishing Platform (P3), to allow them to create and modify Frameworks in an efficient and seamless way.

Introduction

Introduction - 31 Options

Introduction

32 - Introduction

KEYPOINT:

Access to the Pragmatic Publishing Platform is granted by graduating from an Instructor led course.

ADOPTION:

EA Project Team: Attend Instructor led training, to gain access to the

OO Publishing Platform and all component files.files.

Questions to Ponder

♦ Which type of course would you choose? ♦ Do you think a better understanding could be gained from an Instructor led course? ♦ What are the benefits of each type of course?

PR The Pragmatic Publishing Platform (P3) is available for purchase separately and exists in two versions:

♦ A Standalone Version – with no content, allowing people to create and maintain any content they wish, that results in the creation of training presentations, associated exams, websites and books. ♦ A Pragmatic Version – which include 100% of the base material in all of Pragmatic frameworks – currently PF2, POET and PEAF, allowing people to rebrand and modify as they wish.

P3 comprises a coherent environment which automates much of the administrative tasks related to the production and maintenance of the base material and the creation of custom material. The platform uses MS PowerPoint as its base, utilising a custom Pragmatic Ribbon to allow users to manage the material.

♦ Documents – Allow the maintenance of the words for each component. ♦ Drawings – Allow the maintenance of the drawings for each component. ♦ Images – Allows the generation of images. Separate .png files are exported in

five different resolutions - one for Books, three for the website (thumbnail, normal and hi-res) and one for the export folder. ♦ Image Testing – Allows supplementary functions for testing image generation. ♦ Generate - Allow the generation of PowerPoint and Word Toolkit documents ♦ Create Shows – Allows the creation of shows using tags or the selection

Introduction

Introduction - 33 Pr agmatic Publis hing Platfor m Over view

Introduction

34 - Introduction ♦ Tags – Allows the manipulation and visualisation of tags which define each ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦

show. Component Files- These files constitute the master files of the Framework or Ontology that all other files are created from. Each component is composed of a Visio file for the graphic and a Word document for the words. Metadata – This information (per component) is held in tags within the Notes of each slide. It comprises Show indicators, Keypoints, Questions, Answers, Adoption Statements and Reader Questions. Toolkit – From these Components, any number of Documents and PowerPoint Presentations can be easily created, based on a selection of the Components. Website - Easily integrate your framework (images and words) with your intranet to promote understanding and adoption. Mobile - The images of your framework are automatically exported to a folder (e.g. Dropbox) that can be synchronised to mobile devices, allowing you to carry the core of your framework with you at all times, to promote understanding and adoption. Books – From the Book documents, physical books can be easily created. Training Courses – Training courses consisting of presentations to be used in classroom training and information loaded into an online course system. In addition an online examination system is loaded with exam questions. Integration – Component Information is synchronised to Google Sheets, which can then in turn, integrate though any integration application to, for example, Facebook, Twitter, LinkedIn etc for publishing of changes or daily messages.

KEYPOINT:

P3 allows Enterprises to easily

produce and maintain their own

Frameworks and publish them to books, their intranet and mobile devices.

ADOPTION:

Management: Adopt the Pragmatic Publishing Platform to streamline your Pragmatic X-Framework adoption.

Questions to Ponder

â&#x2122;Ś What do you currently use to maintain and publish the frameworks your Enterprise uses? â&#x2122;Ś What other uses can you think of for the Pragmatic Publishing Platform?

Introduction

Introduction - 35

Introduction

36 - Introduction Des ign

PR P3 is a component-based knowledge authoring and publishing system. All content is constructed from components. A component is whatever the author wants a component to be, however it is suggested that each component teach people one important concept or thing. More complicated things should be broken down into other components. Each component consists of three distinct pieces of information:

♦ Words – Authored in any document editor such as Microsoft Word, and in any

format such as rtf or html. ♦ Images – Authored in any image editor such as Visio, and in any format such as raster (e.g. png, gif, jpg) or vector (e.g. vsd, wmf) ♦ Properties ♦ Name (as part of a navigation structure) ♦ Keypoint – The key thought or point that the reader should take away from this component. ♦ Adoption – A list of things to do in order to adopt the component. ♦ Exam Questions – One or more exam questions to test the knowledge of someone learning the component. ♦ Exam Answers – For each question, 1 correct answer and any number of wrong answers, to allow a multiple choice examination to be conducted. (The exam subsystem allows for both multiple choice exams and written exams)

In addition, the repository contains two other important parts. Firstly Sets. Sets collect components together for the purposes of publishing and training.

♦ Links – a list of links to components included in the set and the order that is

required. ♦ Properties ♦ Name – The Authors internal quick name of the set ♦ Title – The title to be used when published ♦ Prices – The prices of things published for example print books, Kindle books, training courses. Secondly, Authors Customer. ♦ Details - Information about the authors customers/subscribers, such as name, email address etc. ♦ Access – Information about what content the authors customer has accessed and when. ♦ Exams – Information about what courses and exams the user has subscribed to. All of this information is owned and controlled by the Author and can be exported at any time, in a variety of formats (words documents, image files, sets, etc) such that the Author always owns their content. In addition, to aid adoption of the platform, Authors can import their existing knowledge in a variety of formats with automatic splitting of large documents into components by using some identifying data such as headings or page breaks. ♦ Functionality ♦ Integration ♦ Create, Maintain, Components ♦ Create, Maintain Sets ♦ Publish ♦ Training ♦ Website ♦ Marketing ♦ Exams / Certification

Introduction

Introduction - 37

Introduction

38 - Introduction Customer Segments

♦ Worldwide - Platform akin to YouTube for thinkers. ♦ Best practice ♦ Stories for children/learning ♦ Companies – To document the MAGIC of their business, for onboarding or general change management teaching/rollout. ♦ Universities - For professors to author content for students.

Why would an author want to use P3? People who tick 1 or more of these boxes:

♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦

Have a reasonably large set of information/knowledge Need flexibility to easily evolve/maintain it over time Want to share/publish their content on the internet/intranet Want to publish their content to eBook or Print Want to be able to easily slice and dice their content into focus areas. Want to offer training (offline, online, onsite) to people. Want to offer exams/certification to people. Want to automatically push their content out via twitter, likedin, facebook etc Want to build a following of subscribers who like their content

OO F

P3 can be used to create, maintain, and publish any type of information for any domain of interest:

♦ Best Practice ♦ Management ♦ Enterprise Architecture ♦ Drilling oil wells ♦ Banking ♦ Pharma… ♦ Sales play books ♦ Stories

The content can be structured around any domains you like, although P3 provides 5 fundamental MAGIC domains for grouping best practice information:

♦ ♦ ♦ ♦ ♦

Methods - Methodologies Artefacts - Ontologies Guidance – Principles, policies, Standards… Items - Technologies Culture - Ethics, Values, Roles…

It provides a consistent updated taxonomy of knowledge that can be shared across all outputs and to all of the people (customers) using the content that it creates and manages. Competitors Before P3 was written, I spent some time looking for a component based publishing platform. At that time I discovered AuthorIT https://www.author-it.com/ but after spending some time to review it by actively use it, it became obvious that it could not meet my needs.

Introduction

Introduction - 39

Introduction

40 - Introduction

KEYPOINT:

P3 is a component based authoring system.

ADOPTION:

Management: Adopt the Pragmatic Publishing Platform to streamline your Pragmatic X-Framework

OO adoption.

Questions to Ponder

â&#x2122;Ś What do you currently use to maintain and publish the frameworks your Enterprise uses?

â&#x2122;Ś What other uses can you think of for the Pragmatic Publishing Platform?

Language - 41

Language

PR LAN GUA GE

OO F

42 - Language

KEYPOINT:

PR Language

The Language section of PEFF

introduces fundamental terminology that is used throughout Pragmatic’s Frameworks.

Questions to Ponder

♦ Do you think fundamental language is useful to your Enterprise? ♦ What fundamental language does your Enterprise use? ♦ If none, what fundamental language do you think would be appropriate?

Language - 43 Bas ics I Didn’t Mean What Y ou Hear d!

Language

PR OO

The Pragmatic Family of Frameworks are written in English and you would therefore expect to be able to understand every word. However, although most of us speak English fluently, the same cannot be said about the language we use to talk, about things in relation to Enterprises. Different people use different words to mean different things at different times. This is a massive problem, which makes understanding anything anyone says, at best impossible, and at worst, apparently possible. (It’s worse when apparently possible, because that’s when people think they understand each other, but don’t) People, including me, get attached to the meaning of the words we use, and defend those meanings passionately. This is totally understandable, because the meanings we attach to words, are the absolute basis for our understanding things. Pragmatic has no desire or wish to impose our meaning of words onto you, however, for the purposes of understanding the Pragmatic Family of Frameworks, I would ask you to temporarily put aside your current meanings of words, and try to embrace, accept and understand the meanings of the words used here. The actual words are not so important as the meaning behind them. Many words people use are overloaded with multiple meanings, and when this is not clear (i.e. a lot of the time!) communication can become quite confusing, not to say heated. Sometimes we need to use different language to explain a difficult concept. For example, let’s look at an explanation of the offside rule in football (or soccer to those of you from across the pond – see, there’s that language problem again!) to someone who knows nothing about the rules of football, but knows everything about the rules of buying shoes…

44 - Language

Language

“You're in a shoe shop, second in the queue for the till. Behind the shop assistant on the till is a pair of shoes which you have seen and which you must have. The shopper in front of you has seen them also and is eyeing them with desire. But, both of you have forgotten your wallets. It would (of course) be rude to push in front of the shopper in front of you, if you had no money to pay for the shoes. (The shop assistant remains at the till waiting.) Your friend is trying on another pair of shoes at the back of the shop and sees your dilemma. They prepare to throw their wallet to you. If they do, you can catch the wallet, then walk round the other shopper and buy the shoes! At a pinch your friend could throw the wallet ahead of the other shopper, and "whilst it is in flight" you could nip around the other shopper, catch the wallet, and buy the shoes! BUT, you must always remember that until the wallet has "actually been thrown", it would be just plain wrong for you to move in front of the other shopper and buy the shoes. - Anonymous

So, if English can be confusing to people who speak it natively, imagine the problems in the multinational world we live in, as we can see in this explanation of Cricket (in a world without boundaries - pun intended), …

“You have two sides, one out in the field and one in. Each person that's in the side that's in goes out, and when he's out he comes in and the next person goes in until he's out. When they are all out, the side that's out comes in and the side that's been in goes out and tries to get those coming in, out. Sometimes you get people still in and not out. When a person goes out to go in, the people who are out try to get him out, and when he is out he goes in and the next person in goes out and goes in. There are two people called umpires who stay out all the time and they decide when the people who are in are out. When both sides have been in and all the people have been out, and both sides have been out twice after all the people have been in, including those who are not out, that is the end of the game.” - Anonymous

Language - 45

Be ever vigilant of the hidden

confusion that language can create.

ADOPTION:

EA Project Team: Create a data

dictionary for all the terms used in the Enterprise's Transformation

OO Capability.

Questions to Ponder

♦ Do people in your enterprise speak the same language? ♦ Are you prepared to map the content of The Pragmatic Family of Frameworks to your own internal naming conventions?

♦ If not what changes would you make to The Pragmatic Family of Frameworks?

Language

KEYPOINT:

46 - Language What is a Sys tem?

PR Language

When we use the word “System” we use it to refer to anything. Literally any “Thing”.

♦ It can refer to physical things, like a car, a boat, a molecule, a planet, etc. ♦ It can refer to non-physical things, like processes, thoughts or computer programs. ♦ It can also refer to things which are a mixture of the two, like an Enterprise, or part of an Enterprise.

Whatever the System is, that System always exists within a Context. The Context is not a thing in itself, but instead is formed by other Systems (in part or in whole) that are not considered to be part of that System, but have some connection or relationship to it. For example they influence it, or are influenced by it. This basic concept of a System existing within a context, is also defined in an International Standard, ISO42010. Although its title is “Systems and Software Engineering”, and there are numerous and constant references to, and examples of IT Systems, 95% of it applies equally to the Architecture of Systems in any domain. It’s unfortunate that it is so IT focussed, because it perpetuates the common myth that Enterprise Architecture is only about IT, and the things connected to IT. The overwhelming desire of any system is one of self-preservation, which includes preservation of its structure - which is why many systems (and the people that operate within them) resist change. A key thing to understand about any system is that it WILL be abused, especially any system that people participate in, be it at work, the tax system, the healthcare system, the social care system, etc. People who are accountable for a system (e.g. management) tend to make two invalid and deeply damaging assumptions:

1) Firstly, they assume that the system they have put in place will not be abused. That is not to say that they have not thought about how the system will be abused, and put in place things to stop that abuse, of course they have. The problems come from not accepting that even with all the measures they have put in place, the system will still be abused. 2) Secondly, they think that when new types of abuse are exposed, that the solution to that problem is to put in place more and more detailed checks and balances. What is not realised, is that they are increasing complexity, and as complexity increases, so does the opportunity for abuse. A better approach, would be to look more at the fundamentals and aim to reduce complexity, thereby reducing the opportunity for abuse.

So, if we accept that the number of opportunities to abuse a system that Actually Exists is always larger than the number of opportunities that we Think Exists and have catered for, there will always be a number of Opportunities for Abuse. The only argument is what is the relationship between the number that we Think Exists vs the number that Actually Exists. The function is definitely not linear and more likely polynomial in nature. So, if you want to reduce the opportunities to abuse a system, you need to reduce the complexity of that system. This is illustrated in the table below. As we can see, things break down pretty rapidly. You could argue that a polynomial function is not the correct function to apply, but one thing you have to admit is, the opportunity to abuse a system is always greater than opportunities we think exist. Think Exists

Actually Exists

Opportunities for Abuse

105

5460

5355

5460

14903070

14897610

14903070

1.11051E+14

Language

Language - 47

48 - Language

KEYPOINT:

PR Language

Everything is a System.

ADOPTION:

EA Project Team: Add the definition of “System” to the data dictionary used in the Enterprise's

Transformation Capability.

Questions to Ponder

♦ ♦ ♦ ♦ ♦

What Systems does your Enterprise use and operate that are not IT Systems? Has anyone outside of IT heard of or read ISO42010? If not, who will you introduce ISO42010 to tomorrow? When correcting problems, does your Enterprise add complexity or reduce it? What function would you use to relate the number of opportunities for abusing a system to the number of opportunities we think exists and have catered for? ♦ You are a System. What makes up your context?

Language - 49 What is an Enter pr is e?

Language

PR OO

An Enterprise is a type of System. The word Enterprise is used as a general noun - to refer to things such as public and private companies, government agencies, charities, universities etc. This is not an exhaustive list but illustrates the point. In addition we use the word Enterprise as a general noun in place of many other words people may use to refer to each these “types”. For example, a Private Company may be called a Company, Business, Corporation, Conglomerate, Organisation, SME, Firm, Establishment, Group, Multinational or Venture. We use the word Enterprise to refer to them all. An Enterprise is a system and therefore every Enterprise also has an Enterprise Context. Many people take a different view (citing TOGAF) which is that an Enterprise could be anything, e.g. a department, a smaller part of a company, etc, and from a purists point of view they are correct but only if you use the word Enterprise as synonym for the word System, rather than to describe a specific type of system - an Enterprise. To support that view they refer to TOGAF’s Preliminary Stage which states as one of its objectives is “To identify and scope the elements of the enterprise organizations affected by the business directive and define the constraints and assumptions (particularly in a federated architecture environment)” i.e. to restrict the scope of EA to something that could well be a smaller part of the entire Enterprise and to further restrict that to “the business directive”. This is borne out by the rest of TOGAF which is Project Architecture based rather than Enterprise Architecture based. However, TOGAF (on page 25 - section 3.34) defines and Enterprise as “The highest level (typically) of description of an organization and typically covers all missions and functions. An enterprise will often span multiple organizations.” which appears to tie in with our definition above. This is one of the many conflicts and inconsistencies within TOGAF. It says it is an Enterprise Architecture framework, goes on to define an Enterprise as being typically an organisation (as described by Pragmatic) but

50 - Language

Language

then goes on to state that the first act is to de-scope the entire Enterprise to something smaller - and restrict work to a â&#x20AC;&#x153;business directiveâ&#x20AC;? at which point it is no longer Enterprise Architecture but a sub part of the Enterprise and moves forward from that single transformation project perspective which makes it project level and not Enterprise Level.

OO F

Language - 51

The Word Enterprise does not mean “large” or “large IT” or “senior”. It is a general noun.

ADOPTION:

EA Project Team: Add the definition

of “Enterprise” to the data dictionary

OO used in the Enterprise's

Transformation Capability.

Questions to Ponder

♦ ♦ ♦ ♦

Does your Enterprise use the word Enterprise to refer to many types of things? If not, what other words are used and what are their definitions? Is there a common understanding? If not, what problems does that create?

Language

KEYPOINT:

52 - Language What is Tr ans for mation?

PR Language

It can be easily misinterpreted (and often is) how Pragmatic uses the word Transformation. It is possible for people to believe that the word Transformation (as we use it) is used specifically because it means something different to the word change. Hereâ&#x20AC;&#x2122;s a quote from Patrick on LinkedIn illustrating how many people confuse Pragmatic's use of the word Transformation: â&#x20AC;&#x153;I don't believe that Organisations are under a constant pressure to transform, but they are under pressure to change. I think there is a fundamental difference between change and transformation. Transformation is the re-inventing of an Organisation and effects the majority of the organisation itself. Change is more subjective and specific in nature and delivery. Therefore transformation is NOT a normal event within an organisation and therefore doesn't require a permanent "C" positionâ&#x20AC;? - Patrick (LinkedIn)

Pragmatic makes no such distinction. We use the word Transformation to mean any and all change. A general noun to refer to many other nouns that, at a fundamental level, mean the same thing.

Language - 53

There is no hidden connotation to Pragmatic’s use of the word “Transformation”.

ADOPTION:

EA Project Team: Add the definition of “Transformation” to the data

dictionary used in the Enterprise's Transformation Capability.

Questions to Ponder

♦ Does your Enterprise use the word Transformation to refer to a specific type of change?

♦ If not, what other words are used and what are their definitions? ♦ Is there a common understanding? ♦ If not, what problems does that create?

Language

KEYPOINT:

54 - Language What is a Fr amewor k

PR Language

What is a Framework? This is a common question and one that has almost as many answers (if not more!) as the eternal “What is EA?” question. All Frameworks exist to improve the way something is done (i.e. to increase the effectiveness and efficiency and to reduce the risk of failure). In many respects they are an expression of “Best Practice”. They contain different types of things depending upon the purpose of the framework - its domain. More specifically, Frameworks are composed of information relating to:

♦ Methods (e.g. processes, practices, etc) and/or ♦ Artefacts (e.g. Ontologies, Metamodels, Reference Models, Product Descriptions etc) and/or ♦ Guidance (e.g. Principles, Policies, Standards, etc) and/or ♦ Items (e.g. Tools, Frameworks, etc) and/or ♦ Culture (e.g. People, Culture, Values, Psychology, etc)

There must be at least one thing in at least one of these areas for it to be a framework. A Framework may optionally also contain:

♦ Adoption (e.g. Actions regarding which Steps to take to adopt it, and for each step, what the Measures, Assessment and Motivation for moving to the next step are.)

Some frameworks only contain one of the above (e.g. Zachman is only an Ontology - an Artefact). Some frameworks contain some of the above (e.g. TOGAF has No information on Culture or Adoption.

And some frameworks contain all of the above (e.g. POET and PEAF). Many people take the view that a framework consists only of Artefact information, e.g. metamodels, ontologies, reference models, etc. This tends to be a very engineering, IT and data, myopic view. This view is plainly not true. Frameworks can contain all of the things that MAGIC and MAGMA define. For example, There are legal Frameworks, political Frameworks, cultural Frameworks, analysis Frameworks, architectural Frameworks, management Frameworks, business Frameworks, project management Frameworks, software development Frameworks, governance Frameworks, modelling Frameworks, etc, etc, etc. They may or may not have some information relating to meta-models or meta-meta-models or ontologies etc, but they are all frameworks - even the ones with no meta-model.

Language

Language - 55

56 - Language

KEYPOINT:

PR Language

A Framework is an expression of

Best Practice comprising information in at least one area (Methods,

Artefacts, Guidance, Items, Culture)

and optionally information regarding its Adoption.

OO ADOPTION:

Enterprise Architect: Categorise the content of any Framework you use, in terms of Context + MAGIC + Adoption.

Questions to Ponder

♦ How do you define a framework? ♦ What kinds of things would you put in a Framework? ♦ What Frameworks do you know and what types of things do they contain?

Language - 57 Theor y or Pr actice

Language

PR OO

Pragmatic’s Ontologies and Frameworks can easily be thought of some ivory tower academic tomes which are nice in a perfect world but does not provide any practical advice. People ask me… “Yeah! It’s great but, does it tell me and others exactly what to do, when, how and with what?” Usually closely followed by…

“It’s not detailed enough to be useful.” The answer is no. That is exactly what they were designed not to do. Yes, there is a difference between theory and practice. In practice detail will be exposed and problems will be found that means we cannot follow the theory literally and to the letter, but theory is never meant to be applied literally and so why people complain when it’s not I am not sure. It’s almost like people want theory to be practice, which if it was, it wouldn’t be theory anymore! In the world, there is no lack of things telling people exactly what to do with excruciating detail (look at some other frameworks out there) and while detail is good, detail that is not framed in theory is either foolhardy or just plain dangerous. Balance is the key. We call that a Pragmatic approach. Theory is more about thinking than doing and practice is more about doing than thinking. The intimation that if something is “theory” it is useless and not worth looking at is ludicrous, but people do it all the time and use it as way to dismiss things. Maybe it’s a sign of the times we live in where doing things is the only thing people seem to care about - thinking doesn’t seem to have any value anymore. Which is really strange since thinking is exactly what humans are best at.

58 - Language

Language

The truth is, everything you see around you was built on theory. Theory provides a context for practice to happen within. By exposing the fundamentals of transformation and defining patterns that link all the parts into a holistic whole we give people the context to work within that continuum cooperatively. It’s like driving a car, you don’t teach someone to drive a car by telling them how to turn the steering wheel (left a bit, right a bit, a bit more, too much, go a bit left, a bit more….) you explain and show what the steering wheel and other controls do and how they interrelate, understanding the physics involved and getting them to feel the physics involved (e.g. what happens if you turn the steering wheel fast at high speed as compared to slow speed) and that provides the context.

Language - 59

Theory is just as important as Practice

ADOPTION:

Management: Don’t dismiss theory as not important.

Questions to Ponder

♦ Is someone telling you when to turn the steering wheel and how much? ♦ Does your Enterprise provide you with things that allow you to understand how you fit into the overall Transformation domain?

♦ If not, would your job be more effective, efficient and more rewarding if it did? ♦ Who will you lobby to provide it?

Language

KEYPOINT:

60 - Language Colour s

PR Language

Here we detail Pragmatic's use of colour. Colour is not used to make think look pretty. Pragmatic uses colour to aid peoples understanding as colour is an excellent way for the mind to quickly take in and relate information. Some people like to see colour (information) others see it as extraneous and creating more confusion that clarity. Others like colour but just not like Pragmatic's choice of colour and would change them in certain ways, such as making them more muted, or only using colour to represent the type of thing â&#x20AC;&#x201C; e.g. instead of using the 40 colours shown here, use one colour for each set of colours. Whatever your preference, using P3 (Pragmatic Publishing Platform) allows you to easily change the colours to anything you prefer. In addition, users of the website can elect to see the diagrams in full colour, or one of a set of themed colours such as shades of blue or orange or grey.

Language - 61

Colour =

Information =

Understanding.

ADOPTION:

EA Project Team: Use standardised colours to mean something.

Questions to Ponder

♦ Do you like Pragmatic’s use of colour? ♦ If not, what would you change?

Language

KEYPOINT:

Ontologies - 63

Ontologies

O NTO LO GIE S

OO F

64 - Ontologies

KEYPOINT:

The Ontologies section of PEFF

introduces fundamental ontologies

that are used throughout Pragmatic’s

Ontologies

Frameworks.

Questions to Ponder

♦ Do you think fundamental ontologies are useful to your Enterprise? ♦ What fundamental ontologies does your Enterprise use? ♦ If none, what fundamental ontologies do you think would be appropriate?

Ontologies - 65 Str uctur al MAGIC

Ontologies

PR OO

MAGIC is a high level Ontology (like People, Process and Technology, or POLDAT - Process, Organisation, Location, Data Applications, Technology), but without all the problems they create!

♦ Methods -Information about what is being done and how it is being done. E.g. Functions, Processes, Practices, Activities, Phases, Disciplines.

♦ Artefacts - Information about the things that are being consumed and produced by the methods. E.g. Products, Services, Materials, Information.

♦ Guidance - Information about things that guide the execution of the Methods. E.g. Principles, Policies, Standards.

♦ Items - Information about the things that are used to execute the Methods and

work with the Artefacts. These Items include Information technology (which is a large part) but also, crucially, includes other Items such as buildings, tables, chairs, lorries, cows, cranes, etc. It may be useful to categorise Items by considering which technologies they utilise: Chemical, biological, mechanical, electrical, etc. ♦ Culture - Information about the People that are being used to perform the Methods. E.g. People, Values, Ethics, Trust, Psychology.

NOTE: It can be useful to read Items as ITems, to remind you that Items is where IT sits but also refers to other technologies – physical, electrical, mechanical, chemical, etc.

66 - Ontologies

KEYPOINT:

Methods, Artefacts, Guidance, Items and Culture (MAGIC) is a Structural Ontology

Ontologies

ADOPTION:

Enterprise Architect: Think about

Structural information in terms of

Methods, Artefacts, Guidance, Items and Culture (MAGIC).

Questions to Ponder

♦ What high level ontology do you use for describing information relating to the structure of things?

♦ Does it cover everything MAGIC does? ♦ If not, does that cause any problems?

Ontologies - 67 Relations hips

Ontologies

PR OO

So, how do the parts of MAGIC relate to each other? Culture (People) and Items (Things), are used to execute Methods, which consumes and generates Artefacts. The cycle can then repeat. The all-encompassing Guidance is like a trees trunk that guides everything else. The tree can bend and take many shapes, but the trunk remains. It allows movement, but within limits.

68 - Ontologies

KEYPOINT:

Methods are executed by Culture (people) and/or Items (things) to transform Artefacts.

Ontologies

ADOPTION:

Enterprise Architect: Think about

Structural information in terms of the

OO flow of Artefacts.

Questions to Ponder

♦ What high level ontology do you use for describing the interrelationship of the information relating to the structure of things?

♦ Does it cover everything MAGIC does? ♦ If not, does that cause any problems?

Ontologies - 69 Tr ans for mational MAGMA

Ontologies

PR OO

MAGMA is an ontology used to categorise information relating to transforming something.

♦ Measures - Information about the things that will allow us to know if we have ♦ ♦ ♦ ♦

achieved our goals and satisfied our requirements. E.g. Maturity Models, Metrics, KPIs, CSFs. Assessment - Information about assessments against the Measures, E.g. Strengths, Weaknesses, Opportunities, Threats, Pro’s, Cons, Issues, Risks. Motivation - Information about A) what is motivating us to proceed, e.g. Visions, Goals, Objectives, Requirements, etc, and B) what is demotivating us to proceed, e.g. Risks, Misconceptions, Threats, etc. Actions - Information about the things we need to do in order to achieve those goals and satisfy those requirements. E.g. Mission, Strategies, Tactics, Roadmaps, Plans, Tasks. On one hand, the actions are the actions were are currently executing Guidance - Information about the things that will guide us in our journey, E.g. Principles, Polices, Standards, Rules, Values, Frameworks.

70 - Ontologies

KEYPOINT:

Motivation, Actions, Guidance,

Measures and Assessment (MAGMA) is a Transformational Ontology

Ontologies

ADOPTION:

Enterprise Architect: Think about Transformational information in

OO terms of Motivation, Actions,

Guidance, Measures and Assessment (MAGMA).

Questions to Ponder

♦ What high level ontology do you use for describing information relating to the transformation of things?

♦ Does it cover everything MAGMA does? ♦ If not, does that cause any problems?

Ontologies - 71 Relations hips

Ontologies

PR OO

So, how do the parts of MAGMA relate to each other? Actions cause us to decide on the Measures we will use, which leads us to perform an Assessment based on those Measures, which leads us to create the Motivation (to proceed), which leads us to create proposed subsequent Actions. The cycle can then repeat. The all-encompassing Guidance is like a trees trunk that guides everything else. The tree can bend and take many shapes, but the trunk remains. It allows movement, but within limits.

72 - Ontologies

KEYPOINT:

Measures lead to Assessments lead to Motivation, leads to Actions

Ontologies

ADOPTION:

Enterprise Architect: Think about

Structural information in terms of the flow of Artefacts.

OO Enterprise Architect: Think about Transformational information in

terms of the flow of information.

Questions to Ponder

♦ What high level ontology do you use for describing the interrelationship of the information relating to the transformation of things?

♦ Does it cover everything MAGMA does? ♦ If not, does that cause any problems?

Ontologies - 73 Enter pr is e DOTS

Ontologies

PR OO

Pragmatic asserts that every Enterprise consists of four distinct conceptual parts which a) totally and completely defines all Enterprises without overlaps or gaps, b) are the most fundamentally important to the Board and the sustainability of the Enterprise and c) have different operating models, different cultures, different languages, different drivers, different mind-sets, different tools, different processes, different artefacts, etc.

Operation

Operation is that part which exists solely to fulfil that Enterprises Mission and thereby helping it to fulfil its Vision.

Transformation

Transformation is that part which exists solely to transform the Enterprise. If the Enterprise never needed to change, this area would simply not exist.

Support

Support is that part which exists solely for the purposes of dealing with problems and issues from the rest of the Enterprise and from customers and suppliers outside the Enterprise.

Direction

Direction is that part which exists solely to provide direction and leadership to the rest of the Enterprise. This is where the C-Suite, Partners and Exec Management team generally sit working on things like Vision, Mission, Goals, Objectives, Strategies, Tactics, Business Models and Operating Models.

74 - Ontologies

Ontologies

Direction tends to be different for some Enterprises, based on the type of Enterprise Private, Public, Charity, Partnership, Academic, etc. Operations tends to different for many Enterprises, based on what sector they operate within (energy, transportation, financial services, retail, etc) and then their place within that sector (wholesale gas, train manufacturing, insurance, grocery store). Transformation tends to be (or perhaps more importantly can be) very similar for most Enterprises. Whilst what is being transformed (mostly the Operations part of an Enterprise) varies from Enterprise to Enterprise, how that transformation is effected generally does not. Support tends to be (or perhaps more importantly can be) very similar from Enterprise to Enterprise, at least the high level structure. Most Enterprise have an IT Support function where tickets are generated and problems go through 1st and 2nd line, but most Enterprises also deal with other types of problems such as when employees have problems with their holiday entitlements or paychecks. These are problems that deserve to be handled in the same way as IT problems, where a ticket is raised and managed until the problem is resolved. Doing so would be much more efficient. Using DOTS is a very useful way to think about Enterprises (and perhaps to even physically structure them) because the areas are so fundamentally different but all are strategically important. No one (currently) thinks of structuring an Enterprise in this way, but Pragmatic says there are major benefits in doing so.

Ontologies - 75

KEYPOINT:

Direct, Operate, Transform and

Support (DOTS) is an Enterprise

ADOPTION:

Management: Make sure your

Enterprise recognises, and connects

the strategically important DOTS.

Questions to Ponder

♦ What high level structures does your Enterprise use to describe itself? ♦ Are they purely physical like Departments or more conceptual? ♦ Do you think DOTS is a useful structure for analysing and/or designing your Enterprise? ♦ What are you doing in your Enterprise to connect the DOTS? ♦ Who bangs the boardroom table for resources to improve each part? ♦ What is their title? Do they have a seat at the Board Table? If not, why not?

Ontologies

Ontology

76 - Ontologies Relations hips

PR Ontologies

So, how do the parts of DOTS relate to each other? At a high level, Direct (in response to the Enterprise Context) directs all other parts. Operate (supported by Transform and Support), takes things from the Context (customers, supplies, etc) and puts things into the context (products and services). Since each of DOTS constitutes a domain where things happen, we can see that each is composed of its own MAGIC.

Ontologies - 77

KEYPOINT:

Direction drives Operate (supported by Transform and Support) which puts things into the context.

ADOPTION:

Enterprise Architect: Think about

Enterprise Structure in terms of DOTS.

Questions to Ponder

♦ What high level ontology do you use for describing the interrelationship of the information relating to the structure of Enterprises?

♦ Does it cover everything DOTS does? ♦ If not, does that cause any problems?

Ontologies

takes things from the Context and

Methods - 79

PR OO

Methods

M E THO DS

80 - Methods

KEYPOINT:

The Methods section of POET

defines 'WHAT' should be done, 'HOW' and 'WHEN'.

ADOPTION:

C-Suite: Instigate a review of the

Methods

Methods used in the Enterprise's

OO Transformation Capability, to determine if their maturity is appropriate.

Questions to Ponder

♦ With respect to your Enterprises Transformation capability, what Methods are ♦ ♦ ♦ ♦

employed? Are those Methods documented? Understood? Are they fit for purpose? Are they followed? All the time? Only when it suits? Which of them are Good? Why? Bad? Why?

Methods - 81

PR These are the fundamental phases of Transformation which sit between the fundamental levels of Transformation. Starting at Strategising,, the transformation at each phase takes us closer to the physical world.

♦ ♦ ♦ ♦ ♦ ♦ ♦

Strategising - Why Should I Care? Roadmapping - Plan of action. Solutioning – High Level design and detailed planning. Elaborating – Detailed design. Constructing - Building the changes. Transitioning - Deploying the changes. Using - Using the changes.

The critical piece here, that connects and keeps all these phases synchronised and working together coherently, is Governance and Lobbying.

Methods

Phas es

82 - Methods

KEYPOINT:

The seven phases of transformation (Strategising, Roadmapping, Solutioning, Elaborating,

Constructing, Transitioning, Using)

are connected with the Governance & Lobbying discipline.

Methods

ADOPTION:

Management: Adopt the seven phases of Transformation - Strategising, Roadmapping, Solutioning, Elaborating, Constructing,

Transitioning, Using and the

Governance & Lobbying discipline that connects them.

♦ ♦ ♦ ♦

Questions to Ponder

Do you agree with these fundamental phases? If not, what would you change and why? What fundamental phases does your Enterprise define? If it does not, does that cause any problems or issues?

Methods - 83

Methods

â&#x2122;Ś If so, how will you solve them?

84 - Methods Bas ics

PR Methods

Here we see the fundamental Phases of Enterprise Transformation, laid out over the domains of the Enterprise. The Direction part of the Enterprise feeds requirements for transformation into the Transformation part of the Enterprise which delivers change into the Operations part of the Enterprise. It should be noted that the Transformation part of the Enterprise may also deliver change into the Direction, Support or even Transformation (the whole point of POET) part of the Enterprise but we just show Operations here as that is the most common occurrence. These Phases of Transformation are not strict and rigid waterfall type “processes”, but every journey has to be split up into parts, and these high level Phases form the high level parts of the journey, by which to consider holistically, how Transformation is effected from the formulation of Strategy to the Deployment of change into the Enterprise. For each Phase, the How that is effected is done by the next Phase down, and the Why comes from the Phase above. The key to the Transformation cascade working together holistically and coherently is the Governance and Lobbying disciplines which use the concept of Transformation Debt™. The white horizontal line at the top of the Transformation domain delineates the transition planning work from the project execution work. Everything below that white line is effectively “projectland” The white horizontal line at the bottom of the transformation domain delineates project execution work from the deployment work. Our remit is not only what is happening in one of these areas. Our remit is what is happening in all of these areas. In general people work within these areas and in most Enterprises these people try to improve what they do (if they are allowed) and how they do it. This is a laudable thing to do, however, no one is looking at the whole cascade and ensuring that the whole cascade is effective and efficient. The parts are being optimised at the expense of the

Methods - 85

♦ BA - Business Architecture (verb) consists of "doing": ♦ Enterprise Context modelling. ♦ Business Model modelling. ♦ Business Capability Model modelling. ♦ Business Motivation Model modelling. ♦ EA - Enterprise Architecture (verb) consists "doing": ♦ Operating Model modelling. ♦ Roadmap Model modelling. ♦ SA - Solution Architecture (verb) consists of "doing": ♦ Modelling Logical Solutions to business problems defined in the Roadmap. ♦ EE - Enterprise Engineering (verb) consists of "doing" all project level work: ♦ Elaborating (primarily detailed physical design). ♦ Constructing (primarily building and testing). ♦ Transitioning (primarily rolling change out into live operation).

Please see Methods > Overview > Levels > Basics for a description of the information being used in each phase.

Methods

whole. POET provides the basis for Senior Management to address optimising the whole of Transformation, for it is the output of the whole that most important rather than the output of each Phase - this in fact, may mean the de-optimisation of some or all of the parts. For this reason, everything in POET applies equally to all Phases of the Transformation cascade and is the unifying holistic and coherent context in which all Transformation work is performed. In terms of naming these phases there are four fundamentals.

86 - Methods

KEYPOINT:

Business Architecture feeds

Enterprise Architecture feeds Solution Architecture feeds Enterprise Engineering.

ADOPTION:

Methods

Management: Ensure everyone in the Enterprise understands which phases

are part of BA, EA, SA and Enterprise Engineering.

Questions to Ponder

♦ Do you agree with these Phase boundaries? ♦ How does your Enterprise map onto them? ♦ Does everyone working within the Transformation domain understand how where they work, fits into the whole?

♦ If not, would there be a benefit if they did? ♦ What will you do to allow people to understand how they fit into the whole, and what will you use?

Methods - 87

PR F

Here we see an illustration of how much resource (time, money, people, etc) is expended in each phase, expressed as a percentage of the annual spend on Transformation. These are not scientifically researched figures, but an approximation based on my experience of 40 years working in the Transformation capability of multiple companies and performing multiple roles. It can easily be seen that the majority of the resource (some 93%) is spent on Engineering phases; Elaborating (detailed designs and capability sourcing), Constructing (building, installing and testing capabilities), and Transitioning (capability rollout), while the minority (7%) is spent on Business, Enterprise and Solution Architecture. It is obvious therefore, that if we want to improve the effectiveness and efficiency of our Transformation capability (from Strategising to Transitioning) we should concentrate on improving Engineering, since that is where the majority of the work is done. Right? Well, let's seeâ&#x20AC;Ś If we consider a scenario where we are spending $10M per year on Transformation efforts, and we have decided to invest $10k to improve the way we perform Transformation, where will we get the most bang for our buck? In this scenario, we are therefore spending $9.3M on Engineering, and $700k on Architecture. If we elect to spend our $10k to improve Engineering and let's say we can get a 10% reduction in cost (on $9.3M) this means we will save $930k per year thereafter. If we elect to spend our $10k to improve Architecture and let's say that we also can get a 10% reduction in cost (on $700k) this means we will save $70k per year thereafter. So, the right choice is clearly to spend our 10k on improving Engineering and reap a $930k saving year on year. Right?

Methods

Res our ce Utilis ation

88 - Methods

Methods

Not quite. What we are not taking into account, is the fact that an improvement to Architecture, also brings about an improvement in Engineering. Not in HOW Engineering is being performed, but on WHAT Engineering is being performed upon and WHY. Of course it depends on the Enterprise, but it is not beyond the realms of possibility that improving Architecture could result in 10% of projects being cancelled (resulting in a 930k saving) but also a reorganisation of projects that brings another 10% savings on the Engineering (resulting in another 930k in savings). Add that to the $70k of savings in Architecture, could bring the savings up to over $2M per year. Of course, the "correct" answer would be to spend some money on improving both areas, but the point here is that while 99.9% of Enterprises are happy to spend money on improving Engineering, they are very reticent to spend money on improving Architecture.

Methods - 89

KEYPOINT:

99.9% of Enterprises are happy to spend money on improving

Engineering, but are very reticent to spend money on improving

ADOPTION:

Management: Assign more resources to improving Architecture.

Questions to Ponder

♦ Do you agree with this percentage split? ♦ If not, what percentages would you apply? ♦ Do those percentages prove or disprove the assertion that Architecture has a massive impactr despite its size?

Methods

Architecture.

90 - Methods Patter n

PR Methods

Here we see how the Phases of Transformation exist in a holistic and coherent cascade from Strategic intent at the top, down to deployed change at the bottom. For each phase, we can say that the information regarding WHY we are doing what we are doing (Transformational) and WHY we are doing it this way (Structural), flows from the phase above, and the information regarding HOW what we are doing will be made real (or operationalised) is accomplished by the phase below. For each phase (or ellipse) the same basic pattern of work is being carried out.

1. The structural starting point (as defined by MAGIC) for each phase is what currently exists, and is shown on the left of each ellipse.

2. This structural starting point for one phase, also acts as the information to perform

impact analysis on, and is shown below each phase. 3. The structural and transformational output for each phase is shown on the right of each ellipse. 4. This structural output for one phase, also acts as the information that provides constraints, and is show above each phase.

You will notice in the main diagram, that the some of the boxes are only showing slivers. This illustrates the fact that scope of work of each project at these levels, and therefore only deals with part of the Enterpriseâ&#x20AC;&#x2122;s Architecture and Engineering Models at a time rather than the whole.

5. We also see how the Transformational Artefacts (as defined by MAGMA) exist in this holistic and coherent cascade, by providing the Motivation and Actions that drive each phase.

Methods - 91 6. Finally we see that each phase performs Governance on the phase below, to ensure

that Principles, Polices and Standards are followed… 7. And Lobby’s the phase above, to raise Transformation Debt™ when the Principles, Polices and Standards cannot be adhered to, and the reasons why.

So, for each phase (or ellipse) the same basic pattern of work is being carried out:

♦ The inputs of Why are we doing it and Why are we doing it this way flow from the phase above.

♦ The outputs to the right consist of the transformation needed to effect the change

This simple pattern is the key to enable the whole Transformation domain to work together in a coherent and connected manner, allowing us the absolute best chance of success.

Methods

within the constraints of the Why are we doing it this way. This transformational information consists of detailed information to perform the next phase and high level information to perform all subsequent phases. ♦ These outputs are produced in the context of what currently exists at that level - to the left, and in the context of what currently exists - at the level below. ♦ Governance is performed down to the phase below. Lobbying is performed up to the phase above.

92 - Methods

KEYPOINT:

Use the Transformation cascade to link the phases together.

ADOPTION:

Management: Ensure everyone in the Enterprise understands how the

Methods

phases and levels of Transformation link together.

Questions to Ponder

♦ Do you think that this basic pattern can help to keep the whole aligned and connected and why?

♦ Does your Enterprise consider how the structural information at each level is used and reused by other levels?

♦ Do you think that this basic pattern can help to keep the whole aligned and connected and why?

♦ Does your Enterprise consider how the transformation information at each level is used and reused by other levels?

Methods - 93

PR To aid understanding, here we see the Transformation Cascade of Phases, but with common names in place of the base structural/transformational names. It is therefore obvious of the dependencies between each of the artefacts used by each phase. With these dependencies clearly shown, the error of creating an artefact without the proper dependent artefacts can hopefully be avoided.

Methods

Models

94 - Methods

KEYPOINT:

Understand how common artefacts relate to the Phase cascade.

ADOPTION:

Management: Ensure everyone in the Enterprise understands the

Methods

dependencies between common Artefacts.

Questions to Ponder

♦ Do you recognise any of these common Artefacts? ♦ Does your Enterprise utilise any of them? ♦ If so, which ones does it use, and for each one, are the required pre-requisites in place to be able to produce them? ♦ If not, which artefacts does it use and where would you place them on the Phase cascade?

Methods - 95

PR F

Governance & Lobbying is the glue which connects each phase together in an aligned and cooperative manner. Governance has long been seen as either some kind of policing activity where people are either forced to comply with things or alternatively a watered down box ticking exercise. Both approaches are insidiously destructive as they appear to have solved a problem when in fact they are making things worse! In fact the first part of governance is often overlooked - that of handover. There needs to be some handover to explain the why, to explain the constraints, to explain the reasons behind the decisions that have been taken. The key to effective governance is balance that Lobbying provides and is built upon the simple premise that a problem or an opportunity can be discovered at any time by anyone rather than the â&#x20AC;&#x153;normalâ&#x20AC;? western type management approach which tends to be the person who is right is the person who is more senior. Things change. Always. Continually. Guaranteed. So you can either ignore that inconvenient truth or accept it and put in a method to deal with it when it does happen. In the domain of Transformation it is not only the change related to the transformation we are executing but more importantly change to the context - the why - that we must also deal with. What we decided to do yesterday (and how and why) for many good reasons could be a massively bad thing to do today. This is a fact of life in the 21st century. So, if we are to deal with transformation in a Pragmatic way we need to accept this fact and deal with it rather than pretend it doesnâ&#x20AC;&#x2122;t exist and hope for the best. The overall idea that someone creates a strategy and 24 months later it is delivered is rubbish. The plans for the project portfolio (and the reasons) could (and generally do) change as the projects execute. Therefore we need a holistic and coherent environment for transformation to happen within which allows us to backtrack as soon as possible rather than blindly following a flawed plan.

Methods

Dis ciplines Gover nance & Lobbying Dis cipline

96 - Methods It is not only that work at any level can deviate from guidance (it will - the devil is in the detail) but also the fact that the strategic plan or roadmap changes (or should change) that causes the disconnect between each level.

PR Methods

Methods - 97

KEYPOINT:

Recognise that Governance &

Lobbying are inextricably linked.

ADOPTION:

Use Governance & Lobbying to of Transformation.

Questions to Ponder

♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦

Does your Enterprise do Governance? What happens when things do not comply? Does your Enterprise do Lobbying? What happens when things do not comply? Does your Enterprise just issue waivers that get forgotten? It is a tick box exercise? Is it a case of might is right? What happens when some problem or opportunity is found in a lower phase that means it cannot comply with guidance or it would not be wise to do so?

Methods

connect and synchronise each phase

98 - Methods Gover nance & Lobbying Tr ans for mation Synchr onis ation

PR Methods

The Transformation domain is made up of many parts. These parts are in constant motion and all are trying to do the best that they can. Even if those parts start off being synchronised and working together, over time they tend to become de-synchronised and in some cases even start working against each other. None of the parts want to work against any other part but the context they all work within does not tend to lend itself to helping the individual parts. Here we see the results of two experiments run by the Ikeguchi Laboratory in 2012 and 2013. A number of metronomes (32 or 64) are placed on a solid platform. Since there is something that is rigidly connecting the metronomes together you might think that this will help them synchronise. When we think about this in the physical world it is immediately obvious that just placing the metronomes on a common fixed surface will not cause them to synchronise, for while they are all “connected” there is no “communication” between them. This fixed surface can be thought of as the Governance that is performed during Transformation. Governance is the thing that we try to use to keep all parts joined up, synchronised, working toward a common goal, and connecting strategic intent to the changes that are ultimately deployed. But since governance is not a physical thing, it is not obvious that this alone will not work - although everyone expects (hopes) it will. However, while the fixed surface (Governance) is definitely required, the key to synchronisation is Lobbying. Lobbying is a subtle feedback loop, represented here by the fact that the fixed platform (Governance) is suspended. This suspension (Lobbying)of the platform (Governance) allows the platform itself to move slightly, and it is this (almost imperceptible) movement that causes the metronomes to synchronise. There is no outside force doing the synchronising, Synchronisation occurs because the metronomes collectively synchronise themselves.

Methods - 99

Methods

It is this feedback loop (the suspension of the platform) that is akin to Lobbying. Lobbying allows just enough â&#x20AC;&#x153;giveâ&#x20AC;? in the system (and reduction of friction) to allow Governance to work effectively, keeping all the parts synchronised

100 - Methods

KEYPOINT:

Utilise Governance and Lobbying to synchronise Transformation.

ADOPTION:

Management: Implement Governance and Lobbying.

Methods

Questions to Ponder

♦ Are the people working in your Enterprises Transformation domain, synchronised? ♦ If not, what problems does this create? ♦ If not, what can you do to help the synchronisation?

Methods - 101

PR The term â&#x20AC;&#x153;Technical Debtâ&#x20AC;? (in relation to the Creation and Transformation of IT systems) was coined by Ward Cunningham March 26, 1992. He coined the debt metaphor to explain product. the refactoring that he was doing on the WyCash http://c2.com/cgi/wiki?WardExplainsDebtMetaphor

Methods

Technical Debt

102 - Methods

KEYPOINT:

Technical Debt is the future

problems created when we write “bad” code. (Ward Cunningham)

Questions to Ponder

Methods

♦ Have you heard the term “Technical Debt” before? ♦ How did is show itself? ♦ What happened when “Technical Debt” was created?

Methods - 103

PR The concept of Transformation Debt™ (originally called Enterprise Debt™)

was created in 2008 as part of PEAF, and

was based on the concept of Technical Debt. Pragmatic EA Ltd has since clarified

expanded and developed the concept into a practical and easily usable methodology.

This methodology can be easily adopted to Pragmatically mature an Enterprises Transformation capability.

Technical Debt generally only considered one type of guidance “Think Long Term” in relation to IT Solutions (Application, Data, Platform, Technology) - illustrated on the graphic with green lines.

Methods

Technical Debt vs Tr ans for mation Debt ™

104 - Methods Transformation Debt™ takes this basic idea and expands it in 3 very important ways illustrated on the graphic with purple lines:

♦ Firstly, it applies not only to IT, but also (using MAGIC) to the Methods, Artefacts,

Guidance, Items (that IT is only a sub-domain of) and Culture domains. ♦ Secondly, it applies not only to one kind of guidance (“Think Long Term”) but to all types of Guidance (Values, Principles, Policies, Standards, etc) that guide HOW we effect Transformation, and the Structural Guidance provided by the levels above. ♦ And thirdly, it applies not only in one phase (Constructing) but in all phases of the Transformation stack.

In this way, Transformation Debt™ sits at the heart of the Governance & Lobbying disciplines which are the glue the makes the whole Transformation cascade coherent, effective and efficient. It provides the concept, mechanism and practical guidance that allows for problems or opportunities to be exposed (whenever and wherever they occur), and for them to then be evaluated and raised to the correct level for a decision to be made regarding their resolution in the full knowledge of the implications of doing so or not doing so.

Methods

Methods - 105

KEYPOINT:

Transformation Debt™ is applying

the principle of Technical Debt to all Guidance, all Phases and all Levels of Transformation.

Enterprise Architect: Apply the

concept of Transformation Debt™. (Application of the Technical Debt

concept to all guidance, all phases and all levels of Transformation.)

Questions to Ponder

♦ Have you heard the term “Transformation Debt™” before? ♦ Do you think applying “Technical Debt” to all guidance, and all parts and all phases of Transformation is useful? ♦ If not, why not?

Methods

ADOPTION:

106 - Methods Tr ans for mation Debt™ Overview

PR Methods

Let’s get some definitions out of the way:

♦ Resources - money, time, people, etc - whatever is required to effect a ♦ ♦ ♦ ♦

transformation. Requirements - the resources associated with satisfying the requirement of the work. Guidance - the Resources associated with satisfying the things that guide and influence how we satisfy the Requirements. Things like Principles, Policies, Standards, etc, but also things like conforming to the structures and methods imposed on us. Required Resources - the Resources that are required to satisfy the Requirements and conform to the Guidance. Assigned Resources - the resources that are actually provided - which are always less than those that are required!

Don’t forget that Governance & Lobbying happens at each level of the Transformation cascade and therefore each level has to conform to (or lobby against) the guidance (Structural and Transformational) from the level above. Now, lets consider these three worlds… The Perfect World

In the perfect world, the Assigned Resources (what we are given) would always equal the Required Resources (what we need) and there are therefore no problems. But that never happens...

The Real World In the real world, the Assigned Resources very rarely (aka never) equal the Required Resources… From the point of view of satisfying the Requirements, this discrepancy is usually managed as part of Requirements Management. Any requirements that cannot be met are usually identified and either resource is brought to bear to satisfy them, or they are “de-scoped”. This is not where most of the problems that derail Transformation efforts lie. From the point of view of satisfying the Guidance, this discrepancy is usually not managed, or if it is, not managed well. Often the discrepancy is ignored, or an entry placed in a risk register that is never acted upon. In fact, many Enterprises take a very dim view of exposing these problems. There may very well be valid business reasons for this, but a lot of the time this restriction is pretty arbitrary. For example, I have personally worked on countless projects that had drop dead go live dates that, if missed, would mean the world would end - but, it never did. I have also worked on countless projects where the money required was not made available - again for some pretty arbitrary reasons - but in reality, those restrictions meant the project ended up spending far more. I am sure you have too. Restriction of resources tends to be the very simplistic (and ultimately severely damaging) control mechanism that management uses in relation to Enterprise Transformation, as well as the simplistic management style of always asking for more for less. This leads people to produce inflated estimates (assuming they will be cut) and management to not believing them (assuming they will be inflated). Two well-known phrases come to mind:

“There is never time to do it right, but always time to do it over.” “A short-cut is the longest distance between two points.” For most Enterprises that’s where it stops. People just have to knuckle down and muddle through somehow - put their nose to the grindstone - work as team - forge ahead - think positive thoughts - don’t be negative - just-do-it etc. Perhaps some lip service is paid to this gap - some entry in a risk register that is never used for anything - but that’s about it. There will be implications, but those implications are not fully known and will only be discovered later when nothing can be done about them and those that could have done something about them have moved on to far more important things. But, let us be clear. Not providing what is required is not the problem. Ignoring the implications is… The Pragmatic World

In the Pragmatic world, things start off the same as in the real world i.e. the Assigned Resources very rarely equal the Required Resources. However, in the Pragmatic world we accept this inconvenient truth and do something about it. We recognise that we are creating Transformation Debt™ and there are three things we need to expose and consider:

♦ Cost of Compliance - What is preventing the Enterprise from complying with the guidance and what is required to allow the Enterprise to comply?

And, assuming what is required is not provided…

Methods

Methods - 107

108 - Methods ♦ Cost of Non-Compliance - What issues and risks going forward will this non-

compliance create for the Enterprise? ♦ Cost of Remediation - What will it cost the Enterprise to become compliant in the future?

Transformation Debt™

Methods

Transformation Debt™, is what it will cost to service the debt going forward, and what it would cost to bring the work being done up to the same standard as would have been produced if the Assigned Resources had been provided. Note that the Cost of Remediation is bigger than the difference between the Required Resources, and the Assigned Resources. This is because it will always cost more to do something one way and then change it to another than it would have cost to just do it right the first time. It should also be noted that while Transformation Debt™ can be incurred when doing Transformation, it can also be incurred when not doing Transformation, by just the passage of time. For example, by not keeping operating systems up to date or by not maintaining a building or people properly. In many ways, this type of Transformation Debt™ is more insidious as it can creep up on you unawares. Having exposed these three key pieces of information, a Business decision can then made to either provide what is required to comply (Cost of Compliance) or to accept the implications of not doing so (Cost of Non-Compliance + Cost of Remediation). If the Business decision is made to not provide what is required to comply, this Transformation Debt™ adds to the overall Enterprise Debt™. Enterprise Debt

Enterprise Debt is a measure of the overall debt an Enterprise has incurred and is literally a list of the debts the Enterprise has on its books. It is a well understood accounting term meaning short and long term loans, accrued wages and utilities, income taxes payable, and other liabilities. Pragmatic believes that Transformation Debt™ should also be listed as a liability of an Enterprise and accounted for in the proper way. Transformation Debt™ (like any financial debt) also has to be serviced in the form of interest payments, for example increased support costs. Like interest payments on a loan, this is a recurring cost and will continue for as long as the Transformation Debt™ it is servicing exists. In addition, if the thing that was transformed now needs to be transformed again, there will also be an increased cost to effect that change. This change also requires resources and if the Assigned Resources for this change does not equal the Required Resources for this change we are introducing even more Transformation Debt™ into the Enterprise - a double whammy! This is akin to taking out another loan to pay the interest on a current loan! However, it’s not all doom and gloom. If it is recognised that we need to do some remedial work, (or more likely, things just get so bad the Enterprise has no choice but to do some remedial work) this reduces Transformation Debt™ and is therefore akin to paying off (some) of the overall Enterprise Debt. Recognising and managing Transformation Debt™ provides a simple and extremely effective control mechanism for management to get back in control of their Transformation initiatives and for those working in them to produce quality work (and to be able to sleep at night!) Managing Transformation Debt™ is not an exercise in making sure that the Assigned Resources always equals the Required Resources.

Methods - 109

Methods

Managing Transformation Debtâ&#x201E;˘ makes sure that when the Assigned Resources does not equal the Required Resources (most of the time) that the implications are exposed so that management can make informed business decisions in the light of that information.

110 - Methods

KEYPOINT:

The future cost of Non-Compliance

and Remediation will always be bigger than the current Cost of Compliance.

ADOPTION:

Management: Ensure everyone in the

Methods

Enterprise understands Enterprise Debt and Transformation Debt.

Questions to Ponder

♦ Do you have experience of any of these scenarios? ♦ What happened? ♦ Do you think the “Pragmatic World” scenario beneficial and why?

Methods - 111

PR This diagram illustrates three main things

1) Firstly, it illustrates (in red) what happens when Transformation Debt™ is not exposed and managed. This is typical of most Enterprises. 2) Secondly, it illustrates (in green) what happens when Transformation Debt™ is exposed and managed. 3) Thirdly, it shows (in orange and blue) the savings produced when Transformation Debt™ is exposed and managed vs when it is not exposed and managed.

When Transformation Debt™ is Hidden and Not Managed The solid red line illustrates the cumulative Transformation Costs of an Enterprise that does not expose and manage Transformation Debt™ and is typical of many Enterprises. The light red line shows the resulting Transformation Debt™. Cumulative Transformation Costs rise, but very slowly, while Transformation Costs are kept low. During this time hidden Transformation Debt™ is slowly building up… When this hidden Transformation Debt™ reaches a critical point (akin to when the pile of dirt that is swept under the carpet has become too big to ignore any longer) a very large and abrupt rise in Transformation Costs is required to deal with it. Often referred to as “getting the car out of the ditch”, its focus is usually very tactical - short term and only concerned with dealing with the major issue that cannot be ignored any longer. Having spent a large amount of money on Transformation over a very short timeframe, the focus then tends to be, once again, to keep Transformation Costs low and therefore we return to the low level of Transformation Costs we saw before and the whole process repeats itself. Not exposing and managing Transformation Debt™ is characterised by:

♦ Low Transformation Costs while hidden Transformation Debt™ builds up…

Methods

Investm ent Profiles

112 - Methods ♦ Followed by large, unplanned and abrupt Transformation Costs when things get too

These large, unplanned and abrupt rises in Transformation Costs, can often occur at the same time that an incumbent CIO is replaced by another! This is obviously not good news for the CIO, but more importantly is not good news for the entire Enterprise. A cynical view might be this. From the point of view of giving prospective Enterprises a feeling that someone senior is a good hire, what could be better than for a previous Enterprise to have been fantastically successful while they were there and then fall apart when they left? What could be better than to say “While I was there, they were growing well and highly profitable because I kept Transformation Costs low. When I arrived they were in the doo doo, but I turned it around! Then, after I left, without my guidance, Transformation Costs increased and profits fell. It all fell apart”. Of course the reasons they managed to keep Transformation costs low was because they were raping the future. So, what could be a perfect way to engineer this outcome? Is there one thing that could be done to achieve both of these things? Can I hit two birds with one stone? The answer is yes you can. All you need to do is rape the future of the Enterprise by ignoring Transformation Debt™. You will then guarantee short term benefits while you are there (for which you will be applauded and given large bonuses because everyone loves quick wins) at the same time as guaranteeing it will all fall apart when you leave. But that’s not the best part. The best part of it is, you can achieve all of this by effectively doing nothing! (Is this the definition of Management Nirvana?) Not exposing and not Managing Transformation Debt™ is like boom and bust in the economy, and we all know the effects of boom and bust! When Transformation Debt™ is Exposed and Managed The solid Green line illustrates the cumulative Transformation Costs of an Enterprise that does expose and manage Transformation Debt™. The green dotted lines shows the resulting Transformation Debt™. Cumulative Transformation Costs rises more steeply than before, as management decisions release resources to keep Transformation Debt™ under control. Transformation Debt™ does build up but this debt is exposed and managed and does not get as large as before, purely because we are managing it and spending money wisely. Since we are managing Transformation Debt™, increased Transformation Costs to reduce it can be planned ahead, so that when debt reaches a critical point we can reduce it in a controlled way. In addition, while this increased Transformation Cost solves any short term problems that may be evident it is also aligned to longer term goals. After the increased Transformation Costs, we again return to a more moderate level of Transformation Costs and the whole process repeats its self. Exposing and managing Transformation Debt™ is characterised by:

Methods

bad… ♦ Causing unpredictability, which leads to instability, which means management is not in Control.

Methods - 113 ♦ An Increased level of Transformation Costs while Transformation Debt™ is exposed

and managed… ♦ Followed by moderate Transformation Costs when planned… ♦ Providing predictability, which leads to stability, which means management is in Control.

Exposing and Managing Transformation Debt™ relieves this boom and bust investment cycle. The downside is that it requires an increased initial investment in the short term. The upside is that it requires lower investment over time and prevents Transformation Debt™ from spiralling out of control. “If you don’t control your Transformation Debt™, it will control you.” - Pragmatic

“If I utilise Transformation Debt™ how much money will I save?” The lines are shown negative as negative = savings. Positive = costs. The Orange line shows the direct savings made by managing Transformation Debt. Essentially it is the Green line minus the Red Line. Although the Orange line does show savings over time, the important thing to note is that it costs us more initially. It is only when the first “panic” is averted later (because we managed Transformation Debt™ over time) that the savings kick in. This initial increase in costs is what needs to be “sold” to management. The Blue line shows the savings of the Orange line added to the additional indirect savings we make by not incurring as much Transformation Debt™. Essentially it is the Orange line plus the difference between the light green dotted line and the light red dotted line.

Methods

Savings Produced When Transformation Debt™ is Exposed and Managed Looking at the two final lines - Blue and Orange. They essentially answer the question:

114 - Methods

KEYPOINT:

If you do not control Transformation Debt™ it will control you.

ADOPTION:

Management: Draw a graph of the last 20 years of transformation

Methods

investment.

Questions to Ponder

♦ Which line most closely resembles your Enterprises Transformation cost profile? ♦ Do you think it is preferable to expose and manage Transformation Debt™, and if ♦ ♦ ♦ ♦ ♦

so, why? How much hidden Transformation Debt™ exists within your Enterprise? What is the interest rate you are paying? How long will you have to continue to pay the debt for? How do you intend to pay off the Debt and when? How close are you to maxing out your Enterprise’s credit card?

Methods - 115

PR Considering the final results the right hand side of the graph, we can see that over time the savings can be huge. Transformation Debt™, like any debt, is not inherently a bad thing though. Used correctly it is a massively important Strategic Management tool. But like any debt, Transformation Debt™ is only bad when:

♦ ♦ ♦ ♦ ♦

It is hidden and you don’t know you are incurring it You don’t know how you will pay off the debt You don’t know the interest rate You don’t know how long you will have to pay the interest …all of the above.

When times are good, you can invest in reducing Transformation Debt™, which means when times are bad, you can lean on Transformation Debt™ by allowing a controlled increase. However, if you do not expose and manage Transformation Debt™ your Transformation Debt™ could already be too high to allow you to ride out the bad times. If you max out your credit card, how will you be able to fix your car when the exhaust falls off?

Methods

Investm ent Results

116 - Methods

KEYPOINT:

Managing Transformation Debt™ can save huge amounts of money, and

(probably more importantly) time.

ADOPTION:

Management: Estimate how much

Methods

money the Enterprise could save

over the next 10 years, if it managed Transformation Debt.

Questions to Ponder

♦ What is your estimate (for your Enterprise) for how much money could be saved, if Transformation Debt™ is exposed and managed?

Methods - 117

PR Although the process laid out here is step by step, it should be understood that many iterations of this work may need to be done, and that these steps only provide an overall outline of the work required and the probably order of its execution. When The process is usually conducted once per year although can be executed on an ad-hoc basis whenever a major event causes the Enterprise to rethink its Intermediate or Target Model. E.g. A Merger or acquisition. In addition, it should be understood that when Solutioning and Engineering projects execute, they may (via Lobbying) expose problems or opportunities that cannot be solved or exploited unless the roadmap is revisited.

Methods

Phas es Roadmapping Pr oces s

118 - Methods Analyse Business, Capability & Motivation Models

PR Enterprise Strategy Model Complete

Update Current Operating Model

Baseline Created

Methods

Analyse Business Capability & Motivation Models Here we confirm that the Business Capability & Motivation models are of the required standard for us to use them, and we understand them. This is easily said, but in practice could take an appreciable amount of time, especially if the Business Capability & Motivation Models are not of the required quality. Many Enterprises create these "Models" but they are often incomplete, incoherent, and stored in unstructured storage such as word documents. There is nothing "perfect world" about wanting to have this information in structured storage (aka a Modelling Tool). Doing so easily exposes any inconsistencies or incompleteness, allowing them to be corrected before more expensive work is carried out based on them. For many Enterprises who do not express their Business Capability & Motivation Models in a Modelling Tool, this is the first thing that needs to be done. Its not all doom and gloom though! Although it is essentially extra work (extracting the information from Word documents and placing it into a Modelling Tool) it is a great way for the EA to really understand what the Business Capability & Motivation Models are saying. Obviously, if this is the first time this has been done, it will take more time. For subsequent times, it should be easier since a lot of the information should already exist, and we can spend more time understanding the differences between the old Business Capability & Motivation Models and the new ones. Update Current Operating Model Here we ensure we have an update baseline of the Current Operating Model. If this is the first time, this will need to be created and could take an appreciable amount of time. If not, it comes from the last Roadmaps Target Operation Model and should be simply to confirm that it still represents reality.

Methods - 119 Update Target Operating Model

Update Intermediate Operating Models

Structural States Agreed

Update Target Operating Model The Target Operating Model largely aspirational. It represents what some people may call “a perfect world”. If the definition of “a perfect world” is “something that is impossible to achieve” then the Target Model is NOT “a perfect world” Model. The Target Model should be attainable given enough resource and time, and while it MAY never be achieved, it is POSSIBLE. The Target Model is also inspirational. It provides a reasonably clear statement as to what the Enterprise would look like in the future. The more people who understand that in an Enterprise, the more chance the Enterprise has of attaining it. Documenting, understanding, and distributing a clear statement of the Target state, provides everyone with a goal to aim at in principle. Because it is defining the Enterprise in the future (5 to 10 years) its scope, depth and detail is not as high as the Current Model. It is meant to contain a broad brush definition of the target with only enough detail to convey what is important about the target. Update Intermediate Models Here we create one or more Intermediate Models. These Models correspond to Objectives defined in the Motivation Model, although the relationship between the two does not have to be one to one. The decision regarding what these states are and their timing in relationships to the Objectives is part of the art and science of Architecture. The further these models are in the future, the less detail (certainty) they are likely to contain.

Methods

PR Baseline Created

120 - Methods Update Principles Model

PR Structural States Agreed

Analyse & Include Transformation Debt™ Remediation Update Portfolio Model (Transformational Roadmap)

Portfolio Agreed

Create Project Packs for Each Entry in the Portfolio

Methods

Update Principles Model Here we Update the Principles that the Transformation Capability will use for Governance & Lobbying as the project portfolio executes. As stated in other places, while many of these principles are born from general Best Practice, some of them Enterprise specific, having been born from the Target and Intermediate models that have been defined for this Enterprise. Analyse & Include Transformation Debt™ Remediation Here we look at the current Transformation Debt™ which exists and try to include its remediation at the same time as work that is satisfying the Objectives and the resulting Target and Intermediate Operating Models. While having specific Remediation projects to remove Transformation Debt™ is not out of the question, it is more likely (efficient) that any reduction is carried out by including the necessary remediation work in other existing projects that are “touching” that part of the Enterprise. Update Portfolio Model (Transformational Roadmap) Here we construct a set of projects, programs, and initiatives (Roadmap) required to move the Enterprise from its Current Operating Model towards its Target Operating Model, through the required Intermediate Operating Models, including the remediation of Transformation Debt where reasonable. Create Project Packs for Each Entry in the Portfolio Here we flesh out each of the projects, programs and initiatives we have formulated with the conceptual designs for each, along with high-level scoping documents and Business Problem Definitions. It is this information that will be handed to Solution Architects later when the next phase of work (Solutioning) begins.

Methods - 121

KEYPOINT:

Accumulated Transformation Debt™ is reviewed during Roadmapping.

ADOPTION:

Enterprise Architect: Feed into Roadmapping.

Questions to Ponder

♦ ♦ ♦ ♦

Does this process match your Enterprises process for doing Roadmapping? If not, is their anything missing? Does it feed currently existing Transformation Debt into the mix? How would you mature your Enterprises Roadmapping process?

Methods

outstanding Transformation Debt™

122 - Methods Gover nance & Lobbying

PR Methods

Methods - 123

KEYPOINT:

EA performs Governance down to projects, and accepts Lobbying up from Projects.

ADOPTION:

Governance down to projects.

Accepts Lobbying up from Projects.

Questions to Ponder

♦ Does your Enterprise recognise that EA Governance is imperative to Transformation?

♦ Does your Enterprise recognise that EA Lobbying is imperative to Transformation? ♦ Does your Enterprise recognise that EA Governance and Lobbying is the glue which keeps Project execution in line with the strategic goals? ♦ If not, what does it do to keep Project execution in line with the strategic goals?

Methods

Enterprise Architect: Perform

124 - Methods Pr oces s

PR Methods

The steps in the bottom part of this process (in grey) are there to illustrate what work should be going on in a project as part of the Solutioning phase. PEAF does not prescribe what these are (that is the job of PEEF - The Pragmatic Enterprise Engineering Framework) but we need to document them so we can show how Governance & Lobbying fits in, and also to make sure it fits in, in the correct way.

Methods - 125

KEYPOINT:

Reviewing Options and Solutions is the heart of Governance.

ADOPTION:

Enterprise Architect: Make sure EA Problem. 2. Solution Options. 3.

OO Solution.

Questions to Ponder

♦ Does your current Project Process start with a clear definition of the Business ♦ ♦ ♦ ♦ ♦

Problem? Does your Governance ensure that all options have been considered? Do you expose Transformation Debt™ as it is being created? If you do not do one or more of the above, does that cause issues and problems? If so, what are the effects of those issues and problems? What will you do to solve them?

Methods

Governance reviews: 1. The Business

126 - Methods Str ategic vs Tactical

PR Methods

The words Strategic and Tactical are used frequently in Enterprises in relation to Transformation. However, these words are normally ill defined, and as such, different groups tend to use them in different ways, while assuming they are being used in the same way. “The Business” “The Business” tends to talk in terms of WHY work is required. Objectives.

♦ Strategic – Achieves long term objectives. ♦ Tactical – Achieves short term objectives which may or may not contribute to Strategic Objectives.

These definitions seem reasonable. But, in my experience, “The Business” tends to call everything they want Strategic - In 40 years, I cannot recall “The Business” ever saying something they wanted was Tactical. In some ways you could say that this is correct, since even Tactical work (should) contribute to Strategic objectives. However, I suspect calling everything Strategic is more to do with politics:

♦ To increase the likelihood of the work being chosen (“We must do this – it’s a strategic project”).

♦ To drive the work on after it has been started (“Full steam ahead – it’s a strategic project”)

♦ To prevent work stopping (“We can’t stop now! – it’s a strategic project”).

Methods - 127 “IT” “IT” tends to talk in terms of HOW work is performed. Actions (to achieve Objectives).

♦ Strategic – Done in a way that maximises long term value, by following best business

Arguments Something that happens a lot in Enterprises when projects are executing, is a discussion (or rather an argument) about whether a project is Strategic or Tactical. “IT” may be raising red flags saying “This is a Tactical Project” while “The Business” may be saying “This is a Strategic Project”. They are both right, but for different reasons. WHY we are doing the project is Strategic, but HOW we are doing the project is Tactical. This is why many “Tactical Projects” end up being the “Strategic Solution” This disconnect between “The Business” and “IT” can often lead “The Business” to ignore “IT” when it says “Its Tactical” and just chalk it up to “IT” complaining again, try to live in a perfect world Quadrants The diagram shows a quadrant diagram with all possible permutation of the Strategic vs Tactical conundrum. The red boxes denote states that logically should not exist. If the reason for doing something is because it is strategically important (Achieves long term objectives) why would it be done in a Tactical way (Done in a way that maximises short term value, by ignoring best business practice principles, which will cost more in the long term, compared to Strategically). Similarly, If the reason for doing something is because it is tactically important (Achieves short term objectives which may or may not contribute to Strategic Objectives) why would it be done in a Strategic way (Done in a way that maximises long term value, by following best business practice principles, which will cost more in the short term, compared to Tactically.) The green boxes denote states that logically should exist. If the reason for doing something is Strategically important (Achieves long term objectives) it is reasonable (even desirable) that the work should be done in a Strategic way (Done in a way that maximises long term value, by following best business practice principles, which will cost more in the short term, compared to Tactically). Similarly, If the reason for doing something is Tactically important (Achieves short term objectives which may or may not contribute to Strategic Objectives) it is reasonable (even desirable) that the work should be done in a Tactical way (Done in a way that maximises short term value, by ignoring best business practice principles, which will cost more in the long term, compared to Strategically.). Of course, there may be exceptions, but the general rule is that if you find yourself in the red boxes, serious thought should be given to the reasons for that.

Methods

practice principles, which will cost more in the short term, compared to Tactically. ♦ Tactical – Done in a way that maximises short term value, by ignoring best business practice principles, which will cost more in the long term, compared to Strategically.

128 - Methods

KEYPOINT:

Don’t confuse the Tactical/Strategic

reasons for doing projects, with the Tactical/Strategic methods of executing them.

ADOPTION:

Methods

Management: Ensure everyone in the

Enterprise understands the difference between a Strategic/Tactical project, vs a project executed in a Strategic/Tactical way.

Questions to Ponder

♦ ♦ ♦ ♦

Does your Enterprise confuse Strategic Projects and Tactical work? If so, does that cause any problems? What needs to change to alleviate those problems? Can you think of an example of Tactically Important work, done in a Strategic way?

Methods - 129

PR The work undertaken in any project can be thought of consisting of three fundamental types:

♦ Compliant Work - Work that complies with Guidance. Generally the most

effective, most efficient and least risky manner of achieving an end. ♦ Non-Compliant Work - Work that contravenes Guidance. Generally less effective, less efficient and more risky manner of achieving an end. ♦ Remedial Work - Work that exists to correct previous Tactical Work (i.e. changing previous Tactical work into Strategic Work) Guidance here refers to the Guidance of the Structural (MAGIC) and Transformational (MAGMA) information, dependant on the phase of the Transformation cascade we are in. Here we see the Transformation Debt Ratio™ (TDR) for the projects in the currently executing Project Portfolio. TDR is the ratio (adding up to 1.0 or 100%) of Compliant vs Non-Compliant vs Remedial work in any project. Each project has a different ratio of Compliant vs Non-Compliant vs Remedial work. Non-Compliant work is essentially a shortcut, and while a dictionary definition of a shortcut sounds quite positive and inviting:

1 : a route more direct than the one ordinarily taken 2 : a method or means of doing something more directly and quickly than and often not so thoroughly as by ordinary procedure <a shortcut to success> - Merriam-Webster In the business world the following is more true:

Methods

Tr ans for mation Debt™

130 - Methods “A shortcut is the longest distance between two points.” - Issawi's Law of the Path of Progress

Add to this the following…

“Nothing is permanent, except for temporary solutions.” - Jeroen van de Kamp

…and you can perhaps begin to see why Enterprises not only naturally decay into entropy over time but how uninformed management decisions actively encourage and hasten it. If the work in a project complies with all Guidance (aka is Compliant) then we have no problems. If not and some work does not comply with some Guidance (aka is NonCompliant) then a Transformation Debt™ Agreement (TDA) is created. The TDA details three things:

♦ Cost of Compliance - What is preventing the project from complying with the

Methods

guidance and what does the project need to be given to allow the project to comply and therefore convert the work from Non-Compliant to Compliant. ♦ Cost of Non-Compliance - What issues and risks going forward will this NonCompliance create for the Enterprise. ♦ Cost of Remediation - What will it cost the Enterprise to become Compliant in the future (assuming the project is not allowed to do what is required now to become Compliant).

In simple terms:

♦ The Cost of Compliance - What will it cost the project to do the right things now. If the project is not granted the Cost of Compliance:

♦ The Cost of Non-Compliance - What pain will the Enterprise have to endure going forward, until we incur ♦ The Cost of Remediation - What will it cost the Enterprise later to fix it.

But why is it called an “Agreement” rather than an “Assessment” or “Waiver” or something else? Originally, Pragmatic called it a “Waiver”, but that word did not truly reflect what it was. The reason we call it a Transformation Debt™ Agreement, is because it really is an agreement! An agreement by management that they agree to provide the resources required to satisfy the guidance, or that they agree to accept the recurring cost of non-compliance and potentially the future cost of remediation. Another way to think about it, since it is possibly incurring debt, it is similar to a loan agreement, where you detail the loan amount, what the interest is, and what it will cost to pay off the loan in the future. Having defined this information, a business decision can then be made to either provide what is required now or accept the pain we will have to endure going forward AND the costs of fixing it later. This is what sits at the heart of Governance and Lobbying. Since a project that is Non-Compliant with guidance while the project is executing could become Compliant at any time before the project ends, only when a project completes will we know how many TDAs have been issued and the Transformation Debt™ being created in the form of the Cost of Non-Compliance that the Tactical work created and the Cost of Remediation to correct that Tactical work in the future.

Methods - 131

Methods

At that point in time the Cost of Non-Compliance that the Non-Compliant work created and the Cost of Remediation to correct that Non-Compliant work in the future can be added to the Transformation Debtâ&#x201E;˘ for the whole Enterprise. In effect the Cost of Non-Compliance is akin to paying interest on the Debt we have incurred, while the Cost of Remediation (if spent) is akin to paying off the Debt. When you incur Transformation Debtâ&#x201E;˘, you are selling tomorrow, to get through today.

132 - Methods

KEYPOINT:

Transformation Debt™ Agreements expose Transformation Debt™ Value.

ADOPTION:

Management: Ensure that

Methods

Transformation Debt™ Agreements

OO to expose: 1) The cost of

Compliance. 2) The cost of NonCompliance. 3) The cost of remediation, are raised.

Questions to Ponder

♦ Does your Enterprise think about how Transformation work is carried out in terms ♦ ♦ ♦

♦

of Compliant vs Non-Compliant vs Remedial? When projects currently do not comply with guidance, what happens? Does your Enterprise keep track of how much Transformation Debt™ your Transformation projects are creating? When projects currently do not comply with guidance, is some kind of Transformation Debt Agreement (TDA) issued? If not, how are valid and sound business decisions made?

Methods - 133

PR Although Transformation Debt Ratio™ is defined for each project, it can also be combined to produce an TDR for a group of projects in a program or an overall TDR for the entire Project Portfolio. Of course, when combining TDR you need to weight each individual TDR to get a balanced view. While TDR for the entire Transformation Portfolio provides a useful metric at a point in time, it is more useful to track it over time. A sensible view might be that over time, an Enterprise might like to see the amount of work that is Compliant increase and the amount of work done in a Non-Compliant way decrease - since doing work in a Compliant way is generally the most effective, most efficient and least risky manner of doing it.

♦ In Year 0 - the year of adopting PEAF (and hence Transformation Debt™) it is more

♦ ♦

♦

than probable that a lot of work will still have to done in a Non-Compliant way. However we make the necessary plans to do a decent amount of Remedial work the following year. In Year 1, while still having to do a lot of work in a Non-Compliant way, we perform the Remedial work we planned the year before, which lays the groundwork for Year 2. In Year 2, we can now start to do more work in a Compliant way (because of the remedial work we did in the previous year) and less work in a Non-Compliant way, while still doing some Remedial work, both of which lays the groundwork for Year 3. In Year 3, doing work in a Compliant way is now beginning to outweigh doing work in a Non-Compliant way (because of the remedial and Compliant work we did in the previous year) and this, in addition to a little Remedial work, lays the groundwork for Year 4. In Year 4 we are doing most work in a Compliant way and only do work in a NonCompliant way when really necessary.

Methods

Ratio

134 - Methods

Methods

This is only an example of course and will vary from Enterprise to Enterprise and will be influenced by many factors such as the fiscal climate and current Enterprise Strategy. However, the examples provided illustrate one of the indicators of increasing EA Maturity in that Enterprises that are more “mature” are the ones who spend a greater proportion of their resources doing work in a Compliant way rather than a Non-Compliant way and therefore need to spend little on remedial work. The key point is: If You Never PLAN To Do Transformation In A Way That Complies With Guidance, You Will Never DO Transformation In A Way That Complies With Guidance. Unless you planned for it, time pressures (the incessant need for quick wins for example) will always force you to do work in a Non-Complaint way rather than in a Compliant way. The key is breaking the cycle. Another thing to consider is that the choices being made when formulating the Transformation Portfolio should perhaps aim to do less, better. What we mean by that is that it might be a better approach to doing less things in a Compliant way (spending the money and time you save on allowing those initiatives to execute in a Compliant way (thereby incurring no Transformation Debt™) rather than doing more things in a NonCompliant way (thereby incurring Transformation Debt™).

Methods - 135

KEYPOINT:

Over time, increase the ratio of Strategic to Tactical work.

ADOPTION:

Management: Over time, increase the done in a Compliant fashion, while

OO decreasing the amount of

Transformation work done in a NonCompliant fashion.

Questions to Ponder

♦ ♦ ♦ ♦

What is the TDR for your currently executing Transformation Portfolio? How do you want that to change going forward? What do you need to do to make that happen? What will you do to break the cycle?

Methods

amount of Transformation work

Artefacts - 137

PR OO

Artefacts

ARTE FACTS

138 - Artefacts

KEYPOINT:

The Artefacts section of POET defines 'WHAT' information is consumed and produced and 'WHEN'.

ADOPTION:

C-Suite: Instigate a review of the

OO Artefacts used in the Enterprise's

Artefacts

Transformation Capability, to determine if their maturity is appropriate.

Questions to Ponder

♦ ♦ ♦ ♦ ♦

With respect to your Enterprises Transformation capability, what Artefacts are used? Are those Artefacts documented? Understood? Are they fit for purpose? Are they used? All the time? Only when it suits? Which of them are Good? Why? Bad? Why?

Artefacts - 139 Over view Levels

♦ Enterprise Context - A representation of the physical world outside out Enterprise.

♦ Contextual - A representation of why we exist and how we satisfy the need for our ♦ ♦ ♦ ♦ ♦

existence? Conceptual - A representation of how we need to change. Logical - A representation of Logical Solution designs. Physical - A representation of Physical solution designs. Operational - A representation of the physical world. Physical Stuff - The physical world inside out Enterprise.

Artefacts

PR These are the fundamental levels that artefacts can exist at, which sit between the fundamental phases of transformation. Starting at the Enterprise Context, the information at each level is transformed and becomes closer to the physical world.

140 - Artefacts

KEYPOINT:

The seven levels of transformation (Enterprise Context, Contextual, Conceptual, Logical, Physical,

Operational, Physical Stuff) sit in between the seven phases of Transformation.

OO ADOPTION:

Artefacts

Management: Adopt the seven levels of transformation

Questions to Ponder

♦ ♦ ♦ ♦ ♦

Do you agree with these fundamental levels? If not, what would you change and why? What fundamental levels does your Enterprise define? If it does not, does that cause any problems or issues? If so, how will you solve them?

Artefacts - 141 Bas ics

Artefacts

PR F

Here we see the fundamental Levels of Enterprise Transformation, laid out over the domains of the Enterprise. The Direction part of the Enterprise feeds requirements for transformation into the Transformation part of the Enterprise which delivers change into the Operations part of the Enterprise. It should be noted that the Transformation part of the Enterprise may also deliver change into the Direction, Support or even Transformation (the whole point of POET) part of the Enterprise but we just show Operations here as that is the most common occurrence. These Levels of Transformation are not strict and rigid, but every journey has to be split up into parts, and these high level Levels, form the high level artefacts of the journey, by which to consider holistically, what information is required, from the formulation of Strategy to the Deployment of change into the Enterprise. For each Level, information about the How that is effected, is done by the next Level down, and information about the Why comes from the Level above. The white horizontal line at the top of the Transformation domain delineates the transition planning work from the project execution work. Everything below that white line is effectively â&#x20AC;&#x153;projectlandâ&#x20AC;? The white horizontal line at the bottom of the transformation domain delineates project execution work from the deployment work. Our remit is not only what is happening in one of these areas. Our remit is what is happening in all of these areas. In general people work within these areas and in most Enterprises these people try to improve what they do (if they are allowed) and how they do it. This is a laudable thing to do, however, no one is looking at the whole cascade and ensuring that the whole cascade is effective and efficient. The parts are being optimised at the expense of the whole. POET provides the basis for Senior Management to address optimising the whole of Transformation, for it is the output of the whole that most important rather than the output

142 - Artefacts of each Level - this in fact, may mean the de-optimisation of some or all of the parts. For this reason, everything in POET applies equally to all Levels of the Transformation cascade and is the unifying holistic and coherent context in which all Transformation work is performed.

Artefacts

In terms of naming these levels there are four fundamentals (note that all of this information can exist in Current, Intermediate(s) and Target(s) states: ♦ BA - Business Architecture (noun) consists of information representing: ♦ Things outside the Enterprise (e.g. The Market, Legislation, Competitors, Partners, Shareholders, Suppliers, Customers, etc) ♦ Business Models – How this Enterprise creates value . ♦ Business Capability Models – What Capabilities are required. ♦ Business Motivation Models – What motivates the Enterprise. ♦ EA - Enterprise Architecture (noun) consists of information representing: ♦ Operating Models – Overall structure required to provide the Capabilities. ♦ Roadmap Models – The projects and programs required to effect the change required to implement the Operating model. ♦ SA - Solution Architecture (noun) consists of information representing: ♦ Logical Designs – High level solutions to business problems required to deliver the Roadmap. ♦ EE - Enterprise Engineering (noun) consists of information representing: ♦ Physical Designs – Detailed designs to solve business problems required to deliver the Roadmap. ♦ Constructed Systems – Built things that solve business problems required to deliver the Roadmap. ♦ Live Configuration – The configuration of things that are operating in the Enterprise. Please see Methods > Overview > Phases > Basics for a description of the work being done to create information on each level.

Artefacts - 143

KEYPOINT:

Business Architecture, Enterprise Architecture and Solution

Architecture information are closely related.

ADOPTION:

Management: Ensure everyone in the

Enterprise understands which levels Engineering.

Questions to Ponder

♦ Do you agree with these Level boundaries? ♦ How does your Enterprise map onto them? ♦ Does everyone working within the Transformation domain understand where their artefacts they consume and produce, fit into the whole?

♦ If not, would there be a benefit if they did? ♦ What will you do to allow people to understand how the artefacts they consume and produce, fit into the whole, and what will you use? ♦ If so, how will you solve them?

Artefacts

are part of BA, EA, SA and Enterprise

144 - Artefacts Ontology Detail Str uctur al & Tr ans for mational

PR Artefacts

Here we see how the three fundamental ontologies from POET are woven together. On the right we show the Structural ontology - MAGIC. On the left the Transformational ontology - MAGMA. Down the middle the Ontology for the fundamental parts of all Enterprises - DOTS. Looking at the centre, it is the transformation domain we are interested in but we set that domain in the context of the Direction Domain above which drives it and the Operations domain below which it “delivers” into. (It should be noted however, that the transformation domain could also “deliver” into the Direction, Support or Transformation domains, but only the Operation domain is shown for clarity) The words in the boxes give some examples of the Structural and Transformational information you would expect to see at each level.

Artefacts - 145

KEYPOINT:

This is the complete map of information required for

Transformation to be executed in an

Effective, Efficient, Agile and Durable way.

ADOPTION:

Management: Map the Artefacts of MAGMA over the seven layers of

Transformation, to determine where the gaps and overlaps are.

Questions to Ponder

♦ In what way does your Enterprise consider Transformational as well as Structural

♦ ♦ ♦ ♦ ♦

models at all levels? What ontologies and meta-models are you using? How do they map to, and fit into, the POET Ontology? Are they any gaps or overlaps? If there are gaps and or overlaps, is it useful to know that? What will you do to fill the gaps and remove the overlaps?

Artefacts

Transformation to MAGIC and

146 - Artefacts Meta-models Tr ans for mational Pr inciples

PR ♦ Name - The name of the Principle.

Artefacts

Represents the essence of the Principle as well as being easy to remember.

♦ Statement - Succinctly and unambiguously communicates the fundamental rule.

For the most part, the principles statements for managing information are similar from one Enterprise to the next. It is vital that the principles statement be unambiguous. ♦ Rationale - Highlights the reasons why this Principle exists. Describing why this principle exists is important. If people understand why a principle exists, they are more likely to “buy-into-it” and adoption is greatly enhanced. Principles usually exist to solve a particular problem or to guide change in a particular fashion. ♦ Implications - Highlights the implications, both for the Business and IT, for operating the principle - in terms of resources, costs, and activities/tasks. Without implications, principles are just words that management can agree to but can then fall into disrepair due to the implications as they occur. Defining and then getting agreement on the implications is a key step in principle agreement and adoption. ♦ Metrics - Lists the measures that must be in place in order to monitor whether the positive results that each principle is meant to achieve are being achieved. It is imperative to understand and know whether the principles are having the desired effect or not and to what degree. The metrics given for each principle define how well that principle is achieving its desired result and not the number of Transformation Debt™ Agreements produced. Whilst counting the number provides a simple metric for all principles, this is akin to measuring the input rather than the output. E.g. Measuring how fast we are pumping water, not how much water we are

Artefacts - 147

Artefacts

pumping. For this reason, these metrics measure the desired outputs of each principle. â&#x2122;Ś Tasks - Lists the tasks that must be executed to be able to operate the Principle. If the associated tasks for a principle are not undertaken, it will be impossible to utilise and therefore gain the benefit from that principle.

148 - Artefacts

KEYPOINT:

The purpose of a Transformation Debt™ Agreement is to expose Transformation Debt™.

ADOPTION:

EA Project Team: Define the

Transformation Debt Agreement

OO entities, you need to be able to

Artefacts

record Transformation Debt™

Questions to Ponder

♦ What entities does your Enterprise use to model this information? ♦ Are they well known and consistently used from person to person? ♦ If not, what problems does that create and what can you do to alleviate them?

Artefacts - 149 Debt Agr eement

PR Problem Type

The type of problem. (Cannot Comply / Insufficient or Inadequate Input)

Transformation Reference

The Program, Project or Initiative experiencing the problem

Governance Boundary

The governance level that is experiencing the problem. (Strategising-Roadmapping / Roadmapping-Solutioning / Solutioning-Elaboration / Elaboration-Construction / ConstructionTransitioning)

Reasons

A high level description of why this problem exists.

Transformational Impact

The general impact non-compliance will have on the Effectiveness, Efficiency, Agility and Durability of how the transformation is being performed.

Scope

The information that is causing the problem. Transformational (Motivation / Actions / Guidance / Measures / Assessment) or Structural (Methods / Artefacts / Guidance / Items / Culture)

Artefacts

Summary

150 - Artefacts Operational Impact

The general impact non-compliance will have on the Effectiveness, Efficiency, Agility and Durability of the result of the transformation.

PR Cost of Compliance

A summary (Capital, Revenue, People, Time, Scope, etc)

Cost of Non-Compliance

A summary (Capital, Revenue, People, Time, Scope, etc)

Cost of Remediation

A summary (Capital, Revenue, People, Time, Scope, etc)

Decision

The result of the decision. (Compliance / Non-Compliance)

Rationale

The reasons why the decision was taken

Capital Costs

What money (Capital) do you need that you do not have budget for?

Revenue Costs People

What money (Revenue) do you need that you do not have budget for? What People do you need that you cannot get access to?

What time is required that has not been budgeted for and how does that impact the project milestones?

Time Scope

What change in scope is required?

Process

What changes to the project plan are required? (tasks to be removed, changed or added)

Cost of Non-Compliance Description

A description of the issue.

Actions

How the issue will be resolved.

Costs

What it will cost us to deal with the issue or the impact of the Issue (Money (Capital/Revenue), People, Time, Scope, Reputation, Loss of Ability to Innovate, Reduced Agility, etc).

Issues

Artefacts

Cost of Compliance

A target date of when the issue will arise.

Owner

Who owns/is responsible for ensuring the Issue is resolved as specified.

Description

A description of the risk.

Effect

A description of the effect to the Enterprise if the risk occurs.

Proximity

An indication of how imminent the risk is to occurring (months).

Likelihood

Likelihood that the risk will occur. (Low, Medium, High).

Impact

An Indication of the impact to the business if the risk occurs. (Low, Medium, High).

Mitigating Actions

How the risk will be mitigated with respect to Likelihood and/or Impact.

Costs

What must be provided to mitigate the risk (Money (Capital/Revenue), People, Time, Scope).

Risks

Date

Target Date

A target date of when the remedial work will be undertaken by.

Owner

Who owns/is responsible for ensuring the Issue is resolved as specified.

Cost of Remediation Capital Costs

What money (Capital) will you need, to remove the issues and risks and be compliant, and how that will change (probably increase) over time?

Revenue Costs

What money (Revenue) will you need, to remove the issues and risks and be compliant, and how that will change (probably increase) over time?

People

What People will you need, to remove the issues and risks and be compliant, and how that will change (probably increase) over time?

Time

What tasks will you need to execute, to remove the issues and risks and be compliant, and they will change (probably increase) over time?

Process

What time will you need to remove the issues and risks and be compliant, and how that will change (probably increase) over time?

Artefacts

Artefacts - 151

152 - Artefacts

PR Artefacts

Artefacts - 153

KEYPOINT:

The purpose of a Transformation Debt™ Agreement is to expose Transformation Debt™.

ADOPTION:

EA Project Team: Define the

Transformation Debt Agreement

entities, you need to be able to

Questions to Ponder

Artefacts

record Transformation Debt™

Culture - 155

PR OO

This view shows how the various roles of Transformation map to the different phases of Transformation. The roles shown here may differ from the names used in your Enterprise. These are not hard and fast divisions of labour but will allow us to illustrate how the simple patterns tabled here, when repeated at each level, allow the whole to work together coherently. RACI is used here as a method of representing who is:

♦ Responsible – The people who actually do the work required. ♦ Accountable – The people who make sure the work is carried out correctly, ♦ Consulted – The people who are consulted and can contribute while the work is

being performed. ♦ Informed. – The people who are informed about the work being performed as it progresses.

This does not mean that one person cannot work at more than one level. If a person does work at more than one level, that person is performing two roles, but can only wear one hat at a time.

Culture

CULT URE

156 - Culture

There are three patterns here that make the whole cohesive, and each pattern guides what the A, C and I roles should be, based on the R role. As we shall see, these patterns allow use to make sure we have the right roles, doing the right things, at the right time. First, we choose which roles are primarily Responsible for the work in each phase, and show them on the diagram in green. We now wish to add to the diagram the roles that will be Accountable and when. To do this, we use:

♦ The A Pattern - If a role is Responsible for one phase, that role should be Accountable for the phase below.

And so we show them on the diagram in Red. Next, we need to decide which roles will be Consulted and when. To do this, we use:

♦ The C Pattern - If a role is Responsible for one phase, that role should be Consulted about the work happening, 1 phase above and 1 phase below.

And so we show them on the diagram in Blue. Note that Red Accountable roles are now a mixture of Accountable and Consulted (which makes perfect sense). You will also see that we have added extra Blue Consulted roles to the User (customer), as the Users/Customer role is a special roles that needs to be consulted at all stages. Finally, we need to decide which roles will be Informed and when. To do this we use:

♦ The I Pattern - If a role is Responsible for one phase, that role should be Informed about the work happening 2 phases above and 2 phases below.

And so we show them on the diagram in Grey. Towards the bottom of the diagram you will see we have added some more Grey Informed roles, as the Enterprise Architect and Solution Architect roles are special roles, that need to be kept aware of the completion and rollout of projects.

Culture

Culture - 157

KEYPOINT:

The Pragmatic Role and Phase

patterns are key to assigning RACI to roles.

ADOPTION:

Management: Apply the Role and

Phase patterns when assigning RACI

OO to Transformation roles.

Questions to Ponder

♦ Does your Enterprise have a pattern for Accountability and Responsibility, that

enables the whole of the Transformation cascade to work together coherently?

♦ Does your Enterprise have a pattern for Consulting and Informing people, that Enterprise defines along with their RACI mappings?

Culture

enables the whole of the Transformation cascade to work together coherently?

♦ What would the diagram look like if you overlaid the people and roles that your

Guidance - 159

PR OO F

Guidance

GUI DAN CE

160 - Guidance

KEYPOINT:

The Guidance section of PEAF

defines what information is used to

guide people in their decision making.

ADOPTION:

C-Suite: Instigate a review of the

Guidance used in the Enterprise’s EA

OO Capability, to determine if their maturity is appropriate.

Questions to Ponder

♦ ♦ ♦ ♦ ♦

With respect to your Enterprises EA capability, what Guidance is used? Is the Guidance documented? Understood? Is it fit for purpose? Is it used? All the time? Only when it suits? Which part of the Guidance is Good? Why? Bad? Why?

Guidance

Guidance - 161 Pr inciples Over view

PR F

Guidance

There are two types of Principles. Best Practice Principles are the type that PEAF provides, which apply to the majority of Enterprises. The other type, are born from your Enterprises Strategy and its resulting Enterprise Transformation Strategy. The purpose of these principles is not to constrain, but to provide a broad cultural framework in which work will be carried out. As work progresses, these principles should be augmented with principles arising from considering the Enterprise Strategy Model.

162 - Guidance

KEYPOINT:

Principles come from Best Practice and your Enterprise's Strategy.

ADOPTION:

EA Project Team: Create Principles from Best Practice and your Enterprise Strategy.

Questions to Ponder

♦ What Best Practice Principles does your Enterprise operate? ♦ What Enterprise specific Principles does your Enterprise operate?

Guidance

Guidance - 163 Types

PR Most people think of principles in terms of Business, Data, Application and Technology – or some other similar categorisation. Pragmatic considers principles from a more Pragmatic perspective. We use MAGIC as a primary categorisation approach. Since the Guidance part of MAGIC is where the Principles sit, Guidance is not listed itself, as a category. In addition, we can also consider principles in terms of those which guide outcomes or What we want to achieve (Ends), or those that guide how the outcomes are achieved or How we are doing it (Means). We Therefore have 8 types of principles:

♦ How (we transform)

♦ Principles that guide how we transform (Methods). ♦ Principles that guide the things that are consumed and produced (Artefacts a lot of which is data) as we transform.

♦ Principles that guide people as we transform. ♦ Principles that guide the IT and other technologies we use (Items) as we transform.

Although principles can be categorised, some apply universally, namely:

Guidance

♦ What (we deliver) ♦ Principles that guide the Methods we deliver. ♦ Principles that guide the Artefacts (a lot of which is data) we deliver. ♦ Principles that guide how the people we deliver to (Culture). ♦ Principles that guide the IT and other technologies we deliver (Items).

164 - Guidance Universal Principles

Apply Principles Universally

We apply principles to all parts of the Enterprise.

Rationale:

♦ If parts of the Enterprise are exempt from these principles, this will undermine and reduce the benefits gained to an unacceptable level.

Implications:

♦ Parts of the Enterprise may react negatively and resist the removal of the “flexibility” to pick and choose which principles to adopt.

♦ All change initiatives will be reviewed for their compliance with the principles. ♦ An unresolved conflict with a principle will be resolved by issuing a Transformation Debt™ Agreement (TDA) which will then be analysed, costed and managed. ♦ Any deviation from these principles will be documented and managed as Transformation Debt™ Agreements (TDAs).

Metrics:

Raw: % of Initiatives that have been examined for compliance with the principles. Raw: Per project: Number of TDAs issued Raw: Per project: Number of TDA issues. Raw: Per project: Total Cost of TDA issues. Raw: Per project: Number of TDA risks Raw: Per project: Total impact cost of TDA risks Raw: Per project: Number TDAs avoided Derived: Total: Number of live TDAs Derived: Total: Number of TDAs issued Derived: Total: Number of TDAs closed Derived: Total: Number of TDAs issues Derived: Total: Total Cost of TDAs issues Derived: Total: Number of TDA risks Derived: Total: Total impact cost of TDAs risks Derived: Total: Number TDAs avoided (At which level)

♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦

Enterprise Compliance Rationale:

♦ The Enterprise is not viable unless it complies with appropriate laws and regulations. Implications:

Guidance

We comply with all relevant laws, policies and regulations.

♦ A programme of training is required to make appropriate people aware of

appropriate laws, policies and regulation and when, where and how to apply them. ♦ Non-Functional Requirements need to identify the laws, polices and regulations (internal and external) that solutions must comply with.

Guidance - 165 Metrics:

♦ Raw: % of systems which have been formerly reviewed and deemed compliant.

Enterprise Continuity

We maintain appropriate levels of Enterprise Continuity.

Rationale:

♦ The impact to the Enterprise if it is unable to conduct its business is not only

measured in terms of lost revenue and wasted employee time, but can also have an impact on the Enterprise’s reputation with its suppliers and its customers. ♦ The impact of any disruption can continue long after the actual disruption has been corrected.

Implications:

♦ The component parts of the Enterprise and the MAGIC they use must be assessed in

♦

Metrics:

♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦

♦ ♦

Raw: Existence of a BC Risk Log. Raw: Number of open risks. Raw: % of risks with mitigation tasks. Raw: % of mitigation tasks planned for action. Raw: % of mitigation tasks in progress. Raw: % of mitigation tasks completed. Raw: Existence of a BC test plan. Raw: Execution of the BC test plan every 12 months Raw: % of applications that have been assigned a business criticality. Raw: % of applications that meet the level of business criticality assigned.

Guidance

♦

terms of the importance and criticality to the business. The level of business continuity to be put in place is dependent upon the importance or criticality to the business. The Business continuity plan and measures put in place will be adequately tested periodically. The Business continuity plan will be reviewed periodically. Appropriate levels of availability, disaster recovery, and security for all systems (not just IT systems) will be addressed in their design.

166 - Guidance

KEYPOINT:

Don't think in terms of Business and IT principles. Use MAGIC to categorise them.

ADOPTION:

EA Project Team: Categorise Principles using MAGIC.

Questions to Ponder

♦ What categories does your Enterprise use to group related principles? ♦ Do your categories cover the Methods and Artefacts and Culture and Environment used for Transformation?

♦ If not, what problems does that create and what can you do to alleviate them?

Guidance

Guidance - 167 WHAT We Want t o Achieve

PR Here we see a set of Principles related to WHAT we want to achieve (Ends). It is interesting to note that the Cultural Principles are blank. This is because most Transformation/Change that happens within an Enterprise does not change or guide the Culture. If this sounds like a bad thing to you, you are not alone! In Pragmatic 's opinion, while Cultural change is easily the most difficult thing to effect, it is usually the thing that has the most profound impact, not only in terms of its outcome, but also in terms of whether the outcome is positive or negative. Interestingly, it seems to be true that effecting a bad culture is much more easily done than effecting a good culture!

Method Principles

Reduce Manual Processes

We reduce and remove manual processes - but only when there is a clear business reason for doing so. â&#x2122;Ś The benefit of manual processes are that they are immeasurably flexible, can be easily

changed (on a daily basis if necessary) with little cost and without any of the problems associated with changing electronic software systems. This is the reason, manual processes tend to grow and grow through an Enterprise. However, manual processes require people to operate them, office space, desks, HR, or not scalable, etc, etc Therefore straight through processing (STP) is a valid target aim. â&#x2122;Ś There are places where manual processes should and/or must be used as systems and technology cannot currently replace them or they are more cost effective.

Guidance

Rationale:

168 - Guidance ♦ Cost is only one aspect though, people are good at non-repetitive highly complex tasks rather than repetitive simple tasks and so it makes sense to use one of the most important assets of the company (i.e. its people) in the best way possible.

PR Implications:

♦ People rarely ask the question “why do you do it that way”. Even if they do, the usual answer is “because that’s the way we’ve always done it”. It takes a determined and concentrated effort to research, investigate and identify processes that can be reduced or removed. ♦ People can believe that removing or reducing manual processes will make them less worthwhile to the company, give them less job satisfaction and/or could ultimately lead to loss of jobs. This is a misnomer in that what usually happens is that people feel more worthwhile and get better job satisfaction and job losses do not materialise as people are freed up to do more productive and less repetitive work. ♦ Usually the people best suited to spot where improvements could be made are the people on the coal face who have to follow and work within these processes on a day to day basis.

Metrics:

♦ ♦ ♦ ♦

Raw: The number of manual, semi-automatic and automatic process. Raw: The cost of manual, semi-automatic and automatic process. Derived: The total cost of manual, semi-automatic and automatic process. Derived: The ratio of the number of manual to semi-automatic to automatic processes. ♦ Derived: The ratio of the cost of manual to semi-automatic to automatic processes.

Consolidate

We consider consolidation at all times and we proactively drive towards reducing proliferation and complexity. Rationale:

♦ Anything which is complex costs more to produce and maintain. ♦ This increase in cost tends to increase in an exponential manner - initially not having much impact on costs and timescales, but as complexity grows there comes a point whereby costs become prohibitive. ♦ Consolidation is concerned across the board e.g. Processes, Applications, Vendors, Hardware, Software, Services.

♦ Consolidation is not something that happens overnight and usually consolidation

projects do not make economic sense. ♦ Consolidation should become part of all projects remits and the Business should provide the resources to effect consolidation as opportunities arise. ♦ Consolidation should become part of the Roadmapping phase, allowing for pieces of consolidation work to be included in the project portfolio. Metrics:

Guidance

Implications:

Guidance - 169 ♦ Raw: % of programmes, projects and initiatives that include a consolidation component.

Open Integration

We view and manage the integration of IT systems as a strategic capability separate to each individual system and project, rather than something that is thought of as part of each individual system.

Rationale:

♦ One of the key capabilities to IT successfully supporting the Business is Integration. ♦ Integration is the glue and the key to flexibility - Open, configurable, scalable,

resilient, secure. ♦ Integration is the cornerstone and backbone of any agile Enterprise in this world of constant change (business model’s technologies, environmental, regulatory, commercial, etc). ♦ Integration should not be thought of as something secondary that just connects various things, it needs to be thought of as the heart of IT and the Business, connecting packaged applications with legacy, bespoke and external systems.

Implications:

♦ In the same way as Enterprises have teams responsible for networks, servers and

databases the Enterprise also should have an integration team which creates new integrations or replaces old integrations and is driven by the Business and project need. ♦ In this way integration is considered, guided and architected on a strategic and infrastructural level and implementation is carried out on a system by system or interface by interface level. ♦ This approach removes the problems associated with a “big bang” approach, but still allows a big picture to be the driving force behind individual integration work carried out as part of other projects. Systems, parts of the Enterprise and individual links can be brought into this systemic integration environment gradually as time, money and business pressures dictate. Metrics:

used.

Guidance

♦ Raw: An integration group exists within IT with its own budget. ♦ Raw: Number of shared integration points, systems, technologies, interfaces being

170 - Guidance Artefact Principles

Treat Data as Assets

We accept that Data are assets that have value to the Enterprise.

Rationale:

♦ Data is the blood of most Enterprises, and its value can be huge. ♦ Data, like anything else of value, needs to be maintained if its use is to be preserved. ♦ Collecting and storing data can be very time consuming and resource intensive, and so to not maintain data (so it can be used in the future) is extremely inefficient.

♦ Data exists in two fundamental categories: ♦ Production: These data are the product (for a data based Enterprise - like a bank). They are the crown jewels of the Enterprise. ♦ Business: These data aids decision-making. Unless this data is accurate, current and available when it is needed bad decisions can be made with far reaching consequences to the entire Enterprise.

Implications:

♦ Each major data entity will have an associated data steward assigned responsible for

♦ ♦

Metrics:

♦ ♦ ♦ ♦ ♦

♦ ♦

managing the data. Data Stewards are responsible for the quality of the data they are responsible for. Procedures must be created to monitor data quality and correct any errors. A set of Data Management Policies are required. A Metadata repository is required. Common tools are required for creating, maintaining and managing data. Raw: Does a Business Data Model exist? Raw: % that have an assigned business data steward. Raw: % that have defined data quality procedures. Raw: Per Entity: Data Quality score. Derived: Total Data Quality score.

Do Not Duplicate Data Rationale:

♦ The Enterprise holds a large amount of data, but it is stored in multiple physical

databases. ♦ Duplication of data costs money in effort to maintain it and to synchronise its copies. ♦ Duplication means there are many versions of “the truth” making decision making very haphazard. ♦ Duplication adds un-needed complexity. Implications:

Guidance

We ensure that Data are shared across organisational and technical boundaries.

Guidance - 171 ♦ Data Sharing and Data Security can be contradictory - It is important to recognise

that data stored in the same place can have different security requirements. ♦ A set of Data Management Policies are required. ♦ A Metadata repository is required. ♦ Common tools are required for creating, maintaining and managing data.

Metrics:

♦ Raw: Do Data Management Polices and Standards exist? ♦ Metrics for measuring the adherence and effectiveness of these are defined in the associated policies/standards.

Make Data Accessible

We ensure that people have access to the data required to perform their duties.

Rationale:

♦ Data which is accessible increases efficiency and effective decision making. ♦ Access to data must be considered for an Enterprise wide perspective otherwise data silos are likely to grow.

Implications:

♦ Different levels of access need to be defined for all data entities - Create, Read, ♦ ♦ ♦ ♦

Update, Delete. An Enterprise wide access framework is required to manage access based on Enterprise role rather than individual persons. A set of Data Management Policies are required. A Metadata repository is required. Common tools are required for creating, maintaining and managing data.

Metrics:

♦ ♦ ♦ ♦

Raw: A Data Accessibility user survey has been created. Raw: % of entities that have had a Data Accessibility user survey carried out. Raw: % Data Accessibility score for each entity. Derived: Total % Data Accessibility.

We define and use Data consistently. Rationale:

♦ For the Enterprise to come together and work in a partnership there must be a

Implications:

common and well understood definition for all the important data entities within the Enterprise.

♦ A Metadata repository is required.

Guidance

Define Data

172 - Guidance ♦ Whenever there is disagreement over the use of an existing definition or when new definitions are required the Architecture Review Board will ensure consistency and completeness.

PR Metrics:

♦ Raw: % complete Business Data Dictionary.

Secure Data

We protect Data from unauthorized use and disclosure.

Rationale:

♦ In the same way access to applications is controlled through role based security, so must access to data.

♦ It is all too easy to have an application provide elaborate security access control and restrictions but if the data that the application uses can be accessed directly in a relatively easy fashion then that data is not sufficiently protected. ♦ This is especially pertinent to integrations across Enterprise boundaries where different data in a data set may be considered differently in terms of security.

Implications:

♦ It is possible that to gain data security, data is physically separated into different

database. This may not be the optimal method of securing the data since it needlessly fragments the data and can cause maintenance issues. ♦ A Data security policy and standards are required. ♦ Existing data sources will need assessing and evaluating. ♦ Like applications, security must be designed into data entities and attributes at design time, not by adding it later. Metrics:

♦ Raw: % of Databases that have had a security assessment. ♦ Raw: Do Best Practice Data Security Policies and Standards exist? ♦ Metrics for measuring the adherence and effectiveness of these are defined in the associated policies/standards.

Guidance

Guidance - 173 Items (Technology) Principles

Ease-of-Use

We ensure that technology is easy to use. The underlying technology is transparent to users, so they can concentrate on tasks at hand.

Rationale:

♦ The more a user has to understand the underlying technology, the less productive that user is.

♦ Ease-of-use is a positive incentive for use of applications. It encourages users to work within the integrated information environment instead of developing isolated systems to accomplish the task outside of the Enterprise’s integrated information environment. ♦ Most of the knowledge required to operate one system will be similar to others therefore training is kept to a minimum, and the risk of using a system improperly is reduced. ♦ Using different applications should be as intuitive as driving different cars.

Implications:

♦ Applications will be required to have a common "look and feel" and support

ergonomic requirements. Hence, the common look and feel standard must be designed and usability test criteria must be developed. ♦ Guidelines for user interfaces should not be constrained by narrow assumptions about user location, language, systems training, or physical capability. Factors such as linguistics, customer physical infirmities (visual acuity, ability to use keyboard/mouse), and proficiency in the use of technology have broad ramifications in determining the ease-of-use of an application. ♦ It is accepted that increased use of COTS applications may mean this principle is not met as much as would be if purely bespoke applications are used. Metrics:

♦ Raw: An Ease-Of-Use satisfaction survey has been created. ♦ Raw: % of services/applications that have had an Ease-Of-Use satisfaction survey carried out.

Common Use

Rationale:

We ensure that technology that can support and/or be reused by multiple parts of the Enterprise are favoured over those that are only point solutions. ♦ Technology that only solve one problem or support one part of the Enterprise

exacerbate the proliferation of Technology that cause increased cost and complexity.

Implications:

Guidance

♦ Raw % Ease-Of-Use satisfaction score for each service/application. ♦ Derived: Total % Ease-Of-Use satisfaction.

174 - Guidance ♦ Existing point solutions may need to be replaced. ♦ Careful management of projects is required to identify possible synergies as early as

possible. ♦ Projects may need extra investment to allow their scope to be expanded in order to procure a broader application or service.

Metrics:

♦ Raw: Number of applications providing essentially the same functionality or services

i3. Security

We ensure that technology will be secured from unauthorized access.

Rationale:

♦ Malicious intrusion, viruses, and terrorism increasingly threaten the Enterprise’s

systems. ♦ The Enterprise has a duty to maintain its customer’s and supplier’s trust in its systems from unauthorized access and to preserve confidentiality where required. ♦ Secure systems ensure the continuity of the Enterprise’s business.

♦ ♦ ♦ ♦ ♦

Implications:

Systems must be secured with application security best practices. Application security assessments being conducted on a regular basis. Must identify, publish, and keep applicable policies current. Security must enable not impede business. Security must be designed into the Enterprise, its structure, processes and systems from the beginning. Adding it later seriously compromises quality and/or seriously increases costs.

Metrics:

♦ Raw: % of Systems, Applications, Departments that have had a security assessment. ♦ Raw: Do Best Practice Application Security Policies and Standards exist? ♦ Metrics for measuring the adherence and effectiveness of these are defined in the associated policies/standards.

Minimise Customisation Rationale:

♦ One of the benefits of buying a COTS package is the reduced maintenance burden

Guidance

We only allow the customisation of COTS packages when there is a clear and burning business advantage for doing so.

and the easy acceptance of updates from the manufacturer. ♦ The more a COTS package is Customised (as opposed to Configured) the more these basic benefits are lost. ♦ A heavily customised COTS package effectively becomes a built application. Implications:

Guidance - 175 ♦ The Business may have to forego some functionality and settle for “what the product ♦

can do out-of-the-box” rather than have all their requirements fully satisfied.

PR Metrics:

♦ Raw: Number of Customisations done.

Replace Legacy Appropriately We will replace legacy systems only when there is a valid business case for doing so.

Rationale:

♦ Legacy systems are not inherently bad and a wholesale approach to replace them

with the latest technology will be avoided. ♦ Replacement of existing/legacy systems will only be done if there is a sound value proposition to do so and if the risks have been properly evaluated.

Implications:

♦ Legacy systems will continue to exist in the Enterprise and it should be noted that

Metrics:

this position will not change much over time. ♦ Only the specifics of which systems are legacy will change. i.e. the systems introduced today will be deemed to be “legacy” at some point in the future.

♦ Raw: Number of legacy systems in place. ♦ Raw: A legacy system evaluation framework exists ♦ Raw: % of legacy systems that have been evaluated.

Increase Independence

We ensure that applications and services should be independent of specific technologies. Rationale:

some technologies are favoured over others due to security concerns, scalability, costs, or other important drivers. ♦ Applications which are independent of the technologies they require to operate provide the business with an increased level of flexibility to change technologies when required based on business drivers. Implications:

♦ Technology Standards are required. ♦ This principle may be difficult to comply with because Commercial Off-The-Shelf (COTS) applications can tend to be platform dependent.

Metrics:

Guidance

♦ Technologies (Hardware and software) change and evolve over time. As time passes

176 - Guidance ♦ Raw: For each application and service, the number of alternative Technologies that

could be used. ♦ Derived: Average number of alternative Technologies per application/service.

Reduce Diversity

We aim to reduce the number of technologies wherever possible.

Rationale:

♦ The higher the number of technologies used the higher the cost of supporting and

maintaining them. ♦ If many technologies are in use, it becomes a necessity for IT resources to have to concentrate on a subset of technologies thereby reducing the flexibility of the workforce.

Implications:

♦ Technology Standards are required. ♦ This principle may be difficult to comply with because Commercial Off-The-Shelf (COTS) applications can tend to increase technology diversity.

Metrics:

♦ Raw: For each Technology, the number of different types in use. ♦ Derived: Average number of instances per Technology.

Increase Interoperability

We aim to increase the level of interoperability between disparate technologies wherever possible. Rationale:

♦ Where disparate technologies have to be utilised, interoperability provides the best way of enabling them to work together coherently.

♦ Interoperability reduces the cost of integration and maintenance. Implications:

♦ Interoperability Standards are required. ♦ This principle may be difficult to comply with because Commercial Off-The-Shelf (COTS) applications may or may not adopt open standards.

♦ Raw: For each Technology, the number of different types in use. ♦ Derived: Average number of instances per Technology.

Guidance

Metrics:

Guidance - 177 Culture Principles

Guidance

178 - Guidance

KEYPOINT:

When categorising Principles, think in terms of those that guide WHAT we want to achieve (Ends).

ADOPTION:

EA Project Team: Create Principles that guide WHAT we want to

OO achieve (Ends).

Questions to Ponder

♦ Has your Enterprise defined principles that guide WHAT you want to achieve (Ends)? ♦ If not, what problems does that create and what can you do to alleviate them?

Guidance

Guidance - 179 HOW We Will Achieve It

PR Here we see a set of Principles related to HOW we effect Transformation (Means). It is interesting to note that the Items Principles are blank. This is because most Transformation/Change that happens within an Enterprise only considers the Items (Technology) that is being delivered, rather than the Items (Technology) being used to deliver them. If this sounds like a bad thing to you, you are not alone! In Pragmatic's opinion, Items (Technology) that are being delivered are always to the fore largely because a) delivering new or changed Items (Technology) is the purpose of many (IT) projects and b) there is no one Accountable for the Items (Technology) being used by Transformation. Thus, all focus is on the Items (Technology) being delivered rather than the Items (Technology) being used to deliver them.

Method Principles

We ensure we plan to work in a Strategic way in order to allow us to do work in a strategic way. Rationale:

â&#x2122;Ś Most companies tend to find themselves in a fire fighting spiral, where problems and priorities are focussed on just keeping the Business running. â&#x2122;Ś This is a spiral because work that should be done to head off the next potential problem or panic is not done resulting in the potential problem becoming a real problem to such an extent that it makes it onto the panic sheet. â&#x2122;Ś If you do not plan to do any strategic work, you will never do any strategic work.

Guidance

Plan Ahead and Organise

180 - Guidance Implications:

♦ The firefighting spiral needs to be broken and the only way to do that is to plan

ahead and organise work not only based on short term objectives but also from the point of view or stopping things becoming a crisis in the future. ♦ Therefore, a proportion of budget and effort needs to be directed towards preventing things becoming a crisis in the future rather than exclusively performing crisis management and firefighting activities. ♦ Only by planning ahead will the crisis management spiral be broken.

Metrics:

♦ Raw: % of budget spent on strategic work.

Refactor Where Possible

We always consider refactoring and improvement whenever anything is changed.

Rationale:

♦ Improving something whilst already “having your fingers on it” costs a lot less in

Implications:

terms of time and resources than doing so at a later time. ♦ If you don’t improve things as a normal part of “work” (continuous improvement) they will potentially never be improved.

♦ Requires time and resources. ♦ People need an environment that allows then to refactor and improve things “as they go”

♦ Management needs to create that environment. Metrics:

♦ Raw: Amount of refactoring work undertaken.

Manage Transformation Debt™ Value

We expose, document, and manage Transformation Debt™ Value (TDV). Rationale:

♦ Transformation Debt™ exists. It is created every day. This principle recognises its

Guidance

existence and therefore the requirement to expose and manage it. ♦ Transformation Debt™ incurs interest. This interest is paid as long as the interim change (debt) exists in the form of maintenance and other costs that would not exist otherwise. Remedial change is like paying off a (portion of a) loan and as such reduces overall debt and subsequent interest. ♦ Transformation Debt™ is not inherently a bad thing. It is an important tool for an Enterprise to achieve its goals and objectives. Like financial debt, Transformation Debt™ needs to be visible & managed. If Debt is not managed it will inevitably only increase. ♦ Like any debt, Transformation Debt™ is bad when you:

Guidance - 181 Don’t know you are incurring it. Don’t know how you will pay off the debt. Don’t know the interest rate. Don’t know how long you will have to pay interest for.

♦ ♦ ♦ ♦

Implications:

♦ Changes are required in process and culture to enable identification of

Transformation Debt™ to be an acceptable and appropriate thing to do. ♦ A Strategic Investment Board (with budget) is required to sit above all projects and programs.

Metrics:

♦ Raw: The Transformation Debt™ (cost of the issues and risks created) of each programme, project and initiative. ♦ Derived: The total cost of Transformation Debt™.

Manage Transformation Debt™ Ratio We classify all change in terms of the Transformation Debt™ Ratio (TDR - Strategic vs Tactical vs Remedial)

Rationale:

♦ ♦ ♦

♦ ♦ ♦ ♦

be. (May or may not also satisfy a short term need.) Tactical: Changes that satisfy a short term need, but does not take you from where you are to where you want to be in the most effective and/or efficient way. Remedial: Changes that correct previous Tactical change. This remedial change will also consist of Strategic and Tactical change. All projects have a Business and a Technical change component. The Transformation Debt Ratio™ for each can be very different. E.g. The Business change component of an initiative may be 90:10:0, whereas the IT change component of the same initiative may be 10:30:60. Strategic changes do not increase Transformation Debt™ but could reduce it as a side effect. Tactical changes, by definition, increase Transformation Debt™. Remedial changes decreases Transformation Debt™. When budgets and timescales are constrained, the bias is more likely to be towards Interim change (taking on more debt) whereas when budgets and timescales are more relaxed the bias is more likely to be towards Strategic and Remedial change (paying off the debt).

Implications:

♦ All Programmes, Projects and Initiatives need to be classified in terms of Strategic vs

Interim vs Remedial ratios, for the Business change component and for the IT change component. ♦ It should be also noted that the Transformation Debt Ratio™ is a ratio of how change is effected not why. E.g. Change may be driven by a strategic imperative but if

Guidance

♦ Strategic: Changes that take you directly from where you are to where you want to

182 - Guidance the way that change is effected is interim then the Debt Ratio would be 0:100:0 and not 100:0:0

Metrics:

♦ Raw: The % of programmes, projects and initiatives that have the Transformation Debt Ratio™ identified. ♦ Derived: The total %’s of Strategic vs Interim vs Remedial ratios (Business & IT)

Be Architecture Centric

We adopt Architecture Best Practice

Rationale:

♦ Architecture is about structure, reuse, cost reduction and flexibility. ♦ An architecture centric approach to delivering services to the Business is a widely accepted and adopted best practice for success.

♦ Currently there are limited architecture resources, groups, documentation, ♦ ♦

♦

Implications:

♦

principles, policies, standards, governance. Work undertaken tends to be tactical rather than strategic in focus. IT systems are diverging in terms of technology and applications and point solutions are proliferating. IT finds it difficult to provide a good service to the Business. This results in IT being viewed as a cost rather than a positive value. IT has a tactical reactive focus rather than a proactive strategic focus. This will allow the Enterprise to be in control of its IT capabilities and fully understand how they are related to each other and the Business. Projects produce good quality, fit for purpose solutions.

♦ Define an architecture framework. ♦ Introduce/improve and integrate Enterprise, Solution and Technical architecture processes and products. ♦ Introduce a Best Practice project management approach. ♦ Introduce Business/IT planning and Project Portfolio Management. Metrics:

♦ Utilise the Metrics (part of the Maturity Model) defined in the Adoption section of the Framework you have adopted.

Be Service Oriented Rationale:

Guidance

We adopt a service based approach instead of an application based approach. ♦ The traditional application based approach to providing functionality does not

promote reuse and flexibility at the Business level. i.e. it is difficult to rearrange and re-connect applications as business needs change.

Guidance - 183 ♦ Adopting a Service based approach to providing services to the Business will increase Business agility enabling it to respond faster and more efficiently to internal and external change .

PR Implications:

♦ We need to identify and provide reusable business level services that can be linked together and easily changed to increase business agility.

♦ A Service based approach is not a product that can be bought and installed. It is more a way of thinking and structuring things. This can be difficult to grasp although the benefits can be substantial. ♦ Vendors of packaged applications (COTS) may not be as mature as the Enterprise would like and may require work to define and wrap various functionality as services.

Metrics:

♦ ♦ ♦ ♦ ♦ ♦

Raw: Number of internal facing Functional Services defined. Raw: Number of external facing Functional Services defined. Raw: Number of internal facing Data Services defined. Raw: Number of external facing Data Services defined. Raw: % of programmes, projects and initiatives which are defining new services. Raw: % of programmes, projects and initiatives which are using existing services.

Avoid Under/Over Engineering

We will not under or over engineer solutions. Rationale:

♦ If solutions are under engineered there is a danger that Enterprise will not reap the

benefits associated with an architecturally driven approach i.e. reuse and flexibility is not free and has to be designed appropriately into solutions. ♦ If solutions are over engineered there is a danger that projects and systems can drown in the drive to achieve the perfect solution or the increased costs and timescales do not warrant the perceived benefit created. ♦ A balance needs to be achieved. Implications:

how that functionality is provided need to be considered as a whole in the context of the four EA Strategies (aka the spinning plates of Cost, Flexibility, Risk and Quality). ♦ The key to allow this to occur is the three party partnership behind the successful adherence to this principle, represented by: ♦ Project Manager - Cost & timescales. ♦ Architect - How the solution is engineered. ♦ Business Analyst - What functionality the solution contains. ♦ These roles should exist as a true partnership with no one partner being able to overrule the other and with each role being equally concerned and mindful of the 4 EA Goals. Where common agreement cannot be reached, this principle will be violated and the Transformation Debt™ Agreement process will begin.

Guidance

♦ Costs, timescales, how the solution is constructed, the functionality it provides and

184 - Guidance ♦ This will require considerable discussion and agreement to break down the usual

“The Project Manager rules the roost” mentality and to provide the environment where this important cultural change can happen.

PR Metrics:

♦ Survey of PM’s, BA’s and TA’s - “Do you think that PM’s, BA’s and TA’s are working together as an equal partnership or does one role seem to have more power than the other? If so which ones?” ♦ The number of answers where one role is shown to have more ‘power’ than the others.

Reuse

We consider and favour the reuse of existing people, processes, locations and technology over buying, adopting or creating anything new.

Rationale:

♦ Reuse is the key to low costs. ♦ Must be balanced against increase complexity that reuse introduces.

Implications:

♦ A repository of what exists and the relationships between them needs to be

maintained. ♦ This can be difficult and can be viewed as introducing complexity, risk and cost. However, if these risks and costs are weighed against the longer term benefits and costs it usually is in the best interests of the Business to reuse wherever possible. ♦ Reuse of standard things is favoured over reuse of bespoke things. ♦ Reuse of bespoke things should only occur when there is a compelling business expediency to do so. Metrics:

♦ Raw: The number of times things are reused.

Buy (for reuse) Before Build

We buy Services (for reuse) before buying packages (for reuse) before building (for reuse) . ♦ There is no reason to re-invent the wheel. ♦ Where possible, the Enterprise should lever existing and future functionality offered

Guidance

Rationale:

by IT companies instead of bespoking IT.

♦ Please see the sub principles for more detailed Rationale. Implications:

Guidance - 185 ♦ Buying (for reuse) means that whenever an individual programme, project or initiative

♦

identifies the need to purchase, the requirements and the eventual decision on what is purchased is considered from a more holistic strategic perspective. The individual programme, project or initiative may encounter a higher cost (both in terms of evaluation as well as licensing and ongoing cost) than it would have if it only considered its own scope. For selection, the 80/20 rule applies, favouring Services/Packages which satisfy 80% or more of requirements as opposed to a built Services/Package which satisfies near to 100%. A best of breed approach should generally be followed. However, the numbers of existing vendors, services and packages already in use should be taken into account. i.e. One solution may not be best in breed but is favoured because the vendor is already being used to provide other services or packages. Vendors supplying other Services/Packages which may be of interest at a later time should be favoured. Services/Packages that have the capacity to be extended or additional modules purchased should be favoured. Please see the sub principles for more detailed Implications.

♦ ♦

We buy Services (for reuse) before Building.

Rationale:

♦ Externally supplied services managed through SLAs tend to be cheaper and make an Enterprise more agile. ♦ This should be tempered by the commodity vs specialist nature of the system being sourced and the security, resilience of the service and the company providing it. ♦ Services that can also provide programmatic access (e.g. using web services technologies) should be favoured over those which provide a purely user interface.

Implications:

♦ Vendors supplying other services which may be of interest at a later time should be favoured. Services that have the capacity to be extended or additional modules purchased should be favoured. ♦ Procurement processes may have to change radically to enable this. ♦ Integration aspects need to be carefully considered.

We buy Packages (for reuse) before Building. Rationale:

than bespoke applications. ♦ However, this should be tempered by the commodity vs specialist nature of the system being sourced.

Implications:

♦ Vendors supplying other capabilities which may be of interest at a later time should be favoured. Systems that have the capacity to be extended or additional modules purchased should be favoured.

We Build (for reuse).

Guidance

♦ Packaged applications tend to be far cheaper to produce and to support and maintain

186 - Guidance Rationale:

♦ Bespoke development tends to be the most costly option in terms of up-front costs

and support and maintenance costs. ♦ Bespoke developments tend also to be the most risky for non-software house based companies. ♦ Bespoke development can produce significant competitive advantage and so tends to be only considered for USP type functionality or when the functionality required does not exist in the market place. If this is the case, it may be prudent to consider a partnership with a software house to jointly develop a new package that can subsequently be sold.

Implications:

♦ Where a requirement cannot be satisfied by a COTS system or where the ♦ ♦ ♦

Metrics:

♦ ♦ ♦ ♦

Raw: The number of COTS services in use. Raw: The number of COTS packages in use. Raw: The number of bespoke systems in use. Derived: The ratio of COTS Service to COTS Package to Bespoke.

Guidance

♦

requirement for competitive advantages dictates a build solution, a build should be adopted. The 80/20 rule applies regarding the scope and complexity of the solution. The system being built should (as much as practicable) allow for easy extension and additions, and also allow the potential to be re-used by other parts of the Business. A generic and/or data driven application that can easily be extended and re-used should be favoured. Should adhere to defined quality standards. For example the system should be fully documented to enable it to be supported or changed up by other developers at a later date.

Guidance - 187 Artefact Principles

Artefacts Must Be Complete, Sufficient and Comprehensible We ensure that all artefacts used are of the quantity, quality and format required by the person using the artefact.

Rationale:

♦ Artefacts are used by one process to perform an action. ♦ Artefacts used by a process that are not of the required quantity, quality and format, greatly increases the risk of that process producing bad outputs.

♦ If those artefacts are decisions, bad decisions can end up being piled upon bad decisions.

Implications:

♦ Whether an artefact is Complete, Sufficient and Comprehensible is determined by the person who will use the artefact not by the person that produces the artefact.

Metrics:

♦ Raw: Number of artefacts labelled “satisfactory” by those that use them. ♦ Raw: Number of artefacts labelled “unsatisfactory” by those that use them. ♦ Derived: % of “satisfactory” artefacts.

Structured Modelling

We hold and manage information in structured rather than unstructured forms. Rationale:

reused, related to information it depends on or related to information that depends on it. ♦ Reducing the ability to relate information and see a clear line of sight between it, greatly increases the risk of making bad decisions. ♦ If information is held in unstructured forms, there is a great risk that any problems it contains will not be seen and corrected until much later. ♦ Seeing problems much later than when problems are introduced greatly increases the risk of wasting resources and the risk of not achieving what was planned. Implications:

Metrics:

♦ Appropriate Tools and Processes will be required. ♦ It can take longer to create and work with information in structured forms. ♦ Increase time and resources will likely be required. ♦ Raw: Amount of information in use, stored in unstructured forms. ♦ Raw: Amount of information in use, stored in structured forms.

Guidance

♦ If information is held in unstructured forms, there is a great risk that it cannot be

188 - Guidance ♦ Derived: % of unstructured vs structured information in use.

Relationships & Traceability

We ensure that Information (Structural & Transformational) used for transforming the Enterprise is related.

Rationale:

♦ Relationships are the key to understanding the impact of change which enables informed decisions.

♦ IT consists of a large number of different things (e.g. applications, databases,

objectives, technologies, etc). ♦ In addition IT operates within a business context of different things (e.g. business processes, people, locations, requirements, objectives, etc). ♦ Whilst these things are important it is the relationships between them that allow the best decisions to be made and allow IT to make sure that what it does has concrete business value. (e.g. mapping Business Objectives to Requirements to Solutions, etc) ♦ The relationships allow impact analysis and the implications of decisions to be made clear.

Implications:

♦ A repository and various tools (EA Modelling, Requirements Analysis, Portfolio

Management, etc) are required to enable these different things and their relationships to be modelled effectively. ♦ There will be a learning curve to be able to use these tools. ♦ There will be a population curve while the information is initially loaded. Metrics:

♦ ♦ ♦ ♦ ♦

Raw: Is there an appropriate EA modelling tool in place? Raw: % of the Enterprise using the EA Model. Raw: % complete of the Strategy domain model. Raw: % complete of the Business domain model. Raw: % complete of the Technology domain model.

Have a Sound Business case

Rationale:

♦ All too often projects are initiated without a clear definition of the costs, benefits and therefore the true value of a proposition. ♦ Whilst costs and benefits are defined these values can often be “invented” to make the Business case stick and can also often miss the wider strategic and ongoing costs. Implications:

Guidance

We ensure that all projects are supported by a sound business case which addresses the total cost of ownership, plus any wider impacts on the Business and IT.

♦ There are no IT projects, there are only Business projects that have a mixture of IT Change and Business change.

Guidance - 189 ♦ All business cases need to articulate business benefits in business terms ♦ In order for ball park costs to be reasonably representative, a high level view of the

solution options and lifecycle costs must be produced at an architectural level. ♦ This view can be produced in a very short space of time, by engaging with architects and business analysts. If it is not possible to determine a broad brush set of options and representative costs, it means that the initial business case would be for an investigation/feasibility study of possible solutions and associated costs, rather than for the solution which would then be contained in a later business case.

Metrics:

OO F

Guidance

♦ Raw: % of programmes, projects and initiatives that have a business case. ♦ Raw: % of programmes, projects and initiatives that include solution options ♦ Raw: % of programmes, projects and initiatives that include lifecycle costs.

190 - Guidance Items (Technology) Principles

PR F

Guidance

Guidance - 191 Cultural Principles

Disagreement <> Confrontation

We ensure that any disagreement is taken as a positive opportunity for learning.

Rationale:

♦ In general, people can see disagreements as confrontations. ♦ In general people really hate confrontations and tend to do anything and everything

to avoid them. ♦ That does not mean that they do not tell anyone, it just means they tell the wrong people. ♦ Allowing disagreements, rather than seeing them as confrontations to be avoided, allows people to understand and learn from one another and get to the bottom of any disagreement, instead of burying them. ♦ If we bury disagreements, they will only rear their head later where more damage will have been done.

Implications:

♦ Hearing disagreement can be challenging and threatening to some people. ♦ Everyone, regardless of their pay grade will be impacted. ♦ Some people may not like this principle if they have in the past, are used to being able to ignore anyone who disagrees with them.

Metrics:

♦ Raw: The number of times “Because I said so” is used.

Explain Decisions

We ensure that “…because I said so” will never be used as the reason or rationale for any decision. Rationale:

Enterprise as a whole and to individuals. Allowing it shows people that there is no point in asking “why”. ♦ It promotes a good culture to make sure people understand why decisions are been taken. ♦ This does not mean that all people will be happy with all decisions. ♦ If people understand the reason for a decision, they will accept the decision more readily even if they do not agree with it.

Implications:

♦ It takes time and energy to explain reasons to people. ♦ Some people may not like this principle if they have in the past been used to saying “Because I said so”.

Guidance

♦ Allowing “because I said so” as a reason for decisions is deeply damaging to the

192 - Guidance ♦ This does not imply that every decision will be explained to every person. What it means is that if someone has reason to ask why a decision is being made then that decision will be explained.

PR Metrics:

♦ Raw: The number of times “Because I said so” is used.

Record Decisions

We ensure that people understand why decisions are made and that the reasons for those decisions are recorded.

Rationale:

♦ “You can please some of the people all of the time, you can please all of the people ♦ ♦

Implications:

♦ ♦

some of the time, but you can't please all of the people all of the time.” - John Lydgate. A lot of “non-acceptance” of decisions stems from people not understanding why a decision was made. If decisions are explained, a lot of peoples “problems” with those decisions are likely to vanish. Explaining why decisions are made helps people accept them, and make them work. Even if people still do not like a decision, if they can see the rationale behind a decision, they are much more likely to “run with it”.

♦ It is the responsibility of the person making a decision to explain that decision to

those who are affected by it. ♦ Requires time and resources. ♦ People need an environment that allows then to feel comfortable and to have the mandate to ask for decisions to be explained. ♦ Management needs to create that environment. Metrics:

♦ Raw: Number of decisions taken. ♦ Raw: Number of decisions documented. ♦ Derived: % of documented decisions.

Consider Context & Implications

Rationale:

Guidance

We ensure that all decisions are based on understanding the context that causes them to be made and the implications that making them create. ♦ Decisions made without first seeing and then understanding the full context, greatly increases the risk of making bad decisions.

♦ Decisions made without first seeing and then understanding the full implications, greatly increases the risk of making bad decisions.

Guidance - 193 Implications: The Context for Decisions must be documented. The Implications for Decisions must be documented. Appropriate Tools and Processes will be required. Increased time and resources will likely be required.

♦ ♦ ♦ ♦

Metrics:

♦ Raw: Number of decisions made that did not consider the full context and/or implications.

Work Smart not Hard

We concentrate on expending the 20% of the effort that provides 80% of the benefit.

Rationale:

♦ "The Pareto principle", "The law of the vital few" or "The principle of factor sparsity"

state that, for many events, roughly 80% of the effects come from 20% of the effort. ♦ If we concentrate on addressing the 20% that provide us with 80% of the benefits we will be as effective as we can reasonably be, whilst still allowing for further improvement.

Implications:

♦ Requires time and resources. ♦ People need an environment that allows then to feel comfortable and to have the mandate to think-out-of-the-box.

♦ Management needs to create that environment. Metrics:

♦ Raw: Number of instances where the 8020 rule is applied.

Consider Efficiency

We consider how things are done, rather than only what things are done. ♦ The Enterprise will always have finite resources. ♦ Those resources are precious, and the return on their use must be maximised. ♦ What the Enterprise does, is not so much of a differentiator as how it does, what it does. ♦ Efficiency is a key to strategic success.

Implications:

♦ Requires time and resources. ♦ People need an environment that allows then to feel comfortable and to have the mandate to consider efficiency. ♦ Management needs to create that environment.

Guidance

Rationale:

194 - Guidance Metrics:

♦ Raw: Amount of resources spent on efficiency.

Consider Important Non-Urgent Work We break the negative feedback loop of always spending more time on Important Urgent Work (Firefighting) to the detriment of Important Non-Urgent Work.

Rationale:

♦ Increasing time spent on Important Non-Urgent work, tends to reduce the amount of time subsequently required to deal with Important Urgent work (Firefighting). ♦ Reducing the amount of time dealing with Important Urgent work (Firefighting), tends to increase the amount of time available for Important Non-Urgent Work. ♦ Prevention is better than cure.

Implications:

♦ Requires time and resources. ♦ People need an environment that allows then to feel comfortable and to have the

Metrics:

mandate to consider Important Non-Urgent work. ♦ Management needs to create that environment.

♦ Raw: Amount of resources spent on efficiency.

Consider Things of Fundamental Importance

We spend more time thinking more deeply about fundamental things and getting those things correct. Rationale:

♦ Concentrating on things of Fundamental Importance are likely to yield better

decisions and better outcomes than ignoring them or not giving them enough consideration. ♦ If you do not get fundamentals right, it is likely to cause serious problems further down the line. Implications:

mandate to Consider Things of Fundamental Importance.

♦ Management needs to create that environment. Metrics:

Guidance

♦ Can be subjective. ♦ Requires time and resources. ♦ People need an environment that allows then to feel comfortable and to have the

♦ Raw: Amount of resources spent on Considering Things of Fundamental Importance.

Consider the True Value of Things

Guidance - 195

We look deeper into things to see where true value lies rather than only looking at things with obvious value.

Rationale:

♦ .

Implications:

♦ Requires time and resources. ♦ People need an environment that allows then to feel comfortable and to have the mandate to Consider the True Value of Things. ♦ Management needs to create that environment.

Metrics:

♦ Raw: Amount of resources spent on Considering the True Value of Things.

Prioritize Substance over Style We value the content and substance of ideas and argument over and above the way those ideas or arguments are communicated.

Rationale:

♦ The way something is said or a message is delivered can unduly influence those

listening to and affected by it. ♦ The Halo Effect can mean that a decision with dubious value could be accepted. ♦ The Horns Effect can mean that a decision with great value could be rejected. ♦ “If the honourable gentlemen would pay more attention to what I am saying, rather than how I am saying it, he might receive a valuable education in spite of himself” Margaret Thatcher. Implications:

♦ People need to feel comfortable expressing their opinions even though they may not be delivered in a “professional” manner.

♦ People need to focus on the content of opinions rather that their delivery. ♦ Management needs to create that environment. Metrics:

Consider Future Benefit Rationale:

We consider things from the point of view of future benefit rather than only in terms of short term benefit. ♦ Short term benefits satisfy the craving for low hanging fruit and immediate

gratification, however, not balancing immediate needs for more longer term needs will usually cause longer terms problems that can easily outweigh short term gains..

Guidance

♦ Raw: The number of times substance is wins out over style.

196 - Guidance Implications:

♦ Requires time and resources. ♦ People need an environment that allows then to feel comfortable and to have the mandate to Consider Future Benefit.

♦ Management needs to create that environment.

Metrics:

♦ Raw: Amount of resources spent on Considering Future Benefit.

Expose Individual and Contrary Opinion We seek out and hear people with opinions that are contrary to the opinions of people that have more “seniority” or contrary to the opinions of the majority.

Rationale:

♦ ♦ ♦ ♦

Implications:

Being senior does not mean that someone is right. Being in the majority does not mean that someone is right. Innovation and progress can come from seeing things that others cannot. If we do not allow (demand) contrary opinion, the risks of making bad decisions are greatly increased.

♦ People in power may feel very uncomfortable allowing contrary opinions to be heard. ♦ People understanding that being in the majority does not automatically mean they are right. ♦ People need to feel comfortable and able to express contrary opinions. ♦ Management needs to create that environment. Metrics:

♦ Raw: The number of contrary opinions heard.

Change Actions and Beliefs over Perceptions

We don't allow cognitive dissonance to corrupt decisions. Rationale:

individual to resolve the dissonance. ♦ Dissonance will be resolved in one of three basic ways:  Changing ones Belief.  Changing ones Actions.  Changing ones Perception.

Guidance

♦ Cognitive dissonance theory is based on three fundamental assumptions: ♦ Humans are sensitive to inconsistencies between actions and beliefs. ♦ Recognition of this inconsistency will cause dissonance, and will motivate an

♦ It is inherently very hard for people to change their Beliefs - otherwise they would not be Beliefs.

Guidance - 197 ♦ It can be very difficult for people to change their Actions (one type of action is a

decision) ♦ It is very easy for people to change their Perceptions to justify a Belief or an Action regardless of how erroneous the Belief or Action may be.

Implications:

♦ People will feel very uncomfortable changing their Beliefs or Actions. ♦ People need to fee that changing their Beliefs or Actions is seen as a positive rather than a negative. ♦ An environment will be required that stop people feeling uncomfortable. ♦ Management needs to create that environment.

Metrics:

♦ Raw: The Number of Beliefs that have changed. ♦ Raw: The Number of Actions that have changed.

Don't Jump to Conclusions We don’t unnecessarily jump to conclusions.

Rationale:

♦ A general (insatiable) appetite for quick wins and doing things faster can cause people to make snap decisions. ♦ Decisions that are taken without the required information to make them are not decisions, but arbitrary guesses.

Implications:

♦ "Analysis Paralysis" is a phrase often used when people who want to jump to conclusions or to repress others who may be more wary.

♦ Requires time and resources. ♦ People need an environment that allows then to feel comfortable spending the time required to make well founded decisions. ♦ An environment will be required that stop people feeling uncomfortable. ♦ Management needs to create that environment. Metrics:

♦ Raw: The number of decisions that were going to be made incorrectly, but were

Think Strategically Rationale:

We make decisions to provide maximum benefit to the Enterprise as a whole.

♦ Decisions that are made purely from a tactical perspective provide less long term

value than those made for the benefit of the Enterprise as a whole. ♦ All parts of the Enterprise only exist to enable and fulfil the goals and objectives of the Enterprise.

Guidance

changed.

198 - Guidance Implications:

♦ Some short term goals may need to be sacrificed in preference to larger and more

strategic goals. ♦ Some projects may need extra funding to achieve this. ♦ IT systems and services will be evaluated in terms of the benefits to the whole Enterprise rather than to satisfy the needs of a particular project or group.

Metrics:

♦ Raw: Number of decisions which produce a multi project, multi department benefit as opposed to a singular benefit.

♦ Raw: The number of Applications shared across boundaries. ♦ Raw: The number of Services shared across boundaries. ♦ Raw: The number of Components shared across boundaries.

No Bullying

We make decisions based on rational thinking not on power, control or position.

Rationale:

♦ Bullying can take many forms, not just physical. ♦ Bullying: Anyone who holds some kind of power, control or position over someone

else, and who uses that power, control or position to force another person to do (or not to do) something. ♦ Bullying only serves to benefit the individual and damage the Enterprise. Implications:

♦ People who are used to using bullying as a tool to get things done will feel very

uncomfortable not being able to. ♦ People who are used to being bullied will feel very uncomfortable exposing it when it happens. ♦ An environment will be required that stop people feeling uncomfortable. ♦ Management needs to create that environment. Metrics:

♦ Raw: Number of Incidences of Bullying.

Expose Problems Rationale:

Guidance

We expose, evaluate and deal with problems when they occur, rather than ignoring or burying them. ♦ Solving problems as early as possible greatly limits the damage and knock on problems those problems can cause later.

♦ Hiding “bad news” only serves to benefit the individual and damages the Enterprise. ♦ Sometimes information can come to light that requires a very large change in what is being done.

Guidance - 199 ♦ The bigger the problem, the more likely it is for people want to gloss over it and

ignore it. ♦ Either because they feel they may be looked on as having done something wrong, or because the implications of accepting it will cause an increase or loss of a large amount of time, money, effort, etc.

♦ However inconvenient and painful the truth is, it is usually an order of magnitude less that the pain that will be suffered later if it is not dealt with.

Implications:

♦ People who are used to hiding problems will feel very uncomfortable not being able to.

♦ People who are used to seeing problems hidden will feel very uncomfortable exposing them.

♦ An environment will be required that stop people feeling uncomfortable. ♦ Management needs to create that environment.

Metrics:

♦ Raw: Number of problems exposed. ♦ Raw: Number of problems hidden. ♦ Derived: Ratio of problems exposed vs hidden.

Proactive Business Leadership

We ensure that business and IT leadership engage proactively on Transformation planning activities. Rationale:

♦ The Business is the key stakeholder, or customer, in the application of technology to address a business need. ♦ The business needs to be an active participant in order to close the gap between IT and the Business and to allow the Business and IT to operate within a partnership rather than a purely customer/supplier relationship. ♦ In order to ensure IT is aligned with the Business, all areas of the Business must be involved in all aspects of the IT environment. Implications:

Metrics:

♦ ♦ ♦ ♦

responsibility and accountability for developing the information environment. ♦ Commitment of resources will be required to implement this principle. ♦ The business experts from across the Enterprise and the senior technical staff responsible for developing and sustaining the IT environment need to come together as a team to jointly define their goals and objectives. Raw: Does a model of IT and Business leaders involved in Business Planning exist? Raw: % of roles, responsibilities and accountabilities defined for each Raw: % of leaders that have agreed their roles, responsibilities and accountabilities. Raw: Last 4 Quarters: Did the quarterly Business Planning meeting take place?

Guidance

♦ To operate as a team, every stakeholder, or customer, will need to accept

200 - Guidance

♦ Raw: % Business leaders attendance at quarterly Business Planning meetings. ♦ Raw: % IT leaders attendance at quarterly Business Planning meetings. ♦ Derived: % attendance at quarterly Business Planning meetings.

Recognise Responsibilities

We recognise and respect the responsibilities of business departments and the IT department.

Rationale:

♦ Business departments are best placed to define WHY something needs to change. ♦ Business & the IT Department are best placed, together, to define WHAT needs to change. ♦ The IT department is best placed to define HOW IT change should be implemented. ♦ Business departments are best placed to define HOW Business change should be implemented.

Implications:

♦ Business departments are responsible for explaining to the IT department why

Metrics:

something needs to change. If the IT department does not understand, the onus is on the business department to explain. ♦ Business departments and the IT department need to work together to determine what needs to change to achieve the desired outcome of a change. ♦ Whilst the IT department is always open to any discussions and recommendations regarding how its change processes could be improved, it is the IT department that will decide what processes must be followed to effect IT change and that these processes may impact business timescales and/or costs. ♦ Whilst business departments are always open to any discussions and recommendations regarding how its change processes could be improved, it is the business departments that will decide what processes must be followed to effect business change and that these processes may impact IT timescales and/or costs.

♦ Raw: % of instances where the IT department is not allowed to follow its change processes.

♦ Raw: % of instances where business departments are not allowed to follow their change processes.

Guidance

Guidance - 201

KEYPOINT:

When categorising Principles, think in terms of those that guide HOW we effect Transformation (Means).

ADOPTION:

EA Project Team: Create Principles that guide HOW we effect

OO Transformation (Means).

Questions to Ponder

♦ Has your Enterprise defined principles that guide HOW you effect Transformation (Means)?

Guidance

♦ If not, what problems does that create and what can you do to alleviate them?

Appendix - 203

PR APPE NDIX

Appendix

204 - Appendix

KEYPOINT:

The Appendix section contains

information on the background of PF2, POET, PEAF and the author.

OO F

Appendix

Appendix - 205 Backgr ound

PR Why Were They Created?

Because I care. Because I care about Enterprises. Because I care about the people who Direct, Operate, Transform and Support Enterprises. Because I am angry about how much time is wasted. Because I am angry about how much money is wasted. From the Afghani to the Zloty, I guarantee you are wasting it. Big time! This work was inspired by all those who seek to make the world a better place rather than those that seek to own it.

When Were They Created?

PEAF was initially launched in November 2008 and POET in 2014.

Where Did They Come From?

All Pragmatic Ontologies and Frameworks were created from observing failure. That is: Seeing why people fail What problems they encounter Providing things to reduce the risk of others failing in the same way Providing things to alleviate the problems people have.

Around 2002 I began to be interested in something called “Enterprise Architecture”. The term started to appear more in publications and people started to talk about it more although from listening to them there never seemed to be a concrete definition of what it actually was that everyone agreed with (some say that’s still the case today!). Using logic and common sense I could surmise that it was not Project level Architecture (because that

Appendix

♦ ♦ ♦ ♦

206 - Appendix already had a name - Solution Architecture) and therefore it must be something at a “higher level” - not just bigger. Something related to:

♦ What goes on before projects execute and before Solution Architects start working on those projects. ♦ Enterprise Centric, or more specifically Enterprise Transformation Centric, rather than Project Centric and/or IT Centric.

At that time it all seemed to be a bit of a black art (some say it still is!) and so, being an Architect and not wanting to reinvent the wheel (others call it being lazy!), I surmised that there must be something out there (a bit like Prince or ITIL or MSP for example) - a framework - that might help people to “do” EA by:

♦ Helping people understand what EA was. ♦ Helping people increase the maturity in how an Enterprise “does” EA.

So, I consulted the mighty Google (sorry Oracle!). Google told me about something called Zachman and something called TOGAF. And so I went off to investigate further. From what I could tell, Zachman’s message seemed to resonate well with me in terms of general thinking I had built up over the preceding 20 years, namely:

♦ You can’t change what you can’t see - hence the need to model things - in a structured way.

♦ There must be Phases involved in Transformation to get from Strategic intent at the top down to real physically deployed things at the bottom.

Appendix

These basic messages haven’t changed and are as valid today as they always were - although the important distinction between Enterprise Architecture and Enterprise Engineering that Pragmatic makes today was not (and still is not) recognised in Zachman (despite my attempts to do so). But, whilst these fundamental things (modelling and phases/levels) were a good start, they were much too high level to provide any practical help in using them (which is what a framework is supposed to do) and so I invested more time looking into the much more detailed TOGAF. As I looked into TOGAF, the first thing that struck me was “Where the hell do I start?”. The material was immense, complex, confusing, very dry, hard to consume and offered no guidance about how to adopt it. So, assuming it was my ignorance that was the problem I booked myself on a TOGAF course. Within the first 2 hours of the first day it became clear that it was centred around Project level IT centric Architecture. Nothing wrong with Project level IT centric Architecture, but not Enterprise Architecture. Fantastic for those Enterprises that had still not figured out that the complexity of the IT landscape had grown to such a level that using Architecture as a discipline on IT Projects (Solution Architecture) was almost mandatory (unless you wanted to waste a shed load of money and deliver a shed load of bad IT to customers), but not Enterprise Architecture. Great for those Enterprise that wanted to formalise their Solution Architecture discipline, but not Enterprise Architecture. Great for those Enterprises that wanted to continue to treat “The Business” as a second class citizen to “IT”, but not Enterprise Architecture. At least not the Enterprise Architecture that logic and common sense dictated to me. Anyway, I got through the course, passed the exams and became TOGAF Certified. Over the next few years I worked at various organisations and my TOGAF certification served me well

Appendix - 207

in terms of getting me job interviews and most of the subsequent contracts. Having got a contract (because I was TOGAF certified) I then endeavoured to first discover how much and what parts of TOGAF were being used. The conversation (over many days, sometimes weeks) usually went something like this:

K: “Hi Allen, I’m new here. I’ve been told that you use TOGAF, can you tell me what parts you are using and which you aren’t?” A: “Hi Kevin, Errrmm, Yeah sure - you need to talk to Steve, he’s the one that did the training.” <time passes….>

K: “Hi Steve, I’m new here. I’ve been told that you use TOGAF, can you tell me what parts you are using and which you aren’t?” S: “Hi Kevin, Errrmm, why are you asking me?” K: “Allen told me you did the training and you would know.” S: “Err yeah, but I was only one of the twenty people who did it, I wasn’t the main person. Listen - I’m a bit busy on this CRM project at the moment, can you go and ask James about it - I think he was the main guy.” <time passes….>

K: “Hi James, I’m new here. I’ve been told that you use TOGAF, can you tell me what parts you are using and which you aren’t?” J: “Hi Kevin, Errrmm, why are you asking me?” K: “Steve told me you did the training and you were the main guy so you would know.” J: “Err yeah, but I was moved off that onto this ESB project. Listen - I’m a bit busy at the moment, Dave took over that TOGAF thing - go talk to Dave.” <time passes….>

K: “Hi Chris, I’m new here. I’ve been told that you use TOGAF, can you tell me what parts you are using and which you aren’t?” C: “Hi Kevin, Errrmm, why are you asking me?” K: “James told me Dave did the training and he was the guy in charge of TOGAF adoption, but that Dave says it wasn’t him, it was you”

Appendix

K: “Hi Dave, I’m new here. I’ve been told that you use TOGAF, can you tell me what parts you are using and which you aren’t?” D: “Hi Kevin, Errrmm - why are you asking me?” K: “James told me you did the training and you’re now the guy in charge of TOGAF adoption.” D: “Err No! That’s Chris, you need to talk to Chris” <time passes….>

208 - Appendix

C: “Err Yeah - well I went on the course, but to be honest we never did anything about if after that, you should go talk to Allen, he knows what’s going on” In every case, after being passed from pillar to post, it always transpired that no one was actually using TOGAF at all. So, I began to build up my own intellectual capital (documents, checklists, presentations, spreadsheets, ideas, concepts, processes, products, etc) so that I could bring them to bear as a set of quick start artefacts for subsequent contracts. During 2008 it suddenly dawned on me that all this intellectual capital that I had built up, actually constituted what I thought an EA framework should contain. So, in addition to cleaning up and structuring the material so others could adopt and use it easily, I had to choose a name. So, I thought, what one word would sum up my approach? A core of fundamental things - the 20% that would give 80% of the benefit - that would reduce or remove 20% of the risks that cause 80% of the failures. Cutting through all the smoke and mirrors and Cutting EA to the Bone. And so the name Pragmatic chose me.

How Were They Created?

POET and PEAF have taken more than 10,000 hours to produce in terms of physical work, born from approximately 150,000 hours of thinking. The graphics were not just drawn - like most good things they evolved - and while many of them look quite simple, it took an awful lot of work and pain to get to those simple graphics. To an outside observer, those diagrams could appear as if someone just sat down and drew them but each one has had many versions as it has evolved, coalesced, fragmented, reconstituted, gone down the wrong track, fragmented, coalesced again and then finally thrown away, only to be resurrected when a light bulb went on somewhere in the deepest darkest recesses of my feeble brain. Elegance and simplicity takes a lot of hard work to achieve but, anything Pragmatic must be so. “Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte.” - Blaise Pascal (“Lettres Provinciales”, 1657) Which loosely translates to

Appendix

“If I Had More Time, I Would Have Written a Shorter Letter” In fact, the amount of things and work I have thrown away greatly outweighs what now exists. I believe that POET and PEAF have achieved elegance and simplicity to some degree but, of course, “we don’t live in a perfect world” (as so many Managers I have worked for in the past have reminded me on so many occasions) and there is always more work to do. POET and PEAF will evolve, as everything must do, but for now, it is good enough. With the benefit of time to think of a suitable response to those Managers, my response now would be: “We don’t live in a perfect world? I know - Believe me I know! If we did, we wouldn’t be having this conversation ;-)”

Appendix - 209 What Was Used to Create Them?

Basically, common sense. It has always amazed me, how many things in business (and in life) do not seem to adhere to any common sense at all, which probably explains why a lot of things that are created to help people improve or mature something, contain a lot of common sense. In addition I have a brain split into two parts (Architecture and Engineering) that work together but also conflict a lot of the time. But it is from this conflict that progress lies. Methods

♦ Architecture, Engineering, Logic.

Artefacts

♦ Input - Air, Water, Nespresso, Earl Grey, Toast, Ham Eggs & Chips, Bombay

Sapphire (Tonic), Johnny Walker Black Label (Coke Zero), Whiskers, Paper, Ink, Blood, Sweat, Tears. ♦ Output - PF2 Book, POET Book, PEAF Book, Pragmatic365.org Website

Guidance

♦ Common Sense, W.E. Deming, J. Zachman, T. Graves.

Items

♦ Biological Technology - Kevin - Generally all of him, but mostly his brain, eyes and

Appendix

hands. (His stomach, colon and bladder put in an appearance occasionally, with his posterior providing a supporting role :-), Murphy the cat. ♦ Mechanical Technology - 25 Buttermere, Braintree, Essex, CM77 7UY, UK, Desk, Chair, Whiteboard (Pens and Eraser). ♦ Electrical - Challenge Fan Heater, Creative GigaWorks T40 Series II 2.0 PC Speakers ♦ Information Technology ♦ Hardware - Dell Latitude E6520 (Intel i7-2760QM @ 2.4GHz, 8GB RAM), 2 * 32in 2560x1600 LED Monitors, 2 * 24in 1920x1200 LED Monitors, HP Officejet Pro X576, Samsung Galaxy Note 8. ♦ Software - MS Windows 10, MS Visio, MS Word, MS Excel, MS PowerPoint, Paint.NET, Integromat, CognitoForms ♦ Languages – VBA, VBscript, Javascript, SQL, ASP, HTML, CSS ♦ Data – (mp3) David Bowie, Pet Shop Boys, Dean Martin, Chris Rea. Culture ♦ God, Honesty, Integrity, Pragmatism, Altruism, Persistence, Passion, Psychology

210 - Appendix

KEYPOINT:

Use POET and PEAF to make sure you don’t make the mistakes that

cause 90% of all EA initiatives to fail.

Questions to Ponder

♦ Do you think that observing failure is a good way to figure out how to improve things? ♦ What failures have you witnessed in the past? ♦ What does that tell you about how to improve it?

OO F

Appendix

Appendix - 211 The Author

Appendix

PR Who Created The Pragmatic Family of Frameworks (PF2)? A simple man. My career began at the age of 16 in 1978 as an Electrical and Electronic Apprentice with Marconi Radar Systems (Blackbird Road, Leicester, UK) At that time I was really into electronics and had been playing with little circuits for a few years. It was really exciting. I spent my time between college and “The Factory” where I got the chance to work in many different departments. It was really exciting. Around 1980 I ended up in a Department (New Parks, Leicester UK) called TEPIGEN (TElevision PIcture GENerator) who had built the visual system for a ship simulator. Six million Pounds of custom built hardware (that had less processing power than the CPU in the phone that’s in your pocket) consisting mainly of four racks of “Picture Processors” (Motorola 68000s) driven by a PDP11. It was really exciting. The output was on three channels each delivering 40 degrees field of view which drove three large Barco projectors. Interestingly at one point there were black speckles that kept appearing on the displays, moving about in random patterns and appearing and disappearing in the same apparently random fashion. After months of software and hardware investigation the problem was identified. It was a test Radar across the apron from where our Portacabins where located that was spraying us periodically with microwaves! It was really exciting. I began my time there hand entering the data which described the terrain and buildings and which fed the picture processors, and wrote my first program in DEC BASIC. Over the next four years or so my programming skills grew, and I moved from BASIC to FORTRAN and then to PASCAL. It was really exciting. The ship simulator turned into a flight simulator which meant it was the biggest video game in the world. It was really exciting. So much so that I would work late into the night (sometimes 48 hours at a stretch) and go into work on Saturdays or Sundays. Right from the beginning it wasn’t so much the code I wrote that I got excited about it was more HOW I wrote the code that interested me. I would often spend hours writing a program and finally get it working, only to tear it to pieces and rewrite it in a

212 - Appendix

new and elegant way, often with more features, less code and more opportunity to reuse things later. It was really exciting. Even at that time I spent more time throwing things away than I spent creating things. I believe this is where progress comes from. Sounds totally counter-intuitive I know, but most things of value are counter-intuitive! Around 1986 the plug was pulled on TEPIGEN and I moved to another department (Fleet, Hampshire, UK) who produced a system called TELEVIEW (an improvement on Teletext and a forerunner of “The Web”) for Singapore’s Telecom Company (SingTel). I had moved on to C as a programming language. The most elegant and powerful language I have ever used. It took me a while to understand it but after reading the perfect “The C Programming Language” (Kernighan and Ritchie) the penny dropped. It was really exciting. A brief spell at SD Scicon (1989-1991) was followed by three years working for Deutsche Bank (Singapore) where I found the best food in the world and where my architectural tendencies came to the fore. It was really exciting. While there I created and sold a numerical analysis package for lottery numbers called Mega4D. Returning in 1994 I spent six years working for Eurobase Systems (Chelmsford, UK) doing Application Architecture and creating Architectural and programming frameworks. From 2000 to 2011 I spent my time working for various Enterprises as a contractor. While interesting, it wasn’t very exciting, but all the time, whatever domain I worked in I was always interested in improving it. Each time this met a limit and the limit was always as a consequence of things being done less than effectively and less than efficiently in the preceding step. Hence my roles moved from Application Architecture, Data Architecture and Technology Architecture into Technical Architecture (a bit of a misnomer!) then Solution Architecture then Enterprise Architecture and finally the entire Transformation domain. Since 2011 I have devoted my time to Pragmatic. It is really exciting. Whilst I have never been an academic person, and never went to university (I have always preferred to “go out and do stuff”) I have recognised over the last year that Psychology plays such a vital role in Enterprise Transformation (for good or bad) and so in February 2014 I began a BSc (Honours) Psychology degree with The Open University. It is really exciting. MBTI My MBTI is a split between INTJ and INTP. INTJ - Sometimes referred to as the "Architect," or the "Strategist," people with INTJ personalities are highly analytical, creative and logical. Strengths: Enjoys theoretical and abstract concepts. High expectations. Good at listening. Takes criticism well. Self-confident and hard-working. Weaknesses: Can be overly analytical and judgmental. Very perfectionistic. Dislikes talking about emotions. Sometimes seems callous or insensitive. INTP - People who score as INTP are often described as quiet and analytical. They enjoy spending time alone, thinking about how things work and coming up with solutions to problems. INTPs have a rich inner world and would rather focus their attention on their internal thoughts rather than the external world. They typically do not have a wide social circle, but they do tend to be close to a select group of people. Strengths: Logical and objective. Abstract thinker. Independent. Loyal and affectionate with loved ones. Weaknesses: Difficult to get to know. Can be insensitive. Prone to self-doubt. Struggles to follow rules. Has trouble expressing feelings. DISC

Appendix

Appendix - 213

Appendix

My DISC Profile is 7414 and categorised as Result-Oriented. Result-Oriented people display self-confidence, which some may interpret as arrogance. They actively seek opportunities that test and develop their abilities to accomplish results. ResultOriented persons like difficult tasks, competitive situations, unique assignments, and "important" positions. They undertake responsibilities with an air of self-importance and display self-satisfaction once they have finished. Result-Oriented people tend to avoid constraining factors such as direct controls, timeconsuming details, and routine work. Because they are forceful and direct, they may have difficulties with others. Result-Oriented people prize their independence and may become restless where involved with group activities or committee work. Although Result-Oriented people generally prefer to work alone, they may persuade others to support their efforts especially when completing routine activities. Result-Oriented people are quick-thinkers, and they are impatient and fault-finding with those who are not They evaluate others on their ability to get results. Result Oriented people are determined and persistent even in the face of antagonism. They take command of the situation when necessary, whether or not they are in charge. In their uncompromising drive for results, they may appear blunt and uncaring. Belbin Belbin categorises me as a Plant (Creative and inventive individuals, Plants are the ones in the team most likely to come up with new ideas and suggestions. The name comes from Dr Belbinâ&#x20AC;&#x2122;s original research. It was discovered that there was no initial spark of an idea in a team unless a creative person was â&#x20AC;&#x153;plantedâ&#x20AC;? in each team) and a Shaper (Shapers are people who challenge the team to improve. They are dynamic and usually extroverted people who enjoy stimulating others, questioning norms, and finding the best approaches for solving problems.). Putting MBTI, DISC and Belbin together just about sums me up to a tee. Different people have different profiles, and different profiles fit into different roles in different ways. We all kind of know this but do we ever take it into account?

214 - Appendix

KEYPOINT:

Use people for the type of person

they are, not the type of person you want them to be. If we were all the

same, nothing would ever get done.

Questions to Ponder

What are the MBTI, DISC and Belbin profiles of the people in your Enterprise? Do they all suit their roles? Have you ever found someone to be a “difficult person” or a “loose cannon”? If so, did their MBTI/DISC/Belbin profile taken into account?

♦ ♦ ♦ ♦

Appendix

Appendix - 215 Keypoints

PR PF2 introduces the Companies and Frameworks that are part of the Pragmatic Family.

The Introduction section of PF2

introduces the companies that are

Appendix

part of the Pragmatic Family.

216 - Appendix

Pragmatic 365 is a non-profit

research company. Pragmatic EC is a consulting company.

Most consultancies only want to sell you fish.

Pragmatic will teach you how to fish.

Use Pragmatic Frameworks (for free) to improve your Enterprise.

PEAF Certified training, provides

everything to enable you to adopt PEAF.

Appendix

Appendix - 217

PEAF Focused Workshops, allow you

to focus on specific areas.

Access to the Pragmatic Publishing Platform is granted by graduating from an Instructor led course.

P3 allows Enterprises to easily

produce and maintain their own

Frameworks and publish them to books, their intranet and mobile devices.

P3 is a component based authoring

Appendix

system.

218 - Appendix

The Language section of PEFF

introduces fundamental terminology that is used throughout Pragmatic’s Frameworks.

Be ever vigilant of the hidden

confusion that language can create.

OO Everything is a System.

The Word Enterprise does not mean “large” or “large IT” or “senior”. It is a general noun.

Appendix

Appendix - 219

There is no hidden connotation to

Pragmatic’s use of the word “Transformation”.

A Framework is an expression of

Best Practice comprising information in at least one area (Methods,

Artefacts, Guidance, Items, Culture)

and optionally information regarding its Adoption.

Theory is just as important as

Appendix

Practice

220 - Appendix

Colour

Information =

Understanding.

The Ontologies section of PEFF

introduces fundamental ontologies

that are used throughout Pragmaticâ&#x20AC;&#x2122;s Frameworks.

Methods, Artefacts, Guidance, Items and Culture (MAGIC) is a Structural Ontology

Appendix

Appendix - 221

Methods are executed by Culture

(people) and/or Items (things) to transform Artefacts.

Motivation, Actions, Guidance,

Measures and Assessment (MAGMA) is a Transformational Ontology

Measures lead to Assessments lead to Motivation, leads to Actions

Direct, Operate, Transform and

Support (DOTS) is an Enterprise

Appendix

Ontology

222 - Appendix

Direction drives Operate (supported

by Transform and Support) which

takes things from the Context and puts things into the context.

The Methods section of POET

defines 'WHAT' should be done,

'HOW' and 'WHEN'.

The seven phases of transformation (Strategising, Roadmapping, Solutioning, Elaborating,

Constructing, Transitioning, Using)

are connected with the Governance & Lobbying discipline.

Appendix

Appendix - 223

Business Architecture feeds

Enterprise Architecture feeds Solution Architecture feeds Enterprise Engineering.

99.9% of Enterprises are happy to spend money on improving

Engineering, but are very reticent to spend money on improving Architecture.

Use the Transformation cascade to link the phases together.

Understand how common artefacts

Appendix

relate to the Phase cascade.

224 - Appendix

Recognise that Governance &

Lobbying are inextricably linked.

Utilise Governance and Lobbying to synchronise Transformation.

OO Technical Debt is the future

problems created when we write “bad” code. (Ward Cunningham)

Transformation Debt™ is applying

the principle of Technical Debt to all Guidance, all Phases and all Levels of Transformation.

Appendix

Appendix - 225

The future cost of Non-Compliance

and Remediation will always be bigger than the current Cost of Compliance.

If you do not control Transformation Debt™ it will control you.

Managing Transformation Debt™ can save huge amounts of money, and

(probably more importantly) time.

Accumulated Transformation Debt™

Appendix

is reviewed during Roadmapping.

226 - Appendix

EA performs Governance down to

projects, and accepts Lobbying up from Projects.

Reviewing Options and Solutions is the heart of Governance.

Don’t confuse the Tactical/Strategic

reasons for doing projects, with the Tactical/Strategic methods of executing them.

Transformation Debt™ Agreements expose Transformation Debt™

Appendix

Value.

Appendix - 227

Over time, increase the ratio of

Strategic to Tactical work.

The Artefacts section of POET defines 'WHAT' information is consumed and produced and 'WHEN'.

The seven levels of transformation (Enterprise Context, Contextual, Conceptual, Logical, Physical,

Operational, Physical Stuff) sit in between the seven phases of

Appendix

Transformation.

228 - Appendix

Business Architecture, Enterprise

Architecture and Solution

Architecture information are closely related.

This is the complete map of information required for

Transformation to be executed in an

Effective, Efficient, Agile and Durable way.

The purpose of a Transformation Debtâ&#x201E;˘ Agreement is to expose Transformation Debtâ&#x201E;˘.

Appendix

Appendix - 229

The purpose of a Transformation

Debtâ&#x201E;˘ Agreement is to expose Transformation Debtâ&#x201E;˘.

The Pragmatic Role and Phase

patterns are key to assigning RACI to roles.

The Guidance section of PEAF

defines what information is used to

guide people in their decision making.

Principles come from Best Practice

Appendix

and your Enterprise's Strategy.

230 - Appendix

Don't think in terms of Business and

IT principles. Use MAGIC to categorise them.

When categorising Principles, think in terms of those that guide WHAT we want to achieve (Ends).

When categorising Principles, think in terms of those that guide HOW we effect Transformation (Means).

The Appendix section contains

information on the background of

Appendix

PF2, POET, PEAF and the author.

Appendix - 231

Use POET and PEAF to make sure

you donâ&#x20AC;&#x2122;t make the mistakes that

cause 90% of all EA initiatives to fail.

Use people for the type of person

they are, not the type of person you want them to be. If we were all the

same, nothing would ever get done.

All Pragmatic books contain a Keypoint section.

www.Pragmatic365.org is the official

source for all PF2/POET/PEAF related

Appendix

materials, and is constantly evolving.

232 - Appendix

Pragmatic EA is a non-profit research

company, dedicated to developing Best Practice in relation to the

structure and transformation of Enterprises.

OO F

Appendix

Appendix - 233 Sour ces & Res our ces

PR F

Appendix

Here is listed various sources and references to things referred to in the Pragmatic Frameworks. You can always access the most up to date material online at www.Pragmatic365.org.

234 - Appendix

KEYPOINT:

www.Pragmatic365.org is the official

source for all PF2/POET/PEAF related materials, and is constantly evolving.

OO F

Appendix

Appendix - 235

Appendix

236 - Appendix

KEYPOINT:

Pragmatic EA is a non-profit research company, dedicated to developing Best Practice in relation to the

structure and transformation of Enterprises.

OO F

Appendix

PR F

,!7IB9A8-eceeii!

If we are to sail safely in these unpredictable waters we must make preparations and plans to allow us to respond when treacherous conditions face us. For if we wait until that time before we act, it is unlikely that we will survive.

The unprepared ship will often catch more fish than other more well prepared ships not having to comply with safety regulations they are able to cast and wind in the nets much faster and therefore fill their holds faster. Holds also have more space due to the absence of emergency equipment which means more fish can be stored before having to return to port to offload them. It is not a case of "if" the ship will meet the storm. It is a case of “when”. What preparations has your Enterprise made? To weather its own “Perfect Storm”?

ISBN 978-1-908424-48-8

,!7IB9A8-ece i !:t;K;k;K;k

Kevin Lee Smith

The Author Kevin’s professional career in Enterprise Transformation began in 1980. MBTI and DISC says that he is a Result Oriented, Independent, Individualistic Visionary. However, he also freely admits that he is an Arrogant, Inflexible, Argumentative, Intolerant, Impatient, Critical & Stubborn Sceptomist!

A Pragmatic Approach Using Transformation Debt™

While the seas are calm, an unprepared ship and crew is generally indistinguishable from a well prepared ship and crew. In fact the unprepared ship will often seem preferable to many, setting sail before other more well prepared ships - not having to waste time gathering and studying the correct charts, loading extra emergency rations, checking the presence and quality of the life-rafts nor performing preventative maintenance on the engine. Often the unprepared ship will set sail and return with a hold full of fish while the prepared ship is still making good their preparations.

A Pragmatic Approach Using Transformation Debt™ $40,000,000

Cumalative Amount of. Transformation Costs, Enterprise Debt and Savings

Without proper preparation, every Enterprise is sailing full speed into their own perfect storm.

1 02 v2

Most Enterprises invest huge amounts of time and effort in battling the storms. Very few spend any resources on preparing the ship. Instead, the call is “all hands on deck” to land the next catch and set the next net.

Enterprise Transformation Governance

Enterprises have been and will continue to live in a state of flux. A never ending sea of change that buffets them and blows them around, seemingly at random, in an unending churning ocean. Even when it is calm, a storm can blow up “out of the blue” and literally sink the ship at a moment’s notice.

$30,000,000

Transformation Costs (ED Hidden) Enterprise Debt (ED Hidden) Transformation Costs Saved (Excluding ED)

Transformation Costs (ED Managed) Enterprise Debt (ED Managed) Transformation Costs Saved (Including ED)

$20,000,000

$10,000,000

$20,000,000

$30,000,000

Time

Kevin Lee Smith The Pragmatic Thinker

Part of the Pragmatic Family