Page 1

PR

Enterprise Architecture Tools A Pragmatic Approach to Selection and Adoption

OO F

Kevin Lee Smith The Pragmatic Gardener

Connecting the DOTS

Part of the Pragmatic Family 


PR

OO

Enterprise Architecture Tools

A Pragmatic Approach to Selection and Adoption

2017 Edition Kevin Lee Smith V1.1

F


Published by:

First published: May 2017 Last updated: June 2017 ISBN 978-1-908424-53-2 (hardback) ISBN 978-1-908424-54-9 (paperback) ISBN 978-1-908424-55-6 (ebook)

http://www.PragmaticEA.com

© Pragmatic EA 2008 - 2017

PR

Pragmatic EA Ltd 25 Buttermere Great Notley, Essex CM77 7UY England

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

Book

ISBN

PF2

978-1-908424-42-6

OO

The Pragmatic Family of Frameworks

Prerequisites

Enterprise Direction

978-1-908424-16-7

PF2

Enterprise Operation

978-1-908424-19-8

PF2

Enterprise Transformation

978-1-908424-07-5

PF2

Enterprise Architecture

978-1-908424-10-5

POET

Enterprise Engineering

978-1-908424-13-6

POET

Enterprise Support

978-1-908424-22-8

PF2

A Pragmatic Approach using POED

A Pragmatic Approach using POEO

A Pragmatic Approach using POET

A Pragmatic Approach using PEAF

A Pragmatic Approach using PEEF

A Pragmatic Approach using POES

Enterprise Debt™

978-1-908424-48-8

A Pragmatic Approach to Enterprise Transformation Governance

Enterprise Architecture Tools

978-1-908424-54-9

F

A Pragmatic Approach to EA Tool Selection and Adoption


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

PR

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

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

OO

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

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

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

F

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


Contents

PR

Introduction..............................................1 Training – EA Tools Workshop .................................................................... 2 What is it?.............................................................................................................................................. 2 Why Should I Attend? ........................................................................................................................ 2 Who Should Attend? .......................................................................................................................... 2

PF2.............................................................5 Introduction .................................................................................................... 6 Training .................................................................................................................................................. 6

Content...................................................................................................................................................................................... 6

Licensing ............................................................................................................................................... 10 Non-Commercial (Internal).............................................................................................................................................. 10 Commercial (External) ...................................................................................................................................................... 11

Language ........................................................................................................ 12

OO

I Didn’t Mean What You Heard! ................................................................................................... 12

Ontologies ..................................................................................................... 15 Enterprise ............................................................................................................................................ 15 Paradigm Shift ..................................................................................................................................................................... 15 DOTS ...................................................................................................................................................................................... 17

Structural ............................................................................................................................................. 19 MACE ..................................................................................................................................................................................... 19

Transformational................................................................................................................................ 20 MAGMA ................................................................................................................................................................................. 20

Methods ..................................................21 Overview........................................................................................................ 22 Phases ................................................................................................................................................... 22 Basics ...................................................................................................................................................................................... 23 Strategising ........................................................................................................................................................................... 25 Roadmapping ....................................................................................................................................................................... 26 Project Execution................................................................................................................................................................. 27 Governance & Lobbying ................................................................................................................................................... 28 Models .................................................................................................................................................................................... 29 Example Roles and RACI Patterns ................................................................................................................................ 31

F

Disciplines ...................................................................................................... 32 Modelling.............................................................................................................................................. 32

Artefacts .................................................35 Levels ............................................................................................................. 36


Structural (MACE)........................................................................................ 37 Relationships ....................................................................................................................................... 38

PR

Transformational (MAGMA) ....................................................................... 39 Relationships ....................................................................................................................................... 40

Ontology ........................................................................................................ 41 Basics..................................................................................................................................................... 41 Mapping to Phases ............................................................................................................................................................. 43 Volatility, Volume, Impact & Population ...................................................................................................................... 44

Structural & Transformational ........................................................................................................ 47 Business Model, Operating Model, Capability Model & Roadmaps ....................................... 48

Meta-models .................................................................................................. 50 Hybrid ................................................................................................................................................... 50

Environment .......................................... 51 Tools ............................................................................................................... 52

OO

Coverage .............................................................................................................................................. 52 Integration ........................................................................................................................................... 54 Coverage .............................................................................................................................................. 56 Vendors ................................................................................................................................................ 57

F

Adaptive ................................................................................................................................................................................. 58 Archi ........................................................................................................................................................................................ 59 Atoll.......................................................................................................................................................................................... 60 Avolution ................................................................................................................................................................................ 61 BiZZdesign ............................................................................................................................................................................ 62 BOC Group............................................................................................................................................................................ 63 Capability Management Inc. ........................................................................................................................................... 64 Casewise ................................................................................................................................................................................ 65 Dragon1 Inc. ......................................................................................................................................................................... 66 EAS .......................................................................................................................................................................................... 67 FrankITecture ....................................................................................................................................................................... 68 Future Tech Systems Inc................................................................................................................................................... 69 holocentric ............................................................................................................................................................................. 70 UNICOMÂŽ Systems .......................................................................................................................................................... 71 iGrafx ...................................................................................................................................................................................... 72 INARTEC................................................................................................................................................................................ 73 inspired ................................................................................................................................................................................... 74 intelligile.................................................................................................................................................................................. 75 iteratec.................................................................................................................................................................................... 76 Link Consulting ..................................................................................................................................................................... 77 mega ....................................................................................................................................................................................... 78 MooD International ............................................................................................................................................................ 79 No Magic ............................................................................................................................................................................... 80 OpenText ............................................................................................................................................................................... 81 Orbus Software .................................................................................................................................................................... 82 Pragmatica Innovations ..................................................................................................................................................... 83 QPR Software Plc ................................................................................................................................................................ 84 qualiware ............................................................................................................................................................................... 85 Modeliosoft/Softeam .......................................................................................................................................................... 86 Software AG .......................................................................................................................................................................... 87


Sparx Systems...................................................................................................................................................................... 88 SAP .......................................................................................................................................................................................... 89 Troux....................................................................................................................................................................................... 90

PR

Evaluation............................................................................................................................................. 91 Requirements ....................................................................................................................................................................... 91

Demonstrations ............................................................................................................................... 100 Process..................................................................................................................................................................................103 Raw Scores..........................................................................................................................................................................104 Weighted Scores ...............................................................................................................................................................105 X-Requirements ................................................................................................................................................................106 XA - Tool Architecture ....................................................................................................................................................107 XC - Tool Configuration and Maintenance ..............................................................................................................109 XF - Tool Functionality ....................................................................................................................................................112

Adoption .............................................. 115 Motivation.................................................................................................... 116

Environment...................................................................................................................................... 117 Tools ......................................................................................................................................................................................117

Actions ......................................................................................................... 127

Constructing ..................................................................................................................................... 127

OO

Environment .......................................................................................................................................................................127

Transitioning ..................................................................................................................................... 128 Environment .......................................................................................................................................................................128

Appendix .............................................. 129 Background ................................................................................................. 130

Why Were They Created?............................................................................................................ 131 Where Did They Come From? .................................................................................................... 132 When Were They Created? ......................................................................................................... 134 What Was Used to Create Them? ............................................................................................. 135 How Were They Created? ........................................................................................................... 136 Who Created Them? ...................................................................................................................... 137 MBTI .....................................................................................................................................................................................138 DISC ......................................................................................................................................................................................139

Keypoints ..................................................................................................... 140 Sources & Resources .................................................................................. 162

F


Introduction - 1

PR

INTRODUCTION

OO

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.

F


2 - Introduction

Training – EA Tools Workshop

PR

What is it?

The EA Tools Workshop is an introduction and hands on workshop designed to enable Enterprises to effectively and efficiently; choose a tool, and how to operate it in a sustainable way by adopting A Pragmatic Approach to EA Tool Selection and Adoption. Run over 1 day and using this book, the first part of the workshop presents the concepts required to understand an EA Modelling Tool, what it used for, what information must be modelled, and pragmatic methods for adoption and use. The remainder of the day is a hands-on workshop where you will formulate your own tailored approach for selection, define which requirements are key to you, and develop a shortlist.

Why Should I Attend?

Enterprises (Public Companies, Private Companies, Government Agencies) spend a lot of money on tools. But many of these tools sit on the shelf or are used in only small ways. The most common reasons are that:

OO

a) The tool they selected is not is not appropriate for their Enterprise. b) 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.

Who Should Attend?

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. Please contact Training@PragmaticEA.com to book places for your team today.

F


Introduction - 3

OO

PR This section contains a number of fundamentals about the Pragmatic Family of Frameworks. It sets out some definitions, fundamental ontologies, explains the licensing model and introduces the frameworks in the Family..

F


OO

PR

F


PF2 - 5

PR PF2

OO F


6 - PF2 Introduction Training Content

OO

PR Overview Various training courses are available which are structured for easy and appropriate adoption. PEAF Foundation training is a pre-requisite for PEAF Certified training because PEAF inherits and builds on the Pragmatic Operating model for Enterprise Transformation defined by POET which forms the Foundation of PEAF. These courses educate individuals and organisations in a vendor and technology neutral Pragmatic approach to improving their Transformation capability in general and the Enterprise Architecture part of that domain in particular.

♦ PEAF Foundation (2 days) set out an Operating Model for the whole of the

transformation domain (from Strategy to Deployment) and the common patterns of methods and artefacts that allow an organisation to tactically improve parts of it while preserving the effectiveness and efficiency of the whole. It sets the context for Enterprise Architecture in terms of where it fits in, and where it doesn’t. ♦ PEAF Certified (2 days) concentrate on the specifics of the EA domain and sets out the fundamental pieces to be put in place to be successful. Classroom Format All courses are run by a Pragmatic Certified Trainer. Each day consists of 6 hours of presentation and discussions, finishing with an Exam lasting 1 hour.

F

9-12 Presentations/discussions 12-1 Lunch 1-4 Presentations/discussions 4-5 Certification Exam


PF2 - 7 Certification Exams •

PR

Exams are marked dynamically in real-time, and so if you get an answer wrong or partially wrong, you will receive feedback for example “Correct but you need to give a little more detail”. The pass mark for all exams is 100%. The reason for this is that we want to make sure that people understand 100% of the things an exam is asking (which is only a small proportion of the entire content). Most people complete each exam in 45-60 minutes, and although there is no hard time limit as such, we will close each exam after 2 hours. If you fail an exam, you are welcome to re-sit the exam (maximum of 3 times) at a later time for no additional cost

OO

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

F

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.


8 - PF2

OO

PR

Prior Knowledge No prior knowledge of Enterprise Architecture is required, although it is useful if the attendees have worked as part of the Transformation capability of an Enterprise. Relevant Industries. Learning the fundamental discipline of Enterprise Architecture (and the wider Transformation domain) and how to mature it in an Enterprise is not dependent upon any business industry knowledge. Previous Customers Experian, Hasbro, Freshfields Bruckhaus Deringer, California Franchise Tax Board, California Department of Health Care Services, Aspen Re, Dunn & Bradstreet, California State Board of Equalization. Private/On Site Courses Can be run and tailored to the challenges of your Enterprise. Certification Body The certificating body is Pragmatic EA Ltd. Previous comments We have a 100% positive feedback from the course. Some comments below but all comments (unedited and unabridged) can be read at http://www.pragmaticea.com/commentstraining.asp “Excellent, thought provoking and well laid out” - Global Automation Manager, UK “Energizing and invigorating -- helps put the passion back in EA efforts” - VP Marketing & Business Development, USA “It was fantastic course - very insigthful and valuable. Thank you.” - Architect, UK “A refreshing approach to EA, focused on *helping* the business develop an approach and strategy, rather than telling them what to do. The course was very logical and easy to follow.” - Executive Director, USA

F


PF2 - 9

PR

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

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

OO

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

F


10 - PF2 Licensing

OO

PR Non-Commercial (Internal)

If you wish to use any of Pragmatic’s Ontologies, Frameworks or materials (in whole or in part) internally (e.g. Individual Consultants, End-User Enterprises, Government Bodies, Academic Institutions, etc) then the Enterprise that uses them, and the people that use them, must possess a Non-Commercial License. NOTE: Contractors who operate their own one-man-band companies and provide services through recruitment agencies to End-User Organisations and Government Bodies are considered to be Individual Consultants and therefore only require a 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:

F

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

Applications for a license can be made at http://www.pragmaticea.com/licensing-noncommercial.asp


PF2 - 11 Commercial (External)

PR

If you wish to use any of Pragmatic’s Ontologies, Frameworks or materials (in whole or in part) externally (e.g. Consultancies, Training Providers and Tool Vendors) to improve your clients Enterprises, then your Enterprise, and the people that use them, must possess a Commercial License. NOTE: Contractors who operate their own one-man-band companies and provide services through recruitment agencies to End-User Organisations and Government Bodies are considered to be Individual Consultants and therefore only require a Non-Commercial License.

If you wish to evaluate any of Pragmatic’s Ontologies, Frameworks or materials internally for commercial use, you can do so under a free Non-Commercial License. If you wish to evaluate any of Pragmatic’s Ontologies, Frameworks or materials for external commercial use (by using it with an external client) this is possible by contacting Pragmatic first and obtaining written permission to do so. The license is issued with the following terms:

OO

Any use must be attributable to Pragmatic EA. Details of the license issued will be posted on the Pragmatic EA website. The Licensee is entitled to use the Licensee Logo on their websites and other promotional materials. When used on a website the logo must link back to www.PragmaticEA.com Licensees agree to be contacted by Pragmatic EA periodically with updates. It is expressly forbidden to pass on any Pragmatic Commercial Licensing Fees to clients of the commercial Enterprise, either directly or indirectly. The Standard Commercial License specifically prohibits the production of derivative frameworks, however, if you wish to create derivative frameworks this is possible by contacting Pragmatic EA and obtaining explicit written consent.

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

F


12 - PF2 Language I Didn’t Me an Wh at You He ard!

OO

PR The Pragmatic Family of Frameworks are written in English and you would therefore expect to be able to understand every word. However, although most of us speak English fluently, the same cannot be said about the language we use to talk about things in relation to Enterprises. Different people use different words to mean different things at different times. This is a massive problem which makes understanding anything anyone says at best impossible and at worst apparently possible. (It is worse when apparently possible because people don’t realise they misunderstand each other.) People, including me, get attached to the meaning of the words we use and defend those meanings passionately. This is totally understandable because the meanings we attach to words are the absolute basis for our understanding things. Pragmatic has no desire or wish to impose our meaning of words onto you, however, for the purposes of understanding the Pragmatic Family of Frameworks, I would ask you to temporarily put aside your current meanings of words and try to embrace, accept and understand the meanings of the words used here. The actual words are not so important as the meaning behind them.

F


PF2 - 13

PR

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

OO

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

F


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

PR

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

OO

Do people in your enterprise speak the same language?

Are you prepared to map the content of The Pragmatic Family of Frameworks to your own internal naming conventions? If not what changes would you make to The Pragmatic Family of Frameworks?

F


PF2 - 15 Ontologies Enterprise Par adigm Shift

OO

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

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

F

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


16 - PF2

OO

PR

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

F


PF2 - 17 DOTS

OO

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

Operation

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

Transformation

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

Support

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

F

Direction

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


18 - PF2

PR

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

OO

What high level structures does your Enterprise use to describe itself? Are they purely physical like Departments or more conceptual?

Do you think DOTS is a useful structure for analysing an Enterprise?

Do you think DOTS is a useful structure for designing an Enterprise? What are you doing in your Enterprise to connect the DOTS?

Who bangs the boardroom table for resources to improve each part?

What is their title? Do they have a seat at the Board Table? If not, why not?

F


PF2 - 19 Structural MACE

OO

PR MACE is an ontology used to categorise information relating to the operational structure of something:

Artefacts

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

Culture

Information about the People that are being used to perform the Methods. E.g. People, Values, Ethics, Trust, Psychology.

Environment

Information about the technical Environment that is used to execute the Methods and work with the Artefacts. This Environment includes Information technology (which is a large part) but also includes other technologies. For example if your company is Shell Oil, then Chemical and Biological Technology is also very important – perhaps even more so than Information Technology!).

F

Methods

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


20 - PF2 Transf or mational MAG MA

OO

PR MAGMA is an ontology used to categorise information relating to transforming something. Information about the reasons why we are transforming. E.g Visions, Goals, Objectives, Requirements.

Actions

Information about the things we need to do in order to achieve those goals and satisfy those requirements. E.g. Mission, Strategies, Tactics, Roadmaps, Plans, Tasks.

Guidance

Information about the things that will guide others as the Actions are executed. E.g Principles, Polices, Standards, Rules, Values, Frameworks (MACE)

Measures

Information about the things that will allow us to know if we have achieved our goals and satisfied our requirements. E.g. Metrics, KPIs, CSFs,

Assessment

Information about the things that led to us to choose the target and intermediate structural models (as defined by MACE) and the the Actions (as defined by MAGMA) that will effect the changes between them. E.g. Strengths, Weaknesses, Opportunities, Threats, Pro’s, Cons, Issues, Risks.

F

Motivation


Methods - 21

PR METHO DS

OO

In this section, we look at the Methods of POET. The methods deal with the ways in which the Structural (MACE) and Transformational (MAGMA) information, defined in the Artefacts section, are used for the purposes of Transformation. The HOW. Before you read the section, what are the fundamental Methods that you think are essential for Enterprise Transformation? What things exist within your Enterprise in this regard today?

F


22 - Methods Overview Phases

OO

PR These are the fundamental phases of Transformation which sit between the fundamental levels that artefacts can exist at. Starting at Strategising,, the transformation at each phase takes us closer to the physical world. Strategising - Why Should I Care? Roadmapping - Plan of action. Initiating - Detailed planning. Elaborating - Designing the changes. Constructing - Building the changes. Transitioning - Deploying the changes. Using - Using the changes. Governance & Lobbying - Ensuring the phases align. Do you agree with these fundamental phases? If not, what would you change and why?

What fundamental phases does your Enterprise define? If so, how will you solve them?

F

If it does not, does that cause any problems or issues?


Methods - 23 Basics

OO

PR Here we see the fundamental phases of Enterprise Transformation, laid out over the domains of the Enterprise. The Direction part of the Enterprise feeds requirements for transformation into the Transformation part of the Enterprise which delivers change into the Operations part of the Enterprise. It should be noted that the Transformation part of the Enterprise may also deliver change into the Direction, Support or even Transformation (the whole point of POET) part of the Enterprise but we just show Operations here as that is the most common occurrence. These phases of Transformation are not strict and rigid waterfall type “processes”, but every journey has to be split up into parts, and these high level phases form the high level parts of the journey, by which to consider holistically, how Transformation is effected from the formulation of Strategy to the Deployment of change into the Enterprise. For each phase, the How that is effected is done by the next phase down, and the Why comes from the phase above. The key to the Transformation cascade working together holistically and coherently is the Governance and Lobbying disciplines which use the concept of Enterprise Debt™.

F


24 - Methods

PR

The white horizontal line at the top of the Transformation domain delineates the transition planning work from the project execution work. Everything below that white line is effectively “projectland� The white horizontal line at the bottom of the transformation domain delineates project execution work from the deployment work. Our remit is not only what is happening in one of these areas. Our remit is what is happening in all of these areas. In general people work within these areas and in most Enterprises these people try to improve what they do (if they are allowed) and how they do it. This is a laudable thing to do, however, no one is looking at the whole cascade and ensuring that the whole cascade is effective and efficient. The parts are being optimised at the expense of the whole. POET provides the basis for Senior Management to address optimising the whole of Transformation, for it is the output of the whole that most important rather than the output of each phase - this in fact, may mean the de-optimisation of some or all of the parts. For this reason, everything in POET applies equally to all phases of the Transformation cascade and is the unifying holistic and coherent context in which all Transformation work is performed. In terms of naming these levels there are two fundamentals. Enterprise Architecting (EA) consists of all work done prior to project execution, namely Strategising and Roadmapping. Enterprise Engineering (EE) consists of all project level work, namely Initiating, Elaborating, Constructing and Transitioning.

OO

Do you agree with these Phase boundaries?

How does your Enterprise map onto them?

Does everyone working within the Transformation domain understand how where they work fits into the whole? If not, would there be a benefit if they did?

What will you do to allow people to understand how they fit into the whole and what will you use?

F


Methods - 25 Strategising

OO

PR Does your Enterprise recognise this as a phase? If not, how is this work recognised?

Does your Enterprise recognise how this work it fits into the whole Transformation cascade - from Strategy to Transitioning? If not, how does it make sure that it works coherently with the phases around it? What does your Enterprise call this phase?

Who in your Enterprise is accountable for this work being performed? Who in your Enterprise is responsible for performing this work? Who do they hand the output of their work over to?

F


26 - Methods Road mapping

OO

PR Does your Enterprise recognise this as a phase? If not, how is this work recognised?

Does your Enterprise recognise how this work it fits into the whole Transformation cascade - from Strategy to Transitioning? If not, how does it make sure that it works coherently with the phases around it? What does your Enterprise call this phase?

Who in your Enterprise is accountable for this work being performed? Who in your Enterprise is responsible for performing this work? Who do they hand the output of their work over to?

F


Methods - 27 Project Execution

OO

PR Initiating - where a project starts up, requirements are understood and developed, various possible solutions are identified and considered, and a high level solution is chosen. (Please note that the word Solution is being used in its widest sense, not meaning an IT solution - although a solution may include IT. Elaborating - where this high level solution is developed into the designs required to “build” the solution. Constructing - where the designs are used to “build” the solution. Transitioning - where the solution (comprising changes to Methods, Artefacts, Environment and Culture) is deployed into Operations. Using (from the Operation Domain) - where the changed environment is utilised. Does your Enterprise recognise these as phases? If not, how is this work recognised?

Does your Enterprise recognise how this work it fits into the whole Transformation cascade - from Strategy to Transitioning? If not, how does it make sure that it works coherently with the phases around it?

F

What does your Enterprise call these phases?

Who in your Enterprise is accountable for each phase?

Who in your Enterprise is responsible for performing each phase?


28 - Methods Governance & L obbying

OO

PR Does your Enterprise recognise that Governance is imperative to ensure work proceeds in an orderly fashion? Does your Enterprise recognise that Lobbying is imperative to ensure problems or opportunities that are discovered at any level are raised to the appropriate level to be solved or exploited? Does your Enterprise recognise that Governance and Lobbying is the glue which makes the whole Transformation cascade work together coherently, holistically, effectively and efficiently? If not, how does it make the whole Transformation cascade work together coherently, holistically, effectively and efficiently? Who in your Enterprise is accountable for Governance at each level? Who in your Enterprise is responsible for Governance each phase? Who in your Enterprise is accountable for Lobbying at each level? Who in your Enterprise is responsible for Lobbying each phase?

F


Methods - 29 Models

OO

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

F


30 - Methods

PR

Transformational We also see how the Transformational Artefacts (as defined by MAGMA) exist in a holistic and coherent cascade from Strategic intent at the top, down to deployed change at the bottom. For each phase (or ellipse) - the same basic pattern of work is being carried out: The inputs of Why are we doing it and Why are we doing it this way flow from the phase above. The outputs to the right consist of the transformation needed to effect the change within the constraints of the Why are we doing it this way. This transformational information consists of detailed information to perform the next phase and high level information to perform all subsequent phases. These outputs are produced in the context of what currently exists at that level - to the left, and in the context of what currently exists - at the level below. Governance is performed down to the phase below. Lobbying is performed up to the phase above. Do you think that this basic pattern can help to keep the whole aligned and connected and why?

OO

Does your Enterprise consider how the structural information at each level is used and reused by other levels? Do you think that this basic pattern can help to keep the whole aligned and connected and why? Does your Enterprise consider how the transformation information at each level is used and reused by other levels?

F


Methods - 31 Example Roles an d RACI P atterns

OO

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

F

Does your Enterprise have a pattern of Accountability and Responsibility that enables the whole of the Transformation cascade to work together coherently? What would the diagram look like if you overlaid the people and roles that your Enterprise defines along with their RACI mappings?


32 - Methods Disciplines Modellin g

OO

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

F


Methods - 33 Integrate the Data

PR

Here we ensure that information that has been loaded into the model is sustainable and will be maintained. 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‌

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.

or‌

The source is preserved - The necessary Methods, Artefacts, Cultural and Environmental things are 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 tools and analyses provided by the modelling tool to answer the question.

OO

How does this discipline map to your Enterprise?

Are there any problems with how your Enterprise approaches Modelling? Does your Enterprise even recognise Modelling as a 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?

F


OO

PR

F


Artefacts - 35

PR ARTEF ACTS

OO

In this section, we look at the Artefacts of POET that deal with the information required for Structural description and Transformational description. The WHAT. This is the smallest section in POET. Interestingly it is the thing that most frameworks and ontologies focus on, which when you see the other quite important things like Methods, Culture and Environment might make you wonder how much value they contain. It is understandable however, that people concentrate on Artefacts as they are very “tangible� and because many frameworks come from IT departments and IT people love structure. Methods, Environment and Cultural things are much harder to produce and therefore tend not to be produced. Before you read the section, what are the fundamental Artefacts that you think are essential for Enterprise Transformation?

F

What things exist within your Enterprise in this regard today?


36 - Artefacts Levels

OO

PR These are the fundamental levels that artefacts can exist at, which sit between the fundamental phases of transformation. Starting at the Enterprise Context, the information at each level is transformed and becomes closer to the physical world. Enterprise Context - A representation of the physical world outside out Enterprise. Contextual - A representation of why we exist and how we satisfy the need for our existence? Conceptual - A representation of how we need to change. Logical - A representation of Logical Solution designs. Physical - A representation of Physical solution designs. Operational - A representation of the physical world. Physical Stuff - The physical world inside out Enterprise. Do you agree with these fundamental levels? If not, what would you change and why?

What fundamental levels does your Enterprise define? If so, how will you solve them?

F

If it does not, does that cause any problems or issues?


Artefacts - 37 Structural (MACE)

OO

PR POET uses the MACE ontology to allow an Enterprise to describe the Structural information of any domain and notes that this information exists at different levels of Idealisation/Realisation. Methods - How the work should be carried out. Artefacts - What things the work consumes and produces. Culture - The people and culture required. Environment - The tools, technologies, frameworks and locations that are used to perform the work. It is important to note that Culture sits at the centre. Because - Culture trumps everything™ In fact, in addition to POET defining MACE, POET itself is structured using MACE as are all the Frameworks and Ontologies in PF2. Whilst it is very useful to have a structure like MACE, to map things to and to make sure that nothing has been missed, it is also important not to lose sight of the fact that these things all need to work together, cooperatively, like an organism, and the story of how that happens is as equally important. What ontology do you use to completely define the structural elements of your Enterprise?

F

Are you missing anything?


38 - Artefacts Relationships

OO

PR Here we illustrate how the components of MACE are related. Don’t forget that to enable Transformation, each is represented at different levels of Idealisation/Realisation. At the core are the Methods which execute within the Culture and Environment that exists, with the whole existing within a context. The Methods break down into Phases and Disciplines and it is these Disciplines that are utilised to varying degrees in each phase which act upon the Artefacts to varying degrees. The Operating Model for the domain in question equates to the Contextual level information which defines an abstract representation of how the Methods, Artefacts, Culture and Environmental things come together to accomplish its function. In your Enterprise, where are the Operating Models defined for Direction, Operations, Transformation and Support? Do they cover all areas?

If you mapped them to MACE, would there be any overlaps or gaps? If so, would there be any benefit in removing them? How would you do that?

F


Artefacts - 39 Transf or mational (MAG MA)

OO

PR POET uses the MAGMA ontology to allow an Enterprise to describe the Transformational information required to effect the transformation of a domain from one state to another and notes that this information can exist at different levels of Idealisation/Realisation. Motivation - The reason we are transforming, our goals, our requirements. Actions - The tasks we need to execute in order to achieve those goals and satisfy those requirements. Guidance - The things that will guide others as the Actions are executed. Measures - The metrics that will allow us to know if we have achieved our goals and satisfied our requirements. Assessment - The reasons that led to us choosing the Actions. What ontology do you use to completely define the transformational elements of your Enterprise? Are you missing anything?

F


40 - Artefacts Relationships

OO

PR Here we illustrate how the components of MAGMA are related. Don’t forget that to enable Transformation, each is represented at different levels of Idealisation/Realisation. Motivation at the top is what drives the Transformational Information and what is produced at the bottom is primarily a set of Actions required to satisfy that Motivation. Guidance and Measures are also produced to guide and measure those Actions, while the Assessment expresses why the Actions, Guidance, and Measures have been decided upon. Where is your Transformation Model defined? Does it cover all areas?

If you mapped it to MAGMA would there be any overlaps or gaps?

F


Artefacts - 41 Ontology Basics

OO

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:

F

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.


42 - Artefacts

PR

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 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: The Enterprise Architecture Model (EA) consists of Contextual and Conceptual information set in the Context of Enterprise Context information and Logical information. 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. Does your Enterprise have the concept of an EA Model and an EE Model? If not, should it?

OO

Where does your Enterprise draw the boundaries? Do the boundaries exist? How are they managed?

F


Artefacts - 43 Mappin g t o Ph ases

OO

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

F

What needs to be done to alleviate them?


44 - Artefacts Volatility, Volume, I mpact & Population

OO

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

F


Artefacts - 45

OO

PR

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

F


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

PR

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

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!

OO

Does your Enterprise understand the low volume of information required for a complete EA Model? 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?

F


Artefacts - 47 Structural & T rans for mati onal

OO

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

How do they map to, and fit into, the POET Ontology? Are they any gaps or overlaps?

F

If there are gaps and or overlaps, is it useful to know that?

What will you do to fill the gaps and remove the overlaps?


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

OO

PR F

The fundamental ontology for a Business Model is defined in POED. The Metamodel actually used is very business dependant (and dependent upon the C-Suite’s experience) but typically utilise things like the Business Motivation Model (BMM), the Business Model Canvas (BMC), the Enterprise Canvas (EC - Tom Graves), V4 BM, etc are used. There is a Current and Target Business Model indicating last year’s Business Model and the one you begin create for this year. Of course the Business Model should rarely change, but the Enterprise may decide internally that they want to change it or it may need to change based on a new Enterprise Context (or the understanding of something that was already part of the Enterprise Context but not taken into account). There is a Current and Target Operating Model indicating last year’s Operating Model and the one you begin create for this year. Of course the Operating Model should rarely change, but the Enterprise may decide internally that they want to change it or it may need to change based on a new Business Model. The Operating Model consists of the Methods, Artefacts, Culture and Environment (as defined by MACE) required to enable the Business Model. The Roadmap Model consists fundamentally of 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. These different Structural states (and the relationships between them) constitute the Structural Roadmap (generally made up of Business and Technical capabilities)


Artefacts - 49

PR

For Transformational Projects, there are the Structural Transformational Models (MACE) and the Transformational Transformation Models (MAGMA) required to execute the projects, which deliver into Operations, Transformation, Support or Direction. From these basic models, it can be clearly seen how the Enterprise Strategy and Transformation Strategy are composed. The Enterprise Strategy consists of the Business Model and Operating Model set in the context of the Enterprise Context Model. The Transformation Strategy consists of the Roadmap Model and Capability Model, set in the context of the Operating Model. Where does your Enterprise’s Business Model, Operating Model and Roadmaps fit into your Enterprises Transformation domain? Do you have the required basic information, in a usable format, to allow your Enterprise to produce the Business Model and Operating Model? Do you have the required basic information, in a usable format, to allow your Enterprise to produce the Structural and Transformational Roadmaps?

OO F


50 - Artefacts Meta-m odels Hybrid

OO

PR In reality one Metamodel to cover the entire Transformation domain does not exist and so a hybrid approach is needed. Here we see a full hybrid meta-model, constructed by taking the most appropriate things from various meta-models and producing a meta-model with 100% coverage. Horizontally - from a Structural and a Transformational perspective, Vertically from a Strategy to Deployment perspective. You may be surprised that the part that Pragmatic contributes is so small. However this is perfectly understandable as Pragmatic have always asserted that lack of meta-models has rarely been the reason for EA’s failure and since there are already a multitude of Metamodels already in existence it would be churlish to re-invent the wheel so to speak. It has, however, made a massive contribution by the introduction of Waivers that allow the exposing and management of Enterprise Debt™ and with the definition of the vessels (Ontology) that all these frameworks co-exist within, most notably MACE and MAGMA. However, a full Pragmatic Metamodel is in production, which will cover all domains and all levels. What Hybrid Meta-model are you currently using?

Is this a good starting point for a complete and Pragmatic meta-model? Who could create such a hybrid meta-model? How long would it take to create?

F

How would you implement such a hybrid meta-model?

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


Environment - 51

PR ENVIRONM ENT

OO

In this section, we set out the Environment that POET provides. These are the fundamental concepts and things that are used throughout POET. On their own they do not provide much value and could be seen as quite academic, however they form the bedrock of POET and are essential for its adoption and for obtaining the massive value it can create. Before you read the section, what is the fundamental Environment that you think is essential for Enterprise Transformation? What things exist within your Enterprise in this regard today?

F


52 - Environment Tools Coverage

OO

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

F


Environment - 53

OO

PR

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 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. The Blue lines indicate areas where specific tools could fit. While these lines may be moved for individual Enterprises based on the 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.

F


54 - Environment Integrati on

OO

PR Each physical Tool tends to consist of two parts:

A Repository that stores the information. A Tool which allows a user and other tools to manipulate that repository. 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.

F


Environment - 55

PR

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 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 What Tools do you use for Transformation? Where do they fit into Transformation domain? Are there overlaps or gaps?

OO

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?

F


56 - Environment Coverage

OO

PR To carry out the work in the EA domain (Strategising and 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’s not what they call themselves, it’s what information they manipulate. Which tools do you currently use?

What domains (Structural/Transformational) do they cover? What disciplines utilise them? Are they adequate?

If so, does this present any issues or problems?

F

What will you do to alleviate or solve them?


Environment - 57 Vendor s

OO

PR Here we present all the EA Modelling tool vendors presently in the marketplace, with some basic information about both the companies and their tools.

F


58 - Environment Company Adaptive

PR

Tool Adaptive Enterprise Architecture (EAM) v7.1

Company Adaptive creates simplicity out of complexity. Bio Information, though routinely misaligned, remains the lifeblood of every organisation. It is essential today to know how critical data moves across an enterprise. Adaptive offers standards-based solutions that help organisations better align their valuable information by supporting specific management challenges including Data Governance, Data Quality, Metadata Management, Enterprise Architecture Management and IT Portfolio Management. Adaptive is a global company headquartered in Irvine, California with offices in New York, London, Dublin, Ireland and Pune, India. A market leader with a long history of helping organisations adapt to and support the rapidly changing business and IT environments, which are driven by the ever increasing demands of compliance, regulatory pressures and governance requirements, Adaptive provides innovative solutions that enable enterprises to align their capabilities with strategic initiatives

OO

Tool Adaptive Enterprise Architecture Manager (EAM) is a robust MOF-compliant Bio knowledge repository solution for organizing, integrating and analysing information about the key architecture elements of an enterprise. Adaptive EAM captures and monitors the full scope of enterprise architecture initiatives, enabling performance monitoring and enterprise governance on a holistic scale. Adaptive’s capabilities include the ability for “Intelligent Search” from the Microsoft suite of products where content is provided directly to those tools based on their security profiles. Adaptive also provides comprehensive capabilities for change management, versioning, workflow, and collaboration via our web based platform. The overriding needs to cut costs, to increase efficiency and to improve profitability are significant challenges in today’s economy. Adaptive EAM delivers significant benefits to organisations in addressing these issues. Adaptive provides a Business Excellence program allowing organisations to model and manage their EA initiatives.

F


Environment - 59 Company Archi

PR

Tool Archi 2.4

Company Archi has been developed by Phil Beauvoir, initially while working for the Bio Institute of Educational Cybernetics and from 2013 onwards as an Open Source initiative together with the Archi community and users. We are now seeking funding and support from interested parties in order to continue development work.

OO

Tool Archi is targeted toward all levels of Enterprise Architects and Enterprise Bio Modellers. It is intended to provide a low cost to entry (i.e. free) solution to users who may be making their first steps in the ArchiMate language or who are looking for a cross-platform ArchiMate modelling tool for their company or institution. Archi fulfils the needs of most Enterprise Architects and associated stakeholders, but it can also be regarded as an introductory ArchiMate tool for those wishing to engage with the language before committing to a commercial solution. Since its introduction, Archi has been widely adopted for real-world use in the commercial and educational sectors and is used in-house by major global companies and consultants. It is rapidly becoming the de facto open source ArchiMate modelling tool. Website: http://www.archimatetool.com

F


60 - Environment Company Atoll

PR

Tool SAMU v5.5

Company At Atoll we deliver agility into transformations. Bio We have been developing SAMU, our transformation modelling tools since 2003. It stands out with flexibility, visual capabilities and ease of use. Customers range from Banking and Insurance to Government, Telecommunication, Industry, Utilities and Pharmaceuticals.

OO

Tool SAMU offers almost all functionalities of the large footprint EA solutions and Bio numerous exciting unique features at a fraction of implementation time and resources. Main differentiators • Ready-made for super-quick implementations yet extremely flexible • Sexy visuals generated on the fly based on architecture data • Made to support transformations from planning to every day operations • Completely web-based, available SaaS or on-premise implementation • Ease of use • Open for integrations

F


Environment - 61 Company Avolution

PR

Tool ABACUS 4.5

Company avolution provides the market leading ABACUS solution for I.T. strategy and Bio enterprise architecture. ABACUS is recognized as the #1 EA tool in several independent tool assessments and as a ‘leader’ by the analysts. avolution has offices in Europe, Asia-Pacific and the United States and together with their global partner network services an ABACUS user-base of several thousand users in over 100 countries. Tool ABACUS is quite simply the most flexible, feature-rich and easy-to-use I.T. Bio strategy, planning and enterprise modelling tool on the market today. What can take months with other tools (if it is possible at all) can be done in minutes with ABACUS. ABACUS was the first tool certified to support PeaF and through simple drag-and-drops in the standard user interface it supports over 100 other frameworks and notations including ArchiMate, BPMN, BMM, UML, TOGAF, DoDAF, MoDAF, NAF and FEAF.

OO F


62 - Environment Company BiZZdesign

PR

Tool BiZZdesign Enterprise Studio

Company The rise of a digitally savvy populace increases the pressure on your organization to Bio deliver products and services that meet the digital expectations of your audiences.

Therefore, a clear vision on the alignment of strategy, technology, processes and people within your organization is key. To become successful in the digital age a powerful business design is crucial. That’s why we have developed BiZZdesign Enterprise Studio, our collaborative software platform that transforms the way you design your digital business. BiZZdesign Enterprise Studio gives you and your colleagues the opportunity to join forces and work together on the alignment of strategy, IT and processes. Together with our global partner network we offer complete solutions, consisting of consultancy, training and excellent customer services that drive continuous innovation, enhance operational excellence and support collaboration.

Tool BiZZdesign Enterprise Studio is a collaborative business design platform that enables the continuous innovation, transformation, and management of the digital enterprise, Bio using shared descriptions of business models, investment portfolios, and business,

OO

application and technology architectures, in order to exceed customer expectations, improve productivity, shorten time to value, reduce risk, and create competitive advantage. BiZZdesign Enterprise Studio has the following key characteristics: • BiZZdesign Enterprise Studio is a flexible, easy to use collaborative business design platform that enables clients and partners to create new solutions that easily integrate with and adapt to their environments. • BiZZdesign Enterprise Studio has powerful analysis and visualization capabilities enabling the who, what, where, when, and why questions to be asked and answered with meaningful charts, graphs, tables, dashboards, and reports. • BiZZdesign Enterprise Studio supports senior management and line-of-business owners in their quest to drive continuous innovation, transformation and management of their organizations into next generation digital enterprises. • BiZZdesign Enterprise Studio supports the operational needs of organizations by empowering them to plan, track, and communicate change - more rapidly, more reliably and with less risk. BiZZdesign Enterprise Studio gives excellent support for the core capabilities for an EA tool (repository/meta model, modeling, decision analysis, presentation, administration, configurability, frameworks and standards, usability). Enterprise Studio also provides substantial and differentiating support in the areas of innovation, visualization, mapping and modeling, analysis and design, time to value, and business architecture design, and offers unique capabilities e.g. for risk & security and business strategy.

F

BiZZdesign Enterprise Studio is often selected as the tool of choice because it is very easy to use, has powerful visualization features, appeals to both business and IT stakeholders in an intuitive way, supports best of breed frameworks, provides accelerating best practices and reference models and is easily extendable to map adjacent information.


Environment - 63 Company BOC Group

PR

Tool ADOIT 6.8

Company BOC Information Technologies Consulting GmbH was established in 1995 in Vienna Bio as a spin-off from the Department of Knowledge and Business Engineering at the University of Vienna. Through its international orientation and customer centric strategy, new branch offices in Berlin, Madrid, Dublin, Athens, Paris, Warsaw and Winterthur were established to support clients locally. Today BOC can count many and varied Enterprises as customers on all five continents. All our customers are individually supported based on their native language by experienced consultants and partners. BOC is a consulting and software company specialising in IT-based management solutions in the following areas: • Business Process Management with ADONIS • Enterprise Architecture, ITSM and GRC with ADOIT • Strategy Management with ADOscore • Supply Chain Management with ADOlog

Tool ADOIT is the flagship enterprise architecture tool by the BOC Group. With ADOIT, the BOC Group provides professionals with an easy-to-use, intuitive and TOGAF®Bio compatible tool for enterprise architecture. Compelling features, such as the different

OO

role-based dashboards, make the tool interesting for architects as well as C-level executives and non-EA roles. In addition, ADOIT is TOGAF 9 certified The BOC Group provides customers with other frameworks and notations such as, PEAF, ArchiMate, etc. The Meta-modelling concept of the BOC Group allows customers to build their own individual framework or adapt frameworks, such as TOGAF, to their needs. Besides enterprise architecture management, ADOIT is also used for IT Service Management and Governance, Risk and Compliance. Tool features include:

F

• Collaboration features • Role-based, user-based landing pages • Individual dashboards • Data capture and modelling features • Flexible Meta-model • Different types of analyses, views and viewpoints • Easy-to-configure views • Support for different frameworks, such as TOGAF • Provision of reference architectures • Repository-based tool • Multilingual user interface • And many more EA buyers, consultants, alumni, students can download the free version of ADOIT, namely the ADOit:Community Edition (www.adoit-community.com) to become familiar with the many features of the tool. On the ADOIT:CE website users will find instructions on how to download and quickly set up ADOIT:CE. They can join the ADOIT Enterprise Architecture forum on LinkedIn to ask questions and discuss trending EA topics with other professionals. ADOIT:CE is available for free download at: www.adoit-commmunity.com


64 - Environment Company Capability Management Inc.

PR

Tool Enterprise Evolver 2.50

Company An App to Map the whole Enterprise Bio Change is a constant. Today, change happens faster than ever. Many kind of initiatives constantly take place to change the organization. If your organization is complex, visualizing the complexity and transforming it in response to external pressures is difficult. Enterprise Evolver gives you a clear picture of your organization at any given point in time about your enterprise. This makes it easier to understand how best to respond to change. Capability Management is a digital company headquartered in Latham, New York (USA). Capability Management provides innovative and intuitive digital app that support enterprise evolution. www.enterpriseevolver.com

OO

Tool It is an app to comprehend and present holistic view of enterprise through Bio network graph database and intuitive user interface on mobile iPad device. With Enterprise Evolver, you can map Customer Journeys, Strategy, Business Capabilities, Processes, People, Services & Application Systems and understand how all parts of the enterprise fit together and relate to each other to deliver value to your customers and generate revenue. The app offers many capabilities such as: • Model business parts, their connections and flow. • • • •

Understand impact of change before a change is affected. Built-in architecture viewpoints templates to jump start the architecture mapping Visualize maps/blueprints as a network graph or as a layered architecture Identify critical relationships, critical applications, critical capabilities and critical touchpoints using built-in social network analysis tool like centrality Visualize and understand how value flow within your organization and work is accomplished.

F


Environment - 65 Company Casewise

PR

Tool The Casewise Suite

Company Founded in 1989, Casewise is a globally recognized leader in Business Process Bio Analysis and Management, Enterprise Architecture and Governance Risk & Compliance, that provides software and consultancy solutions to over 3,000 major global organisations. Casewise solutions allow you to: Visualize - Seeing is believing. Casewise allows you to document any aspect of your business, from high level strategy through process and IT infrastructure quickly and easily. Expand - Communication & collaboration are essential. Casewise allows you to share and collaborate with all parts of your organisation, from core team members to senior executives. Optimize - Adaptation is vital. Casewise enables you to analyze, plan, improve and monitor how you do business. From integrating with a CMDB to process analysis and automation, Casewise solutions allow you to live and thrive in the business ecosystem.

OO

Tool The Casewise Suite provides the integrated, adaptable, and flexible framework Bio you need to align your IT and business strategies to obtain desired business outcomes. Casewise’s featured EA solution Evolve leverages social communication technology to enable collaboration that delivers true end-toend best practices, governance and compliance driven process improvement within your enterprise, so it becomes part of your corporate culture and DNA. Casewise solutions leverage the collective intelligence of your workforce and enable successful collaboration across organizational silos. Casewise helps identify problems before they become major risks and in turn facilitates the discovery of valuable opportunities. Casewise truly does deliver a 360 ° view of your enterprise. Casewise Evolve build on the foundation created by Casewise Modeler. Casewise Modeler enables your organisation to better understand what you do, how you do it, who does it, why you do it, when you do it, where you do it, and what’s needed to do it. Information stored in the Casewise central repository allows you to develop better insights to make better decisions to optimize your organisation’s performance. That means gaining efficiencies, saving money, increasing agility, mitigating risk and delivering better customer experiences. By linking together strategic, organisational, process, IT architecture and data technology modeling through dynamic object linking, the Casewise Suite enables teams to capture and understand the relationships and interdependencies between the organisation’s people, processes and technology.

F


66 - Environment Company Dragon1 Inc.

PR

Tool Dragon1

Company Dragon1 Inc. was founded in 2005 and is based in The Netherlands. The software company develops and markets cloud-based enterprise software worldwide to design, communicate and Bio report enterprise architecture combined with strategic management information. The main software product is Dragon1. The enterprise software is suitable for LMEs and SMEs, industryindependent. Key drivers for developing our software are: • People often have unused capabilities and competences • Organizations need to use people & information more effectively • Knowledge needs to be made reusable • Information can be of strategic impact The main users of Dragon1 are architects and managers. Also business and information analysts, process designers, consultants, program - and project managers, service managers and project workers. Their created architectural products are used to support decision-making by Board and management. Also Dragon1 Inc. develops and maintains the body of knowledge of the open Dragon1 EA Method. Dragon1 is a registered trademark and brand. Website: www.dragon1.com Dragon1 is an online collaboration platform enabling people and organizations to do enterprise innovation in a visual and effective way. Dragon1 is used as innovation lab, with access to a BPM Tool, EA Tool, UML Tool, Project Management Tool and GRC Tool. Business professionals design concepts, innovations and business models on Dragon1. And with that they create new and improved products, services and solutions for the organization. In fact with Dragon1 they are building their SMART DIGITAL Company. SVG is used as open the vector graphics language for creating models. We recommend to use Dragon1 in a SVG-compliant browser for interoperability purposes and graphics performance. Dragon1 can be used with Safari, Google Chrome, IE9+ and Firefox.

OO

Tool Bio

F

Dragon1 is a suite of several web applications. The availability of a web application in an edition depends on the purchased user license for an edition: Dragon1 PRO or Dragon1 ENTERPRISE: • Digital Workplace - is an online digital workplace to do your basic office automation work, task management, work management and messaging with fellow users in your account. You can share your created documents, plan tasks, check your calendar, write blogs, startup applications and send and receive messages. • Resource Center - is an information policy web application providing architects with editable checklists and templates, design strategy, glossary of terms, a set of strategic baseline documents about the companies way of working with architecture. • Architecture Repository – is your own architecture CMDB tool with which a user can create, administrate, store and manage storage data and information in the form of entities, adjustable to the user. Entities, classes, attributes and types can be created and edited, also relationships can be created between entities (i.e. modelling). • Visual Designer - is the drawing tool in which you create your visualizations based on views, perspectives, models and meta models using layers and time-frames. You can create a visualization and change, at once, all the symbols to a different drawing style: sketch, drawing, diagram (wireframes) and photographic images. • Models Atlas - is the web application for making design books: your visualizations interactive and publishing them to the outside world. Not every visualization you create in the Visual Designer you want to be accessible by everyone. In the Models Atlas you can work with real time data-indicators and pop ups and you can have users leave notes on the atlas pages. • Catalog - can be used to create catalogs, like an application catalog or process catalog. This comes in handy if you want to enter large amounts of data (number of attributes) for an entity-type. • Application Manager - is the maintenance application: Technical management, Application Management and Functional Management all can be done role based using this web application. Dragon1 works with Role Based Access Control (RBAC) and allows for integration with the companies identity management solutions. Dragon1 can be used as SaaS, IaaS and PaaS. You can have a Dragon1database on the web or at your own premises to use with the software.


Environment - 67 Company EAS

PR

Tool Essential Architecture Manager (5.0.6)

Company The Essential Project is a powerful, professional, proven and free of charge Bio Enterprise Architecture toolkit, available for download from www.enterprisearchitecture.org. The goal of the project is to promote the value that EA can bring to organisations of all sizes and experience, lowering barriers to entry with a set of free, simple, productive and effective tools. The project is not only about the tools. It is building a community supported by the tools and aims to provide a useful, active forum for sharing ideas and experiences of applying EA practices to real world business. The Essential Project is created and sponsored by Enterprise Architecture Solutions Ltd. www.enterprise-architecture.com.

OO

Tool The Essential Project takes its name from the focus on providing those Bio capabilities that are "essential" to maximising the value of enterprise architecture; helping organisations manage and analyse the knowledge needed to make decisions that impact or are impacted by the enterprise architecture. Built by architects, for architects, Essential Architecture Manager is the reference implementation of the Essential Meta-Model (the open-source, framework- independent ontology for EA). Essential Architecture Manager consists of Essential Modeller and Essential Viewer, which separate the capture of information from the analysis to bring class-leading management and visualization of your enterprise knowledge. A powerful multi-language framework for both the modeller and viewer, data import/export capabilities and a continuously-developed Essential Meta Model means that Essential can rapidly import your data from your existing sources, capture and manage more details of your enterprise architecture and dynamically produce views of your data, in your language. From managing regulations and compliance, strategic roadmaps, project and programme impact and progress, to detailed visualisation of the application and infrastructure, the over 500 meta classes in the Essential Meta Model provide the richest and extensible platform with which to capture and manage any aspects of knowledge about your enterprise. Central to web-based Essential Viewer is the ability to rapidly provide insights and support for a wide range of stakeholders - in particular for those from the business and outside of IT and architecture - in formats and terms that make sense to them immediately. Real world application of Essential Architecture Manager combined with shared experience of the Essential Community continues to direct the development of Essential, focussed on an enhanced and powerful platform for managing your Enterprise Architecture.

F


68 - Environment Company FrankITecture

PR

Tool MappIT 2.5

Company Effective use of IT can provide organisations with new means of serving Bio customers by enabling innovative products and services and achieving operational excellence We support companies in integrating ICT with their business to create value. Our offering of consulting services on strategy, architecture, organisation and governance of systems allows companies to align Business and IT processes with their strategic goals. The experience we have gathered in all the different market sectors has been formalized in a rich set of frameworks and analysis tools, that enable the quick and reliable delivery of consulting projects. Tool MappIT is an easy to use tool designed to manage an IT Strategy, Governance Bio and Architecture based on our MappIT model. It can be used for many purposes such as: assess and track your technical landscape define and map your future vision, objectives and requirements reclassify and analyze you IT expenses or future budget map and analyze you IT organisation and resource skills define and follow your IT project and their potential benefits on business and impact on IT

OO

• • • • •

F


Environment - 69 Company Future Tech Systems Inc

PR

Tool Envision® VIP 11.0

Company Ever wished for an ‘EYE’ into your business - providing unlimited visibility? Bio Enabling you to better "Envision Your Enterprise" has been our goal since 1985. Over the years we have evolved a highly adaptable and user-friendly enterprise repository supporting both technical and business stakeholders. Our highly collaborative and secure ENVISION® VIP system provides powerful and truly unique tools for visualizing, analyzing, leveraging, and synergistically sharing any and all types of enterprise information. • “Envision in your mind” a truly adaptable and visual computer-aided enterprise! • “Envision a normalized, secure, fully leveraged enterprise repository! • “Envision secure multi-user support with unlimited stakeholder views! Fully empowering your enterprise information is our goal!

Tool ENVISION VIP® intuitively lets you visualize and leverage all types of enterprise data. Bio Any number of "stakeholder views" including any desired "Business Objects" can easily

OO

leverage and share useful enterprise "attributes". Today’s enterprises are striving to better coordinate and link strategic planning, enterprise resource & asset management, service function identification, risk management, change management, process modeling & renewal. Typically, the myriad systems & files associated with these activities are sent to various “Document Management Systems” [Museums of files?] or perhaps into a state-of-the-art “Cloud”. Independent word processing, spreadsheet/DB, and graphic programs with little or at best file-level connectivity preclude referential integrity and true information leveraging. ENVISION VIP® securely supports the intuitive “Normalization” and “Synergistic Sharing” of your vital enterprise information. Unlimited “Visual Portals” enable various business stakeholders & analysts to identify, manage & track complex interactions and fully leverage all vital enterprise information. Goals, capabilities, business rules, processes, services, functions, associated risks, KPI’s, and metrics can all be easily linked and tracked. Information can be captured at the earliest useful point and referential integrity easily maintained & leveraged throughout the organisation. Security, access control, risk analysis, change notification, and change history management are all supported. Powerful reporting capabilities provide timely and intuitive insights into these vital enterprise resources. Dynamic dashboards can to setup to alert various stakeholders of changes or risks requiring their attention. Automated web site creation allows sharing of selected repository views with various authorized stakeholder groups. Multiple intranet sites can be easily maintained for various groups. Envision supports multiple frameworks [including PEAF, TOGAF/ArchiMate, Zachman, DODAF, and many others] and allows new views to be added as desired with no need for any vendor modifications, coding, or scripting changes. Linkages between models from any of these frameworks can be easily added as desired. More info: www.future-tech.com .

F


70 - Environment Company holocentric

PR

Tool Holocentric Modeler 7.1 and Modelpedia 2.1

Company Holocentric software, helps organisations to operationalize strategy, manage Bio business transformations and achieve operational excellence by providing a business management system and enterprise architecture tools that helps them capture, understand, change and optimize their business - from strategy, people, programs and procedures to compliance obligations. Holocentric software stores information in a single location and makes it easy to personalize and distribute views of the business to employees, based on their job. Tool Holocentric Modelpedia 2.1 Bio Modelpedia is the award winning platform* for implementing model-based collaboration and model-based communication. Using advanced collaboration and Web 2.0 capabilities, Modelpedia helps you achieve two things:

OO

• Provide a single source of customized information for employees about their role & how they should interact with the organisation • Leverage the wealth of knowledge and understanding held by your people, helping them describe & improve how your organisation works Modelpedia is a Model repository designed to store models created in Holocentric Modeler 7.1. In addition to this Modelpedia is a web portal for publishing those models as well as providing various related collaboration and portal features. Holocentric Modeler 7.1 Holocentric Modeler is a modelling tool for building rich business and architecture models about your people, processes and technology and how they interact to produce value. You can use Holocentric Modeler to model business processes, your technology systems, or you can use it to map the relationships between people, process and technology. At every level of your business, the model becomes like a map that shows where you are, where you want to go, and how to get there. Because you can flexibly describe and associate “entities”, such as people, processes or systems, you can choose how to apply the modeling tool to your business. Essentially, you can model any item or thing in your business and define relationships between any of these.

F


Environment - 71 Company UNICOM® Systems

PR

Tool UNICOM® System Architect®

Company UNICOM® Systems, Inc. is a global information technology company Bio delivering world-class solutions for the enterprise computing marketplace. Our extensive client portfolio includes Fortune 500 and Global 2000 corporations, and federal, state and local government organizations who use our end-to-end solution suites and software across the globe.

OO

Tool UNICOM® System Architect® is a market-leading enterprise architecture Bio tool that enables you to build and automatically generate data-driven views of your organization's enterprise architecture -- its strategy, business architecture, operational architecture, data, application landscape, supporting systems, technologies, and infrastructure. Together, these views form a mosaic that delivers the insight and analytics necessary to describe current and future states of the enterprise along with interdependencies, risks, life cycles, and standards. Empowered with this knowledge, your executives, decision makers, and managers can quickly and more effectively plan initiatives for improvement, due to a more thorough understanding of the reward, impact, roadmap, and risk of changes. You gain visibility of planned initiatives from the business through operations, solution architecture development, release management, and deployment (DevOps). • Build capability-driven enterprise architectures o Create a line of sight from strategies to key capabilities to systems and technologies supporting them o Take advantage of disruptive technologies and plan migration to the cloud o Use industry-standard frameworks and patterns o Perform master data management o Create roadmaps of business transformation o Produce dashboards to gain clear understanding of the big picture • Perform Business Process Analysis with Simulation and Optimization •

F

• •

Build operational and system architectures with defense architecture frameworks o Use market-leading support for DoDAF 2, NAF, and MODAF Build architectures using the Federal Enterprise Architecture Framework (FEAF 2) Integrate with UNICOM Focal Point for portfolio management Reverse-engineer and analyze ERP systems such as Salesforce.com and SAP


72 - Environment Company iGrafx

PR

Enterprise Modeler 2013 Process for Enterprise Modeling 2013 (EM Lite) Tool Enterprise Central 2013 Performance Central 2013

Company iGrafx is a ‘Gartner recognised’ leading provider of Enterprise Architecture, Bio Business Process Analysis and Management solutions that help Enterprises achieve competitive advantage through process visualisation and excellence. The iGrafx solutions enable Enterprises to define and link the Enterprise Architecture to the Business Process landscape enabling full visualisation and Impact analysis. This will ultimately lead to: increased customer satisfaction, reduction of costs, improved quality and increased resource utilisation.

OO

Tool An Enterprise wide modelling and management tool suite enabling all Bio necessary Artefact Modelling. This will enable full alignment of company processes, resources, RACI, and systems with corporate goals and strategies. It enables compliance management, risk management, enterprise architecture, quality improvement initiatives and any required KPI. Through data integration and visual workflows, Enterprises can develop comprehensive Enterprise models with multidimensional views of business processes, supporting systems, technology components and resources (RACI). In addition, Performance Central - provides real-time Process Performance Monitoring and ‘Dashboard’ reporting. An Enterprise wide solution enabling Process-oriented behaviour and measurements to be captured in real-time in relation to business strategies and goals. Reports and displays intuitive and meaningful business critical information to executives adopting a Process Performance Management approach. These displays are entirely customisable to the end users’ viewing requirements and preferences.

F


Environment - 73 Company INARTEC

PR

Tool idungu (2.0)

Company We want to combine the best of engineering, innovation and design. Our goal Bio is the creation of innovative software products that appeal to global audiences. We are a team focused on delivering innovative software solutions by leveraging emerging technologies and trends. INARTEC is the place where engineering, design and innovation is real. Tool idungu is a BPA Tool + Enterprise Architecture Model + Social + WES (Web Bio + Easy & Simple). Idungu is a unified vision of the how the company works and how it relates. With idungu, everything is connected.

OO F


74 - Environment Company inspired

PR

Tool Enterprise Value Architect (EVA) Netmodeler (2.8)

Company Inspired provides consulting services, training and tools to support Bio organisations in achieving desirable futures. Focus includes strategic planning, business and IT alignment, Business and Enterprise Architecture, Digital Transformation, Initiative Management and Delivery methods. Training on TOGAF, Other EA methods, business, information, process and application architectures. Consulting services at senior level.

OO

Tool EVA Netmodeler is an innovative web and repository based collaborative Bio enterprise modeling and knowledge management tool. It supports the work of strategists, enterprise architects, portfolio and programme managers and others in defining and realizing enterprise strategy. • Web based - including all administrative, updating and graphical modeling • Complete meta model flexibility - alter at run time with automatic adjustment of forms, browsers, reporting etc. • Notation flexibility - standard notations (e.g. BPMN, Archimate) or your own • Framework neutrality - concurrently support multiple frameworks (e.g. Zachman, PEAF, TOGAF, Inspired..) • Available on a Software as a Service (SaaS) basis - no infrastructure to worry about & cost effective • Role and Group based security • Built in analysis capability / report writer / event subsystem • Support for integration, both batch and realtime via standards such as XML, CSV and REST/Json • Cross Platform desktop graphical modeler • Document management • Time support and calendaring • Computed properties defined declaratively • Milestone charts, strategy charts & portfolio views • Visualization – some out of the box (e.g Radar charts, Pack Maps, multidimensional matrices) plus ability to easily extend via popular visualization tools such as D3 and Roassal

F


Environment - 75 Company intelligile

PR

Tool MAP 2.8

Company Intelligile is a pioneer in the area of Business Excellence. Intelligile defines Bio Business Excellence as the ability of an organisation to provide the maximum value to its stakeholders, which requires a continuous understanding of its surrounding landscape, ability to envision the future, set a winning direction and quickly and intelligently align itself to achieve its objectives. The company develops methodologies and tools that cover all aspects of Business Excellence Life cycle. It provides an integrated methodology for complete round-trip planning from strategy to implementation and capabilities building.

OO

Tool Intelligile MAP™, which stands for Model, Analyze and Publish, is a Bio comprehensive and powerful modeling solution for developing a complete Knowledge Maps for an organisation. It is the ideal tool to integrate, the most elaborate support for Enterprise Architecture, Business Landscape, Strategic Planning with Business Motivation Model and Balanced Score Cards, Operation engineering and BPMN, IT Architecture with TOGAF9 and Archimate, Service Model, Business rules, Roles management, Business Automation framework, Competency Framework with skills and responsibilities, Organisational Structure, Strategic Brand Management, Organisational Culture Management, GRC (Governance, Risks and Compliance), and Organisational Project Management with Prince II, OPM and P3M3 as well as DoDAF. The solution supports the full life cycle of modeling, communicating and publishing, monitoring implementation of planned Knowledge Maps, measurement, performance and evolution of models. Based on technology that mimics the functionality of the brain, the tool is natively Meta-model driven and come with a very rich of model types that cover all aspects of an enterprise. The Meta-models are fully customizable and expandable.

F


76 - Environment Company iteratec

PR

Tool iteraplan 5.1

Company iteratec is an independent software foundry and consultancy with over 200 Bio employees. Founded in 1996, the IT company specialises in end-to-end IT project

implementation, technology consulting and IT management consulting. Numerous enterprises – with both national and international operations – look to iteratec for expertise on IT architecture issues, and the company boasts an eminent client base which includes names such as Audi, BMW, E.ON, Lufthansa, Swisslife or Telekom. For more information, please visit www.iteratec.com Locations: Munich, Frankfurt, Hamburg, Stuttgart, Vienna, Zurich iteratec is appealing to top talents. Last year we were awarded Great Place to Work & Bayerns Best 50 awards. We are a dynamic enterprise. You’ll find us easy to work with, and good at taking quick decisions to move your project forward.

OO

Tool iteraplan 5 – the amazing Enterprise Architecture Management Tool – is a new product that combines tried and proven concepts, methods and experiences from Bio past releases. It is based on the best-practice EAM method developed by iteratec from experience gained in a multitude of projects. With its central repository, intuitive web interface and powerful reporting capabilities, iteraplan is an effective solution for documenting, analyzing and planning the enterprise architecture. iteraplan delivers support on all fronts to help you with starting and embedding EAM practices in your company. The free LITE edition covers all key requirements: • • • •

Central repository and consistent data source for all views Broad set of visualizations Flexible, customizable and extensible attribute system Intuitive HTML5 browser interface, no client installation necessary

The CORPORATE edition offers additionally:

The unique Graphics Reactor for individual visualizations and reports Management of users and roles, LDAP integration and Single Sign On (SSO) Data import and export via MS Excel, XML/XMI, JSON and REST interface Dashboards based on user-defined templates Tracing of all changes through a consistent history Quality assurance through consistency checks Query language iteraQL for complex analyses Ability to connect to enterprise DBMS (Oracle, MySQL and MS SQL)

F

• • • • • • • •

You are welcome to try the iteraplan Corporate Edition Demo available online without any need of installation or registration: https://www.iteraplan.de/en/editionen/online-demo/


Environment - 77 Company Link Consulting

PR

Tool EAMS

Company Link Consulting was created at the end of 1998 as a company with clearly Bio marked innovative characteristics, congregating nowadays about two hundred highly qualified and motivated collaborators, with a vast knowledge of the market and its companies. Since its creation Link Consulting has been a differentiating factor in the Portuguese society, reaffirming it is possible to create wealth in the national territory with Portuguese people, Technology and Innovation. www.linkconsulting.com

OO

Tool EAMS was created as a result of research over a decade in the attempt to Bio solve the fact that manual diagrams tend to required too effort to be kept upto-date over time, thus leading to the abandon of Enterprise Architecture projects. Thus in EAMS all diagrams are generated on-the-fly based on information gathered from multiple repositories/tools, Manual diagramming is an external task that can be done in external modelling tools and then imported into EAMS. Thus EAMS does not provide you a graphical modelling interface as information input. Another aspect is that in EAMS all generated diagrams have a time slider, so one can see the contents of that diagram to change over time according to the planned or occurred changes. The result is that in EAMS, the faster the organization changes, the easier is to keep the Enterprise Architecture up-to-date, since it is fuelled by change plans, that can be be expressed in a collection of models they be in BPMN, UML, Archimate, of in textual data (eg Excel) or both. www.linkconsulting.com/eams

F


78 - Environment Company mega

PR

Tool HOPEX Solutions for Enterprise Architecture

Company MEGA helps organizations manage enterprise complexity. In a fast-paced and Bio disruptive business environment, organizations must be forward-looking and agile to

Tool Bio

OO

adapt to rapidly-changing markets, technologies, and regulatory requirements. MEGA offers them powerful solutions for managers to make the right decision, govern their operations and strike the right balance between innovation, cost, and risk. Through a fully integrated set of software solutions called HOPEX – coupled with consulting services that have been recognized by customers and industry analysts for years – we help organizations address corporate governance challenges and implement successful IT strategy delivery and digital transformation programs. MEGA’s innovation is driven by customer success in achieving their business goals. And MEGA is proud to have earned a loyal customer base spanning over 40 countries. No matter where their company operates, customers will find a MEGA office or a trusted partners near to support their business development. MEGA has operations in nine countries across North America, Latin America, Europe, North Africa, and Asia, as well as 20+ business partners around the world. • More than 2,800 corporate and government customers • 80,000+ users in 40+ countries • Founded in 1991, Privately-held, independent company • 300 employees, 100+ specialized consultants • 9 subsidiaries, 20+ distribution, solution, and technology partners worldwide MEGA’s HOPEX solutions, powered by a single integrated platform, bring together industry-leading best practices in enterprise architecture (EA), business process analysis (BPA), IT portfolio management (ITPM), and governance, risk, and compliance (GRC). The platform offers an easy-to-use, collaborative, multilingual workspace backed by a single repository. Users access the platform through a unified, rolebased, web browser interface that provides just enough of the tools, information and reports they need to be effective and ease decisions. They receive support and guidance at every step of their programs through the platform’s services, repository administration, and technical configuration capabilities.

F

The HOPEX platform wrong-foots the “best-of-breed” approach to enterprise architecture tooling in the digital era: it fosters synergies and collaboration across silos and allows the enterprise architect to easily reach new audiences, while speaking the language of the business. Every user can work towards the same goal to support the organization’s strategy and focus on delivering business value.


Environment - 79 Company MooD International

PR

Tool MooD® 15

OO

Company MooD International is headquartered in York, UK, with additional UK offices Bio in London and Bristol. With its MooD software platform, the company works directly and through partners to deploy customer solutions that improve performance of large, complex, information & people-intensive missions, programmes and service portfolios. MooD-driven solutions drive business outcomes by providing transparency and control to inform and evidence decision making for improved transformation and delivery performance. Achievement of outcomes is evidenced through gains in deployment of cost and capital. The Company’s direct customer base extends across the UK, EMEA and USA. It achieves global reach through alliances with a number of major industry players who integrate the MooD platform into their own market offerings to deliver business model-enabled solutions, extending their market reach and strengthening their business portfolio. In recent years MooD solutions have been instrumental in delivering efficiency gains and savings to the tune of hundreds of millions of pounds to the British Government and to the economies of major enterprises. It provides solutions to the defence, central government, commercial sectors, national security communities and to other sectors via industry alliances. Tool MooD is an architecturally-driven software platform that enables MooD Bio International, its partners and customers to rapidly configure solutions to address business problems specific to an industry or an individual organisation. In each case the key objectives are to improve transparency and dialogue about business performance, to allow investment-level decision making to be connected through into operations, and to make the 'ropes touch the ground'. A MooD solution is driven by an Enterprise Business Model that captures domain knowledge of the moving parts of an enterprise, in terms of what really drives what in a business - a dynamic, layered, risk-focused model that accommodates both human judgement and hard data. The causal and probabilistic algorithms in a MooD Enterprise Business Model capture understanding about how a business should or could be working, and enable a ‘trade and balance’ approach to decision making. This decision process, including how best to respond to priority issues, either in the near term (hours, days) or longer term (months and years), so as to retain alignment with target outcomes.

F


80 - Environment Company No Magic

PR

Tool MagicDraw 18.0 LTR

OO

Company One of the most respected providers of standards-compliant modeling, Bio simulation, and analysis offerings in the industry celebrates its 15th year anniversary. No Magic’s Cameo™ Suite includes support for modeling (people, business, processes, systems, systems-of-systems, hardware and software), requirements management, enterprise architecture, simulation and model execution, data modeling, parametrics, compliance, testing, asset management, model driven architecture, code generation, reverse engineering, documentation and publication, and systems modeling. The Cameo Suite with award-winning, OMG® standards-compliant products allows users to efficiently model organisational structure, business processes, compliance, applications, information and technology. MagicDraw® supports multiple domain-specific models based on UML® including: BPMN, SysML, DoDAF/MODAF/UPDM/UAF, MDD, SOA, unit testing, data modeling and more. Professional services include training, consulting, custom applications and MagicDraw® product customizations such as custom modeling domain diagrams, requirements management, team collaboration, design and analysis. No Magic, Inc. is headquartered in Allen, Texas with operations worldwide. More information can be found by visiting http://www.nomagic.com or http://www.magicdraw.com Tool The company’s flagship, MagicDraw encompasses a wide variety of offerings Bio spanning from model-based UML drawing tools (Personal Edition) to the team-based software design environment featuring code, engineering, model transformations and visual differencing (Enterprise Edition and Teamwork Server). MagicDraw® supports multiple domain-specific models based on UML® including: BPMN™, SysML™, fUML, DoDAF/UPDM/UAF, MDD, SOA, unit testing, data modeling, simulation and activity-based model-driven costing.

F


Environment - 81 Company OpenText

PR

Tool OpenText ProVision 9.1

Company OpenText (NASDAQ: OTEX, TSX: OTC), founded in 1991 with 2012 Bio revenues of US$1,207.5m is the leader in Enterprise Information Management (EIM). EIM enables organisations to grow their business, with lower costs of operation, and reduce information governance and security related risks. OpenText focuses on the key drivers of business success to improve business insight, strengthen business impact, accelerate process velocity, address information governance and provide security. OpenText is unique among its peers in providing leading solutions for Architecture, Business Process Management, Enterprise Content Management and Customer Experience Management. Tool OpenText ProVision is a market leading business architecture, process modeling, and analysis tool providing the ability to discover, model, analyze, and optimize your Bio business enabling you to make smarter decisions when considering changes or the

OO

impact of change on your organisation. With OpenText ProVision, both business and IT personnel can work seamlessly together to create rich models, supporting initiatives such as mergers and acquisitions, business transformations, ERP implementations and upgrades, process excellence and Enterprise Information Management. The ability to take the guesswork out of business change and process improvement plans by performing a thorough analysis of proposed changes before they are implemented helps to minimize risk and ensure faster time to value. Business users, business architects, enterprise architects, business analysts, business process analysts, Lean and Six Sigma belts as well as system analysts use OpenText ProVision. Some of the key uses of OpenText ProVision in supporting the initiatives outlined above include:

F

• Capturing, documenting, connecting and analyzing business processes and procedures • Connecting process information with strategies, goals, objectives, organisations and projects • Identify gaps and producing plans and roadmaps • Communication of process and procedure information across organisations • Ensuring compliance requirements are met with regard to risks and governance • Supporting the transition to automation where appropriate • Generating business requirements and providing traceability • Identify and quantify the impact of business or process change alternatives OpenText also offer an expanded collaboration server and repository - OpenText Knowledge Exchange provides an extended ability for larger teams of OpenText ProVision users to work together. OpenText Knowledge Exchange also enables users to build, manage, update, share and collaborate on OpenText ProVision models via the web - enabling globally-distributed teams to work together on a common, modelbased view of their enterprise. It is designed to better support the scalability and productivity challenges encountered by large architecture programs, which often need to support thousands of users. (OpenText Knowledge Exchange is not required for individuals or smaller teams, where the inbuilt OpenText ProVision repository is generally sufficient).


82 - Environment Company Orbus Software

PR

Tool iServer

Company Headquartered in London, and founded in 2004, Orbus Software is an Bio independent software vendor and a leading global provider of software solutions for Enterprise Architecture, Business Process Analysis and Application Portfolio Management. Tool iServer is an easy to use, collaborative enterprise modeling environment that Bio extends and enhances the Microsoft Office and Visio products. Core components include Microsoft Visio as the diagramming interface, a powerful central repository for all enterprise architecture or business process models and documentation, and a range of tools for presentation, analysis and decision making.

OO F


Environment - 83 Company Pragmatica Innovations

PR

Tool Data Enabled Enterprise Modeler (DE2M)

Company Pragmatica Innovations (PI) creates more efficient and profitable enterprises. Unlike Bio companies that start by managing documents, improving processes or building

OO

software - our team begins with the foundations of these solutions. We provide a complete understanding of the information that builds the requirements for successful and robust business capabilities. Using the doctrine of pragmatism, our team applies architectural rigor to all its solutions. It makes no sense to try to improve, using new expensive tools and software, what is fundamentally flawed – bad information. Information is the tool of management decisions and world-class operations. Our products and services are built based on how information is generated, transformed and shared in an organization. Within every solution is the same persistent information built into a strong architecture that can survive organizational change, new requirements and products, even mergers and acquisitions. New programs and procedures do not fail by themselves. They fail because they are hastily built without a full understanding of what they are supposed to do. With a solid understanding of the information that must be managed we can improve business management services, create collaborative environments, provide ways to visualize complex information that help make objective resource decisions and show how information becomes data and data becomes decisions. We are confident because we have created a complete approach (the 42 way). We designed and integrated frameworks (42 framework) to capture the information; developed a tool (DE2M) to model it both visually and within a database; pioneered methods to generate solution requirements from repeatable models and synthesized a complete business management model and platform (PrISM) that integrates the software investment you have already made. We continuously strive for the most practical means to accomplish our work! We work with each customer and partner to ensure their self-sufficiency - always including our unique ethical perspective on contributing to an environmentally sustainable future.

Tool DE2M is an enterprise level modeling solution that integrates Microsoft Visio with a relational database to “data enable” your diagrams. Bio

F

Use Microsoft Visio to model information such as business processes, network diagrams, system architecture, facility architecture, or organisational constructs and consolidate this information, analyze, manage, and control it using DE2M. View and edit the combined information and diagrams online through a securitycontrolled central web accessible repository or take your data offline to work in an isolated environment and then synchronize back to the repository later. Full support to model and analyze all enterprise architecture frameworks with the power and extensibility of customizing attributes and adding new objects entirely. DE2M comes with many stencils to get you started and we also sell stencils for DODAF 1.5, DODAF 2.0 and more. Make your data work for you with complete dashboard support and powerful business intelligence Go from existing data to diagrams with the ability to import several formats of Microsoft Excel worksheets and other data and then use DE2M’s powerful and customizable Auto-Draw feature to meet the modeling methodology of frameworks or even fit for purpose modeling rules that you can define.


84 - Environment Company QPR Software Plc

PR

Tool QPR EnterpriseArchitect

Company QPR Software Plc (Nasdaq Helsinki) provides solutions for strategy execution, Bio performance and process management, process mining and enterprise architecture in over 50 countries. Users of QPR Software gain the insight they need for informed decisions that will make a difference. With 25 years of experience, 2 000 customers and over a million licenses sold, QPR’s products are highly regarded by industry analysts and customers alike.

OO

Tool All organizations have operations consisting of people, processes and IT Bio systems. Smart organizations improve their operations, and the smartest ones do it with QPR EnterpriseArchitect. When you need to be faster in an ever changing environment, QPR EnterpriseArchitect helps you gain the capabilities needed to analyze, plan and improve your business. Intuitive and easy to use, both business and IT users prefer QPR EnterpriseArchitect to help them ensure that operations are aligned with strategy. 3 key differentiating aspects with QPR EnterpriseArchitect: • Professional enterprise architecture, easy process modeling, analysis, ABPD (Automated Business Process Discovery), and performance management in one modular product suite. All products have an open metamodel and integrated methodology, and they support both logical level modeling and monitoring of actual performance. • Web-based collaboration portal makes enterprise architecture available to everyone, supporting interactive contribution and involvement in the actual context (action management with workflow). Embedded analytics allows discovery of usage patterns and volumes. • Microsoft Office compliance: user interface look & feel and out of the box integration with Microsoft Excel, PowerPoint, Visio, Word and SharePoint.

F


Environment - 85 Company qualiware

QEA

PR

Tool

Company Bio

Tool Bio

Declined to be included

OO F


86 - Environment Company Modeliosoft/Softeam

PR

Tool Modelio BA

Company Model-Driven since 1989 Bio Modeliosoft (www.modeliosoft.com ) provides enterprise solutions based the limitless modelling capacities of Modelio. Modelio is developed and maintained by Modeliosoft. Based in Paris, France, Modeliosoft provides training and consulting in EA, BPM, IT, software modeling and MDA tool customization to adapt Modelio to specific contexts and organisations. Its international support team and its network of partners can help make a project successful throughout the world. Modeliosoft is (100%) part of the SOFTEAM group (920 engineers).

OO

Tool Modelio is the result of 22 years of experience in modeling, methodology, and Bio case tool architecture. Modelio has been designed to make modeling a pleasure, through its efficient ergonomics, its built-in consistency checks, its internal MDA capacities and its model management features supporting the organisation of large-scale distributed models for large distributed teams. Modelio BA is a Modelio toll dedicated to Business Architecture, including Enterprise Architecture. (http://www.modeliosoft.com/en/products/modelioba-for-business-analysts.html) Key Features • • • •

• •

• •

F

Data modeling, Application Architecture modeling, Business Architecture modeling, Business process modeling… On the shelf TOGAF modeling support. MODAF, DoDAF and NAF support. Integrated support of Requirement analysis, Goal Analysis, Risks, Business Rules, and glossary Federated repositories support, enabling Enterprise architecture modeling across federated enterprises, independent BUs, or enterprise ecosystems (partners, customers, …). Distributed repositories allow an open access and referencing between repositories (similar to the WEB). This World Wide Modeling technology is unique on the market. WEB based administration, stakeholder’s roles management, federated repositories management. View configuration per role, project portfolio management. Integrated support of UML, BPMN, TOGAF, standard. Archimate alignment. Global traceability and impact analysis support, from goals and requirements to solution modeling. Customizable document generation: MS Word, WEB/HTML, Excel. Customizable tool: adapting the metamodel, changing the diagram types, having dedicated document generation, coupling with other tools, …


Environment - 87 Company Software AG

PR

Tool Alfabet 9.10

OO

Company Software AG empowers customers to innovate, differentiate and win in the Bio digital world by offering the world’s first Digital Business Platform. This service-oriented and event- driven platform enables modernization of existing systems, consolidating them on-premises and in the cloud into a single platform that optimizes businesses and delights customers. With Software AG, organizations can rapidly build and deploy digital business applications to exploit real-time market opportunities, get maximum value from big data, make better decisions with streaming analytics, achieve more with the Internet of Things, and respond faster to shifting regulations and threats with intelligent governance, risk & compliance. Building on over 40 years of customer-centric innovation, the company offers solutions that are vendor-neutral and deliver faster time-to-value by combining proven products, process blueprints and fast implementation paths to address vertical and horizontal business needs. It is therefore ranked as a “leader” in more than a dozen market categories by the industry’s top analyst firms. The Digital Business Platform is built of best-of-breed product families: Adabas-Natural, Alfabet, Apama, ARIS, Terracotta and webMethods. Software AG has more than 4,400 employees in 70 countries that serve 70% of the Fortune 1000. The company was founded in 1969 and is headquartered in Germany.

F

Tool Alfabet is a high-level, out-of-the-box, cloud-capable and mobile-enabled Bio application service of Software AG’s Digital Business Platform. It helps IT decision-makers make better IT investment decisions and reduce transformational risks by understanding when, where, how and why to make changes in the IT portfolio. It links the interdependent perspectives of IT, business, finance and risk for “whole view” analysis of how IT can support business change. Enterprise architecture capabilities build the necessary foundation with an accurate, real-time picture of the IT landscape - including all applications and technologies, the inter-relationships between them, the information they exchange as well as the business capabilities and processes they support. Alfabet’s portfolio management capabilities support independent portfolio decision-making for optimization of individual portfolios as well as portfolio-level strategy modelling to incorporate all portfolios into strategy formulation. Its collaborative planning platform enables all stakeholders to interface, communicate and consider multiple perspectives when making transformation decisions as well as prioritize project proposals based on alignment with business strategy.


88 - Environment Company Sparx Systems

PR

Tool Enterprise Architect 12

Company Sparx Systems specializes in high performance and scalable visual modeling Bio tools for the planning, design and construction of software intensive systems. With customers in industries ranging from aerospace and automotive engineering to finance, defense, government, entertainment and telecommunications, Sparx Systems has won seven consecutive SD Times awards and is the leading vendor of innovative solutions based on the Unified Modeling Language (UML) and its related specifications. A Contributing Member of the Object Management Group (OMG), Sparx Systems is committed to realizing the potential of model-driven development based on open standards. The company's flagship product, Enterprise Architect, has received numerous accolades since its commercial release in August, 2000, including two Jolt and Visual Studio Magazine Reader's Choice Merit awards. Now at version 12, Enterprise Architect is the design tool of choice for over 380,000 registered users world-wide.

OO

Tool Enterprise Architect is an award winning visual platform for designing and Bio constructing Software, Business and Real Time systems. Enterprise Architect is ideally suited for describing the structure of an enterprise, with support for leading architecture frameworks including TOGAF, UPDM and Zachman Framework. Describe organisational structure and management controls, develop strategic models, compare changes to established baselines, visualize hardware deployment, optimize business processes and create a shared vision of the enterprise using a team based, collaborative modeling tool.

F


Environment - 89 Company SAP

PR

Tool SAP Sybase PowerDesigner V16.5

Company SAP is at the center of today’s technology revolution, developing innovations Bio that not only help businesses run like never before, but also improve the lives of people everywhere. As the market leader in enterprise application software, we help companies of all sizes and industries run better. From back office to boardroom, warehouse to storefront, desktop to mobile device - SAP empowers people and organisations to work together more efficiently and use business insight more effectively to stay ahead of the competition. SAP applications and services enable more than 248,500 customers to operate profitably, adapt continuously, and grow sustainably.

OO

Tool Take charge of change with collaborative, model-driven architecture and Bio design. Visualize, understand, and manage the impact of change to your enterprise system before it happens - with SAP Sybase PowerDesigner. This end-to-end tooling software supports model-driven architecture (MDA) design with industry-standard modeling techniques, a powerful metadata repository, and unique link and sync technology - so you can respond to change with confidence.

F


90 - Environment Company Troux

PR

Tool Troux Enterprise Portfolio Management

Company Troux helps the world’s leading commercial and government enterprises make better decisions, faster. Using Troux, business leaders can connect business context to IT and gain new levels of Bio visibility and management control over key areas of their business. Troux delivers transparency

that empowers business leaders with a real-time view into the IT assets spread across their company. Troux-powered data visualizations and analytics illustrate how IT supports corporate goals, strategies, and core business processes. The result: business leaders better understand which IT assets are needed to function, operate and grow their business, and make wellinformed investment and divestment decisions. Troux’s suite of Enterprise Portfolio Management (EPM) products help business leaders make

Tool more informed decisions that lead to reduced costs, decreased risk and improved agility by Bio ‘connecting’ business context to IT. Troux EPM products help decision makers gain valuable

OO

insights into the key portfolios (areas) that characterize a business. This transparency delivers executives with a clear, real-time view into their assets (tangible and non-tangible) and illustrates how and where they are used across their business. With Troux decision makers are able to quickly see how these assets support corporate goals, strategies, and core business processes. The result, business leaders have the ability to better understand which assets are required to operate and grow their business and which are not; and decisions that affect the business can now be consistently made on facts rather than opinions. Troux’s suite of EPM Products include: TrouxSource Platform • Contains a best-in-class Meta-model that characterizes a business by organizing and connecting key data elements into IT and business related portfolios. • Provides a centralized repository to store important enterprise data. • Provides data collection tools that facilitate and manage the import of key information from a variety of existing applications and systems. • Supports the export of key data to 3rd party business intelligence tools or data marts for additional reporting. Troux Navigate • Supports the ability to browse, search, edit and report against data stored in Troux’s centralized repository (Troux Source). • Provides the ability to cascade deeper into key reports to gain additional action-oriented details behind the summary values. • Built-in data stewardship capabilities support the ability to federate the management and maintenance of information assets on both an organisational and individual level. Troux Insight • Provides a powerful interactive and ad-hoc analysis engine for business analysts. • Library of preconfigured visualizations called ‘perspectives’ help decision makers quickly analyze and identify risk areas, as well as, opportunities for cost savings and investment re-alignment. • Supports the ability to perform data management and maintenance en masse against large data sets. Troux Architect • Provides a visual modeling environment to create models and quickly understand the connections and dependencies between portfolio elements. • Delivers rich visual models that represent the current state of organisations, processes, information, technologies and their relationships. • Supports scenario-based alternatives modeling and analysis of current to future state transformation.

F

Ability to create new objects and relationships in the Troux repository (Troux Source).


Environment - 91 Evaluation Requirements

OO

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.

F


92 - Environment A. Importing 1

Can .CSV be used as a source?

PR Can .XML be used as a source?

3

Can .XLS be used as a source?

4

Can .MDB be used as a source?

5

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

6

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?

7

Can .VSD be used as a source?

8

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

9

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

10

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

11

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

12

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

13

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

OO

2

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

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

16

Is this hierarchical information imported as entities linked by relationships?

17 Can other types of relationships supported be imported? 18 Can the tool handle conflicts? 19

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 20 relationships stored outside the tool (e.g. CMDBs, portfolio management tools, change management tools)?

F


Environment - 93 B. Exporting 1

Can .CSV be used as a target?

PR 2

Can .XML be used as a target?

3

Can .XLS be used as a target?

4

Can .MDB be used as a target?

5

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

6

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?

7

Can .VSD be used as a target?

8

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

9

Can other types of relationships supported be exported?

C. Relationships

Are relationships a fundamental type?

2

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

3

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

4

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

5

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

OO

1

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

2

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?

3

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

4

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?

F

1


94 - Environment E. Diagrams / Views 1

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

PR

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

3

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

4

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

5

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

6

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

7

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

8

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

9

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

10

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

11

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

12

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

OO

2

13 Are all predefined entities provided with associated graphics?

14 Are all predefined relationships provided with associated graphics? 15

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

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

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

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?

19

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

Can I automatically navigate the data at varying levels of detail where the 20 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?

22

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

23

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

24 Can I use "layers" on diagrams?

F

21

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


Environment - 95 (see “Expected Views & Expected Dashboards” Sections) 26

PR

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

27

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

28

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

29

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

30

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?

2

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

3

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

OO F


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

2

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

3

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

4

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

5

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

6

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

7

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

8

Can I change the Meta-model visually?

9

Can I add and remove new entities?

OO

PR

1

10 Can I add and remove new relationships?

11 Can I add and remove attributes to existing and user defined entities? 12 Can I add and remove attributes to existing and user defined relationships? 13 Is the Meta-model totally flexible or are there limitations? (If so what are they?) 14 Can attributes be simple (e.g. text, number, list, date, money)? 15

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

16 Can attributes be complex (e.g. an attribute consisting of a group of attributes)? 17 Can I automatically navigate the model using TOGAF as a navigation structure? 18 Can I automatically navigate the model using Zachman as a navigation structure? 19 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?

2

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

F

1


Environment - 97 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?

3

Is it possible to "check out" partial models?

4

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

5

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

6

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?

7

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?

2

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

3

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

4

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

5

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

6

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

7

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

8

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

9

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

OO

1

10 Do you have any out of the box integrations with 3rd party BI tools? 11 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.

13

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

14

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

F

12


98 - Environment K. Expected Views (Does the tool provide answers to these questions)

PR 1

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

2

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

3

What is the split between COTS and bespoke applications?

4

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

5

What applications support a business function?

6

What applications are not covered by a DR plan?

7

What applications or technologies are candidates for rationalisation

8

What applications are the most costly (value based)

9

What applications are the most important to the business

10 What are the transition plans for an application / process / etc 11 What are the recurring costs of an application 12 How critical is an application to a business process

OO

13 How many users depend on an application

14 What is the usage profile/roadmap for an application 15 What skills are required to support an application

16 Which applications have the greatest impact on the business

17 Who are the business and technical owners for an application 18 Who are the owners of applications with no DR plans 19 Who is using an application

F


Environment - 99 L. Expected Dashboards (Does the tool provide these dashboards)

PR 1

Executive Dashboard: Project Portfolio Impact Executive Summary

2

Executive Dashboard: Demands Executive Summary

3

Executive Dashboard: Portfolio Complexity Summary

4

Executive Dashboard: Goals and Strategy Executive Summary

5

Executive Dashboard: Spend Alignment Executive Summary

6

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

7

Business And IT Executives: Business Demand

8

Business And IT Executives: Projects alignment to strategies

9

Business And IT Executives: Spend related to business need

10 Business And IT Executives: Programmes and projects roadmap 11 Programme and Financial planners: Applications related to Business Capability 12 Programme and Financial planners: Enterprise Application Roadmap

OO

13 Programme and Financial planners: Spend related to Business value 14 Enterprise architects: Analysis of interrelationships 15 Enterprise architects: Model Enterprise

16 Enterprise architects: Ensure data is complete and accurate and up to date 17 Enterprise architects: Define Future State

18 Enterprise architects: Plan State transitions

19 Enterprise architects: Principles and policies related to goals and objectives 20 IT: Understand technology roadmap 21 IT: Analysis of interrelationships 22 IT: Impact Analysis 23 IT: Manage risks

F


100 - Environment Demonstrations

PR

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

OO

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 Show Relationship matrix editor

D. User Interface / Ease of use

F

Show Pan and zoom

Show Viewer for freeform navigation of the model


Environment - 101 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; Technology, Governance

Strategy,

Environmental,

Business,

Information,

Show Meta-model navigation/discovery Show Making changes also Types of complex sets/groups of data

OO

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 Show Workflow

Show Management of inconsistent/missing/invalid imported data Show Syntax, semantic and consistency, and completeness reports

F


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

OO

Show XC6. Flexible Notation Show XC7. Tool Integration

Show XC8. Concerns & Viewpoints XF - Tool Functionality

Show XF1. Meta-Data Inheritance Show XF2. Dangling Relationships

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

F


Environment - 103 Process

OO

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.


104 - Environment Raw Scores

OO

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

F


Environment - 105 Weighted Scores

OO

PR 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 Is this What weighting criteria fair?

If not, what weighting criteria will you use?

F


106 - Environment X-Requirements

OO

PR The following are provided as 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. They are split into three distinct sections: XA - Tool Architecture

How the tool is fundamentally architected and engineered. This is important because if thatâ&#x20AC;&#x2122;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.

F


Environment - 107

XA - Tool Architecture

PR XA1. Single Object Table Description

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

Rationale

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

Rationale

Without modelling relationships as 1st order entities a tool fails as a real architecture tool (a la IEEE 1471). These sorts of convoluted designs smack of being a kludged together Object-Oriented (OO) approach with objects being the only element of interest. Most likely relationships on the diagrams were an afterthought to be stored in the repository with some serious implications including the next few criteria

OO

Description

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.

Rationale

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.

F

Description


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

Rationale

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.

PR

Description

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.

Rationale

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.

OO

Description

XA6. Time as a Fundamental Description

The repository should:

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 version of architectures / scenarios c) Allow for relationships to exist between them rather than just storing different scenarios as separate repositories that cannot be related.

Rationale

EA Modelling tools are built to allow Enterprises to transform things. This basically consists of modelling the structure of the Enterprise at various points in time. It is therefore paramount to be able to model relationships between these “different” 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 EA modelling tool.

F


Environment - 109

XC - Tool Configuration and Maintenance

PR XC1. Bulk Upload Description

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 copypasting data into forms or requiring professional services support.

Rationale

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 Description

OO

Rationale

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. Based on the premise that “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.

XC3. Open ERD Description

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.

Rationale

If the datamodel (which may or may not include its relationships) is either nonexistent 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.

F


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

Rationale

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.

PR

Description

XC5. Hybrid Metamodels

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

Rationale

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

OO

Description

XC6. Flexible Notation Description

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 other convoluted edit of a cryptic configuration file.

Rationale

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

F


Environment - 111 XC7. Tool Integration The tool should provide the ability to seamlessly integrate with other tools and to 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.

Rationale

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.

PR

Description

XC8. Concerns & Viewpoints Description

OO

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

Rationale

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.

F


112 - Environment

XF - Tool Functionality

PR XF1. Meta-Data Inheritance Description

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.

Rationale

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

OO

Description

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.

Rationale

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

Rationale

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.

F

Description


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

Rationale

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.

PR

Description

XF5. Analytic Charts Description

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

Rationale

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

OO

XF6. Quantitative Analytics Description

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

Rationale

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, or b) Options - Analysing differences between states at the same point in time - for the purpose of selecting which one is more appropriate. c) Both of the above at the same time.

F


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

Rationale

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.

PR

Description

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.

Rationale

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.

OO

Description

F


Adoption - 115

PR ADO PTION

OO

The Adoption of PEAF is, in itself, a transformation. Therefore PEAF adoption is accomplished by the use of EMMA, MACE and MAGMA - which combine to form the PEAF Maturity Model.

F


116 - Adoption Motivation

OO

PR If there is no reason, no motivation, for us to increase our maturity, and if we do not articulate that to the correct audience, we will not obtain the mandate to do so and will therefore fail before we have even started. Here we look at the Motivation behind transforming our Methods, Artefacts, Culture and Environment.

F


Adoption - 117 Environment Tools Types

OO

PR “Tools are expensive and cost a lot to procure and maintain, can’t I just use Excel and Visio?” 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 Structure (Methods, Artefacts, Culture, Environment) 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.

F


118 - Adoption

OO

PR

It is imperative that all the entities and their associated attributes be gathered together in one place so that there is one version of the truth and so that relationships between these attributes can be defined. The driving force, therefore, behind the use of a tool is to reduce and minimize the maintenance and management overhead of a no tool based (manual) approach. Whilst initially a 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. We have already reached (and gone past!) this tipping point.

F


Adoption - 119 There are 3 basic types of tools that we could use with various pros and cons: Visio and Excel

Custom Tool

Description

Visio diagrams. Excel spreadsheets. No linkage between them.

Visio diagrams. A DB (e.g. Access). Entities on Visio diagrams linked to DB tables.

A tool specifically designed for the task.

Training Requirements

None.

Some needed around DB and Visio data linkage.

Extensive.

Diagram to entity and relationship management

As there is no linkage between the diagrams and the data, maintenance of the diagrams is therefore manual. Diagrams have to be drawn manually.

Linkage from entities on diagrams to entities in the spreadsheets is possible but the relationships (where most of the value lies) are still manually maintained.

Automatic.

Consistency

Since the data is separated in sheets there are no consistency checks resulting in manual changes when anything changes that is entered on one sheet and referred to on another. Especially true of relationships.

Consistency can be automatically managed though primary and foreign key combinations and list field although the keys have to be defined and set up manually.

Automatic.

Cost

Minimal as Visio 2003 (or above) and Excel licenses have already been purchased.

Small. Visio and DB licenses are required which we may already have. Possible cost of $3k.

Medium Possible initial cost of $40k+, with subsequent costs dependent upon the size of the Enterprise.

OO

PR

Visio and DB

F


120 - Adoption Issues

Ability to Use Information

OO

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.


Adoption - 121 Effort to Maintain Information

OO

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.


122 - Adoption Fundame ntal s

OO

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

- Kevin Smith

F

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 - 123 Can I use my CMDB?

OO

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

F


124 - Adoption Can I use my CMDB

Technical Content

OO

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 and Culture). The Strategic information required to support and drive Strategising and Roadmapping.

F


Adoption - 125 Entities

OO

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

F


126 - Adoption Attributes

OO

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

F


Adoption - 127 Actions Constructing Environment Select an EA Model ling Tool

OO

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

Send RFI to Tool Vendors. Evaluate responses and shortlist 5-6 Tool Vendors. Organise and Attend Tool demonstrations. Evaluate demonstrations and select a â&#x20AC;&#x153;Final 3â&#x20AC;?. Create the RFP. RFP

Source

F

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.


128 - Adoption Transitionin g Environment Roll out EA Modelling Tool

OO

PR Installation

The EA Modelling toolâ&#x20AC;&#x2122;s hardware and software are installed and commissioned. Training

Appropriate training is performed.

F


Appendix - 129

PR APPENDIX

OO F


130 - Appendix Background

OO

PR F


Appendix - 131 Why Were They Created?

OO

PR

Because I care. Because I care about Enterprises. Because I care about the people who Direct, Operate, Transform and Support Enterprises. Because I am angry about how much time is wasted. Because I am angry about how much money is wasted. It doesnâ&#x20AC;&#x2122;t matter if your currency is the Afghani, Baht, Balboa, Birr, Bolivar, Boliviano, Cedi, Colon, Dalasi, Denar, Dinar, Dirham, Dobra, Dollar, Dong, Dram, Escudo, Euro, Forint, Franc, Francs, Gourde, Guarani, Guilder, Hryvnia, Kina, Kip, Koruna, Krona, Krone, Kuna, Kwacha, Kwanza, Kyat, Lari, Lats, Lek, Lempira, Leone, Leu, Lev, Lilangeni, Lira, Litas, Loti, Manat, Marka, Metical, Naira, Nakfa, Ngultrum, Oro, Ouguiya, Pa'anga, Pataca, Peso, Pound, Pula, Quetzal, Rand, Real, Renminbi, Rial, Riel, Ringgit, Riyal, Ruble, Rufiyaa, Rupee, Rupiah, Shekel, Shilling, Sol, Som, Somoni, Sterling, Sucre, Sum, Taka, Tala, Tenge, Tugrik, Vatu, Won, Yen or Zloty, I guarantee you are wasting it. Big time! This work was inspired by all those who seek to make the world a better place rather than those that seek to own it.

F


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

PR

Seeing why people fail What problems they encounter Providing things to reduce the risk of others failing in the same way Providing things to alleviate the problems people have.

Around 2002 I began to be interested in something called “Enterprise Architecture”. The term started to appear more in publications and people started to talk about it more although from listening to them there never seemed to be a concrete definition of what it actually was that everyone agreed with (some say that’s still the case today!). Using logic and common sense I could surmise that it was not Project level Architecture (because that already had a name - Solution Architecture) and therefore it must be something at a “higher level” - not just bigger. Something related to: What goes on before projects execute and before Solution Architects start working on those projects. Enterprise Centric, or more specifically Enterprise Transformation Centric, rather than Project Centric and/or IT Centric.

OO

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

So, I consulted the mighty Google (sorry Oracle!). Google told me about something called Zachman and something called TOGAF. And so I went off to investigate further. From what I could tell, Zachman’s message seemed to resonate well with me in terms of general thinking I had built up over the preceding 20 years, namely: You can’t change what you can’t see - hence the need to model things - in a structured way. There must be Phases involved in Transformation to get from Strategic intent at the top down to real physically deployed things at the bottom.

F

These basic messages haven’t changed and are as valid today as they always were - although the important distinction between Enterprise Architecture and Enterprise Engineering that Pragmatic makes today was not (and still is not) recognised in Zachman (despite my attempts to do so). But, whilst these fundamental things (modelling and phases/levels) were a good start, they were much too high level to provide any practical help in using them (which is what a framework is supposed to do) and so I invested more time looking into the much more detailed TOGAF. As I looked into TOGAF, the first thing that struck me was “Where the hell do I start?”. The material was immense, complex, confusing, very dry, hard to consume and offered no guidance about how to adopt it. So, assuming it was my ignorance that was the problem I booked myself on a TOGAF course. Within the first 2 hours of the first day it became clear that it was centred around Project level IT centric Architecture.


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

PR

Fantastic for those Enterprises that had still not figured out that the complexity of the IT landscape had grown to such a level that using Architecture as a discipline on IT Projects (Solution Architecture) was almost mandatory (unless you wanted to waste a shed load of money and deliver a shed load of bad IT to customers), but not Enterprise Architecture. Great for those Enterprise that wanted to formalise their Solution Architecture discipline, but not Enterprise Architecture. Great for those Enterprises that wanted to continue to treat “The Business” as a second class citizen to “IT”, but not Enterprise Architecture. At least not the Enterprise Architecture that logic and common sense dictated to me. Anyway, I got through the course, passed the exams and became TOGAF Certified. Over the next few years I worked at various organisations and my TOGAF certification served me well in terms of getting me job interviews and most of the subsequent contracts. Having got a contract (because I was TOGAF certified) I then endeavoured to first discover how much and what parts of TOGAF were being used. The conversation (over many days, sometimes weeks) usually went something like this:

OO

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

F

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


134 - Appendix

PR

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

OO

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

When Were They Created?

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

F


Appendix - 135

God

Honesty

Integrity

Pragmatism

Altruism

Persistence

Passion

Psychology

Architecture

Engineering

Common Sense

Logic

Auditory

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

Location

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

Biological / Chemical

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

Mechanical

Desk, Chair, Whiteboard (Pens and Eraser).

Electrical

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

H/W

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

S/W

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

Input

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

Output

PF2 Book, POET Book, PEAF Book, PragmaticEA Website

F

Artefacts

Information

Technology

OO

Environment

Methods

PR

Culture

What Was Used to Create Them?


136 - Appendix How Were They Created?

PR

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

Which loosely translates to

OO

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

F


Appendix - 137 Who Created Them?

OO

PR

A simple man. My career began at the age of 16 in 1978 as an Electrical and Electronic Apprentice with Marconi Radar Systems (Blackbird Road, Leicester, UK) At that time I was really into electronics and had been playing with little circuits for a few years. It was really exciting. I spent my time between college and “The Factory” where I got the chance to work in many different departments. It was really exciting. Around 1980 I ended up in a Department (New Parks, Leicester UK) called TEPIGEN (TElevision PIcture GENerator) who had built the visual system for a ship simulator. Six million Pounds of custom built hardware (that had less processing power than the CPU in the phone that’s in your pocket) consisting mainly of four racks of “Picture Processors” (Motorola 68000s) driven by a PDP11. It was really exciting. The output was on three channels each delivering 40 degrees field of view which drove three large Barco projectors. Interestingly at one point there were black speckles that kept appearing on the displays, moving about in random patterns and appearing and disappearing in the same apparently random fashion. After months of software and hardware investigation the problem was identified. It was a test Radar across the apron from where our Portacabins where located that was spraying us periodically with microwaves! It was really exciting. I began my time there hand entering the data which described the terrain and buildings and which fed the picture processors, and wrote my first program in DEC BASIC. Over the next four years or so my programming skills grew, and I moved from BASIC to FORTRAN and then to PASCAL. It was really exciting. The ship simulator turned into a flight simulator which meant it was the biggest video game in the world. It was really exciting. So much so that I would work late into the night (sometimes 48 hours at a stretch) and go into work on Saturdays or Sundays. Right from the beginning it wasn’t so much the code I wrote that I got excited about it was more HOW I wrote the code that interested me. I would often spend hours writing a program and finally get it working, only to tear it to pieces and rewrite it in a new and elegant way, often with more features, less code and more opportunity to reuse things later. It was really exciting. Even at that time I spent more time throwing things away than I spent creating things. I believe this is where progress comes from. Sounds totally counter-intuitive I know, but most things of value are counter-intuitive! Around 1986 the plug was pulled on TEPIGEN and I moved to another department (Fleet, Hampshire, UK) who produced a system called TELEVIEW (an improvement on Teletext and a forerunner of “The Web”) for Singapore’s Telecom Company (SingTel). I had moved on to C as a programming language. The most elegant and powerful language I have ever used. It took me a while to understand it but after reading the perfect “The C Programming Language” (Kernighan and Ritchie) the penny dropped. It was really exciting. A brief spell at SD Scicon (1989-1991) was followed by three years working for Deutsche Bank (Singapore) where I found the best food in the world and where my architectural tendencies came to the fore. It was really exciting. Returning in 1994 I spent six years working for Eurobase Systems (Chelmsford, UK) doing Application Architecture and creating Architectural and programming frameworks. From 2000 to 2011 I spent my time working for various Enterprises as a contractor. While interesting, it wasn’t very exciting, but all the time, whatever domain I worked in I was always interested in improving it. Each time this met a limit and the limit was always as a consequence of things being done less than effectively and less than efficiently in the preceding step. Hence my roles moved from Application Architecture, Data Architecture and Technology Architecture into Technical Architecture (a bit of a misnomer!) then Solution Architecture then Enterprise Architecture and finally the entire Transformation domain.

F


138 - Appendix

PR

Since 2011 I have devoted my time to Pragmatic. It is really exciting. Whilst I have never been an academic person, and never went to university (I have always preferred to “go out and do stuff”) I have recognised over the last year that Psychology plays such a vital role in Enterprise Transformation (for good or bad) and so in February 2014 I began a BSc (Honours) Psychology degree with The Open University. It is really exciting. MBTI

OO

My MBTI is INTJ with a hallmark of Vision and categorised as Independent, Individualistic and Visionary. INTJs tend to be independent-minded, theoretical, and original. They have great drive for their own ideas and purposes. They are sceptical, critical, determined, and sometimes stubborn. In areas of expertise, they will develop systems to organize and carry through a project with or without help. INTJs are typically innovators in their fields. They trust their inner vision of how things fit together and relentlessly move their ideas to action. They would rather spend time on what they believe is important than on what’s popular with others. INTJs are independent and individualistic, and others may see them as stubborn at times. They move ahead with or without the support of others, and they have a single-minded concentration. They like using logic to solve complex, challenging problems. Routine, everyday tasks bore them. They analyse and attempt to fit pieces together into a coherent whole. Although INTJs are usually organized and follow through, they may sometimes ignore details that do not fit with their vision of the future. If these details are important, their ideas may not work as well as they would like. INTJs are likely to be most satisfied in a work environment that values their insights and ideas and lets them work independently. People can count on them for their vision and innovative solutions to problems in their field. Some famous INTJ’s: Isaac Newton (Physicist) - "I can calculate the motion of heavenly bodies, but not the madness of people." Karl Marx - (Philosopher) - "Philosophers have hitherto only interpreted the world in various ways; the point is to change it." Augustus (Emperor of Rome) - "I found Rome brick and left it marble." Isaac Asimov (Science fiction writer and science writer) - "Those people who think they know everything are a great annoyance to those of us who do." Martin Luther (Theologian and Protestant reformer) - "I [am] slave to the authority of no one." Nikola Tesla (Inventor) - "My ideas have revolutionized the industries of the United States." Stephen Hawking (Physicist) - "My goal is simple. It is a complete understanding of the universe."

F


Appendix - 139 DISC

OO

PR

My DISC Profile is 7414 and categorised as Result-Oriented. Result-Oriented people display self-confidence, which some may interpret as arrogance. They actively seek opportunities that test and develop their abilities to accomplish results. ResultOriented persons like difficult tasks, competitive situations, unique assignments, and "important" positions. They undertake responsibilities with an air of self-importance and display self-satisfaction once they have finished. Result-Oriented people tend to avoid constraining factors such as direct controls, timeconsuming details, and routine work. Because they are forceful and direct, they may have difficulties with others. Result-Oriented people prize their independence and may become restless where involved with group activities or committee work. Although Result-Oriented people generally prefer to work alone, they may persuade others to support their efforts especially when completing routine activities. Result-Oriented people are quick-thinkers, and they are impatient and fault-finding with those who are not They evaluate others on their ability to get results. Result­Oriented people are determined and persistent even in the face of antagonism. They take command of the situation when necessary, whether or not they are in charge. In their uncompromising drive for results, they may appear blunt and uncaring. So putting MBTI and DISC together it says that I am a Result-Oriented Independent Individualistic Visionary. Well that about sums me up to a tee. Sounds very grand, but of course, there are always downsides. I am also an Arrogant, Inflexible, Argumentative, Intolerant, Impatient, Critical & Stubborn, Pessimistic Optimist! Different people have different profiles, and different profiles fit into different roles in different ways. We all kind of know this but do we ever take it into account? What are the MBTI and DISC profiles of the people in your Enterprise? Do they all suit their roles?

Have you ever found someone to be a “difficult person” or a “loose cannon”? If so, did their MBTI/DISC profile have any bearing as to how they were treated?

F


140 - Appendix Keypoints

OO

PR F


Appendix - 141

PR

PEAF Foundation training

covers the Operating Model for the whole

Transformation domain. PEAF Certified training

covers the Logical Model

OO for EA.

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

F


142 - Appendix

PR

Be ever vigilant of the hidden confusion that language can create.

The â&#x20AC;&#x153;Business and IT are so

OO intrinsically linked, a new paradigm is needed.

That paradigm is DOTS.

F


Appendix - 143

PR

Think about structuring

your Enterprise in terms of Direction, Operation,

Transformation and Support (DOTS).

OO

Think about Structural

information in terms of

Methods, Artefacts, Culture and Environment (MACE).

F


144 - Appendix

PR

Think about

Transformational

information in terms of Motivation, Actions,

Guidance, Measures and Assessment (MAGMA).

OO

Adopt the seven phases of

transformation: Strategising, Roadmapping, Initiating,

Elaborating, Constructing,

F

Transitioning, Using.


Appendix - 145

PR

Understand the difference between Enterprise

Architecture and Enterprise Engineering.

OO

Strategising is what the CSuite does.

Roadmapping is â&#x20AC;&#x153;doingâ&#x20AC;?

Enterprise Architecture.

F


146 - Appendix

PR

Initiating, Elaborating, Constructing and

Transitioning is â&#x20AC;&#x153;doingâ&#x20AC;? Projects.

OO Use Governance &

Lobbying to connect and

synchronise each phase of Transformation.

F


Appendix - 147

PR

Use the Transformation

cascade to link the phases together.

Apply the Role and Phase

OO

patterns when assigning RACI to roles.

F


148 - Appendix

PR

1. Only model things to answer a question.

2. Treat model population as a Data Migration exercise.

3. Integrate/remove source

OO

data.

F


Appendix - 149

PR

Adopt the seven levels of

transformation: Enterprise Context, Contextual, Conceptual, Logical,

Physical, Operational, Physical Stuff.

OO Ensure Structural

information (MACE) is maintained at different levels of abstraction

F

(Idealisation/Realisation).


150 - Appendix

PR

Methods act on Artefacts that are executed by

Culture (people) or the Environment

(Technologies).

OO Ensure Transformational

information (MAGMA) is maintained at different levels of abstraction

(Idealisation/Realisation).

F


Appendix - 151

PR

The Motivation drives the

creation of Actions and the production of Guidance (which guide those

Actions), all of which are Assessed against the

OO

Measures.

F


152 - Appendix

PR

Ensure a common

understanding of the

domains of the Enterprise

Architecture and Enterprise Engineering models.

OO Ensure that appropriate

information from each level is used for each phase.

F


Appendix - 153

PR

Ensure that the Logical and

Physical levels are populated over time as a deliverable of executing projects.

OO

Map your artefacts to

MACE and MAGMA over the seven layers of

Transformation, to

determine what information is not being captured.

F


154 - Appendix

PR

Enterprise Strategy consists of the Business model and

Operating model set in the Enterprises Context.

Transformation Strategy

consists of the Roadmap

OO

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

F


Appendix - 155

PR

Develop a Hybrid

Metamodel for Enterprise Architecture and

Engineering modelling.

OO

Use POET to plan how all

the tools you use, integrate and work together.

Minimise the number of

F

Tool interfaces.


156 - Appendix

PR

Make sure your EA Tool can deal with Structural (MACE) and

Transformational (MAGMA) information and that it integrates with other

OO

related tools.

Make sure you are aware

of, and consider, all the EA Tool Vendors in the

F

market.


Appendix - 157

PR

Tools that satisfy requirements by

Customisation rather than

by Configuration or Out-ofthe-box, should be avoided.

OO

Be aware that many Tool vendors can be very

economical with the truth.

F


158 - Appendix

PR

Use the X-Requirements as

the key gating criteria when assessing EA Modelling Tools.

OO Weight up the pros and

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

F


Appendix - 159

PR

As the complexity and volume of information grows,

the ability to use the

information can quickly

become impossible unless a

OO

custom EA modelling tool is used.

F


160 - Appendix

PR

As the complexity and volume of information grows,

the effort to maintain it can quickly become impossible unless a custom EA

OO

modelling tool is used.

F


Appendix - 161

PR

You cannot use your

CMDB as you EA modelling tool because their purpose and content are totally different

OO

Use POET and PEAF to

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

F


162 - Appendix Sources & Resources

OO

PR F


Appendix - 163

OO

PR F


OO

PR F

,!7IB9A8-ecefej!


Most Enterprises invest huge amounts of time and effort in battling the storms. Very few spend any resources on preparing the ship. Instead, the call is “all hands on deck” to land the next catch and set the next net. Without proper preparation, every Enterprise is sailing full speed into their own perfect storm. If we are to sail safely in these unpredictable waters we must make preparations and plans to allow us to respond when treacherous conditions face us. For if we wait until that time before we act, it is unlikely that we will survive.

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

Enterprise Architecture Tools A Pragmatic Approach to Selection and Adoption

Kevin Lee Smith

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

A Pragmatic Approach to EA Tool Selection and Adoption

OO

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

Enterprise Architecture Tools

PR

Enterprises have been and will continue to live in a state of flux. A never ending sea of change that buffets them and blows them around, seemingly at random, in an unending churning ocean. Even when it is calm, a storm can blow up “out of the blue” and literally sink the ship at a moment’s notice.

F ISBN 978-1-908424-54-9

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

Kevin Lee Smith The Pragmatic Gardener

Connecting the DOTS

Part of the Pragmatic Family 

Profile for Pragmatic EA Ltd

EA Tools - A Pragmatic Approach to Selection and Adoption  

Many Enterprises already have some kind of EA Modelling Tool, that are being actively used for the purpose of Enterprise Architecture, aka c...

EA Tools - A Pragmatic Approach to Selection and Adoption  

Many Enterprises already have some kind of EA Modelling Tool, that are being actively used for the purpose of Enterprise Architecture, aka c...

Advertisement