Page 1

PR A

Explanation

OO

Current (Now)

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

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

Prog / Proj / Initiative

Prog / Proj / Initiative

Prog / Proj / Initiative

Prog / Proj / Initiative

Prog / Proj / Initiative

Prog / Proj / Initiative

Prog / Proj / Initiative

Prog / Proj / Initiative

Prog / Proj / Initiative

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 Gardener

Connecting the DOTS

Prog / Proj / Initiative

F

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

Target Year 5

Prog / Proj / Initiative

Prog / Proj / Initiative

Prog / Proj / Initiative

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

P F

Part of the Pragmatic Family


PR

What is EA

A Pragmatic Explanation

OO

V3.1 Kevin Lee Smith

F


Published by:

First published: 1 July 2017 Last updated: 1 July 2017 ISBN 978-1-908424-56-3 (hardback) ISBN 978-1-908424-57-0 (paperback) ISBN 978-1-908424-58-7 (ebook)

http://www.PragmaticEA.com

© Pragmatic EA 2008 - 2017

PR

Pragmatic EA 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. Other Titles in the Family:

Prerequisites

Book

ISBN

PF2

978-1-908424-42-6

Enterprise Direction

978-1-908424-16-7

PF2

Enterprise Operation

978-1-908424-19-8

PF2

Enterprise Transformation

978-1-908424-07-5

PF2

Enterprise Architecture

978-1-908424-10-5

POET

Enterprise Engineering

978-1-908424-13-6

POET

Enterprise Support

978-1-908424-22-8

PF2

The Pragmatic Family of Frameworks

OO

A Pragmatic Approach using POED

A Pragmatic Approach using POEO

A Pragmatic Approach using POET

A Pragmatic Approach using PEAF

A Pragmatic Approach using PEEF

A Pragmatic Approach using POES

Enterprise Debt™

978-1-908424-48-8

A Pragmatic Approach to Enterprise Transformation Governance

Enterprise Architecture Tools A Pragmatic Approach to EA Tool Selection and Adoption

The Culture of Enterprise Transformation The Inconvenient Pragmatic Truth

978-1-908424-57-0

F

What is EA

A Pragmatic Explanation

978-1-908424-54-9

978-1-908424-59-4


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

PR

“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

OO

“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

F

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


Contents

PR

Foreword ..................................................1 Who Should Read This Book? ....................................................................... 2 What Does This Book Tell Me?..................................................................... 2

Introduction..............................................3 Overview.......................................................................................................... 4 Companies............................................................................................................................................. 4 Books & Training ................................................................................................................................. 5

PEAF Foundation and Certified ......................................................................................................................................... 5 What is EA – 1 day Training ............................................................................................................................................. 9 Enterprise Debt™ – 1 day Workshop........................................................................................................................ 10 EA Tools – 1 day Workshop........................................................................................................................................... 11 The Culture of Enterprise Transformation ................................................................................................................. 12

Licensing ............................................................................................................................................... 13

OO

Non-Commercial (Internal).............................................................................................................................................. 13 Commercial (External) ...................................................................................................................................................... 14

Language ........................................................................................................ 15 I Didn’t Mean What You Heard! ................................................................................................... 15 What is a System? .............................................................................................................................. 18 What is an Enterprise? ..................................................................................................................... 20

Ontologies ..................................................................................................... 22 Enterprise ............................................................................................................................................ 22 Paradigm Shift ..................................................................................................................................................................... 22 DOTS ...................................................................................................................................................................................... 24 Board Structure ................................................................................................................................................................... 26

Frameworks .................................................................................................. 29 Coverage.............................................................................................................................................. 29

Context ...................................................31 Context is King™ .......................................................................................... 32 Types .................................................................................................................................................... 34

Why Use POET ............................................................................................ 36

F

Sage Words ......................................................................................................................................... 36 Enterprise Viability ............................................................................................................................ 37 Basic Premise ...................................................................................................................................... 39 WE Deming......................................................................................................................................... 40 The Transformation of Transformation ....................................................................................... 41

How POET Helps ......................................................................................... 43 Fundamental ........................................................................................................................................ 43


Where POET and PEAF Fit......................................................................... 44

PR

Theory & Complexity ....................................................................................................................... 44 Zachman, TOGAF, ITIL, COBIT, PEAF ........................................................................................ 46 PEAF and the TOGAF ADM ........................................................................................................... 49 Level of Guidance / Detail ............................................................................................................... 50

Zachman ........................................................................................................ 51

Basic Message ...................................................................................................................................... 51 Missing Perspective and Model ....................................................................................................... 53 Mapping to POET............................................................................................................................... 55 Overall .................................................................................................................................................................................... 55 Architect/Engineer ............................................................................................................................................................... 56 Why/How .............................................................................................................................................................................. 57 How/When/What/Where/Who ..................................................................................................................................... 58 Perspectives and Models .................................................................................................................................................. 59

Why Use PEAF.............................................................................................. 60 Basic Premise ...................................................................................................................................... 60

What Is Enterprise Architecture? ............................................................... 61

OO

Bridging the Gap................................................................................................................................. 61 You Decide.......................................................................................................................................... 63 EA and SA ............................................................................................................................................ 65 160 Char Challenge ........................................................................................................................... 66 The Question ........................................................................................................................................................................ 66 Raw Word Cloud ................................................................................................................................................................ 67 Analysed Answers................................................................................................................................................................ 68 Overall .................................................................................................................................................................................... 68 Analysed Word Cloud ........................................................................................................................................................ 72 Description ............................................................................................................................................................................ 73 Simplified Description ........................................................................................................................................................ 74

How PEAF Helps .......................................................................................... 75 Fundamental ........................................................................................................................................ 75

Where to Start? ............................................................................................ 76

Can I start with one Department?................................................................................................. 76 EA Catalysts ........................................................................................................................................ 78 The First Step is Always the Hardest............................................................................................ 79 Vision .................................................................................................................................................... 80 Goals ..................................................................................................................................................... 81 Strategies.............................................................................................................................................. 85 Tactics................................................................................................................................................... 87 Objectives ............................................................................................................................................ 89

F

Methods .................................................. 91 Overview ........................................................................................................ 92 Phases ................................................................................................................................................... 92 Models .................................................................................................................................................................................... 92 Example Roles and RACI Patterns ................................................................................................................................ 94

Roadmapping Phase ..................................................................................... 95


Process ................................................................................................................................................. 95

PR

Intermediate Journey ......................................................................................................................................................... 95 Create/update Intermediate Models ............................................................................................................................ 96 Create/update Portfolio Model ....................................................................................................................................... 98 Enterprise Transformation Strategy ...........................................................................................................................100

Artefacts .............................................. 101 Ontology ...................................................................................................... 102

Structural & Transformational ...................................................................................................... 102 Business Model, Operating Model, Capability Model & Roadmaps ..................................... 103

Meta-models ................................................................................................ 105

Hybrid ................................................................................................................................................. 105

Ontology ...................................................................................................... 106

Structural & Transformational ...................................................................................................... 106 Business Model, Operating Model, Capability Model & Roadmaps ..................................... 108

Culture ................................................. 109

OO

Architecture & Engineering ...................................................................... 110

Yin & Yang ......................................................................................................................................... 110 Merged ............................................................................................................................................... 112 Application......................................................................................................................................... 115 Inter Phase ..........................................................................................................................................................................115 Intra Phase ..........................................................................................................................................................................116 Overall ..................................................................................................................................................................................117

The Architect .............................................................................................. 118

Secrets ................................................................................................................................................ 118 An Impossible Job ............................................................................................................................ 120 Architect or Charlatan ................................................................................................................... 125 The Pragmatic Architect Creed ................................................................................................... 128 Integrity ................................................................................................................................................................................128 Communication .................................................................................................................................................................129 Understanding ...................................................................................................................................................................129 Qualities ...............................................................................................................................................................................130 Behaviours ...........................................................................................................................................................................131

Risks.............................................................................................................. 134

The Brick Wall of Misconception ................................................................................................ 134 Many People will Hate EA ............................................................................................................. 150

Enterprise Architect................................................................................... 151

F

Two Types......................................................................................................................................... 151 Type 1................................................................................................................................................. 153 Requirements .....................................................................................................................................................................153 Duties ...................................................................................................................................................................................154

Type 2................................................................................................................................................. 155 Requirements .....................................................................................................................................................................155 Duties ...................................................................................................................................................................................156


Environment ........................................ 157

PR

The Architecture Paradigm™ ................................................................... 158 Purpose ..............................................................................................................................................159

It’s Not What You Think ................................................................................................................................................159 Structural Complexity ......................................................................................................................................................161 Transformational Volatility .............................................................................................................................................163 Transformational Complexity ........................................................................................................................................164 Contextual Volatility & Complexity .............................................................................................................................166

Justification ........................................................................................................................................167

Applicability .........................................................................................................................................................................167 Cost and Ability ..................................................................................................................................................................169 Investment ...........................................................................................................................................................................171 Procrastination ...................................................................................................................................................................172

Appendix .............................................. 175 Background .................................................................................................. 176

OO

Why Were They Created? ............................................................................................................177 Where Did They Come From? ....................................................................................................178 When Were They Created? .........................................................................................................180 What Was Used to Create Them? .............................................................................................181 How Were They Created?............................................................................................................183 Who Created Them? ......................................................................................................................184

MBTI .....................................................................................................................................................................................185 DISC ......................................................................................................................................................................................186

Keypoints ..................................................................................................... 187 Sources & Resources .................................................................................. 228

F


OO

PR

F


Introduction - 1

PR

FOREWORD

OO

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

“When you are drowning, it’s too late to learn to swim.” 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. The unprepared ship will often catch more fish than other more well prepared ships - not having to comply with safety regulations they are able to cast and wind in the nets much faster and therefore fill their holds faster. Holds also have more space due to the absence of emergency equipment which means more fish can be stored before having to return to port to offload them. It is not a case of “if” the ship will meet the storm. It is a case of “when”.

F

What preparations has your Enterprise made for its own “Perfect Storm”? Kevin Lee Smith The Pragmatic Mariner


2 - Introduction

Who Should Read This Book?

PR

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.

What Does This Book Tell Me?

OO

Enterprise Architecture has existed (in many forms) for a long time, and there are many “experts” around to educate others. Books and training courses abound. 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 fitting that the acronym does not need to change!) 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 a 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.

F


Introduction - 3

PR INTRODU CTION

OO F


4 - Introduction Overview Comp anies

OO

PR Pragmatic EA is a non-research company developing Pragmatic 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 EA or not) to help Enterprises mature any or all parts of their Transformation Capability (from Strategy to Deployment). This is done by consulting, training and publishing material.

F


Introduction - 5 Books & Tr aining

OO

PR Various training courses are available which are structured for easy and appropriate adoption. 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 forms the Foundation of PEAF. These courses educate individuals and organisations 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. PEAF Foundation and Certified

PEAF Foundation (2 days) set 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 (2 days) concentrate on the specifics of the EA domain and sets out the fundamental pieces to be put in place to be successful. Classroom Format All courses are run by a Pragmatic Certified Trainer. Each day consists of 6 hours of presentation and discussions, finishing with an Exam lasting 1 hour.

F

9-12 12-1 1-4 4-5

Presentations/discussions Lunch Presentations/discussions Certification Exam

Certification Exams


6 - Introduction

PR

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

OO

Self Study Format Self Study Training and Certification is split into four 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. When taught in the classroom, the course is completed in 4 days. However, for self-study, a more relaxed one module per week or two weeks is suggested. You could do one module every three weeks, one month or even three months - the timing is completely up to you. The books supplied contain 100% of the content. Each study guide provides a proportion of the content from the books required for the related exam. Exams are run online via Skype using our online examination system. You can schedule your exam using the link on your personal Exam Dashboard. All exams are closed book. At least 1 week prior to taking an exam… Book your exam by using the link provided on your personal Exam Dashboard. Provide photo proof of identity (photo copy of your passport or local identity card) by emailing it with your name to Admin@PragmaticEA.com. Before the exam starts You must be a in a closed room with no one else present (multiple people taking the same exam in the same location is allowed). You need a web cam that must always be turned on. You need a laptop or tablet and uninterrupted access to the internet and enough bandwidth to be able to send video. You must be available for 30 minutes before the exam for identity checks to be completed and to receive instructions on how to use the exam system. 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.

F


Introduction - 7

PR

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. 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 EA Ltd. Previous comments We have a 100% positive feedback from the course. Some comments below but all comments (unedited and unabridged) can be read at http://www.pragmaticea.com/comments-training.asp

OO

“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

F


8 - Introduction

PR

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 http://www.pragmaticea.com/commentssurvey.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

OO

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

F


Introduction - 9 What is EA – 1 day Training

OO

PR

Why Should I attend this Training? Enterprise Architecture has existed (in many forms) for a long time, and there are many “experts” around to educate others. Books and training courses abound. 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 fitting that the acronym does not need to change!) 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 a 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 attend? 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.

F


10 - Introduction Enterprise Debt™ – 1 day Workshop

OO

PR

The Enterprise Debt™ Workshop is an introduction and hands on workshop designed to enable Enterprises to take back control of their Transformation domains by adopting a Pragmatic Approach to Enterprise Transformation Governance. Run over 1 day, the first part of the workshop presents the concepts required to understand Enterprise 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 Enterprise Debt™ when those principles are violated, and making decisions to accept the debt created or provide the resources required. Why Should I attend this Workshop? 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 Enterprise 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.

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

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

Who should attend? 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.

F


Introduction - 11 EA Tools – 1 day Workshop

PR

The EA Tools Workshop is an introduction and hands on workshop designed to enable Enterprises to effectively and efficiently; choose a tool, and how to operate it in a sustainable way by adopting a Pragmatic approach to EA Tool Selection and Adoption. 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.

Why Should I attend this Workshop? Enterprises (Public Companies, Private Companies, Government Agencies) spend a lot of 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.

OO

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. Who should attend? 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.

F


12 - Introduction The Culture of Enterprise Transformation

PR

Why Should I attend this Training? The biggest enemy (or ally – but mostly enemy in todays world) of Enterprise Transformation is Culture. Do not underestimate the power of culture. Do not underestimate the power of culture.

Do not underestimate the power of culture.

OO

Culture trumps Everything™ 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. For any human based system, you can change as many Methods as you like, define as many Artefacts as you like and change the Environment used (including IT) until the cows come home, but like a cork bobbing in the sea, they are utterly insignificant compared to the churning seas of Culture. Even when the sea appears calm there can be dangerous undercurrents and hidden dangers that can sink the unsinkable. All Enterprises have to navigate the icebergs of culture, but many of them do not realise that they can only see 10% of the iceberg. From personal experience: 5% of the time, that equates to Culture Enables Everything™ 95% of the time, that equates to Culture Screws Up Everything™

Who should attend? 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.

F


Introduction - 13 Licensing

OO

PR Non-Commercial (Internal)

If you wish to use any of Pragmatic’s Ontologies, Frameworks or materials (in whole or in part) internally (e.g. Individual Consultants, End-User Enterprises, Government Bodies, Academic Institutions, etc) then the Enterprise that uses them, and the people that use them, must possess a Non-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 considered to be Individual Consultants and therefore only require a NonCommercial 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:

F

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


14 - Introduction Commercial (External)

PR

If you wish to use any of Pragmatic’s Ontologies, Frameworks or materials (in whole or in part) externally (e.g. Consultancies, Training Providers and Tool Vendors) to improve your clients Enterprises, 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 considered to be Individual Consultants 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:

OO

Any use must be attributable to Pragmatic EA. Details of the license issued will be posted on the Pragmatic EA website. 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.PragmaticEA.com Licensees agree to be contacted by Pragmatic EA 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 EA and obtaining explicit written consent.

For Fees and to apply for a license, please see http://www.pragmaticea.com/licensingcommercial.asp

F


Introduction - 15 Language I Didn’t Me an Wh at You He ard!

OO

PR 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 is worse when apparently possible because people don’t realise they misunderstand each other.) 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.

F


16 - Introduction

PR

Many words people use are overloaded with multiple meanings and when this is not clear (i.e. most of the time!) communication can become quite confusing, not to say heated. Sometimes we need to use different language to explain a difficult concept. This is an explanation of the off-side rule in football (soccer to those of you from across the pond there’s that language problem again!) to someone who is well versed in the process of buying shoes…

OO

“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. Both of you have forgotten your wallets. It would be rude to push in front of the first person 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 plain wrong for you to be in front of the other shopper and you would be OFFSIDE!” - Anonymous

F


Introduction - 17 So if English can be confusing to people who speak it, imagine the problems in the multinational world we live in without boundaries (no pun intended, but I’ll take the credit anyway!) as we can see in this explanation of Cricket…

PR

“You have two sides, one out in the field and one in. Each man that's in the side that's in goes out, and when he's out he comes in and the next man 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 men still in and not out. When a man goes out to go in, the men who are out try to get him out, and when he is out he goes in and the next man in goes out and goes in. There are two men called umpires who stay out all the time and they decide when the men who are in are out. When both sides have been in and all the men have been out, and both sides have been out twice after all the men have been in, including those who are not out, that is the end of the game.” - Anonymous

OO

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?

F


18 - Introduction What i s a System?

OO

PR When we use the word “System” we use it to refer to anything. Literally any Thing. Physical things like a car, a boat, a molecule, a planet, etc. Things that are not physical such as processes, thoughts, computer programs, etc. Things which are a mixture of the two, e.g. an Enterprise or part of an Enterprise.

F

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 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. Its title is “Systems and Software Engineering”, its scope is “Architecture description”, and there are numerous and constant references to and examples of IT Systems. Despite this, 95% of it applies equally to Systems in any domain. It is just unfortunate that it is so IT focussed and disastrous that 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.


Introduction - 19 People who are responsible for a system (e.g. management) tend to make two invalid and deeply damaging assumptions:

PR

1) They assume that the system they have put in place will not be abused (they may or may not have thought about how the system will be abused and have put in place things to stop that abuse) instead accepting that even with all the measures they have put in place that the system will still be abused. 2) 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 instead of realising that they are increasing complexity and as complexity rises so does the opportunity for abuse, instead of looking more at the fundamentals and reducing the 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. I suspect the function is definitely not linear and more likely of a polynomial nature. 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 that the opportunity to abuse a system is always greater than the opportunities we have removed.

OO 4

6

2

6

15

9

15

105

90

105

5460

5355

5460

14903070

14897610

14903070

1.11051E+14

1.11051E+14

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?

F

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?


20 - Introduction What i s an Enterp rise?

OO

PR 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”.

F


Introduction - 21

PR

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 the first act is to de-scope the entire Enterprise to something smaller - and restrict work to a “business directive” 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. What do you interpret the word Enterprise to mean? What do others in your Enterprise interpret it to mean? Is there a common understanding? If not, shouldn’t there be one?

OO F


22 - Introduction Ontologies Enterprise Par adigm Shift

OO

PR Plate A This illustrates the Normal view of how many view an Enterprise.

Business People who work in “The Business” see their domain as the most important, and “IT” as a separate entity which supports “The Business” and is often shown/thought of as underneath “The Business” and therefore viewed as, in some way, subservient. Yes, IT only exists to support “The Business”, but in the 21st Century this Business myopic view is flawed as IT is an integral part of “The Business”. IT People who work in IT see their domain as the most important, and “The Business” as everything else that is not IT. Yes, IT is a major part of “The Business”, but in the 21st Century this IT myopic view is flawed as “The Business” is an integral part of IT.

F

Plate B This illustrates the Pragmatic view of how People (especially those that Direct Enterprises) should view their Enterprise. This new way of looking at the fundamental structure of an Enterprise is a Paradigm shift. Instead of looking at the Enterprise from the point of view of its major parts, we look at the enterprise from the point of view of wholes that are made up of parts. What is of strategic importance are these wholes, the end-to-end effectiveness, efficiency, agility and sustainability of these wholes - Direction, Operation, Transformation and Support. A little history (Yes, there will be exceptions to what is detailed below, but we are talking of the general pattern of what happened over time)….


Introduction - 23

OO

PR

In the beginning IT did not exist and therefore was not represented in Enterprises at all, but eventually IT came into being and Enterprises started to see the value in using it. Over time, as IT grew, it logically got to a point where the Enterprise required an IT department to handle it, and hence IT departments were born. These IT departments were essentially bolted onto the side of whatever currently existed in the Enterprise. At first no one on the board knew what to do with this growing IT department or who should oversee it, and so the IT department was often placed under other “support” areas such as HR or Finance. As the IT department (and IT complexity) grew, it became clear that the HR or Finance Director did not have the knowledge to manage it effectively and hence the birth of the IT Director / CTO / CIO type roles. Initially, although “on the Board”, the people appointed to these roles were often not seen as “proper” Directors most of the time, and instead were tolerated, more as a necessary evil. As time moved on, and with the ever increasing use (and complexity) of IT, these roles gained prominence and understanding, and were made and accepted to be proper board level positions. However, these IT departments are still largely a chunk bolted onto the side of the Enterprise - as they were when IT first came to be used. This is the generally state of play today. So, we are not saying that Enterprises were wrong to think and organise themselves as in plate A. That was a reasonable way of thinking and organising themselves in the past. In fact it was the rational, reasonable and logical way of thinking and organising themselves. But we have moved from a world where IT didn’t exist and was optional, to a world where IT is pervasive and mandatory. So, this is no longer an IT thing, this is a Transformation thing… We need a paradigm shift from thinking in terms of “The Business” and IT, to thinking in terms of Direction, Operation, Transformation and Support.

F


24 - Introduction DOTS

OO

PR 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

F

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.


Introduction - 25 from the rest of the Enterprise and from customers and suppliers outside the Enterprise.

OO

PR

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. 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 an Enterprise? Do you think DOTS is a useful structure for designing an 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?

F


26 - Introduction Board Structure

OO

PR Here we suggest the Executive Structure required for an Enterprise based on DOTS. The three fundamental parts of IT are split up and put under the direction of an appropriate CxO. IT Operations goes under the control of the COO, IT Support goes under the control of the CSO and IT Change goes under the control of the CXO. The CTO role would still exist but only have a dotted line to orchestrate the different parts of IT, in the same way, that the COO has a dotted line to orchestrate the parts of the business. It is not anticipated than an Enterprise would implement this, as-is. It is provided more as a suggestion to how an Enterprise may begin to organise itself differently in response to the strategic drivers of the 21st Century, namely Transformation and Support. Bearing in mind the premise that the Pragmatic Operating model for Enterprise Transformation (POET) is based on: “How an Enterprise effects Transformation is becoming a Strategic Strength or a Strategic Weakness, where massive business opportunities can be gained or massive business problems will result.� - POET

F

It is critical that someone is accountable for Transformation at board level. A Chief Transformation Officer.


Introduction - 27

PR

It is unfortunate that the CTO acronym is already taken and so we use CXO (as distinct from CxO (which means any Chief Officer). Note that the CXO role is distinct from the Ordinary Transformation Officer (OXO) role which is largely concerned with Stock! While whatever the role is ultimately called is largely unimportant (Chief Change Officer, Chief Strategy Officer, etc) what is important is that the role exists with an appropriate focus. Just as there is a COO (because the Operation part of the Enterprise is critical to its success), in the 21st century the same is true for the CXO. There needs to be someone, at board/CxO level who is accountable for this strategically important part of the Enterprise, and to bang the boardroom table for resources to improve it. If the CXO role does not exist, who will champion the holistic and coherent increase in maturity of Transformation?

OO

Who might be best placed to move into the CXO role? If you accept that the role is important and mandatory for strategic success then the next obvious question is - who should you employ to do it? Whilst recruitment from outside the Enterprise is a possibility, it is difficult because the role doesn’t really exist yet and therefore there is no pool to choose from. Recruitment to the post from inside the Enterprise is possible from an interim and permanent point of view and from an expediency point of view, may be the most Pragmatic approach. So, if you were to appoint the role to an existing employee, who would that be? You would probably want to choose someone who already spends an appreciable amount of time involved in Enterprise Transformation at a senior level, and since a large part of Transformation happening within Enterprises today is IT related it might seem reasonable to ask the CIO to expand his remit from just dealing with IT Transformation to dealing with Transformation as a whole. To be accountable for the Entire Transformation domain Transforming the Methods, Artefacts, Culture and Environment used for Transformation not just its IT (which is a sub part of the Technology domain, which is a sub part of the Environment domain, which is a sub part of the Enterprise Transformation domain). The other important adjustment is to make this person accountable not only for the running of Transformation but for its improvement. This is a very very important point. Most CIO’s today do not have that remit in their current role (or if they do, are rarely provided with the resources to do so) and therefore the move from CIO to CXO is not only a change from an IT focus to a Transformation focus, but also a change from one that is only accountable for running Transformation to one that also includes its improvement - The Transformation of Transformation. This will require the CXO to relinquish accountability for IT Operations and IT Support to someone else.

F


28 - Introduction

PR

The COO has someone he can call on who is accountable for transforming Operations - the CXO, but the CXO has no one to call on who is accountable for transforming Transformation except himself, and he can only do that if he is given an explicit remit and mandate from the CEO to do so. Do you have a CXO?

Who in your Enterprise will drive the holistic and coherent improvement of how Transformation is effected? Who in your Enterprise will bang the boardroom table to resources to improve how Transformation is effected? Who in your Enterprise would be best placed to move into that role? Are Transformation and Support represented at the CxO level in your Enterprise? If not, does this cause any problems?

What are the impact of these problems? What needs to happen to alleviate these problems?

OO F


Introduction - 29 Framew orks Coverage

OO

PR PF2 consists of a coherent and holistic set of Ontologies and Frameworks designed to help improve the maturity of how Enterprises carry out their business. The relationships between the frameworks are not one of decomposition but are one of inheritance. Therefore to adopt any lower level framework, the ontology that it inherits from must be understood first. Each Framework is designed to be: Pragmatic Provide 80% of the benefits for only 20% of the effort. Well-defined Deal with a well-defined domain. Complete

Be complete in scope with no overlaps and no gaps (not the same as complete in terms of detail. Detail is provided by Frameworks to the right). Connect to and interface with frameworks at the same level.

Inheritable

Each framework inherits and builds on the content and guidance from Frameworks to the left and provides content and guidance to frameworks to the right.

Extensible

Helps Enterprises create their own frameworks (marked with a red X) by inheriting as much or as little as they deem appropriate from whatever level they deem appropriate.

F

Interlocking


30 - Introduction

PR

The Pragmatic Ontology for Enterprise Transformation sets the context for the Transformation part of the Enterprise. It defines Methods, Artefacts, Cultural and Environmental things that apply to all parts of Transformation, that serve to set the context to increase the maturity of its individual parts (Strategising, Roadmapping, Initiation, Elaboration, Construction and Transitioning and Governance). The Pragmatic Enterprise Architecture Framework sets the context for the Strategising and Roadmapping parts of Transformation (Enterprise Architecture). It defines Methods, Artefacts, Cultural and Environmental things that serve to set the context to increase their maturity. PEAF is based on and inherits from POET and therefore POET is a pre-requisite for understanding and adopting PEAF.

OO

The Pragmatic Enterprise Engineering Framework sets the context for the Initiation, Elaboration, Construction and Transitioning parts of Transformation (Enterprise Engineering). It defines Methods, Artefacts, Cultural and Environmental things that serve to set the context to increase their maturity. PEEF is based on and inherits from POET and therefore POET is a pre-requisite for understanding and adopting PEEF. The Pragmatic Ontology for Enterprise Direction sets the context for the Direction part of the Enterprise. It defines Methods, Artefacts, Cultural and Environmental things that apply to all parts of Direction, that serve to set the context to increase the maturity of its individual parts. The Pragmatic Ontology for Enterprise Operation sets the context for the Operations part of the Enterprise. It defines Methods, Artefacts, Cultural and Environmental things that apply to all parts of Operations, that serve to set the context to increase the maturity of its individual parts.

F

The Pragmatic Ontology for Enterprise Support sets the context for the Support part of the Enterprise. It defines Methods, Artefacts, Cultural and Environmental things that apply to all parts of Support, that serve to set the context to increase the maturity of its individual parts.


Context - 31

PR CONTEXT

OO F


32 - Context Context is King™

OO

PR F

Context is King™. It really is! However, as mind-bogglingly important as context is, it is equally mind-bogglingly difficult to talk about. The reason is that when you talk about the context of a “thing” you stop talking about the “thing” itself. This is extremely disconcerting and possibly upsetting for many people. People (including me) like to talk about a “thing” and if someone wants to talk about something else which is not “the thing” then, well, it’s not the “thing” is it - it’s “off topic”. Let’s put that in the “parking lot”. Let’s “take that offline” or “we’re going off at a tangent”. You will find things like that in many books about “How to run an effective meeting” etc but who is to say something is off-topic. Clearly the person saying it does not think it is “off-topic” or he would not have said it! Context is extremely important for the correct understanding of anything, so in this section, we look at the Context of PEAF by understanding what problem it exists to solve, how in general it achieves that and how it relates to other Frameworks and Ontologies with respect to Enterprise Architecture. Every “thing” exists within a context. You, me, this room, a car, a smile, a thought, an Enterprise, a molecule, a planet. What you understand the context of anything to be can massively change your understanding of it and therefore the validity of any decisions you make about it. Sometimes the context can change massively but the implications are small, sometimes the context can change very subtly but the implications can be massive. It is this fact that makes context and our understanding of it far too important to ignore. It is for this reason that all the Frameworks and Ontologies in PF2 start with a section called Context. Context comes into play whenever decisions are made. And decisions are made by everyone, day in day out, week after week, month after month, year after year. It could be said that decisions are the lifeblood of every enterprise.


Context - 33

PR

However, as mind-bogglingly important as context is, it is equally mind-bogglingly difficult to talk about. The reason is that when you talk about the context of a “thing” you stop talking about the “thing” itself. This is extremely disconcerting and possibly upsetting for many people. People (including me) like to talk about a “thing” and if someone wants to talk about something else which is not “the thing” then, well, it’s not the “thing” is it? “It’s off topic.” “We’re going off at a tangent.” “Let’s take that offline.” “Let’s put that in the parking lot.”

You will find things like that in many books about “How to run an effective meeting” etc but who is to say something is off-topic? Clearly the person saying it does not think it is “off-topic” or he would not have said it!

OO F


34 - Context Types

OO

PR Context is made of different types:

Requirements define why a System exists. It’s raison d'être. For example, the purpose of a plant is to reproduce, nothing more. But Requirements can also be complex with multiple purposes that interact in complex ways. For example, the purpose of a concert is to provide entertainment to a group of humans but it is also to make money for the promoters and performers and increase awareness of the performers “brand” while at the same time providing gainful employment to various other people and giving the performers a massive ego boost! Constraints define things which limit or constrain the System in some way. These constraints can be Structural in nature or Transformational. For example, a plant is constrained structurally by the ground it exists within and transformationally by the limitations of photosynthesis. It should also be noted that the context of a System can also be deemed to be a System and therefore that every Context has a Context! Context is comforting; context is good - Have you ever been in a traffic jam - feeling irritated and frustrated. A lot of that comes from not knowing the context for the jam - the WHY. Like queuing at the doctors, it’s not the wait that’s the problem, it’s not knowing how long the wait will be or why you are waiting that is frustrating.

F


Context - 35

PR

Losing sight of context, or not paying attention to it, is akin to losing spatial awareness in the cockpit of an aircraft. Many have crashed because the pilots have become disconnected from their environment. Similarly many have also crashed because the pilots spent so much time concentrating on solving problems with the aircraft they lost sight of the bigger picture. Eastern Air Lines Flight 401 crashed into the Florida Everglades in December 1972 killing 101 people because the entire flight crew (4 people with over 50,000 hours of flying experience and a combined age of 192) became so preoccupied with a burned out landing gear indicator light they didn’t notice that the autopilot had become disconnected, prompting the incredible phrase “Who’s flying the plane?”. There are many other examples. You could also view Context is an inalienable human right and to deny people context is a form of abuse. Are you aware of the things in your context? What are they?

How do you interact with things in your context? How do you the things in your context interact with you? Who is “flying” the aircraft of Enterprise Transformation in your Enterprise? Are they spatially aware?

OO

If not, what would help them to concentrate on the bigger picture?

F


36 - Context Why Use PO ET Sage Words

OO

PR We all spend time looking forward, wanting new things, We think that the solutions to all problems come from thinking of them. But sometimes it’s a good idea to look to the past to see what we can learn. Sometimes we can learn more about our problems, sometimes we can learn more about solutions. These words are very old but perfectly embody both the problem and solution with respect to the Transformation domain of many Enterprises. Sage words indeed. Sage words that are largely being ignored‌.. Do you think that the rate of change on the outside of your Enterprise exceeds the rate of change of your Enterprise today? Next year? In five years time? Do you think your Enterprise is more or less adaptable than your competitors, today? Next year? In five years time? What new thinking is your Enterprise employing today? Next year? In five years time? If you ignore these sage words, what do you think your Enterprise will look like in 5 years?

F

If you ignore these sage words, do you think your Enterprise will still exist in 5 years?


Context - 37 Enterprise Vi ability

OO

PR Please note that the term “The Enterprise” used below, should be taken to mean the Senior Strategic Management of the Enterprise. This generally means the C-Suite, Board of Directors, Partners and Senior Executive Team of the Enterprise in question. These types of Enterprise Viability are not hard and fast rules. Every Enterprise will be different in terms of how it thinks (and in terms of how it acts in reality). They are presented as an aid for Enterprises to determine: How they think and act. How viable their Enterprise may be as time passes. If they need to adjust how they think and how they act to stay viable in the future. Pre 20th century Enterprises didn’t change much. After being created they pretty much stayed as they were. Their viability just depended on what they did. The era of What. During the latter part of the 20th century, what an Enterprise did was not enough anymore to distinguish them. Their viability not only depended on what they did, but how they did it. For example, what distinguished the banks was not what they did (because they all did the same thing), it was how they did, what they did, that distinguished them. Therefore improving what they did became a strategic benefit, and vast amounts of money were poured into Transformation projects. Resources were not really an issue, just being able to change kept them ahead. The era of the Transformation - of Operations.

F


38 - Context

PR

In todays world, the pressure for Enterprises to change is immense and grows day by day. It comes from internal pressures (which are largely under the control of the Enterprise), but it also comes from external pressures (which are largely NOT under the control of the Enterprise) such as changing markets, changing customer segments, legislation, regulation and Business models, not to mention the inexorable advances in IT that seem to only ever accelerate. So, in todays world, just being able to change, is not enough. What distinguishes Enterprises these days is how they change. How effective and efficient they are at doing Transformation. The era of the Transformation - of Transformation. Is executing Transformation in your Enterprise getting more and more complicated? Do you think that how your Enterprise effects Transformation is important? Is the effectiveness and/or efficiency how your Enterprise effects Transformation sufficient? If not, what are you going to do about it?

OO F


Context - 39 Basic Premise

OO

PR “The only constant is change!” has been the battle cry for many years but just being able to deal with change is no longer enough. The new battle cry is “The only constant is the acceleration of change!” How an Enterprise effects Transformation has become a Strategic Strength or a Strategic Weakness, where massive business opportunities can be gained or massive business problems will result. This is the basic premise behind POET. If you do not agree with this basic premise, then you have no need to increase the maturity of your Transformation capability and therefore no need for POET. Not the Transformation of Operations, but the Transformation of Transformation, to better enable the Transformation of Operations. Do you agree with this basic premise? If not, why not?

What are you doing to make sure HOW your Enterprise effects the whole of Transformation is a Strategic Strength rather than a Strategic Weakness?

F


40 - Context WE De ming

OO

PR The philosophical basis for POET is the work of W.E.Deming. But while Deming applied it to the Operations parts of Enterprises (specifically manufacturing), we apply it to the Transformation Enterprise that exists within every Enterprise. 99% of what Deming said about the Operation part of an Enterprise (specifically about manufacturing) applies equally well to the Transformation part of every Enterprise. Here we reproduce the philosophy of Deming but have made some adjustments shown in purple to phrase it in the context of Transformation rather than Operations. It is interesting to note that the exact same problems that Deming faced when trying to explain his thinking to the western world, also exist when trying to explain Enterprise Transformation and the Ontologies and Methodologies for improving it. It should also be noted that it was The Toyota Motor Company that first “got it”, and then subsequently used it to decimate the US manufacturing industry. The same will be true of Enterprise Transformation. Those that “get it” will have a serious business advantage over their competitors. Those that do not will be decimated by those that do. Who is the person in your Enterprise who is Accountable for Transformation? Who will make sure the end to end domain of Transformation is operating in an effective and efficient manner? Do they have a seat at the Board Table? If not, why not?

F

What is their title?


Context - 41 The Transform ation of T ran sform ation

OO

PR F

99% (if not more) of the Transformation work going on in most Enterprises is related to Transforming Operations, while the remaining 1% is spent transforming Direction and/or Support. Since “How an Enterprise effects Transformation is becoming a Strategic Strength or a Strategic Weakness, where massive business opportunities can be gained or massive business problems will result.” there should be someone in the Enterprise who is accountable for this massively important area. In the same way that there is someone accountable for Operations. It is obvious that the person Accountable for the Direction of the entire Enterprise is the CEO. (Note here that we are specifically using the word Accountable here as defined by RACI rather than the word Responsible). It is also obvious that the person Accountable for making sure Operations runs smoothly is the COO. So while the COO flies the flag for Operations in the boardroom - to improve HOW it is done - there should also be someone who flies the flag for Transformation - to improve HOW it is done. But most Enterprises (management) are totally blind to this. It’s a bit like they are looking hard to make sure they do not stand on that thumb tack on the road and complete failing to notice the juggernaut that is about to kill them. Some will look up early and with little energy avoid the juggernaut. Others will see it later and have to expend massive amounts of energy to avoid it. Others will see it too late and be injured. Some will be fatally injured and die a long agonising death. Some will die at the scene. For a few, they will never see it coming and will never know what hit them. POET aims to set the context to allow Enterprises to avoid the juggernaut.


42 - Context

PR

Whilst Transformation tends to mostly transform the Operations part of most Enterprises, POET is concerned with improving the Transformation part of every Enterprise, illustrated here with the red dotted line. This rarely happens on its own, although some parts may be improved in a sporadic, tactical and piecemeal fashion. This approach is in and of itself not a problem. What is a problem, a very very big problem, is when tactical change are made without an understanding as to how those changes fit into the wider context and the implications of those changes on that wider context. Context and Implications. This what the (commonly misinterpreted) phrase “Think Strategically, Act Tactically� means. Not the transformation of Operations, but the transformation of Transformation. How much time and money does your Enterprise spend annually on Transforming Direction? Support? Operations? How much time and money does your Enterprise spend annually on transforming Transformation? Who is the person in your Enterprise who is Accountable for the Transformation of Transformation? Do they have a seat at the Board Table? If not, why not?

OO

Who is Responsible for making sure that the end to end domain of Transformation is operating in an effective and efficient manner?

F


Context - 43 How POET Helps Fundame ntal

OO

PR Do you think a holistic and coherent framework for Enterprise Transformation is beneficial? How much time and money does your Enterprise spend on Transformation? How much time and money does your Enterprise spend on transforming HOW they effect Transformation?

F


44 - Context Where POET and PEAF Fit Theory & Complexity

OO

PR Here we present a method of categorising frameworks and ontologies The vertical axis ranges between the Theoretical and the Detailed, 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 detail 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 Detailed and Complex. It could be said that it is too complex and too detailed to enable easy adoption. It effectively provides Physical guidance. There is a noticeable chasm between them.

F


Context - 45

PR

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

OO

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?

F


46 - Context Zachm an, TOG AF, ITIL, COBIT, PE AF

OO

PR F

Here we show how other frameworks map on to the Transformation cascade (From strategy to Deployment) that POET defines. The Enterprise Context consists of all the things that are not part of The Enterprise (i.e. not directly under its control) but affect or is affected in some way by it. Things like Customers, Suppliers, Partners, Regulators, etc. The thick black line across the diagram marks the delineation between Project Portfolio Planning above and Project Execution below. 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 actually physical things. All models are shown to exist in two fundamental states, Current and Target. There are also, of course, intermediate states but they are not shown to aid readability. In between each phase of transformation, we show the Governance and Lobbying disciplines of POET (using Enterprise Debt™) which, as you will see later, is the key to making the whole coherent, connected and aligned. Zachman® Zachman 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.


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

PR

Vertically although it includes some Roadmapping it is mainly concerned with projects. Horizontally the blue box is shown to not cover the entire width of the Enterprise because TOGAF’s domain is really only IT. It does cover things that are not IT, such as processes and business things, but only where these business things have some relationship or connection to IT. Consequently, there are other things in the Enterprise, that do not use IT, that TOGAF ignores.

ITIL® ITIL in its original form 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. COBIT® COBIT covers four main domains:

OO

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 Initiating, Elaborating, Constructing and Transitioning levels of POET. Monitor, Evaluate, Assess (MEA) maps to the Governance domain/interface between the Roadmapping Initiating, Elaborating, Constructing Transitioning and Using levels of POET. Deliver Service & Support (DSO) maps to the Using domain of the Operation/Support domains of DOTS.

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 Enterprise Debt™ comes in that you will see later. Horizontally - it covers the entire enterprise including but NOT LIMITED to IT. PEEF™ PEEF is an Enterprise Engineering Framework for two reasons:

F

Vertically - it covers the Initiating 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.


48 - Context Do you utilise POET? If not, what do you use for your Enterprise Transformation Operating Model?

PR

Do you utilise Zachman?

Do you know how it maps to the other frameworks you utilise for Transformation? Do you know which parts to use where, when and how? Do you utilise TOGAF?

Do you know how it maps to the other frameworks you utilise for Transformation? Do you know which parts to use where, when and how? Do you utilise ITIL?

Do you know how it maps to the other frameworks you utilise for Transformation? Do you know which parts to use where, when and how? Do you utilise COBIT?

Do you know how it maps to the other frameworks you utilise for Transformation? Do you know which parts to use where, when and how?

OO

Do you utilise PEAF? If not, what do you use for Enterprise Architecture? Do you know how it maps to the other frameworks you utilise for Transformation? Do you know which parts to use where, when and how?

Do you utilise PEEF? If not, what do you use for Enterprise Engineering? Do you know how it maps to the other frameworks you utilise for Transformation? Do you know which parts to use where, when and how?

F


Context - 49 PEAF and the TOGAF AD M

OO

PR Here we show how the POET and PEAF adoption cycle compares to the TOGAF ADM. Essentially POET and PEAF are all about the P (Preliminary) Phase or perhaps the Pragmatic Phase. 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. So, 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. Have you used TOGAF?

What did you do in the Preliminary Phase?

Did you get the mandate and resources required to increase your maturity?

F


50 - Context Level of Guid ance / Detail

OO

PR 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) Zachman provides very low detail and only in the structural parts of the cascade. POET provides more detail, and covers transformation as well as structure. 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 Initiating, Elaborating, Constructing, Transitioning and the Governance of those phases. TOGAF provides much more detail but only in Initiation to Elaboration and the governance of Construction, although it does touch on Roadmapping. COBIT and ITIL provide good detail but only in a narrow focus. 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?

F


Context - 51 Zachm an Basic Mess age

OO

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

F

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.


52 - Context

OO

PR

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 thing 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 mean 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.”

F


Context - 53 Missing Pers pective and Model

OO

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

F


54 - Context Plate B As we move down these perspectives and models this makes sense:

PR

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

OO

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. Do you agree with this interpretation? If not, why not?

If not, how to you reconcile the mismatches?

F


Context - 55 Mappin g t o POET Overall

OO

PR 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 red line illustrates how the content of the Zachman Ontology maps to the content of POET and PEAF. 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, Environment and Culture are covered to a small degree in training although the Ontology itself does not. Do you agree? If not, why not?

F

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?


56 - Context Architect/Engineer

OO

PR 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 Initiating 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 Initiating 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. Do you agree? If not, why not?

If not, how would you map these things?

F


Context - 57 Why/H ow

OO

PR 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. Do you agree? If not, why not?

If not, how would you map these things?

F


58 - Context How/When/Wh at/Where/Wh o

OO

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

Rows 1 and 2 map to the top two levels of MACE (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 MACE. The What column talks in terms of business entities and therefore maps to the Artefact domain of MACE. The Where column talks in terms of location and therefore maps only to the Location sub-domain of the Environment domain of MACE. The Who talks in terms of people and therefore maps only to the people sub-domain of the Culture domain of MACE. Rows 3, 4 and 5 map directly to the Logical, Physical and Operation levels in MACE, 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 MACE. Do you agree? If not, why not?

F

If not, how would you map these things?


Context - 59 Perspectives and Models

OO

PR 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. Do you agree? If not, why not?

If not, how would you map these things?

F


60 - Context Why Use P EAF Basic Premise

OO

PR “The only constant is change!” has been the battle cry for many years but just being able to deal with change is no longer enough. The new battle cry is “The only constant is the acceleration of change!” How an Enterprise effects Transformation has become a Strategic Strength or a Strategic Weakness, where massive business opportunities can be gained or massive business problems will result. This is the basic premise behind PEAF. If you do not agree with this basic premise, then you have no need to increase the maturity of your EA capability and therefore no need for PEAF. Not the Transformation of Operations, but the Transformation of EA, to better enable the Transformation of Operations. Do you agree with this basic premise? If not, why not?

F

What are you doing to make sure HOW your Enterprise effects does EA is a Strategic Strength rather than a Strategic Weakness?


Context - 61 What Is Ente rprise Architecture? Bridging the Gap

OO

PR Many people believe and espouse that…

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

F

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. My thoughts about EA also had brought me to the conclusion that the only purpose of EA was an enable and support Transformation of the Enterprise. For if the Enterprise never changed, there would be no reason to use EA at all.


62 - Context So, since EA is all about Transformation, and since EA (aka Roadmapping) was the work that was done between strategy formulation on the one hand and projects (the execution of change) on the other it because obvious that a much more valid statement was:

PR

“EA is all about - Bridging the gap between Strategy and Execution� Pragmatic EA Ltd

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 Strategy and Execution is a more helpful way of viewing the world? If not, why not?

OO F


Context - 63 You Decide

OO

PR F

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. Each of these definitions defines something useful and each of these things is defined both in terms of itself and, but more importantly in terms of its context - because as POET teaches us - Context is King™.


64 - Context …set in the context of…

the whole of the Enterprise (including but not limited to IT and not limited to the things currently connected to IT)

the things outside the Enterprise

the IT of the whole of the Enterprise

the things in the Enterprise that are connected to IT and the Business strategy

a very large IT project

the things in the Enterprise that are connected to that IT project and the IT roadmap

PR

X

The Architecture of…

Y

Z

The table below shows which definition PEAF allocates the EA label to, along with the labels it uses to refer to the other important definitions. We also show two alternative camps representing views expressed by others. If you do not agree with PEAF’s allocation of labels, you are completely free to allocate whatever labels you wish. Camp B

OO

Camp A (PEAF)

Camp C

X

The Architecture of… the whole of the Enterprise (including but not limited to IT) …set in the context of… the things outside the Enterprise

EA

?

?

Y

The Architecture of… the IT of the whole of the Enterprise …set in the context of… the things in the Enterprise that are connected to IT and the Business strategy

EITA

EA

?

Z

The Architecture of… a very large IT project …set in the context of… the things in the Enterprise that are connected to that IT project and the IT roadmap

PITA

?

EA

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?

F


Context - 65 EA and S A

OO

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. 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 Methods, Artefacts, Culture and Environment 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. 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?

F

Is there anything in your Enterprise that you need to change?


66 - Context 160 Char Ch allenge The Question

OO

PR F

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.


Context - 67 Raw Wor d Cloud

OO

PR 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. Do you think this word cloud helps or hinders people’s understanding? Are there things you think are missing?

Are there things here that you believe should not be?

F


68 - Context Analysed Answe rs

OO

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

F

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.


Context - 69 WHY All of the WHYs were reviewed and allocated to a structured list of WHYs that was created iteratively by analysing the WHYs.

PR Mission

help achieve the Enterprise’s vision, mission, objectives, strategies, goals 85

Agility

help the Enterprise be able to respond to change and transform itself

57

Efficiency

increase efficiency

56

Costs

reduce costs

36

Effectiveness

increase effectiveness

36

Value

increase and create value

30

Durability

increase durability

27

Growth

increase growth and create opportunity

24

Profitability

increase profitability

23 18

Customers

increase customer satisfaction

17

Risk

reduce risk

15

Stability

increase stability

11

Quality

increase quality

9

OO

Competitiveness increase competitive edge

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.

F

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.


70 - Context HOW All of the HOWs were reviewed and allocated to a structured list of HOWs that was created iteratively by analysing the HOWs.

PR Decision Support

MI, Decision Making, Understanding, Clarity

118

Strategic Planning

Strategic Planning. Transformation, Change, Evolution, Roadmapping, Steering

92

Architecting

Analysis, Architecting, Engineering

71

Governance

Guidance, Governance, Steering, Control, Communication

61

Alignment

Aligning all of the Enterprise’s parts with each other

61

OO

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.

F


Context - 71 WHAT All of the WHATs were reviewed and allocated to a structured list of WHATs that was created iteratively by analysing the WHATs.

PR Models

Structural Models, Blueprints

Processes Practices, Processes, Disciplines, Frameworks

140 70

Guidance

Principles, Policies, Standards, Guidelines, Metrics 27

Tools

Tools

15

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.

OO

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.

F


72 - Context Analysed Word Cloud

OO

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

F


Context - 73 Description

OO

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. Do you agree with it? If not why?

What would you add? Take away? Change?

F


74 - Context Simplified Description

OO

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!

F

Do you agree with it? If not why?

What would you add? Take away? Change?


Context - 75 How PE AF Helps Fundame ntal

OO

PR Do you think a holistic and coherent framework for Enterprise Architecture is beneficial? How much time and money does your Enterprise spend on Strategising and Roadmapping? How much time and money does your Enterprise spend on transforming HOW it executes Strategising and Roadmapping?

F


76 - Context Where t o Start? Can I start with one Department?

OO

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?” The short answer is - No! The long answer is - It depends! 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 think about the verb - “doing” Enterprise Architecture (primarily Roadmapping) we begin to understand that the domain we choose to “do” EA on, is not determined by selecting an arbitrary part of the Enterprise like a Business Unit, but upon what needs to be Transformed and why, which is driven by the Enterprise Strategy (or more specifically, the part of the Enterprise Strategy that the Enterprise cannot satisfy, or only partially satisfy, in its current structural state.

F


Context - 77

PR

So, the structure of what is in scope in terms of EA is not defined by a Business Unit or a Department per se, but by the parts of the Enterprise that the people involved in Roadmapping deem requires Transformation. Hence “doing” EA is already descoped to comprise only the parts of the Enterprise that currently need to change in response to the current Enterprise Strategy. Having now understood this view, if we consider again the initial questions regarding “starting small” and “reducing the scope”, it is clear that we are now referring to reducing the scope of work undertaken by the people involved in Roadmapping. If we wished to do this, we are in effect saying we would utilise EA tools and techniques for doing some of the roadmapping work and not use them for the remaining roadmapping work. This does not make much sense. So, the “scope” of EA (at any point in time) is determined by the Enterprise Strategy (at that point in time) not on a Department or Business Unit level. However, there are two slight (but very important) exceptions to this rule. The first is when an Enterprise has more than one Roadmapping group. For example if a very large Enterprise is composed of some large parts and these large parts each have their own Roadmapping groups, then you could reduce the scope of EA to one of those groups. Not because they are a separate group, but because they have a separate Roadmapping group.

OO

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 involved in Roadmapping? Does your Enterprise have more than one Roadmapping Group?

The second is when there is an EA Catalyst…

F


78 - Context EA Cat alysts

OO

PR This is not a list of the things that EA can be useful for per se, as EA is useful at all levels throughout the Enterprise and at all times. This is a list of some catalysts that can cause people to begin to think about adopting EA. All these things have one thing in common. Enterprise Transformation. Not only that…. Large Transformation. Fundamental Transformation. Strategic Transformation. Enterprises begin to look at EA because of a simple truth - you cannot change what you cannot understand and you cannot understand what you cannot see. To figure out what to change and in what way, the Enterprise (or rather the “Project”) is forced to embark upon modelling things. This is a large part of EA but the problem is, most Enterprises embark on this process only from the perspective of that particular “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. If you cannot invest in an increase in EA Maturity at these times, you probably never will. Have any of these catalysts existed in your Enterprise?

F

Was the opportunity to adopt EA properly taken up?

If not, why not? What needs to change so next time it will be?


Context - 79 The First Step is Always the Hardest

OO

PR One of the hardest aspects of anything, including Enterprise Architecture, is where to start. Like with any journey, the most important thing to know is why you wish to embark on the journey. Its purpose. Whilst this is true of the Enterprise journey, it is also true of the Enterprise Architecture journey. The place to start is therefore with an understanding and acceptance of the purpose of Enterprise Architecture, the problems it helps to solve, and how it proposes to do so. Unless this understanding and acceptance of its implications is achieved progress will be impossible. Like an alcoholic admitting they are an alcoholic is the most important (first) step to helping them, the same is true of Enterprise Architecture. Unless the Enterprise admits there is a problem, they cannot be helped and in fact will probably actively derail any attempt to do so. Bon voyage!

F


80 - Context Vision

OO

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 support an 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. The Goal of Enterprise Architecture - to Increase the Effectiveness, Efficiency, Agility and Durability of Enterprise Transformation - defines the purpose of Enterprise Architecture and therefore EA’s whole existence relies on this Goal to be specified in the Enterprise Strategy. If it is not, the second thing to do is to get the Strategy creators to either explicitly add it, or explicitly state that it is not a Goal. 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.

F

Do these Goals exist in your Enterprise Strategy?


Context - 81 Goals

OO

PR The rationale for increasing one’s maturity in Enterprise Architecture (Methods, Artefacts, Culture and Environment) come 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.

F

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.


82 - Context

PR

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

Question

Answer

Defensive

How fast do I have to run in order not to be eaten by a Tiger?

Slightly faster than the slowest of your competitors.

Offensive

How fast do I have to run in order to be a winner?

Slightly faster than the fastest of your competitors.

The Past

The World Today

OO

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.

F


Context - 83

PR

Agility This goal is concerned with how fast the Enterprise can transform itself to adapt to internal and external pressures and priorities. The table below illustrates the differences in the drivers of change from the past and the world today. The Past

The World Today

Changes in Legislation

Happened rarely

Year on year

Competitor’s strategic moves

Happened rarely

Weekly.

The possibility of mergers and acquisitions

Happened rarely

Monthly

Introduction of new products and services

Happened rarely

Daily

The wax and wane of suppliers

Happened rarely

Monthly

The creation and demise of market and customer segments

Happened rarely

Bi-annually

The creation and demise of market and customer Channels

Happened rarely

Bi-annually

Changes in scale

Happened rarely

By the minute

The introduction of new machines (and technologies)

Happened rarely

Monthly

OO

Driver

F


84 - Context Comparing the past with the world today…

The World Today

Enterprises today 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 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’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.

OO

PR The Past

Agility was not really important at all because things didn’t change very 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.

This importance continues to grow year on year. Durability This goal is actually a component/modifier of the other three goals. 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 time component is built into the Enterprise’s Goals, the Enterprise will be solely driven by the needs of now above the needs of tomorrow. The Enterprise will be effectively (and efficiently!) selling tomorrow to live today.

F


Context - 85 Strategies

OO

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

F

Reducing the risks associated with Transformation is important to the Enterprise but 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.


86 - Context Manage Flexibility

PR

Increasing the flexibility of Transformation is important to the Enterprise but not to the exclusion of its other strategies. 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


Context - 87 Tactics

OO

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: A flexible Modelling Tool An extensible Meta-model Methods for managing the models.

F

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.


88 - Context

PR

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

OO

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 Enterprise 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 Enterprise Debt™ Expose and manage Enterprise Debt™ created when short term tactical choices compromise long term strategic intent by: Recording Enterprise Debt™ as it is created. 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.

F


Context - 89 Objectives

OO

PR Our objective, to increase EA maturity, is achieved by adopting an EA Framework which is effected by using the three phases of EMMA - Evaluate, Analyse, Modify. Each iteration of Evaluate, Analyse and Modify 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: Evaluate Determining if there is any appetite to increase EA Maturity. Analyse

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

Developing and then making the necessary changes and adjustments to the Enterprise identified in the Analysis phase, in preparation for it to be able to utilise Enterprise Architecture.

F

These three phases are achieved by utilising the PEAF Maturity Model, which is the Adoption section of PEAF.


OO

PR

F


Methods - 91

PR METHO DS

OO F


92 - Methods Overview Phases Models

OO

PR Structural Here we see how the Structural Artefacts (as defined by MACE) exist in a holistic and coherent cascade from Strategic intent at the top, down to deployed change at the bottom. For each phase (or ellipse) - the same basic pattern of work is being carried out: The structural constraints flow from the phase above. The structural output is to the right. This output is 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. You will notice that the some of the boxes are only showing slivers - this illustrates the fact that work at these levels is constrained by the domain of each project and therefore only deals with part of the Enterprise’s Architecture and Engineering Models at a time rather than the whole.

F


Methods - 93

PR

Transformational We also see how the Transformational Artefacts (as defined by MAGMA) exist in a holistic and coherent cascade from Strategic intent at the top, down to deployed change at the bottom. 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.

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

OO

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?

F


94 - Methods Example Roles an d RACI P atterns

OO

PR This view shows how the various roles of Transformation map to the different phases of Transformation and in what way. These are not hard and fast divisions of labour but illustrate how the same pattern is repeated at each level, thus enabling the whole to work together. RACI is used here; Responsible, Accountable, Consulted and Informed. There are two patterns here that make the whole cohesive. Role Pattern - If we consider roles, each role is Responsible for one level. That role is also, by definition, Accountable for the level below. That does not mean that one person cannot work at more than one level, in that respect that person is performing two roles but can only wear one hat at a time. Phase Pattern - If we consider phases, there is someone (or more than one) person at each level Responsible for doing the work in that level. In order to do their work they must Consult people from the level immediately above and below and Inform people two levels above and below. Do you think that this basic pattern can help to keep the whole aligned and connected and why?

F

Does your Enterprise have a pattern of Accountability and Responsibility 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 Enterprise defines along with their RACI mappings?


Methods - 95 Road mapping Ph ase Process Intermediate Jou rney

OO

PR Why 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. “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.

F


96 - Methods Create/upd ate Inter mediate Models

OO

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

F


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

PR

Provision: QA: Modelling: Update:

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

OO F


98 - Methods Create/upd ate P ortf olio Model

OO

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 - 99 Who Strategic Planning Team. The Board & Senior Management. Anyone trained in the tool being used. Strategic Planning Team.

PR

Provision: QA: Modelling: Update:

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

OO F


100 - Methods Enterprise T rans for mati on Str ategy

OO

PR The definition of the current, target and intermediate states, in addition to the definition of the project portfolio and the resulting business and technical roadmaps constitute the Enterprise Transformation Strategy consisting of integrated Business & IT Transformation Strategies.

F


Artefacts - 101

PR ARTEF ACTS

OO

I

F


102 - Artefacts Ontology Structural & T rans for mati onal

OO

PR Here we see how the three fundamental ontologies from POET are woven together. On the right we show the Structural ontology - MACE. 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. 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?

F

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 - 103 Business Model, Oper ating Model, Capability Model & Roadm aps

OO

PR F

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 defies them in the same way!) Business Model The Business Model corresponds to the contextual level of MAGMA. However, since this information is part of the Direction Domain, the specific ontologies used are defined in POED. Any metamodels actually used are very business dependant (and dependent upon the C-Suite’s experience) but typically utilise things like the Business Motivation Model (BMM), the Business Model Canvas (BMC), the Enterprise Canvas (EC - Tom Graves), V4 BM, etc are used. There is a Current and Target Business Model indicating last year’s Business Model and the one you begin to create for this year. Of course, the Business Model should rarely change, but the Enterprise may decide internally that they want to change it or it may need to change based on a new Enterprise Context (or the understanding of something that was already part of the Enterprise Context but not taken into account). Roadmap Model The Roadmap Model corresponds to the Conceptual level of MAGMA. It fundamentally 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 at different levels of abstraction rather than centred around the levels themselves. People generally talk of Requirements, Plans, Principles etc, Metrics and (hopefully for not generally) the rationale for decisions, which map directly to the Motivation, Actions, Guidance, Metrics and Assessment domains of MAGMA.


104 - Artefacts

OO

PR

Enterprise Context There is no commonly existing name for things that constitute the Enterprise Context but structural information about things outside the Enterprise definitely exist and must be considered. Operating Model The Operating Model corresponds to the Contextual level of MACE. It defines the highest level view of the structure of the Enterprise required to enable the Business Model. There is a Current and Target Operating Model indicating last year’s Operating Model and the one you begin to create for this year. Of course, the Operating Model should rarely change, but the Enterprise may decide internally that they want to change it or it may need to change based on a new Business Model. Capability Model The Capability Model corresponds to the Conceptual level of MACE. It defines the fundamental capabilities required to support and enable/operationalise the Operating Model. Like the other models, there is are current, target and intermediate state models. These different Structural states (and the relationships between them) constitute the Structural Roadmap. Solution Architecture Solution Architecture corresponds to the Logical level of MACE. It defines (for each solution/project) the logical designs. Detailed Design Detailed Design corresponds to the Physical level of MACE. It defines (for each solution/project) the physical designs. Enterprise Strategy, Transformation Strategy. From these basic models, it can be clearly seen how the Enterprise Strategy and Transformation Strategy are composed. The Enterprise Strategy consists of the Business Model and Operating Model set in the context of the Enterprise Context Model. The Transformation Strategy consists of the Roadmap Model and Capability Model, set in the context of the Operating Model. Where does your Enterprise’s Business Model, Operating Model and Roadmaps 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 Model and Operating Model? Do you have the required basic information, in a usable format, to allow your Enterprise to produce the Structural and Transformational Roadmaps?

F


Artefacts - 105 Meta-m odels Hybrid

OO

PR In reality one Metamodel to cover the entire Transformation domain does not exist and so a hybrid approach is needed. Here we see a full hybrid meta-model, constructed by taking the most appropriate things from various meta-models and producing a meta-model with 100% coverage. Horizontally - from a Structural and a Transformational perspective, Vertically - from a Strategy to Deployment perspective. You may be surprised that the part that Pragmatic contributes is so small. However 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. It has, however, made a massive contribution by the introduction of Waivers that allow the exposing and management of Enterprise Debt™ and with the definition of the vessels (Ontology) that all these frameworks co-exist within, most notably MACE and MAGMA. However, a full Pragmatic Metamodel is in production, which will cover all domains and all levels. 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 long would it take to create?

F

How would you implement such a hybrid meta-model?

Are there any tools that can implement and utilse Hybrid Meta-models?


106 - Artefacts Ontology Structural & T rans for mati onal

OO

PR In this section, we look at the Artefacts of PEAF. The artefacts deal with the structures required for Structural and Transformational description. The WHAT. Interestingly it is the thing that most frameworks and ontologies focus on, which when you see the other quite important things like Methods, Culture and Environment might make you wonder how much value they contain. It is understandable however, that people concentrate on Artefacts as they are very “tangible� - 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, Environment and Cultural things are much harder to produce and therefore tend not to be.

F


Artefacts - 107

PR

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 Strategising and Roadmapping phases (as defined in the Methods section) and the associated Governance/Lobbying work down to projects. The structural information is represented at three levels of abstraction: Enterprise Context, Contextual and Conceptual, and in support of these three Structural levels, there are two Transformational levels that support the phases and allow the transformation between the Structural Levels to happen. 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?

OO F


108 - Artefacts Business Model, Oper ating Model, Capability Model & Roadm aps

OO

PR 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. 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?

F


Culture - 109

PR CULTURE

OO F


110 - Culture Architecture & En gineerin g Yin & Yang

OO

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.

F

However The Architecture Paradigm™ also recognises that the approach must integrate with work that is to come later, namely Engineering. An important distinction is that we should aim to Architect horizontally and Engineer vertically. This distinction allows us to explain a fundamental confusion that people have when people are trying to explain or advocate the architecture of something, namely, that just because an Architect is talking about the fundamentals of the whole, it does not mean they are advocating building the whole, immediately. By definition, 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” you should say, “Yes, It is! If it were not high level and big, it wouldn’t be Architecture!”


Culture - 111

OO

PR

Think (and plan) strategically (Architecture), act tactically (Engineering). 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. Because Architecture tends to (should) consider things from a Contextual and/or Conceptual and/Logical perspectives this allows us to consider the whole. 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. 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‌

F


112 - Culture Merge d

OO

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 “Just do it!� - 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.


Culture - 113 Engineering is more of a science.

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

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

Architects tend to think in terms of outside-in.

Engineers tend to think in terms of inside-out.

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

Engineers are aware of whole systems, but tend to focus on the parts.

Architects are more concerned with the Why > What translation with a little of the How.

Engineers are more concerned with the What > How to translation with a little of the Why.

Architects deal in uncertainty.

Engineers deal in certainty.

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 his job is done when there is nothing more to take away.

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

The most important tool for an Architect is his eraser.

The most important tool for an Engineer is his 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.

An Architect doesn’t get what he wants until an Engineer Builds it for him.

An Engineer doesn’t know What to Build until an Architect tells him.

An Architect doesn’t know Why to Architect something until a Client tells him.

An Engineer doesn’t know Why to build something until an Architect tells him.

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

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

You Architect Long Term Wins.

You Engineer Quick Wins.

OO

PR

Architecture is more of an art.

F

You cannot cost justify Architecture.

You can cost justify Engineering.

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

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


114 - Culture

Are you more of an Engineer or an Architect or are you both?

PR

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?

OO F


Culture - 115 Application Inter Ph ase

OO

PR 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. 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?

F


116 - Culture Intra P hase

OO

PR 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! Do people in your Enterprise who work in the Strategising phase think of themselves primarily as Architects or Engineers or a mixture? Do people in your Enterprise who work in the Roadmapping phase think of themselves primarily as Architects or Engineers or a mixture? Do people in your Enterprise who work in the Initiating phase think of themselves primarily as Architects or Engineers or a mixture? Do people in your Enterprise who work in the Elaborating phase think of themselves primarily as Architects or Engineers or a mixture? Do people in your Enterprise who work in the Constructing phase think of themselves primarily as Architects or Engineers or a mixture?

F

Do people in your Enterprise who work in the Transitioning phase think of themselves primarily as Architects or Engineers or a mixture?


Culture - 117 Overall

OO

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. Are the Architecture and Engineering disciplines recognised in your Enterprise?

F

Are they working in harmony or not?

If not, what will you do to increase the harmony?


118 - Culture The Architect Secrets

OO

PR F

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.


Culture - 119 Architects do not necessarily discover new things, more they discover new ways of seeing existing things. Putting things “in a new light”.

PR

“New Light through Old Windows” - Chris Rea

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 ;-)

OO

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?

F


120 - Culture An I mpossible J ob

OO

PR F

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.


Culture - 121

OO

PR

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. 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!”

F


122 - Culture

PR

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. “A wise man gets more use from his enemies than a fool from his friends.” - Baltasar Gracian

OO

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 and thinking, 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.

F


Culture - 123

PR

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

OO

"All fine architectural vales are human values, else not valuable." - 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

F


124 - Culture

PR

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

How do you react when an Architect tells you that 1+1=blue? How do you react when an Architect breaks the rules? 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 doesn't accept and answers and continues to ask more questions?

OO

How do you react when an Architect refuses to be ignored? 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? Where do you think Architects "fit"?

F


Culture - 125 Architect or Ch arl atan

OO

PR How can you tell the difference between an Architect and a Charlatan? DO NOT TURN THE PAGE. YET….

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

F


126 - Culture

OO

PR You can’t!

F


Culture - 127

OO

PR

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. 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. Do you or your Enterprise view Architects as Charlatans, promising snake oil that will cure all ills? Do you or your Enterprise view Architects as people that talk in future promise that cannot really be objectively quantified?

F


128 - Culture The Pr agmatic Architect Creed

OO

PR The Pragmatic Architect Creed is a set of statements and values that an Architect in any domain should possess. It could almost be considered to be the culture of an Architect and consists of three pillars: Integrity

F

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


Culture - 129 Communication

PR

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.

Understanding

OO

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. I can see disagreement between people when those people think they are in agreement 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.

F

You can sign the Pragmatic Creed at www.PragmaticEA.com/creed


130 - Culture Qualities

The following details the personal qualities of Pragmatic Architects.

PR

Rationale

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.

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.

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.

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’s “favourite� things.

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.

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.

Strategic

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

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

OO

Description

F


Culture - 131 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.

Diplomatic

They are sensitive to other people’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 and 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.

Generalist

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.

Altruistic

OO

PR Behaviours

The following details the personal behaviours of Pragmatic Architects. Rationale

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.

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.

F

Description


132 - Culture 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.

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.

Expose

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

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.

OO

PR

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.

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 and to bring people together where there is agreement and to facilitate valued discussed where there are differences.

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.

Do you think people with these Qualities and Behaviours would be beneficial to your Enterprise?

F

If so, in what parts of your Enterprise and in what roles?

Does your Enterprise motivate people to strive for these Qualities and Behaviours or punish them (implicitly or explicitly) for having them?

How are people received, and what happens to people who exhibit these Qualities and Behaviours in your Enterprise?


Culture - 133 Do you evaluate your current employees or new hires using these Qualities and Behaviours

PR

If not, which Qualities and Behaviours do you actively look for? Will you sign the Creed?

OO F


134 - Culture Risks The Brick Wall of Misconception

OO

PR Because the field of Enterprise Architecture is very immature (we cannot call it a profession) and there is no way to know who is and is not a “real” Enterprise Architect, almost anyone can call themselves an Enterprise Architect and begin telling others about it. Negativity around EA is widespread but it is not a surprise. Most people and Enterprises have just enough knowledge to be dangerous! A lot of people have heard of EA. Unfortunately, most of them have only heard parts of the story and from sources of varying quality and completeness. Also those parts of the story may have been heard or told at different points in time. Myths, inaccuracies and untruths abound. With this in mind it’s hardly surprising that a lot of people’s understanding of EA is inaccurate, incomplete, erroneous and inconsistent. Over the years this has caused a massive amount of disinformation to build up and percolate around the business and IT communities which has lead people to have very negative views about what EA is and what it means for their Enterprise. There are many misconceptions associated with bringing Enterprise Architecture to an Enterprise. But more than misconception, they are real risks. Each risk defined, documents the impact and general mitigation strategies to deal with them and they are all fundamentally perception problems.

F


Culture - 135

We don’t have an EA EA is perceived as not existing in an Enterprise and therefore “we don’t need it”

Impact

FAILURE EA is not viewed as a serious issue that management need to address and hence nothing is done to mature it.

PR Description

OO

Every Enterprise already has an EA. The word Architecture just means structure and so an Enterprise Architecture is really just the structure of the Enterprise. Every Enterprise definitely has structure and therefore definitely has an Enterprise Architecture. It may be good or bad. It may be documented or not. It may be understood or not. It may be what is required or not. An Enterprise may not have an Enterprise Architecture model (something documented in some way) but every Enterprise definitely already has an Enterprise Architecture. Every Enterprise already “does” EA. “Doing EA” is a bit of a misnomer. “Doing EA” is actually the work that happens in the Strategising and Roadmapping phases of the Transformation cascade (as defined by POET) including high level project Governance. This work is already happening in every Enterprise. It may be good or bad. It may be documented or not. It may be understood or not. It may be what is required or not but every Enterprise is definitely already “doing” Enterprise Architecture. Every Enterprise already employs EAs. The people who currently work in the Strategising and Roadmapping phases and perform high level project Governance are EA’s. They may not have that title, they may not know what EA is, but they are most definitely EAs. “Having” EA or “doing” EA is therefore not a question of existence or not, it’s more a question of maturity - the effectiveness and efficiency by which those things exist and are done. It’s a question of Maturity.

Reality

Likelihood / Impact

M/H

Mitigation

Communication

F


136 - Culture

We don’t do EA EA is perceived as not existing in an Enterprise and therefore “we don’t need it”

Impact

FAILURE EA is not viewed as a serious issue that management need to address and hence nothing is done to mature it.

Reality

Yes you do - Strategy formulation and high level Transformation Planning is “doing” Enterprise Architecture

PR Description

Likelihood / Impact

M/H

Mitigation

Communication

We don’t have any EAs Description

Reality

OO

Impact

EA is perceived as not existing in an Enterprise and therefore “we don’t need it”

Likelihood / Impact

FAILURE EA is not viewed as a serious issue that management need to address and hence nothing is done to mature it. Yes you do - The Senior Management Team and Transformation planners are the Architects of the Enterprise The question is, are the Methods, Artefacts, Culture and Environment they use, mature enough. M/H

Mitigation

Communication

F


Culture - 137

Ivory tower and hypothetical

Impact

FAILURE Senior management does not engage, meaning EA tries to move forward by driving from the bottom up and is viewed as something to be placated to “just get them off my back so I can do something more useful instead”. The business and IT remain unconnected. Initiatives continue to operate in silos with short term goals.

OO

PR Description

Many people may think that EA is all a bit hypothetical and ivory tower. This is not surprising as there is no shortage of people who will wax lyrical for hours on end about EA. In fact an entire industry has built up that does just this. Seminars are frequent but never seem to offer much Pragmatic advice or things people can actually use. Consultancies will come and talk to you (for a large fee) about EA but getting them to actually deliver something of value, that’s a different story. With all this posturing, style over substance and sound bites, it’s hardly surprising that people can think EA is hypothetical and ivory tower.

Reality

Likelihood / Impact

It is precisely because we don’t live in a perfect world that we need EA. H/H

Mitigation

Communication

F


138 - Culture

Many failures Many people think EA is of little practical value because they have heard (and continue to hear) stories about how people have failed at “doing� EA.

Impact

FAILURE EA is not viewed as a serious issue that management need to address and hence nothing is done to mature it.

Reality

It is true that many attempts at EA fail. This is largely due to EA not being well defined in the first place and then because many people do the wrong things to the wrong things at the wrong time. Bad implementation is the cause for most failures. The baby should not be thrown out with the bathwater.

PR Description

Likelihood / Impact

M/H

Mitigation

Communication

OO

Benefits are never achieved Description

The benefits that EA is supposed to deliver are generally well known and yet most implementations tend not to deliver them.

Impact

FAILURE EA is not viewed as a serious issue that management need to address and hence nothing is done to mature it.

Reality

Likelihood / Impact

Apart from bad implementation another reason is that either no metrics are used or bad metrics are used. How can you know if something is successful if you do not measure it or measure it in the wrong way? M/H

Mitigation

Communication

F


Culture - 139

Invented by consultants

Impact

FAILURE EA is not viewed as a serious issue that management need to address and hence nothing is done to mature it.

Reality

In reality it is largely true that many consultancies view EA as means to more work, however EA existed long before consultants realised they could make a lot of money by exploiting it. Correlation does not mean causality. The key problem there though is a lack of understanding about what EA is actually about and how to actually do it rather than the important people in expensive suits waxing lyrical whilst charging you an arm and a leg. When the Head of Strategy and Architecture thinks that EA is useless we have really big problems. This is why education and exposing Pragmatic information about EA and how to do it in a Pragmatic way is so important.

OO

PR Description

The Head of Strategy and Architecture of a large UK Government department I worked for once said “EA - it’s just something invented by consultants to get them paid more money”. To be honest that view is hardly surprising considering all we have mentioned so far.

Likelihood / Impact

M/H

Mitigation

Communication

A large expensive team? Description

Do I need to employ a large team of highly paid Enterprise Architects and have a whole new set of processes, job titles and departments? FAILURE Funding is not provided.

Reality

No. EA is a cultural shift. Adopting EA is to increase an Enterprise’s maturity in its use of The Architecture Paradigm™ to support Strategy Development (Strategising), Transformation Planning (Roadmapping) and Project Governance. EA is therefore an adjustment to the way people do work they are currently doing, not bolting on a whole new chunk. There are some people/groups that would love you to “employ a large team of highly paid Enterprise Architects”.

Likelihood / Impact

M/H

F

Impact

Mitigation

Communication


140 - Culture

A large expensive project? If I do utilise EA in my business, do I need to have a big EA project spanning years and costing millions of dollars?

PR Description Impact

FAILURE Funding is not provided.

Reality

No. It’s about maturity. Adopting EA is to increase an Enterprise’s maturity in its use of The Architecture Paradigm™ at the scope of the Enterprise to support Strategy Development and Transformation Planning. One step at a time. An EA project is one step and can be a large or as small as you like and is driven by understanding how mature you are, how mature you want to be, what the benefits are of moving to that level of maturity and then making the necessary adjustments. EA is a journey not a destination.

OO

Likelihood / Impact

M/H

Mitigation

Communication

Losing Strategic Control Description Impact

Reality

FAILURE .

No. The business will. EA provides the context and visibility for the business to make even better business decisions. Enterprise Architecture and Enterprise Architects are much more about exposing pertinent information for decisions to be made. Of course, if the Enterprise wishes to delegate some decision making powers to an Enterprise Architect to carry out on their behalf that’s perfectly fine, but those decisions are made on behalf of the Business Management. M/H

Mitigation

F

Likelihood / Impact

If I do utilise EA in my business, will Enterprise Architects be making strategic decisions?

Communication


Culture - 141

It’s another silver bullet EA is perceived as a perfect fix for all of an Enterprise’s problems, with little or no work or cost.

Impact

FAILURE Other associated and related activities are overlooked and stagnate while the Nirvana that EA is supposed to provide, but will not, is created.

Reality

EA is one tool in toolbox that an Enterprise uses to run efficiently. It is linked to and cooperates with other processes in the Enterprise.

PR Description

Likelihood / Impact

M/H

Mitigation

Communication

Nothing to do with me, mate! Description

EA is perceived as an IT or technology level thing.

OO

Impact

FAILURE The Business does not engage with IT. The board does not see EA as something that it should discuss. It’s for the IT Director to do if he wants. IT builds models and diagrams for its own purposes but does not connect them to the business level adequately thereby propagating the myth. EA is placed under the control of the IT Director or CIO. It loses visibility at the board level and descends into being seen as a cost rather than an asset.

Reality

EA is a tool to expose the relationships between the Business and IT. It is ultimately a business tool to enable the board and senior management to see and therefore understand the components of the Enterprise and the relationships between them.

Likelihood / Impact

H/H

Mitigation

Communication

F


142 - Culture

How much!!! EA is perceived as large, costly and slow. EA is perceived as a huge Initiative to immediately move the Enterprise from Current to Target with associated huge costs and timescales.

Impact

FAILURE Similar to large EAI Initiatives in the past large sums of money are spent and time invested until the bubble bursts and someone asks “what are we getting for all this money we are spending�.

Reality

The initial setup of EA should take no longer than 6 months so long as it is driven in the right way. The planning part of EA (as an integral part of the annual business planning cycle) should take no longer than 3 months. The initiatives that come out of the business planning exercise do not try to solve all problems in the first year. There is always a mixture of strategic, tactical, and temporary work in any initiative.

PR Description

OO

Likelihood / Impact

M/M

Mitigation

Communication

Are we there yet? Description

EA is perceived as a destination rather than a journey, and/or as a deliverable rather than a process with deliverables.

Impact

FAILURE Once the principles and models are done they slowly get more and more out of date leading to distrust of them and finally resulting in Shelfware and just another set of diagrams and lists we never use.

Reality

Likelihood / Impact

The setup phase of EA is a destination but that is only to provide the environment to be able to perform the repetitive processes of governance and business planning. M/H

Mitigation

Communication

F


Culture - 143

I have important firefighting to do...

Impact

FAILURE EA never gets a look in with senior management as they are solely concentrating today’s, this week’s, or this month’s crisis.

Reality

EA never says yes or no. It provides the environment for senior management to see and understand the implications and effects of their decisions BEFORE they make them. EA does not preclude short term, tactical or even “throwaway” work. Having EA means that however much tactical or “throwaway” work needs to be done, it is done in the context of a wider and more strategic context.

PR Description

EA is perceived as a roadblock to more important and immediate problems such as “getting the car out of the river”. EA is perceived as purely long term & strategic and not capable of adding value in a tactical world.

H/H

Mitigation

Communication

OO

Likelihood / Impact

F


144 - Culture

Oh what pretty pictures EA is perceived as creating static “pretty” pictures that hang on people’s walls but not used by anyone.

Impact

FAILURE “Pictures” or models, have some value to certain people but they are mostly viewed as things to point at when saying “we have an architecture” rather than living things which aid understanding and decision making.

Reality

Models are powerful things that convey understanding and therefore then provide the basis for understanding the impacts of change). Whilst sometimes it is more beneficial to deal with lists and spreadsheets there are times where pictures show problems and inconsistencies much more clearly. EA allows access to dynamic Models. Communication EA models should be online and navigable. EA models should consist of different and appropriate views and viewpoints targeted at specific audiences. EA Models should be actively used in business planning and projects to assess impact & risk and perform what-if analyses.

OO

PR Description

Likelihood / Impact

H/H

Mitigation

F


Culture - 145

I can’t afford a modelling tool! EA modelling tools are perceived as expensive and “nice to have” but not mandatory.

Impact

FAILURE Pictures and discrete spreadsheets are mostly produced in silos with little reuse value, with a huge information gaps and with the most important relationships missing. These pictures are, or soon become, out of date as the pictures and spreadsheets are not maintained,

Reality

Compared to the cost of paying people to manually maintain the linkages between pictures and spreadsheets, the cost of a tool is very small. Some things are not possible without a tool, e.g. managing relationships, building different views, Version control, security. federation of maintenance rights., etc.

PR Description

H/H

Mitigation

OO

Likelihood / Impact

Communication Evaluate and source a tool Expend the necessary time to understand, configure and use the tool

F


146 - Culture

I don’t want another maintenance nightmare EA models are perceived as being owned and updated by IT.

PR

Description

Impact

FAILURE IT does not have the bandwidth to maintain all of the information and therefore parts of the model become out of date, unconnected and subsequently unused.

Reality

Maintenance of the information within an EA model repository is performed by those most suitable and able to maintain it. E.g. IT people maintain application, Database and hardware information, Business people maintain objectives, products and business activities information.

Likelihood / Impact

H/H

Mitigation

OO

Communication EA Models are owned by the stakeholders/users of the views. The different entities and relationships are owned and maintained as part of existing business and IT processes by the people most appropriate for that entity/relationship

How many paperclips? Description

EA is perceived as producing Models with huge amounts of detail and will descend into analysis paralysis.

Impact

FAILURE The high level strategic view is lost. A huge amount of work is done for little benefit to the stakeholders

Reality

M/M

Mitigation

Communication Stay at the right level of granularity

F

Likelihood / Impact

EA is all primarily about breadth rather than depth (although deep dives may be necessary occasionally). EA is interested in the entire breadth of an Enterprise but only as much depth as required for the strategic planning and governance of initiatives.


Culture - 147

You can’t define the future EA is perceived as not being able to define a Future state because no one knows what that is and it’s always changing anyway.

Impact

FAILURE The long term direction is not known and therefore work operates in a “today” silo timeframe resulting in people not even knowing if the decisions they are taking are good or bad in the long term.

Reality

All Enterprises have some idea of a future state, The fact that their view may not be complete and is probably prone to change does not detract away from this long term general vision, and it is this vision that guides the ship.

PR Description

Likelihood / Impact

H/H

Mitigation

Communication Make sure the “Target” Model is defined at the correct level of granularity and well understood by the Business and IT

OO

Don’t tell the business what to do Description

The perception is that IT is dictating to the Business.

Impact

FAILURE IT tells the Business how wrong it is, how stupid it has been in the past and how IT knows what to do to solve all their problems. The business stops listening to IT.

Reality

EA is all about the Business and IT working in a true partnership, where each understands the other enough to be able to co-operatively work together to achieve shared goals.

Likelihood / Impact

M/M

Mitigation

Communication.

F


148 - Culture

Don’t tell IT what to do The perception is that the Business is dictating to IT.

PR

Description

Impact

FAILURE The business dictates how, when and with what IT will do its job. Requirements are thrown over the wall like incendiaries. IT stops listening to the Business.

Reality

EA is all about the Business and IT working in a true partnership, where each understands the other enough to be able to co-operatively work together to achieve shared goals.

Likelihood / Impact

M/M

Mitigation

Communication.

Let’s model everything

Feverish modelling of various things without a plan for how to gather the data, how to QA it, and who will benefit from it once it is gathered.

Impact

FAILURE A large amount of work is done gathering data and producing diagrams for little or no benefit. Models are not connected to the sources of the information and so people continue to use the diagrams and spreadsheets they always have used or they start creating new one duplicating effort.

Reality

OO

Description

Likelihood / Impact

EA is all about being of value to the Enterprise. Models should not be created without a firm idea of who will use the information, in what way, and for what benefit.

H/H

Mitigation

Communication. Clearly Define the Version 0.1 Meta-model Clearly define the benefits to what stakeholders the model will bring

F


Culture - 149

Shhh! Don’t mention the words EA EA is driven in a largely covert manner, It is only known of within IT and even then only to a very select few.

Impact

FAILURE EA is only used for managing IT and usually largely from an infrastructure point of view. The business and IT remain largely unconnected.

Reality

EA is all about connecting things. EA is a cultural shift and therefore needs to be communicated, understood and bought into by the entire Enterprise.

PR Description

Likelihood / Impact

H/H

Mitigation

Communication.

My bonus is based on todays shareprice

OO

Description

Executive incentives reward short term investments and reduced acquisition costs.

Impact

FAILURE These incentives are in direct conflict with the stated vision, objectives and principles that EA aims to achieve.

Reality

EA is all about investment for future benefit. Executives should be incentivized to produce long terms benefit. Executives should be de-incentivized from producing short term benefits at the expense of long term strategic goals.

Likelihood / Impact

H/H

Mitigation

Communication. Change the Executive incentive scheme. Reward strategic and long term thinking

F


150 - Culture Many Pe ople will H ate E A

OO

PR Many of the things that EA aims to do will not be readily received by many people. This is because adopting EA is a paradigm shift. One could say that if there were no resistance then either you are not doing your job properly or the Enterprise is already mature enough in its use of EA. This is because the paradigm shift involves changing the culture of the Enterprise and therefore how people are motivated. There are no bad people, only bad contexts (Culture) and if we want to change people’s behaviour we need to concentrate on changing the context rather than trying to change the people. People may not like EA exposing problems or mistakes because the Enterprises culture punishes those that do. People may not like EA breaking down silos and fiefdoms because the Enterprise’s culture tends to motivate them financially and with promotions to build them. People may not like to think about the benefit to the whole Enterprise because the Enterprise’s management measures them only on their small part of it. Who in your Enterprise will hate EA?

What do you need to do to stop them hating EA?

F


Culture - 151 Enterprise Architect Two Types

OO

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 Methods, Artefacts, Culture and Environment that they are forced to work within. But I hear you cry: “A good workman never blames his tools” This is a common saying (“tools” = “context”) and does have some validity.

F


152 - Culture However, it is also true to say that if you force a surgeon to:

PR

Save time - by not washing his hands before an operation (Immature Methods), Save money - by using untested blood and medicine (Immature Artefacts). Not care - about the Hippocratic Oath (Immature Culture). Save money - by using carving knife instead of a scalpel (Immature Environment).

OO

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 improving the Methods, Artefacts, Culture and Environment that they are forced to work within. It is not in the Surgeon’s power to increase the maturity of the Methods, Artefacts, Culture and Environment 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:

“A good manager never blames”

F


Culture - 153 Type 1 Requirements

OO

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


154 - Culture Duties

OO

PR 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, Initiating, 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’s Maturity in its use of EA. Hence the phases we refer to here are the phases of the maturation of the EA capability. 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?

F


Culture - 155 Type 2 Requirements

OO

PR 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. Who in your Enterprise currently fulfils this role? Are they called an Enterprise Architect?

F


156 - Culture Duties

OO

PR 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 Initiating 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. 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?

F


Environment - 157

PR ENVIRONM ENT

OO F


158 - Environment The Architecture P ar adigm™

OO

PR The Architecture Paradigm™ exists to help people deal with the Structural Complexity and Transformational Volatility of things. 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.

F


Environment - 159 Purpose It’s Not Wh at Y ou Think

OO

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

F

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?


160 - Environment

PR

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

OO F


Environment - 161 Structural Complexity

OO

PR 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 an 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.

F


162 - Environment

PR

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

OO

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.

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

How would you measure it? Do you care?

F


Environment - 163 Transf or mational V olatility

OO

PR All things have a level of Transformational Volatility. Transformational Volatility merely refers to how often the “thing” 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. Are you aware of your Enterprise’s Transformational Volatility? How would you define it?

How would you measure it? Do you care?

F


164 - Environment Transf or mational C omplexity

OO

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

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.

F


Environment - 165 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™.

PR

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

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

How would you measure it? Do you care?

OO F


166 - Environment Contextual V olatility & Complexity

OO

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

F


Environment - 167 Justification Applicability

OO

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. “You Can’t ‘Cost-Justify’ Architecture”

- John A. Zachman.

F


168 - Environment

PR

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

OO F


Environment - 169 Cost and Ability

OO

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

F


170 - Environment The solid lines indicate the result if we DO USE The Architecture Paradigm™

PR

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 Methods, Artefacts, Culture and Environment used in those domains. 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?

OO F


Environment - 171 Investment

OO

PR These adjustments to the Methods, Artefacts, Culture and Environment 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.

F

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?


172 - Environment Procr astination

OO

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

F


Environment - 173

PR

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 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. 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™?

OO F


OO

PR

F


Appendix - 175

PR APPENDIX

OO F


176 - Appendix Background

OO

PR F


Appendix - 177 Why Were They Created?

OO

PR

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. It doesn’t matter if your currency is the Afghani, Baht, Balboa, Birr, Bolivar, Boliviano, Cedi, Colon, Dalasi, Denar, Dinar, Dirham, Dobra, Dollar, Dong, Dram, Escudo, Euro, Forint, Franc, Francs, Gourde, Guarani, Guilder, Hryvnia, Kina, Kip, Koruna, Krona, Krone, Kuna, Kwacha, Kwanza, Kyat, Lari, Lats, Lek, Lempira, Leone, Leu, Lev, Lilangeni, Lira, Litas, Loti, Manat, Marka, Metical, Naira, Nakfa, Ngultrum, Oro, Ouguiya, Pa'anga, Pataca, Peso, Pound, Pula, Quetzal, Rand, Real, Renminbi, Rial, Riel, Ringgit, Riyal, Ruble, Rufiyaa, Rupee, Rupiah, Shekel, Shilling, Sol, Som, Somoni, Sterling, Sucre, Sum, Taka, Tala, Tenge, Tugrik, Vatu, Won, Yen or 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.

F


178 - Appendix Where Did They Come From? All Pragmatic Ontologies and Frameworks were created from observing failure. That is:

PR

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

OO

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.

F

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.


Appendix - 179 Nothing wrong with Project level IT centric Architecture, but not Enterprise Architecture.

PR

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

OO

“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?” “Hi Kevin, Errrmm, Yeah sure - you need to talk to Steve, he’s the one that did the training.” <time passes….>

“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?” “Hi Kevin, Errrmm, why are you asking me?” “Allen told me you did the training and you would know.” “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….>

F

“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?” “Hi Kevin, Errrmm, why are you asking me?” “Steve told me you did the training and you were the main guy so you would know.” “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….> “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?” “Hi Kevin, Errrmm - why are you asking me?”


180 - Appendix

PR

“James told me you did the training and you’re now the guy in charge of TOGAF adoption.” “Err No! That’s Chris, you need to talk to Chris” <time passes….>

OO

“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?” “Hi Kevin, Errrmm, why are you asking me?” “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” “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.

When Were They Created?

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

F


Appendix - 181

God

Honesty

Integrity

Pragmatism

Altruism

Persistence

Passion

Psychology

Architecture

Engineering

Common Sense

Logic

Auditory

David Bowie, Pet Shop Boys, Dean Martin, Chris Rea.

Location

25 Buttermere, Braintree, Essex, CM77 7UY, UK.

Biological / Chemical

Kevin - Generally all of him, but mostly his brain, eyes and hands. His stomach, colon and bladder put in an appearance occasionally, with his posterior providing a supporting role :-) Murphy the cat.

Mechanical

Desk, Chair, Whiteboard (Pens and Eraser).

Electrical

Challenge Fan Heater, Creative GigaWorks T40 Series II 2.0 PC Speakers

Input

H/W

Dell Latitude E6520 (Intel i7-2760QM @ 2.4GHz, 8GB RAM), 3 * 24in 1920x1200 LED Monitors, HP Officejet Pro X576, Samsung Galaxy Note III.

S/W

MS Windows 7, MS Visio, MS Word, MS Excel, MS PowerPoint, MS VBA, Paint.NET, Faststone Photo Resizer, MozyBackup, PF2

F

Artef acts

Information

Technology

OO

Environment

Methods

PR

Culture

What Was Used to Create Them?

Air, Water, Nespresso, Earl Grey, Toast, Ham Eggs & Chips, Bombay Sapphire, Johnny Walker Black Label, Baileys, Whiskers, Paper, Ink, Blood, Sweat, Tears.


182 - Appendix Output

PF2 Book, POET Book, PEAF Book, PragmaticEA Website

OO

PR F


Appendix - 183 How Were They Created?

PR

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

OO

“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 ;-)”

F


184 - Appendix Who Created Them?

OO

PR

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

F


Appendix - 185

PR

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

OO

My MBTI is INTJ with a hallmark of Vision and categorised as Independent, Individualistic and Visionary. INTJs tend to be independent-minded, theoretical, and original. They have great drive for their own ideas and purposes. They are sceptical, critical, determined, and sometimes stubborn. In areas of expertise, they will develop systems to organize and carry through a project with or without help. INTJs are typically innovators in their fields. They trust their inner vision of how things fit together and relentlessly move their ideas to action. They would rather spend time on what they believe is important than on what’s popular with others. INTJs are independent and individualistic, and others may see them as stubborn at times. They move ahead with or without the support of others, and they have a single-minded concentration. They like using logic to solve complex, challenging problems. Routine, everyday tasks bore them. They analyse and attempt to fit pieces together into a coherent whole. Although INTJs are usually organized and follow through, they may sometimes ignore details that do not fit with their vision of the future. If these details are important, their ideas may not work as well as they would like. INTJs are likely to be most satisfied in a work environment that values their insights and ideas and lets them work independently. People can count on them for their vision and innovative solutions to problems in their field. Some famous INTJ’s:

F

Isaac Newton (Physicist) - "I can calculate the motion of heavenly bodies, but not the madness of people." Karl Marx - (Philosopher) - "Philosophers have hitherto only interpreted the world in various ways; the point is to change it." Augustus (Emperor of Rome) - "I found Rome brick and left it marble." Isaac Asimov (Science fiction writer and science writer) - "Those people who think they know everything are a great annoyance to those of us who do." Martin Luther (Theologian and Protestant reformer) - "I [am] slave to the authority of no one." Nikola Tesla (Inventor) - "My ideas have revolutionized the industries of the United States." Stephen Hawking (Physicist) - "My goal is simple. It is a complete understanding of the universe."


186 - Appendix DISC

OO

PR

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. So putting MBTI and DISC together it says that I am a Result-Oriented Independent Individualistic Visionary. Well that about sums me up to a tee. Sounds very grand, but of course, there are always downsides. I am also an Arrogant, Inflexible, Argumentative, Intolerant, Impatient, Critical & Stubborn, Pessimistic Optimist! 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? What are the MBTI and DISC 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 profile have any bearing as to how they were treated?

F


Appendix - 187 Keypoints

OO

PR F


188 - Appendix

PR

Pragmatic EA is a non-profit research company.

Pragmatic EC is a consulting company.

OO PEAF Foundation training

covers the Operating Model for the whole

Transformation domain. PEAF Certified training

covers the Logical Model

F

for EA.


Appendix - 189

PR

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

Be ever vigilant of the

OO

hidden confusion that language can create.

The word â&#x20AC;&#x153;Systemâ&#x20AC;? does not mean IT System,

F

everything is a System.


190 - Appendix

PR

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

OO

The “Business and IT are so intrinsically linked, a new paradigm is needed.

That paradigm is DOTS.

F


Appendix - 191

PR

Think about structuring

your Enterprise in terms of Direction, Operation,

Transformation and Support (DOTS).

OO Appoint a Chief

Transformation Officer (CXO).

F


192 - Appendix

PR

Pragmatic frameworks are Pragmatic, Well-defined, Complete, Interlocking,

Inheritable and Extensible.

OO

Context is Kingâ&#x201E;˘ because the context can

fundamentally change how

something is viewed and the basis of the decisions that are made about it.

F


Appendix - 193

PR

Remember that Context is

comprised of Requirements and Constraints.

Jack Welch, Darwin and

OO

Einstein do have a point!

It’s not what you do,

it’s the way that you do it. (And that’s what gets

F

results.)


194 - Appendix

PR

How an Enterprise effects

Transformation is becoming a Strategic Strength or a Strategic Weakness.

OO We have seen the enemy, and the enemy is us (Management).

F


Appendix - 195

PR

Spend some time on the Transformation of Transformation,

rather than 100% on the Transformation of Operations.

OO Use POET to take a

coherent and holistic view

of the Transformation part of your Enterprise.

F


196 - Appendix

PR

Use POET and PEAF to

bridge the chasm between Zachman and TOGAF.

POET provides an

OO Operating model for how Zachman, TOGAF, PEAF,

COBIT, ITIL (and all other Transformation

frameworks) relate to each other.

F


Appendix - 197

PR

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

POET provides high level

OO

guidance, PEAF & PEEF

provide a medium level of detail and guidance while TOGAF provide a huge amount of detail.

F


198 - Appendix

PR

You can’t change what you don’t understand, and you

can’t understand what you can’t see.

OO

If using Zachman, be aware that the Deployer

perspective is missing.

F


Appendix - 199

PR

How an Enterprise effects

Transformation is becoming a Strategic Strength or a Strategic Weakness.

Whether you realise it or not!

OO

EA is about bridging the gap between Strategy and Execution

F


200 - Appendix

PR

X Architecture is the

fundamental structure of X, set in its context.

EA and SA are not the same

OO

thing. EA is not just big SA.

F


Appendix - 201

PR

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.

OO F


202 - Appendix

PR

Use PEAF to take a

coherent and holistic view of the Strategising and Roadmapping (EA)

Transformation phases of your Enterprise.

OO F


Appendix - 203

PR

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.

OO Lever large change

initiatives (catalysts) as the perfect opportunity to

increase your EA maturity.

F


204 - Appendix

PR

The most important step is the first.

To startâ&#x20AC;Ś

Increasing your EA maturity

OO must be born from the Strategic Goals of the Enterprise.

F


Appendix - 205

PR

EA Goals:

The purpose of EA is to

improve the Effectiveness, Efficiency, Agility and Durability of

Transformation.

OO EA Strategies:

By Supporting the

Management of the Cost,

Risk, Flexibility and Quality

F

of Transformation.


206 - Appendix

PR

EA Tactics:

Using Structural and

Transformational Models,

Performing EA Governance and Managing Enterprise Debtâ&#x201E;˘.

OO The Objective of using an EA Framework is

to Increase your Maturity in how you utilise the

F

Architecture Paradigmâ&#x201E;˘.


Appendix - 207

PR

Use the Transformation

cascade to link the phases together.

Apply the Role and Phase

OO

patterns when assigning RACI to roles.

EA is not a destination, it is a journey.

F


208 - Appendix

PR

Create intermediate models to satisfy Business and

Technical Objectives from the Enterprise Strategy.

OO Create a project portfolio to effect transformation

between the intermediate models.

F


Appendix - 209

PR

Create the Enterprise

Transformation Strategy by creating interlocking Business and IT

Transformation Strategies.

OO

Map your artefacts to

MACE and MAGMA over the seven layers of

Transformation, to

determine what information

F

is not being captured.


210 - Appendix

PR

Enterprise Strategy consists of the Business model and

Operating model set in the Enterprises Context.

Transformation Strategy

consists of the Roadmap

OO

and Capability models set in the context of the Operating Model.

F


Appendix - 211

PR

Develop a Hybrid

Metamodel for Enterprise Architecture and

Engineering modelling.

OO Enterprise Context,

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

F


212 - Appendix

PR

Enterprise Strategy is

formed from the Current Enterprise Context and Operating Model, the

Target Enterprise Context and Operating Model, and

OO

the Business Model.

F


Appendix - 213

PR

Recognise that Architecture and Engineering are two sides of the same coin. Architect horizontally. Engineer vertically.

OO

Recognise the differences

between Architecture and Engineering, and use both appropriately.

F


214 - Appendix

PR

Architecture is performed largely in the top phases, while Engineering is

performed largely in the bottom phases.

OO Architecture and

Engineering can be

performed within any phase.

F


Appendix - 215

PR

The relationship between Architecture and

Engineering as we move

from the top to the bottom phases is complex..

OO

Accept and exploit the fact that Architects can easily

see things that others find difficult or impossible to see.

F


216 - Appendix

PR

Donâ&#x20AC;&#x2122;t quash ideas just

because they are impossible. Impossible is just an opinion.

OO The true value of

Architecture (or Snake Oil) is intangible.

F


Appendix - 217

PR

When recruiting Architects, use the Pragmatic

Architects Creedâ&#x201E;˘ to sort the Architects from the Charlatans.

OO F


218 - Appendix

PR

There are many risks

related to increasing your EA maturity.

99% of these are misconceptions.

If you do not address them,

OO

YOU WILL FAIL.

F


Appendix - 219

PR

Many people will hate EA because:

1. It exposes problems and mistakes,

2. It breaks down silos and fiefdoms,

OO

3. Itâ&#x20AC;&#x2122;s about long term

benefits to the Enterprise, rather than short term benefits to individuals.

F


220 - Appendix

PR

Recognise that there are two types of EA:

1. Those that improve how EA is done.

2. Those that â&#x20AC;&#x153;doâ&#x20AC;? EA

(Strategic Transformation

OO

Planning and Governance).

Type 1 Enterprise

Architects help an

Enterprise to increase their

F

EA maturity.


Appendix - 221

PR

Type 2 Enterprise

Architects do Strategic

Transformation planning.

The Architecture

OO

Paradigmâ&#x201E;˘ is a way of

thinking about things in abstract terms to aid

understanding and design.

F


222 - Appendix

PR

Any “good” Architecture ONLY EXISTS to fulfil a customer’s needs.

Structural Complexity is a

OO function of the number of things something is

composed of, and the

number of relationships between them.

F


Appendix - 223

PR

Transformational Volatility is the rate of change of something.

Transformational

OO

Complexity is a function of the Structural Complexity and Transformational

Volatility of something.

F


224 - Appendix

PR

Contextual Volatility &

Complexity is defined as the Structural Volatility &

Transformational Volatility

of the context of something.

OO The Architecture

Paradigmâ&#x201E;˘ is only

applicable when Structural Complexity and

Transformational Volatility

F

are high enough.


Appendix - 225

PR

As Transformational

Complexity rises, use of the Architecture Paradigmâ&#x201E;˘ becomes mandatory, to preserve your ability to

transform, and manage the

OO

cost of transformation.

F


226 - Appendix

PR

Recognise that as the need to adopt The Architecture Paradigmâ&#x201E;˘ increases, the appetite (and therefore commitment) to do so, decreases.

OO F


Appendix - 227

PR

Do not overestimate the short term value, or

underestimate the long

term value, that use of The Architecture Paradigmâ&#x201E;˘ can provide.

OO

Use POET and PEAF to

make sure you donâ&#x20AC;&#x2122;t make the same mistakes that cause 90% of all EA

F

initiatives to fail.


228 - Appendix Sources & Resources

OO

PR F


Appendix - 229

OO

PR F


OO

PR F

,!7IB9A8-ecefha!


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

What is EA

PR

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.

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

OO

While the seas are calm, an unprepared ship and crew is generally indistinguishable from a well prepared ship and crew. In fact the unprepared ship will often seem preferable to many, setting sail before other more well prepared ships - not having to waste time gathering and studying the correct charts, loading extra emergency rations, checking the presence and quality of the life-rafts nor performing preventative maintenance on the engine. Often the unprepared ship will set sail and return with a hold full of fish while the prepared ship is still making good their preparations.

A

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

Current (Now)

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

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

Prog / Proj / Initiative

Prog / Proj / Initiative

Prog / Proj / Initiative

Prog / Proj / Initiative

F

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

ISBN 978-1-908424-57-0

,!7IB9A8-ecefha!:t;K;k;K;k

Prog / Proj / Initiative

Prog / Proj / Initiative

Prog / Proj / Initiative

Target Year 5

Prog / Proj / Initiative

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 Gardener

Connecting the DOTS

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

Prog / Proj / Initiative

Prog / Proj / Initiative

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!

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

P F Part of the Pragmatic Family

Profile for Pragmatic EA Ltd

What is EA - A Pragmatic Explanation  

Advertisement