Enterprise Architecture Tools - A Pragmatic Approach to Selection and Adoption by Pragmatic EA Ltd

1 02 v2

A Pragmatic Approach to Selection and Adoption

OO F

Kevin Lee Smith The Pragmatic Thinker

Part of the Pragmatic Family

Enterprise Architecture Tools

A Pragmatic Approach to Selection and Adoption

v2021 Kevin Lee Smith

First published: May 2017 Last updated: January 2021

ISBN 978-1-908424-53-2 (hardback) ISBN 978-1-908424-54-9 (paperback) ISBN 978-1-908424-55-6 (ebook) Published by:

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

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

Currently Available Reference Books

The Pragmatic Family of Frameworks A Pragmatic Introduction

Enterprise Fundamentals

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

A Pragmatic Approach Using PEFF

Enterprise Transformation A Pragmatic Approach using POET

Enterprise Architecture A Pragmatic Approach using PEAF

Currently Available Focus Books PEAF 4 TOGAF

978-1-90842407-5

PEFF

978-1-90842410-5

POET

ISBN

Pre-requisites

978-1-90842425-9

Kick-start Your TOGAF Adoption. Pragmatically

Transformation Governance

A Pragmatic Approach using Transformation Debt™

Enterprise Architecture Tools

A Pragmatic Approach to EA Tool Selection and Adoption

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

What is EA

978-1-90842457-0

A Pragmatic Explanation

Transformation Culture

978-1-90842459-4

The Inconvenient Pragmatic Truth

Transformation Maturity Assessment A Pragmatic Approach using the PTMC

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

Coming Soon

Enterprise Direction

A Pragmatic Approach using POED

Enterprise Operation

A Pragmatic Approach using POEO

Enterprise Support

A Pragmatic Approach using POES

Enterprise Engineering A Pragmatic Approach using PEEF

Pre-requisites

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

ISBN

Pre-requisites

978-1-90842416-7

PEFF

978-1-90842419-8

PEFF

978-1-90842422-8

PEFF

978-1-90842413-6

POET

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

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

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

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

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

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

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

Acknowledgements

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

Contents

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

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

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

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

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

Methods ................................................. 63 Disciplines................................................................................................... 65 Overview ............................................................................................................................................. 65 Capability Model ................................................................................................................................ 68 Overview ............................................................................................................................................. 70

Artefacts................................................................................................................................................................................. 70

Modelling .............................................................................................................................................. 72 Decision Making ................................................................................................................................. 75

Artefacts ................................................ 79 Ontology..................................................................................................... 81 Basics .................................................................................................................................................... 81

Mapping to Phases ............................................................................................................................................................. 84 Volatility, Volume, Impact & Population ...................................................................................................................... 86 Transitions ............................................................................................................................................................................. 90

Detail..................................................................................................................................................... 92

Structural & Transformational ....................................................................................................................................... 92 Models .................................................................................................................................................................................... 94 Meta-models......................................................................................................................................................................... 98

Structural & Transformational ..................................................................................................... 100 Models ............................................................................................................................................... 102

Relationships...................................................................................................................................................................... 105

The reasons the work is required........................................................... 105 Meta-models ............................................................................................ 109 Overview .......................................................................................................................................... 109

Enterprise Strategy (aka Business Strategy) ........................................................................................................... 109 Transformation Strategy (aka IT Strategy).............................................................................................................. 110

Transformational ............................................................................................................................. 112

Business Model ................................................................................................................................................................. 112 Roadmap Model............................................................................................................................................................... 113 Principles ............................................................................................................................................................................. 115 Debt Agreement ............................................................................................................................................................... 118

Structural .......................................................................................................................................... 123

Capability Model .............................................................................................................................................................. 123 Operating Model .............................................................................................................................................................. 124

Items..................................................... 127 The Architecture Paradigmâ&#x201E;˘ ................................................................ 129 Abstraction & Elaboration ............................................................................................................ 129 Relationships .................................................................................................................................... 132 The Value is in the Lines not the Boxesâ&#x201E;˘ ............................................................................... 134 Patterns ............................................................................................................................................. 137 Models, Meta-Models & Semantics ............................................................................................. 140

Models ................................................................................................................................................................................. 140 Meta-Models ..................................................................................................................................................................... 141 Semantics ........................................................................................................................................................................... 141

Tools......................................................................................................... 144

Number & Growth ......................................................................................................................... 144 How POET Helps ........................................................................................................................... 147 Coverage ........................................................................................................................................... 150 Integration......................................................................................................................................... 153 Coverage ........................................................................................................................................... 156 Vendors ............................................................................................................................................. 158 Evaluation .......................................................................................................................................... 160

Requirements .................................................................................................................................................................... 160

Demonstrations............................................................................................................................... 168

Process ................................................................................................................................................................................. 173 Raw Scores......................................................................................................................................................................... 175 Weighted Scores .............................................................................................................................................................. 177 X-Requirements................................................................................................................................................................ 179 XA - Tool Architecture X-Requirements................................................................................................................... 180

XC - Tool Configuration and Maintenance X-Requirements ............................................................................. 183 XF - Tool Functionality X-Requirements ................................................................................................................... 186

Adoption .............................................. 191 Step 5........................................................................................................ 193 Actions ............................................................................................................................................... 193

Select an EA Modelling Tool ......................................................................................................................................... 193

Step 6........................................................................................................ 196 Actions ............................................................................................................................................... 196

Rollout EA Modelling Tool.............................................................................................................................................. 196

Guidance .................................................................................................. 198 Tools ................................................................................................................................................... 200

Types..................................................................................................................................................................................... 200 Issues .................................................................................................................................................................................... 203 Fundamentals..................................................................................................................................................................... 207 Can I use my CMDB?...................................................................................................................................................... 209

Appendix .............................................. 217 Background .............................................................................................. 219 Why Were They Created?............................................................................................................ 219 When Were They Created? ......................................................................................................... 219 Where Did They Come From? .................................................................................................... 219 How Were They Created?............................................................................................................ 222 What Was Used to Create Them? ............................................................................................. 223 The Author........................................................................................................................................ 225

Keypoints .................................................................................................. 229 Sources & Resources ............................................................................... 251

Foreword - 1

FOREWORD

OO F

2 - Foreword Why Should I Read This Book?

Many Enterprises already have some kind of EA Modelling Tool, that are being actively used for the purpose of Enterprise Architecture, aka creating and maintaining Structural (Capability) and Transformational (Portfolio) Roadmaps. But those Enterprises are in the minority. Many, many more have either no EA Modelling Tool at all, or they have one but have found that it has not lived up to expectations and sits gathering dust on the shelf or being used as glorified reporting tool and generally providing questionable (if any) returns. Having witnessed many failures, this book sets out the Methods, Artefacts and Environment required to effectively choose and operate an EA Modelling Tool. It covers the key things that must be done to effectively and efficiently choose a tool, and then to operate it in a sustainable way. If the Management decides to choose (or replace) and operate an EA modelling tool effectively, then this book sets out all that is required to do so. Pragmatically. Who Should Read This Book?

Anyone involved in making sure their investment in an EA Modelling Tool is sound. E.g. CIOs, Head of PMO, Head of Business Analysis, Head of S&A, Head of Solution Delivery, Enterprise Architects, Solution Architects, Business Analysts, Project Managers, Configuration Managers, Change Managers, etc, etc. Why Should I attend a Workshop?

Run over 1 day and using this book, the first part of the workshop presents the concepts required to understand an EA Modelling Tool, what it used for, what information must be modelled, and Pragmatic methods for adoption and use. The remainder of the day is a hands-on workshop where you will formulate your own tailored approach for selection, define which requirements are key to you, and develop a shortlist. Enterprises (Public Companies, Private Companies, Government Agencies) spend a lot of time and money on tools. But many of these tools sit on the shelf or are used in only small ways. The most common reasons are that: The tool they selected is not is not appropriate for their Enterprise. The way the tool is being used is not appropriate for their Enterprise.

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

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

Foreword - 3

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

4 - Foreword

KEYPOINT:

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

ADOPTION:

Management: Instigate a project to ensure everyone related to

OO Transformation is trained in

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

Questions to Ponder

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

PR INTRO DUCT IO N

Introduction

Introduction - 5

OO F

Introduction

6 - Introduction

KEYPOINT:

The Introduction section of PF2

introduces the companies that are part of the Pragmatic Family.

Questions to Ponder

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

OO F

PR F

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

Introduction

Introduction - 7 Companies Over view

Introduction

8 - Introduction

KEYPOINT:

Pragmatic 365 is a non-profit

research company. Pragmatic EC is a consulting company.

ADOPTION:

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

Enterprise's Transformation capability.

Questions to Ponder

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

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

Introduction

Introduction - 9

Introduction

10 - Introduction Pr agmatic EC

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

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

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

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

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

Pragmatic’s Vision is…

“The Transformation of Transformation. ”

Introduction

Introduction - 11

OO F

Introduction

12 - Introduction

KEYPOINT:

Most consultancies only want to sell you fish.

Pragmatic will teach you how to fish.

ADOPTION:

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

OO consultancies and therefore Transformation.

Questions to Ponder

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

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

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

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

Introduction

Introduction - 13 Licens ing

Introduction

14 - Introduction

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

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

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

KEYPOINT:

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

ADOPTION:

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

OO circumstances.

Questions to Ponder

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

Introduction

Introduction - 15

Introduction

16 - Introduction Tr aining Cer tification Cour s es

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

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

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

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

Certification Courses

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

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

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

Introduction

Introduction - 17

Introduction

18 - Introduction

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

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

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

“I would recommend PEAF because It is a great straight forward place to start looking into EA. The concept are straightforward and both easy to apply and understand.” - ICT Architect, Australia “I would recommend PEAF because of it's logical and Pragmatic approach to EA. I find it less academic than some of the other frameworks.” - Enterprise Solution Architect, South Africa

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

Introduction

Introduction - 19

Introduction

20 - Introduction

KEYPOINT:

PEAF Certified training, provides

everything to enable you to adopt PEAF.

ADOPTION:

Management: Engage Pragmatic EC to deliver PEAF Certified

Transformation Best Practice training. Questions to Ponder

♦ ♦ ♦ ♦ ♦

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

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

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

Introduction

Introduction - 21 Focus ed Wor ks hops

Introduction

22 - Introduction

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

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

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

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

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

Your Enterprises Transformation capability is strategically important to its survival.

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

Introduction

Introduction - 23

Introduction

24 - Introduction

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

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

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

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

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

Either you will control it.

Or it will control you.

Introduction

Introduction - 25

Introduction

26 - Introduction

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

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

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

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

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

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

Introduction

Introduction - 27

Introduction

28 - Introduction

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

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

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

Introduction

Introduction - 29

PR F

Introduction

30 - Introduction

KEYPOINT:

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

ADOPTION:

Management: Engage Pragmatic EC to deliver Focussed training.

Questions to Ponder

♦ ♦ ♦ ♦ ♦

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

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

Introduction

Introduction - 31 Options

Introduction

32 - Introduction

KEYPOINT:

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

ADOPTION:

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

OO Publishing Platform and all component files.files.

Questions to Ponder

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

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

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

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

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

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

Introduction

Introduction - 33 Pr agmatic Publis hing Platfor m Over view

Introduction

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

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

KEYPOINT:

P3 allows Enterprises to easily

produce and maintain their own

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

ADOPTION:

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

Questions to Ponder

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

Introduction

Introduction - 35

Introduction

36 - Introduction Des ign

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

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

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

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

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

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

Introduction

Introduction - 37

Introduction

38 - Introduction Customer Segments

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

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

♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦

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

OO F

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

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

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

♦ ♦ ♦ ♦ ♦

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

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

Introduction

Introduction - 39

Introduction

40 - Introduction

KEYPOINT:

P3 is a component based authoring system.

ADOPTION:

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

OO adoption.

Questions to Ponder

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

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

Language - 41

Language

PR LAN GUA GE

OO F

42 - Language

KEYPOINT:

The Language section of PEFF

Language

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

Questions to Ponder

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

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

Language

PR OO

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

44 - Language

Language

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

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

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

Language - 45

KEYPOINT:

confusion that language can create.

ADOPTION:

EA Project Team: Create a data

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

OO Capability.

Questions to Ponder

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

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

Language

Be ever vigilant of the hidden

46 - Language What is a Sys tem?

PR Language

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

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

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

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

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

Actually Exists

Opportunities for Abuse

105

5460

5355

5460

14903070

14897610

14903070

1.11051E+14

Language

Language - 47

48 - Language

KEYPOINT:

Everything is a System.

Language

ADOPTION:

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

Transformation Capability.

Questions to Ponder

♦ ♦ ♦ ♦ ♦

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

Language - 49 What is an Enter pr is e?

Language

PR OO

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

50 - Language

Language

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

OO F

Language - 51

KEYPOINT:

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

ADOPTION:

EA Project Team: Add the definition

of “Enterprise” to the data dictionary

OO used in the Enterprise's

Transformation Capability.

Questions to Ponder

♦ ♦ ♦ ♦

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

Language

The Word Enterprise does not mean

52 - Language What is Tr ans for mation?

PR Language

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

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

Language - 53

KEYPOINT:

Pragmatic’s use of the word “Transformation”.

ADOPTION:

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

dictionary used in the Enterprise's Transformation Capability.

Questions to Ponder

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

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

Language

There is no hidden connotation to

54 - Language What is a Fr amewor k

PR Language

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

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

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

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

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

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

Language

Language - 55

56 - Language

KEYPOINT:

A Framework is an expression of

Language

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

Artefacts, Guidance, Items, Culture)

and optionally information regarding its Adoption.

OO ADOPTION:

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

Questions to Ponder

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

Language - 57 Theor y or Pr actice

Language

PR OO

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

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

58 - Language

Language

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

Language - 59

KEYPOINT:

Practice

ADOPTION:

Management: Don’t dismiss theory as not important.

Questions to Ponder

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

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

Language

Theory is just as important as

60 - Language Colour s

PR Language

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

Language - 61

KEYPOINT: =

Information =

Understanding.

ADOPTION:

EA Project Team: Use standardised colours to mean something.

Questions to Ponder

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

Language

Colour

Methods - 63

Methods

M E THO DS

OO F

64 - Methods

KEYPOINT:

The Methods section of POET

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

Methods

ADOPTION:

C-Suite: Instigate a review of the

Methods used in the Enterprise's

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

Questions to Ponder

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

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

Methods - 65 Dis ciplines Over view

Methods

PR OO

Here the phases are across the top and the disciplines are down the side. The coloured humps give an indication of when each discipline is used and to what degree. Some of you will notice the similarity with RUP (Rational Unified Process). POET does not use RUP and does not mandate anyone that uses POET should adopt RUP. However, POET does recognise some important fundamentals that are present in RUP, which POET has also adopted:

♦ Firstly, POET (like RUP) recognises Phases vs Disciplines and that the mapping of

disciplines to phases is complex and not a simple one-to-one mapping. In addition POET also adds the disciplines of Modelling, Discovery, and Governing & Lobbying. ♦ Secondly, POET (like RUP) is iterative and recognises that within each of the phases, the work carried out may not be of a simple waterfall nature but is more naturally of an iterative nature. We also need to point out that while RUP is IT Project Centric, POET is Enterprise Transformation centric, recognising that Transformation has an Enterprise scope (not just IT) and encompasses Strategising and Roadmapping as well as Project Execution. Note the background colours:

♦ Light blue for disciplines that predominately work on Structural Information

(MAGIC). ♦ Light red for disciplines that predominately work on Transformational information (MAGMA). ♦ White for disciplines that work on both Structural and Transformational information. The disciplines that are not grey (which form the backbone of Pragmatic Transformation) are defined in more detail later.

66 - Methods

Methods

So, starting to look at the disciplines and phases contained in RUP, the question was, “What work is going on in the Strategising and Roadmapping phases?”. It turns out the it’s the same! So, I extended the use of the basic disciplines to the left. Essentially, the only difference between the use of Analysis and Design in the project phases, and the use of Analysis and Design in the Strategising and Roadmapping phases, is the information that is being Analysed and Designed. The same is true for all the other disciplines also, to a greater or lesser extent. To complete the work going on in the Strategising and Roadmapping phases I added more key disciplines that are sadly very immature in many Enterprises. Having done so, I then realised that these disciplines are also used (and mostly immature) in the Project level phases also (Solutioning, Elaboration, Constructing and Transitioning) And so they we added there too, which provides us with a complete overview of the key disciplines used throughout the Transformation domain. At this point, it is also worth point out, that Frameworks aimed at maturing parts of the Transformation domain, could be focussed around Phases or around Disciplines. For example, PRINCE2 is organised around the Project Planning and Management disciplines (horizontally), whereas EA frameworks such as PEAF are organised around the Strategising and Roadmapping phases (vertically). In general, this distinction is largely hidden and exists because without POET there is no context to position them within.

Methods - 67

KEYPOINT:

The Disciplines are used to a greater or lesser extent in each phase.

Management: Ensure everyone in Transformation is provided

appropriate training in the disciplines

they use to perform their tasks.

Questions to Ponder

♦ Does your Enterprise recognise the complicated mapping of Disciplines to the Phases of Transformation?

♦ If yes, how is this evidenced? ♦ If not, do you think it would be a good idea? ♦ Does your Enterprise recognise Modelling, Discovery, Decision Making and

Governance & Lobbying as disciplines that require an appropriate amount of time and resources to execute? ♦ If not, does that create any problems or issues? ♦ What needs to be done to alleviate them?

Methods

ADOPTION:

68 - Methods Capability Model

PR Methods

Here we present the Capability Model for the Transformation Capability of the Enterprise. When talking about Capability Models, most Enterprises only consider the O part of DOTS, that is, they only consider the Capabilities required for the Operation part of the Enterprise. While the Capabilities required for the Operation part of the Enterprise are of paramount importance (for it is those Capabilities which perform the actions that the Enterprise was created to perform, e.g. banking, drilling oil wells, providing healthcare services, etc) we must not forget the other strategically important parts of the Enterprise such as the domain we are concerned with here, aka the Transformation Capability of the Enterprise. Hang onâ&#x20AC;Ś.. This is a capability model right? Isn't a capability mode an Artefact of Transformation? So shouldn't this be in the Artefact section of POET not the Methods??? Good question! The answer is no. Whilst a capability model is an Artefact, it is a Methodological Artefact!

Methods - 69

KEYPOINT:

The Disciplines form the Capability Model for the Transformation

ADOPTION:

Management: Adopt the POET

Transformation Capability Model.

Questions to Ponder

♦ Does your Enterprise have a Capability Model for the Trasnsformation Capability of the Enterprise? ♦ If not, do you think it would be a good idea? ♦ Do you agree with Pragmatic’s Transformation Capability Model? ♦ If not, what would you change, and why?

Methods

Capability of the Enterprise.

70 - Methods Over view Ar tefacts

PR Methods

Here we have expanded the disciplines and moved the various models to the top and bottom of the diagram.

♦ Solid lines indicate models that are created in this phase. Outputs. ♦ Dotted lines indicate models that are created in another phase (either below or ♦ ♦ ♦ ♦

above). Inputs. An arrow at the top pointing up, indicates that information from this phase is used by the phase above. An arrow at the top pointing down, indicates that information from the phase above is used by this phase. An arrow at the bottom pointing up, indicates that information is used from the phase below. An arrow at the bottom pointing down, indicates that information from this phase is used by the phase below.

All disciplines are of an iterative nature. The interaction between these disciplines is also of an iterative nature.

Methods - 71

KEYPOINT:

The 6 main disciplines are: Discovery, Requirements Management, Analysis & Design, Governance & Lobbying,

ADOPTION:

Management: Review the maturity of

the 6 main disciplines (Requirements Management, Analysis & Design,

Discovery, Governance & Lobbying, Modelling and Decision Making.

Questions to Ponder

♦ Does your Enterprise allow for iteration in and between these disciplines? ♦ If not, does that create any problems? ♦ If so, what needs to be done to alleviate them?

Methods

Modelling and Decision Making.

72 - Methods Modelling

PR Methods

NOTE: The Modelling Discipline is special. It could be called a Meta-Discipline. It is special because it is never done on its own, It’s only every used by the other disciplines. Here we see the five main sub-disciplines of Modelling: Determine the Question

♦ Here we identify a question that needs to be answered. There is no reason to model

anything unless it will be used to answer a question. Either the question cannot currently be answered or the quality and confidence in an existing answer is too low to be useful.

Determine Required Data

♦ Having understood what the question is, here we identify what information will be required in order to answer it.

Populate the Model •

Here we find the information identified and populate the model with it. This should be thought of as effectively a data migration exercise - as illustrated by the sub process shown.

Integrate the Data

and will be maintained.

♦ Here we ensure that information that has been loaded into the model is sustainable ♦ For each source of the information loaded, there are two alternatives (which were identified in the Analysis Phase of the Populate the Model sub process).

Either…

Methods - 73 ♦ The source is removed - The people and/or processes and/or technology using the original source will stop using it and will use the information in the model in the future.

PR or…

♦ The source is preserved - The necessary MAGIC is put in place to enable the synchronisation and management of the data going forward with the people using it.

Answer the question

♦ Having populated the model, it is now possible to use the model in concert with the

Methods

tools and analyses provided by the modelling tool to answer the question.

OO F

74 - Methods

KEYPOINT:

1. Only model things to answer a

question. 2. Treat model population as a Data Migration exercise. 3. Integrate/remove source data.

Methods

ADOPTION:

Management: Ensure that Modelling

OO exists and is treated as a data migration exercise.

Questions to Ponder

♦ ♦ ♦ ♦

Does your Enterprise even recognise this as a discipline? How does this discipline map to your Enterprise? Are there any problems with how your Enterprise executes this discipline? Does the discipline your Enterprise uses include all of these required inputs and outputs? ♦ If not, what do you need to change? Who is Responsible for making them? And who is Accountable for making sure the changes are made? ♦ Does your Enterpise train people in this discipline? ♦ If not, do you think it would be beneficial to do so? If so, who will you talk to, to make it happen?

Methods - 75 Decis ion Making

Methods

PR OO

Decision making is the bedrock of everything that happens within the Transformation Capability of all Enterprises. Hundreds of decisions are made every day, thousands a month and probably millions per year. Each decision has the power to have a positive impact, but also has the power to make a negative impact. Decisions made in the higher up Phases (Strategising, Roadmapping, Solutioning) are likely to have more impact (positive or negative) than decisions made in the lower phases (Elaboration, Constructing, Transitioning). Decision making, is not so much trying to understand how to make good decisions, its more about how to avoid making bad ones. This does not mean that bad decisions will not be made because politics can destroy anything, but it will at least alleviate us from some of the more common and mundane reasons why bad decisions get made. It's also not so much about making good or bad decisions, because that can be very subjective. A decision by a customer to not buy a bottle of Champagne may well be a good decision from their point of view if their aim is to save money, but a very bad decision from the point of view of the bar owner. So, it's not really about the end result of the decision that is important, but more about how we go about it. Is it a reasonable method?

76 - Methods Do I understand the problem domain well enough? I have a saying

Methods

"If you don't know what the solution is, you don't understand the problem well enough." - Kevin Lee Smith

When making any decision, it is usually quite easy if you understand the problem that is requiring a decision to be made. If you understand the problem very well, solutions tend to appear in your mind as if by magic. So, don't rush to making a decision, Do I understand the aim well enough? This is similar to above but instead of considering the "input", we consider the "output" i.e. what are we trying to achieve why making this decision. For the same reasons as above, if we are not 100% clear on what we are trying to achieve, there is not much chance of us achieving it. Have I considered all reasonable options? Many times, people rush to judgment on making decisions. Often making a decision is finished as soon as a decision can be arrived at, but the "best" decisions tend to come when all options are on the table to be compared. Have I considered all the impacts? Many decisions turn out to be extremely sub-optimal purely because of unintended consequences. In my book, you only get unexpected consequences if you did not spend enough time, considering impacts in the first place. You should consider the Impact of a decision on you, other people, the thing the decision is being made about and other things. Another dimension to keep in mind is time, so for all the things you are considering the impact on, you should also consider the impact in the near term, mid term and long term impact.

Methods - 77

KEYPOINT:

1. Only model things to answer a

question. 2. Treat model population as a Data Migration exercise. 3.

ADOPTION:

Management: Ensure that Modelling

exists and is treated as a data migration exercise.

Questions to Ponder

♦ ♦ ♦ ♦

Methods

Integrate/remove source data.

Artefacts - 79

PR OO

Artefacts

ARTE FACTS

80 - Artefacts

KEYPOINT:

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

ADOPTION:

C-Suite: Instigate a review of the

Artefacts

Artefacts used in the Enterprise's Transformation Capability, to determine if their maturity is appropriate.

Questions to Ponder

♦ ♦ ♦ ♦ ♦

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

Artefacts - 81 Ontology Bas ics

♦ 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 Contextual level consists of the Enterprises Strategy (Mission, Vision, Goals, Objectives, Strategies, Tactics, etc). The Conceptual level consists of Transformational Roadmaps (Business and Technical), Conceptual Structural Models (Current, Target and Intermediate), and definitions of a series of programs projects and initiatives that effect the transformation. The Logical level consists largely of Logical structural designs. The Physical level consists largely of Physical structural designs. The Operational level consists largely of the CMDB - Configuration Management Database.

While these levels are often portrayed as separate it should be noted that the information at each level is not insular. The information at each level is fundamentally related to the

Artefacts

PR Here we see the fundamental levels of Enterprise Transformation based on the fundamental levels of Idealisation/Realisation. The Direction part of the Enterprise feeds Contextual information into the Transformation part of the Enterprise which delivers Physical Things into the Operations part of the Enterprise. It should be noted that the Transformation part of the Enterprise may also deliver Physical Things into the Direction, Support or even Transformation (the whole point of POET) part of the Enterprise but we just show Operations here as that is the most common occurrence. The fundamental levels are:

82 - Artefacts

information in the other levels and it is these relationships which are of paramount importance as they provide the glue that makes the whole coherent. Most relationships occur with the information that exists above and below each level and diminish for levels further away. This also illustrates that while people may be working with information primarily at one particular level, they need access to information at other levels to understand context (from above) and to understand implications (from below). In terms of naming these levels there are two fundamentals:

â&#x2122;Ś The Enterprise Architecture Model (EA) consists of Contextual and Conceptual information set in the Context of Enterprise Context information and Logical information. â&#x2122;Ś The Enterprise Engineering Model (EE) consists of the Logical, Physical and Operational information set in the Context of the Conceptual information and the Physical World.

Artefacts

Artefacts - 83

KEYPOINT:

All levels of the Enterprise

Transformation model are used in all phases.

ADOPTION:

Management: Ensure that all levels of

people working in all Phases.

Questions to Ponder

♦ ♦ ♦ ♦ ♦

Does your Enterprise have the concept of an EA Model and an EE Model? If not, should it? Where does your Enterprise draw the boundaries? Do the boundaries exist? How are they managed?

Artefacts

information are readily available to

84 - Artefacts Mapping to Phas es

PR Artefacts

Here the phases of Transformation are across the top and the levels of information down the side. The coloured humps give an indication of when the information at each level is used and to what degree. Some of you will notice the similarity with RUP (Rational Unified Process). POET does not use RUP and does not mandate anyone that uses POET should adopt RUP. As can be seen, while each phase is centred around using all of the information from a particular level, each phase also utilises information in levels above (For Requirements, Governance and Lobbying), and in levels below (for Impact Assessment, Governance and Lobbying).

Artefacts - 85

KEYPOINT:

Information from all levels are used in each phase.

ADOPTION:

Management: Ensure that all

information from each level can be

Questions to Ponder

♦ Does your Enterprise recognise the complicated mapping of levels of information ♦ ♦ ♦ ♦

required to the Phases of Transformation? If yes, how is this evidenced? If not, do you think it would be a good idea? If not, does that create any problems or issues? What needs to be done to alleviate them?

Artefacts

used in each phase

86 - Artefacts Volatility, V olume, Impact & P opulation

PR Artefacts

Volume This view gives an indication of the volume of information (as a percentage of the whole) that exists at each level. It can be seen that volumes increase the further down the phases we go. This seems pretty obvious but this fact tends to be ignored in most Enterprises. This therefore illustrates that an Enterprise Architecture Model is actually quite small in terms of the volume of information where a common misconception is that it is very large and therefore cannot be populated easily. Volatility Here we see the approximate rate of change for each of the levels of the structural and transformational Models.

♦ The Contextual level (consisting of the Enterprise’s Strategy - some call Business ♦

♦

Strategy) tends to change annually. In general an Enterprise’s overall strategy changes very slowly. The Conceptual level (consisting of the Business, Technical and Transformational roadmaps and portfolio of programmes and projects) tend to change annually or biannually. In general Enterprises tend to largely create/update these once per year as part of the annual business planning cycle. The Logical level (consisting largely of the Logical designs of the Enterprise) changes more often, perhaps monthly as transformation projects execute. The Physical level (consisting largely of the Physical designs of the Enterprise) changes more often again, perhaps weekly as transformation projects execute. The Operational level (consisting largely of the CMDB - Configuration Management Database) changes more often still, perhaps on a daily basis.

Artefacts - 87

Good decisions that have positive benefit cannot be proved and can be easily rejected, with any naysayers being accused of having their head in the clouds with no proof to back them up. Bad decisions that have bad effects cannot be proved and can be easily be accepted, with any naysayers being accused of being negative with no proof to back them up. It is for these reasons (and probably others) that it is easier for bad decisions to be made rather than good decisions, especially when the culture of the Enterprise supports it.

Population Here we propose how each level of information should be populated and some ball-park timescales.

â&#x2122;Ś Information at the Enterprise Context, Contextual and Conceptual levels can be and should be populated by a concerted effort to so - a project, which is generally the annual Strategy and Business Planning work that many Enterprises undertake on an annual basis.

Artefacts

Both the Contextual and Conceptual levels could also be changed at any time due to pressures in the Enterprise context such as Mergers & Acquisitions, etc. Impact Here we see the potential impact of decisions made at each level. The impact could be positive or negative. Good decisions will have positive effects, bad decisions will have negative effects. In general, the impact will be felt in terms of the effectiveness and efficiency of subsequent phases and in terms of the effectiveness and efficiency of what is ultimately deployed. If good decisions are made, the impact will be felt in terms of reduced costs, reduced timescales, reduced risks and increased agility and durability of the transformation. If bad decisions are made, the impact will be felt in terms of increased costs, increased timescales, increased risks and decreased agility and durability of the transformation. The impact (positive or negative) is greater the higher up the Transformation Phases we go. For example, bad decisions made in the Roadmapping phase that are not picked up until we get to Construction can be severe and difficult and costly to correct (from a resource point of view but also from a cultural point of view), whereas bad decisions made in the Transitioning phase are mild by comparison and generally tend to be of low cost to correct (from a resource point of view but also from a cultural point of view). Conversely, good decisions made in the Roadmapping phase can have massive benefits for the Construction phase whereas good decisions made in the Transitioning phase will not have as much impact. Since the Enterprise Architecture Model is concerned with the Contextual and Conceptual information set in the context of the Enterprise Context and the Logical Information, it is obvious what impact (positive or negative) this can have if done well or done badly. This is why Enterprise Architecture is so important for many Enterprises. NOTE An interesting point to note here is that, the time to see the effects of decisions made at the higher levels (good - if good decisions are made, bad - if bad decisions are made), takes longer to be found/realised than at the lower levels. This is a perfect storm/environment for people to make bad decisions!

88 - Artefacts â&#x2122;Ś Information at the Operational level could also be populated by a project, despite

the volume of information involved. This is because automated tools can be deployed to break the back of this work although interpretation and massing by humans is still required.

â&#x2122;Ś Information at the Logical and Physical levels is normally far too large to be

populated by a single project and also tends to be very difficult to obtain. While a project could be created to populate this information wholesale, the time and money involved is usually very high with the benefits of doing so only realised over a long timeframe as subsequent projects utilise the information collected. A more Pragmatic approach is to populate this information as and when individual projects from the project portfolio require it. Every project will need to create some of this information for the purposes of being able to execute the project anyway, and so capturing this over time in an ordered and well managed way, will mean that the information builds up gradually on an as-needed basis. Some may say, Pragmatically!

Artefacts

Artefacts - 89

KEYPOINT:

Ensure that the Logical and Physical levels are populated over time as a deliverable of executing projects.

ADOPTION:

Management: Instigate Projects to

Contextual, Conceptual and Operational levels of the

Transformation information.

Management: Ensure all executing

Projects populate the Logical and Physical levels of Transformation information, as they execute.

Questions to Ponder

complete EA Model?

♦ Does your Enterprise understand the low volume of information required for a ♦ Does your Enterprise understand the large volume of information required for a complete EE Model?

♦ Does your Enterprise populate this information in a Pragmatic way? ♦ Can you improve the way your Enterprise populates and maintains this information?

Artefacts

populate the Enterprise Context,

90 - Artefacts Tr ans itions

PR Artefacts

The interaction between the Structural and Transformational artefacts are shown here. All of the boxes with rounded lines relate to models (based on their associated meta-models). The Structural Models relate to the information about the structure of the Enterprise at various levels of Transformation abstraction and can exist in two main states:

â&#x2122;Ś Current - What currently exists. â&#x2122;Ś Target - What is required to exist. There may also be zero or more intermediate states and there may also be more than one target state representing different scenarios.

The Transformational models relate to the reasons for the Transformation along with information required to effect the transformation from one state to the next. As you can see these models do not and should not exist in a vacuum. They are all connected and related to one another.

Artefacts - 91

KEYPOINT:

MAGIC defines Structural

information at points in time,

MAGMA defines Transformational information between them.

ADOPTION:

create the information necessary to do their job.

Questions to Ponder

♦ Is the information you use to execute Transformation connected and related to the information it needs to be?

♦ If it isn’t, what problems is that likely to create? ♦ Are you experiencing any of those problems?

Artefacts

Management: Allow workers to

92 - Artefacts Detail Str uctur al & Tr ans for mational

PR Artefacts

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

Artefacts - 93

KEYPOINT:

This is the complete map of information required for

Transformation to be executed in an

Effective, Efficient, Agile and Durable way.

Management: Map the Artefacts of Transformation to MAGIC and

MAGMA over the seven layers of

Transformation, to determine where the gaps and overlaps are.

Questions to Ponder

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

♦ ♦ ♦ ♦ ♦

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

Artefacts

ADOPTION:

94 - Artefacts Models

PR Artefacts

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

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

♦

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

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

♦ The Business Motivation Model corresponds to the Contextual level of

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

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

♦

♦ ♦

♦

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

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

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

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

Artefacts

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

96 - Artefacts

KEYPOINT:

Enterprise Strategy is the Business

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

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

Artefacts

Artefacts - 97

ADOPTION:

Management: Ensure that all parts of the Enterprise understand the

dependencies between the Business model, the Business Motivation

model, Capability models, Operating models and Roadmap models.

Management: Ensure that all parts of

dependencies between the Enterprise

Strategy and Transformation Strategy.

Questions to Ponder

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

Artefacts

the Enterprise understand the

98 - Artefacts Meta-models

PR Artefacts

If we intend to model all the information we have identified, we will need a Metamodel, aka a list of Entities and their Relationships of the things that we will model. It would be nice to choose one, however in reality, one Metamodel to cover the entire Transformation domain does not exist and so a hybrid approach is needed. Here we see an example of a full hybrid meta-model, constructed by taking the most appropriate things from various meta-models from various frameworks, and producing a meta-model with 100% coverage. We say 100% coverage because it covers both Structural and Transformational information, from a Strategy to Deployment perspective. You may be surprised that the part that Pragmatic contributes (in red) is so small. This is perfectly understandable as Pragmatic have always asserted that lack of meta-models has rarely been the reason for EA’s failure and since there are already a multitude of Metamodels already in existence it would be churlish to re-invent the wheel so to speak. Pragmatic has, however, made a massive contribution by the introduction of Transformation Debt™ Agreements (TDAs) that allow the exposing and management of Transformation Debt™.

In addition Pragmatic's contribution is by the definition of the Ontology that all these other frameworks co-exist within, aka DOTS, MAGIC and MAGMA. Having said that, it has become obvious over time, that the lack of a single coherent metamodel, coupled with the difficulty most tools have in using hybrid metamodels, creates a massive problem for Enterprise and therefore a full Pragmatic Metamodel is in production, which will cover all domains and all levels.

Artefacts - 99

KEYPOINT:

There is no single metamodel, that

covers all the information required for Transformation.

ADOPTION:

EA Project Team: Develop a Hybrid

Architecture and Engineering modelling.

Questions to Ponder

♦ ♦ ♦ ♦ ♦ ♦

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

Artefacts

Metamodel for Enterprise

100 - Artefacts Str uctur al & Tr ans for mational

PR Artefacts

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

Artefacts - 101

KEYPOINT:

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

ADOPTION:

Management: Ensure everyone in the

of information relate to EA.

Questions to Ponder

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

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

Artefacts

Enterprise understands which levels

102 - Artefacts Models

PR Artefacts

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

Artefacts - 103

KEYPOINT:

Enterprise Strategy is the Business

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

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

Artefacts

Business Motivation models.

104 - Artefacts

ADOPTION:

Enterprise Architect: Support the

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

Enterprise Architect: Create the

Transformation Strategy, by creating

Artefacts

the Roadmap Model and Operating Model.

Questions to Ponder

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

Artefacts - 105 Relations hips

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

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

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

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

Artefacts

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

106 - Artefacts

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

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

Artefacts

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

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

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

Artefacts

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

108 - Artefacts

KEYPOINT:

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

ADOPTION:

Management: Ensure EAs have the

information required to do their job.

Artefacts

Questions to Ponder

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

Artefacts - 109 Meta-models Over view

have. It takes the view that the Business Strategy is written and then thrown over a wall to those IT bods to figure out the IT strategy, and out of that there then comes projects - Generally IT projects, because most transformation is all or mostly, about changing IT. Effectively the proper Roadmapping phase (the core of EA) is lost or, if not lost, is limited to and conflated with IT Strategy. ♦ Plate B illustrates the Pragmatic view where the Business and IT strategies are formulated together. They are (should be) inextricably linked and must be formulated together as each feeds on the other. The IT Strategy is shown smaller because the Business Strategy is much bigger! The Business Strategy includes, Methods, Artefacts, Guidance, Culture and part of Items (IT - which is itself a sub domain of the larger Technology domain) while the IT Strategy only covers the IT part of the Technology Part of the Items domain. Thus, the Business Strategy and IT Strategy come together to make the Enterprise Strategy which then flows into the Transformation Strategy (the high level plan of how the required Enterprise Transformation will be undertaken) Enterprise Strategy (aka Business Strategy)

A strategy is really just a high level plan and answers four basic questions: Where are we? Where do we want/need to go? Why do we want/need to go there? How will we get there?

1) 2) 3) 4)

Artefacts

PR ♦ Plate A illustrates the “normal” but flawed mental model, that many Enterprises

110 - Artefacts

I say “should” because many “Strategy” documents produced by Enterprises are not Strategy documents at all based on this definition. The only thing that makes a lot of them “Strategy” documents is because they have the word “Strategy” written on the front! Although we use the term Enterprise Strategy (and urge others to do so) many Enterprises refer to this as Business Strategy. The term is in widespread use and there is nothing wrong with that per se. But as time has passed since it was first used, IT happened! More importantly people have begun (unfortunately) to refer to IT and “The Business” (as PEAF does - because you cannot ignore reality however wrong it may be from a purist’s perspective). The word Business has come to mean “everything in the Enterprise that is not IT”. This distinction is reinforced with terms such as Business Analysis and Business Analysts who work 99% of the time purely on the people and process issues of a solution, leaving the IT issues to someone else. So the term Business Strategy would seem to intimate that there is a separate IT Strategy (another slight misnomer as explained below). In addition the term Business is not very general to refer to the whole (do people refer to the Army as “The Business”?) and so we prefer to use the word Enterprise hence we use the term Enterprise Strategy instead of Business Strategy because it is, after all, the Strategy of the Enterprise aka a high level plan of where we are, where we want to go to, why we want/need to go there and how we are going to get there. Transformation Strategy (aka IT Strategy)

Artefacts

Although we use the term Transformation Strategy (and urge others to do so) many Enterprises refer to this as IT Strategy. This has happened because most of the Transformation happening in any Enterprise is IT Transformation. The difference between Transformation and IT has become blurred and confused. It should be noted here that we are walking a fine line between the words I would like to use and the words I have to use because of history and the way people generally use them (rightly or wrongly).

Artefacts - 111

KEYPOINT:

The Business Strategy and IT Strategy are inherently linked and cannot be thought of separately.

ADOPTION:

Enterprise Architect: Develop the IT

Business Strategy in an integrated

way, not after the Business Strategy is thrown over the wall.

Questions to Ponder

♦ Do you agree with the definition of a “Strategy” above? If not, how would you define ♦ ♦ ♦ ♦ ♦ ♦ ♦

a “Strategy”? Does your Enterprise define an integrated Enterprise Strategy (Business and IT)? Does your Enterprise define an integrated Transformation Strategy (Business and IT)? If not, does this cause any issues or problems? If so what do you need to do to alleviate them? What Meta-models do you currently use? Do they have limitations? How do you integrate them?

Artefacts

Strategy at the same time as the

112 - Artefacts Tr ans for mational

PR Artefacts

Business Model

The Business Model Meta-model is loosely based on the Business Motivation Model (BMM) that was developed by The Object Management Group (OMG) although various changes have been made - most notably being that it is structured using MAGMA.

♦ Motivation ♦ Vision - A statement about the enduring value the Enterprise will deliver

without regard to how it is to be achieved. ♦ Goal - Statements about a state or condition of the Enterprise to be brought about or sustained through appropriate means. Compared to an Objective, a Goal tends to be: ongoing, qualitative (rather than quantitative), general (rather than specific), longer term. ♦ Objective - Statements of a specific time-targeted, measurable, attainable target that an Enterprise seeks to meet in order to achieve its Goals. Compared to a Goal, an Objective is: short-term, not continuing beyond its timeframe (which may be cyclical). ♦ Actions ♦ Mission - The ongoing operational activity of an Enterprise. ♦ Strategy - Courses of action that is one component of a plan for a Mission. It is accepted by the Enterprise as the right approach to achieve its Goals, given the environmental constraints and risks. Compared to a Tactic: longerterm, broader in scope. ♦ Tactic - Courses of action that represents part of the detailing of Strategies. Compared to a Strategy: shorter term, narrower in scope. ♦ Guidance

Artefacts - 113 ♦ Influence - An act, process, or power of producing an effect without

apparent exertion of tangible force or direct exercise of command, and often without deliberate effort or intent. ♦ Policy - Guides the Enterprise. Compared to a Rule it is less structured, less discrete or not atomic, less carefully expressed in terms of standard vocabulary. ♦ Rule - Influences or guides business behaviour, in support of a Policy. Compared to a Policy it is highly structured, discrete or atomic, carefully expressed in terms of standard vocabulary. ♦ Measures

♦ CSF (Critical Success Factor) - are the causes of our success. Measures the things we must do to be successful and used to measure and track Actions.

♦ KPI (Key Performance Indicator) - Measures the effects of our success. They are indicators that we are winning and used to measure and track Motivation.

♦ Assessment ♦ SWOT (Strengths, Weaknesses, Opportunities, Threats) - An assessment

Roadmap Model

♦ Motivation ♦ Requirement - Conceptual representation of requirements. More detailed than an Objective.

♦ Actions ♦ Program - A grouping of Projects and Initiatives. ♦ Project - A grouping of Initiatives. ♦ Initiative - A piece of work. ♦ Guidance ♦ Principle - Conceptual guidance. ♦ Policy - Logical guidance. ♦ Standard - Physical guidance. ♦ Assessment ♦ Transformation Debt Agreement (TDA) - An assessment of the impact and implications of not following a Principle, Policy or Standard.

Artefacts

that indicates an area of advantage or area of excellence, an area of inadequacy, something that can have a favourable impact, something that can have an un-favourable impact to the execution of the Means or achievement of Ends.

114 - Artefacts

KEYPOINT:

Specific Entities are required to

define the Business Motivation and Roadmap models

ADOPTION:

EA Project Team: Define the

Motivation, Actions, Guidance,

Artefacts

Measure and Assessment entities,

you need to create the Business and Roadmap Metamodels.

Questions to Ponder

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

Artefacts - 115 Pr inciples

♦

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

Artefacts

PR ♦ Name - The name of the Principle.

116 - Artefacts

Artefacts

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

Artefacts - 117

KEYPOINT:

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

ADOPTION:

EA Project Team: Define the

entities, you need to be able to

record Transformation Debt™

Questions to Ponder

Artefacts

Transformation Debt Agreement

118 - Artefacts Debt Agr eement

Scope

PR Artefacts

Summary

The information that is causing the problem. Transformational (Motivation / Actions / Guidance / Measures / Assessment) or Structural (Methods / Artefacts / Guidance / Items / Culture) The type of problem. (Cannot Comply / Insufficient or Inadequate Input)

Transformation Reference

The Program, Project or Initiative experiencing the problem

Governance Boundary

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

Reasons

A high level description of why this problem exists.

Transformational Impact

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

Problem Type

Artefacts - 119 Operational Impact

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

PR Cost of Compliance

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

Cost of Non-Compliance

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

Cost of Remediation

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

Decision

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

Rationale

The reasons why the decision was taken

Capital Costs

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

Revenue Costs

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

People

What People do you need that you cannot get access to?

Time

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

Scope

What change in scope is required?

Process

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

Cost of Non-Compliance

Actions Costs

A description of the issue.

Issues

Description

How the issue will be resolved.

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

Artefacts

Cost of Compliance

120 - Artefacts A target date of when the issue will arise.

Owner

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

Description

A description of the risk.

Effect

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

Proximity

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

Likelihood

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

Impact

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

Mitigating Actions

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

Costs

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

Risks

Artefacts

Date

Target Date

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

Owner

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

Cost of Remediation

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

Revenue Costs

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

People

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

Time

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

Process

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

Capital Costs

Artefacts - 121

Artefacts

PR F

122 - Artefacts

KEYPOINT:

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

ADOPTION:

EA Project Team: Define the

Transformation Debt Agreement

Artefacts

entities, you need to be able to

record Transformation Debt™

Questions to Ponder

Artefacts - 123 Str uctur al

♦ Methods ♦ Business Capabilities - Core business functionality (with inputs/outputs – ♦ ♦

♦

Artefacts) required to effect the Business model Artefacts ♦ Artefact Capabilities – Core business supplies or production Guidance ♦ Influence - An act, process, or power of producing an effect without apparent exertion of tangible force or direct exercise of command, and often without deliberate effort or intent. ♦ Policy - Guides the Enterprise. Compared to a Rule it is less structured, less discrete or not atomic, less carefully expressed in terms of standard vocabulary. ♦ Rule - Influences or guides business behaviour, in support of a Policy. Compared to a Policy it is highly structured, discrete or atomic, carefully expressed in terms of standard vocabulary. Items ♦ Physical/Mechanical Capabilities – e.g. Buildings, Tables, ♦ Electrical Capabilities – e.g. Motors, Servers, ♦ Chemical Capabilities – e.g. Oxidation, Hydrolysis ♦ Information Capabilities – e.g. storage, processing, display Culture ♦ Human Capabilities – Skills  Role - A group of behaviours

Artefacts

PR Capability Model

124 - Artefacts Operating Model

♦ Methods ♦ Function - A hierarchical list of Business functions that the business carries

out. ♦ Activity - A high Level logical grouping of business processes carried out by one or more departments. ♦ Phase - A step ion a Function or Activity. ♦ Discipline - A type of work performed in one or more Phases. {{Murambwa Clever Haparari}}

Artefacts

♦ Artefacts ♦ Service - The services the Enterprise consumes or produces. ♦ Product - The products the Enterprise consumes or produces. ♦ People - The people the Enterprise consumes or produces. ♦ Technology - The technologies the Enterprise consumes or produces. ♦ Guidance ♦ Principle - Conceptual guidance. ♦ Policy - Logical guidance. ♦ Standard - Physical guidance. ♦ Items ♦ Location - Physical geographical locations. ♦ Service - A Technology Service used by Functions and activities. ♦ Application - The main applications in use. ♦ Datastore - The main groups of data in use. ♦ Device - A generic piece of hardware provided as or part of a service to the business. ♦ Culture ♦ Value - Defines what is fair and unfair. ♦ Ethic - Rules of behaviour based on Morals. ♦ Moral - Relates what is right and wrong. ♦ Department - The departmental structure of the Enterprise.

Artefacts - 125

KEYPOINT:

Specific Entities are required to define the Enterprise Context,

Enterprise Capability and Operating models.

ADOPTION:

Artefact, Culture and Environment entities, you need to create the

Enterprise Context, Capability Model and Operating Model Metamodels.

Questions to Ponder

Artefacts

EA Project Team: Define the Method,

Items - 127

PR OO

Items

ITE M S

128 - Items

KEYPOINT:

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

ADOPTION:

C-Suite: Instigate a review of the

Tools and Frameworks used in the

OO Enterprise's Transformation

Capability, to determine if their maturity is appropriate.

Items

Questions to Ponder

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

(Frameworks/Tools) is used? Are those Frameworks/Tools documented? Understood? Are they fit for purpose? Are they used? All the time? Only when it suits? Which of them are Good? Why? Bad? Why?

Items - 129 The Ar chitectur e Par adigm™ Abs tr action & Elabor ation

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

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

Items

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

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

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

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

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

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

Items

Items - 131

KEYPOINT:

There are 4 types of Abstraction / Elaboration.

ADOPTION:

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

Questions to Ponder

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

Items

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

132 - Items Relations hips

PR Items

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

Items - 133

KEYPOINT:

The relationships between things rises in a polynomial fashion.

ADOPTION:

Management: Provide people the

tools and time to deal with the fact

that the relationships between things,

rise in a polynomial fashion.

Questions to Ponder

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

model and maintain relationships?

Items

relationships?

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

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

PR Items

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

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

Items - 135

Items

PR F

136 - Items

KEYPOINT:

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

ADOPTION:

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

Questions to Ponder

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

Items

Items - 137 Patter ns

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

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

Items

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

138 - Items

Items

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

Items - 139

KEYPOINT:

Look for patterns in everything.

ADOPTION:

Enterprise Architect: Look for patterns in everything.

Questions to Ponder

Items

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

♦ ♦ ♦ ♦ ♦

140 - Items Models , Meta-M odels & Semantics

PR Models

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

Items

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

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

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

Items - 141

Meta-Models

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

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

Items

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

142 - Items

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

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

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

Items

Items - 143

KEYPOINT:

Use structured data for all structural

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

ADOPTION:

Management: Provide people the

tools and time to model information,

instead of writing it in unstructured documents.

♦ ♦ ♦ ♦ ♦ ♦ ♦

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

Items

Questions to Ponder

144 - Items Tools Number & Gr owth

PR Items

In relation to the Transformation of Enterprises, there are many tools (Pragmatic is tracking hundreds) that have been produced to help Enterprises deal with Enterprise Transformation in a more effective and efficient manner These tools come in are of various types; Governance, Risk, Compliancy tools, Portfolio, Program, Project Management tools, Business, IT Strategy tools, Enterprise, Solution, Technical Architecture tools, Software Engineering tools, Change Management tools, Configuration Management tools, CASE tools, Test Management, Load Testing, Stress Testing tools, etc, etc, etc. Each of these tools has been designed and engineered to operate with a specific domain or context, for example; strategic planning, project management, enterprise architecture, software design and development, service management, change management, etc, etc, etc. We could categorise tools in different ways:

♦ Scope - Some tools exist to help with Strategising or Roadmapping, while others

exist to help with the design of systems, or a particular discipline such as Project Management. ♦ Type - Some tools deal only with Structural elements of Transformation (Categories, Ontologies, meta-models) like Archimate while others deal more with Procedural elements of Transformation (Methods, Practices, Processes) like MS Project or Rational RequisitePro. Like many things, these tools have grown and evolved organically and expanded their scope and areas of interest as they themselves have matured This has happened as the tool vendors have responded to requests from their clients for increased functionality and also as they see opportunities to expand into other lucrative areas. It’s very rare that a tool vendor will tell you that their tool does not do something! Project Management tools grew into Portfolio

Items - 145

Items

Management tools and vice versa, modelling tools that were created to model one thing have expanded into modelling other things. How successful tools have been in morphing themselves into areas they were never designed to operate in is largely subjective, and opinion tends to be driven by allegiances and crusades. In addition all of these tools have been designed and built in isolation - to optimise specific parts rather than the whole. So, the problem is not the lack of tools. The problem is the abundance of tools. Because of this, there are overlaps, gaps, inconsistencies and clashes. In short, total confusion. So the tool providers, whose primary aim is to provide clarity in their domain, have created confusion in the wider domain. Consequently people have adopted these tools in a similarly haphazard fashion, optimising specific parts but never considering the whole. Perhaps starting in one area and then finding themselves being subtly pulled into other areas. They have been optimising the parts at the expense of the whole. Pragmatic is currently tracking over 400 Enterprise Transformation tools. Pragmatic aims to categorise and compare them all. This work is currently in progressâ&#x20AC;Ś

146 - Items

KEYPOINT:

Over time, tools have grown and overlapped.

Questions to Ponder

♦ How many Transformation tools have you heard of? ♦ Did you know there were so many (Pragmatic is tracking hundreds)? ♦ Is your Enterprise using the ones most applicable to it?

Items

Items - 147 How POE T Helps

PR â&#x2122;Ś Firstly, and most importantly, POET provides this framework to Enterprises today -

for Enterprises to be able to consider and take a holistic, strategic and joined up view of all the Tools they use for Enterprise Transformation rather than point solutions. POET is the only framework in the world that does this. â&#x2122;Ś Secondly, it provides a framework to Tool Vendors as a basis (a super-type if you will) to allow Tools to begin to change and align themselves with this coherent and holistic environment. This will provide another benefit to Enterprises in the future because it will allow them to see much more clearly how these Tools relate and interface to each other in clear and straight forward ways which allow the holistic adoption of them much more straightforward. Of course this is likely to take a long time because Tool vendors tend to want to argue about their differences rather than agree on areas of similarity and demarcations.

Currently, to try to understand how all these different tools are related is almost impossible. For all the tools you want to use or do use, you need to map each tool to each other tool, to try to understand how they relate. But as tool vendors begin to use POET as the context for their tools, and map their tools to POET, it will become much much easier for Enterprises and the people who are accountable for how Transformation is effected, to be able to understand how they all relate, enabling

Items

Since the whole is much much more important than the parts (Context is Kingâ&#x201E;˘), it is important to have a cohesive and holistic Framework for all the Tools used to aid Enterprise Transformation, to ensure that the emphasis is to use these different Tools to optimise the whole of the Transformation domain rather than just the parts. To stop Enterprises optimising the parts at the expense of the whole, and to begin to allow Enterprises to optimise the whole at the possible expense of the parts. POET provides this cohesive and holistic Framework and provides two main benefits:

148 - Items them to make more informed decisions about who needs to use what, where, why, how and when.

PR Items

Items - 149

KEYPOINT:

POET provides an Ontology that you can map Transformation Tools to.

ADOPTION:

Enterprise Architect: Map all Tools

you currently use to POET, in order to be able to find your gaps and

OO overlaps.

♦ ♦ ♦ ♦ ♦ ♦

What Transformation Tools do you use? Are there overlaps? Are there gaps? Are there inconsistencies? What do you use to decide which Transformation Tools to use, where and how? What do you use to orchestrate the Transformation Tools you use into a holistic, coherent and cooperative whole?

Items

Questions to Ponder

150 - Items Cover age

PR Items

The use of Tools tends to grow out of the need people have to deal with the volume and complexity of the information they use to do their jobs or for people to be able to do things that they could otherwise not do. Configuration Management Tools grew out of the need to deal with the complexity and volume of the information in operations. Software Tools grew out of the complexity and volume of the information related to Software. Requirements Management Tools grew out of the complexity and volume of the information related to Requirements, etc, etc. The Green boxes with Blue lines, indicate areas where specific tools could fit. Before we start executing projects, we are dealing with the whole Enterprise at the Contextual and Conceptual levels, and so it is logical (and possible) for us to use one tool to do so. However, as we move into project specific areas of greater detail at the Logical Physical, and Operational levels, it is more usual to use tools that are specifically designed to satisfy a particular discipline, such as Requirement Management tools, Analysis & Design tools, Testing tools, Project Management tools, Configuration Management tools, etc. A tool could be as simple as a pen and paper but as the complexity and volume of the information rises, it is more common to use software based tools because (if used correctly, because “A fool with a tool is still a fool”) they reduce the maintenance burden and can provide analysis and visualisation functions that would otherwise not be possible. The information people use to do their jobs with respect to Enterprise Transformation splits into two fundamental types, Structural information and Transformational Information as defined by MAGIC and MAGMA. In order for people performing a role at each level of the Transformation Cascade™ to be effective and efficient, they need access not only to the primary information at their level but also, in decreasing amounts, to the information at other levels. Many Enterprises buy many tools, but these tools are usually bought as point solutions, without much consideration as to how they integrate into a whole. POET shows the scope of

Items - 151

Items

information that each tool requires access to, and thereby shows the large amount of overlap of information between tools. Each tool must not only be able to deal with the information that is required as an output for that phase, but each tool must also be able to relate that information to information at the level above (which provides the context) and to the level below (for impact analysis). In this way a coherent approach to selecting an integrated transformation tool portfolio is required. POET provides the framework to enable Enterprises to take a coherent and holistic view of the Tools used for Enterprise Transformation. This may in fact, require the sub-optimisation of some or all of the tools! A logical view may be to use one tool for the Enterprise Architecture Model and one Tool for the Enterprise Engineering Model. However, since there is (by definition) more detail in the Engineering Model it might be more logical to use multiple Tools at that level. It would also be logical to think that those tools may be aligned more around the Disciplines and Roles used rather than levels themselves. While these lines may be moved for individual Enterprises based on their needs and maturity, it should be noted that what is of more importance is how the interfaces between these tools work as shown by the red boxes. It is critically important that all the tools used for Enterprise Transformation work together cohesively as a whole. No information is an island, and although different roles may concentrate on working on one particular type of information and use one particular tool, what is crucially important (because Context is Kingâ&#x201E;˘) is that people can see their information of interest, in the context of other information.

152 - Items

KEYPOINT:

Use POET to plan how all the tools

you use, integrate and work together.

ADOPTION:

Enterprise Architect: Make sure the tools used within your

Transformation capability are

OO integrated.

Questions to Ponder

♦ Do the Tools your Enterprise uses for Transformation, fit together and integrate

Items

♦ ♦ ♦ ♦ ♦ ♦

properly? If not, what problems does this create? What impact do those problems have, and how can you solve those problems? Which tools do you currently use? What domains (Structural/Transformational) do they cover? What disciplines utilise them? Are they adequate?

Items - 153 Integr ation

PR Each physical Tool tends to consist of two parts:

However many tools an Enterprise uses, an overriding principle should be born in mind, which is that people working within each phase need access to information not only in the level associated with that phase, but also with the information in the levels preceding and following phases. Integration of tools is therefore key - not only within a phase but also across phases. To enable this (and to minimise integration overheads and associated synchronisation problems) it is usually advisable to minimise the number of physical tools used in any one domain (Option A), however, the number of physical tools that an Enterprise decides to buy is a personal choice and based on many things, not least the tools they already have and the tools available in the market. If two tools are used (Option B) the integration is probably manageable, however more than two tools (Option C) can cause an integration and maintenance nightmare. If more that 2 tools are utilised a possible solution would be for multiple tools to all sit upon and integrate with one common repository (Option D), or if that is not possible for multiple tools with their own repositories to integrate with one master repository (Option E). Options D and E would also be beneficial for integrating all tools in the entire Transformation domain, however, these options are only possible if the Tool Vendors had had the foresight to think of them and had made the necessary investment to provide that functionality to do so - particularly for plate D. The problem of these “interfaces” are largely of a technical nature because tool vendors need to come together to agree on a method of allowing their tools to interact. Open Service for

Items

♦ A Repository that stores the information. ♦ A Tool which allows a user and other tools to manipulate that repository.

154 - Items

Items

Lifecycle Collaboration (OSLC) is an open community trying to define a set of specifications that enable integration of Transformation tools. Its initial focus is around software development but the specifications should be (fingers crossed!) equally applicable to any set of tools that need to work together cooperatively. Their primary intention is a simple one to make life easier for tools users and tools vendors, by making it easier for tools to work together. www.open-services.net

Items - 155

KEYPOINT:

All Transformation Tools need to be integrated to work together.

ADOPTION:

Enterprise Architect: Minimise the number of Tool interfaces.

♦ ♦ ♦ ♦ ♦ ♦ ♦

Which of your Transformation tools exchange or reference data used in other tools? Which Option (A-E) best describes your approach to the integration of tools? How is data in different tools kept synchronised? How can data in one tool be related to information in another tool Are there any issues or problems? What will you do to alleviate or solve them? Do you have a coherent and holistic strategy for which tools you use where and for what purpose?

Items

Questions to Ponder

156 - Items Cover age

PR Items

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

Items - 157

KEYPOINT:

Any EA Tool must integrate with other tools.

ADOPTION:

EA Project Team: Make sure your EA

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

information and that it integrates with other related tools.

♦ ♦ ♦ ♦ ♦

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

Items

Questions to Ponder

158 - Items Vendor s

PR Here we present all the EA Modelling tool vendors presently in the marketplace. Detailed information about the companies, their tools and licensing can be found in the PEAF Toolkit.

Items

Items - 159

KEYPOINT:

Many of the EA Tool Vendors, are not EA Tool Vendors.

ADOPTION:

EA Project Team: Consider, all the EA Tool Vendors in the market.

Questions to Ponder

Items

♦ Which Tool Vendors have you heard about? ♦ Which Tool Vendors tools have you used? ♦ What is your view of each of these Tool Vendors?

160 - Items Evaluation Requir ements

PR Here we detail a set of Pragmatic requirements for EA Tool selection. These are the most important requirements that need to be met, not an exhaustive list and come under these general headings. ##END##

A. Importing

Items

Can .CSV be used as a source?

Can .XML be used as a source?

Can .XLS be used as a source?

Can .MDB be used as a source?

Can relationships be imported as a list of the form <primary key1>,<primary key 2>,<attributes>?

Can relationships be imported as a grid where <primary key1> is listed across the top, <primary key2> is listed down the side, with an X in intersecting cells indicating the presence of a relationship?

Can .VSD be used as a source?

Can the objects be mapped to entities in the Meta-model and imported as such?

Can the connectors be mapped to relationships in the Meta-model and imported as such?

Is the diagram imported the same type as a diagram created within the tool?

Can the user import the data without the display properties of the graphics?

Items - 161 Can the user import the data with the display properties of the graphics?

Can the diagram produced be manipulated in the same way as a diagram that was drawn natively in the tool?

Is it possible to perform round-trip engineering via Visio?

Can Hierarchical Information be imported of the form <name>,<parent name> where <parent name>'s are previously defined <names>s?

Is this hierarchical information imported as entities linked by relationships?

Can other types of relationships supported be imported?

Can the tool handle conflicts?

Is it possible to configure rules to resolve conflicting information being imported from multiple sources?

Are there any tools/functionality to enable the synchronisation of entities and/or relationships stored outside the tool (e.g. CMDBs, portfolio management tools, change management tools)?

Items

162 - Items B. Exporting 1

Can .CSV be used as a target?

PR 2

Can .XML be used as a target?

Can .XLS be used as a target?

Can .MDB be used as a target?

Can relationships be exported as a list of the form <primary key1>,<primary key 2>,<attributes>?

Can relationships be exported as a grid where <primary key1> is listed across the top, <primary key2> is listed down the side, with an X in intersecting cells indicating the presence of a relationship?

Can .VSD be used as a target?

Can Hierarchical Information be exported of the form <name>,<parent name> where <parent name>s are previously defined <names>s?

Can other types of relationships supported be exported?

C. Relationships

Are relationships a fundamental type?

Are there fundamental types such as Hierarchy, Composition etc that a relationship can be based on?

Are all relationships stored as relationship entities linked to the related entities rather than attributes on entities?

Can I view and manipulate relationships visually by creating, deleting and moving lines between entities?

Can I use a matrix to view, create, delete and modify all non-hierarchical relationships?

Items

D. User Interface / Ease of use

Can I use a combination of the thumbwheel and the shift and ctrl keys (or equivalent) to easily pan and zoom diagrams (ala Visio)?

Can I drag/create graphics (representing entities) onto the diagram and then immediately be able to move things without having to change the drawing tool into a select tool?

Do open windows auto update when changes in other windows are made?

Is there a fully featured (Diagrams, entities, properties, fully hyperlinked) "viewer" interface for consumers of the model to use to navigate the model that allows viewing but not updating?

Items - 163 E. Diagrams / Views 1

Can I define the graphic used to display entities on diagrams?

Can I define the appearance (font, colour, size, alignment) of the properties displayed on the graphic?

Can I fully define the location of each attribute on the graphic?

Can the displayed properties be conditionally set (e.g. make the text colour red if a property of the associated entity equals a value)?

Can I define the graphic used to display relationships on diagrams?

Can I define the properties to be displayed on the graphic?

Can I define the appearance (font, colour, size, alignment) of the properties displayed on the graphic?

Can I fully define the location of each attribute on the graphic?

Can the displayed properties be conditionally set (e.g. make the text colour red if a property of the associated entity equals a value)?

Can I define different properties to be displayed on the beginning and ends of the graphic?

Can I define different properties to be displayed on the middle of the graphic?

Are all predefined entities provided with associated graphics?

Are all predefined relationships provided with associated graphics?

Can I create fully configurable custom diagrams (e. g. Management Dashboard View)?

Can I model processes using BPMN (e.g. Activities, processes)?

Can I model Data using logical ER diagrams (e.g. to model business data models)?

Can I create a diagram, drop any number of entities of any number of types at any level of abstraction, and have the tool draw in the relationships?

Can I use that diagram to change the relationships and entities?

Can I automatically navigate the data at varying levels of detail where the relationships of those lower levels are summarised and displayed as relationships as there are expanded or collapsed?

Can I assign entities to a "group" and then have the tool draw a bounding polygon showing the entities in the group and those without? Can I do multiple groups?

Do I have access to various tools to help me layout diagrams (e.g. arrange as Hierarchy, horizontally, verticals, block, circle, star)?

Do diagrams automatically update when the underlying data changes (I.e. text changes, addition or removal of entities and relationships)?

Can I use "layers" on diagrams?

Are there built-in views/dashboards/reports/questions available for the Business?

Can I define the properties to be displayed on the graphic?

Items

PR 2

164 - Items (see “Expected Views & Expected Dashboards” Sections) 26

Are there built-in views/dashboards/reports/questions available for the Finance dept? (see “Expected Views & Expected Dashboards” Sections)

Are there built-in views/dashboards/reports/questions available for the IT dept? (see “Expected Views & Expected Dashboards” Sections)

Are there built-in views/dashboards/reports/questions available for Suppliers? (see “Expected Views & Expected Dashboards” Sections)

Are there built-in views/dashboards/reports/questions available Customers? (see “Expected Views & Expected Dashboards” Sections)

Are there built-in views/dashboards/reports/questions available for Governance? (e.g. Compliance to principles, polices, etc)

for

B2B

F. Impact Analysis 1

Can I perform impact analysis by navigating a hierarchical textual representation of the model?

Can I perform impact analysis by navigating a hierarchical graphical representation of the model?

Is it possible to view the deltas between different versions of a model?

Items

Items - 165 G. Meta-model Does your Meta-model cover Strategy (e.g. Vision:Goals:Objectives, Mission:Strategies:Tactics, Policies:Rules, etc)? List the entities provided.

Does your Meta-model cover Assessment Architecture (e.g. Trends, Influences, SWOT's, etc)? List the entities provided.

Does your Meta-model cover Business Architecture (e.g. Products, Sectors, Segments, Services, Customers, Enterprise, Locations, Activities, Processes, etc)? List the entities provided.

Does your Meta-model cover Information/Data Architecture (e.g. Business Data Model, Logical Data Model, etc)? List the entities provided.

Does your Meta-model cover Technology Architecture (e.g. Services, Applications, Datastores, Databases, Technologies, Devices, etc)? List the entities provided.

Does your Meta-model cover Governance (e.g. Principles, Policies, Waivers, etc)? List the entities provided.

Do you provide an easily navigable Meta-model documentation consisting of a high level view with the ability to drill down?

Can I change the Meta-model visually?

Can I add and remove new entities?

Can I add and remove new relationships?

Can I add and remove attributes to existing and user defined entities?

Can I add and remove attributes to existing and user defined relationships?

Is the Meta-model totally flexible or are there limitations? (If so what are they?)

Can attributes be simple (e.g. text, number, list, date, money)?

Can attributes have rules associated (e.g. limit number of chars, limit numbers/dates to a defined range)?

Can attributes be complex (e.g. an attribute consisting of a group of attributes)?

Can I automatically navigate the model using TOGAF as a navigation structure?

Can I automatically navigate the model using Zachman as a navigation structure?

Can I define new navigation structures?

H. Target and Intermediate Models

Does the model fundamentally understand and support the concepts of target and intermediate models and the special relationships between them?

Does the model offer specific functionality for the definition, management and analysis of target and intermediate models and the gaps between them?

Items

166 - Items I. Model Management 1

Are all changes to the model subject to version control and management?

PR 2

Is it possible to "check out" whole models?

Is it possible to "check out" partial models?

Does it allow branching and merging of entities, relationships and diagrams?

Is there any workflow built in to allow the acceptance or rejection of changes to the model through a lifecycle (e.g. discussion, draft, authorised, published)?

Can I load inconsistent and/or missing attributes into the model and then use the tool to manage the consolidation and completion of the data?

Can I generate syntax, semantic and consistency, and completeness reports?

J. Supplementary Questions

Does the tool possess Application Portfolio Management capability or do you have another tool that does?

Do you have any out of the box integrations with 3rd part APM tools?

Does the tool possess Configuration Management Database (CMDB) capability or do you have another tool that does?

Do you have any out of the box integrations with 3rd party CMDB tools?

Does the tool possess Governance capability or do you have another tool that does?

Do you have any out of the box integrations with 3rd party Governance tools?

Does the tool possess Business Process Analysis and Simulation capability or do you have another tool that does?

Do you have any out of the box integrations with 3rd party BP Analysis and Simulation tools?

Does the tool possess Business Intelligence (BI) capability or do you have another tool that does?

Do you have any out of the box integrations with 3rd party BI tools?

List the EA Frameworks supported and describe how they are supported.

Describe/Illustrate the architecture of your tool including the use of any 3rd party software.

List the modelling notations supported and indicate any 3rd part products used to provide the functionality.

List any standard queries/reports (textual or diagrammatic - please indicate which for each).

Items

Items - 167 K. Expected Views (Does the tool provide answers to these questions)

What fundamental architectures are being used and numbers of each type?

What is the split between COTS and bespoke applications?

How many FTE's are requirement to support an application?

What applications support a business function?

What applications are not covered by a DR plan?

What applications or technologies are candidates for rationalisation

What applications are the most costly (value based)

What applications are the most important to the business

What are the transition plans for an application / process / etc

What are the recurring costs of an application

How critical is an application to a business process

How many users depend on an application

What is the usage profile/roadmap for an application

What skills are required to support an application

Which applications have the greatest impact on the business

Who are the business and technical owners for an application

Who are the owners of applications with no DR plans

Who is using an application

What are the average costs for applications that support a particular business process?

Items

PR 1

168 - Items L. Expected Dashboards (Does the tool provide these dashboards)

Executive Dashboard: Project Portfolio Impact Executive Summary

Executive Dashboard: Demands Executive Summary

Executive Dashboard: Portfolio Complexity Summary

Executive Dashboard: Goals and Strategy Executive Summary

Executive Dashboard: Spend Alignment Executive Summary

Executive Dashboard: Revenue Views of customers, segments, sectors, products, etc

Business And IT Executives: Business Demand

Business And IT Executives: Projects alignment to strategies

Business And IT Executives: Spend related to business need

Business And IT Executives: Programmes and projects roadmap

Programme and Financial planners: Applications related to Business Capability

Programme and Financial planners: Enterprise Application Roadmap

Programme and Financial planners: Spend related to Business value

Enterprise architects: Analysis of interrelationships

Enterprise architects: Model Enterprise

Enterprise architects: Ensure data is complete and accurate and up to date

Enterprise architects: Define Future State

Enterprise architects: Plan State transitions

Enterprise architects: Principles and policies related to goals and objectives

IT: Understand technology roadmap

IT: Analysis of interrelationships

IT: Impact Analysis

IT: Manage risks

Items

Demonstrations

After short listing a set of Vendors/Tools by using the requirements defined in the previous section, it is important to receive demonstrations of each where a more qualitative assessment can be made. The aim of demonstrations is not so much to find out if a tool does or does not provide a particular function but more to determine how well functions are provided. There can be widely differing methods of particular functions provision. For example, one tool may be able to perform a function with one click of the mouse. Another tool performing the same function may require 10 button clicks.

Items - 169

The other point to consider is that because this assessment is qualitative it is also largely subjective. One person’s view of what “sub-optimal” means may be very different to what someone else’s view is. The criteria below is to be used for this qualitative assessment and is a measure of how well the functionality/capability is provided (Qualitative)

♦ Poor

♦ Good

♦ Excellent

♦ Outstanding

Provided for via a sub-optimal, indirect or unnecessarily convoluted way Provided for but has some limitations or usability issues that makes its use sub-optimal Provided for in a very good manner but wouldn't be called "Best in class". Some room for improvement Provided for in the best possible way. “Best in Class”. If you were to write it from scratch this is how the functionality would be provided

The following items are deemed most pertinent for demonstration.

A. Importing

Show Import a VSD + roundtrip if supported Show Conflicts and management/resolution

Describe How Integration with CMDB works

B. Exporting

Show Relationship export as a grid

C. Relationships

Show Creating/modifying/deleting relationships by editing a diagram

D. User Interface / Ease of use Show Pan and zoom

Show Viewer for freeform navigation of the model

Items

Show Relationship matrix editor

170 - Items E. Diagrams / Views Show Graphic designer including relationships (lines)

PR Show Custom views - e.g. dashboard Show

Drop entities, let tool show relationships - save, change entities does diagram auto-update. Navigate/display at higher levels of abstraction

Show Layout tools; hierarchy, star, block, align, etc. Show Built in Views/Dashboards

F. Impact Analysis

Show Impact analysis

Show Deltas between versions of a model

G. Meta-model Show

Meta-model structure; Strategy, Guidance, Business, Information, Technology, Governance

Show Meta-model navigation/discovery

Show Making changes also Types of complex sets/groups of data

Show Model mapping to Zachman, TOGAF, others

H. Target and Intermediate Models

Show Current, Target, Intermediate and tools around them

I. Model Management

Show Version control, management, check-in/out Describe Branching and Merging

Items

Show Workflow

Show Management of inconsistent/missing/invalid imported data

Show Syntax, semantic and consistency, and completeness reports

Items - 171 X. Additional considerations. XA - Tool Architecture

PR Show XA1. Single Object Table

Show XA2. 1st Order Relationships Show XA3. Heterogeneous Hierarchy Show XA4. Foreign Keys Relations Show XA5. Plain Text Encoding

Show XA6. Time as a Fundamental

XC - Tool Configuration and Maintenance Show XC1. Bulk Upload

Show XC2. Structured Upload Show XC3. Open ERD

Show XC4. Graphical Meta-Model Show XC5. Hybrid Metamodels

Show XC6. Flexible Notation Show XC7. Tool Integration

Show XC8. Concerns & Viewpoints XF - Tool Functionality

Show XF1. Meta-Data Inheritance

Show XF3. Explorer Drag And Drop Show XF4. Explicit Variants Show XF5. Analytic Charts

Show XF6. Quantitative Analytics

Show XF7. Catalogue Data Management Show XF8. Round Trip Engineering

Items

Show XF2. Dangling Relationships

172 - Items

KEYPOINT:

When evaluating EA modelling tools, use a good set of requirements.

ADOPTION:

EA Project Team: Use the Pragmatic EA Tool Requirements when reviewing EA Tools.

Questions to Ponder

♦ Do you agree with these high level requirement categories? ♦ If not, which ones would you add, change, remove? ♦ How would you rank them in terms of importance?

Items

Items - 173 Pr oces s

Items

PR F

Since the answer to most questions posed to a Tool Vendor are likely to be “Yes”, it is not a question as to whether a Tool Vendor can satisfy a requirement, it is more in terms How they can satisfy a requirement. For this reason, each Tool Vendor was asked to rate their tool against each of the Requirements using a set of categories. Out of the Box This is the best way a Tool Vendor can satisfy a requirement. This means that the functionality is built in and can be utilised with no changes at all. Associated costs and risks are zero because no changes are being made. Subsequent releases of the tool can be adopted with no impact. Configuration This is the second best way a Tool Vendor can satisfy a requirement. This means that the functionality is built in but requires some configuration to be used, usually through a specific user interface or via configuration files. Associated costs and risks are low because only simple “changes” are being made. Subsequent releases of the tool can be adopted with very little or no impact. Customisation This is the worst way a Tool Vendor can satisfy a requirement. This means that the functionality has to be specifically added to the tool by the Tool Vendor. Associated costs and risks are high because changes need to be designed, coded, tested and maintained. This can produce severe problems in adopting subsequent releases of the tool.

174 - Items

KEYPOINT:

Tools that satisfy requirements by Customisation rather than by

Configuration or Out-of-the-box, should be avoided.

ADOPTION:

EA Project Team: Ignore EA Tools

OO that satisfy requirements by Customisation.

Questions to Ponder

Items

♦ Do you agree with these high level evaluation categories? ♦ If not, which ones would you add, change, remove? ♦ How would you rank them in terms of importance?

Items - 175 Raw Scor es

PR Items

Here we see an overview of the vendor supplied scores against each of the requirements. The evaluation scores have been supplied by the vendors themselves. Pragmatic accepts no responsibility for the accuracy of the information presented. Accuracy and correctness of the information rests solely with the individual companies concerned. This section only contains summary information. The detailed evaluation scores and comments can be found in the Tool Evaluation Excel spreadsheet.

176 - Items

KEYPOINT:

Be aware that many Tool vendors can be very economical with the truth.

ADOPTION:

EA Project Team: Be very sceptical when talking to Tool Vendors.

Questions to Ponder

♦ If you already use an EA Modelling Tool, how does the tool you currently use fair? ♦ If you are not currently using and EA Modelling Tool, which Tool Vendors will you shortlist?

Items

Items - 177 Weighted Scor es

PR Items

Here we have applied a Pragmatic weighting to the base scores. Tools that can satisfy requirements out-of-the-box or just by configuration are much more favoured over those that require modification. If you do not agree with these weightings, you can choose your own using the PEAF Tool Vendor Evaluation Toolkit spreadsheet

178 - Items

KEYPOINT:

Weighting vendors to downgrade “customisation” answers can be useful.

Questions to Ponder

♦ Do you think this weighting criteria is fair? ♦ If not, what weighting criteria will you use?

Items

Items - 179 X-Requir ements

PR ♦ XA - Tool Architecture

How the tool is fundamentally architected and engineered. Why? Because if that’s not done right, it will cause massive problems for all functionality and all users.

♦ XC - Tool Configuration & Maintenance

How the tool is Setup and administered by those people who are responsible for setting up all the reusable things such as meta-models, notations, standard viewpoints etc. that everyone else will use.

♦ XF - Tool Functionality

Key functionality that must be present if the tool is to be used for Enterprise Architecture.

Items

The X-Requirements are fundamental core requirements, that Enterprises should consider applying to Tool Vendors, when evaluating EA Modelling Tools. These are the single most important features that, if not present, will seriously limit your use of a tool. The other detailed Tool Requirements documented elsewhere in PEAF are useful also, however, these much smaller set of X-Requirements can be used as critical gating criteria, to reduce a large number of Vendors down to a smaller set, for detailed evaluation. They are split into three distinct sections:

180 - Items ####

XA - Tool Architecture X-Requirements XA1. Single Object Table

There should be a single table of all objects (e.g. Objects, Elements or Components) with their type indicated via a foreign key to a unique list of types, as opposed to an individual table in the database for each object type (i.e. separate Process, Application, Department tables). Why?

Because without a single table for each object type, the underlying repository is completely rigid, and the inevitable configuring of existing objects for additional attributes or adding of new objects altogether is going to require some serious back-end customization. Not to mention the consequent business logic and presentation layer hacks that will be required. In some cases “spare” tables are provided or attribute “slots” but this is hardly configurable.

XA2. 1st Order Relationships

All relationships between the objects in the repository should be explicitly stored as a different collection of elements in their own right, as opposed to being only on the diagrams, or attributes on objects, or just some specific subset of objects). Why?

Items

Because without modelling relationships as 1st order entities, a tool fails as a real architecture tool (see IEEE 1471). These sorts of convoluted designs smack of being a kludged together. Most likely, relationships on the diagrams were an afterthought to be stored in the repository with some serious implications including the next few criteria.

XA3. Heterogeneous Hierarchy

The repository should use a heterogeneous hierarchy of objects (and relationships), as opposed to flat collections of objects with (for example) a ‘decomposes’ relationship between them or only homogenous hierarchies. Why?

Because with a single flat collection of each object (or relationship) type, none of the principles of information hiding and role-based access are available. Slightly better are approaches that allow homogenous hierarchies where at least objects can be decomposed natively into objects of the same type (e.g. Processes into sub-Processes). These approaches are legacy of ‘flatlanders’ who simply compose Meta-models as ‘boxes and lines’ without any use of heterogeneous composition/aggregation or ‘boxes within boxes’. Cars have four wheels, an engine, gearbox etc. … not just sub-Cars.

Items - 181 XA4. Foreign Keys Relations

The relationships between the objects / entities in the repository should be defined and stored in the repository, rather than defined and stored in program or SQL code. Why?

Because if the relationships are stored in the program or SQL code, this creates serious limitations on what relationships can and cannot be defined and if you want to change them, you would have to change program or SQL code rather than just the data in the repository.

XA5. Plain Text Encoding

The objects / entities / tables and relationships in the repository should be coded as decipherable plain text data, as opposed to being binary objects from some other proprietary format. Why?

Because the practice of “wrapping” a proprietary data model as binary objects or other coded data in order to become “SQL Server” or “Oracle” compliant severely reduces the openness of the customer’s data that is ultimately being stored there.

XA6. Time as a Fundamental

a) Allow any objects / entities and any relationships to exist in time., rather than just having a “time” attribute attached to them b) Allow different versions of architectures / scenarios c) Allow for relationships to exist between architectures / scenarios, rather than just storing different scenarios as separate repositories that cannot be related. Why?

Because EA Modelling tools are built to allow Enterprises to transform things over time. This mandates modelling the structure of the Enterprise at various points in time. It is therefore paramount to be able to model relationships between these different point-in-time models. If time has not been properly considered and designed in to the tool from the beginning (i.e. architected) you will face serious limitations when you come to create and maintain roadmaps and different scenarios - which, after all, is the whole point of an Enterprise Architecture.

Items

The repository should:

182 - Items ####

PR Items

Items - 183

XC - Tool Configuration and Maintenance XRequirements XC1. Bulk Upload

It should be possible for a user to bulk upload 1000’s of rows and columns of structured data to the repository in a single step from MS Excel, MS Access and/or MS SQL Server with the base product, as opposed to one-by-one copy-pasting data into forms or requiring professional services support. Why?

Because users may well assume this to be the case and then be surprised by a large cost required to either enter data by hand or to pay for professional services to do the work.

XC2. Structured Upload

Why?

It should be possible to bulk upload objects, relations and attributes all at the same time, as opposed to a single flat collection of an individual object type and their attributes at a time. Because, as POET teaches us, “The value is in the lines, not in the boxes”. If you can only upload lists of single entities at one time, there is very limited ability to easily build a connected repository.

Documentation of the complete Entity-Relationship-Diagram (ERD) / Object Model (OM) for the repository should be provided to clients on request, as opposed to being kept secret, and the relationships between the objects / entities / tables should be explicitly defined as relationships in the database technology being used, as opposed to being coded in application logic. It should be clear by looking at the datamodel utilised by the repository how all the tables are related. Why?

Because if the datamodel (which may or may not include its relationships) is either non-existent or hidden, this profoundly inhibits users from running reports using other external tools of their own without requiring potentially costly professional services fees to achieve it.

Items

XC3. Open ERD

184 - Items XC4. Graphical Meta-Model

It should be possible to use a graphical and navigable representation of the Meta-model(s), as opposed to creating (and maintaining) a dummy set of entities based on that Meta-model or by editing cryptic configuration files. Why?

Because understanding and maintaining the Meta-model(s) used, is crucial for the correct and streamlined management of an EA Modelling Tool. This can be highly complex, and attempting to do it purely by editing “configuration” text, is fraught with difficulty.

XC5. Hybrid Metamodels

It should be possible to concurrently utilise and relate multiple Meta-model implementations out-of-the-box. Why?

Because the Meta-model(s) used by any Enterprise will generally be a mixture of Meta-models rather than just one. e.g. P3O + BPMN + Archimate + PEAF + BMM. Without this ability, you will find it extremely difficult to create “your” Meta-model(s) and even more difficult to utilise them effectively.

XC6. Flexible Notation

It should be possible to change the iconography of the Explorer / Object Browser and shapes used for the objects themselves on the diagrams, through simple drag-and-drop operations in the standard UI, as opposed to hacking code or some convoluted editing of a cryptic configuration file.

Items

Why?

Because a lot of the frameworks don’t have agreed notations so it is essential that the appropriately trained / skilled users can easily reconfigure the lookand-feel of the views for maximum business impact without needing vendor support or ever writing a line of code of customization.

Items - 185 XC7. Tool Integration

The tool should provide the ability to seamlessly integrate with other tools, and be able to synchronise precisely with the data they contain, without any need for translation or transformation of their data, such that changes made in the EA Modelling tool are pushed out to other tools, and changes made in other tools are incorporated back into the EA Modelling tool, all in a controlled way and without any loss of data. Why?

Because no tool exists in a void. The tools you choose must cooperate together into a coherent whole. If your EA Modelling Tool cannot integrate and synchronise faithfully and easily with data in other tools (without the need for any transformation of the data) all you will do is create another island of data, with all the risks and costs related to duplication of data, and those data becoming out of date and therefore useless.

XC8. Concerns & Viewpoints

In addition to the obvious requirement for a Metamodel (and the requirement for Hybrid Meta-models) an EA Modelling tool should also allow for the definition of:

Because as POET teaches us â&#x20AC;&#x153;There is no reason to model anything unless it will be used to answer a question.â&#x20AC;? In order to do that in a reasonably coherent way, the tool also needs to define who wants the question answered, what are the questions that require an answer and how that question will be answered. ####

Items

Why?

a) Users - Who will use the tool to answer questions? b) Concerns - What questions do those stakeholders require answers to? c) Viewpoints - How those questions are answered?

186 - Items

XF - Tool Functionality X-Requirements

PR XF1. Meta-Data Inheritance

It should be possible to define meta-data on a general entity in the repository, that can be inherited and then extended by local object or relationship instances, as opposed to simply having a relationship type called Generalizes or Generalized By (or Specializes / Specialized By or Realizes / Realized By etc) between two existing objects. Why?

Because a lot of tools provide a ‘flat’ repository with tables of objects (and possibly foreign-key relationships between them). This approach ignores the concepts of inheritance and meta-data. Invariably these tools are then kludged to provide a specific relationship type called ‘Generalizes’ or ‘Realizes’ between two existing objects. This approach does not exploit the benefits of inheritance including efficiency, meta-data re-use and specialization.

XF2. Dangling Relationships

Why?

Items

It should be possible to detach the end of a relationship from an object on a diagram and leave it unattached (i.e. ‘hanging in space’) and then re-attach the same end of the relationship to a different object. Because if a tool merely has a drawing SDK on top of a RDB it is probable that only some of the drawing features are ‘linked’ to the RDB. For example, to allow there to be a detached relationship at some point in time on a diagram (as a minimum) the relationships need to be explicitly contained in the repository (not just an ‘attribute’ of the objects) and there needs to be tight coupling between the diagrams and the repository. If a user cannot detach then re-attach relationships, when you inevitably want to change the attachments, the user will have to delete and recreate them, losing all the information associated with the relationship, and its occurrence in any other views.

XF3. Explorer Drag And Drop

It should be possible (using the “Explorer” or “Object Browser”) to re-order items in any way using simple drag-and-drop, as opposed to, for example, just a forced sorting of alphabetical ‘A-Z’ or ‘Z-A’.

Why?

Because there is often a logical ordering to the group of objects that isn’t alphabetical, e.g. Business - Information - Application - Technology. If the sorting is forced, then you end up prefixing all the objects with a numerical index to control the sort order.

Items - 187 XF4. Explicit Variants

It should be possible to explicitly model variants / scenarios / what-ifs / options etc as separate collections of (the same baseline) objects relationships and views, as opposed to just ‘tagging’ the one set of objects / relationships with flags saying which variant they are in. Why?

Because just ‘tagging’ objects seriously limits the amount of difference / gap analysis that is possible, and more or less negates the ability to do trade-off analysis at all.

XF5. Analytic Charts

It should be possible for the tool to produce standard charts like pies, lines, bars etc. Why?

Because if the tool can’t produce simple charts, it may struggle to produce other more complicated diagrams or analytics.

XF6. Quantitative Analytics

Why?

Because the purpose of an EA Modelling tool is to model various Structural states of an Enterprise and to quantitatively analyse the differences between them, for the purposes of: a) Roadmapping - Analysing differences between states at different points in time - for the purpose of creating a roadmap to move from one state to another, and b) Options - Analysing differences between states at the same point in time - for the purpose of selecting which one is more appropriate.

Items

The tool should allow for quantitative ways of analysing the information in the repository, not only simple analytics such as “how many”, but more detailed analysis for KPIs from the Financial (e.g. Total Cost of Ownership (TCO), ROI, NPV) to the Technical (e.g. Resource Utilization, Response Times, Availabilities) to the environmental (e.g. Carbon Footprint, Resource Re-use, Sustainability, Heat & Power Consumption).

188 - Items XF7. Catalogue Data Management

It should be possible to manage a catalogue / list of elements (e.g. objects, entities, relationships) and their properties natively in the tool, as a tabular list of data through the standard UI, as opposed to hacking into or querying the back-end repository / database (assuming itâ&#x20AC;&#x2122;s possible to understand). Why?

Because tabular data entry / management is fundamental to efficient portfolio management of data around objects / relations, and simply providing a single form / screen per object and relationship for data editing, is going to guarantee data obsolescence very quickly.

XF8. Round Trip Engineering

It should be possible to export information into Excel and Visio, allow someone to edit that data, and then reimport the changes they made back into the repository. Why?

Items

Because Excel and Visio are widely used applications that most people are familiar with and most Enterprises already own. To be able to lever this existing investment and to give people information in a format they are familiar with allows many more people to be involved with the creation, maintenance and consumption of the information in the repository.

Items - 189

KEYPOINT:

X-Requirements are the key when assessing EA Modelling Tools.

ADOPTION:

EA Project Team: Use the X-

Requirements as the key gating

criteria when assessing EA Modelling

OO Tools.

♦ Do you agree with these high level X Requirements? ♦ If not, which ones would you add, change, remove? ♦ How would you weight them in terms of importance?

Items

Questions to Ponder

Adoption - 191

PR ADO PTIO N

Adoption

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

192 - Adoption

KEYPOINT:

The Adoption section of PEAF

defines 'HOW' it should be adopted and used.

Questions to Ponder

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

Adoption

Adoption - 193 Step 5 Actions Select an EA Modelling To ol

PR This process is concerned with the procurement of an EA modelling tool. It should be noted that any information within the Enterprise is not an island and therefore (as POET prescribes) due consideration must be given to how the EA tool fits in with the landscape of other tools utilised by the Enterprise (e.g. Portfolio Planning and Management, Risk Management, Configuration Management and Change Management, etc). Preparation

RFI

♦ ♦ ♦ ♦ ♦

Send RFI to Tool Vendors. Evaluate responses and shortlist 5-6 Tool Vendors. Organise and Attend Tool demonstrations. Evaluate demonstrations and select a “Final 3”. Create the RFP.

RFP

Source

♦ Send out RFP and arrange Proof of Concepts. ♦ Evaluate responses, perform commercial negotiations and select Vendor. ♦ Plan the training, buy the licenses and order the hardware.

Adoption

♦ Determine how this new Tool will fit into the wider Transformation Tool family. ♦ Using PEAF, create a list of all EA Tool Vendors to be considered. ♦ Using PEAF, create a set of EA Tool Requirements.

194 - Adoption

PR Adoption

Adoption - 195

KEYPOINT:

Without a proper EA modelling tool, we won't be able to do any sensible modelling.

ADOPTION:

EA Project Team: Select an EA

modelling tool by Proof-of-Concept

OO comparisons.

Questions to Ponder

♦ Does this process match your Enterprises process for Selecting and EA Modelling Tool?

Adoption

♦ If not, is their anything missing? ♦ How would you define this process?

196 - Adoption Step 6 Actions Rollout EA Modelling Tool

PR Installation

♦ The EA Modelling tool’s hardware and software are installed and commissioned. Training

♦ Appropriate training is performed.

Adoption

Adoption - 197

KEYPOINT:

Without a proper EA modelling tool, we won't be able to do any sensible modelling.

ADOPTION:

EA Project Team: Make sure

Modelling Training is part of rolling

OO out the EA modelling tool.

Questions to Ponder

♦ Does this process match your Enterprises process for Rolling Out the EA Modelling Tool?

Adoption

♦ If not, is their anything missing? ♦ How would you define this process?

198 - Adoption Guidance

PR Adoption

Adoption - 199

KEYPOINT:

The Guidance section of the

Adoption section of PEAF defines

what is used to guide people in their decision making.

ADOPTION:

C-Suite: Follow the Guidance in the

Adoption

Adoption Section of PEAF

200 - Adoption Tools Types

PR Adoption

â&#x20AC;&#x153;Tools are expensive and cost a lot to procure and maintain, canâ&#x20AC;&#x2122;t I just use Excel and Visio?â&#x20AC;? This is a common question. The answer is - it depends! Our Enterprise today is more complex than it has ever been, both in terms of the Enterprise MAGIC Structure and the Enterprise Context it exists within (suppliers, customer, outsourcers, media, legislation, competitors, etc, etc). In addition we are constantly changing, Transforming either 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 thing you are changing and how changing one part may affect other parts in potentially unwanted or surprising ways. Therefore, in this environment of constant change and complexity it is important for us 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 people involved in Strategising, Roadmapping and Project Governance, can see how that may affect other parts. In order for us 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.

Adoption - 201

Whilst initially a custom EA tool may not be required, there comes a time where the amount of time it takes us to maintain the information increases to unacceptable levels and our ability to use the information decreases to unacceptable levels. Most Enterprises have already reached (and gone past!) this tipping point There are 3 basic types of tools that we could use with various pros and cons: Visio + Excel This entails using Visio diagrams and separate Excel spreadsheets with no linkage between them.

♦ In terms of Training Requirements - there are none, as most people already know

how to use Visio and Excel, and if some finer points are not known, there is a huge amount of free resources on the internet. ♦ In terms of managing the consistency of entity information between Visio and Excel the maintenance is purely manual. Diagrams have to be drawn manually and changing something in one application means a manual change needs to be made in the other. ♦ In terms of managing the consistency of relationship information between Visio and Excel - the maintenance is purely manual. ♦ In terms of cost – they are minimal as most Enterprises already have Visio and Excel licenses, and if more need to be acquired the costs are very low.

Visio + Database This entails using Visio diagrams linked to a separate Database (SQL Server, Access, Excel).

♦ In terms of Training Requirements - some maybe needed around Database and Visio

data linkage and around the use of DataGraphics. ♦ In terms of managing the consistency of entity information between Visio and Excel the maintenance is automatic. ♦ In terms of managing the consistency of relationship information between Visio and a Database - the maintenance is purely manual. ♦ In terms of cost – they are small as most Enterprises already have Visio and Excel and Access licenses, although they may need to be upgraded. Custom tool This entails using a custom EA Modelling Tool.

is being used effectively and efficiently.

♦ In terms of managing the consistency of entity information – this is automatic. ♦ In terms of managing the consistency of relationship information – this is automatic. ♦ In terms of cost – Medium to high. Possible initial cost of $40k+, with subsequent

costs dependent upon the size of the Enterprise and the number of users.

Adoption

♦ In terms of Training Requirements – extensive training is required to ensure the tool

202 - Adoption

KEYPOINT:

Be aware of the pros, cons and

implications of using a Visio/Excel or a Visio/DB or a Custom Tool.

Questions to Ponder

♦ Which of these three types does or has your Enterprise used? ♦ What were the pros and cons of them?

Adoption

Adoption - 203 Is s ues A bility to U se In forma tion

Adoption

PR F

How easy it is to use the information in a modelling tool is very important and dependent upon the complexity and volume of the information. Here we compare how easy it is to use the information in the model as its complexity and volume increases. While complexity and volume is low, the ability to use the information is easier for the Visio based approaches.. The Custom Tool is slightly lower due to the extra complexities of its user interface and the functions available. This is one of the reasons why many Enterprises utilise a Visio based approach. The problem is that very quickly the Visio based approaches become unusable. Visio/Excel As the complexity and volume of information increases, the ability to use that information quickly gets worse and worse. Very quickly a point is reached where it is impossible to continue to use the information. Visio/DB As with Visio/Excel the ability to use the information reduces to zero quite quickly although the decline is slightly less severe due to the connection with a structured database providing slightly better use. Custom Tool As the complexity and volume of information increases, the ability to use the information increases due to more functionality being used such as multi person access and data integration, presentation and dissemination features.

204 - Adoption

KEYPOINT:

As the complexity and volume of

information grows, the ability to use the information can quickly become impossible unless a custom EA modelling tool is used.

Questions to Ponder

♦ How easily can you currently use the information in your EA Modelling Tool? ♦ What is the current level of complexity/volume of information it contains? ♦ What will the level of complexity/volume of information be in 1 year? 2 years? 5 years? ♦ How will the ease of using the information change over time?

Adoption

Adoption - 205 Effort to Mai ntai n Inf ormati on

Adoption

PR F

How easy it is to maintain models in a modelling tool is very important and dependent upon the complexity and volume of the information. Here we compare how much effort it takes to maintain the information in the model as its complexity and volume increases. While complexity and volume is low, the effort to maintain the information is generally low but disproportionally large for a Custom Tool due to the user interface and the conformity it enforces. Visio/Excel As the complexity and volume of information increases, the effort to maintain the information quickly grows exponentially to impossible levels due to the effort to keep the drawings in Visio and the data in Excel in sync, the difficulty in maintaining the relationships between the differing Domains, and the consistency of the data. Visio/DB As with Visio/Excel the effort to maintain the information quickly becomes impossible although the inevitable is slightly delayed due to the linkages between drawings and the database being automatic. Custom Tool As the complexity and volume of information increases, the features of referential integrity, linked drawings, multi-user access and dissemination of information keeps the effort to maintain the information at a manageable level.

206 - Adoption

KEYPOINT:

As the complexity and volume of information grows, the effort to maintain it can quickly become impossible unless a custom EA modelling tool is used.

Questions to Ponder

♦ How easily can you currently maintain the information in your EA Modelling Tool? ♦ What is the current level of complexity/volume of information it contains? ♦ What will the level of complexity/volume of information be in 1 year? 2 years? 5 years? ♦ How will the effort required to maintain the information change over time?

Adoption

Adoption - 207 Fundamentals

PR There are essentially three fundamental types of data we need to maintain and manage in an EA tool:

♦ Entities - These are the “things” that we gather information about such as Objectives, Business processes, Applications, Goals, Locations, Departments, Databases. ♦ Relationships - There are the “linkages” between the entities such as relating Business Processes to Departments or applications ♦ Views - These are the illustrations of one or more Entities and one or more Relationships drawn in a particular kind of notation. Views can also be assembled into dashboards. Note that a diagram could be pictorial, tabular or text based. “The value is in the lines, not the boxes.”

While Entities and Views are very important, it is the Relationships that provide us the real value and power, and it is the Relationships that are the primary reason for us adopting a tool. Without relationships, all we have is lists. People can cope with a small number of Relationships between a small number for Entities but the human brain reaches its limit at maybe three Entities and 5 Relationships. Anything more than that and you just cannot keep it in your brain. With literally thousands of relationships, our brains need help! A Tool will allow us to keep all these relationships and give us the ability to surf through them depending on the task at hand. A kind of Just-In-Time-Intelligence.

Adoption

- Kevin Smith

208 - Adoption

KEYPOINT:

Modelling tools should be architected and built on 4 fundamentals: 1) Entities. 2) Relationships. 3 Properties. 4) Views.

ADOPTION:

EA Project Team: Favour modelling

OO tools that are architected and built on 4 fundamentals: 1) Entities. 2)

Relationships. 3 Properties. 4) Views.

Questions to Ponder

♦ Which models does your Enterprise have? ♦ Can you indicate on a few, those things that are Entities, Relationships, Properties

Adoption

and Views? ♦ How do you determine if something is a View or an Entity? ♦ How do you determine if something is a Property or a Relationship?

Adoption - 209 Can I us e my CMDB?

PR Adoption

Some people may believe that we already have all the information for an EA Model already in our Configuration Management Database (CMDB). After all, it contains lots of information about applications, databases, etc. However, although related and linked, these two repositories of information are different in many ways. In order for us to realise why using our CMDB is not a good idea - it is important to understand how an EA Model relates to our CMDB. Here we see a comparison of various fundamental aspects.

210 - Adoption

KEYPOINT:

You cannot use your CMDB as you EA modelling tool because their purpose and content are totally different.

Questions to Ponder

♦ Are there people in your Enterprise that think a CMDB can double up as an EA Model?

Adoption

♦ Can you think of any more differences between an EA Model vs a CMDB?

Adoption - 211 Conte nt

PR In terms of content, our CMDB only contains technical information about the current state of our Enterprise. While our EA Model would need to contain information about the current state of our IT our EA model also needs to contain:

♦ The target and intermediate states of our IT (but at higher levels of abstraction). ♦ The target and intermediate states of our Business information (Methods, Artefacts

Adoption

and Culture). ♦ The Strategic information required to support and drive Roadmapping.

212 - Adoption

KEYPOINT:

CMDBs Only contain a subset of

information you need to work with in an EA modelling tool.

Questions to Ponder

♦ Do you integrate Current Technical Data from your CMDB into your EA Model? ♦ What other things are in your EA Model that are not in your CMDB?

Adoption

Adoption - 213 Enti ties

PR Adoption

If we then consider only the technical content, it can be seen that although there are many entities stored in our CMDB, only some of them would be required in our EA Model. E.g. our CMDB contain entities relating to network switches but our EA Model would not. In addition our EA Model will need to contain more entities that are sourced from other places. E.g. Logical Applications.

214 - Adoption

KEYPOINT:

CMDBs Only contain a subset of

Current Technical information you need to work with in an EA modelling tool.

Questions to Ponder

Adoption

♦ Do you integrate all Entities from your CMDB into your EA Model? ♦ What Entities are in your EA Model that are not in your CMDB? ♦ What Entities are in your CMDB that are not in your EA Model?

Adoption - 215 A ttributes

PR Adoption

If we then consider only one of the entities that are shared between our EA Model and our CMDB, it can be seen that although there are many attributes (columns) stored in our CMDB, only some of them would be required in our EA Model. E.g. our CMDB contains attributes relating to the IP addresses of servers but our EA Model would not. Also, although there are many records (rows) stored in our CMDB, only some of them would be required in our EA Model. E.g. our CMDB contains records relating to all the applications in use but our EA Model would only contain records relating to the most important applications. In addition our EA Model will need to contain more attributes that are sourced from other places. E.g. The cost of an application.

216 - Adoption

KEYPOINT:

CMDBs Only contain a subset of

Current Technical Attributes you need to work with in an EA modelling tool.

Questions to Ponder

♦ Do you integrate all Attributes, from all Entities from your CMDB, into your EA Model?

Adoption

♦ What Properties are in your EA Model that are not in your CMDB? ♦ What Properties are in your CMDB that are not in your EA Model?

Appendix - 217

PR APPE NDIX

Appendix

218 - Appendix

KEYPOINT:

The Appendix section contains

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

OO F

Appendix

Appendix - 219 Backgr ound

PR Why Were They Created?

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

When Were They Created?

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

Where Did They Come From?

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

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

Appendix

♦ ♦ ♦ ♦

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

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

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

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

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

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

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

Appendix

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

Appendix - 221

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

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

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

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

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

Appendix

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

222 - Appendix

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

How Were They Created?

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

Appendix

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

Appendix - 223 What Was Used to Create Them?

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

♦ Architecture, Engineering, Logic.

Artefacts

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

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

Guidance

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

Items

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

Appendix

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

224 - Appendix

KEYPOINT:

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

cause 90% of all EA initiatives to fail.

Questions to Ponder

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

OO F

Appendix

Appendix - 225 The Author

Appendix

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

226 - Appendix

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

Appendix

Appendix - 227

Appendix

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

228 - Appendix

KEYPOINT:

Use people for the type of person

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

same, nothing would ever get done.

Questions to Ponder

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

♦ ♦ ♦ ♦

Appendix

Appendix - 229 Keypoints

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

The Introduction section of PF2

introduces the companies that are

Appendix

part of the Pragmatic Family.

230 - Appendix

Pragmatic 365 is a non-profit

research company. Pragmatic EC is a consulting company.

Most consultancies only want to sell you fish.

Pragmatic will teach you how to fish.

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

PEAF Certified training, provides

everything to enable you to adopt PEAF.

Appendix

Appendix - 231

PEAF Focused Workshops, allow you

to focus on specific areas.

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

P3 allows Enterprises to easily

produce and maintain their own

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

P3 is a component based authoring

Appendix

system.

232 - Appendix

The Language section of PEFF

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

Be ever vigilant of the hidden

confusion that language can create.

OO Everything is a System.

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

Appendix

Appendix - 233

There is no hidden connotation to

Pragmatic’s use of the word “Transformation”.

A Framework is an expression of

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

Artefacts, Guidance, Items, Culture)

and optionally information regarding its Adoption.

Theory is just as important as

Appendix

Practice

234 - Appendix

Colour

Information =

Understanding.

The Methods section of POET

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

The Disciplines are used to a greater or lesser extent in each phase.

The Disciplines form the Capability

Appendix

Model for the Transformation Capability of the Enterprise.

Appendix - 235

The 6 main disciplines are: Discovery, Requirements Management, Analysis & Design, Governance & Lobbying, Modelling and Decision Making.

1. Only model things to answer a

question. 2. Treat model population

as a Data Migration exercise. 3. Integrate/remove source data.

1. Only model things to answer a

question. 2. Treat model population as a Data Migration exercise. 3.

Appendix

Integrate/remove source data.

236 - Appendix

The Artefacts section of POET

defines 'WHAT' information is consumed and produced and 'WHEN'.

All levels of the Enterprise

Transformation model are used in all

phases.

Information from all levels are used in each phase.

Ensure that the Logical and Physical levels are populated over time as a

Appendix

deliverable of executing projects.

Appendix - 237

MAGIC defines Structural

information at points in time,

MAGMA defines Transformational information between them.

This is the complete map of information required for

Transformation to be executed in an

Effective, Efficient, Agile and Durable

Appendix

way.

238 - Appendix

Enterprise Strategy is the Business

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

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

OO There is no single metamodel, that

covers all the information required for Transformation.

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

Appendix

Appendix - 239

Enterprise Strategy is the Business

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

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

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

The Business Strategy and IT Strategy are inherently linked and cannot be

Appendix

thought of separately.

240 - Appendix

Specific Entities are required to

define the Business Motivation and Roadmap models

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

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

Specific Entities are required to define the Enterprise Context,

Appendix

Enterprise Capability and Operating models.

Appendix - 241

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

There are 4 types of Abstraction / Elaboration.

The relationships between things rises in a polynomial fashion.

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

Appendix

boxes.

242 - Appendix

Look for patterns in everything.

Use structured data for all structural

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

Over time, tools have grown and overlapped.

POET provides an Ontology that you can map Transformation Tools to.

Use POET to plan how all the tools

Appendix

you use, integrate and work together.

Appendix - 243

All Transformation Tools need to be

integrated to work together.

Any EA Tool must integrate with other tools.

Many of the EA Tool Vendors, are not EA Tool Vendors.

When evaluating EA modelling tools,

Appendix

use a good set of requirements.

244 - Appendix

Tools that satisfy requirements by

Customisation rather than by

Configuration or Out-of-the-box, should be avoided.

Be aware that many Tool vendors can be very economical with the

truth.

Weighting vendors to downgrade â&#x20AC;&#x153;customisationâ&#x20AC;? answers can be useful.

X-Requirements are the key when

Appendix

assessing EA Modelling Tools.

Appendix - 245

The Adoption section of PEAF

defines 'HOW' it should be adopted and used.

Without a proper EA modelling tool, we won't be able to do any sensible modelling.

The Guidance section of the

Adoption section of PEAF defines decision making.

Appendix

what is used to guide people in their

246 - Appendix

Be aware of the pros, cons and

implications of using a Visio/Excel or a Visio/DB or a Custom Tool.

As the complexity and volume of

information grows, the ability to use the information can quickly become

OO impossible unless a custom EA modelling tool is used.

As the complexity and volume of information grows, the effort to maintain it can quickly become impossible unless a custom EA modelling tool is used.

Appendix

Appendix - 247

Modelling tools should be architected

and built on 4 fundamentals: 1) Entities. 2) Relationships. 3 Properties. 4) Views.

You cannot use your CMDB as you EA modelling tool because their

purpose and content are totally different.

CMDBs Only contain a subset of

information you need to work with in

Appendix

an EA modelling tool.

248 - Appendix

CMDBs Only contain a subset of

Current Technical information you need to work with in an EA modelling tool.

CMDBs Only contain a subset of

Current Technical Attributes you

need to work with in an EA modelling tool.

The Appendix section contains

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

Appendix

Appendix - 249

Use POET and PEAF to make sure

you donâ&#x20AC;&#x2122;t make the mistakes that

cause 90% of all EA initiatives to fail.

Use people for the type of person

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

same, nothing would ever get done.

All Pragmatic books contain a Keypoint section.

www.Pragmatic365.org is the official

source for all PF2/POET/PEAF related

Appendix

materials, and is constantly evolving.

250 - Appendix

Pragmatic EA is a non-profit research

company, dedicated to developing Best Practice in relation to the

structure and transformation of Enterprises.

OO F

Appendix

Appendix - 251 Sour ces & Res our ces

PR F

Appendix

Here is listed various sources and references to things referred to in the Pragmatic Frameworks. You can always access the most up to date material online at www.Pragmatic365.org.

252 - Appendix

KEYPOINT:

www.Pragmatic365.org is the official

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

OO F

Appendix

Appendix - 253

Appendix

254 - Appendix

KEYPOINT:

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

structure and transformation of Enterprises.

OO F

Appendix

PR F

,!7IB9A8-ecefej!

Without proper preparation, every Enterprise is sailing full speed into their own perfect storm. If we are to sail safely in these unpredictable waters we must make preparations and plans to allow us to respond when treacherous conditions face us. For if we wait until that time before we act, it is unlikely that we will survive.

The unprepared ship will often catch more fish than other more well prepared ships not having to comply with safety regulations they are able to cast and wind in the nets much faster and therefore fill their holds faster. Holds also have more space due to the absence of emergency equipment which means more fish can be stored before having to return to port to offload them. It is not a case of "if" the ship will meet the storm. It is a case of “when”.

A Pragmatic Approach to Selection and Adoption

A Pragmatic Approach to EA Tool Selection and Adoption

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

1 02 v2

Most Enterprises invest huge amounts of time and effort in battling the storms. Very few spend any resources on preparing the ship. Instead, the call is “all hands on deck” to land the next catch and set the next net.

Enterprise Architecture Tools

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.

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

ISBN 978-1-908424-54-9

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

Kevin Lee Smith

The Author Kevin’s professional career in Enterprise Transformation began in 1980. MBTI and DISC says that he is a Result Oriented, Independent, Individualistic Visionary. However, he also freely admits that he is an Arrogant, Inflexible, Argumentative, Intolerant, Impatient, Critical & Stubborn Sceptomist!

Kevin Lee Smith The Pragmatic Thinker

Part of the Pragmatic Family