What is EA - A Pragmatic Explanation by Pragmatic EA Ltd

1 02 v2

A Pragmatic Explanation Business Objective (e.g. reduce costs by 20% Year 1)

Current (Now)

Business Objective (e.g. Comply with new legislation - Year 2)

Business Objective (e.g. Launch New product Year 4)

Target Year 5

OO Prog / Proj / Initiative

Prog / Proj / Initiative

IT Objective (e.g. replace out of support apps - Year 1)

Prog / Proj / Initiative

IT Objective (e.g. Provide DR for mission critical Apps â&#x20AC;&#x201C; Year 3)

Kevin Lee Smith The Pragmatic Thinker

Part of the Pragmatic Family

Enterprise Architecture

A Pragmatic Explanation

v2021 Kevin Lee Smith

First published: 1 July 2017 Last updated: January 2021

ISBN 978-1-908424-56-3 (hardback) ISBN 978-1-908424-57-0 (paperback) ISBN 978-1-908424-58-7 (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

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-90842407-5

PEFF

978-1-90842410-5

POET

ISBN

Prerequisites

978-1-90842425-9 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

Prerequisites

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

ISBN

Prerequisites

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

Frameworks........................................... 41 Comparisons .............................................................................................. 43 TOGAF & Zachman .......................................................................................................................... 43

Misunderstanding ............................................................................................................................................................... 46 Criteria.................................................................................................................................................................................... 49 Raw Scores............................................................................................................................................................................ 52 Overall .................................................................................................................................................................................... 54 Example Weightings #1................................................................................................................................................... 56 Example Weightings #2................................................................................................................................................... 58

TOGAF ................................................................................................................................................ 60

Now What? .......................................................................................................................................................................... 60 Content vs Benefits............................................................................................................................................................. 62 Overall .................................................................................................................................................................................... 65 ADM........................................................................................................................................................................................ 68 Other Frameworks ............................................................................................................................................................. 70 Other Detail.......................................................................................................................................................................... 73 Guidance vs Detail.............................................................................................................................................................. 76 Trends..................................................................................................................................................................................... 78

Zachman............................................................................................................................................... 80

Basic Message ..................................................................................................................................................................... 80 Missing Perspective and Model...................................................................................................................................... 83 Overall .................................................................................................................................................................................... 86 Architect/Engineer............................................................................................................................................................... 88 Why/How .............................................................................................................................................................................. 92 How/When/What/Where/Who..................................................................................................................................... 94 Perspectives and Models .................................................................................................................................................. 96

Language ................................................ 99

Basics........................................................................................................ 101 I Didnâ&#x20AC;&#x2122;t Mean What You Heard!................................................................................................. 101 What is a System? ........................................................................................................................... 104 What is an Enterprise?................................................................................................................... 107 What is Transformation? .............................................................................................................. 110 What is a Framework .................................................................................................................... 112 Theory or Practice ......................................................................................................................... 115 Colours.............................................................................................................................................. 118

Ontologies ............................................ 121 Structural ................................................................................................. 123 MAGIC .............................................................................................................................................. 123

Transformational..................................................................................... 125 MAGMA ............................................................................................................................................ 125

Enterprise ................................................................................................ 127 DOTS................................................................................................................................................. 127

Methods ................................................ 131 Phases ...................................................................................................... 133 Basics.................................................................................................................................................. 136 Resource Utilisation ....................................................................................................................... 139 Pattern ............................................................................................................................................... 142 Models ............................................................................................................................................... 145 Roadmapping .................................................................................................................................... 147

Process ................................................................................................................................................................................. 147 Intermediate Journey....................................................................................................................................................... 152 Create/update Intermediate Models ......................................................................................................................... 154 Create/update Portfolio Model .................................................................................................................................... 157 Enterprise Transformation Strategy ........................................................................................................................... 160

Artefacts............................................... 163 Overview .................................................................................................. 165 Levels ................................................................................................................................................. 165

Basics ................................................................................................................................................................................... 167

Ontology .................................................................................................. 170 Detail.................................................................................................................................................. 170

Structural & Transformational .................................................................................................................................... 170 Models ................................................................................................................................................................................. 172 Meta-models...................................................................................................................................................................... 176

Structural & Transformational ..................................................................................................... 178 Models ............................................................................................................................................... 180

Relationships....................................................................................................................................................................... 183

The reasons the work is required ........................................................... 183

Items .................................................... 187 The Architecture Paradigm™ ................................................................ 189 What is Architecture ...................................................................................................................... 189 Purpose .............................................................................................................................................. 192

It’s Not What You Think................................................................................................................................................ 192 Structural Complexity ...................................................................................................................................................... 195 Transformational Volatility ............................................................................................................................................. 198 Transformational Complexity........................................................................................................................................ 200 Contextual Volatility & Complexity ............................................................................................................................. 202

Justification ........................................................................................................................................ 204

Applicability ......................................................................................................................................................................... 204 Cost and Ability.................................................................................................................................................................. 206 Investment........................................................................................................................................................................... 208 Procrastination ................................................................................................................................................................... 210

Why and How .................................................................................................................................. 213

Asking How - Looking Down - Structural.................................................................................................................. 213 Asking Why - Looking Up - Contextual ..................................................................................................................... 214

Abstraction & Elaboration ............................................................................................................. 216 Relationships ..................................................................................................................................... 219 The Value is in the Lines not the Boxes™ ................................................................................ 221 Patterns .............................................................................................................................................. 224 Models, Meta-Models & Semantics .............................................................................................. 227

Models.................................................................................................................................................................................. 227 Meta-Models ...................................................................................................................................................................... 228 Semantics ............................................................................................................................................................................ 228

Tools ......................................................................................................... 231 Coverage............................................................................................................................................ 231

Culture ................................................. 233 Organisation Structure ........................................................................... 235 Workers ............................................................................................................................................ 235

Architecture & Engineering .................................................................... 238 Yin & Yang ......................................................................................................................................... 238 Architect Horizontally, Engineer Vertically ............................................................................... 240 Overlap............................................................................................................................................... 243

Inter Phase .......................................................................................................................................................................... 245 Intra Phase .......................................................................................................................................................................... 247 Overall .................................................................................................................................................................................. 249

Fundamentals .................................................................................................................................... 251 Comparison....................................................................................................................................... 253 Who Are You? ................................................................................................................................. 258

The Architect ........................................................................................... 261 Secrets ................................................................................................................................................ 261

An Impossible Job ........................................................................................................................... 264 What Does An Architect Do? ..................................................................................................... 268 Architect or Charlatan .................................................................................................................. 271 The Pragmatic Architect Creed .................................................................................................. 276

Communication................................................................................................................................................................. 277 Integrity................................................................................................................................................................................ 277 Understanding................................................................................................................................................................... 277

Organisation Structure ........................................................................... 284 Traditional vs Pragmatic ................................................................................................................ 284

Traditional .......................................................................................................................................................................... 284

Enterprise Architect ............................................................................... 288 Two Types ........................................................................................................................................ 288 Type 1 ................................................................................................................................................ 291

Requirements .................................................................................................................................................................... 291 Duties................................................................................................................................................................................... 293

Type 2 ................................................................................................................................................ 295

Requirements .................................................................................................................................................................... 295 Duties................................................................................................................................................................................... 297

Adoption .............................................. 299 Guidance .................................................................................................. 301 What Is EA ....................................................................................................................................... 303

Bridging the Gap .............................................................................................................................................................. 303 You Decide ......................................................................................................................................................................... 306 Solution Architecture ....................................................................................................................................................... 309 160 Char Challenge........................................................................................................................................................ 311 Overall.................................................................................................................................................................................. 315

Frameworks...................................................................................................................................... 324

Why use a PM Framework?......................................................................................................................................... 324 Why use an EA Framework?........................................................................................................................................ 326

Where to Start? .............................................................................................................................. 329

Can I start with one Department? ............................................................................................................................. 329 EA Catalysts ....................................................................................................................................................................... 332 Vision .................................................................................................................................................................................... 336 Goals .................................................................................................................................................................................... 339 Strategies ............................................................................................................................................................................ 343 Tactics.................................................................................................................................................................................. 346 Objectives............................................................................................................................................................................ 349

Appendix .............................................. 351

Background .............................................................................................. 353 Why Were They Created? ........................................................................................................... 353 When Were They Created? ........................................................................................................ 353 Where Did They Come From? ................................................................................................... 353 How Were They Created? ........................................................................................................... 356 What Was Used to Create Them?............................................................................................. 357 The Author....................................................................................................................................... 359

Keypoints .................................................................................................. 363 Sources & Resources ............................................................................... 401

PR F

Foreword - 1

FOREWORD

OO F

2 - Foreword

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.

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/credibility-commentstraining.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 out-puts 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?

Frameworks

Frameworks - 41

FRAM E WO RKS

OO F

42 - Frameworks

Frameworks

KEYPOINT: The Frameworks section of PF2

introduces the Frameworks that are part of the Pragmatic Family.

Questions to Ponder

OO F

Frameworks - 43

Frameworks

Compar is ons TOGAF & Z achman

Here we present a method of categorising frameworks and ontologies. The vertical axis ranges between the Theoretical and the Concrete, while the horizontal axis ranges between the Simple and the Complex. The green area illustrates a domain of balance between these extremes, where the 80/20 rule applies and a good balance between simplicity and complexity and between theory and concreteness is achieved. The red area illustrates a range where these categorisations stray too far into extremes and the opposite of the 80/20 rule applies. The blue area illustrates a range between these points.

♦ Zachman is an Ontology and is therefore Simple & Theoretical. However, it could

be said that it is too Simple and too Theoretical to enable easy adoption. It effectively provides Contextual guidance. ♦ TOGAF is very Concrete and Complex. It could be said that it is too Concrete and too Complex to enable easy adoption. It effectively provides Physical guidance.

There is a noticeable chasm between them. Before POET and PEAF were created, many people found this chasm too wide to bridge. I have heard people who have attended Zachman training, come out and say “OK, that’s was a nice grounding. What the hell do I do now!? Where do I start!?”. Similarly, I have heard people who have attended TOGAF training, come out and say “OK, that’s was a huge amount of stuff. What the hell do I do now!? Where do I start!?” This chasm is what POET and PEAF were designed to fill.

♦ POET is an Ontology and therefore by definition tends towards the theoretical like

Zachman. However, POET is less theoretical than Zachman with an appropriate level of complexity to make it easily usable. Zachman and POET do not compete.

44 - Frameworks

Frameworks

They are complementary to each other. It is not a question of Zachman or POET but more a question of Zachman and POET. It effectively provides Conceptual guidance. â&#x2122;Ś PEAF is a Framework and therefore, by definition, tends towards the Concrete like TOGAF. However, PEAF is less concrete with an appropriate level of complexity to make it easily usable. PEAF and TOGAF do not compete. They are complementary to each other. It is not a question of PEAF or TOGAF but more a question of PEAF and TOGAF. It effectively provides Logical guidance.

In this way, POET and PEAF bridge the chasm between Zachman and TOGAF.

OO F

KEYPOINT:

POET and PEAF bridge the chasm between Zachman and TOGAF.

ADOPTION:

Management: Use POET and PEAF to bridge the chasm between Zachman and TOGAF.

Questions to Ponder

♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦

Do you agree with this method of categorisation? If not, why not and how would you draw the diagram? Where would you place the Frameworks you currently use on this diagram? Where would you put Zachman? Where would you put TOGAF? Where would you put POET? Where would you put PEAF? How do other frameworks you use fit? What do you use to bridge the gaps between them?

Frameworks

Frameworks - 45

46 - Frameworks Mis under s tanding

Frameworks

A common misunderstanding is that people misinterpret Pragmatic’s Frameworks in two totally opposing ways. Both of which cannot be correct. People in Camp 1 say something like, “It’s all a bit high level and conceptual to be adopted. It doesn’t actually tell me what to do, and therefore, is of little practical use.” They view Pragmatic’s Frameworks as being as simplistic as a basic diagram on Aerodynamics is to a pilot. People in Camp 2 say something like, “It’s far too detailed and large to be adopted, will take too long to learn, will require massive change and therefore, is of little practical use.”

They view Pragmatic’s Frameworks as being as complicated and complex as a full Flight manual is to a trainee pilot. Plainly something is not right, as something cannot be too high level and conceptual and be too detailed and large at the same time. One of those camps must be wrong! In fact, the truth is, they are both wrong. But why do they think they are right? When someone who has not spent enough time understanding something, wishes to stop spending time understanding something, an easy getout-of-jail-free card is to reject it, and an easy way to do that is to say that it’s either too simple to be of any use, or its too complicated to be of any use. These people are not bad people. They are just “Slaves to Psychology™”

So, when people reject Pragmatic’s Frameworks, it is more to do with their understanding, which is a function of the time they have available, and the appetite they have for understanding them. The reality is that Pragmatic’s Frameworks sit in a Pragmatic area between the two. They are more detailed than the simplistic views of Camp 1 and they are less detailed than the complex views of Camp 2. To understand that Pragmatic’s Frameworks do not fit into Camp 1 or Camp2 we can refer back to the comparison of Zachman and TOGAF with POET and PEAF.

♦ Zachman is an example of a Framework that exists in Camp 1, because it is essentially just a grid and that’s it. ♦ TOGAF is an example of a Framework that exists in Camp 2, because it is horrendously complicated, inconsistent and detailed.

It is precisely because of this, that POET and PEAF were written - to bridge that chasm. Pragmatic’s Frameworks, are in the Pragmatic Camp, were we provide more information and guidance than Camp 1 believes, and less detail and complexity than Camp 2 believes.

Perhaps people categorise Pragmatic’s Frameworks in these two camps because these two camps are the only camps they have ever known, and so they lump Pragmatic’s Frameworks into the same camp as the Frameworks that they already know aka Zachman and TOGAF. Frameworks that have frustrated them in the past, for either being too high level or too complicated.

Frameworks

Frameworks - 47

48 - Frameworks

Frameworks

KEYPOINT: People incorrectly think Pragmatic

Frameworks are either too high level and conceptual or incorrectly think they are too large and detailed.

ADOPTION:

EA Project Team: Use POET and

PEAF in the way they were designed to be used.

Questions to Ponder

♦ Do you think Pragmatic Frameworks are a bit high level and conceptual to be adopted and therefore of little practical use?”

♦ Do you think Pragmatic Frameworks are far too detailed and large to be adopted and therefore of little practical use?”

♦ What time have you spent understanding them? ♦ What is your appetite to understand more?

Frameworks - 49

Frameworks

Cr iter ia

Here we see some criteria that we will use to analyse and compare PEAF, TOGAF and Zachman: Transformational Focus

♦ Strategic - Frameworks that score highly here are ones whose remit is more

towards the Strategising, Roadmapping and governance of Solutioning phases of the Transformation domain - the domains typically associated with Enterprise Architecture. ♦ Project - Frameworks that score highly here are ones whose remit is more towards the Solutioning, Elaborating, and the governance of Construction phases of the Transformation domain - the domains typically associated with Enterprise Engineering. Structural Focus

♦ Enterprise - Frameworks that score highly here are ones whose remit is more

Content

towards the structure of the entire Enterprise without limitation - the domain typically associated with Enterprise Architecture. ♦ IT - Frameworks that score highly here are ones whose remit is more towards the structure of only those parts of the Enterprise consisting of IT and the other parts of the Enterprise that are connected to IT in some way - the domain typically associated with Enterprise IT Architecture (EITA).

♦ Detail - Frameworks that score highly here are ones that are large and contain massive amounts of detail.

50 - Frameworks â&#x2122;Ś Usability - Frameworks that score highly here are ones that are easy to understand, use and deploy.

Frameworks

KEYPOINT:

Key Framework comparison criteria: Strategic vs Project, Enterprise vs IT, Detail vs Usability.

Questions to Ponder

♦ Are these reasonable criteria? ♦ If not, what criteria would you use? ♦ How would you score each Framework?

Frameworks

Frameworks - 51

OO F

52 - Frameworks Raw Scor es

Frameworks

Here we see the raw scores for each framework. Of course you may have different views and can use the Framework Comparison Toolkit Spreadsheet in PEAF to modify them as you wish with a resulting changing of overall scores.

KEYPOINT:

Raw Scores given by Pragmatic show PEAF in the lead.

Questions to Ponder

♦ ♦ ♦ ♦ ♦ ♦

Do you agree with the categories? If not, which would you remove or add? Why? Do you agree with these raw scores? If not how would you change them? Why did you change them in the way you did?

Frameworks

Frameworks - 53

OO F

54 - Frameworks Over all

Frameworks

TOGAF TOGAF’s Transformational focus is mainly on the Solutioning and Elaboration phases of projects and the governance of Construction. It does cover Roadmapping to a small degree but only really from the point of Roadmapping for a very large project or a program. It doesn’t cover Construction or Transitioning and its Structural focus is very IT oriented. It does provide a large amount of detail but largely because of this and other issues it is not very usable and difficult to implement. Zachman

♦ Zachman’s Transformational focus is largely strategic in nature and does cover most of the project domain but is very IT oriented. It doesn’t provide much detail at all and not much guidance on how to use it either. PEAF

♦ PEAF’s Transformational focus is on the Strategising, Roadmapping and Governance of the Solutioning phases of the Transformation domain. Structurally it includes IT but is not limited to IT, instead covering the entire Enterprise domain. It offers a moderate amount of detail and concentrates mostly on the fundamentals that Enterprises need to get right. Because of this it is extremely usable and provides a lot of help to implement it - The Adoption section - which constitutes the Maturity Model.

KEYPOINT:

The EA framework you choose,

depends on what you want from your EA framework.

ADOPTION:

EA Project Team: Decide what you want from an EA framework.

Questions to Ponder

♦ Do you agree with these overall ratings? ♦ If not, what would you change?

Frameworks

Frameworks - 55

56 - Frameworks Example Weightings #1

Frameworks

Even if you accept the raw scores provided by PEAF or change them, you may also place a different emphasis on each category, favouring some more than others. This will also change the resultant scores. Here we see how the scores change if you make Project level guidance and Detail your preference.

KEYPOINT:

If you favour Project guidance and

Detail, rather than Strategic guidance

and Usability – then TOGAF is clearly for you.

Questions to Ponder

♦ Are these weightings what you would choose? ♦ If not, what would you choose?

Frameworks

Frameworks - 57

OO F

58 - Frameworks Example Weightings #2

Frameworks

Here we see how the scores change if you make Strategic level guidance and Usability your preference.

KEYPOINT:

If you favour Strategic guidance and Usability, rather than Project

guidance and Detail – then PEAF is clearly for you.

Questions to Ponder

♦ What weightings would you assign to each category? ♦ Why? ♦ What is the result of those weightings?

Frameworks

Frameworks - 59

60 - Frameworks TOGAF Now What ?

Frameworks

So, you've been on a TOGAF course. Great! There are many good things in TOGAF, but being able to deploy and use them is a different ball game. Putting aside the conflicts of language within TOGAF created by the committees used to produce it, it does not explain how to adopt it very well. It is also missing some things of such fundamental importance, that using TOGAF without understanding these things and putting them in place will likely set you up for failure before you begin. PEAF4TOGAF is a small subset of the PEFF/POET/PEAF content, specifically selected to help people who understand TOGAF, to deploy it and use it effectively.

KEYPOINT:

PEAF provides the Bootstrap to

kickstart your TOGAF adoption.

ADOPTION:

Enterprise Architect: Use PEAF to set the context, to decide what parts of TOGAF to use where and when.

Questions to Ponder

♦ Have you used TOGAF? ♦ What did you do in the Preliminary Phase? ♦ Did you get the mandate and resources required to increase your maturity?

Frameworks

Frameworks - 61

62 - Frameworks Content vs Benefi ts

Frameworks

Here we illustrate a simple comparison between TOGAF and PEAF. PEAF was never designed to be 100% complete or all encompassing. PEAF was built by an Enterprise Architect, for Enterprise Architects (or people wishing to move into that role, or management wishing to understand EA) in real world scenarios, by observing and experiencing EA failure, and then creating a Pragmatic set of fundamentals things to prevent other Enterprises making those same fundamental mistakes. In comparison, TOGAF has been built by committee and aims to be 100% complete. In doing so, TOGAF has missed the 20% of the fundamentals things any Enterprise needs to get right, BEFORE, they start to expend 80% of the effort to gain the remaining 20% benefit. In essence, if you have adopted PEAF, a case could be made to use TOGAF to gain the remaining 20% of benefit. However, as many Enterprises have found, adopting TOGAF before you have adopted PEAF is foolhardy - you cannot gain the remaining 20% of benefit before you have first put in the place the 20% (and gained the 80% benefit) of fundamentals that PEAF provides. This is the reason why 99% of EA initiatives fail. Not because they tried to adopt TOGAF. But because they tried to adopt TOGAF, before adopting PEAF. Another related point is that, because of TOGAFâ&#x20AC;&#x2122;s size/complexity/detail, TOGAF requires a huge amount of customisation in order to adopt it. In addition, TOG provides nothing to aid an Enterprise in this regard. As a comparison, because of PEAFâ&#x20AC;&#x2122;s simplicity, PEAF requires minimal customisation in order to adopt it. In addition, Pragmatic provides the Pragmatic Publishing Platform (P3) to allow Enterprises to not only customise it as they see fit, but to also publish the content to their intranet, produce physical and kindle books, and allows the creation and operation of in-house exams based on the customised content.

Many people say that no one is supposed to adopt TOGAF out-of-the-box, and in fact, adopting it out of the box is impossible. PEAF can be adopted out-of-the-box.

Frameworks

Frameworks - 63

64 - Frameworks

Frameworks

KEYPOINT: PEAF provides the 20%

(fundamentals) that yields 80% of the benefit. TOGAF provides the 80% (details), that yields 20% of the benefit.

ADOPTION:

EA Project Team: Utilise PEAF to put in place the 20% (fundamentals) that yields 80% of the benefit.

Questions to Ponder

â&#x2122;Ś Do you agree with this assertion? â&#x2122;Ś If not, why not, and how would you draw the diagram?

Frameworks - 65

Frameworks

Over all

Here we see a high-level mapping of how TOGAF and the Pragmatic Frameworks relate to each other. It should be noted that POET and PEAF map to the same areas of TOGAF, but POET's content covers the whole of the Transformation capability (of which EA is only a part), whereas PEAF's content only covers the EA part.

♦ TOGAF Part I – Introduction, maps to the Introduction and Frameworks sections of PF2 and the Language and Ontologies sections of PEFF.

♦ TOGAF Part II – ADM, maps to the Adoption sections of PEFF, POET and PEAF (Preliminary phase), and the Methods sections of POET and PEAF.

♦ TOGAF Part III – ADM Guidelines & Techniques, maps to the Guidance sections of

POET and PEAF. ♦ TOGAF Part IV – ACF, maps to the Artefacts sections of POET and PEAF. ♦ TOGAF Part V – Enterprise Continuum and Tools. It's difficult to map because it includes many different things. When it's talking about Tools, it maps to POET and PEAF's Items section. When it's talking about the information those tools manipulate, it maps to POET and PEAF's Artefacts section, and when it's talking about how to use those tools, it maps to POET and PEAF's Methods section. ♦ TOGAF Part VI – ACF, maps to the MAGIC of POET and PEAF (which define the Architecture Capability). It also maps to part of the Adoption parts of PEFF, POET and PEAF because it talks of maintain the Architecture capability. As you can clearly see, the information for the Adoption of TOGAF is spread in multiple TOGAF sections whilst it is consistently identified in PEFF, POET and PEAF. This is perhaps one of the reasons what adopting TOGAF is so difficult.

66 - Frameworks

Frameworks

KEYPOINT:

PEAF covers the whole of TOGAF and more.

ADOPTION:

Enterprise Architect: Understand

which parts of PEAF to use to aid TOGAF.

Questions to Ponder

♦ Have you used TOGAF? ♦ What did you do in the Preliminary Phase? ♦ Did you get the mandate and resources required to increase your maturity?

Frameworks

Frameworks - 67

68 - Frameworks ADM

Frameworks

Here we show how POET and PEAF compares to the TOGAF ADM. Essentially, the Adoption Sections of POET and PEAF relate to the Preliminary phase of TOGAF. We also show how the Strategising and Roadmapping phases map to the meat of TOGAF, with the Governance and Lobbying disisplines of POET and PEAF map to Implementation Governance and Architecture Change Management. Although I had thought of the phrase “an EA Bootstrap” before, Chris Forde independently thought of exactly the same phrase during discussions I had with him in April 2012. POET also includes the other phases of Transformation (Engineering) that TOGAF lacks. Pragmatic‘s frameworks are much more about making the necessary fundamental changes to an Enterprise’s Transformation capability - defining what those changes are, why they are important and getting the mandate and resources to make those changes, so that the Enterprise can increase its Transformation Maturity to an appropriate level.

KEYPOINT:

Start with POET and PEAF, and then move on to TOGAF if required.

ADOPTION:

Enterprise Architect: If using TOGAF, use PEAF as a bootstrap

Questions to Ponder

♦ Have you used TOGAF? ♦ What did you do in the Preliminary Phase? ♦ Did you get the mandate and resources required to increase your maturity?

Frameworks

Frameworks - 69

70 - Frameworks Other Fr amewor ks

Frameworks

Here we show how other frameworks map on to the Transformation cascade (From strategy to Deployment) that POET defines. The ellipses of POET show the phases of transformation while the rounded boxes show the models used. The boxes with square black lines are not models but actual physical things. In between each phase of transformation, we show the Governance and Lobbying disciplines of POET (using Transformation Debt™) which, as you will see later, is the key to making the whole coherent, connected and aligned. The structure of the Enterprise is represented by the MAGIC of the Enterprise. Each of these is split into two categories. Things that are connected to (use) the IT of the Enterprise and things that are not. So, for example, there are Methods (Processes, etc) that are connected to (use) IT, but there are other processes in the Enterprise that are not connected to (use) IT. This is also true for The Artefacts and Culture columns. The Items column represents different technologies that the Enterprise uses and is split into one column for Information Technology, and one column for all other technologies (Mechanical, Electrical, Biological, Chemical, etc) These categories will be used to overlap various frameworks on, so we can see where each fits and where the overlaps or gaps are. The thick black line across the diagram marks the delineation between Project Portfolio Planning above and Project Execution below. Zachman® Zachman is an Enterprise Structure Framework, which maps almost one-to-one to POET’s structural and transformational levels although we also show the missing Perspective and Model. It should also be noted that this mapping is only general as there are other anomalies such as Zachman’s Architect and Engineer perspectives (shown in Yellow and Green) which are actually fundamental perspectives which occur at all levels not just at one.

Frameworks - 71

♦ Vertically although it includes some Roadmapping it is mainly concerned with

projects, but only goes down to the Elaboration level, playing only a governance role to Construction and Transitioning. ♦ Horizontally the blue boxes show that it only covers IT things in the Items column and does not cover any other technologies. It only covers the Methods connected to IT, the Artefacts connected to IT and does not cover Culture at all.

PEAF™ PEAF is an Enterprise Architecture Framework, for two reasons:

♦ Vertically - it covers the Strategising and Roadmapping phases and is therefore

concerned more with strategic cross-project things rather than tactical project-specific things. It is concerned with projects a little, but only from the EA Governance perspective - down to projects and Lobbying up from Projects - This is where the concept of Transformation Debt™ comes in that you will see later. ♦ Horizontally - it covers the entire enterprise including but NOT LIMITED to IT. It covers the MAGIC of the entire Enterprise.

PEEF™ PEEF is an Enterprise Engineering Framework, for two reasons:

♦ Vertically - it covers the Solutioning to Transitioning phases and is therefore

concerned more with tactical project-specific things rather than strategic cross-project things. It is concerned with the entirety of projects. ♦ Horizontally - it covers the entire enterprise including but NOT LIMITED to IT.

Frameworks

TOGAF® TOGAF is mostly a Project IT Architecture (PITA) framework, for two reasons:

72 - Frameworks

Frameworks

KEYPOINT: POET provides an Operating model for how Zachman, TOGAF, PEAF, COBIT, ITIL (and all other

Transformation frameworks) relate to each other.

ADOPTION:

OO EA Project Team: Use POET as a canvas to understand how other

frameworks you use, relate to each other.

Questions to Ponder

♦ Do you agree with this mapping? If not what would you change? ♦ Which Frameworks do you use? ♦ Which overall framework for Transformation do you use to map other to?

Frameworks - 73

Frameworks

Other Detail

Here we show an expanded view of the IT part of the (technology) Items, to allow us to map COBIT® ITIL® and IT4IT®.. COBIT® COBIT is an IT Governance & Management Framework, and covers Roadmapping and all project phases, plus the Operations domain (of IT Services). COBIT is an IT Governance & Management Framework, and covers four main domains:

♦ Evaluate Direct, Monitor (EDM) and Align, Plan Organise (APO) map to the Management domain of the Roadmapping level of POET.

♦ Build, Acquire, Implement (BAI) maps to the Management domain of the Roadmapping Solutioning, Elaborating, Constructing and Transitioning levels of POET. ♦ Monitor, Evaluate, Assess (MEA) maps to the Governance domain/interface between the Roadmapping Solutioning, Elaborating, Constructing Transitioning and Using levels of POET. ♦ Deliver Service & Support (DSO) maps to the Using domain of the Operation/Support domains of DOTS.

ITIL® ITIL is a Service Management Framework. In its original form, it only covered the Service Operation or Management area, but over recent years has grown up the transformation stack although its domain is still only really IT Services.

♦ Service Strategy maps to the Roadmapping phase. ♦ Service Design maps to the Solutioning and Elaborating phases. ♦ Service Transition maps to the Constructing and Transitioning phases.

74 - Frameworks

IT4IT® IT4IT is a reference model for the IT used by the IT department of an Enterprise. Its width is narrow because it shows that it does not cover the IT for the entire Enterprise, but only the IT used for the IT department of the Enterprise. It does, however, extend up into the Roadmapping and Strategy phases, and down into the support area also.

Frameworks

♦ Service Operations maps to the Operation domain. ♦

♦ Strategy to Portfolio maps to the Strategising and Roadmapping phases. ♦ Requirement to Deploy maps to the Solutioning, Elaborating and Constructing phases. ♦ Request to Fulfil maps to the Operation domain. ♦ Detect to Correct maps to the Support domain.

DevOps DevOps is a software development framework. It is a mindset, a culture, and a set of technical practices that combines software development (Dev) and information technology operations (Ops) to shorten the systems development life cycle while delivering features, fixes, and updates frequently .in close alignment with business objectives. Key aspects of DevOps are:

♦ Coding – Code development and review, source code management tools, code

merging Building – Continuous integration tools, build status Testing – Continuous testing tools that provide feedback on business risks Packaging – Artefact repository, application pre-deployment staging Releasing – Change management, release approvals, release automation Configuring – Infrastructure configuration and management, infrastructure as code tools ♦ Monitoring – Applications performance monitoring, end-user experience

♦ ♦ ♦ ♦ ♦

KEYPOINT:

Frameworks that span multiple

domains (Transformation, Operation and Support) fragment the Enterprise.

ADOPTION:

Management: Consider using

frameworks oriented around DOTS.

Questions to Ponder

♦ Do you agree with this mapping? If not what would you change? ♦ Which Frameworks do you use? ♦ Which overall framework for Transformation do you use to map other to?

Frameworks

Frameworks - 75

76 - Frameworks Guidance vs Detail

Frameworks

Here we compare frameworks in terms of the level of guidance they provide versus where they sit in the Transformation cascade (From Strategy to Deployment). The left of the diagram illustrates the 20% that provides 80% of the benefit. The right of the diagram illustrates the 80% that provides 20% of the benefit. 20% of Zachman provides very low detail and only in the structural parts of the cascade. However, it is part of the 20% that provides 80% of the benefit. POET provides more detail, and covers transformation as well as structure. It is part of the 20% that provides 80% of the benefit. PEAF provides more detail again, but only in the domain of Enterprise Architecture - Strategy, Roadmapping and the Governance of those phases. PEEF also provides more detail, but only in the domain of Enterprise Engineering - Solutioning, Elaborating, Constructing, Transitioning and the Governance of those phases. Together they complete the 20% that provides 80% of the benefit. TOGAF provides much more detail but only in Solutioning to Elaboration and the governance of Construction, although it does touch on Roadmapping. It effectively provides the remaining 80% that provides the remaining 20% of the benefit.

KEYPOINT:

POET/PEAF/PEEF provides the 20%

(fundamentals) that yields 80% of the benefit. TOGAF provides the 80% (details), that yields 20% of the benefit.

ADOPTION:

Management: Decide what is more important – A) The 20%

(fundamentals) that yields 80% of the benefit, or B) the 80% (details), that yields 20% of the benefit.

Questions to Ponder

♦ Where do the frameworks your Enterprise uses map onto this diagram? ♦ Do the frameworks you use cover the areas you need to cover? ♦ What do you use to guide the use of Frameworks?

Frameworks

Frameworks - 77

78 - Frameworks Tr ends

Frameworks

Here we see a comparison of Google Trend Analysis, between TOGAF and PEAF. The time period is the last 5 years, and the geographic area is worldwide. The graph was drawn using data downloaded from the Google Trends website: TOGAF https://trends.google.com/trends/explore?date=2008-01-01%202020-05-27&q=togaf PEAF https://trends.google.com/trends/explore?date=2008-01-01%202020-05-27&q=peaf There can be many reasons why one trend is decreasing, while another is increasing, but we believe it is because after many years of TOGAF not delivering the value it promises, more and more people and Enterprises, are beginning to desire a more Pragmatic approach to Enterprise Architecture.

KEYPOINT:

The trend for TOGAF is falling. The Trend for PEAF is rising.

ADOPTION:

Management: Investigate why demand for TOGAF is falling, while demand for PEAF is rising.

Questions to Ponder

♦ ♦ ♦ ♦ ♦

Why do you think the trend for TOGAF is falling? Why do you think the trend for PEAF is rising? Do you agree with these trends? Have you experienced these trends? Do you think that investigating PEAF (and POET) to see how useful they are would be Pragmatic?

Frameworks

Frameworks - 79

80 - Frameworks Z achman Bas ic Mes s age

Frameworks

Although Enterprise Architecture is only a part of the entire Transformation domain, we mention Zachman here because whilst the Zachman Ontology is known as an Enterprise Architecture Ontology, and whilst John A. Zachman is deemed to be “The Father of Enterprise Architecture”, it does in fact cover the whole Transformation domain (from Strategy to Deployment). It is, in fact, an Enterprise Transformation Ontology where the top half covers Enterprise Architecture and the bottom half covers Enterprise Engineering (although the engineering part is IT focussed). John A. Zachman is therefore “The Father of Enterprise Architecture” and “The Father of Enterprise Engineering” The basic message contained in Zachman is that “You cannot change what you cannot see” and therefore is one of modelling and models - Architectural Models and Engineering Models. POET and PEAF are built on the following conceptual ideas from the Zachman 6x6 grid:

1) Vertically - There are phases of Transformation that we need to consider - from the highest view of Enterprise Strategy to the physical deployment of change - and these phases must cover ALL the transformations we need to do to bridge that gap. 2) Horizontally - There are data used by each phase of transformation - that should be categorised - and these categorisations must cover ALL of the data we need for that phase. Zachman teaches (quite correctly) that “If you want to transform a complex Enterprise in a volatile environment, you have to a) Model (not draw) the Enterprise, b) Persist Models as Primitives.”

Modelling (not drawing) the enterprise means you need to make a distinction between drawings (which cannot be analysed or used in anyway) and models (which can be analysed and used in a multitude of ways) and therefore visual representations of things need a structured base. Persisting models as primitives means that each element in a model should be stored as separate elements, which are then brought together to create one or more models. If you are an IT person, you can think of the primitives as tables in a database and the models as SQL statements (or views) into those tables. The other statements on this graphic relate to additional fundamental things that Zachman should explain but actually incorrectly explains the exact opposite. Firstly, Pragmatic teaches us to “Use Ontologies appropriately”. This means that an ontology should be used to create metamodels, which should be used to create models. Zachman incorrectly teaches people to create models based on the Zachman ontology (since he doesn’t have a metamodel), instead of teaching people to create (and validate) metamodels on that ontology. This is because people want to create models and so since he only has an ontology, that is what is used.

Secondly, Pragmatic teaches us to “Use Architecture and Engineering appropriately”. This means that Architecture and Engineering are closely related but totally different things. Confusing architecture and engineering and architects with engineers probably creates more problems in Enterprises than everything else put together. Can you imagine what would happen if you asked an Engineer to Architect a building or an Architect to Engineer it? When Zachman was asked in a classroom (not by me) to clarify what he meant by architecture and engineering (because he had been using those words a lot and it wasn’t clear what he meant by them) Zachman replied “Oh well, some people say architecture, some people say engineering. They are the same thing really and I use the words interchangeably.”

Frameworks

Frameworks - 81

82 - Frameworks

Frameworks

KEYPOINT: You can’t change what you don’t understand.

You can’t understand what you can’t see.

ADOPTION:

Management: Decide to move away

from unstructured information, and towards modelling structured primitives.

Questions to Ponder

♦ Do you agree that “Modell (not draw) the Enterprise” and “Persist Models as Primitives” are the key messages that Zachman training delivers?

♦ If not, what other messages do you believe are important?

Frameworks - 83

Frameworks

Mis s ing Per s pective and Model

Plate A Here we see the Zachman Ontology, showing the two labels used for each row. On the left is what is referred to as “Audience Perspectives” and on the right is what Z is referred to as “Model Names” or “Representations”. These “Perspectives” and “Model Names” form a stack from high level strategy at the top to physical things in Operations at the bottom. The “Perspectives” on the left relate to people and therefore the work those people do. The “Model Names” on the right relate to the information those people use to do their work. Because of this it is more apt to move the “Model Names” down a little to sit between each of the perspectives because each model forms the output from one perspective and the input to the next as illustrated in Plate B. Plate B As we move down these perspectives and models this makes sense:

The Executives create the Context models… …which are taken by Business Management as input who create Business Models… …which are taken by Architects as input who create Logical Models… …which are taken by Engineers as input who create Physical Models… …which are taken by Technicians as input who create Configuration Models… …which are taken by Users as input who create Operational Instances ?????????

♦ ♦ ♦ ♦ ♦ ♦

Hang on … that last one doesn’t sound right at all … users don’t create Operational Instances … Users use Operational instances … so we need to move the User’s Perspective down to the correct place. Plate C

84 - Frameworks

Frameworks

OK - that’s better! Users take Operational Instances as their input and use them … correct! But this creates a hole in our diagram - a Perspective that takes Configuration Models and creates Operational Instances. We also recognise that there is another hole at the top - a Model that the Enterprise Perspective needs to use as its input.

Plate D And so we add the missing Deployer Perspective and the missing Enterprise Context Model. To be fair to Zachman, he isn’t missing the Enterprise Context Model per se, as he says that the enterprise’s context is comprised of other Enterprises, which would have their own Zachman models. This is true, but as we know Context is King™, and so we really need to show it as, from our Enterprises perspective, it is the most important.

OO F

KEYPOINT:

In the Zachman

Framework/Ontology, the Deployer perspective is missing.

ADOPTION:

Enterprise Architect: Be aware that

the Deployer perspective is missing.

Questions to Ponder

♦ Do you agree that the Deployer Perspective is missing in Zachman? ♦ If not, why not? ♦ If not, how to you reconcile the mismatches?

Frameworks

Frameworks - 85

86 - Frameworks Over all

Frameworks

Here we see how the important seeds that John A. Zachman planted have been extended and built upon by POET and PEAF. Without Johns important work it is debatable whether POET and PEAF would even exist. The height of each box is proportional to the quantity of material in each section. The core of Zachman is an Enterprise Ontology which defines Artefacts hence the larger overlap with the Artefacts section of POET. However, it is only shown just over half width because Zachman is 5/6 Structural (What, How, Where, Who, When) and 1/6 Transformational (Why) which means it only covers just over half of the full Enterprise Transformation domain. Whilst there is no methodological guidance in Zachman, there is a small overlap with the Methods section of POET because Zachman does define the notion of Transformational perspectives (Executive, Business Management, Architect, Engineer, Technician, Enterprise/Users). Context, Items and Culture are covered to a small degree in training although the Ontology itself does not.

KEYPOINT:

POET and PEAF greatly extends what Zachman provides.

ADOPTION:

Enterprise Architect: Use POET and PEAF to greatly extend what Zachman provides.

Questions to Ponder

♦ ♦ ♦ ♦

Do you agree that POET and PEAF greatly extends Zachman? If not, how would you map these things? What things do you think are in Zachman that do not exist in POET or PEAF? What things would you add to Zachman?

Frameworks

Frameworks - 87

88 - Frameworks Ar chitect/Engineer

Frameworks

Here we see how the Zachman rows maps to the POET rows. POET recognises two things about the Architect Perspective (row 3) in Zachman:

♦ An Architect’s Perspective actually covers the Strategising to Solutioning

Transformation phases, utilising the Structural information from the Contextual to Logical levels, driven by the Enterprise Context. ♦ An Architect’s perspective also exists within all of these levels depending on whether the complexity of the work at each level warrants it. POET recognises two things about the Engineer Perspective (row 4) in Zachman:

♦ An Engineer’s Perspective actually covers the Solutioning to Transitioning

Transformation phases, utilising the Structural information from the Logical to the Physical World levels, driven by the Conceptual level. ♦ An Engineer’s perspective also exists within all of these levels depending on whether the complexity of the work at each level warrants it.

Having said that, there is another way too look at it… If you consider Zachman’s rows to be more like disciplines than a cascade of work (essentially take the word perspectives and apply it ruthlessly) then the Architect and Engineering rows are correct. If this is the case, then the order of the rows is irrelevant. Aka there is no meaning to one row being at the top and another row being further down. There is an inference because the rows at the top are more likely to be done earlier and the rows at the bottom are more likely to be done later, but the Architect and Engineer rows (perspectives) could be applied at any time. In fact, the more I think about it, the more I think that the architect and engineer rows should not be rows but should be disciplines that could be utilised on any of the other perspectives.

This would mean that we need new names for the architect and Engineer perspectives. Designer and Builder sound like good ones to me. So, we end up with something like the graphic below.

Project Planning, Project Mgmt, Change Mgmt Configuration Mgmt, Testing

Deploying

Analysis & Design

Implementing

Requirements Mgmt

Discovery, Governance & Lobbying, Decision Making, Modelling

Enterprise Context Context Models

Strategising

OO Roadmapping

Designer Perspective Business Service Deployers)

Builder Perspective Business Service Deployers)

Initiating

Elaborating

Constructing

Deployer Perspective

Transitioning

Business Service Deployers)

Frameworks

Frameworks - 89

90 - Frameworks

Frameworks

So, what this diagram illustrates, is that we consider the Architects and Engineers â&#x20AC;&#x153;perspectivesâ&#x20AC;? more as disciplines rather than phases, while we consider the other perspectives, more as perspectives rather than disciplines, but those perspectives map one2one with Phases. I feel we are getting further, but I also feel I have not found the most elegant description.

KEYPOINT:

Zachman’s Architect and Engineer rows are wrong, because

Architecture and Engineering can be performed at any row.

ADOPTION:

Enterprise Architect: Be aware that

Zachman’s Architect and Engineer rows are wrong, because

Architecture and Engineering can be performed at any row.

Questions to Ponder

♦ Do you agree that Zachman’s Architect and Engineer rows are wrong? ♦ If not, how would you map these things?

Frameworks

Frameworks - 91

92 - Frameworks Why/How

Frameworks

Firstly, at a general level, POET recognises that Why and How actually exist from level to level rather than just as a column. For each level, How that level is achieved is defined by the level below it and Why that level is the way it is, is defined by the level above it. Secondly, in general terms, it would seem sensible that the Why column should map to the Motivation column of MAGMA - however, examining the descriptions in each of the cells under the Why column reveals a mixture of Means and Ends, hence the Why column actually maps to the Motivation and Actions columns of MAGMA. Finally, rows 1 and 2 of the Why column speak specifically of Business Means and Business Ends, hence they actually map to the Motivation (ends) and Actions (means) of only the Strategising level of POET.

KEYPOINT:

Zachman’s Why and How columns, only equate to the Motivation and Actions of MAGMA.

Why and How are also questions

answered by moving up and down the rows, not columns.

OO ADOPTION:

Enterprise Architect: Be aware that Zachman’s Why column contains

Means (How) and Ends (Why), and the How column relates to the

Methods of the thing in question, not the How of Transformation.

Questions to Ponder

♦ Do you agree that Zachman’s Why and How columns are a little strange? ♦ If not, how would you map these things?

Frameworks

Frameworks - 93

94 - Frameworks How/When/ What/Wher e/ Who

Frameworks

Here we map the Zachman Ontology to the structural Ontology of POET:

♦ Rows 1 and 2 map to the top two levels of MAGIC (Contextual and Conceptual) but not completely: ♦ The How and When columns talk of processes and therefore map only to the Process sub-domain of the Methods domain of MAGIC. ♦ The What column talks in terms of business entities and therefore maps to the Artefact domain of MAGIC. ♦ The Where column talks in terms of location and therefore maps only to the Location sub-domain of the Items domain of MAGIC. ♦ The Who talks in terms of people and therefore maps only to the people sub-domain of the Culture domain of MAGIC. ♦ Rows 3, 4 and 5 map directly to the Logical, Physical and Operation levels in MAGIC, however only in relation to IT as those rows only talk in terms of systems and technologies. ♦ Row 6 maps directly to the Physical World level of MAGIC.

KEYPOINT:

Zachman’s top two rows equate to

MAGIC but the lower down you go the more IT specific it becomes.

ADOPTION:

Enterprise Architect: Be aware that

Zachman’s rows, get more IT specific

OO the further down you go.

Questions to Ponder

♦ Do you agree that Zachman gets more IT centric the further down you go? ♦ If not, why not? How would you map these things?

Frameworks

Frameworks - 95

96 - Frameworks Per s pectives and Models

Frameworks

Here we see the holistic and coherent cascade of phases and models that POET defines, from Strategic intent at the top, down to deployed change at the bottom, and how the Zachman Models and Perspectives relate to them. Zachman only references the perspectives, and not the transformations that need to occur at each level. In addition, Zachman also only references current state information related to each perspective and not the target (or intermediate) Structural states.

KEYPOINT:

Zachman’s (corrected) perspectives and models can be mapped to the Phases and Levels of POET.

ADOPTION:

Enterprise Architect: Be aware that

Zachman’s (corrected) perspectives

map one to one with POETS Phases

Questions to Ponder

♦ Do you agree that Zachman’s (corrected) perspectives map one to one with POET phases?

♦ If not, how would you map these things?

Frameworks

Frameworks - 97

Language - 99

Language

LAN GUA GE

OO F

100 - Language

KEYPOINT:

The Language section of PEFF

introduces fundamental terminology

Language

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 - 101 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…

102 - 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 - 103

KEYPOINT:

Be ever vigilant of the hidden

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

confusion that language can create.

104 - 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 - 105

106 - Language

KEYPOINT:

Everything is a System.

Language

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 - 107 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 then goes on to state that

108 - Language

Language

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 - 109

KEYPOINT:

The Word Enterprise does not mean 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

“large” or “large IT” or “senior”. It is

110 - 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 - 111

KEYPOINT:

There is no hidden connotation to “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

Pragmatic’s use of the word

112 - 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 - 113

114 - Language

KEYPOINT:

A Framework is an expression of

Best Practice comprising information

Language

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 - 115 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.

116 - 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 - 117

KEYPOINT:

Theory is just as important as

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

Practice

118 - 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 - 119

KEYPOINT: =

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

Colour

Ontologies - 121

Ontologies

O NTO LO GIE S

OO F

122 - Ontologies

KEYPOINT:

The Ontologies section of PEFF

introduces fundamental ontologies

that are used throughout Pragmatic’s Frameworks.

Ontologies

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 - 123 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.

124 - 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 - 125 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.

126 - 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 - 127 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

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.

128 - Ontologies from the rest of the Enterprise and from customers and suppliers outside the Enterprise.

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 - 129

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

Methods - 131

PR OO

Methods

M E THO DS

132 - 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 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 - 133

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

134 - 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 - 135

Methods

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

136 - 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 whole.

Methods - 137

♦ 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

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.

138 - 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 - 139

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

140 - 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 - 141

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.

142 - 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 - 143 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

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.

Methods

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.

144 - 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 - 145

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

146 - 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 - 147

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

Roadmapping Pr oces s

148 - 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 - 149 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

150 - 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 - 151

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™

152 - Methods Inter mediate Jour ney

PR Methods

Although it is important to understand where you are (Current Model), where you are going (Target Model) and why you are going there (Strategy Model), it is usually impossible and/or not desirable to create a huge plan of work to move there in one step. As in planning a very long journey, you will need to make “Pit-stops” on the way, and you may have to visit various other “Way-points” on the way. “Pit-Stops” equate to the request for and provision of annual budgets providing the fuel to continue the journey. Pit stops can also equate to knowledge. As we move along the Enterprise’s journey, there is learning. At the next pit stop, more knowledge than before is available and this knowledge will impact, favourably, the journey's execution (either by facilitating achievement of the next objective, reducing consumption of resources or speeding up decision-making and change throughout the journey. {{Pedro Correa}} “Way-points” equate to the business objectives which must be accomplished along the road to the “Destination” or Target Model. An Intermediate Model is a statement of intent for some time in the future. The time it relates to usually equates to a particular objective although Intermediate Models can also be time based such as yearly, quarterly, etc.

Methods - 153

KEYPOINT:

EA is not a destination. EA is not a journey. EA is a way of travelling.

ADOPTION:

Management: Ensure everyone in the

a destination. EA is not a journey. EA

OO is a way of travelling.

Questions to Ponder

â&#x2122;Ś Would you agree that an Enterprise's Transformation journey can be compared to a physical journey?

â&#x2122;Ś If not, what would you compare your Enterprise's Transformation journey to?

Methods

Enterprise understands that EA is not

154 - Methods Cr eate/update Inter mediate Models

PR Methods

♦ ♦ ♦ ♦

Provision: QA: Modelling: Update:

Scope Depending on which Intermediate Model is being defined, its scope, depth and detail is really a function of how far that model is in the future. If it’s the next intermediate model in terms of time, then it will be almost as detailed as the current model. For Intermediate Models that are further in the future, their depth and detail get less and less as they become more aspirational the more into the future they project. Note that for Roadmapping, we are referring here to the Conceptual layer. The Logical, Physical and Operational layers get populated and filled out as the projects in the roadmap execute. Source The information to populate the intermediate model(s) should be provided by an analysis of the Strategy, Current and Target Models. However some Intermediate Model(s) may already exist in the Enterprise in terms of diagrams, drawings and spreadsheets. When Populating the Interim Model(s) is usually done when sufficient clarity is known about one or more objectives. This usually occurs during Annual Business Planning but can also occur at any time during the year dependent upon the timescales related to the Objectives. Who Strategic Planning Team. The Board & Senior Management. Anyone trained in the tool being used. Strategic Planning Team.

Methods - 155 How Populating the Intermediate Model(s) is the result of analysing the Strategy Model, the Current Model (if it exists) and the Target Model (if it exists).

Methods

♦ Analyses Strategy, Current & Target Models ♦ Determine the number of Intermediate Models ♦ For each Intermediate Model ♦ Analyse its Objective(s) ♦ Load the information ♦ QA the information

156 - Methods

KEYPOINT:

Intermediate models satisfy Business and Technical Objectives from the Enterprise Strategy.

ADOPTION:

Enterprise Architect: Create

Methods

intermediate models to satisfy

Business and Technical Objectives from the Enterprise Strategy.

Questions to Ponder

♦ ♦ ♦ ♦

How would you describe your Enterprises long term Target? What are some of your Enterprises short and mid term business objectives? What are some of your Enterprises short and mid term IT objectives? Do people working on projects know what these objectives are?

Methods - 157

PR F

Why The Intermediate Model(s) defines WHERE the Enterprise wants to get to and WHEN. The Strategy Model defines WHY they want to get there. The Portfolio Model(s) defines HOW the Enterprise will achieve that transition, by defining the Programmes, Projects and Initiatives that are required. Scope The scope, depth and detail of the Portfolio Model(s) is not meant to provide detailed project plans. The Portfolio Model(s) should provide only enough detail to be able to organise all of the change required to move from one state (Current or Intermediate Model) to another state (Intermediate or Target Model). In addition, the scope, depth and detail of the Portfolio Model(s) will get less and less the further into the future they get. Source Initially an Enterprise will almost certainly already have one or more Portfolio Models in spreadsheets, documents and/or in portfolio analysis tools. Therefore, initially, the Portfolio Models may not be the optimum mix depending upon the Intermediate state the Enterprise wishes. In this situation the Portfolio Model and the resultant linkages back to an Intermediate Model may well illustrate shortcoming of the existing portfolio. As time progresses however, the Portfolio Model(s) will increasingly get their information and become much more dependent upon the Intermediate Model(s). When Predominantly during the Annual Business Planning cycle, although adjustments may need to be made as the year progresses.

Methods

Cr eate/update Por tfolio Model

158 - Methods Who Provision: QA: Modelling: Update:

Strategic Planning Team. The Board & Senior Management. Anyone trained in the tool being used. Strategic Planning Team.

♦ ♦ ♦ ♦

How Populating the Portfolio Model is the result of analysing the Strategy Model and the Current Model.

♦ ♦ ♦ ♦

Analyse the Intermediate Model QA the information Load the information Integrate the Information

Methods

Methods - 159

KEYPOINT:

The Project Portfolio effects transformation between the intermediate models.

ADOPTION:

project portfolio to effect

transformation between the intermediate models.

Questions to Ponder

♦ ♦ ♦ ♦

What does your Enterprise's project portfolio roadmap look like? Is it multi year and moving towards a strategic structural goal? Is the amount of working being done in a strategic way increasing over time? Is the amount of working being done in a tactical way increasing over time?

Methods

Enterprise Architect: Create a

160 - Methods Enter pr is e Tr ans for mation Str ategy

PR Methods

And so, we effectively have a Business Transformation Strategy, which defines the current, target and intermediate states of Business entities, and the roadmap of projects and programmes required to effect the transformation of them over time. And we have an IT Transformation Strategy, which defines the current, target and intermediate states of IT entities, and the roadmap of projects and programmes required to effect the transformation of them over time. However, as we have seen, the business and IT are inextricably linked and the line between the two is very blurred. Therefore what we really end up with, is an integrated Enterprise Transformation Strategy, which defines the current, target and intermediate states of integrated Business and IT entities, and the integrated roadmap of projects and programmes required to effect the transformation of them over time.

Methods - 161

KEYPOINT:

The Enterprise Transformation

Strategy is composed of interlocking Business and IT Transformation Strategies.

Enterprise Architect: Create the

Enterprise Transformation Strategy

by creating interlocking Business and IT Transformation Strategies.

Questions to Ponder

♦ Does your Enterprise have an integrated business and IT Transformation strategy? ♦ Does your Enterprise use these terms? ♦ Who is Accountable and Responsible for producing it?

Methods

ADOPTION:

Artefacts - 163

PR OO

Artefacts

ARTE FACTS

164 - 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 - 165 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.

166 - 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 - 167 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

168 - 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 - 169

KEYPOINT:

Business Architecture, Enterprise Architecture and Solution

Architecture information are closely related.

ADOPTION:

Management: Ensure everyone in the

are part of BA, EA, SA and Enterprise 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

Enterprise understands which levels

170 - 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 - 171

KEYPOINT:

This is the complete map of information required for

Transformation to be executed in an

Effective, Efficient, Agile and Durable way.

ADOPTION:

Transformation to MAGIC and

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

Management: Map the Artefacts of

172 - Artefacts Models

PR Artefacts

In order for people to understand POETs fundamental structural and transformational ontology, here we map the names of common documents/models/artefacts etc, that many people are familiar with (although perhaps, not everyone defines them in the same way!) Looking at the top of the diagram, this information corresponds to what many people refer to as the Business Model. It corresponds to the Enterprise Context level. Since this information is part of the Direction domain, the specific ontologies used are defined in POED. Any metamodels actually used, can be very business dependant (and dependent upon the C-Suite’s experience) but typically utilise things like the Business Model Canvas (BMC) as illustrated here. On the right we can see the Structural information represented at different levels of Idealisation/Realisation, with names that are commonly used to refer to parts of it.

♦ The Capability Model corresponds to the Contextual level of MAGIC. It defines ♦ ♦

♦

the fundamental capabilities required to support and enable/operationalise the Business Model. The Operating Model corresponds to the Conceptual level of MAGIC. It defines the highest level structural view of the Enterprise, required to deliver the Capability Model. The Solution Architecture corresponds to the Logical level of MAGIC. It defines (for each solution/project) the logical designs. The Detailed Design corresponds to the Physical level of MAGIC. It defines (for each solution/project) the physical designs. The Operational Design corresponds to the Operational level of MAGIC. It defines the actual things being rolled out, including the CMDB which represents a model of all the IT that is being rolled out.

Artefacts - 173 On the left we can see the Transformational information represented at different levels of Idealisation/Realisation, with names that are commonly used to refer to parts of it.

♦ The Business Motivation Model corresponds to the Contextual level of

MAGMA. It defines (at a high level) what the Enterprise wishes to achieve (Ends), and how it proposes to achieve them (Means). ♦ The Roadmap Model corresponds to the Conceptual level of MAGMA. It defines the actions that must be taken to structurally change the Enterprise from the current Structural state, through Intermediate Structural states, towards the Target Structural state.

The remaining levels of Transformational information (as defined by MAGMA) tend to be considered more in terms of the type of information existing rather than centred around the levels themselves. People generally talk of Requirements, Plans, Principles, Metrics and (hopefully, but not generally) the Rationale for decisions.

♦

♦ ♦

♦

part of MAGMA, and provide more and more clarity about what is driving the Transformation. Project Plans correspond to the Logical to Operational levels of the Actions part of MAGMA, and provide more and more clarity about how the transformation will be executed. Principles, Policies & Standards correspond to the Logical to Operational levels of the Guidance part of MAGMA, and provide more and more clarity about what guides how the transformation. Metrics correspond to the Logical to Operational levels of the Measures part of MAGMA, and provide more and more clarity about how we are measuring progress and success. Decision Rationale correspond to the Logical to Operational levels of the Assessment part of MAGMA, and provides more and more clarity about the decisions that have been made and why.

There are another two common used names that are composed of parts of this information. Namely:

♦ The Enterprise Strategy (shown with a blue line), which consists of the Business

Motivation Model and Capability Model set in the context of the Business Model. ♦ The Transformation Strategy (shown with a green line), which consists of the Roadmap Model and Operating Model, set in the context of the Business Motivation Model and the Capability Model.

Artefacts

♦ Requirements correspond to the Logical to Operational levels of the Motivation

174 - Artefacts

KEYPOINT:

Enterprise Strategy is the Business

Motivation and Capability models, set in the context of the Business Model. Transformation Strategy is the

Roadmap and Operating models, set in the context of the Capability and Business Motivation modelsâ&#x20AC;&#x2122;

Artefacts

Artefacts - 175

ADOPTION:

Management: Ensure that all parts of the Enterprise understand the

dependencies between the Business model, the Business Motivation

model, Capability models, Operating models and Roadmap models.

Management: Ensure that all parts of

the Enterprise understand the

Strategy and Transformation Strategy.

Questions to Ponder

♦ Where does your Enterprise’s Business Model, Business Motivation Model, Capability Model, Roadmap and Operating Model fit into your Enterprises Transformation domain? ♦ Do you have the required basic information, in a usable format, to allow your Enterprise to produce the Business Motivation Model and Operating Model? ♦ Do you have the required basic information, in a usable format, to allow your Enterprise to produce the Roadmap and Operating models?

Artefacts

dependencies between the Enterprise

176 - Artefacts Meta-models

PR Artefacts

If we intend to model all the information we have identified, we will need a Metamodel, aka a list of Entities and their Relationships of the things that we will model. It would be nice to choose one, however in reality, one Metamodel to cover the entire Transformation domain does not exist and so a hybrid approach is needed. Here we see an example of a full hybrid meta-model, constructed by taking the most appropriate things from various meta-models from various frameworks, and producing a metamodel with 100% coverage. We say 100% coverage because it covers both Structural and Transformational information, from a Strategy to Deployment perspective. You may be surprised that the part that Pragmatic contributes (in red) is so small. This is perfectly understandable as Pragmatic have always asserted that lack of meta-models has rarely been the reason for EA’s failure and since there are already a multitude of Metamodels already in existence it would be churlish to re-invent the wheel so to speak. Pragmatic has, however, made a massive contribution by the introduction of Transformation Debt™ Agreements (TDAs) that allow the exposing and management of Transformation Debt™. In addition Pragmatic's contribution is by the definition of the Ontology that all these other frameworks co-exist within, aka DOTS, MAGIC and MAGMA. Having said that, it has become obvious over time, that the lack of a single coherent metamodel, coupled with the difficulty most tools have in using hybrid metamodels, creates a massive problem for Enterprise and therefore a full Pragmatic Metamodel is in production, which will cover all domains and all levels.

Artefacts - 177

KEYPOINT:

There is no single metamodel, that

covers all the information required for Transformation.

ADOPTION:

EA Project Team: Develop a Hybrid Metamodel for Enterprise

OO modelling.

Questions to Ponder

♦ ♦ ♦ ♦ ♦ ♦

What Hybrid Meta-model are you currently using? Is this a good starting point for a complete and Pragmatic meta-model? Who could create such a hybrid meta-model? How would you implement such a hybrid meta-model? How long would it take to create? Are there any tools that can implement and utilise Hybrid Meta-models?

Artefacts

Architecture and Engineering

178 - Artefacts Str uctur al & Tr ans for mational

PR Artefacts

In this section, we look at the Artefacts of EA. The artefacts deal with the structures required for Structural (WHAT) and Transformational (WHY & HOW) description. Most frameworks and ontologies focus only on Artefacts and within Artefacts only the Structural (WHAT). When you see the MAGIC that Pragmatic's frameworks expose, it might make you wonder how much value they contain wile missing so much. It is understandable however, that people concentrate on Artefacts as they are very â&#x20AC;&#x153;tangibleâ&#x20AC;? - the things being produced and consumed - but also because many frameworks come from IT departments and IT people, and IT people love datamodels, ontologies and Meta-models, and those types of things are reasonably easy to produce. Methods, Guidance, Items and Cultural things are much harder to produce and therefore tend not to be. Here we consider the Artefacts for the whole Transformation domain (as defined by POET) and highlight the Artefacts within the EA domain. Essentially, we are concerned with the Transformational and Structural information utilised by the Roadmapping phase (as defined in the Methods section) and the associated Governance/Lobbying work down to projects. The structural information (MAGIC) and transformational information (MAGMA) that is produced, is represented at the Conceptual level. We also show the Contextual information, not because it is produced by EAs (although EAs do contribute to it) but because it forms the input for the EA (Roadmapping) work.

Artefacts - 179

KEYPOINT:

Enterprise Context, Contextual and Conceptual information levels are part of the EA domain.

ADOPTION:

Management: Ensure everyone in the Enterprise understands which levels

Questions to Ponder

♦ In what way does your Enterprise consider Transformational and Structural models ♦ ♦ ♦ ♦ ♦

at these levels? What ontologies and Meta-models are you using? How do they map to, and fit into this 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

of information relate to EA.

180 - Artefacts Models

PR Artefacts

Here we show the common names for the various domains in the EA Ontology. Many people use these terms (and others) but what they are exactly, and more importantly how they relate to each other, tends not to be clear. This is very worrying since they are all interrelated and depend on each other in complex ways. Not knowing or realising these relationships exist, causes Enterprises to try to create one or more of them without the required input information to do so. Or, if that information exists, to not relate one to the other and hence mistakes of monumental importance can remain hidden until much later when their impact is great, which tends to drive people to minimise or ignore them until something catastrophic happens. Not a good way to manage anything.

Artefacts - 181

KEYPOINT:

Enterprise Strategy is the Business

Motivation and Capability models, set in the context of the Business Model. Transformation Strategy is the

Roadmap and Operating models, set in the context of the Capability and

Artefacts

Business Motivation models.

182 - Artefacts

ADOPTION:

Enterprise Architect: Support the

creation of the Enterprise Strategy, by modelling the Business Model, Business Motivation Model and Enterprise Capability Mode.

Enterprise Architect: Create the

Transformation Strategy, by creating

the Roadmap Model and Operating Model.

Artefacts

Questions to Ponder

♦ Do people in your Enterprise understand what these terms are? ♦ Do they understand how they relate? ♦ Do you have any of these things defined despite the input information for their creation was not available? ♦ Do you have any of these things defined and not related to each other? ♦ What do you need to do to improve this situation?

Artefacts - 183 Relations hips

Here we see an outline of the information required to perform the roadmapping phase that constitute “doing” Enterprise Architecture and forms the basis for a project to perform the required work. The information flows into the portfolio of projects that effect the change defined by the roadmap. We also include the Business, Capability and Motivation model work (Business Architecture) because if this work is not done to the required standard, and/or its output is no represented and accessible in a reasonable way, the EA work is likely to produce far from optimum results. (aka pants!). Working up from the bottom:

♦ The Physical World, essentially defines what the current capability model is. ♦ Projects defined by the Transformational Roadmap, modify this real world, and by

doing so, deliver the Target Operating Model. ♦ The Target Operating Model, in turn, delivers the Target Capability Model and the Objectives from the Business Motivation Model, both of which are driven by the Current Capability Model. ♦ Thus, the Target Capability Model, ultimately delivers the Target Business Model. To initiate the work. a Project Brief (PRINCE2) or Project Charter (PMBOK) is required. PMBOK’s definition of a Project Charter is:

“…the document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. PRINCE2’s definition of a Project Brief is:

Artefacts

PR The r eas ons the wor k is r equir ed

184 - Artefacts

“… used to provide a full and firm foundation for the initiation of the project. Nothing should be done until certain base information needed to make rational decisions about commissioning of the project is defined, key roles & responsibilities are resourced and allocated, and a foundation for detailed planning is available.” Lets define what we mean by these things:

♦ Business Models ♦ Used to discuss and document how the Enterprise will generate revenues

Artefacts

and make a profit. It explains what products or services the business plans to manufacture and market, and how it plans to do so, including what expenses it will incur. ♦ Comprises information such as Customer Segments, Customer Relationships, Channels, Value Propositions, Cost Structure, Revenue Streams, Key Activities, Key Resources, Key Partnerships. ♦ Created by the board supported/facilitated by the EA offering structures to capture the information and ensuring the result is complete and consistent and raising Technology catalysts where appropriate. ♦ Industry standard used - Business Model Canvas ♦ Business Motivation Model ♦ Used to discuss and document the Enterprises business plan in terms of what it wants to achieve, how it will achieve those ends and what will guide the business ♦ Comprises information such as Vision, Goals, Objectives, Mission, Strategies, Tactics, Business Principles, Policies, Rules and Standards. ♦ Created by the board supported/facilitated by the EA offering structures to capture the information and ensuring the result is complete and consistent and raising Technology catalysts where appropriate ♦ Industry standard used: OMG - Business Motivation Model ♦ Capability Models ♦ Describes the complete set of capabilities an Enterprise requires to execute its Business Model and fulfil its mission. ♦ Comprises information such as organizational level skills embedded in people, processes, and technology. ♦ Created by the EA with the C-Suite. ♦ Industry standard used: PEAF – MAGIC (Methods, Artefacts, Guidance, Items and Culture) ♦ Operating Models ♦ An abstract or visual representation of how an organization delivers value to its customers or beneficiaries as well as how an organisation actually runs itself. It is the highest level structural view of the Enterprise. ♦ Comprises information such as Business Functions, Products, Information, Ethics, Roles, Countries, Technologies (including but not limited to Information Technology). ♦ Created by the EA with the C-Suite.

Artefacts - 185 ♦ Industry standard used: PEAF – MAGIC (Methods, Artefacts, Guidance, Items

and Culture) ♦ Roadmap ♦ Describes the programs, projects and initiatives needed to change the Methods, Artefacts, Guidance, Items and Culture of the Enterprise from the Current state to the Target state in order execute the Enterprise Strategy. ♦ Comprises an interrelated set of projects programs and initiatives related to the Target Capability model Principles, Policies and Standards used to guide them. ♦ Created by the EA. ♦ Industry standard used: PEAF – Principles.

Artefacts

Since the way “doing” Enterprise Architecture (aka Roadmapping) is the same regardless of the Enterprise type, Pragmatic provides a default Project Brief document and PowerPoint briefing presentation, that contains 95% of what is required to initiate the work.

186 - Artefacts

KEYPOINT:

Make sure you have the correct input information for the model you are building.

ADOPTION:

Management: Ensure EAs have the

information required to do their job.

Artefacts

Questions to Ponder

♦ Do these models and relationships agree with those used by your Enterprise? ♦ What does your Enterprise use to express each of these models? ♦ Is it clear to the people in your Enterprise, what these models are and the dependencies between them?

Items - 187

PR OO

Items

ITE M S

188 - Items

KEYPOINT:

The Items section of POET defines 'WHAT' tools and frameworks are required, 'WHERE' and 'WHEN'.

ADOPTION:

C-Suite: Instigate a review of the

Tools and Frameworks used in the

OO Enterprise's Transformation

Capability, to determine if their maturity is appropriate.

Items

Questions to Ponder

♦ With respect to your Enterprises Transformation capability, what Items ♦ ♦ ♦ ♦

(Frameworks/Tools) is used? Are those Frameworks/Tools 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?

Items - 189 The Ar chitectur e Par adigm™ What is Ar chitectur e

“The fundamentally important structure of the whole of X...” The first import term here is “fundamentally important”. What does that mean? It means things of “Architectural significance”. What does that mean? That’s a bit more difficult to pin down, because what is architecturally significant changes depending on many factors, most of which come from the context. The second important term here is “the whole of”. This means we do not look at only one part of X, we look at the whole of X. In its entirety. So, that sounds like a good definition.

“The fundamentally important structure of the whole of X...” And that is where many definitions and peoples understanding of Architecture ends. But it is missing the most crucial and important aspect… “… set in the context of things outside of X that affect X, or are affected by X.”

Items

PR The Architecture Paradigm™ exists to help people deal with the Structural Complexity and Transformational Volatility of things. When things get too volatile or too complex, The Architecture Paradigm™ can help. But what do we really mean by “Architecture”? Here we see an illustration of what we define to be a system. A system can represent anything; a boat, a car, an application, a business process an Enterprise. We can also see that any system exists within a context. A context that is made up of other systems, in whole or in part. So what do we define architecture to be? The architecture of anything (X) is…

190 - Items

Items

So, when you consider the architecture of something (X in this case) we do not only look at X. We also look at what is outside of X. It’s context. And as we have learned before, since “Context is King™”, one might say that the context is the most important part of architecture, but also, the component that many people miss. Many miss this crucial aspect because most people have an engineering mind, and for engineers, the parts of X are of most importance. The Building Analogy Many people use the building analogy when talking about architecture and while there are a lot of generic similarities they differ in two extremely important respects. Firstly, the architecture of a lot of things is mostly important to be able to build them, like Buildings, while the architecture of the Enterprise is mostly important to be able to change it. To Transform it. Secondly, what is produced in the Building world is tangible, physical things that can be seen and touched - they are bound by the laws of physics, and it doesn’t matter how important you are or how much money you have, you cannot install the light fittings before you have erected the ceiling. Physical anomalies that make no sense cannot be hidden and forgotten about. However, in the world of Enterprises there are no such limitations, people can, and frequently do install “the lights” before “the ceiling”, or decide that an “effluence outlet” would be a good idea in a “kitchen”. There are no physical limitations and the scope for hiding or ignoring things that are bad is immense.

Items - 191

KEYPOINT:

X Architecture, is the fundamentally important structure of the whole of

X, set in the context of things outside of X, that affect X, or are affected by X.

ADOPTION:

Management: Ensure people

understand what Architecture is, and

Questions to Ponder

♦ What do you think “The Architecture Paradigm™” is? ♦ Does it agree with Pragmatics Definition? ♦ What do others in your Enterprise think?

Items

is not.

192 - Items Pur pos e It’s Not What Y ou Think

PR Many times when explaining what Architecture is, people use the building analogy. Imagine you built a house without a master plan, by continuously adding and changing it over a long period of time without a broad plan of what you were doing. You might end up with something like this:

Items

♦ ♦ ♦ ♦ ♦ ♦

160 rooms, 40 bedrooms and 2 ballrooms. 47 fireplaces, 10,000 window panes, 17 chimneys 2 basements, three elevators. Doors and stairways that lead nowhere Steam and forced-air heating Push-button gas lights

The Winchester Mystery House is a well-known California mansion that was under construction continuously for 38 years. It once was the personal residence of Sarah Winchester, the widow of gun magnate William Wirt Winchester, but is now a tourist attraction. Under Sarah Winchester's day-to-day guidance, its "from-the-ground-up" construction proceeded around-the-clock, without interruption, from 1884 until her death on September 5, 1922. The mansion is renowned for its size and utter lack of any master building plan and is often used as a perfect example of bad Architecture. In fact, it is a perfect example of good Architecture! How come I hear you cry? The story goes that after her husband’s death, Sarah Winchester became obsessed by the all the ghosts from the people her husbands guns had killed. Having consulted a (very wily) clairvoyant (with good connections to building companies!), she was told that the ghosts needed to be “deflected” if they came through windows and doors and the only way to stop them was to confuse them by putting doors on walls the led nowhere, etc. Unfortunately that

Items - 193

Items

meant the ghost were deflected so another false door or internal window was needed…. Etc, etc, etc. Think of it as Feng Shui on Acid! The point is this. Any “good” architecture ONLY EXISTS to fulfil a customer’s needs. It does not exist to “look” nice (unless that’s what the customer wants of course!). In general, “good” architecture tends to “look” nice, but the key thing for people to understand is to concentrate on satisfying the client, not making perfect pretty architectures. This building, although totally “crazy” and “wrong” to some peoples eyes, is actually “perfect” in the clients eyes, hence, by definition, its “good” architecture. A little piece of trivia - A film “Winchester” (released in 2018) staring Helen Mirren, tells a dramatized story of Sarah Winchester and the house. Although the film shows a lot of the houses interior, very little filming took place at the actual mansion. https://www.imdb.com/title/tt1072748/

194 - Items

KEYPOINT:

Any “good” Architecture ONLY

EXISTS to fulfil a customer’s needs.

ADOPTION:

Enterprise Architect: Realise that

good Architecture is defined by the client, not the Architect.

Questions to Ponder

♦ Can you think of other architectures that are actually good but look terrible? ♦ What is a better architecture for roads? The USA system of perpendicular roads with many crossroads and single roads between places or the British system that is more akin to a redundant network?

Items

Items - 195 Str uctur al Complexity

Items

PR F

All things have a level of Structural Complexity Structural Complexity is not the same as size or quantity but can be related. Structural Complexity is more a function of the number of different things and the number of relationships between them. For example, a typical car park might contain 500 parts (cars) but the car park has low complexity because a) they are all cars - things of the same type and b) the only relationships that exist between them are from each car to its immediate neighbour or from each car to a map. On the other hand a typical car contains around 10,000 parts (components) but most of those parts are different and the relationships between them are many and varied, from obvious/direct relationships like the accelerator is related to the throttle body to subtle/indirect relationships such as the cooling output of the air conditioning unit is related to the number of people in the car. From these two examples, it can be seen that Complexity is also a function of how deep we look into the “thing” in question. If we take the example of the car park and say that the thing in question is not only the cars but also the “things” that make up the cars, then the car park changes from having a low complexity to a high complexity. Transformational Volatility merely refers to how often the “thing” changes - its rate of change. In fact, increasing Structural Complexity can be very beneficial, for example the structural complexity of most back seats in cars today is very high compared to their structural complexity 40 years ago. But this increased complexity exists for a purpose - to allow an end user of the car to convert the car to a van easily without having to go back to the factory to have them do it. So there is a notion of good and bad complexity. Good or helpful complexity is defined as:

196 - Items ♦ Complexity which exists for an identifiable benefit. ♦ Tends to be created on purpose - by explicitly architecting or designing it into things

when they are created or changed, although can also be created by accident (e.g. implicitly by the good working practices of individuals). ♦ Created with the knowledge of, and acceptance of, its implications. ♦ Tends to increase the effectiveness, efficiency, agility and durability of the thing in question and its transformation.

Bad or unhelpful complexity is defined as:

♦ Complexity which exists for no identifiable benefit. ♦ Tends to be created by accident - by the passage of time, although can also be created on purpose (e.g. explicitly by the self-interests of individuals - in which case it would be viewed as good complexity by that individual). ♦ Created without little or any knowledge of, or acceptance of, its implications. ♦ Tends to decrease the effectiveness, efficiency, agility and durability of the thing in question and its transformation.

Items

Items - 197

KEYPOINT:

Structural Complexity is a function of the number of things something is composed of, and the number of relationships between them.

Questions to Ponder

Items

Are you aware of your Enterprise’s Structural Complexity? How would you define it? How would you measure it? Do you care?

♦ ♦ ♦ ♦

198 - Items Tr ans for mational Volatility

PR All things have a level of Transformational Volatility. Transformational Volatility merely refers to how often the â&#x20AC;&#x153;thingâ&#x20AC;? changes - its rate of change. Enterprises exist in a never ending turbulent sea of change, caused by internal forces and the volatility of the ever changing external context of customers, competitors, legislation, the global economy etc, and of course technology.

Items

Items - 199

KEYPOINT:

Transformational Volatility is the rate of change of something.

Questions to Ponder

Are you aware of your Enterprise’s Transformational Volatility? How would you define it? How would you measure it? Do you care?

Items

♦ ♦ ♦ ♦

200 - Items Tr ans for mational Complexity

PR Transformational Complexity is a function of:

♦ ♦ ♦ ♦

The Structural Complexity of the system being transformed (C). The Transformational Volatility of changing the system (V). How much of the system needs to be changed - its Scope (S). The reason for the changing the system - the Requirements (R).

Items

To complicate matters, Scope is also a function of the Structural Complexity of the “thing” being transformed and the Requirements. For example, a small requirement may cause a large change to the “thing” in question purely because of that “thing’s” structural complexity. Conversely a large requirement may cause a small change to the “thing” in question again purely because of that “thing’s” structural complexity. While Transformational Complexity is low, people can deal with it easily, but as Transformational Complexity rises tools and techniques are required to cope. One tool/technique specifically designed to address this is The Architecture Paradigm™.

“Seven thousand years of known history of humankind establishes that the only known strategy for accommodating extreme complexity and extreme change is… ARCHITECTURE!!!” - John A. Zachman

Items - 201

KEYPOINT:

Transformational Complexity is a

function of the Structural Complexity and Transformational Volatility of something.

Questions to Ponder

Items

Are you aware of your Enterprise’s Transformational Complexity? How would you define it? How would you measure it? Do you care?

♦ ♦ ♦ ♦

202 - Items Contextual Volatility & Complexi ty

PR Since, as we have seen before, all things exist with a context, it is also important to remember that it is not only the Structural Complexity and Transformational Volatility of the “thing” in question but also the Structural Complexity and Transformational Volatility of all the “things” that make up its context.

Items

Items - 203

KEYPOINT:

Contextual Volatility & Complexity is defined as the Structural Volatility & Transformational Volatility of the context of something.

Questions to Ponder

Items

Are you aware of the Structural Complexity of your Enterprises Context? How would you define it? How would you measure it? Are you aware of the Transformational Volatility of your Enterprises Context? How would you define it? How would you measure it? Are you aware of the Transformation Complexity of your Enterprise Context? How would you define it? How would you measure it?

♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦

204 - Items Jus tification Applicability

PR Justification for the investment required to make the changes necessary to utilise The Architecture Paradigm™ cannot be based on numbers or normal simple cost/benefit justification. Any attempt to do so will end in disaster. Any potential benefits tend to be hard to understand, quantify and express (especially in terms of impact on the bottom line) and the realisation of the benefits after the Transformation of Transformation tend to be slow and cannot be as immediately felt. This is because the benefits of improving Transformation only materialise after subsequent projects (which Transform other things like Operations), execute within that improved Transformation environment.

Items

“You Can’t ‘Cost-Justify’ Architecture”

- John A. Zachman.

Justification MUST therefore be based on understanding when it’s applicable and when it’s not. Just as there are times when use is critically important, there are also times when it is of no use whatsoever. The trick is to understand where you are on that continuum and more importantly where you are likely to be in the short, medium and long term. How applicable and beneficial it is, is a function of the Structural Complexity and Transformational Volatility of the “thing” in question which come together to form Transformational Complexity. Therefore the applicability of utilising The Architecture Paradigm™ rises as a function of rising Structural Complexity Transformational Volatility aka Transformational Complexity. If Transformational Complexity is low then use of The Architecture Paradigm™ is of little use but as Transformational Complexity rises, use of The Architecture Paradigm™ becomes mandatory.

Items - 205

KEYPOINT:

The Architecture Paradigm™ is only applicable when Structural

Complexity and Transformational Volatility are high enough.

Questions to Ponder

Items

Where is your Enterprise on this graph? Where will it be in the next one, three, five years? What will you do then? What will you do now to prepare for then?

♦ ♦ ♦ ♦

206 - Items Cos t and Ability

PR Here we see how the Cost of Transforming some “thing” and the Ability to Transform some “thing” changes as Transformational Complexity increases. The dotted lines indicate the result if we DO NOT USE The Architecture Paradigm™

♦ The Cost of Transformation (the red dotted line) - starts very low but rises

Items

exponentially as Transformational Complexity rises. Ultimately it rises to a point where the cost of Transforming becomes prohibitive. ♦ The Ability to Transform (the green dotted line) - starts very high but falls exponentially as Transformational Complexity rises. Ultimately it falls to a point where the Ability to Transform becomes impossible. The solid lines indicate the result if we DO USE The Architecture Paradigm™

♦ The Cost of Transformation (the red solid line) - starts very low, and while it does rise as Transformational Complexity rises, this rise tends to be more linear and manageable. ♦ The Ability to Effect Transformation (the green solid line) - also starts very high, and while it does fall as Transformational Complexity rises, this fall tends to be more linear and manageable.

Deciding to adopt The Architecture Paradigm™ (increasing the maturity in its use) in one or more domains, requires that an Enterprise make adjustments to the MAGIC used in those domains.

Items - 207

KEYPOINT:

As Transformational Complexity rises, use of the Architecture

Paradigm™ becomes mandatory, to preserve your ability to transform, and manage the cost of transformation.

OO ADOPTION:

C-Suite: Accept that while

Architecture may sometimes be not mandatory.

Questions to Ponder

♦ ♦ ♦ ♦

Where is your Enterprise on this graph? Where will it be in the next one, three, five years? What will you do then? What will you do now to prepare for then?

Items

applicable, at others times, it is

208 - Items Inves tment

PR Items

These adjustments to the MAGIC used for Transformation take an investment of time, money and most importantly commitment. How much time, money and commitment is required, is a function of the current Transformational Complexity that exists. The higher the current level of Transformational Complexity it is being adopted to deal with, the higher the initial investment of time and money and will, will be. This is due to a negative feedback effect. When The Architecture Paradigm™ is not used, any changes made tend to increase the Structural Complexity of the thing being changed, not because it needs to be that complex, but because of a lack of knowledge about the thing being changed. This negative feedback loop is cumulative and can run out of control as the rule of compound interest takes over. The cost of understanding and sorting out the Structural Complexity rises each time another change is made meaning each time there is an opportunity to make the changes necessary to be able to use The Architecture Paradigm™, the appetite for doing so, the will, reduces. This is a downward spiral into oblivion. So as the need to make the adjustments increase, the appetite (and therefore commitment) to make them, decreases. If left too late, there comes a time when the amount of time and money and will required is just not available, and the “thing” in question will cease to be able to transform at all. When you are drowning, it’s too late to learn how to swim.

Items - 209

KEYPOINT:

As the need to utilise Architecture

increases, the appetite to do so will decrease.

ADOPTION:

C-Suite: Recognise that as the need to adopt The Architecture

Paradigm™ increases, the appetite

(and therefore commitment) to do

Questions to Ponder

♦ Where is your Enterprise on this graph? ♦ Where will it be in the next one, three, five years? ♦ What will you do then? What will you do now to prepare for then?

Items

so, decreases.

210 - Items Pr ocr as tination

PR Items

They say that time is a great healer. But time is also a great destroyer. Time is the main problem when trying to justify the changes (and therefore the investment) required to adopt and utilise The Architecture Paradigm™. As with anything, there is a time lapse between making the investment in utilising The Architecture Paradigm™ and reaping its benefits. This is because just making the changes required to utilise The Architecture Paradigm™ creates no benefit in and of itself. The benefits of spending the money making those changes only come from the use of those changes as time progresses. The worst mistake people make when thinking about and justifying the use of The Architecture Paradigm™ is that their expectations of short term value are too high and their expectations of long term value are too low. In reality, short term value is much less than expected but long term value is much higher than expected. In fact the curve is more of an S shape where initially there is a slight decrease in value (when adopting anything new) then a slow increase in value, followed by an abrupt increase in value, followed by a return to a more linear increase in value over time as maximum value is achieved. Justification for The Architecture Paradigm™ cannot be based on the benefit of the next project or even the next two, three or four projects. In fact, the next project (and possibly the second and third projects) may well run slower and cost more money. This is the Chasm of Procrastination. Many people think (incorrectly) that justifying use of The Architecture Paradigm™ is as easy (and should be as easy) as justifying whether to buy a kettle or not - buy a kettle today, get the benefit tomorrow. In actuality, justifying an investment in adopting or becoming more mature in your use of The Architecture Paradigm™ is more akin to justifying spending 30K on going to university for four years where you gain zero benefit for four years and at the end of the four years there is still no immediate benefit and no guarantee that you will a) get a job or b) that even if you do get a job, you will earn more than what you would be earning if you had

Items - 211 not saved 30K and gained four years of experience instead. Another example might be buying insurance, having to pay and pay and pay for something that you many never actually use or get any benefit from whatsoever.

Items

PR F

212 - Items

KEYPOINT:

The short term value of Architecture is overestimated.

The long term value of Architecture is underestimated.

ADOPTION:

C-Suite: Do not overestimate the

short term value, or underestimate

the long term value, that use of The

Architecture Paradigm™ can provide. Items

Questions to Ponder

♦ ♦ ♦ ♦ ♦

Do people in your Enterprise expect Architecture to have immediate benefit? What will you do to explain it doesn’t? What will you do to explain that benefits come down the line? Do you want to accept the risk of not using The Architecture Paradigm™? Is the Management of your Enterprise in the Chasm of Procrastination™?

Items - 213 Why and How

PR Asking How - Looking Down - Structural

The first direction was asking the question HOW or more correctly “How do things work”. This desire drove me to take things apart (much to the annoyance of my mother as I rarely approached putting things back together again with the same vigour that I had exhibited when taking them apart) to see what they were made of and how those parts worked and were connected together. Initially starting on small battery powered things like torches, telephones, and radios, etc but gravitating to larger items that also had the power to kill me such as electric irons, lighting, electric door bells (yes they used to be 240v in those days!) and record players. On more than one occasion my inquisitiveness caused me to accidentally electrocute myself. Firstly when still almost a baby I thought “I wonder what will happen if I push this knitting needle into the socket thing on the wall” (For those who are interested in what happened, my mother reports that there was a bright flash of blue light and a loud bang. This loud bang was shortly followed by a more muted bang as my head hit the wall opposite that I had been thrown against) and later when holding a light socket in my hand and plugging the other end into a wall socket. I am sure there were other times but the unintended electroshock therapy I had been subjecting myself to, appears to have had the unintended side-effect of clouding my memory! Regardless of this, I was very much interested in HOW things worked.

Items

I remember being a small boy growing up in 1970’s England - Pele, Rivelino and Zico dancing in colour on my black and white TV - the long hot summer of ’76 - David Bowie telling us that “We could be Heroes” - Adidas SL76 trainers - accidentally shooting my friend in the head with an airgun - Space Hoppers - my first kiss! Everything seemed new. Everything seemed exciting. I had the feeling of limitless possibilities that always come with youth and the belief that I could achieve anything. I also remember that I had an innate desire to understand things. That burning desire took me in two different directions and both of those directions were driven by questions… HOW and WHY.

214 - Items Asking HOW is the fundamental question The Engineering Paradigm™ forces us to contemplate. For without knowing HOW something is constructed we cannot know HOW to change it or what the unintended implications of any change will be.

PR Asking Why - Looking Up - Contextual

Items

I very quickly learned that although answering the HOW question was interesting, the HOW question seemed to have a logical end point and therefore my interested waned. It then occurred to me to ask WHY things existed in the first place and WHY they were constructed as they were. I also soon discovered that answering the WHY question appeared to have no end at all and whatever was provided as a response could lead onto another WHY. Many people just got plain angry (especially teachers - although it applied to anyone in authority which when you’re ten years young - is everyone!) as it made them think that I was just trying to annoy them. This was not the case at all - I really did want to know WHY. Many years later it occurred to me that the reason that people tended to get angry was because people either a) had not actually considered that question themselves at all and had no idea WHY or b) could answer the first or maybe even the second WHY but then reached a limit of their knowledge and instead of saying I don’t know would proffer “interesting” reasons which did not make sense which only made me ask WHY even more, which got them more annoyed, etc, etc, etc. For, me there has to be a point. To achieve something. A WHY. For without a point or reason for something it is literally - well - pointless! Even things that I enjoy doing have to have a purpose higher than just enjoying them. A purpose that achieves something. For example, I love driving. Driving anything; cars, vans, lorries, taxis, dumper trucks, anything. So you might expect that when I bought the best car I have ever owned (A Porsche Boxster S) that I would go for long drives around the countryside to enjoy driving it. I loved to drive that car, the smell of the leather, the weight of the steering, the sweet sound of the flat-six Boxer engine, but I could not “just go for a drive”. There had to be a purpose, there had to be a reason there had to be a WHY. It didn’t matter what it was (going to the shops to buy a loaf of bread, going to work, giving my daughter or son a lift) but there did need to be a goal. I needed a WHY. Asking WHY is the fundamental question The Architecture Paradigm™ forces us to contemplate. For without knowing WHY we need to change something we cannot know HOW to change it. To use an example of Deming’s: “If you ask me to clean that table I cannot. You may want to use it to store surgical implements. You may want to eat off it, you may want to put a plant pot on it. Without knowing WHY I cannot clean the table. Don’t tell me HOW to clean the table - tell me WHY you want the table cleaned.” - W.E. Deming

Items - 215

KEYPOINT:

Why is the most important question.

ADOPTION:

Enterprise Architect: Always ask WHY? (At least 5 times.)

Questions to Ponder

Items

♦ What is your burning desire? ♦ Do you annoy people by asking questions? ♦ Do people tell you how to do things or do they tell you why?

216 - Items Abs tr action & Elabor ation

PR Items

There is no reason to Abstract or Elaborate anything unless the abstracted or elaborated information is to be used for something. Abstraction is a process used to remove or suppress information that is less relevant to the user of the information at the abstracted level. Elaboration is a process used to create or add information that is more relevant to the user of the information at the elaborated level. Abstraction and Elaboration, therefore, are mechanisms which allows the same fundamental thing to be viewed by different stakeholders with potentially very different viewpoints and there is no theoretical limit to how many times information can be abstracted or elaborated. Whether you view something as being an abstraction or an elaboration is defined by the direction you are looking. If you are looking up to a more abstract level, the information is said to be an elaboration of the information above. If you are looking down to a more elaborated level, the information is said to be an abstraction of the information below. POET uses, and advocates the use of the four primitives of Abstraction and Elaboration:

♦ Subtraction/Addition - These are the simplest types of Abstraction and

Elaboration. ♦ Moving up, we abstract things by removing information. We subtract from them to make smaller things. ♦ Moving down, we elaborate things by adding information. We add to them to make bigger things. ♦ Composition/Decomposition - The second most complex types of Abstraction and Elaboration. ♦ Moving up, we abstract things by grouping them together into larger things. We Compose them into larger parts. ♦ Moving down, we elaborate things by breaking them apart into smaller things. We Decompose them into smaller parts.

Items - 217 ♦ Generalisation/Specialisation - The third most complex types of Abstraction and Elaboration.

♦ Moving up, we abstract things by creating more generic things. We Generalise them into more general things.

♦ Moving down, we elaborate things by creating more specific things. We Specialise them into more specific things.

♦ Idealisation/Realisation - The most complex, and most important, of all types of

Items

Abstraction and Elaboration ♦ Moving up, abstracts things by transforming them into more idealised things. Akin to Analysis and Architecture. ♦ Moving down, we elaborate things by transformation them into more real things. Akin to Design and Engineering.

218 - Items

KEYPOINT:

There are 4 types of Abstraction / Elaboration.

ADOPTION:

Enterprise Architect: Apply the four types of Abstraction/Elaboration appropriately.

Questions to Ponder

♦ Do all people involved in Transformation understand the differences between these

types of abstraction? ♦ Do all people involved in Transformation know how to “move up” and “move down” effectively? ♦ If not, what impact is that likely to have?

Items

Items - 219 Relations hips

Items

PR Whilst identifying things is very important, what is an order of magnitude more important is how those things are related. Understanding how things relate allows us to ask questions of the information more than just simple “give me a list of…” type questions. The negative aspect of this is that the lines are much much harder to create and maintain than the boxes, which probably goes a long way to explain why in general they are not. The value that can be obtained and the difficulty in maintaining the information increases because the number relationships (lines) between things tends to increase in a polynomial fashion (using the formula n*(n-1)/2) which is a fancy way of saying that while the number of things rises linearly, the number of possible relationships (combinations – not permutations) between them rises faster and faster. In fact this also illustrates one of the problems with the adoption of The Architecture Paradigm™. The red line could be thought of the value that is created over time, which can be seen to be very low initially and a good increase in value only happens later as the volume of information builds up. In this world where management insatiably calls for the picking of low hanging fruit and quick wins, anything that takes time to provide value tends to be seen as worthless.

220 - Items

KEYPOINT:

The relationships between things rises in a polynomial fashion.

ADOPTION:

Management: Provide people the

tools and time to deal with the fact

that the relationships between things,

OO rise in a polynomial fashion.

Questions to Ponder

♦ How much time is spent in your Enterprise understanding and maintaining relationships?

Items

♦ What problems exist with documenting and maintaining relationships? ♦ Who should be responsible for maintaining relationships? ♦ Are people in your Enterprise given the appropriate time and resources to find, model and maintain relationships?

Items - 221 The Value is in the Lines not the B oxes ™

lines, as shown by #3.

♦ Don’t necessarily have to be straight, as shown by #1. ♦ Don’t necessarily have to connect to a box at both ends, as shown by #2. ♦ Don’t necessarily have to connect to boxes at all, but may instead connect to other

Items

PR What are these boxes telling you? The Value is in the Lines not the Boxes™. This phrase expresses one of the key aspects of The Architecture Paradigm™. In fact, it could be said that Architecture IS the relationships - the lines and not the boxes, the space between the boxes, the relationship of the lines to the spaces. Another way to think of it is how the brain thinks (no pun intended). The brain is composed of “things” - neurons, and “relationships” - synapses. At birth your brain has about 86 billion neurons. It has been estimated that the brain of a three year old child as about thousand, thousand billion (1 quadrillion or 1015 ) synapses. By adulthood, although the brain increases in size by about five times, the number of neurons do not increase. Most of the growth is done by the growth of the synaptic connections - learning. Interestingly, in adulthood the number of synaptic connections falls through the process of Synaptic Pruning, stabilizing by adulthood from 1,000 thousand billion to around 100 to 500 thousand billion (trillion 1012) If anyone ever told you that Architecture was not brain surgery, maybe they should think again! So while the neurons (boxes) are important, it is the synapses (lines) that are much more important. It is only when we add the lines, that the boxes make sense to us. Indeed, we could remove the boxes altogether, and the important information will still be visible. It is also important to note that lines:

222 - Items

PR Items

Items - 223

KEYPOINT:

Lines (relationships) are an order of magnitude more important than the boxes.

ADOPTION:

C-Suite: Understand and utilise the power of relationships.

Questions to Ponder

Items

♦ Do you agree that there is massive value in “the lines” vs “the boxes”? ♦ What “lines” will you draw to allow you to see the value?

224 - Items Patter ns

PR Here we see the Mandelbrot Set. An illustration of one of the most important and powerful patterns known to man (and nature) - Recursion. There are two types of patterns:

♦ Firstly we recognise that patterns exist everywhere in just about everything and

Items

especially in nature - a self-optimising system for the sustainability of living organisms that are Effective (reproduction), Efficient, Agile and Durable. Hmmm - sounds la bit like an Enterprise! Patterns promote efficiency and elegance in the structure (Architecture) of things and how they work. Things that have discernible patterns tend to be much better than those that do not. ♦ Secondly we recognise that patterns can be used as high level general solutions to commonly occurring problems. A (design) pattern allows us to reuse these solutions with a high degree of certainty that they are effective and efficient. Someone (and probably many people) have already done “the hard work” and this allows us to “stand on the shoulders of giants”. They can be small or large and their size does not necessarily imply importance.

Design patterns can be structural (aka how something is organised) or transformational (aka how something is changed). Some patterns can be a mixture of the two - for example Software Design patterns tend to consist of structure as well as algorithms, whereas other patterns can be purely structural such as technical reference models. Architects see patterns everywhere. Their brains are hard wired that way. Why do we look for patterns? Because patterns reduce complexity. Where they cannot see a pattern they tend to create one! This tends to be an iterative process where a pattern is initially chosen, mostly on gut feel, and then that pattern is used to map things to it. In the process of doing that it may be seen that the pattern was not correct and so the pattern is changed and we repeat the loop.

Items - 225

Items

Architecture is essentially patterns/styles. For buildings, many people look at a building and say â&#x20AC;&#x153;wow - look at the architectureâ&#x20AC;? which implies the physical building itself. Actually the architecture is not the building itself. The architecture is the patterns/styles behind the physical building such as Art Deco, Georgian, Regency, Modernist, Gothic, etc. There are hundreds of Architectures (Architectural styles) in the Building domain. However, there is also a downside to patterns. Patterns promote conformity and sameness (within limits) and so careful consideration should be given to when patterns should be considered to be a friend or an enemy.

226 - Items

KEYPOINT:

Look for patterns in everything.

ADOPTION:

Enterprise Architect: Look for patterns in everything.

Questions to Ponder

Do you agree that there is massive value in patterns? How much time is spent in your Enterprise understanding and maintaining patterns? What problems exist with documenting and maintaining patterns? Who should be responsible for maintaining patterns? Are people in your Enterprise given the appropriate time and resources to find, model and maintain patterns?

Items

♦ ♦ ♦ ♦ ♦

Items - 227 Models , Meta-M odels & Semantics

PR Models

â&#x2122;Ś You cannot build (or change) anything that is complex by wading in with a

screwdriver - you need to understand what you are trying to build or change first. â&#x2122;Ś It is easier, cheaper and faster to build a model of something and then to find out it is wrong in some way, than to build the thing the model represents and then discover the problems.

What we seem to have forgotten is that Models have been used for many many years to help with Architecture and Engineering alike. Long before any computers, when technology consisted of paper, pencils, a drawing board and a chair, there was a department in many Enterprises called the Drawing Office and the people that worked there were called draughtsman. The only reason I have a very vague recollection of this is because my father worked in the Drawing Office at Rolls-Royce in the 1960â&#x20AC;&#x2122;s working on the design of the Olympus 593 Engine that powered Concorde. This department existed to produce and manage drawings - models. It was an extremely important and a strict change management process was in place to make sure that as the drawings were used to engineer and manufacture the engines, that any problems encountered or opportunities that were missed that meant the drawings needed to be changed, were fed back to the Drawing Office and appropriate updates were made.

Items

At a fundamental level, a model is merely a collection of structured information with zero or more relationships that represent something of interest. These days models and modelling are used almost everywhere. Financial models, Stock Trading models, Buildings, Cars, Spaceships, Oilrigs, Weather, etc, etc, etc, although for some reason, many Enterprises cannot understand how useful it is for Transformation. There are two main reasons why models are used:

228 - Items

Meta-Models

Items

This cost a lot of time and money. So why did they do it? The reasons are utterly evident and need no explanation. What does need explanation is why we are finding it so hard in the 21st century to explain to management that modelling is of crucial importance? Imagine how Rolls-Royce would have fared if every time a change to an engine was required that the person responsible for that change had to first spend a whole lot of time wandering round the factory trying to find a drawing of the part of the engine he was going to be working on. Maybe he found one, maybe he didn’t. If he found one he had no way of knowing how old or up to date the drawing was so would wander around trying to find people who knew something about it, who maybe had conflicting opinions. Then, after cobbling together a vaguely correct (who knows!) diagram of the domain of interest (that his project manager would constantly moan about him wasting his time on because that task was not on his project plan) and performing his work, the diagrams (models) of what the engine looked like before and after his changes were then left gathering dust on a shelf while he moved on to other things. Maybe the next person would find them, probably not. This is, of course utterly ridiculous, but this is exactly what goes on in 95% of all Enterprises every single day with the resultant loss in quality of work performed, not to mention the billions of wasted money, but even more importantly the waste of time. Money maybe important, but if you lose it you can always get more of it. Once time is gone, it’s gone forever. Your Enterprise doesn’t have a Drawing Office - but it is of crucial significance. In the past models were drawn by hand on paper, but in today’s world computers are used to streamline that process. And once a model is in a computer there are many operations and analyses that can be performed which streamlines that process even further. What-If analyses can be performed almost instantaneously to explore different scenarios and to aid selection of a final “solution”. But Enterprises seem to have forgotten the fundamentals - Fundamentals that POET is trying to highlight. IT is massively important of course, but people can fall into the trap that thinking that IT can solve all problems, forgetting that IT is only a tool and as important as a tool is, it’s not a case of how big your tool is, but how you use it ;-)

The word meta just means “information about” so a meta-model is information about a model. It really is that simple. You can also use the word meta in conjunction with just about anything so long as there is some benefit/reason for doing so. The word meta also can be used repeatedly for example meta-meta-model which is information about the information about a model. Semantics

As well as giving us the structure of the information that we can model a meta-model also defines the semantics or language used. This is massively important as language is the second biggest enemy of Enterprise Transformation (after Cultural problems). A lot of the words used in Transformation are very ill defined - from individual to individual, group to group and framework to framework. Using the same word doesn’t necessarily mean the same thing and using different words doesn’t necessarily mean different things. A lot of the time, people think they are speaking the same language (because they are both speaking English for example) when in fact they are not. In this environment it is easy to have a disagreement without either party being aware of it. That creates hidden problems which are the worst kind of problems. It is also easy to have disagreement when in fact both parties agree - Have you ever heard anyone say, “I think we are in violent agreement”?

Items - 229

Defining the meanings of the words that are used in a model is key to allowing people from multiple backgrounds and domains to be able to communicate effectively. This is one thing that a framework brings. A common set of terms, definitions and explanations of a discipline. Semantics/Language is defined in two ways:

â&#x2122;Ś Words - A dictionary or glossary, specifying definitions and the meanings of words

and phrases and (more importantly) the relationships between them. â&#x2122;Ś Symbols - The Notation used on diagrams, specifying definitions and usages of shapes, lines, colours and embellishments.

Items

These Words and Symbols form the language of Enterprise Transformation. Different people, or roles, tend to speak these different languages and dialects. Recognising that these languages and dialects do exist is an important part of the glue between each level and in getting the whole of the Transformation stack to work holistically together.

230 - Items

KEYPOINT:

Use structured data for all structural

and transformational information, and generate “documents” as required.

ADOPTION:

Management: Provide people the

tools and time to model information,

instead of writing it in unstructured documents.

Questions to Ponder

Items

♦ ♦ ♦ ♦ ♦ ♦ ♦

Does executive management understand the benefits of modelling? Does your Enterprise use modelling where appropriate? If not, what areas could benefit more? What is preventing your Enterprise using modelling more? What things exist in your Enterprise to define a common set of words? What things exist in your Enterprise to define a common set of symbols? Does your Enterprise have a Drawing Office? Should it?

Items - 231 Tools Cover age

Items

PR To carry out the work in the EA domain (Roadmapping) effectively and efficiency, tools are mandatory. There are two fundamental domains (types) of information that any tool needs to be able to work with (Structural and Transformational) and this information is consumed and produced by various Disciplines. In general (because of their history and initial focus) tools operating primarily on Structural information have tended to be called EA Modelling tools and tools operating primarily on Transformational information have tended to be called EA Planning Tools. This is not a hard and fast rule though as many tools describe themselves using various adjectives - itâ&#x20AC;&#x2122;s not what they call themselves, itâ&#x20AC;&#x2122;s what information they manipulate. Although the output of "doing" EA is at the conceptual level, an EA Tool needs to also be able to model the Enterprise Context and Contextual levels, in order the EA work to be tied back to the information that drives it. In addition, it should also be able to contain (integrate with) information at the Operational Level (CMDB) in order for any EA work to be based on what actually physically exists within the Enterprise. This Operational information contains valuable information that can be abstracted and represented at these top three levels to allow us to understand how the current capability and operating models map to the physical world.

232 - Items

KEYPOINT:

Any EA Tool must integrate with other tools.

ADOPTION:

EA Project Team: Make sure your EA

Tool can deal with Structural (MACE) and Transformational (MAGMA)

OO information and that it integrates with other related tools.

Questions to Ponder

Items

♦ ♦ ♦ ♦ ♦

Which tools do you currently use for Enterprise Architecture? What domains (Structural/Transformational) do they cover? Are they adequate? If not, does this present any issues or problems? What will you do to alleviate or solve them?

Culture - 233

PR OO

Culture

CULT URE

234 - Culture

KEYPOINT:

The Culture section of POET defines the roles and the culture required.

ADOPTION:

C-Suite: Instigate a review of the

Culture at play in the Enterprise's Transformation Capability, to

OO determine if it's maturity is appropriate.

Questions to Ponder

♦ ♦ ♦ ♦ ♦

With respect to your Enterprises Transformation capability, what Culture exists? Is the Culture documented? Understood? Is it fit for purpose? Are they used? All the time? Only when it suits? What parts are Good? Why? Bad? Why?

Culture

Culture - 235 Or ganis ation Str uctur e Wor ker s

PR 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

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. 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:

Culture

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

236 - Culture ♦ 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.

Culture

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 - 237

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

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

Culture

Enterprise defines along with their RACI mappings?

238 - Culture Ar chitectur e & Engineer ing Yin & Yang

PR It seems everyone these days works on solutions. Thinking about one solution or another, solving problems, discussing or arguing with others on which is the right solution or not. People tend to concentrate on solutions because a solution to a problem is the end goal. There is also a psychological aspect to it - whoever’s solution is adopted proves their solution was superior (supposedly - in my experience that’s not always the case!). It is human nature to answer questions - to create solutions. Of course. The Architecture Paradigm™ is also about providing solutions and dealing with their complexity, but the approach focusses much more on understanding the problem - for when you truly understand a problem, solutions tend to be: a) much easier to see and b) much more effective and efficient.

Culture

However, The Architecture Paradigm™ also recognises that the approach must integrate with work that is to come later, namely Engineering. Architecting is more concerned with WHY we need a solution which largely involves asking questions and understanding things. Engineering is more concerned with HOW the solution will be made real which largely involves creating solutions and talking. It could be said that Architecting and Engineering are two sides of the same coin.

Culture - 239

KEYPOINT:

Architecture and Engineering are two sides of the same coin.

ADOPTION:

C-Suite: Train Architects to

understand Engineers. Train

Engineers to understand Architects.

Train Management to undertstand both.

Questions to Ponder

♦ Do the Management in your Enterprise, know the difference between Architecture and Engineering?

♦ Do the Workers in your Enterprise, know the difference between Architecture and

Culture

Engineering?

♦ Does your Enterprise use Architecture and Engineering appropriately? ♦ If not, what problems are created?

240 - Culture Ar chitect Hor izontally, Engineer Ver tically

PR A fundamental confusion that people have when people try to explain or advocate the Architecture of something, is that just because an Architect is talking about the whole, it does not mean they are advocating building the whole, or building the whole immediately. By definition, Architecture (fundamentals) are high level, and by definition, the whole is big. Comments such as “Yes that’s all very good but it’s all high level, and it’s just too big, we can’t do it all (in a short space of time), so we won’t do anything at all” illustrates that confusion. Architecture, by definition, is high level and is big. So, the next time someone says that something Architectural is “high level and big” as a means to dismiss it, you should say…

Culture

“Yes, it is! If it were not high level and big, it wouldn’t be Architecture! And it is precisely because it is high level and big, that it is important." When we say Architect horizontally, it means that Architecture tends to (should) consider the fundamental structure of something large and complex (If it were not large or complex there is little need for Architecture) and for that you have to (should) consider the whole. We also say horizontally because Architecture tends to (should) layer things and is concerned with systemic qualities and capabilities such as Process, Organisation or Locatgion – as a whole, or Data – as a whole, or Applications – as a whole, or Technology – as whole. Because Architecture tends to (should) consider things from a Contextual and/or Conceptual and/or Logical perspectives this allows us to consider the whole. The phases mostly concerned with Architecture work are during the Strategising, Roadmapping and Solutioning phases of Transformation.

Culture - 241

Culture

Whenever we perform Architecture work (Business Architecture, Enterprise/Transformation Architecture, Solution Architecture, Application Architecture, Data Architecture, Infrastructure Architecture, etc) we MUST consider ALL things of that type NOT just the Architecture of a piece. For example, when considering the Architecture of an Application, we must consider that in terms of, and in the context of, the Architecture of all Applications. In this sense, there is no such thing as Architecture for Application 1, and Architecture for Application 2, and Architecture for Application n. There is only Application Architecture - the whole point of which is - that it is used across ALL applications, or at least Applications of a certain class, and that the number of classes is a much smaller number than the number of Applications. This applies regardless of the type of architecture we are considering (Business, Enterprise/Transformation, Solution, Application, Data, Infrastructure, etc). This is in contrast, to Engineering, where the whole tends not to be engineered at the same time. For this reason, we say that we Engineer vertically, that is, we utilise horizontal Architectural Structures but build in an end to end fashion. In direct conflict to Architecture, Engineering MUST consider performing engineering ONLY for that piece, and NOT Engineering of all other things of that type. Why, because engineering work, is only concerned with engineering the piece in question. It has no remit or budget or mandate to perform engineering on anything else. Of course, that does not mean engineering cannot use patterns and lessons learned form performing Engineering in the past, but this use of patterns is not the same as the creation and maintenance of patterns we perform in Architecture work. Thusâ&#x20AC;Ś We Architect horizontally, systemically. We Engineer vertically, specifically.

242 - Culture

KEYPOINT:

Think (and Plan) Strategically

(Architecture), Act Tactically (Engineering)..

ADOPTION:

C-Suite: Mandate that people

Architect horizontally and Engineer

OO vertically.

Questions to Ponder

♦ Do the Management in your Enterprise, know the difference between Architecture and Engineering?

♦ Do the Workers in your Enterprise, know the difference between Architecture and Engineering?

♦ Does your Enterprise use Architecture and Engineering appropriately? ♦ If not, what problems are created?

Culture

Culture - 243 Over lap

Culture

PR F

In practice, there is of course an overlap between Architecture and Engineering. The overlap may be small or may be large depending on the problem in hand. This tends to decide whether one person is required to perform both roles or if two people who specialise in each are required. In this day and age, thinking about things seems to be viewed as a very bad thing as no discernible progress is being made. It should be noted that all the major advancements since time began have come from people thinking about things rather than doing - at least initially. This is not to say that everyone should sit around thinking about things and not doing anything. Doing things informs thinking and thinking informs doing. This is the yin and yang where balance must be achieved for best results and progress. No one ever suggested that people should stop doing things, but it is common for people to suggest that people should stop thinking about things â&#x20AC;&#x153;Just do it!â&#x20AC;? - not explicitly because when you say it explicitly, as I have just done, it sounds ludicrous in the extreme, but in practice, in life, in the day to day run of things, thinking is routinely put on the back burner as the next urgent (but probably unimportant) thing becomes the focus. One of the differences between doing and thinking is that doing things has many limitations. Thinking has no literally no limitations. It is hardly surprising therefore that innovation and progress comes more from thinking than doing, albeit you do not see the fruits until something is built. For example, the fantastic smartphones we have today did not come from doing things, they can from thinking about what could be done. Thinking created the catalyst and doing made it happen. They had to be envisaged first. In that way, engineering places limitations on architecting however, architecting pushes those limitations and boundaries and thereby advances Engineering.

244 - Culture

KEYPOINT:

The line between Architecture and Engineering is a blurred one.

ADOPTION:

C-Suite: Instigate training so that

people recognise that Architecture and Engineering overlap.

Questions to Ponder

♦ Do you agree that Architecture is more about Why, while engineering is more about How? ♦ What do other people in your Enterprise believe? ♦ If there is not a common understanding, does this create problems? ♦ If so, what is the impact of those problems?

Culture

Culture - 245 Inter Phas e

PR Culture

From the perspective of the entire Transformation domain, Architecture is performed more at the top of the stack and less at the bottom. Conversely Engineering is performed more at the bottom of the stack and less at the top. The further down the stack we go the more concrete things become, and the further up the stack we go, the more abstract things become. This does not mean we are saying that there is no Engineering happening at the top and there is no Architecture happening at the bottom.

246 - Culture

KEYPOINT:

Architecture is performed largely in the early phases of Transformation, while Engineering is performed largely in the later phases.

ADOPTION:

C-Suite: Instigate training so that

people recognise that Architecture is performed largely in the early phases of Transformation, while Engineering is performed largely in the later phases.

Culture

Questions to Ponder

♦ Does your Enterprise recognise that people working towards the top of the

Transformation stack are more Architects than Engineers? ♦ Does your Enterprise recognise that people working towards the bottom of the Transformation stack are more Engineers than Architects? ♦ If not, does this create any problems? ♦ Does this create any opportunities for education?

Culture - 247 Intr a Phas e

PR Culture

Architecture and Engineering map on to the fundamental phases of Transformation, and within each phase (depending on the Complexity of the information being worked upon). Consequently the reality is a (potentially confusing) mixture of Architecture and Engineering which probably goes a long way to explain why there is such confusion and debate about how they are related and where they fit into the Transformation cascade. The truth is, they fit everywhere!

248 - Culture

KEYPOINT:

Architecture and Engineering can be performed within any phase.

ADOPTION:

C-Suite: Instigate training so that

people recognise that Architecture

and Engineering are skills that can be

OO applied anywhere.

Questions to Ponder

♦ Considering each phase of Transformation, do people who work there think of themselves primarily as Architects or Engineers or a mixture?

♦ Which phase of Transformation do you primarily work in? ♦ Do you consider yourself to be primarily an Architect or Engineer or a mixture?

Culture

Culture - 249 Over all

Culture

PR In many ways, the key to Transformation happening in a coherent, holistic fashion is the Architecture and Engineering Disciplines working together in harmony. It is natural that the drive is always towards Engineering because it is Engineering that actually produces the tangible things that people want, but this overwhelming desire must be tempered and balanced by Architecture where appropriate. And while it is true that Architecture without Engineering is pointless, it is also true to say that Engineering without Architecture is foolhardy at best and at worst downright dangerous. And this risk increases as complexity and volatility rises. The yin and yang of Architecture and Engineering is built upon the concept of the Thinking Mind-set and the Doing Mind-set. Research by psychologists Arie Kruglanski, Tory Higgins, and their colleagues suggests that we have two complementary motivational systems: the “thinking” system and the “doing” system - and we’re generally only capable of using one at a time. Think about how you best generate new ideas. Often, you “brainstorm” or try to come up with as many ideas as possible. That is called diverging and requires our thinking system. At other times, you need to evaluate those ideas and figure out which ones are best. That is called converging, and it requires the activation of the doing system.

250 - Culture

KEYPOINT:

The relationship between

Architecture and Engineering as we move from the top to the bottom phases is complex.

ADOPTION:

C-Suite: Instigate training so that

people recognise that the application of Architecture and Engineering can be useful in any phase.

Questions to Ponder

♦ Are the Architecture and Engineering disciplines recognised in your Enterprise? ♦ Are they working in harmony or not? ♦ If not, what will you do to increase the harmony?

Culture

Culture - 251 Fundamentals

This is a little joke, but like all jokes, there is usually some grain of truth in it. In this case, there's a whole bag of rice and contains an important message! Architects are generalists who look at the big picture. Since no one has the bandwidth to know everything about everything, an obvious side effect is that the more things they know about, the less bandwidth they have to drill into the details of those things. Engineers are of course, the opposite, being specialists, who look are the small detailed picture. Since no one has the band width to know everything about everything, an obvious side effect is that the more detail they know about some thing, the less bandwidth they have to look at the bigger picture. This intensely important distinction is imperative for the management of Enterprises to understand, not only from the point of view of needing both, but from the point of view of making people happy in the roles they perform and the effectiveness and efficiency by which they perform them. Putting someone with an Architects brain in an Engineering job, or someone with an Engineers brain in an Architecture job, will make both feel hopelessly lost and depressed, which is guaranteed to make their work ineffective and inefficient. The Enterprise loses, the employee loses.

Culture

PR {{Abdul Aziz}}

252 - Culture

KEYPOINT:

Know and exploit the fundamental difference between Architects and Engineers.

ADOPTION:

Management: Ensure that Architects are give Architects jobs and

OO Engineers are given Engineering.

Questions to Ponder

♦ ♦ ♦ ♦ ♦ ♦

Are you more of an Engineer or an Architect or are you both? Who in your Enterprise is an Engineer in an Architect’s role? Are they happy? Who in your Enterprise is an Architect in an Engineer’s role? Are they happy? How can your Enterprise exploit the differences between Architects and Engineers?

Culture

Culture - 253 Compar is on

PR Engineering tends to be more science, than art.

Architecture is more about looking up (Why) than looking down (How).

Engineering is more about looking down (How) than looking up (Why).

Architecture is more about understanding the Problem.

Engineering is more about understanding the Solution.

Architects tend to think in terms of outside-in.

Engineers tend to think in terms of inside-out.

Architecture tends to be more art than science.

Culture

It is not easy (Impossible? â&#x20AC;&#x201C; But thatâ&#x20AC;&#x2122;s why I like it!) to just state what Architecture and Engineering are. The relationship between these two disciplines is complex and more grey than black and white. And so, the best way to more fully understand them is to compare and contrast them in various dimensions.

254 - Culture Engineers are aware of the whole system, but tend to focus on the parts.

Architects tend to be more concerned with the why > what translation with a little of the how.

Engineers tend to be more concerned with the what > how to translation with a little of the why.

Architects tend to deal in uncertainty.

Engineers tend to deal in certainty.

Architects tend to see impossible as an opportunity.

Engineers tend to see impossible as a constraint.

Architecture is more about omission, composition, generalisation and idealisation, than it is about inclusion, decomposition, specialisation or realisation.

Engineering is more about inclusion, decomposition, specialisation and realisation, than it is about omission, composition, generalisation or idealisation.

An Architect knows their job is done when there is nothing more to take away.

An Engineer knows their job is done when there is nothing more to add.

The most important tool for an Architect is their eraser.

The most important tool for an Engineer is their pencil.

Architects tend to think.

Engineers tend to do.

Architects tend to consider things from the perspective of what is yet to come.

Engineers tend to consider things from the perspective of what has been.

Culture

Architects are aware of the parts of a system, but tend to focus on the whole.

Culture - 255 An Engineer doesn’t know what to Build until an Architect specifies it.

An Architect doesn’t know why to Architect something until a Client specifies it.

An Engineer doesn’t know why to build something until an Architect tells specifies it.

To “do” Architecture you need breadth, to see the big picture.

To “do” Engineering you need depth, to see the big detail.

Architects paint pictures. An interpretation of reality.

Engineers take pictures. A record of reality.

You Architect long term wins.

You Engineer quick wins.

You cannot cost justify Architecture.

You can cost justify Engineering.

The true value of Architecture is intangible.

The true value of Engineering is tangible.

Architects tend to like to find out when they are wrong.

Engineers tend to hate to find out when they were wrong.

Architects tend to be more about unleashing the potential of the mind to conceive new ideas (Creativity).

Engineers tend to be more about introducing change into relatively stable systems (Innovation)

Architecture is more about the lines (Relationships) than the boxes

Engineering is more about the boxes (Objects) that the lines.

Architecture tends to be immortal and permanent.

Engineering tends to be mortal and temporary.

Culture

An Architect doesn’t get what they want until an Engineer Builds it.

256 - Culture

PR Culture

Culture - 257

KEYPOINT:

Architecture and Engineering, bring important things to the table, and

makes the whole much more than the sum of its parts.

ADOPTION:

C-Suite: Instigate training so that

people recognise the differences between Architecture and Engineering, and use both appropriately.

♦ ♦ ♦ ♦ ♦ ♦ ♦

Are you more of an Engineer or an Architect or are you both? How much time are you allowed to spend “thinking” rather than “doing”? If you were given the space to think more, would you be better at your job? How many Architects does it take to change a light bulb? (None - It’s an Engineering problem ;-) Does your Enterprise use Architects and Engineers in an appropriate way? Can you think of other ways that Architects and Engineers contrast each other?

Culture

Questions to Ponder

258 - Culture Who Ar e You ?

PR Are you an Architect in an Engineers job? A manager in an Architects job? An Engineer in an Architects job. An Engineer in a Managers job? While others may decide or confer titles on you, we suggest you look into yourself, your soul, and decide first and foremost who the real you is, and then make any changes necessary, so that the real you shines through. Here we discuss a diagram from a book called “The Japanese Secret to a Long and Happy Life” by Francesc Miralles and Hector Garcia. Like most models, it is a powerful aid to thinking about yourself (and others) and can help you decide if you are in the right job, or if you are doing the right things for the right reasons. It considers that there are 4 main areas:

♦ What you LOVE - This equates to what you like to do. What gets you out of bed in

Culture

the morning. What you would choose to do if there were no other restrictions. ♦ What you are GOOD AT - This equates to what you are good at. There will be some things you are good at, and like doing, There will be other things you are good at, that you do not like doing. ♦ What OTHERS NEED - This was originally titled “What the world needs” but the word “world” puts a domain constraint on the question that need not be there. To one person “the world” may literally be the world. To others “the world” may mean their family, or the company they work for. As we have learned before “Context is King”™ and therefore you need to place the context you wish on the model to be able to answer its questions. ♦ What you can GET PAID FOR – This equates to getting something of value that you can exchange for other things you need, aka money.

Culture - 259

Since you are in control of the context, it allows you to utilise the model in different contexts. For example, one to represent your home life where “the world” is your family and “what you can get paid for” is the respect of your family (and the “payment” of your family achieving their Ikigai) and another to represent your working life where the company you work for is “the world” and the “payment” is your salary. Where these primary domains overlap is where happiness (and sadness) lies. At the intersection of what you are good at, and what you need lies your PROFESSION. At the intersection of what you are good at, and what you love, lies your PASSION. At the intersection of what others need, and what you need lies your VOCATION. And, at the intersection of what others need, and what you love, lies your MISSION. The other intersections illustrate areas of partial Ikigai where three of the four aspects are fulfilled but one is not.

♦ Satisfying what you love, what you are good at, and what you need, leaves a feeling of USELESSNESS, because you are not doing what OTHERS NEED.

♦ Satisfying what others need, what you love, and what you are good at, means you

have NO WEALTH, because you are not doing what you can GET PAID FOR.

♦ Satisfying what you need, what others need, and what you love, leaves you with a

sense of UNCERTAINTY, because you are not doing what you are GOOD AT. ♦ And, satisfying what you are good at, what you need, and what others need, leaves you with a feeling of EMPTINESS, because you are not doing what you LOVE.

Ikigai, is that perfect balance where you balance what you need, with what others need, with what you are good at, with what you love. It would be nice if people can truly achieve Ikigai, but for the most part, many of us do not. From my professional life context (at this point in time – because things always change) I would say that I exist in the “Delight & fulfilment but no WEALTH. That is:

♦ I am doing what I truly love to do (maturing the Transformation domain of Enterprises).

♦ I (believe) I am good at it. ♦ I (believe) I am supplying what others need – others being Enterprises all over the So, I feel delight and fulfilment, but have no wealth. For me this is fine, because I place a much higher value on doing things I enjoy, that I am good at, and that help others, than any monetary gain. Money is not what gets me out of bed in the morning. The other three together do.

Culture

world (even though they may not realise they need it)

260 - Culture

KEYPOINT:

A happy productive person, balances what they are good at, with what they love, what others need, and what they want.

ADOPTION:

C-Suite: Initiate a review to allow

people to balance what they are good at, with what they love, what others

needs are, and what their needs are.

Questions to Ponder

♦ What do you love and what are you good at? Are they the same things? ♦ If not, what are you going to do about that? ♦ What can you get paid for and what do others needs that you can provide? Are they

Culture

the same things?

♦ If not, what are you going to do about that? ♦ How does your home life Ikigai map, compare to your professional life Ikigai map? ♦ If you were only able to satisfy 3 out of the 4 primary areas, which ones would you chose and why?

Culture - 261 The Ar chitect Secr ets

“New Light through Old Windows”

- Chris Rea

Culture

PR One of the curses (“my name is Legion, for we are many”) of being an Architect is that they often can see things, as plain as day, that others who are not Architects cannot see. This does NOT mean that Architects are in some way superior or more important. It just means they are different. It’s like everyone else can only see visible light, but Architects can see the full spectrum from infrared to ultraviolet and beyond. Architects can hear what others cannot hear, feel what others cannot feel, smell what others cannot smell and taste what others cannot taste. But there is another curse far worse than all of these. And that is that Architects can see into the future. I don’t mean, of course, that they can tell you the winner of the 4:15 as Ascot! What I mean is that they have the uncanny ability (some may call it a sixth sense) to be able to foresee things, to think ahead. In fact it’s more than a sense, it is almost what defines them to be Architects in the first place. Ignore an Architect because he is talking about things in the future and there is no point in employing him in the first place! Actually, although everyone knows and is taught that there are five senses, this is in fact wrong (as are many things taught in school!). The five senses we commonly know about come from Aristotle who also got it wrong when he said that there are only four elements (Earth, Fire, Water, and Air). Today, it is thought that there are actually anywhere from nine to twenty one senses, for example; Pressure, Itch, Thermoception, Proprioception, Tension Sensors, Nociception, Equilibrioception, Stretch Receptors, Chemoreceptors, Thirst, Hunger, Magnetoception and Time. Architects do not necessarily discover new things, more they discover new ways of seeing existing things. Putting things “in a new light”.

262 - Culture

Architects expose things that can provide new insights into existing things. When people see New Light through Old Windows it can change fundamentally how they see and approach things, the decisions they take and why. This is one thing that POET helps to do, but it’s a difficult thing to see - hence the references to SEPs and the Magic Eye picture at the beginning. Since Architects can see, hear, taste, feel, and smell things that others cannot and also have the ability to peer into the future, they therefore know things that others do not know. Some may say, secrets. And as someone once said: “The secret of business is to know something that nobody else knows”. - Aristotle Onassis.

It may be surprising to people, that the leaders of Enterprises do not see the value that Architects can bring to all domains rather than just IT. In time they will. I know because I am an Architect and I can see into the future ;-)

Culture

Culture - 263

KEYPOINT:

“The secret of business is to know

something that nobody else knows.” - Aristotle Onassis

ADOPTION:

C-Suite: Mandate that people should exploit the fact Architects should be

exploited to easily see things that

others find difficult or impossible to see.

♦ ♦ ♦ ♦

Would you like to see things others cannot? Would you like know things others do not? Do you think seeing into the future is valuable? We are very happy to use animals that have super-senses like the dogs to sniff out drugs and explosives, so why do people shy away from using that strange “animal” called an Architect? ♦ Does your Enterprise shy away from Architects?

Culture

Questions to Ponder

264 - Culture An Impos s ible Job

PR Culture

Impossible is why Architects get out of bed in the morning. But even though they strive to achieve “impossible” things, their job is, in itself also “impossible”. Being an Architect could be looked on more as an affliction - a cross to bear. Architects can’t stop being Architects (which tends to really irritate people who are not Architects!). Being an Architect is a state of mind, a way of being. For an Architect 1+1 often equals 3, or more likely 1+1 equals blue! Architects tend to break the rules. For when you break the rules, you change the game. Architects know and accept that there are things that they do not know about and go looking for them (remember Donald Rumsfeld?). Most of these things do not magically appear to them, they appear to them because they go looking for them. They wheedle them out from all the background noise. While most people bask in their knowledge and experience, an architect knows there are things he does not know about and actively goes about trying to find them. An architect is much more interested in what he doesn’t know that what he knows. He is often surprised by what he finds, but never bored. Because an Architect tends to see things (and find things) others cannot, they tend always to be in a position of exposing things that were not known, and therefore not taken account of, when decisions were made. This puts them in a position of seemingly to always be challenging decisions and wanting those decisions changed or in some cases reversed. This is not something that is generally welcomed, especially by the type of people who are responsible for making those decisions. Humans are good at spotting patterns - our brains are hardwired for visual pattern recognition. However Architects are different for two reasons. Firstly, because they are more adept at seeing patterns in concepts and thoughts, and secondly, because they can see patterns based on sparse or very limited volumes of information. If the volume of information is large (like a hi resolution photo) anyone can spot the pattern, but if the volume of information is low (like a pixelated photo) only an architect can “squint” with his brain and still see things of value.

Culture - 265

“A wise man gets more use from his enemies than a fool from his friends.”

Culture

It’s not so much about people not understanding what an Architect is saying, but more about people finding it difficult to see the thing the Architect is talking about in the first place. Most people do not (are not allowed to) spend the time to do so. An Architect is an investigator (like Judge Judy!) and one of the tools of an investigator is cynicism - he doesn’t believe anything until he can prove it or at least not have any feeling that he is not getting the whole truth. The yardstick of that is understanding. When an Architect gets an answer to a question and the answer doesn’t make sense (a big part of that is common sense) he asks more questions. This irritates people who are hiding things or do not know what they are talking about and then begin to call the Architect “confrontational” or “rude” or “inappropriate” or any other of a number of vague negative words. When that happens, an Architect knows he is onto something. Many many people go through life unchallenged. Talking about things that they do not really understand - possibly just repeating what they heard someone else say, saying things that while not bare-faced lies, could be considered to be economical with the truth. Many more people go through life also hearing things that perhaps they think are wrong or do not make sense but they do not say anything. They do not question and they do not challenge. The reason for this is not because they are bad people, but is rooted in psychology and man’s deep desire to “not upset the applecart” and to be friends and get on with everyone. Architects do not think or work like that. In a way, they could be thought of being socially inept which can easily come across as being rude, confrontational, arrogant or disrespectful. This is not because they are bad people that should be controlled or ignored. The more you try to control or ignore an Architect, the more vocal he is likely to become. Paying them lip-service or trying to placate them is like adding fuel to a fire and is usually a recipe for disaster. Another problem with Architects is that they tend to be in a minority. Perhaps less than 1% of all people are intrinsically an Architect. Add to this the fact that they tend to see things that others cannot see, and it tends to mean they are also in a minority in terms of their views and ideas and there is great scope for the majority to ignore them as it is usually thought that the majority must always right - “You are the only one that thinks that” - aka you must be wrong because the majority must be right. Another problem with being an Architect (and making a difference) is that we, by definition, only see and only raise fundamental problems. By definition this either means a big grand plan needs to be changed or if the work has been going on that a lot of work has to potentially be thrown away. Both of these things can (and usually do) create massive political problems as the onus is usually on someone “important” having to either change something big he/she previously announced or admit they already wasted a whole lot of money, time and resources. That’s why Management should involve Architects in matters as early as possible. It’s almost a case of - “if you don’t involve us early enough, you better not involve us at all because you probably won’t like what we are going to say!” Architects can often be accused of living in a “perfect world”. This is really just a perception problem. Because they can see things clearly that others cannot see, or cannot easily see, or do not want to see, they can see those things are achievable while others think they are not. In general, people see disagreements as confrontations - and people in general really hate confrontations and tend to do anything and everything to avoid them. That, of course, does not mean that they do not tell anyone, it just means they tell the “wrong” people. How many times have you received bad service in a restaurant or from a call centre but didn’t say anything at the time, but then complained to your friends about it later? There is a saying in retail - a happy customer will tell one friend, an unhappy one will tell ten.

266 - Culture - Baltasar Gracian

Of course, with the advent of the internet, social media and YouTube, if you are unlucky, one unhappy customer will tell thirteen million people - as happened with the famous “United Breaks Guitars” case. United Airlines concentrated on saving $1,200. Their stock price fell 10% four days after the YouTube video was posted wiping $180 million off the company’s value. The resulting bad publicity cost them unimaginably more. But we digress. The bigger the disagreement, the greater the perceived confrontation. There is also an element that the person who believes they hold the most “power” tends to see the other person as confrontational rather than the other way round. If the disagreement is about something small or of no real significance the confrontation is very small, but if the disagreement is about something of fundamental importance then confrontation can be huge. Bearing in mind that Architects only talk about things of fundamental significance, it could be said that appearing to be confrontational is not only possible, it is mandatory! “As an Architect, if you aren’t annoying someone, you aren’t doing your job properly” - Pragmatic

The new light Architects expose (through the old windows of peoples existing perceptions) is very challenging for many people as this basically takes them out of their comfort zone. Big time. Most people do not like that at all. Most people are happy to continue to live their lives, in their familiar comfortable pond, and they react in all manner of negative ways when someone tries to explain there is life outside their pond, especially when it impacts their pond in a big or fundamental way. They are not bad people. So, where do architects “fit”? The simple answer is, nowhere and everywhere. They don’t really fit anywhere! This is why many architects always have an uneasy feeling of being different and misunderstood. “When green is all there is to be It could make you wonder why, but why wonder? Why Wonder, I am green and it'll do fine, it's beautiful! And I think it's what I want to be.”

- Kermit the Frog It ‘ain't easy, being green.

Culture

http://youtu.be/hpiIWMWWVco

Culture - 267

KEYPOINT:

"Every noble work is at first, impossible."

- Thomas Carlyle

ADOPTION:

C-Suite: When asking an Architect a question, do not expect an

OO Engineering answer.

Questions to Ponder

How do you react when an Architect talks about unknown unknowns? How do you react when you cannot see what an Architect is trying to explain? How do you react when an Architect is in the minority? How do you react when an Architect exposes (fundamental) things that may cause you to change a previous decision or cause you to "throw away" work?

Culture

♦ ♦ ♦ ♦

268 - Culture What Does An Ar chitect Do ?

PR Some notable quotes that I believe illustrates what an Architect does,

“Architecture at all levels provides the Landing strip of intent for any viable implementation to touch down on.” - {{Gareth Llewellyn}} “An Architect knows his job is done, not when there is nothing more to add, but when there is nothing more to take away.” - Based on a quote from Antoine de Saint-Exupéry, Airman's Odyssey

Culture

“The architect must be a prophet… a prophet in the true sense of the term… if he can’t see at least ten years ahead don’t call him an architect.” - Frank Lloyd Wright “The most important tool for an Architect is his eraser.” - Frank Lloyd Wright

“Every great architect is - necessarily - a great poet. He must be a great original interpreter of his time, his day, his age.” - Frank Lloyd Wright “There is nothing more uncommon than common sense.” - Frank Lloyd Wright “All fine architectural values are human values, else not valuable.”

Culture - 269 - Frank Lloyd Wright

“Early in life, I had to choose between honest arrogance and hypocritical humility. I chose honest arrogance and have seen no occasion to change.” - Frank Lloyd Wright

“Form follows function- that has been misunderstood. Form and function should be one, joined in a spiritual union.” - Frank Lloyd Wright “A great architect is not made by way of a brain nearly so much as he is made by way of a cultivated, enriched heart. ” - Frank Lloyd Wright “Our job is to give the client … not what he wants but what he never dreamed that he wanted; and when he gets it, he recognizes it as something he wanted all the time.” - Sir Denys Lasdon

Culture

“A good Architect can’t sleep because a piece of the puzzle is missing. A bad Architect can’t sleep because his conscience won’t let him.” - Unknown

270 - Culture

KEYPOINT:

"Architecture provides the Landing strip of intent, for any viable implementation to land on." - {{Gareth Llewellyn}}

ADOPTION:

C-Suite: If you know what you want,

but don't know what you need, ask an Architect.

Questions to Ponder

♦ Do you agree with Sir Denys Lasdon? ♦ If not, how would you describe the job of an Architect (of any domain)? ♦ What do others in your Enterprise believe?

Culture

Culture - 271 Ar chitect or Char latan

PR How can you tell the difference between an Architect and a Charlatan?

Please take some time to consider an answer to this question. Think about the kinds of things an Architect and a Charlatan might say. Think about how you would determine (from how they speak and what they say) which one was an Architect and which one was a Charlatan?

Then, turn the page to find the shocking answerâ&#x20AC;Ś.

Culture

DO NOT TURN THE PAGE. YETâ&#x20AC;Ś.

272 - Culture

PR Culture

Culture - 273

Culture

You canâ&#x20AC;&#x2122;t!

274 - Culture Both talk of future benefit that is impossible or difficult to quantify and understand.

♦ The Architect speaks in this way because it’s true. ♦ The Charlatan speaks in this way to draw you in.

Both say that they will have fantastic effects.

♦ The Architect speaks in this way because it’s true. ♦ The Charlatan speaks in this way to draw you in.

Both say they can see into the future.

♦ The Architect speaks in this way because it’s true. ♦ The Charlatan speaks in this way to draw you in.

Culture

Of course, from the perspective of what they do, they are very different, but from the perspective of someone who doesn’t know if you are a Charlatan or not, they are almost indistinguishable by the things they say. It all sounds a bit like “smoke and mirrors”. So, as an Architect, don’t be surprised if people look at you as a potential Charlatan. That is the way an Architect looks to many people - especially the kind of people Architects are “selling” to, such as Leaders, Executives, Managers, CxO’s, Directors etc. These kinds of people have spent many many years listening to the claims and promises of hundreds of vendors who all want to sell them the next bottle of snake-oil and will promise anything just to make the sale. Architects need to accept that inconvenient truth and deal with it. Face it. Talk about it. Openly. Because if you don’t, many people will view you as a Charlatan, whether you like it or not, whether you realise it or not. They are not bad people, they are just a product of the Context they operate in. A context that consists of a never ending supply of salesman and vendors telling them that their offering is the next big things that has will solve all their problems.

Culture - 275

KEYPOINT:

"The value of Architecture is intangible.

If it were tangible, it would be Engineering."

- Kevin Lee Smith

ADOPTION:

C-Suite: When asking an Architect a question, do not expect a tangible answer.

Questions to Ponder

â&#x2122;Ś Do you or your Enterprise view Architects as Charlatans, promising snake oil that will cure all ills?

cannot really be objectively quantified?

Culture

â&#x2122;Ś Do you or your Enterprise view Architects as people that talk in future promise that

276 - Culture The Pr agmatic Ar chitect Cr eed

PR The Pragmatic Architect Creed (PAC) is a set of values, qualities and behaviours that an Architect in any domain should abide by. It effectively defines the culture of a Pragmatic Architect. If a Pragmatic Architect is asked to do something which conflicts with the Creed, or is aware that another Pragmatic Architect is acting in conflict with the values, he or she should raise a concern within their own department. Their department should investigate their concern. If the Pragmatic Architect remains dissatisfied following the outcome of the investigation, they may bring a complaint to the Pragmatic Architect Commission. In some cases, the Commission may also hear a complaint direct. You can sign the Pragmatic Creed at www.Pragmatic365.org/creed

Culture

Pillars The creed defines of 3 main values:

♦ Communication – Recognising that open, honest and direct communication is key

to both understanding and being understood. ♦ Integrity – Recognising that being a trusted advisor is key to being believed by our clients. ♦ Understanding – Recognising that understanding client’s minds and getting clients to understand our mind is the backbone of what we do.

For each of these values, there are statements that a Pragmatic Architect should be able to recite, with their hand on their heart.

Culture - 277 Communication

♦ I believe that communication is crucially important as an architect. ♦ I believe that communication is key to me understanding other people and getting ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦

others to understand me. I believe that without good communication, no relationship can survive or thrive. I evangelise the value of Architecture and its benefits. I strive to create a "safe environment" where people are free to express their views without fear of punishment or recrimination. I relate new things that people do not know to things that people already know. I can vehemently agree with someone about subject/point “A” when I have only recently vehemently disagreed with the same person about subject/point “B”. I commit whatever time is required to explain and convince others when I am right. I can always explain the reasoning behind my views. I can clearly communicate contextual, conceptual, logical and complex issues and tradeoffs to any audience. I am comfortable talking and presenting to large groups or individuals at any level.

Integrity

♦ I believe that integrity is crucially important as an architect. ♦ I believe that an architect’s biggest asset is the trust he is afforded by the people he works for and the people he works with.

♦ I believe that without trust, no relationship can survive or thrive. ♦ I ensure the interests of the Enterprise as a whole are addressed even if they appear

♦ ♦ ♦ ♦ ♦ ♦

Understanding

♦ I believe that understanding is crucially important as an architect. ♦ I believe that if we do not understand something, people cannot form opinions or ♦ ♦

♦ ♦

solutions to problems. I believe that without understanding, no relationship can survive or thrive. I believe that the primary responsibility of an architect is to enable informed decision making. I believe that the most important question to ask is - Why? I see patterns and structure in everything from traffic congestion to Pop music and flowers. I spend more time understanding a problem domain than determining a solution. I spend more time asking questions and listening than I do talking.

Culture

♦

to conflict with immediate management. I stand up and give an unpalatable truth when no one else will, even though it may mean I lose my job. I will seek to terminate a consulting engagement early if it transpires that the customer can get no or little value by continuing. I always tell the truth. I never hide or disguise things. I tell clients what they need to hear, not what they want to hear. I welcome being proved wrong and if I am, admit it as soon as possible. I suggest only appropriate solutions - even if that is a 'pen and paper solution'.

278 - Culture ♦ I can see disagreement between people when those people think they are in agreement

♦ ♦ ♦ ♦

Culture

♦ ♦

and vice versa. I can abstract anything or idea to a logical and conceptual level. I constantly self-analyse what I do and how I do it to determine how to improve myself and my work. I know the difference between Architecture & Engineering. I know the difference between types of abstraction (Omission/Inclusion, Composition/Decomposition, Generalisation/Specialisation, Idealisation/Realisation) and when and how to use them effectively. I know the difference between types of Idealisation/Realisation (Contextual, Conceptual, Logical, Physical, Operational) and when and how to use them effectively. I know the difference between a model, a meta-model, and meta-meta-model.

Culture - 279 Qualities Rationale

Architects need to be able to see the long term perfect solution but they need to be able to temper that unattainable goal with the tactics of getting things done.

Articulate

They are at home communicating with everyone from the board to the graduate programmer or claims clerk and in scales from one to one to speaking to hundreds at conferences.

Communication is a major part of an Architects role. Being able to listen, ask the right questions, and explain things in words that people can understand from CEOs to the tea lady.

Altruistic

They are selfless, and always focused on what is best for the Enterprise not what is best for them.

Architects are 100% focused on the Enterprise they work for. Even if this means losing their own job.

Persistent

They will not be steamrollered and will stand up for what they believe in.

A good idea or a worthy point that needs to be made for the benefit of the Enterprise, needs to be made regardless of an environment that may not let that happen.

Agnostic

They see all things from Supercomputers to paper, pencils and people as possible solutions to business problems and will propose the most appropriate for any given context not what their favourite is.

Architecture is all about providing business value, not about and Architectâ&#x20AC;&#x2122;s â&#x20AC;&#x153;favouriteâ&#x20AC;? things.

Enthusiastic

They are passionate and enthusiastic about what they do and how they do it.

Enthusiasm is an inspiring trait and Architects need to inspire others in order to affect and guide the culture of an Enterprise.

Strategic

They are focused on long term and lasting benefits rather than short term benefits which compromise long term objectives.

Pragmatic

They are always looking to understand what the perfect solution can be but tempering that with a more commercial and tactical view that relates to the realities of getting things done.

Long term and lasting benefits are more important strategically to an Enterprise.

Culture

Description

280 - Culture They have a broad base of technical and business experience.

Architects deal with breadth rather than depth, and therefore need a broad range of business and technical skills.

Diplomatic

They are sensitive to other peopleâ&#x20AC;&#x2122;s drivers and the political context.

Architecture is more to do with people and culture than anything else. Architects therefore need to be able to discuss often difficult and controversial subjects and truths with tact and sensitivity.

Open

They are open to critique, happy to be proved wrong, and will assimilate and apply new information as it arises.

Architects do not have all the answers. They need to be open to criticisms and open to adjusting their views as new information is exposed or the environment changes.

Generalistic

PR Culture

Culture - 281 Behaviours Rationale

They balance a multitude of different and often competing factors in order to arrive at solutions that make the best of

The problems Architects solve are “wicked problems”. Such problems do not have simple answers. Indeed, the questions they answer are also not simple.

Persuade

They persuade others of their views and the way forward rather than dictating.

Architects rely on others to achieve their aims and as such people must be persuaded of an approach. When people buy into an idea or approach they are much happier and much more productive.

Investigate

They have a nose to seek out things that don’t make sense or could pose threats and risks, and the ability to get to the bottom of them.

Things that don’t make sense are usually problems or opportunities. Either way, Architects need to be able to dig into things where necessary to expose them so that they can be addressed.

Learn

They pick up and assimilate new information quickly and easily and are always open to new ideas, businesses, technologies and processes.

Business and the world is an everchanging place. New things are happening all the time and Architects need to quickly understand them and how they impact the business.

Lead

They lead, motivate, inspire and enable others to reach their potential and create the environment where people want to follow them.

Architecture is all about culture, and therefore to adopt and make the cultural changes required, Architects need to be able to take individuals and the Enterprise on a journey and that journey must be by mutual consent not by dictation.

Abstract

They abstract levels of detail to higher levels to aid understanding and to see hidden relationships and patterns.

Architecture is a lot about seeing structure and patterns. In order to do this an Architect needs to be able to see and synthesise these higher-level structures from underlying information that can be very detailed and/or incomplete.

Facilitate

They guide discussions and workshops in order to get the best out of people.

Architecture is a lot about communication and also about liberating information from others. It is also important to be able to guide discussions

Balance {{Tamás Nacsák}}

Culture

Description

282 - Culture

PR Expose

They seek to expose pertinent information to business leaders to enable them to make more informed decisions.

and to bring people together where there is agreement and to facilitate valued discussed where there are differences. Decisions will get made regardless of whether full and/or pertinent facts are known. Architecture is all about making sure people who make decisions are fully aware of the risks, issues and implications before the decision is made.

Culture

Culture - 283

KEYPOINT:

The Pragmatic Architects Creed™ sorts the wheat from the chaff.

ADOPTION:

C-Suite: Mandate the use of the

Pragmatic Architects Creed™ to recruit Architects.

Questions to Ponder

♦ Would these Qualities and Behaviours be beneficial to your Enterprise? ♦ If so, in what parts of your Enterprise and in what roles? ♦ what happens to people who exhibit these Qualities and Behaviours in your

Culture

Enterprise? ♦ Do you evaluate your current employees or new hires using these Qualities and Behaviours ♦ If not, which Qualities and Behaviours do you actively look for? ♦ Will you sign the Creed?

284 - Culture Or ganis ation Str uctur e Tr aditional vs Pr agmatic

PR Although Enterprise Architecture has more to do with Roadmapping than Project Execution, EA still has a role on projects and that is one of Governance & Lobbying. Since much damage can be inflicted upon an Enterprise by how Projects execute, EA also has a remit to make sure the relationships in “projectland” work together cohesively. Traditional Model Any project today tends to be run with three key roles. The names may change from Enterprise to Enterprise or from country to country but broadly speaking these three roles exist:

♦ The Business Analyst is accountable for the Functional Fitness for purpose, takes

Culture

Functional Requirements as input, and produces a Changed processes and provision of a functional capability as output. ♦ The Technical Architect is accountable for the Technical fitness for purpose, takes Non-Functional Requirements as input, and produces a Operating hardware and software as output. ♦ The Solution Architect is accountable for the whole logical design of the solution, taking the Conceptual Designs produce by Enterprise Architects as input and produces a Logical Solution Design as output. ♦ The Project Manager is accountable for the Project Budget and Deadlines, takes a Project Plan as input and produces a Completed Project as output.

Traditional

In the traditional model usually found in most Enterprises, the relationships are usually dysfunctional. In spite of these dysfunctional relationships (which is at the expense of the Enterprise as a whole) things tend not to change because the people with the power required to change them are usually the ones that are incentivised to perpetuate them.

Culture - 285

The SA, BA and TA “report” to the PM, with the PM being “in charge”. The PM’s voice is the loudest and tends to overrule the SA, BA and TA most (99%) of the time. This creates fundamental and important (negative) implications, but since the PM is not measured on any of them, he doesn’t really care. And why should he, if that is how he is driven. This is normal and understandable, because everyone agrees that most projects these days run over time, budget etc, etc and therefore we need a “good” hard PM to keep everyone in check and make sure the project hits its budgets and timescales. It is strange therefore that given this structure most projects fail. The truth is that while this “power structure” is imposed to ensure projects complete on time and on budget, it is precisely this structure that causes them to fail. Doh! The fundamental problem in the Traditional model, is that the work of the Solution Architect can discover significant problems or opportunities that could fundamentally change the project, other projects or even the Enterprise Architecture in operation. The Solution Architect must go to his boss (the PM) and try to convince him to either:

♦ Remove work from his project and put it in another existing project, then make his

And so, many serious problems, that could be fixed, are ignored and the project fails, while the PM and management still say it succeeded. Alternatively, the unsolved problems cause so much knock-on effect that the project has to extend its deadlines and ask for more budget, while the PM and management still say it succeeded. Alternatively, un-grasped opportunities do not make the savings or benefits they could have, while the PM and management still say it succeeded. Alternatively, all of the above. Pragmatic Model

In the Pragmatic model, the work of Solution Architecture (5-10% of most projects overall budget?) is taken out of projects. Projects therefore become Engineering projects and do not even start until the work of the Solution Architect is nearing completion. In this way, all the problems identified in the Traditional Model (and witnessed by be on every single project I ever worked on as a Solution Architect over 20 years) are solved. All fundamental architectural concerns, problems and opportunities are ironed out without the hindrance of Project Managers.

Culture

project dependent upon that project. ♦ This never happens because PM's do not like being dependent on other things that could influence the success (time and budget) of their project. ♦ Remove work from another project and put it in his project, then make the other project dependent upon his project. ♦ This never happens because PM's do not like having extra work added to their project that could influence the success (time and budget) of their project. ♦ Remove work from his project and put it in a new project, then make his project dependent upon that project. ♦ This never happens because a) starting a new project requires a full cost/benefit analysis to be done and the project portfolio and budgets have already been agreed and cannot be changed and b) because PM's do not like being dependent on other things that could influence the success (time and budget) of their project.

286 - Culture

Culture

In addition, we have renamed Business Analysts to Business Engineers because Business Analysts do not only Analyse, they also Design, largely at the physical level (composition/decomposition is used extensively, and composition/decomposition is not architecture). We have also renamed Technical Architects to be Technical Engineers because a) they are largely dealing with physical designs not logical designs and b) the Architecture title is given to many very experienced engineers, and c) to match the Business Engineer moniker.

Culture - 287

KEYPOINT:

Solution Architecture is too

important to be owned by Projects.

ADOPTION:

Management: Move Solution

Architects work out of projects.

Questions to Ponder

Does your Enterprise have SAs reporting to PMs? Does it create any problems? If so, what do you need to do to solve them? Do your Project Boards hear from the PM and SA or just the PM? If not does this cause any problems or issues? If so, what do you need to do to solve them?

Culture

♦ ♦ ♦ ♦ ♦ ♦

288 - Culture Enter pr is e Ar chitect Two Types

PR There are two types of Enterprise Architects:

♦ Type 1 - This type of EA is responsible for increasing an Enterprises Maturity in its use of EA. ♦ Type 2 - This type of EA is responsible for “doing” Enterprise Architecture.

Most (99.999%) Enterprises only ever recruit for a Type 2 Enterprise Architect - and therein lies the problem… Whilst the job of the Type 2 EA is massively important and the things they produce are of massive benefit to the Enterprise, they are, in most cases, severely limited by the context of MAGIC that they are forced to work within. But I hear you cry:

Culture

“A good workman never blames his tools” This is a common saying (“tools” = “context”) and does have some validity. However, it is also true to say that if you force a surgeon to:

Save money – by not washing his hands before an operation (Immature Methods), Save money – by using untested blood and medicine (Immature Artefacts). Save money – by not following the guidance of the GMC (Immature Guidance). Save money – by using carving knife instead of a scalpel (Immature Items). Save money – by not living the Hippocratic Oath (Immature Culture).

♦ ♦ ♦ ♦ ♦

You can hardly complain when patients keep dying. Stopping patients dying is not achieved by replacing the Surgeon with another surgeon operating (no pun intended!) in the same context. Stopping patients dying is achieved by

Culture - 289

improving the Methods, Artefacts, Guidance, Items and Culture that they are forced to work within. It is not in the Surgeon’s power to increase the maturity of the Methods, Artefacts, Guidance, Items and Culture that surgeons are forced to work within, that is the job of Management either with the guidance of Surgeons (hopefully!!) or by Management giving the Surgeons a mandate and resources to do so themselves. I say hopefully because the National Health Service (NHS) in the UK demonstrates time and time again Management’s utter lack of involving and listening to people who actually do the work regarding how to increase its maturity. But this is only one sad example of a much bigger cultural problem which exists all over the world today. A culture which effectively says, that people who are more senior are the ones who somehow magically know how to improve things. This used to be the case many decades ago when the Manager did know everything because he did the job himself for 40 years before he became the Manger, but in the 21st century Managers do not get appointed on that basis. They get appointed for all manner of strange reasons, all of which do nothing to help them actually do their job properly. As we have said before, every Enterprise is already “doing” EA (operating on patients), it’s just a question of their maturity in How they do it. And in the same way that a surgeon cannot improve his context without a mandate, the same is true of a Type 2 EA. If the Type 2 EA’s job description does not give him a mandate to increase maturity, then he is doomed to work within the constraints of his predecessor and almost certainly produce the same results. This always seems to come as a complete shock to Management who then blame that EA and go recruiting for a “better” one. Doh! What is happening is that Management (because of Cognitive Dissonance) is actually ignoring the fundamental problem - which is themselves! “We have seen the enemy, and the enemy is us!”

- W.E.Deming

We could also say:

Culture

“A good manager never blames”

290 - Culture

KEYPOINT:

Recognise that there are two types of EA: 1. Those that improve how EA is done. 2. Those that “do” EA

(Strategic Transformation Planning and Governance).

ADOPTION:

Management: Ensure everyone in the

Enterprise understands that there are two types of Enterprise Architect.

Questions to Ponder

♦ Does your Enterprise recognize these two types of EA? ♦ How much time is spent on the duties of Type 1 vs Type 2? ♦ If you spent more time improving EA, would that reduce the amount of time spent

Culture

"Doing" EA?

Culture - 291 Type 1 Requir ements

Culture

PR F

It is possible for one person to fulfil both roles (if given the mandate to do so), however, they are different in some fundamental respects. The Type 1 Enterprise Architect’s main role is not to “do” EA but to increase an Enterprises maturity in its use of EA - to ultimately allow those who “do” EA to be more effective and efficient. This type of EA does not need any detailed business or IT knowledge, but they do need detailed knowledge about the EA profession, EA Frameworks and how to increase an Enterprise’s EA maturity. That can come from their own innate knowledge and experience (a framework - even though it doesn’t have a name and is not written down), from a published framework such as PEAF, or more likely a mixture of the two. They can work in any type of Enterprise and can be equally as effective. It doesn’t matter to a Type 1 EA whether the Enterprise is a bank, an oil company, a medical centre, the tax office, a university, an aircraft manufacturer, a hotel, an online retailer or a dog grooming company. How transformation is effected and how its maturity can be increased is independent of the type of Enterprise. How Transformation is effected and the approach to the Transformation of Transformation is the same. What will ultimately be transformed (the Enterprise) can be very different but How transformation is effected is fundamentally the same irrespective of the type of Enterprise. This type of EA therefore, is not an expert in your Enterprises Operations. They are (should be) an expert in the Enterprise called Transformation - that exists within all Enterprises. When interviewing for this type of person it is futile to ask questions such as “How much Banking Experience do you have”.

292 - Culture

KEYPOINT:

Type 1 Enterprise Architects help an Enterprise to increase their EA maturity.

ADOPTION:

Management: Ensure everyone in the

Enterprise understands what a type 1

OO EA does.

Questions to Ponder

♦ Do you agree with these basic requirements for a Type 1 EA? ♦ If not, what would you change?

Culture

Culture - 293 Duties

PR Culture

The Type 1 EA is involved in Transformation. Not the Transformation of Operations (What the Type 2 does) but the Transformation of Transformation. As such he also follows the standard Transformation phases of Strategising, Roadmapping, Solutioning, Elaborating, Construction and Transitioning, but these phases should not be confused with the phases in the context of the work a Type 2 EA does. For example, the Type 1 Roadmapping work is not concerned with creating the Roadmaps of the Enterprise, it is concerned with the roadmap to increase the Enterpriseâ&#x20AC;&#x2122;s Maturity in its use of EA. Hence the phases we refer to here are the phases of the maturation of the EA capability.

294 - Culture

KEYPOINT:

Type 1 Enterprise Architect’s work, is primarily to; 1) Evangelise the benefits of EA. 2) Support the

internal EA Team to mature how EA is performed.

ADOPTION:

Management: Ensure everyone in the Enterprise understands what a Type 1 Primary Tasks are.

Questions to Ponder

Culture

♦ ♦ ♦ ♦

Does anyone in your Enterprise perform these duties? If not, who will perform them? Are there people in your Enterprise already capable of performing these duties? If not, where will you get them from?

Culture - 295 Type 2 Requir ements

PR Culture

The Type 2 Enterprise Architect’s main role is “do” EA for which he/she needs detailed (architecturally) Business and IT knowledge. They need to really understand whatever the primary business role of the Enterprise is (be it a bank, an oil company, a medical centre, the tax office, a university, an aircraft manufacturer, a hotel, an online retailer or a dog grooming company) but also the Enterprise Context that that Enterprise Operates within. They also need to really understand the place of IT within the Enterprise but also in the Enterprise Context in terms of vendors, products, services and technologies - both old, existing and upcoming - as part of their job is to highlight Technology Catalysts where a particular vendor, product, service or technology is exposed to the senior business executives that might provide competitive advantage.

296 - Culture

KEYPOINT:

Type 2 Enterprise Architects do

Strategic Transformation planning.

ADOPTION:

Management: Ensure everyone in the

Enterprise understands what a type 2 EA does.

Questions to Ponder

♦ Do you agree with these basic requirements for a Type 2 EA? ♦ If not, what would you change?

Culture

Culture - 297 Duties

PR Culture

The Type 2 EA is involved in Transformation. Not the Transformation of Transformation (What the Type 1 does) but the Transformation of Operations (or Support or Direction). As such he also follows the standard Transformation phases but is only concerned with the Strategising, Roadmapping and Solutioning phases and the Governance and Lobbying between them. He may be required to participate in subsequent phases but only usually when there is a panic or specific strategic guidance is required.

298 - Culture

KEYPOINT:

Type 2 Enterprise Architect’s work, is primarily to; 1) support

Strategising. 2) perform Roadmapping 3) Govern executing projects.

ADOPTION:

Management: Ensure everyone in the

Enterprise understands what a Type 2 Primary Tasks are.

Questions to Ponder

♦ ♦ ♦ ♦

Culture

Adoption - 299

PR ADO PTIO N

Adoption

The Adoption section of PEAF begins at Step 4. Steps 1 to 3 are contained in PEFF and are the same regardless of what part of the Transformation domain is being matured, as steps 1 to 3 define which part requires attention.

300 - Adoption

KEYPOINT:

The Adoption section of PEAF

defines 'HOW' it should be adopted and used.

Questions to Ponder

♦ Do you think EA frameworks should explain HOW they should be adopted? ♦ Which EA frameworks does your Enterprise currently use? ♦ Did they explain how you should adopt them, or leave you to figure it out for yourself?

OO F

Adoption

Adoption - 301 Guidance

Adoption

302 - Adoption

KEYPOINT:

The Guidance section of the

Adoption section of PEAF defines

what is used to guide people in their decision making.

ADOPTION:

C-Suite: Follow the Guidance in the

OO Adoption Section of PEAF

Adoption

Adoption - 303 What Is EA Br idging the Gap

PR Many people believe and espouse that…

Note - use of the term “The Business” here, is used because that is how many people who talk about EA refer to “everything else in the Enterprise that is not IT”. I do not necessarily subscribe to this label but since most people use these two terms together I am also using them to help explain, using terms that people currently use. Until around 2005 I also thought that EA was all about “Bridging the gap between the business and IT”. The reason I thought this was mainly because that’s what everyone, including many EA’s, were telling me. But having begun my quest for the truth of EA it soon dawned on me, that the idea that EA is some kind of physical thing that bridges a gap was erroneous. In any Enterprise “The Business” and IT are inextricably linked. There is no gap. In addition, if you view EA as a kind of marriage counsellor between “The Business” and IT, helping to bring them closer together, then again EA should not be about bridging the gap, it should be about removing the gap. In fact, the only purpose of EA is to enable and support the Transformation of the Enterprise. If the Enterprise never needed to change, there would be no reason to use EA at all. So, since EA is all about enabling Transformation, and since EA (aka Roadmapping) is the work that is done between strategy formulation on the one hand and the execution of projects on the other, it becomes obvious that a much more valid statement was: “EA is all about - Bridging the gap between Strategy and Execution (of change)”

Adoption

“EA is all about - Bridging the gap between the business and IT” Many People

304 - Adoption - Pragmatic

In this way, EA is a continuous process of reacting to changes in the Enterprise’s Strategy, and guiding the required transformation. This is where common phrase comes from… “EA is not a destination. It’s a journey” - Many People

Which sounds very good. However, if we think more deeply, EA is not even the journey. EA is more about the way of making the journey. Many organisations make their journey without the use of Enterprise Architecture (yes they are all “doing” EA but there comes a point when something is being done so badly, that it ceases to be that thing. For example, if you cremate a chicken, can we still call this “cooking the dinner”?) And so, we can say that: “EA is not a destination. EA is not Even a journey. EA is a way of travelling”

- Pragmatic

OO F

Adoption

Adoption - 305

KEYPOINT:

EA is about bridging the gap between Strategy and Execution

ADOPTION:

C-Suite: Accept that EA is not about bridging IT and The Business, but is about Bridging Strategy and

OO Execution.

Questions to Ponder

♦ Do people in your Enterprise think EA is about Bridging the gap between the business and IT?

♦ Do you think that talking in terms of Business and IT in this manner is helpful? ♦ Do you think that the statement that EA is all about Bridging the gap between

Adoption

Strategy and Execution is a more helpful way of viewing the world? ♦ If not, why not?

306 - Adoption You Decide

PR F

Adoption

To borrow from the introduction to The Restaurant at the End of the Universe (a book by Douglas Adams)… There is a theory which states that if ever anyone discovers exactly what EA is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened! This graphic shows three fundamental areas of Transformation; X, Y and Z. Many people say it is not the labels that are important but the things that those labels represent. This is true to a certain extent, however, as POET tells us in the Introduction - language is key. Since we speak in labels all the time, it is vitally important to have a common understanding of what we mean when we use them, or at the very least, the ability to realise when we are not using the labels to mean the same thing and to act appropriately. This is especially true when a label (name or acronym) is used widely and extensively. Enterprise Architecture (EA) is definitely in that category. There is (and has been for a long time) endless debate about what EA is. All those debates revolve around everyone putting forward their definition and then arguing about it. This approach has not taken us forward over the last 20 years, and is unlikely to do so over the next 20 years. Therefore, a more Pragmatic approach is needed. Instead of just stating what we believe EA to be, let’s consider the question from another direction. Before we start let’s define a useful linguistic pattern, with reference to talking about eh architecture of something. We could say that… …X Architecture, is the fundamentally important structure of the whole of X, set in the context of things outside of X that affect X, or are affected by X. So that we can then easily say that

Adoption - 307 •

•

Application Architecture is the fundamentally important structure of the whole of an Application, set in the context of things outside of the Application, that affect it, or are affected by it. Building Architecture is the fundamentally important structure of the whole of a Building, set in the context of things outside of a Building, that affect it, or are affected by it. Aircraft Architecture is the fundamentally important structure of the whole of an Aircraft, set in the context of things outside of an Aircraft, that affect it, or are affected by it.

•

So, given this pattern we have labelled the diagram with 3 things. X, Y and Z. •

•

A shows the fundamentally important structure of the whole of the Enterprise (including but not limited to IT), set in the context of things outside of the Enterprise, that affects it, or are affected by it. B shows the fundamentally important structure of the whole of the IT of the Enterprise, set in the context of things outside of the IT of the Enterprise, that affects it, or are affected by it. C shows the fundamentally important structure of the whole of a Project Solution, set in the context of things outside of a Project Solution, that affects it, or are affected by it.

From this, it is clear to Pragmatic that:

•

A is Enterprise Architecture (or EA for short) B is Enterprise IT Architecture (or EITA for short) which is what the vast majority of people wrongly think EA is. C is Solutions Architecture (or SA for short)

Adoption

• •

308 - Adoption

KEYPOINT:

X Architecture, is the fundamentally important structure of X, set in the context of things outside of X, that affect it, or are affected by it.

ADOPTION:

C-Suite: Understand fundamentally

what the Architecture of anything is.

Questions to Ponder

♦ If you cannot allocate the “EA” moniker to X, Y or Z, what box would you draw on the diagram to represent it?

♦ What names do you use to refer to X, Y and Z? ♦ Does everyone within your Enterprise agree? If not, what needs to be done?

Adoption

Adoption - 309 Solution Ar chitectur e

PR This graphic shows, at a high level, where Enterprise Architecture and Solution Architecture fits in the Enterprise in terms of:

♦ Processes - Planning, Change Projects and Operations. ♦ Disciplines - Solution Architecture, Business Architecture and Technical

Architecture. ♦ Levels - The Contextual Business Vision down to an operating Enterprise. ♦ Input/Output - Shareholders and Value.

Adoption

EA is a culture that pervades an Enterprise. EA does not make decisions. EA is not expensive. Implementation and operation of EA makes subtle changes to an Enterprise’s existing MAGIC related to Enterprise Transformation. The interface between EA and SA is extremely important if an Enterprise’s Transformation efforts are to be Effective, Efficient, Agile and Durable.

310 - Adoption

KEYPOINT:

EA and SA are not the same thing. EA is not just big SA.

ADOPTION:

C-Suite: Understand that Enterprise Architecture is not big Solution Architecture.

Questions to Ponder

♦ Does this fit in with your Enterprises view of where Enterprise Architecture and

Solution Architecture fits? ♦ I not, how would you show how Enterprise Architecture and Solution Architecture fit together? ♦ Is there anything in your Enterprise that you need to change?

Adoption

Adoption - 311 160 Char Challenge Question

Adoption

PR In October 2009, I posted what appeared to be a very simple challenge on “The Enterprise Architecture Network” LinkedIn discussion Group - Describe the purpose of EA. The discussion received more than 1,400 replies. Many people have asked this question numerous times before (and will undoubtedly continue to ask it). Each time the question is asked the result is pages and pages of unstructured text: statements, debates, arguments, counter arguments, bun fights, fallings out, makings up, tiffs, love-ins and wars. Occasionally even peace breaks out! That’s all well and good but it never seemed to solve anything or move things forward in any way. So, I asked for only 160 character messages because I wanted to be able to take what people said, analyse them, so as to arrive at a hopefully agreeable definition that included everyone’s views that people could then agree with. The analysis was carried out during March 2010. Having not been able to find any linguistic analysis tools or anyone else to perform a more detailed analysis, it was (unfortunately for some) left to my brain to do the analysis. Whilst this “manual” analysis was very time consuming it was, I believe, worthwhile. The downside, of course, is that this analysis can be largely subjective and therefore many people may disagree with my analysis. If so, I do not take this disagreement as an indication of failure, but more of an indication of valued discussion. The raw information is provided as part of the PEAF Toolkit and therefore people can perform any analysis on it that they wish to. Ultimately, while anyone can disagree with the results, the only person that can disagree with the structuring of the definitions (which the results are based on) is the person who wrote the original definition.

312 - Adoption

KEYPOINT:

If you want to know the purpose of EA, ask 300+ people.

Questions to Ponder

♦ Did you post an answer to this question around 2009/2010? ♦ If so, what answer did you post? ♦ If not, what would you have posted?

OO F

Adoption

Adoption - 313 Raw Word Clo ud

PR F

Adoption

From over 1,400 postings there were only 374 attempts to define the purpose, the rest, whilst interesting, was the normal (mostly harmless) cut and thrust of argument, counter argument, misunderstanding, joke, etc, etc, etc. This is a word cloud generated from the raw text of those 374 postings, before any detailed analysis has taken place. Although some things stand out it is a confusing picture. You can see why someone listening to all of those people and their postings could easily get confused about what the purpose of Enterprise Architecture was.

314 - Adoption

KEYPOINT:

300+ people use a lot of different

words when describing the purpose of EA.

Questions to Ponder

♦ Do you think this word cloud helps or hinders people’s understanding of EA? ♦ Are there things you think are missing? ♦ Are there things here that you believe should not be?

OO F

Adoption

Adoption - 315 A nalysis

PR Overall

Although I asked people to state the Purpose of EA (the Why) the first interesting thing that became apparent was that people’s responses fell into three distinct categories.

♦ WHY - These responses were a direct response to the actual question asked - the Purpose of EA - WHY do we “do it”.

♦ HOW - These responses didn’t explain the purpose of EA but did describe things

As can be seen, there is generally speaking an equal split between those who define EA in terms of its purpose (WHY), those who define EA in terms of “doing it” (HOW) and those who define EA in terms of what things are produced or used (HOW). This is the first thing that can confuse the issue when people are discussing or trying to understand what EA is because at any one time three fundamentally different things can be being discussed as if they were the same thing. KEY FINDING Any definition we create or discussion we have should always address this fact and any argument and counter argument about some of these things is futile. Let’s stop arguing about which ones are addressed and agree that all of them are valid. WHY All of the WHYs (shown in green) were reviewed and allocated to a structured list of WHYs that was created iteratively by analysing the WHYs.

Adoption

that people do that are related to EA - HOW we “do it”. ♦ WHAT - Again, these type of responses didn’t explain the purpose of EA, this time they described things you would use to do things that are related to EA - WHAT is used to “do it”.

316 - Adoption

Adoption

In terms of why people think we do EA and its purpose, there are many different ideas. The truth is that not one of these is correct - they all are. This is the second thing that can confuse the issue when people are discussing or trying to understand what EA is because in general a person will list one or more of these things but never more than five. This means that any one person only has a piece of the overall picture. KEY FINDING Any definition we create or discussion we have should always address this fact and any argument and counter argument about some of these things is futile. Let’s stop arguing about which ones are addressed and agree that all of them are valid. HOW All of the HOWs (shown in blue) were reviewed and allocated to a structured list of HOWs that was created iteratively by analysing the HOWs. In general terms the same small number of actions are put forward time and again. There is no “clear winner” to speak of with all being tabled generally equally. Again, it is not that one of these is correct - they all are. This is the third thing that can confuse the issue when people are discussing or trying to understand what EA is because in general a person will list one or possibly two, maybe occasionally even three of these but never all of them. Again, this means that any one person only has a piece of the overall picture. KEY FINDING Any definition we create or discussion we have should always address this fact and any argument and counter argument about some of these things is futile. Let’s stop arguing about which ones are addressed and agree that all of them are valid. WHAT All of the WHATs (shown in red) were reviewed and allocated to a structured list of WHATs that was created iteratively by analysing the WHATs. It can be seen that the vast majority of people think of Models as the main artefact or thing to be used when thinking about EA. Processes are also very well represented. Again, it is not that one of these is correct but they all are. This is the fourth thing that can confuse the issue when people are discussing or trying to understand what EA is because in general the vast majority of people will only talk in terms of models, which only represents 50% of the whole. Again, this means that any one person only has a piece of the overall picture. KEY FINDING Any definition we create or discussion we have should always address this fact and any argument and counter argument about some of these things is futile. Let’s stop arguing about which ones are addressed and agree that all of them are valid.

Adoption - 317

KEYPOINT:

If you ask 100 people what is the purpose of EA you will get 100

different responses that only together are likely to give you the full picture.

Questions to Ponder

â&#x2122;Ś If someone asked you the purpose of EA, would your reply be an answer to WHY do EA, HOW to do EA or WHAT is used to do EA?

â&#x2122;Ś How do you think it aids peoples understanding of EA to have so many different

Adoption

answers?

318 - Adoption A nalysed Word Clou d

PR This word cloud was generated using the words from the analysed three perspectives combined. Looking at this cloud and letting it seep into your mind is a reasonable way of getting a flavour of EA.

Adoption

Adoption - 319

KEYPOINT:

Removing synonyms, 300+ people use a small number of different

words when describing the purpose of EA.

Questions to Ponder

Adoption

♦ Do you think this word cloud helps or hinders peoples understanding? ♦ Are there things you think are missing? ♦ Are there things here that you believe should not be?

320 - Adoption Description

PR If we take the output of the analysis and put it into a sentence we get this. Interestingly this seems to me to be a pretty reasonable definition of Enterprise Architecture. It closely matches the one PEAF defines, even though no one actually made the entire statement.

Adoption

Adoption - 321

KEYPOINT:

Arranging the words of 300+ we get a description of the Why (purpose), How (by) and What (using) of EA.

Questions to Ponder

OO F

Adoption

♦ Do you agree with this description of the Purpose of EA? ♦ If not, why not? ♦ What would you add? Take away? Change?

322 - Adoption Simpli fied Descriptio n

PR Reducing those words to something more succinct produces this. Having done all this analysis work I had hoped that this would unite people behind a common definition since it was they who had effectively created it - I added nothing of my own views and only took, analysed and structured what people had said. I was wrong. So wrong! Having arrived at this definition, I then posted a link back to the discussion to a poll where I tabled this definition and asked people if they

♦ ♦ ♦ ♦ ♦

Strongly Disagree Somewhat Disagree Neither Agree Nor Disagree Somewhat Agree Strongly Agree

Out of the 278 people that supplied the 374 definitions, only 15 took the time to vote in the poll. And out of those, most (82%) either disagreed or sat on the fence. There are various possible reasons why this occurred but I think it illustrates one certain truth - people love to disagree more than they love to agree. You might disagree!

Adoption

Adoption - 323

KEYPOINT:

When asking 300+ people the

question “What is EA?”, the answer

is surprising simple when you remove all the noise.

Questions to Ponder

Adoption

♦ Do you agree with this description of the Purpose of EA? ♦ If not, why not? ♦ What would you add? Take away? Change?

324 - Adoption Fr amewor ks Why us e a PM Fr amewor k?

PR Let’s forget EA for a moment. Let’s consider something that we already know - PRINCE2 - a Project Management Framework. You can substitute PRINCE2 here for any other framework that you know of - Six Sigma, MSP, LEAN - the idea here is the same. Here we identify the things that PRINCE2 claims to achieve. It aims to increase our maturity (Effectiveness and Efficiency) with respect to Project Management. Adopting PRINCE2 is not about doing Project Management - it is about how we do Project Management. So, can we achieve all these things without utilising a Project Management framework like PRINCE2? The answer is, yes of course we can. If we have experienced Project Managers and they are allowed to execute their role in the way they know to be efficient and effective they would have no reason to adopt PRINCE2. If we do get the mandate to utilise PRINCE2, will utilising it guarantee we will achieve these things? The answer is of course No. If our people are not given adequate training and time to understand it and/or if they are then driven to execute their role in ways that they then know are ineffective and inefficient then PRINCE2 adoption would fail. So when seeking the mandate and resources to adopt PRINCE2 we would have to say - If we don’t it doesn’t mean we will fail and if we do it doesn’t mean we will succeed. So why would we adopt PRINCE2?

Adoption

Adoption - 325

KEYPOINT:

Using a PM framework will not

guaranteed success. Not using a PM framework will not guaranteed failure.

Questions to Ponder

Adoption

♦ Has your Enterprise adopted other frameworks? ♦ How was the mandate to do so secured? ♦ Who in your Enterprise, was Accountable for its selection and adoption?

326 - Adoption Why us e an EA Fr amewor k?

PR F

Adoption

Here we identify the things that EA claims to achieve. It aims to increase our maturity (Effectiveness and Efficiency) with respect to Strategising, Roadmapping and Project Governance. Adopting EA is not about doing these things - it is about how we do these things. So, can we achieve all these things without utilising an EA framework like PEAF? The answer is, yes of course we can. If we have experienced Enterprise Architects and they are allowed to execute their role in the way they know to be efficient and effective they would have no reason to adopt PEAF. If we do get the mandate to utilise PEAF, will utilising it guarantee we will achieve these things? The answer is of course No. If our people are not given adequate training and time to understand it and/or if they are then driven to execute their role in ways that they then know are ineffective and inefficient then PEAF adoption would fail. So when seeking the mandate and resources to adopt PEAF we would have to say - If we don’t it doesn’t mean we will fail and if we do it doesn’t mean we will succeed. So why would we adopt PEAF? Like PRINCE2, PEAF is just an approach, a framework, a method for doing something. They are “tools”. Using them does not guarantee we will be successful. Not using them does not guarantee we will fail. We don’t have to use it - our Enterprise will not cease to operate if we do not use EA. But it is likely that we will be overtaken by those that do. However, today's world is changing… Effectiveness, Efficiency, Agility and Durability are becoming defining characteristics of successful Enterprises. As time passes our Enterprise needs to get more Effective, Efficient, Agile and Durable with respect to how we execute Strategising, Roadmapping and Project Governance or we will be overtaken by those that do. The 20th century was defined by a mind boggling array of new Enterprises. While new Enterprises and markets will always be created, the 21st century will be defined not by new

Adoption - 327

Adoption

Enterprises or markets but by how Effective and Efficient, Agile and Durable those Enterprises are. The question is not, can we afford to embrace EA? The question is, can we afford not to?

328 - Adoption

KEYPOINT:

Using an EA framework will not

guaranteed success. Not using an EA framework will not guaranteed failure.

Questions to Ponder

Adoption

♦ Has your Enterprise adopted an EA framework? ♦ How was the mandate to do so secured? ♦ If not, who in your Enterprise, is Accountable for the EA capability?

Adoption - 329 Wher e to Star t ? Can I s tar t with one Depar tme nt?

PR “Do I have to ‘do’ the whole Enterprise?” “Can I start small and get some benefits first and then grow it out?” “Can I start with one Department or Business Unit?” These are common questions asked by management who may be “kind of sold” on the idea of EA, but don’t want to spend too much time and money on. They want to dip a toe in the water rather than dive in. In many respects, it’s a bit like asking “Can I get a little bit pregnant?!” But here’s the thing… We first must understand which question is being asked, and answer it accordingly.

♦ Question #1 – With respect to “doing” EA (primarily Roadmapping), can I start with one Department?

♦ Question #2 – With respect to using PEAF to mature our EA capability, can I start

Adoption

with one Department”

330 - Adoption

Adoption

Question #1 – “Doing” EA (primarily Roadmapping) Aka using EA to mature the Operations capability of the Enterprise (DOTS). Can I start with one department? The answer is no. Why? When thinking about Enterprise Architecture, most people think about the noun - the structure of the Enterprise. This is perfectly understandable since an Enterprise Architecture is exactly that - the structure of the Enterprise. It therefore logically (albeit incorrectly) follows that you can decide to make the domain of “Enterprise Architecture” a sub-part of the whole Enterprise structure - like a Department or a Business Unit for example. Hence people often say “we will start small and just ‘do’ EA on one Business Unit”. However, if you think about the purpose of EA and what it is used for, then this simplistic structural view breaks down. If we consider Enterprise Strategy, there will be some Objectives that can be satisfied by the Operations part of the Enterprise. These objectives pass down to Operations and they carry out the work to satisfy these Objectives. However, there are some objectives that the Operations part of the Enterprise cannot currently fulfil, and to be able to fulfil them, they need to be transformed or changed first. These objectives are fed into the Transformation part of the Enterprise, which initially performs the Roadmapping phase. This Roadmapping work creates a portfolio of Projects, which then execute and change/transform various parts of the Operations part of the Enterprise. So, the domain we choose to “do” EA on, is not determined by selecting an arbitrary part of the Enterprise like one Business Unit, but upon what needs to be Transformed, which is driven by the part of the Enterprise’s Strategy that Operations cannot satisfy in its current structural state. The only exception to this, is when a very large Enterprise (for example a government) is composed of very large parts that each have their own EA Capability. In that case, you could reduce the scope, to doing EA to one of those large parts. Question #2 – Using PEAF to mature our EA capability Aka using EA to mature the Transformation capability (the EA part) of the Enterprise (DOTS). Can I start with one department? The answer is yes. Why? Because we are only maturing one department – the EA department. We are not maturing any part of the Operation part of the enterprise. The only exception to this, is when a very large Enterprise (for example a government) is composed of very large parts that each have their own EA Capability. In that case, you could reduce the scope, to doing EA to one of those large parts. While Enterprise Architecture is primarily Roadmapping, we also show some changes to the Business Architecture (Strategising) and Solution Architecture (Solutioning) domains because one feeds EA and one is fed by it, meaning if we do not align BA and SA, the improvements to the EA capability can be lost.

Adoption - 331

KEYPOINT:

The “scope” of EA (at a point in

time) is determined by the Enterprise Strategy (at a point in time) not on a Department or Business Unit level.

ADOPTION:

Management: Accept that you cannot

arbitrarily choose to start with 1 Department or Business Unit.

Questions to Ponder

♦ What do people in your Enterprise think about the scope of EA? ♦ Are they arbitrarily trying to descope EA to a structural part of the Enterprise? ♦ If they are, how does this fit in with the work being undertaken by the people

Adoption

involved in Roadmapping? ♦ Does your Enterprise have more than one Roadmapping Group?

332 - Adoption EA Catalys ts

PR Here we see an examples of what we call EA Catalyst Projects

Mergers & Acquisitions Business Unit Consolidation Introduction of New Products, Services or Lines of Business Outsourcing a Business Function Divesting a line of Business Operational Cost Reduction Business Transformation Building Relocation Strategic Planning Increase Business Agility, Efficiency and Effectiveness Streamlining Business Processes Consolidation of Suppliers, Technologies or Applications Business Process Management Business Process Re-engineering Off shoring Market/Shareholder Pressure

Adoption

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

Adoption - 333 They all have one thing in common. Large Enterprise Transformation. When an Enterprise is faced with such a large change, they also must face a simple truth:

“Measurement is the first step that leads to control and eventually to improvement. If you can’t measure something, you can’t understand it. If you can’t understand it, you can’t control it. If you can’t control it, you can’t improve it.” - H. James Harrington

Which basically boils down to

For this reason, the Catalyst Project is forced to start modelling things (Current State, Target State, Roadmap) and in order for them to do that, they need to acquire a modelling Tool (Review, Select, Install) and decide upon a Metalmodel. If we add to the diagram (in green) the work to setup or mature an EA capability (maturing the Methods, Guidance and Culture), and we add the work to produce a first roadmap using that EA capability (Integrating the data loaded), it would add approximately 5% of extra cost to the Catalyst Project. If this 5% increase in resources is added, it would enable the reuse of approximately 15% of the work done in the Catalyst Project. Namely the selected Tool and its associated Metamodel, and the Current, Target and Roadmap models that where produced. What usually happens if this 5% additional work is not added to the Catalyst Project (which is 99.9% of the time) is that because the a) the processes to create and maintain the information in a coherent, sustainable and Pragmatic way and b) the information in the Tool is not kept up to date and rapidly falls out of date and therefore cannot be trusted (used). In addition, the (often expensive) licenses to use the Tool are allowed to expire or reduced to a few select people, which also prevents the data from being reused and kept up to date. Hence the Tool, Metamodel and the Current, Target and Roadmaps are effectively thrown away. So, it is obvious that if you want to setup or mature an EA capability within an Enterprise, the perfect time to do it would be at a time where a lot of the require work has to be done anyway – known as EA Catalysts. And the bonus is you will gain the 15% that would otherwise have been thrown away. The problem is, most Enterprises embark on a Catalyst Project only from the perspective of the objectives of the Catalyst Project (albeit large) rather than from the perspective of putting sustainable things in place that can be used in the future as well, long after this project has ceased to exist - which is the whole point of an EA model. It is a great shame, because it is precisely at these times where you can get benefit from an investment in EA in the shorter term - since that investment will generate immediately benefit for the large Transformation “project” in question, and will serve as an immediate stress test. It is obvious that the largest proportion of all the things that needs to be done to set up or mature an EA Capability, are being done as part of the Catalyst Project. However, because the other things in red are not done, the investments made are not sustainable as the modelling tool is limited to a few select people and the data in it becomes more and more out of date.

Adoption

"You cannot change what you cannot understand and you cannot understand what you cannot see." - Kevin Smith

334 - Adoption

PR F

Adoption

Adoption - 335

KEYPOINT:

If you cannot invest in an increase in

EA Maturity as part of an EA Catalyst, you probably never will.

ADOPTION:

C-Suite: Mandate that large change

initiatives, preserve the EA work they

OO do and make it sustainable.

Questions to Ponder

♦ Have any of these catalysts existed in your Enterprise? ♦ What Projects that your Enterprise has executed, would you deem to be large enough to be called an EA Catalyst Project?

Adoption

♦ Was the opportunity to adopt EA properly taken up? ♦ If not, why not? What needs to change so next time it will be?

336 - Adoption Vis ion

PR Without a clear vision that the Enterprise can understand, agree and believe in, any attempt to increase one’s maturity will fail. Here we set out the fundamental reasons (Goals) why an increase in maturity is desirable, the means by which we will achieve them (Strategies, Tactics) and what we must do (Objectives).

♦ The Goals of Enterprise Architecture are dependent upon and (should) support an

Adoption

existing Enterprise Goal (shown in grey) - to Increase the Effectiveness, Efficiency, Agility and Durability of the entire Enterprise. If it is not, the first thing to do is to get the Strategy creators to either explicitly add it, or explicitly state that it is not a Goal. If the Strategy creators do not believe that increasing the Effectiveness, Efficiency, Agility and Durability of the entire Enterprise is a goal, then they will not agree that increasing the Effectiveness, Efficiency, Agility and Durability of the Transformation domain of the Enterprise is a goal, and so we can stop and go and do something more interesting instead. ♦ If they do believe that increasing the Effectiveness, Efficiency, Agility and Durability of the entire Enterprise is a goal, then we can ask that they add a goal to Increase the Effectiveness, Efficiency, Agility and Durability of the Enterprise’s Transformation domain. Either way is OK. It is for the Executive Board to decide if these goals are required or not. If they do decide that these goals are valid and required, we can help to achieve them. If not, we will ignore them and therefore an increase in Enterprise Architecture maturity will not be required, for there will be no mandate to do so. If these goals are agreed, we then can flesh out the Strategy by adding an objective of “Increasing our maturity in how we utilise the Architecture Paradigm™”

Adoption - 337 using the Strategy of

“Supporting the Management of the Cost, Risk, Flexibility and Quality of Transformation and the Tactic of

OO F

Adoption

“Using Structural & Transformational models, Performing EA Governance and Managing Transformation Debt™”

338 - Adoption

KEYPOINT:

The Objectives that EA provides,

comes from the Enterprise Strategy.

ADOPTION:

C-Suite: Add increasing the

Effectiveness, Efficiency, Agility and Durability of your Enterprise and

OO therefore your Transformation

Capability and therefore your EA

capability, to the Enterprise Strategy.

Questions to Ponder

â&#x2122;Ś Are the goals of increasing the Effectiveness, Efficiency, Agility and Durability of your Enterprise defined in your Enterprises Strategy?

â&#x2122;Ś If not, do you think they should?

Adoption

Adoption - 339 Goals

PR The rationale for increasing one’s maturity in Enterprise Architecture's MAGIC comes from satisfying four key goals with respect to Enterprise Transformation: Effectiveness Efficiency Agility Durability

Transforming the right things. Transforming more with less. Transforming faster with less. Be effective, efficient and agile in the future with respect to Transformation.

Most Enterprises will not have these goals in their Enterprise Strategy in relation to Transformation. They will exist in general but people tend to only think of them in terms of Operations. This is why 99% of Enterprises spend 99% of their time transforming the Operations part of the Enterprise and almost 0% transforming the Transformation part of the Enterprise. The vision that EA brings, and the vision of EA, is to introduce these goals to the Enterprise Strategy with respect to Enterprise Transformation, If the C-Suite do not wish to add these goals to the Enterprises Strategy then that is their decision, but EA exposes the fact that it might be a good idea to include these goals. Therefore EA does not introduce these Goals (“Ends”) per se, but it does help to provide the “Means” by which they can be effectively and efficiently achieved both for today and in the future. The goals are closely interlinked. Achieving one goal can compromise the others. For example, increasing Effectiveness without regard to Efficiency, Agility or Durability can have severe consequences for the Enterprise Transformation and the things that Enterprise Transformation ultimately delivers. The key is to manage each of these competing goals and to make sound informed decisions having considered the impact and implications. Effectiveness

Adoption

♦ ♦ ♦ ♦

340 - Adoption How effective does Enterprise Transformation need to be? How do we know if we need to increase our effectiveness or not? These questions can be considered from two perspectives:

♦ Defensive

How fast do I have to run in order not to be eaten by a Tiger? Answer: Slightly faster than the slowest of your competitors. ♦ Offensive How fast do I have to run in order to be a winner? Answer: Slightly faster than the fastest of your competitors.

EA cannot and does not determine whether an Enterprise needs to increase the effectiveness of its Transformation efforts or not - only the Management can do that. EA helps the Management to make Enterprise Transformation more effective. Efficiency This goal is concerned with at what cost the Enterprise can Transform. Comparing the past with the world today…

♦ In the past, Operational Efficiency was a key business driver and differentiator. This

led to production lines, mechanisation and automation. ♦ In today’s business world, Operational Efficiency is still important. However, as Enterprises have got more and more efficient in this area the scope for further gains is reducing.

In addition, because of a lack of attention to Transformational Efficiency, Operational Efficiency has been slowly and quietly adversely affecting Transformational Efficiency, which then adversely affects Operational Efficiency. Agility This goal is concerned with how fast the Enterprise can transform itself to adapt to internal and external pressures and priorities. Let’s consider some Transformation drivers: Changes in Legislation, Competitor’s strategic moves, The possibility of mergers and acquisitions, Introduction of new products and services, The wax and wane of suppliers, The creation and demise of market and customer segments, The creation and demise of market and customer Channels, Changes in scale, The introduction of new machines (and technologies)

♦ In the past all these things happened rarely if at all ♦ In today’s business world these things could happen annually, monthly or even weekly and in the case of the Introduction of new products and services, could happen daily.

In general terms, if we compare the past to the world today:

♦ In the past, Agility was not really important at all because things didn’t change very

Adoption

much. Enterprises tended to produce the same products in the same way using the same people and the same tools for long periods of time. Things that could change which would require the Enterprise to change only changed very slowly. When an Enterprise did need to change (since processes were largely carried out by people who were extremely easy to change/control) it could make those changes very quickly by telling those people to do different things, by employing more people or by sacking people. ♦ In the world today, Enterprises exist in an environment of constant and fundamental change, and therefore Enterprises need to be able to adapt and change quickly to cope with this maelstrom. They need to be more Agile. Those that can will grow and prosper. Those that don’t will succumb to those that do. When an Enterprise needs to change today it cannot rely so much on the limitless adaptability of people

Adoption - 341

to effect that change. This is because so much of how an Enterprise does what it does, is now either completely or partially automated and the complexity of those automated systems and business processes is causing a severe bottleneck in the Enterpriseâ&#x20AC;&#x2122;s ability to react to change in a timely and commercially sensible fashion. Agility is becoming, and will grow even more to become, a key business driver and differentiator. This importance continues to grow year on year.

OO F

Adoption

Durability This goal is actually a component/modifier of the other three goals and can also be termed Sustainability. An Enterprise needs to be Effective, Efficient and Agile today, but it would be unwise to unknowingly compromise how Effective, Efficient or Agile it is likely to be tomorrow. Unless this sustainability component is built into the Enterpriseâ&#x20AC;&#x2122;s Goals, the Enterprise will be solely driven by the needs of now, above the needs of tomorrow. Effectively (and efficiently!) selling tomorrow to live today.

342 - Adoption

KEYPOINT:

EA Goals must be born from the Enterprise Strategy.

ADOPTION:

C-Suite: Add the EA Goals: To

improve the Effectiveness, Efficiency, Agility and Durability of

OO Transformation, to the Enterprise Strategy.

Questions to Ponder

♦ Are the goals of increasing the Effectiveness, Efficiency, Agility and Durability of your Enterprise Transformation capability defined in your Enterprises Strategy?

♦ If not, do you think they should? ♦ Are there others that you would add?

Adoption

Adoption - 343 Str ategies

PR The strategies are inherently related. If too much emphasis is placed on one, things can begin to breakdown and a downward spiral of negative feedback can begin. The key is to manage each of these competing strategies and to make sound informed decisions having considered the impact and implications. In support of the EA goals, the following Strategies are identified: Manage Cost

♦ Reducing the cost of Transformation is important to the Enterprise but not to the exclusion of its other strategies.

♦ Reducing the cost of Transformation can and will have an impact on the other strategies. ♦ In some cases it may be to the Enterprise’s benefit to increase the cost of Transformation. Manage Risk

Manage Flexibility

not to the exclusion of its other strategies. ♦ Reducing the risks associated with Transformation can and will have an impact on the other strategies. ♦ In some cases it may be to the Enterprise’s benefit to increase the risks associated with Transformation.

♦ Increasing the flexibility of Transformation is important to the Enterprise but not to the exclusion of its other strategies.

Adoption

♦ Reducing the risks associated with Transformation is important to the Enterprise but

344 - Adoption ♦ Increasing the flexibility of Transformation can and will have an impact on the other

strategies. ♦ In some cases it may be to the Enterprise’s benefit to decrease the flexibility of Transformation.

Manage Quality

♦ Increasing the quality of Transformation is important to the Enterprise but not to the exclusion of its other strategies. ♦ Increasing the quality of Transformation can and will have an impact on the other strategies. ♦ In some cases it may be to the Enterprise’s benefit to decrease the quality of Transformation.

OO F

Adoption

Adoption - 345

KEYPOINT:

EA Strategies must be born from the Enterprise Strategy.

ADOPTION:

C-Suite: Add the EA Strategies: By

Supporting the Management of the

Cost, Risk, Flexibility and Quality of

Transformation, to the Enterprise Strategy.

Questions to Ponder

Adoption

♦ Are these strategies defined in your Enterprises Strategy? ♦ If not, do you think they should? ♦ Are there others that you would add?

346 - Adoption Tactics

PR The tactics are inherently related. If too much emphasis is placed on one, things can begin to breakdown and a downward spiral of negative feedback can begin. The key is to manage each of these competing Tactics and to make sound informed decisions having considered the impact and implications. Utilise Structural and Transformational Models Maintaining Models to aid Strategic Planning by providing:

â&#x2122;Ś A flexible Modelling Tool â&#x2122;Ś An extensible Meta-model â&#x2122;Ś Methods for managing the models.

Adoption

Enterprises today are more complex than they have ever been. The use of technology itself brings its own level of complexities of course, but there is also increasing complexity in the business structure, process, people, etc and the context it exists within of suppliers, customers, outsourcers, media, legislation, competitors, etc, etc. Enterprises are also in a constant state of change, whether that be to outside events or by the Board constantly searching for ways to improve the Enterprise. A basic rule of thumb is that, if you are going to change something, you first must understand the things you are changing and how changing one part may affect other parts in potentially unwanted or surprising ways. Therefore, in this environment of constant change and complexity it is important to understand the structure of the Enterprise (a description of its parts, but more importantly the complex relationships between those parts) so that when one part changes the management and Board can see how that affects the other parts - Enterprise Impact Assessment. In order to properly collect, manage, and use the information, a tool is required.

Adoption - 347

It is imperative that all the entities and their associated attributes be gathered together in one place so that there is one version of the truth and so that relationships between these attributes can be defined. The driving force, therefore, behind the use of a tool is to reduce and minimize the maintenance and management overhead of a no tool based (manual) approach. Whilst initially a tool may not be required, there comes a time where the amount of time to continue to use a non tool based approach exceeds the cost of adopting a tool. This point tends to be reached a lot sooner than you think. Performing EA Governance Provide the business with governance to manage alignment to the Strategic Plan by providing:

♦ A governance structure ♦ Methods for performing governance

The purpose of governance is to ensure that as change happens on a daily basis, that change is guided in accordance with the bigger strategic and long term picture of the Enterprise. Governance must not put up barriers and stop work from happening, but should allow decisions to be made in the context of the implications and the Transformation Debt™ that may be incurred. Even though strategic plans are put into place, it is not long into the financial year that events can overtake an Enterprise where those plans need adjustment. In addition, by the time work gets down to the projects and programmes to carry out the work, the strategic intent can be easily lost amongst the (rightly) blinkered focus of projects. Managing Transformation Debt™ Expose and manage Transformation Debt™ created when short term tactical choices compromise long term strategic intent by:

♦ Recording Transformation Debt™ as it is created (In Transformation Debt™

Adoption

Agreements - TDAs) ♦ Exposing that as change happens so that more informed business decisions can be made at the proper time ♦ Taking account of it and taking opportunities to reduce it during the Strategising and Roadmapping phases.

348 - Adoption

KEYPOINT:

EA Tactics must be born from the Enterprise Strategy.

ADOPTION:

C-Suite: Add the EA Tactics: Using Structural and Transformational

Models, Performing EA Governance

OO and Managing Transformation

Debt™, to the Enterprise Strategy.

Questions to Ponder

♦ Are these Tactics defined in your Enterprises Strategy? ♦ If not, do you think they should? ♦ Are there others that you would add?

Adoption

Adoption - 349 Objectives

PR Our objective, to increase EA maturity, is achieved by adopting an EA Framework which is effected by following the steps of Adoption. Each iteration builds on previous iterations and leads to increased Effectiveness, Efficiency, Agility, and Durability over time. In support of the EA tactics, the following objectives are identified: Steps 1 to 3

♦ Determining if there is any appetite to increase EA Maturity. ♦ Setting out the business case for starting an initiative to increase EA Maturity,

determining what to change and gaining the required remit, budget and resources to do so.

Steps 4 to 6

♦ Designing, developing and rolling out the necessary changes and adjustments to the

Adoption

Enterprise, identified in steps 1 to 3, in preparation for it to be able to utilise Enterprise Architecture.

350 - Adoption

KEYPOINT:

The Objective of using an EA

Framework must be born from the Enterprise Strategy.

ADOPTION:

C-Suite: Add the Objective of using

an EA Framework is to Increase your

OO Maturity in how you utilise the

Architecture Paradigm™ for defining Enterprise Strategy and

Transformation planning.

Questions to Ponder

♦ Is this Objective defined in your Enterprises Strategy? ♦ If not, do you think they should? ♦ Are there others that you would add?

Adoption

Appendix - 351

PR APPE NDIX

Appendix

352 - Appendix

KEYPOINT:

The Appendix section contains

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

OO F

Appendix

Appendix - 353 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 already had a name -

Appendix

♦ ♦ ♦ ♦

354 - Appendix 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 - 355

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….>

356 - 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 - 357 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

358 - 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 - 359 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 new and elegant way, often

360 - Appendix

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 - 361

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?

362 - 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 - 363 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.

364 - 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 - 365

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.

366 - Appendix

The Frameworks section of PF2

introduces the Frameworks that are part of the Pragmatic Family.

POET and PEAF bridge the chasm between Zachman and TOGAF.

OO People incorrectly think Pragmatic

Frameworks are either too high level and conceptual or incorrectly think they are too large and detailed.

Key Framework comparison criteria: Strategic vs Project, Enterprise vs IT,

Appendix

Detail vs Usability.

Appendix - 367

Raw Scores given by Pragmatic show

PEAF in the lead.

The EA framework you choose,

depends on what you want from your EA framework.

If you favour Project guidance and

Detail, rather than Strategic guidance

and Usability â&#x20AC;&#x201C; then TOGAF is clearly for you.

If you favour Strategic guidance and Usability, rather than Project

guidance and Detail â&#x20AC;&#x201C; then PEAF is

Appendix

clearly for you.

368 - Appendix

PEAF provides the Bootstrap to

kickstart your TOGAF adoption.

PEAF provides the 20%

(fundamentals) that yields 80% of the benefit. TOGAF provides the 80% (details), that yields 20% of the

OO benefit.

PEAF covers the whole of TOGAF and more.

Start with POET and PEAF, and then move on to TOGAF if required.

Appendix

Appendix - 369

POET provides an Operating model

for how Zachman, TOGAF, PEAF, COBIT, ITIL (and all other

Transformation frameworks) relate to each other.

Frameworks that span multiple

domains (Transformation, Operation and Support) fragment the Enterprise.

POET/PEAF/PEEF provides the 20%

(fundamentals) that yields 80% of the benefit. TOGAF provides the 80% (details), that yields 20% of the

Appendix

benefit.

370 - Appendix

The trend for TOGAF is falling. The

Trend for PEAF is rising.

You can’t change what you don’t understand.

You can’t understand what you can’t see.

OO In the Zachman

Framework/Ontology, the Deployer perspective is missing.

POET and PEAF greatly extends what Zachman provides.

Appendix

Appendix - 371

Zachman’s Architect and Engineer

rows are wrong, because

Architecture and Engineering can be performed at any row.

Zachman’s Why and How columns, only equate to the Motivation and

Actions of MAGMA.

Why and How are also questions

answered by moving up and down the rows, not columns.

Zachman’s top two rows equate to

MAGIC but the lower down you go

Appendix

the more IT specific it becomes.

372 - Appendix

Zachmanâ&#x20AC;&#x2122;s (corrected) perspectives

and models can be mapped to the Phases and Levels of POET.

The Language section of PEFF

introduces fundamental terminology that is used throughout Pragmaticâ&#x20AC;&#x2122;s

Frameworks.

Be ever vigilant of the hidden

confusion that language can create.

Everything is a System.

Appendix

Appendix - 373

The Word Enterprise does not mean

“large” or “large IT” or “senior”. It is a general noun.

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

Appendix

its Adoption.

374 - Appendix

Theory is just as important as

Practice

Colour =

Information =

Understanding.

The Ontologies section of PEFF

introduces fundamental ontologies

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

Appendix

Appendix - 375

Methods, Artefacts, Guidance, Items

and Culture (MAGIC) is a Structural Ontology

Motivation, Actions, Guidance,

Measures and Assessment (MAGMA) is a Transformational Ontology

Direct, Operate, Transform and

Support (DOTS) is an Enterprise Ontology

The Methods section of POET

defines 'WHAT' should be done,

Appendix

'HOW' and 'WHEN'.

376 - Appendix

The seven phases of transformation

(Strategising, Roadmapping, Solutioning, Elaborating,

Constructing, Transitioning, Using)

are connected with the Governance & Lobbying discipline.

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.

Appendix

Appendix - 377

Use the Transformation cascade to link the phases together.

Understand how common artefacts relate to the Phase cascade.

Accumulated Transformation Debtâ&#x201E;˘ is reviewed during Roadmapping.

EA is not a destination. EA is not a

Appendix

journey. EA is a way of travelling.

378 - Appendix

Intermediate models satisfy Business

and Technical Objectives from the Enterprise Strategy.

The Project Portfolio effects transformation between the intermediate models.

OO The Enterprise Transformation

Strategy is composed of interlocking Business and IT Transformation Strategies.

Appendix

Appendix - 379

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 Transformation.

Business Architecture, Enterprise Architecture and Solution

Architecture information are closely

Appendix

related.

380 - Appendix

This is the complete map of

information required for

Transformation to be executed in an

Effective, Efficient, Agile and Durable way.

Enterprise Strategy is the Business

Motivation and Capability models, set in the context of the Business Model. Transformation Strategy is the

Roadmap and Operating models, set in the context of the Capability and Business Motivation modelsâ&#x20AC;&#x2122;

There is no single metamodel, that

covers all the information required for Transformation.

Appendix

Appendix - 381

Enterprise Context, Contextual and Conceptual information levels are part of the EA domain.

Enterprise Strategy is the Business

Motivation and Capability models, set in the context of the Business Model.

Transformation Strategy is the

Roadmap and Operating models, set in the context of the Capability and Business Motivation models.

Make sure you have the correct input information for the model you are

Appendix

building.

382 - Appendix

The Items section of POET defines

'WHAT' tools and frameworks are required, 'WHERE' and 'WHEN'.

X Architecture, is the fundamentally important structure of the whole of

X, set in the context of things outside

of X, that affect X, or are affected by X.

Any “good” Architecture ONLY

EXISTS to fulfil a customer’s needs.

Appendix

Appendix - 383

Structural Complexity is a function of

the number of things something is composed of, and the number of relationships between them.

Transformational Volatility is the rate of change of something.

Transformational Complexity is a

function of the Structural Complexity and Transformational Volatility of

Appendix

something.

384 - Appendix

Contextual Volatility & Complexity is

defined as the Structural Volatility & Transformational Volatility of the context of something.

The Architecture Paradigmâ&#x201E;˘ is only applicable when Structural

Complexity and Transformational Volatility are high enough.

As Transformational Complexity rises, use of the Architecture

Paradigmâ&#x201E;˘ becomes mandatory, to preserve your ability to transform, and manage the cost of

Appendix

transformation.

Appendix - 385

As the need to utilise Architecture

increases, the appetite to do so will decrease.

The short term value of Architecture is overestimated.

The long term value of Architecture

is underestimated.

Why is the most important question.

There are 4 types of Abstraction /

Appendix

Elaboration.

386 - Appendix

The relationships between things

rises in a polynomial fashion.

Lines (relationships) are an order of magnitude more important than the boxes.

OO Look for patterns in everything.

Use structured data for all structural

and transformational information, and generate â&#x20AC;&#x153;documentsâ&#x20AC;? as required.

Any EA Tool must integrate with other tools.

Appendix

Appendix - 387

The Culture section of POET defines the roles and the culture required.

The Pragmatic Role and Phase

patterns are key to assigning RACI to roles.

Architecture and Engineering are two sides of the same coin.

Think (and Plan) Strategically

(Architecture), Act Tactically

Appendix

(Engineering)..

388 - Appendix

The line between Architecture and

Engineering is a blurred one.

Architecture is performed largely in the early phases of Transformation, while Engineering is performed largely in the later phases.

Architecture and Engineering can be performed within any phase.

The relationship between

Architecture and Engineering as we move from the top to the bottom

Appendix

phases is complex.

Appendix - 389

Know and exploit the fundamental

difference between Architects and Engineers.

Architecture and Engineering, bring important things to the table, and

makes the whole much more than

the sum of its parts.

A happy productive person, balances what they are good at, with what they love, what others need, and

Appendix

what they want.

390 - Appendix

â&#x20AC;&#x153;The secret of business is to know

something that nobody else knows.â&#x20AC;? - Aristotle Onassis

"Every noble work is at first, impossible."

- Thomas Carlyle

"Architecture provides the Landing strip of intent, for any viable implementation to land on." - {{Gareth Llewellyn}}

Appendix

Appendix - 391

"The value of Architecture is

intangible.

If it were tangible, it would be Engineering."

- Kevin Lee Smith

The Pragmatic Architects Creedâ&#x201E;˘

sorts the wheat from the chaff.

Solution Architecture is too

Appendix

important to be owned by Projects.

392 - Appendix

Recognise that there are two types of

EA: 1. Those that improve how EA is done. 2. Those that “do” EA

(Strategic Transformation Planning and Governance).

Type 1 Enterprise Architects help an

Enterprise to increase their EA maturity.

Type 1 Enterprise Architect’s work, is primarily to; 1) Evangelise the benefits of EA. 2) Support the

internal EA Team to mature how EA is performed.

Appendix

Appendix - 393

Type 2 Enterprise Architects do

Strategic Transformation planning.

Type 2 Enterprise Architectâ&#x20AC;&#x2122;s work, is primarily to; 1) support

Strategising. 2) perform Roadmapping 3) Govern executing projects.

The Adoption section of PEAF

defines 'HOW' it should be adopted and used.

The Guidance section of the

Adoption section of PEAF defines

what is used to guide people in their

Appendix

decision making.

394 - Appendix

EA is about bridging the gap between Strategy and Execution

X Architecture, is the fundamentally important structure of X, set in the context of things outside of X, that affect it, or are affected by it.

EA and SA are not the same thing. EA is not just big SA.

If you want to know the purpose of EA, ask 300+ people.

Appendix

Appendix - 395

300+ people use a lot of different

words when describing the purpose of EA.

If you ask 100 people what is the purpose of EA you will get 100

different responses that only together

are likely to give you the full picture.

Removing synonyms, 300+ people use a small number of different

words when describing the purpose

Appendix

of EA.

396 - Appendix

Arranging the words of 300+ we get

a description of the Why (purpose), How (by) and What (using) of EA.

When asking 300+ people the

question â&#x20AC;&#x153;What is EA?â&#x20AC;?, the answer

is surprising simple when you remove

all the noise.

Using a PM framework will not

guaranteed success. Not using a PM framework will not guaranteed failure.

Appendix

Appendix - 397

Using an EA framework will not

guaranteed success. Not using an EA framework will not guaranteed failure.

The â&#x20AC;&#x153;scopeâ&#x20AC;? of EA (at a point in

time) is determined by the Enterprise

Strategy (at a point in time) not on a Department or Business Unit level.

If you cannot invest in an increase in

EA Maturity as part of an EA Catalyst, you probably never will.

The Objectives that EA provides,

Appendix

comes from the Enterprise Strategy.

398 - Appendix

EA Goals must be born from the Enterprise Strategy.

EA Strategies must be born from the Enterprise Strategy.

OO EA Tactics must be born from the Enterprise Strategy.

The Objective of using an EA

Framework must be born from the Enterprise Strategy.

Appendix

Appendix - 399

The Appendix section contains

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

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

Appendix

Keypoint section.

400 - Appendix

www.Pragmatic365.org is the official

source for all PF2/POET/PEAF related materials, and is constantly evolving.

Pragmatic EA is a non-profit research company, dedicated to developing Best Practice in relation to the

structure and transformation of Enterprises.

Appendix

Appendix - 401 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.

402 - Appendix

KEYPOINT:

www.Pragmatic365.org is the official

source for all PF2/POET/PEAF related materials, and is constantly evolving.

OO F

Appendix

Appendix - 403

Appendix

404 - 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-ecefha!

Without proper preparation, every Enterprise is sailing full speed into their own perfect storm. 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.

A Pragmatic Explanation Business Objective (e.g. reduce costs by 20% Year 1)

Current (Now)

A Pragmatic Explanation

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.

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.

What is Enterprise Architecture

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.

Prog / Proj / Initiative

Prog / Proj / Initiative Prog / Proj / Initiative

Prog / Proj / Initiative

It is not a case of "if" the ship will meet the storm. It is a case of “when”.

Prog / Proj / Initiative

ISBN 978-1-908424-57-0

,!7IB9A8-ecefha!: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!

Prog / Proj / Initiative

IT Objective (e.g. replace out of support apps - Year 1)

Business Objective (e.g. Launch New product Year 4)

Target Year 5

Prog / Proj / Initiative

What preparations has your Enterprise made? To weather its own “Perfect Storm”?

Business Objective (e.g. Comply with new legislation - Year 2)

Prog / Proj / Initiative

Prog / Proj / Initiative Prog / Proj / Initiative

Prog / Proj / Initiative

IT Objective (e.g. Provide DR for mission critical Apps – Year 3)

Kevin Lee Smith The Pragmatic Thinker

Part of the Pragmatic Family