EA on LinkedIn - Argument & Apologies, Diatribes & Debates by Pragmatic EA Ltd

EA on

Arguments & Apologies, Diatribes & Debates. Volume I

Kevin Lee Smith The Pragmatic Gardener

https://www.linkedin.com/in/kevinleesmith/

Connecting the DOTS

Part of the Pragmatic Family

EA on LinkedInÂŠ Arguments & Apologies, Diatribes & Debates. Volume I

Kevin Lee Smith

Published by: Pragmatic EA Ltd 25 Buttermere Great Notley, Essex CM77 7UY England http://www.PragmaticEA.com

First published: May 2017 ISBN 978-1-908424-50-1 (hardback ISBN 978-1-908424-51-8 (paperback) ISBN 978-1-908424-52-5 (ebook) © Pragmatic EA 2017

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:

Note: The Pragmatic Ontologies and Frameworks inherit and are therefore dependent upon one another. Understanding each book requires you to have read and understood the books on which it depends.

Book

ISBN 978-1908424-16-7

Enterprise Direction PO E D A Pragmatic Approach using XXXXX

Enterprise Operation PO E O A Pragmatic Approach using XXXXX Enterprise Transformation PO E T A Pragmatic Approach using XXXXX Enterprise Architecture P E A F A Pragmatic Approach using XXXXX

Enterprise Engineering P E E F A Pragmatic Approach using XXXXX

Enterprise Support PO E S A Pragmatic Approach using XXXXX

Prerequisites

978-1908424-19-8 978-1908424-07-5 978-1908424-10-5

POET

978-1908424-13-6

POET

978-1908424-22-8 978-1908424-48-8

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

978-1908424-54-9

Enterprise Debt™ A Pragmatic Approach to Enterprise Transformation Governance

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

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

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

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

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

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

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

Contents

Introduction ............................................. 3 Moderation ...................................................................................................... 4 Format ............................................................................................................. 4

Comments ................................................ 5 Appendix .............................................. 189 Sources......................................................................................................... 189 Resources ..................................................................................................... 189

OO F

Acknowledgements

The author would like to acknowledge and thank the hundreds of people I have had the privilege to cross swords with on LinkedIn© over the years. Even though LinkedIn© is horrible to use, and has less functionality that was available in free bulletin Boards in the 1980s, it does seem to be the place where “professional” people seem to connect and discuss things. Hey ho.

Introduction

INTRODUCTION

This book is volume 1 of a set, containing conversations the author has had with hundreds of people on LinkedIn© on the subject of Enterprise Architecture. Subsequent volumes continue the discussion from where it left of in the previous version. There are no dates as such, but the set generally covers 2010 to 2014 at which point I stopped because I had been put on moderation or banned from most of the groups where discussions were going on that it was pointless to continue. They had won. I have published it not necessarily so people can see the content (although that is useful in itself) but more because I think it’s useful for people to witness how these debates “work”. Perhaps it would be useful as a Psychology analysis regarding how online conversations are conducted. Also, parts of it are quite funny ;-) No apologies are given for the numerous spelling mistakes and other grammatical faux pas! Who cares about grammar – it’s the debate that’s important.

Introduction

Moderation

Format

Moderation doesn’t sound so bad but when you are the subject of it if effectively means you cannot participate anymore, meaning you have effectively been banned. To get a feel for how moderation works, consider a room where a discussion is happening with many people. When you are put on moderation, you have to stand outside the room (but you can still hear the discussion in the room) and when you want to say something you have to write it down and give it to someone at the door. This moderator may either read it out after an indeterminate period of time or put it in the bin. However, you can never see them placing your comments in a bin because they never tell you when they do. You only know if your comments has been binned by waiting for an indeterminate amount of time (could be a few hours, could be a few weeks or more) to see if your words are read out. If they are not read out after some weeks you can only assume those words went into the bin. Even if they are read out, by the time they are the discussion has probably already moved on and therefore your comments can look very odd. Moderation was mainly carried out because some people got “upset” or didn’t like the way I said things, so the board owners closed me down. That is their right I guess. They have that power. However, closing down free speech because some people got “upset” or didn’t like the way I said things seems utterly counter-productive to me. People always talk about a civil level of discourse. Well, who is to say what a civil level of discourse is? Plenty of people enjoy the rough and tumble of debate. People enjoy tabloid journalism; people enjoy all different kinds of discourses. If group owners on LinkedIn© regulate how we can speak, the tone in which we can have debates, the language we can use, is going to find that all the interesting people, all the creatives, all the most fascinating personalities are going to leave.

All of the “Comments” in this book are what I posted to discussions and all of them follow a simple format. First I quote what someone has said (to provide context – for without context my words would be meaningless and therefore worthless) then I provide my response. When quoting others, only the first name is given and their name is preceded with an @ symbol followed by what they said in quotes, with a : in between. For example, @Brian: “I think we should all read this book” That’s a great idea! So Brian had previously written ““I think we should all read this book” and my response to him was “That’s a great idea!” The only thing left to explain is that each post is separated by a horizontal line. Almost but not quite like this one.

──────────────────────────

Comments

COMMENTS

Fasten your seat belts, it's going to be a bumpy ride!

(or more accurately, but less dramatically, and less usefullyâ&#x20AC;Ś) Fasten your seat belts, it's going to be a bumpy night! Margo Channing (aka Bette Davis)

Comments

@Carol "are you saying that all artefacts in the boxes outlined in black belong within the domain of EA?" Yes.

@Carol "I would think that the current portfolio model should also be a box outlined in black - you must know where you are in order to plan for the future" I agree. It is on the diagram but only implicitly represent by the "Project Roadmaps" box and I think this may not be clear enough. In terms of all the details about the portfolio of programmes and projects I have not show this although, again I am implicitly thinking its part of the "Prog'ms, Projects, Initiatives" box.

@Loan2: "What good would be to create a lot of different EA frameworks, just because there are few thinks you don't agree with the existing ones? How will EA practitioners stay in touch with severals frameworks?" - We are not talking about creating a lot of different frameworks. Even if there were a lot, EA practitioners would stay in touch with “several of them” in the same way that IT people stay in touch with hundreds of different technologies. It’s part of the job. @Loan: "EA is a complex discipline as is, why would we want to make even more complex."

I think I do need to change that area a little to make it clearer. Maybe I need to distinguish the actual projects and programmes from the project and programmes portfolio model.....

positive. In reality it is controlled by a lot of large vendors. It is also so large and cumbersome and so many people are involved in changes to it, that it's not exactly agile.

@Loan: "TOGAF is playing an important role in promoting Enterprise Architecture as a discipline with a big international support."

- TOGAF is one of the main reasons proper Enterprise Architects have to keep explaining that Enterprise Architecture is not all about Technology, and certainly is not Solution, Application and Technical Architecture. TOGAF is good for what it is and what it does. But, it keeps spawning more and more people who tell more and more people that TOGAF is EA Framework which is just plain wrong.

- We can learn a lot TOGAF , but sometimes the bullet and start again. as being "open" which

of lessons from you have to bite TOGAF is touted all sounds very

@Loan: “We need a common language .... which one will be? My bet is on TOGAF right now." - TOGAF is not a language. What we do need is for people to really understand what EA is, what it is not, and how to “do it”. @Kirk: “…redesigning executive incentive programs… redesign of accounting practices…”

Cool! – I have often thought that because incentives tend to always reward people for todays achievements and not tomorrows possible debacle. This is one of the major reasons why “Senior Management” and “Top Executives” don’t want to spend a bit more of their budget on things that will create huge benefit in 1, 2 or 3 years time, because

@Loan: "I do agree that is not perfect and it doesn't contain all the answers, but that can be fix by the common efforts of the Enterprise Architect community."

- EA is not complex to understand (when you can cut out all the drivel that is spouted about it). It is complex to do because it involves a lot of communication with people who have their own agendas, self interests, remuneration goals etc etc. You, and others, are making EA complex by constantly muddying the waters.

Comments this years bonus is not dependant on those things. This is what causes Enterprise Debt and why I have been pushing this.

@Tom: “majority of TOGAF specialists would agree that TOGAF needs redesign before it is usable for true enterprise architecture in the sense that Kirk describes.” I really hope so. We just have to get this word out to the majority of the other people out there – this, I think, is going to be an uphill struggle… P.S. I am not a TOGAF basher. I am a TOGAF Certified Practitioner. TOGAF is good at what it is, but what it is not, is an EA Framework. ──────────────────────────

Hi Saify,

This is why I ask people to look at the ratings and if they disagree with any rating, to tell me which one and why they think it is wrong. If it turns out they are correct, I will change it, if it turns out that their wrong, I don’t change it. I keep asking, The page on my website which show the comparison has been viewed the following number of times: This week (22-29 Apr) 215 views (in 2 days) This week-1 (20-26 Apr)

480 views

This week-2 (13-19 Apr)

536 views

Out of all the people that have seen it (>1,000), I think there has been only one person who has suggested I change something, and I agreed with him and changed it.

I'm not sure I was formalising anything. I certainly didn't intend to.

We need some way to succinctly compare frameworks because for people to understand something they have to understand how that something relates to other things. The comparison needs to be quickly understandable as well – I have read various comparison papers of frameworks but I don’t think anyone gets past the first page. Of course there are subtleties that are lost, but the Pragmatic Approach is to concentrate on the most import things. I take your point that any rating is subjective but that doesn’t mean we don’t do it.

@Bill: "I think an important aspect of TOGAF v9 which isn't specifically represented in the analysis is its scalability. It can be applied to very small EA practices in small to medium enterprises, or it can be applied to large practices with a architecture governance hierarchy stretching down three or more levels. "

- I agree I could add Scalability, but I would score all frameworks a three, what would you score them?

@Bill: "I would say TOGAF is more exhaustive, flexible and detailed than PEAF. perhaps attempting to cater for 100% of enterprises rather than the most common 80% - thus bringing considerable complexity and volume to the framework. This is not an uncommon problem with such frameworks. "

My Pragmatic approach to everything is to define something, put a stake in the ground that is consistent complete and reasonable and then let people tear it to pieces if they can. If they can, I change it, if they can’t it remains.

──────────────────────────

- I agree, with your comments about TOGAF being more exhaustive and detailed. Those are some of the reasons why PEAF is so useful because it is none of these. In

Comments create intermediate states and the associated plans.

@Bill: "In my opinion, TOGAF is only going to become even larger and more complex, catering for EA management (beyond simple governance), as well as development - and also advancing its maturity in Information Architecture and SOA."

In simple mapping terms, you can definitely decide where you want to go on a map, but if you then want to get there in a reasonable way you need to know where you are currently on the map.

terms of flexibility - I wouldn't agree, I think all three are just as flexible.

- Oh dear! If there are two things TOGAF does not need to, be they would be, to be larger and to be more complex!! @Bill: "So horses for courses really. PEAF is a very valuable resource for beginner EAs attempting to get an EA practice established within an enterprise. TOGAF v9 has some very valuable lessons/concepts to enrich an EA's understanding of their discipline beyond what is covered in "PEAF."

Hi Kirk, Yes - I have seen both of these multiple times throughout my entire 29 years of professional life from being a lowly programmer up to the heady heights of EA and Strategy. They have been the one pervading and crucial problem. I am grateful you have brought these up again. I think they have been so long in my mind and I have never managed to change them they just sit there like a pair of old socks in a drawer!

- Agreed.

──────────────────────────

@Bill: "TOGAF is considerably easier to absorb once you have a good working knowledge of EA. " - This is a very telling statement and I agree with it.

- To state it in another way, “In order to easily absorb TOGAF you DO need to have a good working knowledge of EA”.

- This contrasts with ‘In order to easily absorb PEAF you DO NOT need to have a good working knowledge of EA” ──────────────────────────

Your VP is correct that you can define the to-be without regard for the current.

Having said that though, if your VP then wants a plan of how to move there you will need to define the current so you can then

One benefit of a "closed" (implication that it is bad) framework like PEAF over an "open" (implication that it is good) framework like TOGAF is that when something is missing or wrong, it get's changed pragmatically, aka almost immediately, instead of talking about it for months and then reaching a consensus that is wrong. ────────────────────────── Come on guys!

We are all on the same side (I think!) The truth of the matter is that we all have to do our jobs within the confines of political and physical boundaries imposed on us.

There is benefit in doing this alone as people will have a clear understanding of the target and that will very slowly guide change as it happens.

You have re-invigorated me and I will be adding these crucial elements into PEAF.

We, therefore, do not need to impose on ourselves any more.

Comments As architects we always have an open mind, we are always keen to explore new areas and possibilities.

Thinking about what has occurred in the past has value. Thinking about today has value.

Thinking about what could be possible in the future has value. In an ideal world we take information from all 3 places to enable us to help the business to make decisions today and plan today, for the future.

We can suggest that using all three pieces of information will help us, but the political and commercial reality may be that we are not allowed to. And yet we still have to sleep at night.

Yes @Kirk "2-Companies know, but don't see value in it?" No - Because of answer to #1 @Kirk "3-Those who have been successful at "good enterprise architecture" are such a small minority, that our successes are below the radar screens? 4-other?" Yes. @Kirk "Maybe the better question (from a self-cantered perspective :-) would be.... ' How does one sell the role / service into an organization? Consultant or permanent, doesn't matter." Absolutely, and that is one of the fundamental drivers behind PEAF. PEAF describes EA as exactly what we have been discussing here (which as you point out is not what 90% of people understand it to be.)

Enterprise Architects do not make decisions. They offer information and their views to the people that do make the decisions - the business. Having provided the business with all the information available and a suggestion based on this information and logic, it is up to the business to decide. If we don’t like their decision we can of course challenge it, but there comes a point that you have to accept it.

I can sleep at night because (although I have worked on many failed projects, and worked for many people who have hidden agendas and value self- interest above what is best for the organisation) I have done my job, I have presented the decision maker with all the information necessary to make the “right” decision. If they decide to make the “wrong” decision, that is their prerogative.

In order to do that effectively you have to be able to answer all the usual questions and some of the more unusual ones as well. It all boils down to how you go about "doing EA". In order to explain it at that level, you have to effectively use a “framework”

If you look all over the world you will see that TOGAF is being used to "train" people and "inform" them about what EA is and how to do it. The reason they use TOGAF is because they need a framework to do the teaching and the only generic framework out there (prior to PEAF) was TOGAF.

If Enterprise Architects don’t like this state of affairs, they are quite at liberty to start their own company, become the CEO, and then they can make all the decisions.

What gets me out of bed in the morning is evangelising what EA is really all about. Cutting through all the hype and opening peoples eyes.

──────────────────────────

@Kirk "1-Companies are ignorant of what enterprise architecture really is?"

This of course had the really bad effect of completely confusing people and describing EA as something that it is not. I really think

Comments

TOGAF has a lot to answer for in terms of it’s muddying of the waters.

I always say that to explain to people what EA is and is not should be relatively straight forward and easy. It’s not rocket science after all. The reason it is soooo difficult is because of all the preconceived ideas, hype and rubbish they have been bombarded with. peoples brains are just so full of rubbish.

@Kirk "What used to be long sales cycle - 36 months - is now 12-18 months if at all, as you have to educate the client that EA is bigger, broader, more enterprise than a techie role (good luck getting that amount of face time!)” I can do it in 2-6 weeks depending on the size of the organisation using PEAF and so could any other EA who had been appropriately trained.

────────────────────────── @Steve "Your credibility would be enhanced if you would stop referring to the *(D*)epartment (*O*)f (*D*)efense (*A*)rchitecture (*F*) ramework aka DoDAF as DodDAF" Thanks for pointing out a spelling mistake. It has been corrected now. @Steve "Regardless, that analysis is so simplistic as to be nearly pointless." Why do you think its simplistic? Maybe its just Pragmatic.

────────────────────────── Hi Cliff,

Of course any framework is not some magic bullet in the same way that EA itself is not a magic bullet, and there is an awful lot of work to be done in an organisation to actually “do EA”. However, I still believe that a “good EA” framework instead of a “Bad EA”can only help matters. It is after all just documenting what we all know in our bones.

First of all, sorry. I accidentally left some of Kirks text in my positing so I deleted it and re-posted so it now sits below your comments!

I'm not saying that doing EA is easy. It's hugely difficult. What I am saying though is knowing what it is and knowing what to do is pretty easy.

I agree with you that its not just about a framework, but a framework provides a common, consistent view of EA that ca be used to un-muddy the waters so to speak.

If we can agree what it is and how to do it we need to document that in some way. That documentation is what I call a framework and is what PEAF is.

If people want to make decisions based on politics and the background of people, I cannot stop them.

For those who would prefer to make a more measured and reasoned decision comparisons of frameworks in various dimensions are useful. If you don't agree with the scoring you can always change the scoring and the weightings assuming you changes are based on facts rather than politics.

Do you have any constructive critisms regarding where you think the scorings are incorrect and why?

The faster us proper” EA’s start agreeing on what it is and how best to express it, the more chance other people will have of understanding it, and that is the first step to them utilising it.

@Steve "...less an issue of desired result and more one of the politics and background of the players."

────────────────────────── @Bob "WHAT criteria were used for this comparison?"

Comments

wrong and if so what they should be and why?

0:Non-Existent. 1:Poor

──────────────────────────

2:Inadequate

@Steve "Pragmatic is not the same as simplistic though in this case, I think it is. We have no way to know whether the scoring is accurate or not since the criteria is so simplistic."

3:Acceptable

4:Very Good

5:Outstanding

@Bob "The rather light PEAF product" It is meant to be light. It's pragmatic.

@Bob "has been available for less then 6 months is being compared to frameworks and EA methods products that have been around for at least 5 years."

Correct. Are you saying that when something new comes along we should not compare it to existing things? The most common question I get about PEAF is "How does it relate to the existing frameworks" so I'm not sure it's valid to criticise me for answering that extremely important question.

You keep saying the comparison is too simplistic - what does that actually mean? In what way would it need to be changed to be acceptable to you? Or, are you saying that it is impossible to write a reasonably short and succinct paper that compares these frameworks? I don't mind you saying what I have done is "simplistic" but you can't just say you think something is wrong without proposing how you would change it or replace it? Otherwise things never move forward.

@Bob "It's a stretch to expect one to consider that PEAF with little or no demonstrated experience some how rates higher (twice in some cases) then well established frameworks and methods." VHS has been around for many may years, so why does BluRay rate higher?

Just because something has been around for a long time doesn't make it good. It also doesn't make it bad. If you take your argument to it's logical conclusion just about everything we rely on in modern society would not exist.

I didn't say that so I do not know why you ask the question. The size of anything is important frameworks included that’s why it’s included as a criteria. It is also based on the vast numbers of people over the years that have told me TOGAF is just too big to get to grips with.

@Steve "if the CEO has not heard of PEAF, he isn't going to invest in it. He's going to go with things that have a track records otherwise MS would be out of business since virtually no product they make is conceivably the best of breed."

I agree with you that you have a point here. I'm not sure I would defend it though. It's kind of like the "No one ever got sacked for hiring IBM" statement, and we know where that leads.

Did you pour scorn on the internet as a new sales medium because it was new and untested and bricks and mortar had been around for many more years?

@Steve "Is the value of any EA Framework really determined by the size of the documentation?"

Why don’t you ignore PEAF in the comparison and just look at the others – Can you tell me if any of the scores are

It is one of the reasons organisations repeatedly make the same decisions and then are surprised by the same outcomes.

Comments

As with anything new it takes time for people to a) know about it, b) be interested in it) c) understand it d) use it e) shout about it. If it has legs it will run (eventually) if it doesn’t it will die.

I am someone who wants to change the world for the better and I am not going to sit around not doing things just because I am only 1 man.

his approach and most of his categorisations. I then used that as the basis for adding things I thought were missing. I then scored PEAF TOGAF and Zachman based on my knowledge. The DoDAF and FeaF scorings were provided by Jim Keller as he has much more knowledge of these frameworks than I do. This is the Pragmatic approach. ──────────────────────────

Churchill was only one man but is testament to what 1 fat man and a big cigar can do!

@Srinidhi: "Your tenacity to pursue PEAF should be acknowledged."

“Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened.” Winston Churchill

Thanks! But, I am not really pushing PEAF per se - although that is how it is coming across.

──────────────────────────

The only difference between me and most other people is that I have taken all of this "stuff" in my head and written it down.

@Bob: "What did you mean by "business value"?"

Essentially I am like anyone else here putting forward my views about all things EA.

I mean when someone in the business says "that's useful, thanks". @Bob: "What measurers were used in assessing and calculating the business value gain for each of the framework and methods in your comparison?

No measures - It is my opinion. If you disagree with any scoring, I am happy to listen to the reasons and what changes you propose to the scoring,

@Bob: "What approach did you use and how did carry out or gather the data to do your comparisons of the frameworks and methods?"

This is one of the problems I believe exists with EA in that there are hundreds if not thousands of people with their opinions on what EA is, is not, and how to "do it". There are also hundreds of books who purpose seems to be as big as possible.

This is not my approach.

My approach it to "Cut EA to the Bone" @Srinidhi: "All frameworks are addressing different specific things, so they should not be confused to be replaceable by one another." Exactly. That’s why the comparison allows people to weight what is important to them.

Since I am an architect and loathe having to re-invent the wheel I first looked out there to find out if there had been any comparisons done in the past. There are some out there but a lot of them are very large and long sections of unstructured text that offers no clear comparison. I then stumbled along the old comparison done by Roger Sessions of ObjectWatch, Inc. I liked

It just so happens that I have also given it a name.

────────────────────────── @Bob: "What did you mean by "business value"?"

Comments I mean when someone in the business says "that's useful, thanks".

@Bob: "You're joking...right"

long term costs and impacts were not thought about (because there was no incentive to do so) ──────────────────────────

Nope!

I have lost count of the complex and convoluted measurement systems that I have seen used. Most of these either just fall into disrepair, or they are manipulated to show everything’s fine when in fact it is not. In my experience I know when I have delivered business value when someone from the business comes up to me and says: -

"You know that X that you did, that was really great. Thanks a lot." It's not big and it's not clever.

To become an Enterprise Architect you first have to be very clear about what it is and what it is not. This is especially true of Enterprise Architecture as the term has been so confused over the years, people a re still asking the question. Of course knowing what it is, although the first step, is not enough. You then need to know what to do to what in what order and why. To do this you need a framework.

Is there any framework out there that can do all this in a simple, uncomplicated and pragmatic fashion? Yes.

It's just pragmatic.

──────────────────────────

One other comment I would make about cutting costs etc....

A lot of people talk about cutting costs, and of course this is important but the problem we have is people never include time in their calculations. (Unless they adopt EA and start recording and Managing Enterprise Debt http://www.pragmaticea.com/displaydoc.asp?DocName=peaf-comms-eaenterprise-debt ) I believe this is partly due to the badly structured short term bonus schemes that we have seen cause the banks to be brought to their knees. It will also bring other companies to their needs.

Of course to "become" an Enterprise Architect you then need to do it and get experience but without the foundation other PEAF provides this can be an extremely long and arduous affair. ────────────────────────── I would mostly say yes to everything although I would simplify and say that the Programme Management function and the EA function sit out side IS in the same way as they sit outside Finance and HR. IT may have its own PM's to PM IT change but there should also be PM's for business change and for overall programme management – this is at the enterprise level.

I have lost count of the number of CIO's/CTO's/Technical Directors and the like who have earned huge bonuses because of their amazing cost cutting measures. It's all smiles anf G&T's in the board room and on the golf course. 2 Years later the company finds itself in total meltdown because the

PEAF Pragmatic ea Framework (www.PragmaticEA.com) can do all these things.

It may be hypothetical in practice in a lot of organisations but this is the structure I put forward for effective EA.

Comments

EA at the highest level provides the business with the context and tools and information for strategic planning. The governance is ensured through delegated authority into the areas where the actual change is happening e.g. IT and the business areas through the project process requiring review against strategy, principles and policies. If they can’t make the decisions it gets escalated ultimately to the Strategic Investment Board sitting at the enterprise level. ──────────────────────────

@ Kirk - Maybe I'm using the term Programme Management in the wrong way ....

What I mean is, in any project in an organisation there is change to IT and change to everything lese (aka the business e.g, processes people, training etc etc)

standard. It describes the typical roles in IT and the skills needed to fulfil them." You can get a wallchart here http://www.bcs.org/upload/pdf/wallchart.pdf It's been around for some time although I am not aware of it being widely used in industry here (I could be wrong as it may be buried in HR and we all know what that department is usually like - The fact that they thought that a change of name from "Personnel" to "Human Resources" would make the "Personnel" happier to be called "Resources" is amazing! - anyway I digress..)

SFIA describes an Enterprise Architecture as "The creation, communication and improvement of the key principles, methods and models that describe the enterprise's future state and enable its evolution. The scope of the enterprise architecture process involves the interpretation of business goals, drivers and strategies, the assessment of the current capabilities of the people, processes, information and technology of the enterprise, and the determination of how these relate to one another and to the external environment. The process supports the formation of the constraints, standards and guiding principles required to define, assure and govern the required evolution and the transitional processes that facilitate predictable transition to the intended state through information-enabled change in the organisation's structure, business processes, information systems and infrastructure." http://scripts.bcs.org/sfiaplus/sfia.htm

So a "project" consists of business change and IT change - therefore you are likely to have two projects for a lot of changes one for the IT change (managed by an IT pm) and the other for business change.

These two projects in my eyes constitute a “programme” for which you need a “programme manager” Obviously this is not always the case as it depends on the size and scope of any change. ──────────────────────────

OMG - I think I must be getting old but (replying to a different thread) I just remembered something that is probably quite pertinent here. I think age is beginning to stress the old grey cells.......

Level 5

Contributes to the creation and review of a systems capability strategy which meets the strategic requirements of the business. Develops models and plans to drive forward the strategy, taking advantage of opportunities to improve business performance. Takes responsibility for

Her in th UK there is something called SFIA (Skills Framework in the Information Age). "SFIAplus is the IT skills, training and development standard widely used in the UK and beyond" - "The Skills Framework for the Information Age (SFIA) is the UK government backed high-level IT skills

And they put it in the "Business / IT strategy and planning" category and they define 3 levels for it (The 3 highest levels they have)

Comments

investigative work to determine requirements and specify effective business processes, through improvements in information systems, data management, practices, procedures, organisation and equipment. Level 6

Level 7

The Singapore Government are working on their own Skills framework called the “National Infocomm Competency Framework (NICF)” When I spoke to them about it in February, they had put the “Enterprise Architect” position in IT because they didn’t know where else to put it. ────────────────────────── HI Cliff, I agree with your sentiment and I had thought of doing this, however, I saw some problems down the road which changed my mind. We can easily create a new name but.. #1 Publishing it and getting it out there is going to be a long hard upward struggle. #2 Creating a name doesn't mean we will "own" as it will potentially get b********z in the same way that the current name has.

Leads the creation and review of a systems capability strategy which meets the strategic requirements of the business. Identifies the business benefits of alternative strategies. Develops enterprise-wide architecture and processes which ensure that the strategic application of change is embedded in the management of the organisation. Establishes the contribution that technology can make to business objectives, conducting feasibility studies, producing high-level business models, preparing business cases, taking into account as necessary any implications of systems considered. Ensures compliance between business strategies, enterprise transformation activities and technology directions, setting strategies, policies, standards and practices.

Directs the creation and review of an enterprise capability strategy to support the strategic requirements of the business. Identifies the business benefits of alternative strategies. Directs development of enterprise-wide architecture and processes which ensure that the strategic application of change is embedded in the management of the organisation. Ensures compliance between business strategies, enterprise transformation activities and technology directions, setting strategies, policies, standards and practices.

#4 Changing the name sounds too much like treating the symptoms and not the problem. #5 It is likely to confuse/alienate us from the rest of the world (or at least parts of it) where EA is well understood properly e.g. South Africa and the US. Sorry to rain on your parade, but forums like this, training, and comments from people at the last Open Group conference show (to my mind at least) that the tide may be turning here. ──────────────────────────

I had tried pushing this framework while I was at the RPA a couple of years ago, and also in other companies but no one ever seems interested. (I do remember, however, BAA looking at it back in 2004 although I’m don’t know if they ever implemented it.

#3 Creating a new name for something existing is likely to confuse a whole lot of people, who may end up saying after a long argument - isn't that what EA is/supposed to be?

Regarding leveraging this forum - the only thing we can all do is keep plugging away and educating other posters as and when they arise.

Comments

For my part: -

1) I have developed an EA training course that educates people - but I don't want to mention anything specific as it may appear commercial and get censored. 2) I am active on various forums educating and evangelising 3) I have developed a usable and pragmatic EA framework

lot of the toolkit required to do it. It just happens to have a name. I know training, a toolkit and certification alone are not enough for people to become EA's but good quality training a toolkit and certification is deeply needed right now to start to turn the minds of people from where thy have been looking to where they should be looking. Cheers,

4) I am in talks with various tool vendors, consultancies and training providers who want to offer "real EA" to their customers.

Kevin.

5) I am talking to "Computer People" (hopefully other recruitment companies when I have the time) and educating them on what EA is and is not and what the Job Description of a "Real EA" is and is not.

Hi Roger, Yes - My comparison is based on yours!!!! I also give you credit on the website - scroll down to the Content Section of the eval page - below the list of the areas being evaluated you will see your name.

Apart from that, I do allow myself short periods to breathe and go to the toilet occasionally ;-)

──────────────────────────

Well since most of what you report are facts its hard to disagree.

Some of your points are not facts but reasoned beliefs but I have no reason to question them, most of the refer to what I have depressingly witnessed over the last 5 years or so. I know this is going to sound like a plug but this is why I created PEAF. (www.PragmaticEA.com) Training and Certification are now available worldwide.

Another way to look at it is as a vehicle for learning how to do EA but also to provide a

Yours was the only one that contained what I would consider to be a pragmatic approach to EA comparison - well done!

Initially I was only interested in TOGAF and Zachman so I started with those from your comparison. I alls remove some categories I thought less relevant and added some more that I thought were relevant. Subsequently Jim Keller gave me the scorings based on my categories for FEA and DoDAF. I would be interested in your comments on my comparison especially if we can agree on the scorings because then we can jointly publish it which would make it more useful to the general EA community.

But don't think of PEAF as closed and proprietary and therefore bad. It's pragmatic and that counts for a lot. It deals with EA head on in a concise and pragmatic fashion. An EA Framework for EA’s by EA’s.

I looked for existing comparisons that I could use (I am an architect after all and reuse is my middle name) as the basis to compare/place PEAF and I couldn't find anything apart from very long winded papers.

Have a look and let me know what you think.

Comments

Cheers,

──────────────────────────

Kevin.

Please do not think I am pushing a product....

────────────────────────── I guess it's only human nature but it always amazes me how much time people have to criticize things but never time to actually do something positive about it. Do we all want to help individuals and companies adopt an EA approach and reap the benefits it can bring? If so what are we all doing to achieve that?

Actually doing it is extremely difficult partly due to the fact that people with brains the size of a planet spend endless hours talking about it. I have not ready anything new about EA in the last 7 years. That is, until I created PEAF. It seems to me that the one thing our profession is responsible for is our constant appetite to discuss things to death. What is needed is a simple pragmatic description of what EA is, what it is not, and how to do it in a simple no nonsense pragmatic way.

In my life I have had many conversations with people about why something is wrong and why it's not the best approach etc, etc, etc. I have always dealt with these situations in exactly the same way. I stop talking about it and start doing something about it. This is usually in the face of people telling me it can't be done and that it is impossible to do what I believe in.

Knowing what EA is and how to do it is so simple it hurts.

Wrt to Enterprise Architecture, I have read the books seen the films, bought the T-Shirt and answered the same fundamental questions over and over again.

After many years I decided to do something about it and Launched PEAF (www.PragmaticEA.com). It's not only a framework for "doing" EA but also very good for "teaching" EA. (please don't point out to me that doing EA is much more than going on a course yada yada yada. I know. The more people we get grounded in a good description if EA the better. Some of them will go on to be very good EA's, some will not go on to be EA's at all. But that's not an excuse for not teaching them.

Pragmatic EA – Cutting EA to the Bone.

I would suggest its time to stop debating EA to death and to unite in one simple pragmatic framework which is designed to get organisations using it rather than designed to inflate peoples ego’s and show how super intelligent pan dimensional beings we are. ────────────────────────── Principles are statements of good intentions yes. But that doesn't make them not principles. Webster’s provides 13 definitions of the word principle(s). Of course you can choose ones that do not fit, but I would choose the one that does which is "guiding sense of the requirements and obligations of right conduct: “

If TOGAF is not up the EA job (it is not useless and it does have a very good part to play in the wider IT Architecture domain) then let’s start to use PEAF. If PEAF is not up to the job, tell me why and if you have a point I’ll change it so that it is.

This is what PEAF does.

Principles come from 2 sources. 1 if best practice or accepted wisdom, e.g. buy before build.

Principles are not hard and fast, if there is good business reason not to comply with a

Comments

principle in a particular instance then that should not be a problem. It does not mean that that principle is worthless. E.g. Buy before build is generate, but if enormous business advantage can be gained by building over buying then why not. Principles are easy to govern, monitor and manage. Part of the management is the enterprise debt non-compliance creates.

It’s all documented in the "Process" document in the governance section here http://www.pragmaticea.com/peaf3governance.htm and a set of these standard principles can be found at the same location in the “Principles” document. It's not complicated.

────────────────────────── Hi Maganathin

and

It is not meant to replace other frameworks but fill the void between the very small and the very large by “Cutting EA to the Bone” and providing everything you need, and nothing you don’t. I don't want to say the name but I hope you can guess what it is. Go have a look. Companies such as Vodaphone, Singapore Arlines, MWEB, MTN, CBH, Yellow Pages, Cerner, Intrado to name a few are very interested, as are both Gartner and Forrester. There are also a number of consultancies that are keen to begin offering it to their customers. Cheers,

The 2nd set of principles are organisation specific and come from modelling and understanding the target state of the enterprise.

difficult for Enterprise Architects Organisations to get to grips with.

I know I may get another rap on my knuckles but here goes anyway....

There is an EA framework out there that is designed for exactly the question you ask.... It purpose is to allow organisations to kick start or re-start an EA initiative and provides a comprehensive EA Framework and associated Toolkit of everything required to hit the ground running.

It bridges the gap between minimal "EA Frameworks" like Zachman which is only a Metamodel and “EA Frameworks” like TOGAF which is huge and complicated and

────────────────────────── I would be very very wary of "picking low hanging fruit." That is what everyone else in the company is usually doing which is why organisations tend to have very short term view of things, and why tactical things mostly rule over longer term strategic things. EA is all about strategic planning not "picking low hanging fruit" "picking low hanging fruit" tends to be what people do to give a company a shot of heroin - with similar results, they get a short term high and then get hooked on wanting more and more short terms highs as the organisation descends into depression as their enterprise debt spirals out of control.

The Toolkit consists of; Foundation (Vision, Maturity Model, Plan & Risks), Communication (Slide-sets), Model (Metamodel, Tool Evaluation & Content, Gathering Process), Governance (Principles & Process), Management (Metrics & Process)

Kevin.

This doesn't mean you can't pick some if you come across them. Have a look at page 8 http://issuu.com/pragmatic-ea/docs/peaf-

Comments overview-v1.1.4/8 - where does it say “picking low hanging fruit”?

────────────────────────── SP = Strategic Planning

infrastructure. It is an asset, an asset that enables business, that needs governance, has a price tag, a run-time cost, and that must have a clear, demonstrable ROI.” One of EA’s problems/risks (for there are many see the risks document in the foundation section) is that EA is tarred with “It’s an IT thing and therefore nothing to do with the business”. This is a huge barrier to understanding and adoption by the business.

BA = Business Architecture

TA = Technology Architecture GO = Governance

MA = Management

If we don’t get the business and board buy in and understanding that EA is not just all about IT, then your EA initiative will fail.

CO = Communication

EA = ((SP + BA + TA + GO) / MA) to the power of CO

“all state-of-the-practices in EA don't cover the entire enterprise…….. current EA Frameworks now available on the market though……..are essentially incomplete.”

@Luis “PEAF defines EA'S purpose to......Wouldn't all that be, then, the management, reasoning and efficient exploitation and alignment of all computing aspects in an enterprise with its (business) strategy?”

PEAF is 100% EA and complete.

Have you had a look – let me know what you think. ──────────────────────────

@Luis “<solution, application or technical architecture.>It shouldn't provide an extensive coverage, but at least it should document it, its governance policies and stakeholders. Obviously of course, the dept of such coverage is/should be proportional to the size and complexity of IT infrastructure.”

I’m not saying that organisations do not need this.

────────────────────────── The reason people refer to Zachman as a framework is because when it came out many years ago it was a framework. Over the years we have realised that the EA model is a very important part of EA but the whole thing, hence we now use the word framework to describe a collection of things such as process and maturity models and also of course a taxonomy or Metamodel. As regards having 1 rather than many – yes it would help However, I don't think that this is something that can be consciously created. Over the years 1 framework may become the de-facto standard at some level of abstraction but when EA frameworks also go down into the detail for a particular vertical (e.g MoD, DoD, Federal government etc) there is no way you will have 1 size fits all.

What I am saying is that in order to begin to adopt EA as an initiative, a culture, this is not required and in may organisations is present anyway.

Yes, but not exclusively IT. Is a business process IT? Is an Office location IT? No – but we include them in EA.

PEAF exists to provide people everything they need to begin their EA journey. @Luis “I'm not sure how can an org start on the EA road without covering IT

Comments

People have pointed out to me in the past that there does exist an abstracted view (GERAM) but GERAM is not an EA framework in itself, it’s a framework that supposedly allows the classification and comparison of EA frameworks. However, I have found it to be much more engineering focussed and therefore difficult to use. I would have loved to find mappings of al the EA frameworks to GERAM but most do not exist from what I can see. There is one mapping TOGAF to GERAM but it dates back to 2004 and is not exactly concise or easy to understand spanning 27 pages. ──────────────────────────

A Google on something else turned up this question in the results list - I notice it dates back to 2006!!!!!!

services or intend to work for someone that does." I see you subscribe to the philosophy that whatever is the largest is best. Do you remember Microsoft? Do you remember the internet? Do you remember streaming? Do you remember mobile phones? How do you let anything new into you life? Or do you just wait until something is big and then jump on the bandwagon? Sounds to me that you are a follower and not a leader. A farmer, not a pioneer. That’s fines though. We can’t all be leaders.

Since companies such as Vodaphone, Singapore Airlines, MTN, MWEB, Cerner, the UK Olympic Delivery Authority and many more are extremely intere4sted in it, I suggest you at least investigate it - the bandwagon maybe leaving sooner than you think...

Anyhow, as it wasn't answered, I see no reason why it cannot be answered now... Zachman only provides you with a Metamodel (a very detailed and comprehensive Metamodel) TOGAF and other frameworks supposedly add the other parts that are required in order to have a successful EA initiative, however most other frameworks fall short. TOGAF is huge, complex, and difficult to begin to use. It's also not just EA as its too IT focussed.

PEAF on the other hand is a great place to start, it provides everything you need, nothing you don't and allows organisations a fast start on the road to EA adoption. ──────────────────────────

@Steve "Then again....I suppose you are selling PEAF" Interesting Steve - Can you tell me how much I am selling it for?? No?

That’s probably because I am not selling it. I am only bringing to the attention of people because it can help them with their EA initiatives. ──────────────────────────

@Steven "You must be joking! When was the last time you saw a government RFI/RFP that asked "how many PEAF certified architects do you have"? - now repeat the exercise for TOGAF....that alone makes it worthwhile if you provide EA consulting

Did you know that Dell is evaluating PEAF in order to potentially provide it as part of EA training to over 100 EA’s?

@Mohan "Hi Kevin, In all fairness to every one involved you should refrain from pushing your own agenda and promoting PEAF when the post was obviously about TOGAF Certification. I am afraid you will dilute the

Comments efficacy of this group by using it as a commercial bill board to advertise, acting otherwise."

fills a gap in the market not provided by any other EA framework. Perhaps you know better than some of the leading EA analysts in the world? I think they have a different view to yours.

You cannot buy PEAF - You can use it for free so long as you are not a consultancy or training provider.

@Bob "From what I've seen of your tool, you've got pretty diagrams (the kinds execs like..."

Really - I am amazed. Politics has crucified companies for many years. Architects and especially Enterprise Architects are the lonely voice in the wind telling people how things really are.

Hmmm in case you hadn't noticed, it’s the execs you need to convince of the value of EA - so thank you very much for you very powerful compliment. Will you allow me to post it on my website?

I see politics coming more and more into the EA community and the sooner this cancer is cut out the better.

@Bob "...but you lack tons of detail in how to use and apply PeaT."

If something is better than TOGAF why are you afraid to hear about it?

Yes Bob – PEAF does lack tons of detail. It’s designed to. That’s the whole point. It’s pragmatic. Once gain, thank you very much for your most gracious comments. I'd like to use that one too if you are OK with that. You (and certainly organisations) don't need tons of detail to initiate and sustain an EA effort. That's one of the reasons TOGAF fails so badly to deliver EA. That and the fact that it's not an EA framework of course. By the way, please don't say that a lot of people disagree - although I'm sure they do - those are the people who do not understand what EA is and what is required to "do it". You only have to listen to the peoples comments that came out of the last Open Group conference.

If you don't like what someone says, you are a big boy, comment on it, ignore it, agree with it, but don't attempt to censor it. Let the people decide.

If something is rubbish, it will die without any help from censorship.

If something is good, it will grow and succeed. It might take longer but all it needs is one man to stand in front of a tank in Tiananmen Square. It is clear here who is the tank and who is the man. ──────────────────────────

@Bob "You are constantly saying your tool is top of the pops. I've seen

PEAF is not a tool, it's a framework.

IMPROVE on your tool. You'll find out real quick the problems with what you've got.”

Since I have using PEAF in various forms over the last 7 years at many organisations I did find out what the problems with “doing” EA are That’s how PEAF plugs all those hole’s.

one independent review of PEAF. That review rated your tool average in some areas, lacking in a number of areas and ahead of the game in one area."

@Bob " “If I were you I'd get myself an EA contract and use it to test out and

I'm not sure I say it’s top of the pops. I do say it is very useful to a lot of companies. When I do extol it's virtues, it's because it

Comments

@Bob "Your PEAF tool has a long way to go to catch up with TOGAF."

PEAF definitely does not want to catch-up with TOGAF, that would be a very backward step. - I think it's more the other way round. ────────────────────────── Forrester: IS PRAGMATIC FRAMEWORK REALLY PRAGMATIC?

Cited from a Forrester paper written by Henry Peyret, Principle Analyst, reproduced courtesy of Forrester Research...

is EA, and many many peoples immediate reaction to PEAF is to relate it to something they already know. I know its a bit of an apples and oranges comparison. We cannot ignore TOGAF In terms of EA though, we need to reach out to these people and show them there is a much more pragmatic and business focussed way, that really is EA. PEAF contains a small technology portion, true, but that’s because it has to be because its EA which does have a leg in that camp. The other leg is firmly in the business camp. 90% of PEAF is geared this way...Communications, Governance, Management, etc etc.

"It is hard to find free alternatives to TOGAF as most of the alternatives come from consulting companies. Pragmatic EA Framework (PEAF) is one freely downloadable EA Framework for end user companies which is comparable in terms of coverage to TOGAF. It claims to be more pragmatic but since it was published in November 2008 it is too early to judge its pragmatic-ness at the moment. However, some companies looking for simpler approach can at least take a look to PEAF and may find it useful either as a complement or a replacement to TOGAF." - HENRY PEYRET

@Joseph "If we consider the enterprise leader to be the CEO, and enterprise architecture to be resolving enterprise issues, then it is the CEO who gains most from EA efforts, and as such needs to keep EA under himself. If EA reports to the CIO, the EA goals would be focussed on resolving the CIO's issues, which might or might not be the tally with the CEO's issues."

Comments?

Agree 100%.

────────────────────────── Hehe!

──────────────────────────

Well, it seems I have about 13 jobs - but being an EA I can do anything!!!! Top of the world Ma! Top of the world!!!! Errhem - back to reality.....

TOGAF is definitely not EA. TOGAF is most definitely ETA. 100% Agree. An any EA worth his salt would agree. However, in the world we live there are a huge number of people which think TOGAF

No apologies necessary.

I like to see where discussions end up sometimes the actual destination is more important and interesting than the planned one. Anyone who has taken a road trip would, I imagine, concur. The more open, un-censored and the less rules we have regarding discussions the better.

OK - this sort of thing keeps coming up so let me explain where I am coming from.....

@Joseph "Apologies to Kevin for going offtopic."

I quite like the quote - which seems to be widely associated with Voltaire – Now there’s a guy with an electric personality ;-)

Comments “I may disagree with what you have to say, but I shall defend, to the death, your right to say it."

────────────────────────── Here's a requirement for a "Chief Business Architect" http://www.execappointments.com/jobs/viewAd.asp?id=13651 4&executiveID=134000&refDate=24+June+2 009&eacid=ea/email/alert/job_listing It’s interesting in various ways.

#1 The name - Hmm on the face of it sounds much better than Enterprise Architect but I'm not sure the business leaders would be too happy about that as they are the architects of the business.

@Dave "2) A (probably near-empty) vector for how the architectural frameworks in question address the things senior executives think are missing from most frameworks." No problem with this also but we need to first identify the things senior executives think are missing from most frameworks. Can you give us a starter for 10?

@Dave "Also, nitpickingly, I recommend the comparison fixes up the descriptions of DoDAF (300pp??? I count closer to twice that, even without the juicy bits from the DoDAFv1.0 Deskbook that have been hived off to an online system only)" No problem - the DoDAF information came from someone else - if you and others generally think DoDAF is more like 600 pages, then no problem I will update it.

#2 Even thought its getting closer to "EA" its still "Reporting directly to the Director General Informatics and the Chief Information Officer, the Chief Business Architect is a member of the Informatics Directorate leadership team." I think as time moves on this will eventually sort itself out but it's going to take a long long time. Unless companies start to use something Like SFIA to define their roles. ──────────────────────────

@Dave "So, perhaps the original document that started this discussion (the one providing a comparison of PEAF, DoDAF, TOGAF, etc) should have a couple of extra rows and columns: 1) Inclusion of MoDAF if not NAF"

────────────────────────── Hi Graham,

There is a framework/approach/methodology that is designed just for what you require. And its free for end-user organisations to use. It allows for extremely fast and pragmatic adoption and EA in an iterative fashion, which allows an organisation to decide what steps to take, how big those steps should be and over what timeframe. ────────────────────────── @Mikael "Nope, no comment." Why not? that’s what these discussing groups are for. @Mikael "After the recent bashings, I can understand your urge to justify PEAF but am now getting a bit sick of it. There was a time when you really added value to the conversations, Kevin, but during the last two months it more and more feels like you are using the group as your private marketing

If someone can provide me the information to populate the comparison model, I'll gladly add it. Could you provide a first iteration? If so, please mail me your raw scorings and I'll add them and then post for views and feedback.

Comments you were doing it (I hope that is the reason). What better place to receive critique about your work than from a group that has identified itself to be 'leaders' in the EA field."

The problem is, Mikael, is that there are an awful lot of discussion that discuss EA in generic terms. This is one of the major major problems EA is facing. We need to move away from discussing it in general terms. and make it real and executable for end-user organisations and government bodies.

Absolutely.

channel. It would be really nice to see you go back to discussing EA in more generic terms instead of simply referencing PEAF in every two sentences."

We all have our views on what EA is, what it is not, how to go about doing it, how not to go about doing it. Whenever anyone talks about EA they are talking from their internal definitions, understandings and methodologies.

I have tried in the past to find comparisons of other frameworks with each other but interestingly they are few and far between. And those that do exist are very difficult to actually use because they consist of many pages of unstructured text.

I am no different. The only difference is that I have formalised, documented, and published my words ad attached a name to them. The framework is an expression of my views.

@Dheeraj "I guess it would have been a bit better received by the group if you posed your posts in a tone of requesting feedback/ratings of your work against the more 'mainstream' frameworks, instead of presenting a ratings done by you. I hope this does come through as I am wanting it to, a constructive feedback (both to you, Kevin and the rest of the group) based on reading all the posts."

I am not pushing a framework per se - What I am pushing is EA and helping people to understand more about it and how to "do" it. This is all within the context of the entirety of EA and all my thought and words create a complete and consistent picture. If you think something in my mind or in my framework is wrong or could be improved please let me know. Honestly, I really do want to hear from you or anyone else.

The more people that critique it or validate the more use it will be to organisations and government bodies that want to do EA but can’t find a good way to start. And don’t forget, these organisations and government bodies can use it for free.

@Dheeraj "That is excellent progress, Kevin. While I understand the feelings of a lot of folks on this forum about the perceived pushiness of PEAF from you, I can see why

@Dheeraj "I think it is a bit of hypocritical of many that criticize you for promoting your work. After all, what are we all doing by posting and blogging in forums such as these. Making our names heard and our opinions heard." True. And as I point out in my previous post, we are all talking about EA from what is in our minds. I just happen to have also written down what is in my mind and given it a name. @Dheeraj “Keep up the good work. Remember, failure is only met by people who give up without knowing how close they are to success."

──────────────────────────

I had two options - just ask people to create comparisons for me, or to create one and then ask for feedback. In my experience it is always better to table something and ask for feedback rather than just asking people to produce something.

Comments Thanks for you kind words - Don't forget that I am an architect and so giving up is not an option ;-)

────────────────────────── @Graham "I fell at the first hurdle. Slide 4 in your first deck gives me the business benefit 'Increase Portability', Increase interoperability', etc, etc. Many of the listed items are NOT business benefits at all, and certainly not couched in language that most of the smaller business owners I know would understand." Good points but, I'm not sure that basing your conclusion on one slide is a wise move. EA is a lot of different things to different people. Pragmatic’s view of EA is that it is a business focussed culture.

────────────────────────── Michael "Is there any document/framework to help businesses in this task ? " You know what I'm going to say don't you ;-) There are metrics specified for each of the principles in PEAF...

[......it is imperative to understand and know whether the principles are having the desired effect or not and to what degree. The metrics given for each principle define how well that principle is achieving its desired result and not the number of waivers produced. Whilst counting the number of waivers provides a simple metric for all principles, this is akin to measuring the input rather than the output. E.g. Measuring how fast we are pumping water, not how much water we are pumping. For this reason, these metrics measure the desired outputs of each principle........]

Cultures are not changed (or put in jeopardy) by 2 bullet points on a slide.

I wouldn't expect anyone to read the whole of PEAF and not find some things they don't agree with. The problem is, that you have to look at the bigger picture and the whole consistent approach.

There are some very large companies out there (You can see all the licensees on the website so I won’t duplicate them here) who are either already utilising PEAF or are seriously considering it.

We in the EA community need to unite and concentrate on things we do agree with (which is probably 90%) rather than to continually to descend into conversations about all the little things we disagree about.

But we need to be careful here, and not get into arguments about what to measure so much as making sure that things are being measured in the first place. In my experience its not bad metrics that cause problems, but lack of any metrics at all. You need to change the culture so metrics are being gathered and reported. ────────────────────────── @Brian "Try first what is the business goal? E.g., Improved Customer Satisfaction through a new order entry system. How does a new process, workflow and ordering website enable this? …"

We need to be leaders, to show the world that EA is, in fact, very very simple, but like any tool, if you try to hammer nails in with a slide rule, you are likely to achieve 2 things. 1) You will forever tell people how useless slide rules are, and 2) you won’t be hammering in any nails sometime soon!

Go have a look at them at them in the principles document at http://www.pragmaticea.com/peaf3governance.htm

I see where you are coming from here but one thing I would also say though is that metrics need to be at the correct level.

Comments

EA metrics should not be measuring how well a project achieves its goals. This sort of thing is usually already being measured.

PR Measuring EA is all about measuring how well the strategic planning and other strategic EA goals are being attained. This is why i say EA metrics are defined for each of the principles...the principle define to overall strategic framework and encouraged actions, the metrics for each principle measures whether the organisation is achieving the benefits those principles are supposed to be achieving. ──────────────────────────

@Kenneth “I'm curious about reading good case stories about EA and where it really made a difference for the organization. Any recommendations?”

And, it’s free to use for Individual Consultants, End-User Companies, Government Bodies and Academic Institutions. ────────────────────────── @Renaud "Day after day TOGAF appears as the de facto standard for Enterprise Architecure." I don't know any true Enterprise Architect that would agree that TOGAF is an Enterprise Architecture Framework. TOGAF is one of the main reasons EA has got so confused and people think its IT centric.

Go to any Gartner / Forrester et al EA event and you will be bombarded with Case Studies.

organisations to kick start or re-start an EA initiative and provides a comprehensive EA Framework and associated Toolkit of everything required to hit the ground running.

However, I have a little theory about EA and case studies..... Organisations are always looking for business advantage over their competitors. Right? And if they find something that gives them a business advantage do you think they are likely to want to share that?

Since EA (done correctly) gives an organisation massive business advantage over its competitors that do not utilise EA (or do, but do it badly) maybe those organisations do not want to shout about it..... Maybe I'm being too cynical. But business is business.

For a pragmatic concise and actionable approach – have a look at PEAF at www.PragmaticEA.com It allows

Hmm - No - Have your read the commercial licensing? If you are a contractor and work utilising TOGAF on and end users site, you need to have paid the Open Group $2,500. I am happy to be contradicted as I have been having some difficulty getting a clear statement regarding this from the Open Group. In the same situation PEAF is free.

@Renaud "TOGAF is ...... open"

Hmm - I'm never quite sure what that means but as I understand it, open wrt to TOGAF means it is controlled by a consortium of large companies and consultancies. Is this a good thing? @Renaud "TOGAF is ...... international"

@Kenneth “Also, can someone give me a 'down-to-earth' explanation of the EA approach. Basic steps, basic questions, basic people to address etc? Thanks”

@Renaud "TOGAF is free"

Hmmm. Not sure what this means either. @Renaud "TOGAF is ...... used So is PEAF!

Comments @Renaud "TOGAF is ...... widely recognized throughout the world"

So is PEAF

@Renaud "TOGAF is ...... living (15 years old and counting, v9), Hmmm. Is that a good thing??? By tthat same token, when TOGAF was at v1.0 would you hav killed it at birth because SSADM had being going for 15 years? @Renaud "TOGAF is ...... communitysupported (Architecture Forum), So is PEAF. But you don’t need to pay anything to contribute to PEAF. @Renaud "TOGAF is ...... tools-supported." So has PEAF

So, Enterprise Architecture could therefore be misinterpreted as meaning really big architecture, rather than the architecture of an entire organisation. ────────────────────────── @Bob "So which one of these is the "proper" definition of an enterprise." I would say none - but they all do describe what Enterprise Architecture is. They all are fundamentally saying the same thing and they are all mostly talking in terms of what it is rather than what its for - its purpose, although some doe stray into that area. In my experience people (especially the board ) do not want to know what EA is. They couldn't care less what it is. They are only interested in what its for.

@Renaud "And remember. It is not about TOGAF or xxx, but TOGAF and xxx"

Absolutely. PEAF and TOGAF are different things. PEAF is an EA framework. TOGAF is an Architecture Framework. ──────────────────────────

SAP is definitely not Enterprise Architecture as "proper" Enterprise Architects would know it. If an organisation uses SAP, then SAP is definitely PART of its Enterprise Architecture.

Many problems in understanding about EA occur because of the use of the word "Enterprise" In "proper" EA, Enterprise means the entire company / government agency.

PEAF's description of EA describes in terms of its purpose which is to ...... Provide the organisation with the tools, information, context and governance to enable it to make sound business decisions, about changes to its structure, processes and technologies, during annual business planning and throughout the year, to ensure appropriate efficiencies are achieved and that the future is not unduly compromised. ────────────────────────── In an effort to move this "definition"/"description" forward, I will take the time to analyse, classify and compare, in a structured way, every single "definition"/"description" of Enterprise Architecture. In order to do this and not waste my time, I need to get all the word for word "definitions"/"descriptions" together first.

Many job advertisements ask for an Enterprise Architect, when actually they are looking for someone who can architect Enterprise Class/Scale applications.

Can I ask people to post links to the documents/web pages to all known "definitions"/"descriptions" of EA by close of play Tuesday next week?

In other uses, Enterprise means really big i.e. Enterprise Class/Scale.

Comments

Alternatively you can email me them to Kevin@PragmaticEA.com.

I will then analyse, classify and compare, and post the results back here for discussion and ratification. OK?

──────────────────────────

Douglas "Your repsonse below is symtomatic of what far to many do that causes confusion."

I'm not sure how I cause confusion, when I propose answers to questions whereas you are just asking questions.

Firstly, there are probably hundreds if not thousands of organisation’s that would beg to differ. It would be interesting and entertaining to see the effect if any publicly listed organisation announced to the market and it’s shareholders that it had no business strategy. Secondly, PEAF is not predicated at all on an organisation having a business strategy. The only part is the Metamodel which has a Strategy Domain. If an organisation decides to represent its strategy in another way, then they can, its no big deal.

I have added my view and also offered a way to move forward to gather these "definitions", analyse them and table them back for discussion. I think this would add more value.

@Geoff “Kevin,, One of the major problems I have with the PEAF irrespective of any definition or views what EA is or is not, is that the PEAF is prdicated on very outdated view of busiess and business strategy. The idea that business strategy is all about mission, objectives and gaols, ie a deliberate strategy is in todays environment nuts…..”

Douglas "What EA is? and What is EA's purpose? as well as Why would you want to do EA? and What is the value of EA? are all different questions that all need rational answers and you have better be ready and able to answer all of them. You don't just get to answer the ones you like. " I think you misinterpret what I said.

I am not answering the questions I want to answer - I am point out that some of the questions we are asking ourselves are of no value whatsoever to the business and the board, and it is the business and the board we have to convince of the value of EA and we can do that by getting them to understand what its purpose is

I can answer any question anyone would like to ask about EA, but I think some of them are more pertinent to moving EA forward with the board.

It’s not about dictating some method of doing/representing business strategy.

────────────────────────── @Kirk "As a student of "principles driven architecture", I find the lack of focus on the impact that core decision values (principles) have on consistent architectural direction somewhat appalling." I agree.

I think to adopt a principle management need to understand the implications of adopting that principle and also the tasks that need to be doe in order to setup the adoption of that principle.

If you are trying to get someone to buy a car, is it ore useful to explain what a cars is or more useful to explain the purpose of a car?

EA is all about providing the organisation with the tools, information, context and governance to enable it to make sound business decisions, about changes to its structure, processes and technologies.

This is what is defined for the PEAF principles.

Comments ────────────────────────── Hi Nic,

I'm not saying SFIA is perfect, but it exists and its better than no framework for skills at all. And, I have to say, I think their representation of EA is one of the better ones I have seen. If you are a member of the BCS you can get access to all the details - it really is very good. It's an extremely good starting point, otherwise people just end up discussing things to death in discussions like this trying to define one job role without any reference to any other job roles which is a massively bad thing to do.

Like an EA model, SFIA may not be 100% complete or even 100% correct, but it does exist and is a good starting point – otherwise you will have to start with a new ream of A4 and a lot of pens! ────────────────────────── I like it!

Maybe the subjects to be discussed should always be subjects that are being discussed in the forum already. I've even created a skype account – TheEnterpriseArchitectureNetwork ────────────────────────── I don’t think these principles should be prioritised. They are statements of strategic intent and as such apply to any decisions. This doesn't mean that everything must comply with them. Whether a principle is complied with or not is a business decision. Not complying with a principle introduces Enterprise Debt (represented in the waiver that results from non-compliance) which then gets managed.

Job roles, like people, interact and have many relationships between them. Like an EA model, it is these relationships that are very important in their own right. Defining applications without any remit to anything else would not be a good idea.

There are obvious downsides of course but as a method of communication and for answering peoples questions I think its a really good idea.

──────────────────────────

@Kirk "Kevin, I don't see how "enterprise debt" can be construed in any way to be a "principle" " Nor do I! I didn't say Enterprise Debt was a principle.

I said "Not complying with a principle introduces Enterprise Debt (represented in the waiver that results from non-compliance) which then gets managed. " It is accepted that, due to tactical reasons, external forces, or business imperative it may not be possible to adhere to all EA principles all the time and to the same degree.

I think the question(s) and answers(s) arrived at can then be posted here for all to see.

It's as simple as that.

I wouldn't see this as a replacement for this group but more of an addition.

When this situation occurs a Waiver will be requested and issued. The purpose of the waiver is not to try to apportion blame or to highlight “failures”. The purpose of the waiver is to make all parties aware of the full impact and implications of issuing the waiver

Comments d) you don’t know how long you will have to pay interest for, or

The waiver records effectively two pieces of information: -

e) all of the above.

so that informed decisions can be made, and so that they can be managed.

1) What is required (in terms of time, money and resources) in order to comply with the principle - A dollar amount.

2) What issues, risks and associated tasks are introduced if the principle is not complied with (in terms of time, money and resources) - A dollar amount.

────────────────────────── Hi Brian, I agree totally that a pragmatic framework is just one aspect needed for a successful engagement! As I am sure you know, EA is all about communication, changing mindsets, culture and adjusting organisations to make sure that strategic businesses planning and the associated governance produce the results that the business desires.

The project board then makes a business decision to comply or not. If the project board will not, or cannot, comply, the waiver is raised to the Strategic Investment Board which sits at the corporate level with corporate budget. The Strategic Investment Board then makes a business decision to comply or not. If the waiver is not complied with, the resultant issues and risks add to the Enterprise Debt, and those issues and risks (and therefore Enterprise Debt) is managed.

Have a look at the Enterprise Debt slides at http://www.pragmaticea.com/peaf1comms.htm and the explanation of principles in the process document at http://www.pragmaticea.com/peaf3governance.htm for more info.

The problem for most organisations is not that they do not document and manage this debt correctly; the problem is that most organisations do not document or manage this debt at all.

This doesn’t mean that we should eradicate all debt. As in finance, debt can be a good thing. For example 99% of us are in debt to some degree or other, Mortgage, Car loans, credit cards, etc. Debt allows us, and business to achieve things they wouldn’t normally be able to achieve usually in a shorter timeframe than would otherwise be possible Debt is only a bad thing when:

b) you don’t know how you will pay off the debt c) you don’t know the interest rate

PEAF however, is vendor and consultancy neutral and free to end-user organisations or individual consultants working at them. Now end user organisations have a pragmatic framework they can all use (PEAF), and judging by the number of licenses issued to date, they are finding that there is real benefit to it.

Of course you need the right people, but the first step is always the hardest and most important, and PEAF allows organisations to take that first step.

a) you don’t even realise you are incurring it

But you obviously agree a framework is required, and the existing ones prior to the release of PEAF didn’t fit the bill, hence you created your own.

If you would like to talk to us about providing a service based on PEAF to your clients, let us know and we would be more than happy to discuss. ──────────────────────────

Comments Hi JP, Hmmm – Efficiency vs Effectiveness

Efficiency for me, means doing as much as possible with as little as possible which agrees with Websters definition as “accomplishment of or ability to accomplish a job with a minimum expenditure of time and effort.” Effectiveness for me, means getting things done, which agrees with Websters definition as “adequate to accomplish a purpose; producing the intended or expected result”

Of course, you can be very efficient without being effective and you can be effective without being efficient.

Interesting isn’t it? That’s why EA is more to do with people, process and culture, rather than It as it is erroneously portrayed – e.g. in TOGAF. ────────────────────────── Hi again Mr Aspiring EA, I just thought I would also let you know that having a set of principles is the easy part.... What is more difficult is getting us and value from those principles. Firstly, documenting and understanding the implications of each principle is very important. Secondly, you need to make sure that the principles you adopt identify what tasks need to be done and what needs to be put in place in order to adopt them.

I understand your point about efficiency though – an engine may be very efficient but if the engine is not connected to the wheels and the wheels are not pointing in the right direction its probably not very effective.

It all comes down to what level of granularity you are looking at. Since EA is looking at the entire enterprise, it is by definition looking at the whole (i.e. the efficiency of getting from a to b rather than the efficiency of the engine in the car.)

Also, the problem is not usually about that organisation not being effective (of course that also comes up) but most issues come from organisations not being efficient. Companies that are not effective, die very quickly, while those that are not efficient just keep going (usually in the face of huge inefficiencies). Every large company I have worked for I have been amazed at how they keep going and make profits because of huge waste and inefficiencies. They are however, effective.

Thirdly you need, for each principle, a set of metrics so that you can measure whether the principles are having the intended effect or not. Fourthly, you need to make sure that the process of how change evaluated against the principles is defined and can be operated.

So make sure whatever principles you use, they address these issues. Don't forget, EA is not about making decisions, it’s about providing the business and executives with information so thEy can make better and more informed decisions. Of course, the ones in PEAF do.

Cheers, Kevin.

──────────────────────────

And that brings us to the dichotomy between the business and IT. The business’s main drive is effectiveness, not efficiency, whereas IT’s drive is towards efficiency not necessarily effectiveness.

How about these top 19 EA risks?

1) “It’s a Silver Bullet”

Comments

EA is perceived as a perfect fix for all of an organisations problems, with little or no work or cost.

PR 2) “Nothing to do with me mate”

EA is perceived as an IT or technology level thing. 3) “…how much?!!!”

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

EA models are perceived as being owned and updated by IT 10) “How many paperclips do we have and who is using each one” EA is perceived as producing Models with huge amounts of detail and will descend into analysis paralysis. 11) “It’s something Consultants invented to get more money” EA is perceived as of no use and will only cost money for no benefit. 12) “Do You Know, Where You’re Going To….”

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

EA is perceived as not being able to define a Future state because no one knows what that is and its always changing anyway.

5) “…I have important fire firefighting to do...”

13) “Techy, techy”

4) “Are we there yet?”

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

EA is perceived as ivory tower, academic and theoretical and is only applicable if we lived in a perfect world 7) “Oh what pretty pictures”

EA is perceived as creating static “pretty” pictures that hang on people’s walls but not used by anyone. 8) “You tool!”

9) “I don’t want another maintenance nightmare”

14) “Daddy knows best”

he perception is that IS is dictating to the Business. 15) “Mummy knows best”

The perception is that the Business is dictating to IS. 16) “Model This!”

Feverish modeling of various things without a plan for how to gather the data, how to QA it, and who will benefit from it once it is gathered. 17) “Don’t mention the war - I mentioned it once but I think I got away with it!”

EA modeling tools are perceived as expensive and “nice to have” but not mandatory.

The perception is that because EA contains the word architecture it must be all about IT and nothing to do with the business.

EA is driven in a largely covert manner, It is only known of within IS and even then only to a very select few. 18) “Bonuses for Failure!”

Comments Executive incentives reward short term investments and reduced acquisition costs.

19) “It’s my ball and you can’t play with it!” Commodities such as servers, databases, storage and Integration are bought and managed in a piecemeal fashion.

The full document defingin these with Impact, Reality and mitigation Strategies is part of Foundation section of PEAF and can be found here http://www.pragmaticea.com/peaf0foundation.htm ────────────────────────── Does SaaS Diminish the Need for Enterprise Architecture? Hmmmm.

Describe the purpose of EA in one 160 character SMS message (including spaces, punctuation and carriage returns)? To avoid duplication, please go to the "The Enterprise Architecture Network" Group on LinkedIn and post your submissions there. http://www.linkedin.com/groupAnswers?view QuestionAndAnswers=&gid=36781&discussi onID=8240387 The more people who post a string there the better. Therefore it would be beneficial if you emailed, blogged, twittered (or even talked to) anyone you know that could contribute, to ask them to do so, to make sure no one who has an opinion is left out.. ############################### ################# Q: What are you intending to do with all of these posts?

Of course we first have to define what you mean by EA, which is what Jörgen touched on. If you mean IT EA (i.e. the structure of the IT in an organisation)...

...then the answer is no - using SaaS does not diminish the need for IT EA. Whatever applications, databases, services you utilise you still have IT EA and you still need to understand it.

If you mean (proper) EA (i.e. the structure of the organisation - Business and IT)... ...then the answer is also no - using SaaS does not diminish the need for EA.

────────────────────────── CHALLENGE:

A: It is my intention to analyse all of these (and the ones yet to come) and see where that analysis leads us. I don’t know what analysis I will do or what it will show, but ultimately it would be nice if it leads us to one 160 character definition that at least 80% of the people who posted submissions agree with. Q: Are there any “rules” A: Not many: -

1) Any posting of 160 characters or less will be included. 2) Any posting longer than 160 characters will be ignored. (For those who have made postings > 160 characters, please post a 160 character string (or less) otherwise your submission will not be included, even if your posting also includes a 160 character string. The reason for this is that for me to include a string from that kind of post requires me to decide which part of that post constitutes the 160 character string to include and it's not my place to decide which 160 characters of a string to use.)

Whatever operating model, business objectives, business functions, customeers, business partners, locations, services, applications, databases, services you utilise you still have EA and you still need to understand it.

Comments You can also approach the analyst community - Forrester, Gartner, et al.

A: Yes

The problem is not that there is not enough information, the problem is that there is too much information - hence asking people for a finite 160 characters definition.

Q: Will all compliant strings be referenced to those that contributed them?

Q: When will you do the analysis?

A: When the discussion naturally dies (numbers of posts reduces to 1 or 2 posts every week or so…) Q: Can I post more than 1 submission. A: Yes.

Q: Can I redact a submission and if so how?

A: Yes, repost the same submission preceded by the word REDACTED ############################### #################

──────────────────────────

────────────────────────── @Matt: “What about those who are not Enterprise Architects - but know something about EA - and don't want to join "The Enterprise Architecture Network" Group? In any case, some of the terms you have used here might be over some people's heads and so not surprised at the challenge.” If people do not want to join that group then its fine to post here.

The reason for asking to post in one place is because EA covers an entire enterprise and therefore is applicable to everyone and all roles types, and it would be better if all posts were done in one place. Of course the there is always a gap between the plan and reality but that was the intention.

Re examples - I'm always interested when people pull that trump card out of the pack. It gives the impression that if it is answered, understanding is reached, budgets are released and no one ever asks what the use of EA is ever again.

The problem is that never, ever, ever happens.

Asking the question gives the impression of not believing something, as if a case study would provide some truth. In my experience case studies are useless, because they are usually dismissed as soon as they are presented for a variety of reasons.

In my experience people who ask for case studies don’t want to believe, but do want the person talking to them to go away!

Again, I don’t want to restrict because its applicable to everyone, but thanks for the offer.

However, if anyone wants case studies, they only have to Google "Enterprise Architecture Case Studies" and they will have enough reading for a few weeks.

@Matt: “By the way, have you also noted the subgroups in this discussion group too? These are there for anyone who does not specialise in an area - but who still wants to be able to discuss subject matter with an expert such as yourself. Happy to alter the profile of one of these subgroups to better fit with helping non-EA people, but interested in it, get together with yourself and which then may lead to work for you if your advice assists them with a challenge that they may be facing with getting management or the business to understand a strategic challenge with implementing, using or supporting technology for business.”

@Matt: “By the way, see Sue Johnson's enlightened discussion to understand EXACTLY the reasons why LinkedIn groups

Comments like the one you are referring people to are losing members now, i.e. it is meant to be about networking!!”

Hmmm, not a fan of networking myself (see my post on that discussion) I’ve also heard various descriptions – Why don’t you post a challenge for your members to define it in 160 characters?

@Matt: “P.S. In my POV, Enterprise Architecture's purpose is "to align technology to fit the business using simple diagrams that show how components integrate - allowing the CIO and CTO to formulate information and communications technology (ICT) strategy and support" - and which then enables implementation and development of enterprise applications that integrate with what the business needs, as a whole, for supporting the enterprise end-toend”

What are these long posts here telling the board and executive of companies? It's confirming to them that (a lot of but not all) EA's cannot resist the temptation to "go off on one" and produce hundreds and thousands of words and arguments, counter arguments, subtle points that need explanation, misinterpretation, re-explaining, etc, etc, etc, on and on, seemingly with no end and no output tat can be used. I have lost count of the number of discussions I have seen that try to define what EA is, what it’s for etc etc etc. From what I can see (whilst some watchers may gain some learning) those long laborious discussions do nothing for our profession apart from trying to demonstrate how intelligent we are. And this discussion is descending into that oblivion. This discussion asked for 160 character definitions.

@Matt “but it is not clear to me from your opening about why this is a challenge that needs to involve the universe brought together by those who want to SMS or twitter about this in less than 160 characters!!”

The reason for this is that I/we can do something useful with those definitions – I/we can model them which is the first step of analysing them. From the analysis will come some output – it will be one step forward.

The problem is not that there is not enough information, the problem is that there is too much information - hence asking people for a finite number of characters to limit the length of the description given.

I cannot force people what or what not to post here. All I can do is explain why I asked people to post only 160 characters.

250 Characters….

Especially with respect to EA, people can often write pages and pages of explanations, that others then spent huge amounts of time discussing to death with no end or close or agreement. This has gone on for years and has achieved little.

────────────────────────── Hi Roderick,

I like your idea but that was the thinking behind PEAF !

The fact that 160 is the SMS limit for one message is not really relevant its just “a small number”

Please help everyone (and EA in general) take 1 step forward by only posting 160 Character definitions.

──────────────────────────

I must admit, a lot of people say things are open, closed, proprietary etc etc with all the emotional connotations that those words bring without actually thinking about things sensibly.

Comments I have always been willing to listen to others views.

I consider PEAF to be open because anyone can suggest changes to it and so long as they are sensible and don't break the fundamental law of being pragmatic I am happy to accommodate them.

I actively seek out people who disagree with me as that is where there is possibility for learning.

XP is proprietary - should the world dump it because it is? Of course not.

Of course we then get into the discussion about it’s me who decides and therefore that’s bad etc etc etc......

I decided to do something about the lack of a “usable” and “complete” EA framework by publishing the one I created over the last 8 years or so. It’s a stake in the ground, it’s a step in the right direction (I believe) Like EA itself PEAF is not a destination, it’s a journey. Cheers, Kevin.

I apologise if I gave you and Leon the wrong impression, my only intention was to keep the discussion on topic. Cheers, Kevin. ──────────────────────────

Some people have told me that TOGAF is open not closed like PEAF. My response is that it is driven by large corporations who sit on the board with their own vested interests and agendas, and it takes them years to change anything and when they do it’s usually not for the better - the latest release v9 is even bigger than 8.1 and of course they still have missed the point as it's still not an EA framework! - the king has no clothes on!

I am deeply passionate about my views, but rather than rejecting any opposing views I seek them out, compare them to my consistent and completer frame of reference, and then adjust my beliefs and understanding accordingly.

──────────────────────────

@WOLF: "I am sure that it is impossible for you and other participants to learn more from Dr.Kappelman' and your humble servant's five posts" I'm not sure what you mean by that.

I could be wrong but you seem to intimate that I do not value yours and Leons views?

Cool - for what its worth I think you have hit the nail on the head. My thinking is as follows: -

Before IT, businesses were very agile - I.E. they could launch new products, move buildings, employ more people, open departments, close departments, form new business partnerships etc etc. Technology was originally employed to speed things up and cut costs. This worked for a while.

But as time has gone on IT has become so pervasive and its growth has ignored agility so much that now a lot of businesses are being constrained by their IT - i.e. their agility is vastly reduced. Seemingly simple changes now appear to take far longer than the business would think, causing them cut corners, which reduces agility even more, and so on, and so on…

If this is not the case, I apologise for my misinterpretation of your comment, if I am correct, you could not be further from my views.

Hi Erich,

You are the only person I have responded to so far about the content of their post – Well

Comments

done – of course we always agree with those that echo our own views, however, I am always open to being proved wrong but that hasn’t happened so far in this case. Cheers, Kevin.

────────────────────────── If you can't see the solution, you probably don't understand the problem. One of my mantras is that usually (100% of the time) people invest huge amounts of time and emotion into solutions. I don't blame them, that is what people are wired to do. We all want to be the one that comes up with the answer. What I have realised over many years, is that if the answer is not obvious, you (me, everyone) probably don’t understand the problem enough.

Was this an email Frank sent you, as I don't see this text posted on the discussion? Anyway, I think his post their saying I was not being FAIR showed him in a bad light to others. It's not the first time I have seen someone who is so engrossed in their own thinking they do not even notice the pain when they shoot themselves in the foot! What he is proposing is what CAEAP is trying to do anyway. Cheers, Kevin. On 10/19/09 3:04 PM, Matt Miller wrote: --------------------

The key is not being clever and thinking of the solution.

On 10/19/09 12:38 PM, Frank Chatonda wrote:

The key is asking the right questions (that define the problem more clearly) and being committed to ask other questions that get raised from answers to those questions.

--------------------

Whether we are trying to define something, work out how a business process should change, whether an interface should be FTP or SOAP, whether it would be good to launch a new product or not, it doesn't matter.

Get this!! They're all power mad these Americans - and want it all for the U.S. of A! He doesn't get that all we want to do here is be able to have a little consistency and clarity in the job. Anyway, I totally get your point about why you have had to look at this framework - TOTALLY!! Let me know what support you need from me to help sort out the wood from the trees. Sadly, I do not have the time nor the energy to have to work with self-seeking power-hungry people like this.

It sounds facile, but its deeply important.

There is a great quote from Picasso that I think sums it up quite nicely.

“Computers are useless. They can only give you answers.” - Pablo Picasso (1881-1973) ────────────────────────── Hi Matt,

I would like to go a little deeper than that. I am intersted in forming an The Association of International Enterprise Architects (AIEA) copy the IEEE model, get Registered in the USA an have global and National Chapters. Will take some doing but we can pull this off (I think) - eventually provide the much needed certifications we can talk about that later, lets set a working forum if you are interested, this,I believe, this is one of the ways we can legitimize our profession, then you, kevin and I can fight for the First

Comments

presidency of the association. Actually any one of you can have it. as we are likely to be a volunteer organization for some time, telling from the economy. ──────────────────────────

@Toto: "Problems, Solutions are not really that important unless you understand the End Goal. "

I think maybe my description of this discussion didn't make things clear enough.

Of course you need an end goal. Without a goal there is no reason to do anything. Once you have a goal - to achieve it, you have to do things.

In order to do things you need to know what things you need to do.

I hope this makes it clearer. ────────────────────────── There are three iterative phases associated with EA which should be adopted in an iterative manner Iteration 1 1) Planning 2) Implementation 3) Operation. Iteration 2 1) Planning

It is these "things" that I am terming the "solution"

Of course, this does not apply to the business owner of the “problem” even if he understands his problem, because it is not his remit to determine the solution or solution options.

@Robin: "how and when do you determine whether you asked 'all' the right questions in order to construct the solution? " That’s the tenet of the discussion - if the solution is not obvious, you need to understand the problem more. ──────────────────────────

OK – Again - I didn’t make the question clear enough (and therefore the problem is not defined enough! - I love recursion!)

Inherent in the question (although not explicitly stated) is the assumption that the person/group/entity trying to determine what the solution is, is the person/group/entity that has the skills and remit to be able to solve the problem.

3) Operation. Etc.

1) Planning - You can measure how mature the organisation is in it's use of EA (and therefore determine the plan for moving forward). For this you can evaluate the organisation using an EA Maturity model. One can be found here http://www.pragmaticea.com/peaf0foundation.htm in the Maturity document. 2) Implementation - You can measure how effective the organisation is in it's implementation use of EA. For this you can utilise implementation metrics. A set can be found here http://www.pragmaticea.com/peaf4management.htm in the Metrics document.

So, as an example, 99.9% of solutions I have been tasked to produce have actually been very easy and quick to determine. What takes the time and effort is eliciting all the information about the problem and it's domain.

2) Implementation

3) Operation - You can measure how effective the organisation is in it's operation of EA. For this you can utilse metrics

Comments

associated with the EA principles you have determined/adopted. These can be found here http://www.pragmaticea.com/peaf3governance.htm in the Principles document. ────────────────────────── How do you know architecture is failing?

the

Magic - You wouldn't have to know where I can get a copy of the essay do you? I have said on many occasions, on many projects, that the PM actually causes timescales to be expanded budgets to be blown and quality to be reduced.

Enterprise

I have also always said that until an architect tells a PM what they need to manage the PM doesn't know what to do (but for some reason they are the ones hired first!)

If Enterprise Architecture is the architecture of the enterprise (business+IT and not just IT) then...

Of course , there are good PM's and I have met some but I reckon out of the ones that I've met, only 5% were actually good at their job. (Unless you think their job is to feel important and bully people in which case 95% were good at their job)

Excellent question.

Usually, organisations don't know until it's too late. EA is all about strategic planning. You only see fruition after and over a number of years in the future

@Aleks: “Kevin - While I love a good discussion, I think you're partially missing the mark. Majority of challenges that I've encountered stem from people believing they see the solution without understanding the problem.”

However, adopt the paradigm of Enterprise Debt (see PEAF) and the debt that is usually hidden is exposed and management will be able to see EA failing on a daily basis - this then allows them to decide to do something about it or not as they require. Without the debt being exposed (as is the case in 99% or organisations) the hidden debt builds up to a point whereby it gets so big it cannot be swept under the carpet anymore and then you get a massive project that costs a lot of money and takes a long time to execute. See “EA Enterprise Debt” http://www.pragmaticea.com/peaf1comms.htm

──────────────────────────

────────────────────────── @Kinshuk: "every premise that a software project can be handled on the same lines as a construction project is completely wrong." I agree but as no one was presuming that, there is no conflict. @Kinshuk: "Truck number == how many people need to go under a truck before the project comes to a standstill"

Hey, that's cool - I'm going to use that. Only problem is I have found that people who are bullies get more and more angry the more facts and reasoned argument they are presented with!

@Robert: "teams that were left to their own devices were fairly consistent in pulling off the hat-trick whilst the teams that were bullied, hassled and misdirected by a PM were fairly consistent in failing to meet the targets set."

Yes! That’s exactly my point!!!!! (although maybe I’m not explaining it enough) So I’m not sure how you can say I am missing it!

@Kinshuk: "If all the risks in the project were added, what would be the timeline ?"

Comments

Sweet - I'm going to use that as well although, most of the PM's I have worked with seem to regard risks as get of jail free cards.... "What, so your saying that if I force you to do what you say we shouldn’t do the world will end? - OK I accept that, so let's just raise a risk and go on as if nothing has changed". Risks seem to be things that get written down in a risk log and then ignored. Project deadlines always put me in mind of that Douglas Adams quote "I like deadlines. I like wooshing sound they make as they fly by!"

@Robert: "Thanks Robert – I’ll see if I can get a copy."

Absolutely –I think we’re on the same page. Problem is, is a very nasty page. Guys (and any gals listening) maybe we should start a Campaign for the Removal of Project Managers from Projects” ────────────────────────── Hi Gregory,

The other mistake executives (and IMHO CIO’s) make is that they either decide, or are drive to, concentrate on spinning one plate to the exclusion of the others. This is usually because the previous incumbent lost sight of that particular plate and it crashed to the floor. So the next CIO concentrates on (let’s say) cost reduction. This goes very well and he makes massive bonuses until one of the other plates crashes to the floor, and round and round on the magic roundabout we go……. Cheers, Kevin. ────────────────────────── Hi Sean, You need to write a vision statement, to define why you are doing EA and what you will get out of it.

@Aleks: "people *believe* that a certain solution is applicable based on their *assumptions* about the nature of the problem.", “There is always an excuse to shortchange this step, and we all know where that strategy usually leads. ”

It's part of the Foundation section of PEAF.

Reduction of Cost is one goal but sometimes its good to increase cost (for tactical business benefit).

Therefore it's not so much about reducing cost as Managing Cost.

Have a look at the ready to use Vision Document at http://www.pragmaticea.com/peaf0foundation.htm

You need to develop a plan of what to do. You need to develop a list of associated risks to maximise success.

Or, you can use the ones provided for you at http://www.pragmaticea.com/peaf0foundation.htm These come together as a pack and then allow you to go to the board to ask for the money and resources you need to implement and operate that you have decided to do (utilising the maturity mode) Then,

Managing Cost is only one of four plates management need to keep spinning, the other 3 being Managing Risk, Managing Quality, Managing Agility,

You need to develop a maturity model so you can evaluate where you are and where you want to be wrt EA maturity.

You need to develop a set of communication slides to be used to explain to everyone in the organisation what EA is, what it is not, how to utilise it, etc.

Comments Or you can use the ones provided for you at http://www.pragmaticea.com/peaf1comms.htm

You need to develop Metamodel to define what information you will populate your EA model with. You need to develop a set of requirements for an EA tool. You need to develop populating the model.

a process for

Or you can use the ones provided for you at http://www.pragmaticea.com/peaf2model.htm You need to develop a set of EA principles.

You need to develop a governance model/process for operating them.

Hi Gregory, I do know what you mean. At the end of the day, it all comes down to money. But there is one other parameter, that you touch on. And I believe that is the one that makes adoption of EA so very difficult, time. One Exec once said to me “So what you’re telling me is that you want me to spend money today, so that I may (or may not) save me money tomorrow?” Of course, than answer is definitely yes, which means his answer is definitely no. This is, I believe, the crux of the problem regarding EA adoption. (Even if you put aside all the problems of it’s understanding) Putting my cynical hat on (which I sometimes also call my “you may not like it but this is how it is” hat) this is what makes EA a cultural and political and people problem. When senior execs bonuses are based on this years results, they are only bothered with this years costs. It’s the same as what happened in the credit crisis and all the talk about exec bonuses should be based on future performance.

You need to develop a set of metrics for measuring whether you are getting the benefits from them. Or you can use the ones provided for you at http://www.pragmaticea.com/peaf3governance.htm

You need to develop a set of metrics measuring how well you are implemnenting EA Or you can use the ones provided for you at http://www.pragmaticea.com/peaf4management.htm

Cheers, Kevin.

This is also why I believe Enterprise Debt (one of the key paradigms of PEAF) is so key, because, like the toxic debt that built up in the financial sector because no one understood it and therefore no one saw it therefore it didn’t exist, so Enterprise Debt is growing in organisations all over the world. This toxic Enterprise Debt is very real and builds up quietly. When it gets too bad and cannot be ignored any more, you then get a huge project to “fix” it. If you want to know more have a look at the “EA - Enterprise Debt” PDF at http://www.pragmaticea.com/peaf1comms.htm

PEAF is a vendor and consultancy independent, technology neutral, Pragmatic Enterprise Architecture Framework which allows organisations to kick start or re-start an EA initiative and provides a comprehensive EA Framework and associated Toolkit of everything required to hit the ground running.

──────────────────────────

Cheers,

Comments

Kevin. ──────────────────────────

PR @Michael: "I do not think that Business Strategy is A model; " I agree. But it can be represented in a model.

However, we again run into the problem of different definitions of similar things.

The term “Business Strategy” is often used in conjunction with “IT Strategy”. e.g. The business strategy drives the IT strategy. i.e. they are things on a comparable level, one relating to business type things and one relating to IT type things.

IMHO EA is just an enabler, a facilitator - to help an organisation align its Organisation Strategy firstly with its Business and IT Strategies and secondly to align/govern ongoing change with the Business and IT Strategies. This is why I think the statement/title “Best Practices for Aligning EA with the Business Strategy” is a bit strange IMHO PEAF defines the purpose of EA to:To provide the business with: • Structural Models to aid Strategic Planning

In this instance the Business Strategy equates to understanding the current and target states of the organisations business entities (such as processes, customers, suppliers, locations, operating model, etc.) and the projects programmes and initiative required to move from one state to the other. this can be (and is often best expressed) in a model.

strategy, and say it is composed of Means (Mission, Strategies, Tactics), Ends (Vision, Goals, Objectives), Drivers (Influences, SWOTS), and Guidance. It is this model that drives the target and intermediates states of the Business and IT Strategies.

In this instance the IT Strategy equates to understanding the current and target states of the organisations IT entities (such as applications, databases and technologies, etc.) and the projects programmes and initiative required to move from one state to the other. this can be (and is often best expressed) in a model. However these are not separate things. You can't do one and then the other. The resulting projects programmes and initiatives are composed of 0-100% business change and 0-100% IT change. As such the Business and IT Strategy needs to be defined together in an integrated fashion.

• Metrics to measure execution of the Strategic Plan ────────────────────────── Hi Matthew,

No problem you contacting me.

I don't think there is anyone at nationwide interested in EA at all! I left there last month, and while I was there I tried numerous times to get them to understand and bit the EA paradigm utilising PEAF (Pragmatic EA Framework). They are just not interested.

It's one of those places where you can sit down with someone and tell them that if they would like to do something that will cost them £1, but next week you will give them £1,000 - they look at you all glassy eyed and come up with any number of

So the only thing left is to decide what causes us to define the target state of these two areas. The answer is also sometimes called the Business Strategy, which is why it’s very easy to be talking at cross purposes. Let’s call this “thing” the organisations

• Governance to manage alignment to the Strategic Plan

Comments reasons why its not a good time for them to make £999.

It's the same as 99.9% of all organisations in the UK. Things don't get done because they are good ideas, things get done because someone senior decides they will be done. Whether its a good thing to do or not is just not part of the equation. I noticed you posting recently, did you guys just pop up or have you been around for a while? I only ask because you appear to have taken what has been in my brain for a while (now in terms of a way of structuring unstructured information to make it easier for people to understand.) and written some software to allow it.

Of course I’m not saying you have stolen my ideas, its just that we seem to be thinking in the same way.

If you want a contact at Nationwide, Kev Robinson would be a good start – he’s in IT but been there ages and knows a lot of people. You can get him on kev.robinson@nationwide.co.uk Cheers, Kevin.

We've worked with Nationwide in the past (Martin Watkin has probably been our main contact) but I've got a bit out of touch. Huge thanks if you felt able to broker an introduction, Regards, Matthew ────────────────────────── Hi Sharon, Yes I do. It's split into 3 phases: 1)

Planning.

Implementation.

Operation.

Planning consists of the tasks to evaluate where an organisation is in terms of its EA Maturity (utilising the PEAF Maturity Model), and determine where it wants to be and in what timeframe, and then the resulting tasks and costs associated.

You knowledge Genes (I call them knowledge beans) look like mine but mine are more recursive.

On 10/28/09 3:30 AM, Matthew Whitcombe wrote: --------------------

Implementation is the phase required to make the necessary changes to implement what was identified in the Planning phase. The Operation phase consists of the tasks required to operate EAas defined in the Planning phase. Of course, the Implementation and Operation phases as completely dependant upon the work done in the Planning phase, however, the .mpp provided details the tasks required assuming an organisation is currently at Level 1 in all aspects of EA Maturity and wishes to move to Level 2 in all aspects of EA Maturity.

Hi Kevin, hope you don't mind me contacting you privately with a question: is there anyone at Nationwide who might be interested in hearing from us about our EA approach? http://www.knowgenes.com/

The end of this phase culminates in going to the board with a request for funding to implement and operate the identified actions.

These parts of the plan are therefore very dependent upon the particular organisation in question.

Comments

This .mpp is due to be released as part of the v1.2 release of PEAF due next month, although due to pressures of other work this release will probably slip to Q1/2010. The .mpp is only 95% complete but I can send you a pre-release PDF if understood how it would be used. Cheers, Kevin.

On 10/28/09 11:19 AM, Sharon L. Stran, CEA, PMP wrote: -------------------Hi Kevin

Thanks Sharon

The pertinent question is “is the EA initiative delivering on the objectives set out for it?” Let me explain it another way. Imagine a company not "doing PRINCE". Essentially this means that the projects it runs are not run very well, products are not well identified, etc, etc, etc. Then, someone suggests utilising PRINCE2 to improve matters, so you create an initiative to plan, implement and operate PRINCE. Now ask yourself this question - Is it a valid question to ask if the PRINCE initiative is aligned to Business Strategy - it doesn't make sense.

I wanted to ask you if you had an architecture effort project plan using Microsoft Project. I am in the process of getting together some templates and wondered if you had anything I could use.

My point is that asking if this EA initiative is aligned to Business Strategy doesn't make sense.

──────────────────────────

@Anne "Very true @Kevin, if you take a purist view of EA." I don't take a purist view Anne. I take a pragmatic view. And, I take your accusation of me taking a purist view as deeply insulting.

Apologies are due however as I think I misinterpreted the title "Aligning EA with the Business Strategy"

Then, someone suggests utilising EA to improve matters, so you create an initiative to plan, implement and operate EA.

I am not saying the content is wrong, its just the title doesn’t sit well in the psyche. ────────────────────────── @John: "They had started creating excel sheets with applications, their technologies and what they support, but soon realised that this approach would not scale" That is a common mistake made and is one of the things that utilising a framework reduces or eradicates. @John: "they needed not to look at PEAF, TOGAF and alot of the stuff" Excellent!

Frameworks only exist to help people do the right thing. If they know what the right thing is to do and how to do it there is no need for any framework.

Imagine a company not "doing EA". Essentially this means that the business and IT strategy are not aligned, and the business and IT are not working together in partnership, etc, etc, etc.

The pertinent question is “is the PRINCE initiative delivering on the objectives set out for it?”

This is also true of PRINCE2, MSP, SIXSIGMA, LEAN, etc, etc.

Comments

witnessed hundreds if not thousands of discussions like this.

There were excellent project managers and projects well managed long before PRINCE2 came along , but there were a lot of projects that were badly managed. PRINCE2 helped more people do "the right thing, in the right way"

Yes, of course, I am all for free speech and hearing everyone's views etc etc etc but when one is asked a question, I find it to everyone’s benefit if we restrict ourselves to answering the question as completely and as succinctly as possible within the bounds we have been given for answering it.

For some companies/people they get all the benefits these things create without using them because they just know (implicitly or explicitly) how to do things (at the end of the day, 99% of this stuff is logical and common sense after all!)

The point I am making is that people should not read from your post that organisations in general do not need frameworks. Of course it depends on the maturity and size of an organisation (and lots of other things too) which framework you wish to use.

And I asked myself, what did those discussions achieve. I have to say, IMHO, I think they achieved nothing.

If the CEO of a company asked for a 1 paragraph business case, I do not think he would be impressed if he were provided with a 13 page essay - even if that essay contained the secret to perpetual motion or how to generate energy through the power of dance.

PEAF was developed to kick start EA initiatives by providing pragmatically what is needed in 99% of situations.

Of course, an organisation that is already "doing" EA and doing it well would have no use for PEAF or any other framework. ────────────────────────── Guys and Gals...

Can we please remember the purpose of this thread.

And ask ourselves - are we aiding or clouding peoples understanding? (And when i say people, I mean senior people who we need to communicate with).

This is the last post I will make in this forum on this subject as I believe this is my third time of saying the same thing. I will restrict any future postings of mine to the analysis of the 160 character strings that have been posted. The power is in the hands of the people posting here. You can either post something useful or not.

────────────────────────── In order to answer the question posed we first have to do 2 things.

If we cannot even keep ourselves (the people who are supposed to know what we are talking about) from devolving once again into long and IMHO pointless discussions we may as well all go back and do what we used t do before we were bitten by the drug called EA.

I am sorry if I offend some people, that is not my aim, however the threat of offending some people will not detract me from my mission to make EA understood by everyone who can gain benefit from it.

This thread is a challenge not a discussion. It was specifically designed not to be a discussion because, in my experience, I have

First we need to agree what the purpose of a framework is. Secondly, having understood the purpose of an EA framework, the next thing to agree on what constitutes an EA framework. I.E. what

Comments organisation is at level 1 of the maturity model and wishes to progress to level 2.

Here's my two cents…

Risks

Q1: What is the purpose of an EA Framework?

This document details the risks associated with bringing Enterprise Architecture to an organization. Each of the risks are further defined by the impact and general mitigation strategies. A placeholder is left for specific mitigation strategies for each individual organization.

"things" or products should it contain to qualify as an EA framework.

=============================== ====

To provide organisations and government bodies with an understandable, effective and pragmatic framework to enable them to quickly understand and adopt Enterprise Architecture and thereby reap the benefits it can bring.

Q2: What products should comprise an EA Framework? =============================== ===========

====================

This document details the vision, goals and objectives of the Enterprise Architecture approach that has been adopted. Maturity

This document details the Pragmatic Enterprise Architecture Framework (PEAF) Maturity Model which describes maturity levels for each part and sub-part of the Framework. In addition to the descriptions of each level, the model details the expected benefits, costs and tasks required by an organisation to move from one level to the next.

A set of communication materials (powerpoints) to educate others on EA in general and the specific framework itself. PRODUCTS – Model ================

Details a high level plan for gaining agreement for a programme of EA work and an example plan for the tasks and work that would be indentified assuming an

Metamodel

This document details a high level Metamodel which describes the entities (things) and attributes (information about those things) that should be gathered when embarking on building an EA model. This starter set of entities can be modified and augmented in any way depending upon the specifics of the organisation it is being used in. Tool

This document details an approach to tool selection. If it is decided that a proper EA Modeling tool is required this document lists the main vendors, a set of requirements, and the resultant scores to arrive at a chosen tool and vendor. Content

Plan

========================

PRODUCTS – Foundation

Vision

PRODUCTS – Communication

This document details the problems, roles and processes required to effectively set up the EA Models initial content. PRODUCTS – Governance

Comments

It was even discussed/agreed with a lot of EA experts at the summers Open Group TOGAF Forum!!!!

===================== Principles

This document details a set of principles that have been adopted and agreed by the Board. The purpose of these principles is not to constrain, but to provide a broad cultural framework in which work will be carried out. Process

This document details a governance process and framework that is used to manage conformance with the Enterprise Architecture principles. PRODUCTS – Management

====================== Metrics

This document defines the overall EA process (as distinct from the Governance process) ────────────────────────── Hi Ana,

TOGAF has caused so much damage to EA by perpetuating the myth that EA is IT architecture. ────────────────────────── @Nick: "But is it pragmatic to invent a new framework instead of just adding on to one that already exists? " If there was one thing that TOGAF doesn't need, it is to be made larger. This is the reason I did not approach the open group (not even sure if they would give me the time of day anyway!) Secondly, I don’t think it’s very pragmatic to embark on a “change cycle” that is likely to take years.

This document details the metrics that measure and monitor how well Enterprise Architecture is helping the organisation and delivering on its goals and objectives. Note: These metrics are separate and distinct from the EA Governance metrics defined for each principle. Process

Does everyone remember this quote (you can apply this to anythimg, an applicaion, a proess, and entrprise, a framework)...

"An architect knows when his job is finished, not when there is nothing more to add, but when there is nothing more to take away."

I think one measure of a framework is not in how big it is but how small it is – of course you need to provide the right content which is why I began in this discussion by getting people to define what the purpose of a framework is and what the products of such a framework is. To progress these points, I have created another discussion so as not to clog this one up…

Many people for many years have thought TOGAF was an EA framework just because it said so. Many people, to seem intelligent would talk about TOGAF and how it was an EA framework, not because they had used it but because they jumped o the bandwagon.

The key thing is being pragmatic.

However, those people that are EA's (and I'm talking industry leading EA experts here) all agree that TOGAF is not an EA framework.

“Q1: What is the purpose of an EA Framework? Q2: What products should comprise an EA Framework?”

Comments

@Nick: “Kevin: do you have, as a reference, an organization that adopted PEAF as a replacement for TOGAF or EACOE or NGOSS/eTOM or FEAF and found more value in it? A white paper that goes into depth about that value proposition and actual experience would help me to see value in what you are doing.” Good question Nick. The simple answer is no I don’t. But I think there are three reasons for this.

#1 The time required for anything new to get traction is usually extremely long. This is even more true of EA and especially EA frameworks. There is also a political element to this timeframe because those that have bought into TOGAF as an EA framework are going to find it a bit difficult to change tack quickly.

────────────────────────── @Tony: "Enterprise Architecture is about a way of thinking" 1000% agree. However, when considering frameworks you have to agrere on what a framework is for. Project management is not about a framework (PRINCE - this is a framework also) If you and you company know how to do good project management then you don't need to even glance at PRINCE.

#2 PEAF was launched from a standing start only 11 months ago and as such even if people started using it in anger immediately (which is obviously not going to be the case) I would be hard pressed to get any references in such a short timeframe.

you would change on a Trabbant to make it more like a luxury cruiser? You can ask the question of course but would you ever do it? This is why I believe young people offer massive potential for any business exactly because they have no experience and are green. They see things differently and spot things that the very knowledgeable and experienced are blind to.

#3 I am an Enterprise Architect not a Marketing man. As such things I should have done such as contact all of the over 500 licensee’s to ask them their opinions and their use or not of PEAF just haven’t got done. Now PEAF is due to have it’s 1st birthday (25th November) I think it’s time I perhaps put together a questionnaire form on the website and chased people for real feedback.

@Nick: “If you could change the TOGAF in some specific manner so that, as a result of the change, you would consider TOGAF to be a valuable and useful EA framework, what change would you make?”

A framework is just a tool. And like any tool, if it's used/implemented/operated badly you shouldn't blame to tool when you get bad results. Use a hammer to bang in a screw and you will bang it in. It's just that it will take a lot more energy to do so, and the screw will promptly fall out the first time any pressure is applied. But Tony - Is TOGAF an Enterprise Architecture Framework or an IT Architecture Framework?

Personally I wouldn’t attempt to change it. Sometimes you just have to start from scratch, and in doing so therein lies true invention. Did MS change Windows 3.1 to make it a better operating system or did they start from scratch. Is it valid to ask what

However, if you and your company are not very good at doing project management, then a framework like PRINCE is extremely beneficial. Of course you don't follow it like a maniac to the exclusion of everything else.

────────────────────────── Zachman is a metamodel not a framework.

Comments A metamodel is an important part of an EA framework but INHO its not the only thing that should be part of a framework.

Or I guess you could say it was an EA framework but one with lots of missing things. Also, I think the zachman metamodel is a good target, but I'm not sure it's a good place to start ────────────────────────── I just had a thought...

I think it would be very useful if we defined things we can use to determine whether a framework/ what people are doing is Enterprise Architecture or Enterprise IT Architecture.

Heres my list …

You are probably doing Enterprise Architecture if you are… You are probably doing Enterprise IT Architecture if you are… 1.

Talking to the CEO Talking to the CIO

2. Concerned with strategy planning 2. Concerned design and implementation

and with

3. Working at an enterprise level giving direction to all projects. 3. Working at individual project level 4.

Technologies) 5. Working with the IT of the enterprise (Processes, Services, Applications, Databases, Technologies, Networks) 6. Working mainly at the logical level. (Projects develop the physical expressions of the logical) 6. Working largely at a physical level 7. Working with HR on motivation models 7. Working with HR on Technical role definition. IMHO - Suggested changes to this list would be beneficial, monologues that do not move this list forward would be less beneficial… ────────────────────────── @Frederick: "These numbers under IT Architecture don't work either and should be changed as follows: 3. Working at an enterprise level giving direction to all projects.

It’s not black and white, but I think this would help people with understanding the distinction.

Working with strategic planning 4. Working with project planning

Agreed.

@Kirk: "Kevin - nice. The one thing I would add/change to your CEO reporting set, is that EA is typically a President AND a CIO (not CEO) dual reporting role. " Agreed but I'm not sure if the President role would make the journey across th pond. Update to CEO/MD and CIO. @Art: "Much as I would like to see and EA report directly to the CEO I think that in a company of any size it it highly unlikely." Agreed, but I think its more driven by rather than reporting to - I have updated to reflect this.

6. Working mainly at the logical level. (Projects develop the physical expressions of the logical.) "

=============================== =====

Comments

You are probably doing Architecture if you are…

Enterprise

I don't see as EA a thing that sits somewhere. EA is a process, a culture.

2. Concerned with strategy and planning

Adopting and operating EA (which means an EA culture) is done more by making adjustments to various parts of an existing organisation, not by creating a whole new group called EA which needs to be placed somewhere. Kind of like re-factoring.

1. Talking to the CEO/MD and CIO

3. Working at an enterprise level giving direction to all projects. 4. Working with strategic planning

5. Working with the entire enterprise (business mission, business vision, business drivers, business objectives, business goals, business tactics, strategy, Customers, Products, Activities, Departments, Functions, Locations , Services, Applications, Databases, Technologies) 6.Working mainly at the logical level. (Projects develop the physical expressions of the logical)

EA is a culture and as such is pervasive (it is if its going to work properly) therefore it makes changes in various groups in the organisation, the Board, Planning, HR, Finance, LOB's, IT, Change Management...

Think of EA as the marbling (fat) in a very expensive piece of Argentinian beef it doesn't exist in one place - its pervasive and gives the meat the sweetness and flavour. And the beef would be less than what it could be if it were removed, but if it were not present it would still be a piece of beef.

7. Working with HR on motivation models

You are probably doing Enterprise IT Architecture if you are… 1. Talking only to the CIO 2. Concerned implementation

with

design

and

3. Working at individual project level 4. Working with project planning

5. Working with the IT of the enterprise (Processes, Services, Applications, Databases, Technologies, Networks) 6. Working largely at a physical level

7. Working with HR on Technical role definition.

────────────────────────── @Roderick: "What do you think of EA sitting in the corporate office, "

EA does not decide how things are changed it enables the people in the organisation that do that or should do that, to do it better. EA does not do modelling - it enables the people in the organisation that do that or should do that, to do it better. Organisations are already doing these things without "utilising EA" That’s the main reason why it's difficult for people (especially board members) to see the value of EA. Without utilising EA, and organisation will still exist, people will still do work, decisions will still be made, things will be bought and sold, money will be mad.

=============================== =====

EA does not do strategy formation - it enables the people in the organisation that do that or should do that, to do it better.

EA does not make a bank, a bank. EA makes a bank, a better bank.

Comments It’s like SCRUM, MSP, PRINCE2, SIX-SIGMA, etc etc. They are all frameworks to help people do stuff better.

Organisations existed and made money long before they were invented or used, but that does not mean they are worthless. EA could learn from these by understanding how they were “sold to the board”. So, imagine no one had heard of PRINCE2 – How would you “sell it” to organisations? ────────────────────────── @Kinshuk "245 definitions (comments on this thread) is a good precise way to pin down EA. " In order to find a solution (pinning down EA) you first must understand the problem.

1. This is the first step.

2. The second step (which will happen over the next couple of weeks) is to analyse the problem domain, find synergies, connections, similarities, differences, etc, etc from which I will create what I believe to be "THE" statement - others can do this also of course. 3. The third step is to present this analysis for discussion in order to find which statement has 80% of the votes.

I believe this process is "a good precise way to pin down EA." ────────────────────────── @ Kirk

Programme, Project or Business Change Manager in changing WHATEVER needs to be changed in line with vision for the business and business strategy. " Yes - although EA is grounded in strategy and planning (for the whole enterprise) it has tendrils going down int the world of projects and change. This is accomplished with Governance. @Matt: "Thus there is a valid role for an Enterprise Architect to be involved in IT (and with IT contractors too, by the way and so it would help to talk to them so that they understand it, just as much as you need to talk to the top level businesspeople so that they understand it too!!) " I absolutely agree that everyone from the CEO to the tea boy needs to be involved in communication about EA in an organisation, that is the only way EA moves from being a process that is being followed to being a culture that is self perpetuating.

This thread is meant to show, expose, quantify the problem.

I have added the focus to the list as I think it does add something… =============================== ===== You are probably doing Architecture if you are…

Enterprise

1. Talking to the CEO/MD and CIO

2. Concerned with strategy and planning 3. Working at an enterprise level giving direction to all projects. 4. Working with strategic planning 5. Working with the entire enterprise (business mission, business vision, business drivers, business objectives, business goals, business tactics, strategy, Customers, Products, Activities, Departments, Functions, Locations , Services, Applications, Databases, Technologies)

Cool! There is hope for us all!

@Matt: "there needs to be a distinction between maintaining the ongoing vision by contrast with what is done to enable and deliver it. As such, in the latter case/list, the Enterprise Architect will work with a

Comments

6.Working mainly at the logical level. (Projects develop the physical expressions of the logical)

Yep! EA is still trying hard to be understood - but I think slowly people are beginning to cotton on.

I believe one reason it is not understood by more organisations is because those organisations that "get it" generate massive competitive advantage from it. And they rightly do not want to give that advantage away to other less informed organisations.

7. Working with HR on motivation models 8. Focus - Strategic

You are probably doing Enterprise IT Architecture if you are… 1. Talking only to the CIO 2. Concerned implementation

with

design

and

3. Working at individual project level 4. Working with project planning

5. Working with the IT of the enterprise (Processes, Services, Applications, Databases, Technologies, Networks)

On another tack, there is a new framework (oh no not another one!) that takes a much more pragmatic approach. It was released around a years ago and V2 will soon be released.

6. Working largely at a physical level

From what I see EA seems to be more accepted and used in government bodies than private companies – USA, South Africa, Singapore, Korea, etc, etc. Maybe we just hear more about these because governments don’t really compete with each other and therefore have nothing to hide.

7. Working with HR on Technical role definition. 8. Focus - Operational

=============================== =====

──────────────────────────

@Matt: "I don't think that there is such a thing as Enterprise IT Architecture."

PEAF – Pragmatic EA Framework – (www.PragmaticEA.com) and it’s FREE to use for Individual Consultants, End-User Companies, Government Bodies and Academic Institutions. If v1 blows your socks off (as one senior and well respected industry analyst said) v2 will blow you legs off… ──────────────────────────

I think there is , there are many examples.

@WOLF:

Nationwide Building Society has a group within IT called "Enterprise IT Architecture". I know because I just finished working there on a 3 month contract.

I disagree with a lot of what you say but I think you may have stumbled over something really quite prophetic……..This is why I absolutely love to talk to people who disagree with me……..

The are just using the word enterprise to mean large scale or big. ──────────────────────────

@WOLF: "Your discussion has brought absolutely the same results.”

Also the terms "Enterprise IT Architecture" or" Enterprise Application Architecture" are the two terms that most commonly people mean when they say Enterprise Architecture.

It hasn’t brought any results yet apart from an initial statistical anaylsis of the source data.

Comments This is not the end of the analysis, it’s the beginning.

@WOLF: “Do you or any other participant of the discussion know better now what 'elephant' looks like? Any advancement in EA is impossible, until blind men regain vision and will be capable to precisely define (not opine about) the poor animal. Until then, have fun by combining any of 'frequent' nouns with any of the verbs. Any combination is acceptable and laughable. " The problem being addressed here is that there is no widely accepted definition of the purpose of EA. This road may lead nowhere but I think it has possibilities that are worth pursuing.

Rationale: All parts of the organisation (HR, Business areas, Finance, IT, Procurement, Marketing) can only see a part of the elephant – in fact they don’t even know the part they are looking at is part of an elephant. EA allows strategic planners to see that the pieces make an elephant, having realised that, that common overall view is then communicated to each area so they understand how their view (that doesn’t look much like an elephant to them) fits in to an overall picture of an elephant. Don’t think of the pieces of the elephant being looked at by different people. Think of those pieces thinking about what they are…..Does the foot know its part of an elephant? Of course at some point the analogy breaks down (like all analogies do) because in an elephant the brain directs everything at fin granularity. There is no intelig4ence in the foot. The foot only does what the brain tells it to do. In this way for the analogy to continue you have to think of an elephant as having a brain, yes, but each foot also having a brain. So, The brain in each foot can tell the leg to move but now when. The brain in the head can tell the foot when to move but not how. In order for the elephant to walk both brains are fundamentally required but they have to work together with the head doing the choreography and the feet doing the work….Now I feel a book coming on…a radio show…a mini-series…a movie…an Oscar…cheering…fame…fortune…to answer to life the universe and everything……and all because you, Wolf, disagreed.

To get consensus you need a large number of people and you also need to let those people express there views and be part of the consensus that is formed. These are steps along a road.

@WOLF: “Any advancement in EA is impossible, until blind men regain vision and will be capable to precisely define (not opine about) the poor animal.” Agreed. This thread is attempting to do that.

If you have any other suggestions about how to do that what are they?

Are you part of the problem or part of the solution? I think your elephant analogy does have merit but I think it should be applied to an Enterprise not to EA itself – here’s another 160 char definition… The purpose of EA is….

Fantastic. I owe you a beer. ──────────────────────────

EA only applies to medium to large companies - companies where their business processes, customers, suppliers and IT is complex.

“To allow the business to see the elephant”

“To allow the enterprise to realise it is an elephant”

EA = Efficiency Applied.

Comments • The possibility of mergers and acquisitions - Happened rarely

Being efficient breaks down into 2 main areas :-

• Introduction of new products and services - Happened rarely

• Operational Efficiency - Efficiency of operation

• The wax and wane of suppliers Happened rarely

• Transformational Efficiency - Efficiency of change

• The creation and demise of market and customer segments - Happened rarely

To understand more, we can look at the “The Past” compared to "The World Today".....

• Changes in scale - Happened rarely

Any enterprise has “To be efficient” as one of its Goals.

########## # The Past #

##########

Operational Efficiency

In the past, operational efficiency was a key business driver and differentiator. This led to production lines, mechanisation and automation. Transformational Efficiency

=====================

Efficiency of change was not really important at all because things didn’t change very much. Change drivers

Ease/difficulty of making changes -------------------------------------------When an enterprise did need to change (since processes were largely carried out by people who are extremely easy to change) it could make those changes very quickly by telling those people to do different things, by employing more people or by sacking people.

================

• The introduction of new machines (and technologies) - Happened rarely

---------------------

• Changes in Legislation - Happened rarely • Competitors strategic moves - Happened rarely

# The World Today #

################# Operational Efficiency

=================

In today’s business world, operational efficiency is still important. However as enterprises have got more and more efficient in this area the scope for further gains is reducing. In addition, because of a lack of attention to the Transformational Efficiency, operational efficiency has been slowly and quietly adversely affecting the Transformational Efficiency.

Enterprises tended to do produce the same products in the same way using the same people and the same tools for long periods of time. Things that could change which would require the enterprise to change only changed very slowly.

#################

Transformational Efficiency

-------------------------------------

Comments

business processes is causing a severe bottleneck in the enterprises ability to react to change in a timely and commercially sensible fashion.

Change drivers

If you believe that…

--------------------

“The only constant is change” - Heraclitus of Ephesus

Transformational Efficiency is becoming, and will continue to be, a key business driver and differentiator. This importance grows year on year.

Enterprises today exist in an environment of constant and fundamental change, and therefore enterprises need to be able to adapt and change quickly to cope with this maelstrom. Those that can will grow and prosper. Those that don’t will succumb to those that do. • Changes in Legislation year on year

Can

occur

• Competitors strategic moves Happen daily.

“Change or die.” Alan Deutschman of Princeton.

────────────────────────── @MATT: "but where's your own hypothesis and/or action plan to now align views and come up with a solid definition yourself?"

• Introduction of new products and services Happened rarely The wax and wane Happened rarely

suppliers

• The creation and demise of market and customer segments Happened rarely • Changes in scale

I always have my views, but I choose when to express them.

• The possibility of mergers and acquisitions Always a possibility/opportunity.

•

then enterprises need to…

Happened rarely

• The introduction of new machines (and technologies) Happened rarely

I don't have an action plan, but then again, I don't think I need one. The general flow is now causing some more analysis to be done and depending on what that turns up and peoples responses in the discussion to the initial simple analysis, that may lead us in different directions. I have a broad plan, but I am seeing where this is leading. MATT: “you need to re-evaluate your approach if you want to get some industry kudos from this and support in getting work in this space (which I presume is the point of you doing this exercise, right?).” Wrong. I don't want any industry kudos or any other kind. You are totally wrong in what you think I want to get out of this.

Ease/difficulty of making changes

---------------------------------------------

I am not a marketing or sales people and tend not to get on with those kinds of people either because while the whole world seems to prefer style over substance, its not what you say but how you say it, I am totally the opposite.

When an enterprise needs to change today it cannot rely so much on the limitless adaptability of people to effect that change.

This is because so much of how an enterprise does what it does, is now either completely or partially automated and the complexity of those automated systems and

Comments

Personally, I couldn't care less about the style, I care about the substance. I could not care less about HOW someone tells me something, what’s important is WHAT they are saying not how they say it. I didn't particularly like a lot of your last post, but it was not because of how you said it, it was what you were saying. If people say something I disagree with I will tell them. I they say something insightful I thank them. This is proved by the fact that I actually saw a great positive in what you said also, which is why I said "Fantastic. I owe you a beer." And I still do.

MATT: “Note how I have not put this comment in the discussion thread itself - but sent it through to you privately”

Censorship (self inflicted or applied) is the cancer of the business world. Cheers, Kevin.

- EA is not about making decisions, its about providing the business with the information to make better more informed business decisions. - Explaining the purpose of EA is not about telling organisations to use EA, it's about providing the business with the information to make a more informed decision whether to utilise EA or not. As an Enterprise Architect, my job is not to make decisions – it is to present all the facts and knowledge I can to people who do make decisions. If I have done that my job is done whether I agree with their decision or not. ────────────────────────── Hi Ana,

Don't feel you have to privately email me. Anything you want to say regardless of how nice or derogatory, can be posted on the discussions.

This is effectively recursively applying EA to itself!

No problem - You've got to have a thick skin.

But you've also got to be the adult that guides the children away from chasing the big red balloon with all their screaming and crying and tantrums and get them to cooperate at playing pass the parcel!

──────────────────────────

I understand your TOGAF approach.

@MATT: "we need clarity and consistency amongst those seeking or considering to market themselves as an "Enterprise Architect" themselves, as to what the definition of EA is and what value it adds."

I am a TOGAF Certified Practitioner (one still has to pay the bills) so I see no problem in anyone learning about TOGAF

This is NOT a marketing exercise.

The purpose of the discussion is to agree on the purpose of EA so that when stated to Boards and leaders of organisations, it would

b) decide that they should be doing something about it (or not).

a) allow THEM to understand the purpose of EA which would them allow THEM to

As in my role practising EA, I only try to help people see through the smoke and mirrors and see things for what they are, simply, pragmatically. What decisions they make I really don't mind one way or the other - so long as I have given them the pragmatic view, I am happy. TOGAF is good for what it is (although watch this space as there will soon be a Pragmatic offering at that level. Although PEAF and TOGAF don't really compete because they are not the same

Comments thing, Pragmatic will come into direct competition with TOGAF because later this year will see the release of :

- PSAF - Pragmatic Solution Architecture Framework - PBAF - Pragmatic Business Architecture Framework

- PTAF - Pragmatic Technical Architecture Framework The reasons for that is 3 fold.

a) provide some pragmatic advice in those areas

b) show that these areas are not part of the EA area

c) show how EA, SA, BA and TA are all tied together.

Kevin.

“The purpose of Enterprise Architecture is” … Obviously if the statements you can find do not define the PURPOSE, then for this discussion they effectively do not exist. @ADRIAN: “I would conclude from here that, in practice, there is a kind of lawlessness in the EA community, that practitioners think that there are not many relevant or accepted standards, to guide them” Agree. @ADRIAN: “Or that there is no forum to sanction and drive EA.” Agree. @ADRIAN: “So architects employ own views, not only producing their own definitions but probably specifying their their ideal jobs according to definitions. “

Cheers,

Agree.

──────────────────────────

@ADRIAN: “Over 340 entries. It appears that everybody assumed that this is a contest or a competition rather than a collaborative effort.” Disagree. 340 entries collaborative effort.

proves

@ADRIAN: “Hence, so many "original" entries and so few quotes from popular work, frameworks... Zachman, for instance, has done an outstanding work in explaining the "why" of the Enterprise Architecture.”

Agree.

@ADRIAN: “Let's help narrow the diversity down.” Excellent.

I thought that was what this discussion is doing. It has not finished and therefore we don’t have one yet. @ADRIAN: “A logical statement of purpose: given the fact that the EA is in fact a blueprint, there is no single purpose.”

This indicates to me that the problem exists, and therefore we need to do something about it. “A problem, remains a problem, until you do something to solve it”

@ADRIAN: “The EA body of knowledge is not mature enough, for sure. But, even so, the diversity of opinions is worrisome because it proves to our customers that our discipline is not properly defined at all, as yet. “

Of course, if existing definitions are good then let’s hear them. Can you complete this statement with text cut from Zachman and TOGAF for us please...

There may not be one single purpose but the purpose should be able to be described succinctly so other people can understand it.

Comments

Not sure how this statement of your correlates with your previous one. First you say is already adequately defined then you say there is no single purpose.

@ADRIAN: “”Each and every stakeholder would use the EA for his own purpose, according to the scope of work." There may be some purposes you prefer. So, in the end, we are all correct in our statements. “ Agree. At the moment. That is because there is no consensus. That is why I am attempting to do something about it. @ADRIAN: “Strategy alignment, business process improvement, decision making, replacement of a system, isolation of a fault etc they are all use cases for the EA.”

@ADRIAN: “I would suggest though another avenue rather than the verb noun analysis, that is if you decide to proceed. Why not voting on the 3 best definitions, now, that we have an oversight of the whole discussion. “ Agree.

This is just the initial analysis, the other analyses that are being done by Nicklas Malik from Microsoft and Stephen Heffner from Pennington will shed more light. ────────────────────────── Hi Kirk, I like your analogy and I have used it myself before but I have the roles reversed.... In business the CxO’s decide what needs to be done and the EA (not that it is one person but the governance part equates to that) makes sure that people do things in the right ways, while the workers do the work. Hence, in my analogy, the CxO’s write the score (the strategy/plan what and why) and the conductor (EA - via governance) makes sure that the performers (workers) are guided appropriately to get the best out of the music (strategy/plan)

Depends on specifics of course but broadly agree (if “a fault” is a piece of software not working then I would say no. if “a fault” means IT and the business not working cooperatively together, I would say yes)

Agree. That the whole point is to “narrow the "why" down to one sentence supported by the majority.”

But, how do you propose to decide which are “the best”? Who will decide which are “the best”?

@ADRIAN: “That way, we may narrow the "why" down to one sentence supported by the majority. Not that it would necessarily be the right one.”

Cheers, Kevin.

──────────────────────────

@NICK: "I think I will finally get some time tonight to work on the analysis of the data that Kevin sent me. I will post my results. " Excellent. One more step, that's good. @ALL

Come on guys (where are the gals?) Chill out! We are all intelligent adults and as such I see no reason for anyone to get annoyed, frustrated or stressed.

We first have to find out what the most common definitions are (don’t forget of course there may not be 3 common ones. A step in the right direction is to initially analyse the kinds of things (nouns and verbs) people use when the define the purpose, this may lead us to 3 or 4 or 5 synthesized “best” definitions.

I’m interested in your view on my opposite view and to understand more why you see it opposite to me.

People can (and will) disagree sometimes.

Comments

it will allow much easier and better analyses of the posted responses.

People can (and will) react with knee jerk reactions sometimes.

──────────────────────────

People can (and will) misinterpret what you say sometimes.

People can (and will) sound arrogant sometimes. In this world of fame, X factor, celebrity et al we intelligent people should be the ones to ignore style of over substance. "Its' not what you say, but how you say it" what a load of cobblers! Let's look past how people express themselves and concentrate on what they are saying. This banter is OK while analyses are going on.

# # SIMPLE ANALYSIS RESULTS – TAKE 2 # ############################### ######### I have updated the simple analysis in two ways. 1) I have included all new definitions posted 2) I have grouped related words into groups and combined their counts.

Now I have been lambasted before for not "having a plan". The reason for that is because I like a bit of flexibility sometimes to see where things go and then decide what the next steps might be.

############################### #########

My "plan" has now coalesced and I think after the analyses that are in progress have finished, I will start the discussion off again (in a new thread).

That thread will ask the same question but will restrict peoples answers to only using a certain set of words. (The words would be considered stems so any related word could be used. e.g. if analysis was a word then analysed would be ok to use also) People can then restate their definition but only using those words - as many or as little as they want that they think are applicable.

Out of these 630 words There were 401 distinct words or word groups (e.g. 1 group = "business, businesses, business's, business") The top 20 words/word groups are: -

- BUSINESS (89) business's, bussiness)

(business, businesses,

- TECHNOLOGY (46) (tech, technical, technological, technologies, technology, system, systems) - STRATEGY (36) strategically, strategies, strategy)

(strategic,

- ORGANISATION (34) (organisation, organisations, organization, organization/business, organizational, organizations, organization's)

In this way, we still provide people flexibility to use or not use words but by restricting the set they choose from (to maybe 20???) I believe this would then take us one more step towards a consensus.

Out of a total of 777 words, 147 were ignored (is, a, at, on by, etc, etc) leaving 630 distinct words

Even if the resulting definitions are still wildly different that won’t matter, because since they will all be coming from a restricted list,

- ALIGNMENT (27) aligning, alignment, aligns) - PROCESS (22)

(align, aligned,

(process, processes)

Comments

- PLANNING (19) plans)

(plan, planning, (change, changes)

- CHANGE (17)

- INFORMATION (17) information) - VISION (16)

(info,

(vision, visionary, visions)

- MANAGE (15) (manage, management, managers, manages, managing)

- MODELLING (15) models)

(model, modeling,

- ENABLING (13) enabling)

(enable, enables,

- STRUCTURE (13) (structural, structure, structured, structures, structuring) - FUTURE (12)

(help, helping, helps)

@KIRK: "With a 70%+ failure rate of IT projects, and these same folks want to design the enterprise.... what am I missing here.... oh, yeah, a radical increase of EA failures. Surprise! " OK, I agree that a lot of IT people think they are doing EA when they are in fact doing Enterprise Application Architecture, but I have to take issue with you comment about failures - intimating it is the IT people that are responsible for the failures..... In my experience, over some 30 years, I have never, ever, seen a project fail because of technology or technology people doing the wrong things. 100% of the project failures I have witnessed (probably 90% of the projects I have worked on - no I'm not the common denominator!!!) have failed for two massive reasons, none of which are in the control of IT.

- HELP (11)

(future)

──────────────────────────

- OBJECTIVES (11)

(objectives)

- SUPPORT (11) supporting, supports)

(support, supported,

TRANSFORMATION (transform, transformation, transitioning) - GOVERNANCE (10) governance, governing)

(11) transition,

(govern,

Using the first 10 in one sentence it seems to produce the following: The purpose of Enterprise Architecture is

153 Characters. It is now my intention to wait for Nick and Steve to post their Analyses and then create a new thread asking people to propose definitions that we can vote on.

2. Project Managers or the Business dictating to technologists how to do their jobs. The first is self explanatory, the second requires a bit more explanation. If you employ someone to do something for you that you do not know how to do, it is stupid to dictate to them how to do it or to force them do work in ways that they pretty much know will fail but restricting time, money, resource or scope. If you employ a bricklayer to build a wall, you wouldn't force him to build it "your way". You also wouldn't tell him to only use half the bricks he requires or to build it in half the time he requires. If you did, he/she would only comply if you signed a disclaimer explaining all the risks involved in their decision and mandating that they take responsibility for it.

To ALIGN the BUSINESS and TECHNOLOGY STRATEGY of the ORGANISATION to enable it to achieve its VISION using INFORMATION and PROCESSES for PLANNING CHANGE.

1. Politics

This happens in failed IT projects the only difference being that the

Comments business/management does not take responsibility for forcing the bricklayer to do shoddy work.

I don’t necessarily blame the business/management for this as time and money are the only usual control mechanisms used to make/force decisions. This is where “Enterprise Debt” comes in – one of the main tenets at the heart of PEAF. Architecture (at any level) is not about making decisions. It’s about exposing information for the business/management to make informed decisions and to hold them to account for those decisions.

However, if you mean spending ages discussing what framework came from what framework on which date, etc, etc, I 100% agree - History can be important but personally I couldn't really care less what framework cam from who when and where. If the CEO is not interested in it, then neither am I! ────────────────────────── @JAMES: "Can anyone identify another flavor of EA person that is on this thread than the 3 that I listed? " I see two fundamental types of Enterprise Architects. Type 1 Purpose: Brings EA to an organisation and gets them set up and working correctly.

Have a look at http://www.pragmaticea.com/displaydoc.asp?DocName=peaf-comms-eaenterprise-debt for more explanation of Enterprise Debt.

In closing, someone sent me some information (I can’t find it now) about a study where two IT teams/groups were set up. One group had Project Managers and the other did not./ The group without any project managers consistently out performed the group that did in time, cost, quality and fitness for purpose. There is no “Me” in Team…..But there is “EA” ! ──────────────────────────

@MARK: "the framework has become more important that the supports"

This may be true, but it's not necessarily a bad thing....

Works with: The Board and Executive Management. Term of employment: Typically this is a transitory consultant role. Type 2

Purpose: Analysis of the information in the Enterprise Architecture models and making a major contribution to the annual business planning cycle and day to day operational governance. Works with: Strategic planning Architecture Review Board.

People will not "do" EA if they do not know the answers to these questions.

team,

Term of employment: Typically this is a permanent role. ────────────────────────── I like it !

While the entire planet is struggling to understand what EA is, what's its purpose is, how to "do it", what to produce, with whom, etc, etc, framework can help in that education.

Post it.....

I would make a slight enhancement though... 1) Projects dig the holes.

Comments

2) Management use EA to tell them how many holes to dig, where to dig then, of what dimensions and when to dig them.

PR 3) Projects decide how to dig the holes, what tools to use and how long it will take to build a hole that will not collapse.

--- This last point is where things break down becuase it's usually management (business and/or project management) that sticks their oar in here and force the diggers to use teaspoons and will not provide the wood to shore up the sides..... Cheers, Kevin.

On 01/07/10 4:58 PM, Mark Allard wrote: --------------------

──────────────────────────

@TONY: "Been standing on the side lines of this thread for a while. Some good stuff here but, seems that we are getting into naval gazing phase. "

Agreed. What’s even more worrying is that the discussions are just between EA’s (of various backgrounds and experience levels) and no management, business reps or board members. @TONY: "The fact is that, whether you call this Enterprise Architecture or not, what we "should" do is: 1. Reduce Cost 2. Increase Profit "

My view is there are 4 plates to keep spinning:: Cost

Risk

Quality

Agility

Many organisations (and boards and directors) lurch from one of these 4 being of paramount importance for a period of time (until one of the other plates falls) to another. These lurches usually coincide with the sacking (sorry – resigning – directors can crucify a company but 99.999999% of the time they do not get sacked) of one director or another. EA in general and PEAF in particular allows organisations (through exposing enterprise debt) to expose the impact on these four components to business management to allow them to make an informed decision, thereby stopping the plates falling by only keeping one spinning. ────────────────────────── @Frank: "the engagement model will attempt to show when and where, as well articulate their deliverables and what they actually do..."

Ahh - I understand. t's how EA and EA processes fit into the rest of the organisation. PEAF does include this and it's better articulated in v2. As you say this is massively important. EA does not necessarily introduce a huge team and whole load of new processes costing millions of pounds/dollars/bead . This is, I believe, one of the things that frightens some boards. Introducing EA introduces changes/adjustment to the enterprises processes.

In other words sometimes increasing risk and/or cost is a good thing. Sometimes reducing quality and/or agility is a good thing.

Projects dig the hole. EA tells them where to dig.

Although the general drives for these are to increase (agility and quality) or decrease them (cost and risk) the important this is the Manage them.

EA does not make a bank, a bank. EA merely helps to make a bank a better bank

Comments

@Doug: "Sorry - I am going to monologue a little. I am new to the group but not to the topic. I have found the discussions enlightening and troubling at the same time. I have not had an opportunity to review all 39 pages of string of thought so I apologize to anyone if I am repeating something that has already been said."

No problem, the discussion has turned more into a discussion anyway as we have just about exhausted everyone’s 160 character description (although I am interested that I find that some very high level and well know EA's have not been posting on this board - as I am sure they know about it - I just wonder why....It could be they are too busy, it could be they think this discussion is beneath them, it could be they have nothing to contribute….) ──────────────────────────

Colin Wheeler (Vice President Partnerships) and Executive Vice President, and Mark Goetsch (Co-founder and Chief Accreditation Officer) are well aware of PEAF and my views on EA. I have not problem talking to anyone but my time is limited to seek out people and "sell" the concept - alas I am not a marketing type of person, I don’t’ like it and because of that I’m not good at it. I am only committed to making EA easily usable by End-User Organisations and Governments. Full Stop. It is my view that we (EA's) all need to gather together and sing from a single hymn sheet. If PEAF was that hymn sheet great, if it's someone else’s hymn sheet, great. But my cynical nature tells me that there are so many commercial and egotistical pressures that for everyone to choose a hymn sheet may be near impossible. Still, if in my career I had stopped every time someone told me something was impossible I wouldn’t have achieved 90% of the things I have achieved. To me, impossible is just a problem no-one has spent enough time thinking about.

@James; "I am saying, what if the enterprise didn't have an EA group..." Absolutely.

My view is that it is a misnomer that to adopt EA an enterprise needs a big EA group with a whole new set of processes, people, costs etc. No, EA is an adjustment to what an enterprise is and how it does things. Yes it may need one or maybe two new individuals, but not an entire group – there lies madness. This misconception that a huge separate EA group is required is another one of those pesky risks that needs to be addressed. - See slides 19-24 in http://www.pragmaticea.com/displaydoc.asp?DocName=peaf-comms-ea-why-idont-need-it

@Charles: "EA is the process and product of planning, designing and constructing IT systems that reflect functional, social, and business objectives of the Enterprise. " No it is not. This definition is too narrow. some "solutions" to "business problems" require no IT change at all. Also, (Sorry I don't mean to be rude I am just stating my views) EA is not the process of designing and constructing IT systems, that is for SDLC, RUP, Agile, OO, TOGAF, etc.

@Skip: "regarding EABoK suggestion: Is there a reason, or have you already suggested this to Mark Lane and the CAEAP Group??? All of these discussions on LinkedIn have a good variety of "value snippets", but nothing seems to keep 'focus'."

──────────────────────────

I agree with your word “planning” but not only IT. I know this discussion is for people to table their own definitions (and not to be lambasted for them which I hope I am not

Comments

doing) but this IT centric view of EA (which is most definitely not EA) is the single most divisive and damaging view in the world today and has been so for many years now and therefore I thought I had to say something. It was also because others were agreeing with you. If there were no IT in an organisation there would still be EA (EA products and processes) therefore you cannot define EA just in terms of IT. IT encapsulates IT yes, but it isn't solely IT and its also not low level.

If the organisation does not have problems (it is willing to face up to) then your work is done. It may very well be that silo’d LOB’s are perfectly valid for that company (e.g. maybe their enterprise strategy is to sell the LOB’s off at some point and therefore they want to keep them autonomous…) As I mentioned in a previous discussion, IMHO too much time is wasted on people talking about, discussing, creating solutions. If you spend more time understanding the problem, the solutions are usually self evident. I don't sell myself as someone who can provide solutions. I sell myself as someone who can understand problems.

EA is enterprise wide and its architecture (i.e. structure) the word architecture has no qualifier because it means the architecture (structure) of everything, the business (processes, locations, departments, etc) IT (applications, databases) and the enterprises strategy that drives those two things (mission, goals, objectives, etc)

they are problems that EA would help with and most could)

──────────────────────────

@Marcus: “What is the role of Enterprise Architecture within a Corporate with multiple LOB's having their own Architects and different reporting lines?” EA is a "solution" to a problem.

If you understand the problem enough, the solution will be revealed. ────────────────────────── @Robert: "Are you assuming improved efficiency is always a good idea in a business? If so, you're making a bad assumption."

In order to "sell" any "solution" you first have to get people to admit that there is a problem.

I think you're being a bit too narrow and, dare I say it slightly, naive.

If the management and board do not or will not define a problem (and there are many political reasons why this may be so) then forget "selling" then a "solution"

When we say increased efficiency we (obviously) mean increased efficiency of what the business wants to do. This is whether we agree with what the business wants to do or not.

If the organisation in question has "problems" or "pain points" then if we know what they are it would be very easy to explain where and how and why EA could help (assuming

If the business wants up-selling and customer loyalty then obviously we mean the efficiency of up-selling and keeping customers and not the efficiency of people answering the phones.

This must be your starting point as any other discussions about principles, frameworks, processes, governance, etc, etc, etc is "putting the cart before the horse"

Efficiency is very easy to measure (output / input)

Comments ────────────────────────── @James: "Enterprise Debt in PEAF"

PR Yeps – you’ve generally got it right…

1) Overall EA principles are agreed by the board. These principles are not only technical. 2) EA principles come from two sources, a) "best practice" e.g. think strategically act tactically, Sound Business Cases, buy not build, Service based, etc, etc. These principles apply equally to 99% of all enterprises are provided by PEAF. b) principles specific to that organisation that are born out of understanding their target state e.g. Outsource certain business functions, all processes and systems must be multilingual, etc.

9) The SIB looks at waivers and considers the cost of compliance vs the cost of non compliance and makes a business decision to provide what is needed or not. 10) If the SIB decides not provide what is needed then the waiver is issued and Enterprise Debt has been created. 11) The sum of all outstanding waivers constitutes the total Enterprise Debt. 12) This Enterprise Debt (expressed as waivers) is then managed going forward. Part of the management of this debt is its review in the next annual Business Planning cycle leading to changes and projects that reduce it (assuming the organisation wishes to reduce it) ────────────────────────── @James: "Somehow I don't think the words "enterprise debt" serves us the way we want...."

4) For a project, if all principles are complied with - no problem - no Enterprise Debt is created.

To me it is debt.

3) As projects begin to define solutions to problems they are assessed as complying with these principles or not.

5) For a project, if all 1 or more principles cannot/will not be complied with (e.g. through lack of time, people, money, scope) then a Waiver is produced. 6) The Waiver defines two fundamental things. a) The cost of compliance (i.e. what is needed for that project to comply with the principle). b) The cost of non-compliance (i.e. the issues and risks that non-compliance would introduce and the tasks and mitigating actions that would have to be done to resolve those issues and mitigate those risks. 7) The project board can then (if it is able) provide the project what it needs to comply.

If I were buying a company, I want to know all about its debts. To use another term in stead of debt I think it dilutes it's simplicity and essence. It is a debt. It costs money to service it and it will take money to reduce it. As to using the word "enterprise" in front of it... I agree maybe that's not a good thing as it's too loose. We are talking about the debt caused by short term thinking and practices over longer terms strategic benefit. Essentially the organisation is being raped. (although perhaps in a semi consentory fashion!)

Maybe “Inherent Debt” is a better term. In any case, I don't care. What I do care about is that organisations are aware they are creating it, and therefore are able to manage it.

8) If it cannot/will not then the waiver is escalated to the “Strategic Investment Board” (This board sits above all projects and business areas and has assigned budget to use for strategic purposes.

@Martin: "It seems a lot like risk to me" It's part risk and part fact. When a decision is made (for whatever reason and I do not

Comments

mind why) that creates "Enterprise Debt" two things are created. 1) Issues - things that definitely will happen as a result. These things have a cost. 2) Risks - things that may or may not happen. These things also have a cost (albeit a cost that may or may not materialise) however there is also the cost of mitigating those risks.

These 2 things added together = the Enterprise Debt being created. It is real. It is money. But as you say it is also risk although not necessarily exclusively. Enterprise Debt sits at the centre of PEAF’s EA Governance section. ──────────────────────────

@James " '"future cost of change to meet strategic intent' " Yes - I like that - but that’s not the whole thing. Firstly its not only the cost to meet strategic intent because there is also an element of future strategic intent - e.g. agility - that’s an ongoing thing whereas "future cost of change to meet strategic intent" sounds like its finite. Secondly, there is also an element of remedial work which doesn't necessarily meet strategic intent but again provides the basis for future strategic achievement. In the world of PEAF every project/programme of change should be categorized in terms of the "Enterprise Debt Ratio".

I agree - just because you have a principle (backed up by a rationale) does not mean that the business wants to follow it religiously all the time.

Enterprise Debt Ration is a complimentary concept to Enterprise Debt. Maybe it’s a bad name again, maybe not. We could call it Ermintrude!

The business wants cart blanche to change its mind at a moments notice. And so it should.

What it means is that we recognise that work/change carried out on projects can be categorized as a ratio between :-

The important things about principles is not that they get adhered to. What is important is that when they are not adhered to the implications of not doing so are 1) identified and considered and 2) if compliance is not achieved, the resulting cost of the Debt being created is managed going forward and not hidden.

a) Strategic: A change that takes you directly from where you are to where you want to be, that may or may not also satisfy a short term need.

Can we take this Debt discussion to the new topic though…

c) Remedial: A change previous Interim change.

One of the fundamentals about EA is that is not there to make decisions and it is not there to say NO.

So that one project may be 10 : 50: 60, (i.e. Strategic:10 Interim: 50 Remedial: 60) another may be 0: 100: 0.

@James - "Principles at each level of abstraction are guides and guides are just that...not always followed. "

──────────────────────────

that

corrects

It is there to expose information so that the business can make more informed decisions.

b) Interim: A change that satisfies a short term need, but does not take you from where you are to where you want to be.

So - The full "Enterprise Deb" concept consists of: -

Comments "Enterprise Debt" - A "point in time" measure of the amount of debt that has been built up in the entire enterprise.

"Enterprise Debt Ratio" - An indicator for the current project portfolio indicating the "direction"/health of the current project portfolio in terms of Enterprise Debt. To get scientific, you can think of Enterprise Debt as a point (a value) and Enterprise Debt Ratio as a vector (direction and magnitude) Each of these key measures are useful in them selves but what is more useful is to evaluate these on a month by month basis to see who they change over time. to provide an "acceleration" value. (Differentiation springs to my mind for some reason)

@James: “it never seems to be in complete enough a state that it can answer the specific question a project needs answering at a specific time” Good question James, The answer is very very simple. EA is method, a tool and like any tool if it is used incorrectly that the "tool" will fail. One of the key things people miss when EA modelling (which is only one aspect of EA) is that they need to follow a reasonable process for populating it and using it. The reason for your "architecture" never being complete is 2 fold. #1 Do not think that a bunch of "Architects" in a room are responsible for maintaining the information in the model. The information in an EA model consists of many different types of information - department hierarchies, processes, financials, applications, etc, etc. The information should be owned and maintained by those people who are responsible for it. HR, Finance, Programme Office, Support, Development, Facilities, etc, etc…

Please don't think I understand math though! - I fell apart at college when they started talking about moments of inertia and the lecturer could not give me any example of where moments of inertia apply in the real world!!!!

And in any case, it’s probably not a good idea to talk in such terms as it might make The Board’s ears bleed!

Failure to do this will create a massive bottleneck.

@Doug “Do groups receive more budget or better access to resources if they contribute less than others to the debt?”

#2 Do not populate a model without integrating or removing the data sources where the information came from.

No – it doesn’t work like that.

Failure to do this will result in the information getting out of date meaning when someone wants to use some information they will have to “update” it first and therefore the model never seems correct or up to date because it isn’t.

Any project can “create” enterprise debt at any time. When it happens, exposing it allows the business to use strategic budget (allocated during annual business planning) to reduce enterprise debt where it decides to.

──────────────────────────

How the business decides it totally up to the business to determine by balancing requests from multiple projects and all other factors at their disposal – knowledge of market forces….etc etc. ──────────────────────────

@ James: "It seems that the "remedial" work is a risk reduction activity" It could be risk reduction but it could also be issue resolution. If something that was originally done as a short term fix was

Comments The PEAF principles are not vague. There are defined, and supported by rationale, implications and metrics.

Essentially any non compliance with a principle could result in issues (things we definitely know will happen and we can estimate the remedial work to deal with the issues and/or, risks - things that may or may not happen that have high/low/medium impact and high/low/medium likelihood of occurring. For risks, in addition there may be risk mitigation actions arising which should have some concrete cost.

@Richard: "but would this kind of compliance make any significant reduction to the quantity of enterprise debt"

identified as a problem or becomes a problem, the remedial work may be to remove and replace it. So we aren't reducing risk then so much as dealing with an issue. It may have originally been a risk that then over time turned into an issue.

──────────────────────────

Yes. The point about principles and Enterprise Dent is that in 99.9 % of enterprises and on 99.9% of projects there comes a time where one person will say one thing should happen (based on the principles that the enterprise has adopted or if they don't have principles, based on reasonable long term thinking) usually this person is the architect, and another person will say no because .... we don’t have the time, its out of scope, we don’t have the money - usually the project manager.

@Zahid: "Our first goal is to become a truly excellent organisation. Then our next goal is to maintain that position. Not just for our Customers, but also for our workers - for everybody. Some form of EA is something that you will NEED to do - start, maintain, and get good at...IF (and that's a big "if") that's where you want to be"

http://www.pragmaticea.com/peaf3governance.htm

Allow me to play devils advocate. Imagine I am the CEO.....

"We are already a truly excellent organisation and to infer that we are not I find insulting to the company generally, to me personally and to the hundreds of excellent people that work here...There's no way I'm going to let you stand up and talk to a lot of senior people in this company if that’s what you think. I have built this company up to what it is today and I don't need someone telling me what to do. Last year we made a profit of $100M. When you've run a company and made $100M come back and talk to me ".

@Richard: " am uncomfortable about basing the calculation of enterprise debt on something as vague as "principles"

Getting the business to agree to, sign up to and understand the implications of the principles they want to operate is the first step. Then having a defined process for identifying when the principles are being not adhered to, the "cost" of compliance vs the "cost" of non compliance escalated to a strategic board that has budget it can bring to bear allows informed strategic decision making by the business, rather than a project manager or project board that does not (quite rightly) have strategic focus. ────────────────────────── @Richard: "...principles may be useful for identifying various kinds of enterprise risk, but surely we then need to assess and quantify the risks in their own right, rather than merely trying to count how many principles we have managed to comply with. "

──────────────────────────

in 99.9% of enterprises the project manager "wins", he looks successful and the debt that has been created is now hidden.

Comments Firstly - no one ever said that all we were going to do was count how many principles we have managed to comply with.

If a principle cannot/will not be complied with, then: 1) the potential enterprise debt that would be created is quantified. This is done by detailing the issues (things that definitely will happen) and the risks (things that may happen) and the tasks and costs associated with those issues and risks. 2) the costs/requirements if the principles is to be complied with. This can be time, money, scope, etc.

the table but to get the ear of the CEO money is always a good route. Calling a debt a liability because it's semantically better etc etc is not helping the cause. I know you are right but I try to balance correctness vs use and understanding. I am aware of boundary games - the internet has allowed an awful lot of that, the most prevalent is by getting customers to do the work of previously employed people (costs) maintaining their address details, asking for statements etc etc. @Pat: “Jumping in late here...my apologies.”

Both of these are very easy to do for the people on the project in question.

Don’t worry – wade in – the more the merrier.

The project board then tries to comply (for that is part of their remit) if it cannot because it does not have access to the money, time, responsibility to increase scope, etc then the cost of compliance and the cost of non compliance is escalated to the SIB which does have budget and responsibility to decide if the enterprise wishes to incur the costs of complying or the costs of not complying.

@Pat: “I see EA as a map of the terrain”

Part of EA is the EA model. and yes it’s a bit like a map but also includes all the important buildings, roads, gas mains, lay lines, etc.

────────────────────────── @Tom: "liability vs debt"

I know the world is a complex and grey space but sometimes its best to simplify and make things black and white for people. Rather than being 100% correct in terms of language and semantics I think understanding is more important.

We are off the topic of Enterprise Debt here so I’ll keep it brief… The map is maintained by the people who own the information. It is their information after all. The finance people are responsible for the finance information in the model, HR are responsible for the departmental structure information, the LOB’s are responsible for the business processes they operate, IT is responsible for the applications and database information, projects and programmes are responsible for the portfolio information, the board and executive team are responsible for the enterprise strategy information, etc, etc.

Debt very clearly = Money. I know some organisations and governments especially are not in it for the profit but they still do need to be effective, efficient, and agile (adding in longevity to all those) and at the end of the day it's mostly money that talks.

@Pat: “So, who pays to have the map updated?”

Yes, yes I know that brand, customer satisfaction and other intagiables are also on

Each contributes something. Each can see, not only the things they contributed, but also more importantly other things they are not responsible for but are related to the things they are responsible for.

Comments

──────────────────────────

@Richard: " The first is that each project may argue that it is thinking strategically; architects disagree; and we just have a difference of opinion generating more heat than light." No – Firstly the non compliance is recorded, exposed. Secondly, the decision gets escalated to the SIB which has strategic budget it can bring to bear.

@Richard: " The second difficulty is that it is not the responsibility of individual projects to maximize organizational benefit. Surely it's the job of architects to assign different benefits to different projects, rather than having each project trying to do as much as possible. If an individual project attempts to maximize organizational benefit, it will probably fail.”

especially in the post credit crisis world – I think everyone on the planet understands that debt = money. Of course I don’t say that all debt is moneym but it is a compelling argument for enterprises where money is all that matters (despite the rhetoric of serving the customer better – do call centres in deprived areas serve the customer better? do closing branch offices server the customer better?) Call it debt. Call it liability. Call it Mabel and paint a face on it. The question is do you understand it? I think you do. @Richard: “To how many CEOs have you presented the concept of enterprise debt?” 2. How many have you presented on the concept of enterprise liability?

I take you point but strategic benefit does not only come from the top. Many times (too many to remember) project level people identify things that could bring strategic benefit. This should be defined and escalated to those that make decisions. I.E. The business. @Richard: " The third difficulty, which I think links to Tom's comment, is the fact that what counts as "maximum benefit to the organization as a whole" is highly problematic. Who is calculating the benefit to the organization - the CFO? " No – not just the CFO but he’s in there. The point is that the decision is moved from the siloed ranks of a project into a strategic forum where the business can decide.

Ask 100 people what debt means and they are likely to tell you that it means they owe money.

@Richard: “How many organizations are actually following the procedure you have described here”

Since it’s very new – not many. But so what. These questions sound like challenges. The number of people I have presented to and the number of people who believe what I say is irrelevant to the correctness or value of what I am saying. I get the feeling that you would have been part of the crowd baying for Galileo’s blood after hearing his ideas that the earth orbits the sun. Don’t criticise something for being new. ──────────────────────────

@Andrew: “Scenario #1: Given that management decisions typically involve a many unknowns, using one set of assumptions a decision may be considered dodgy/tactical when it is made and thus incurs a debt. However after six months it turns out to be a masterstroke and saves a

@Richard: “You justify the use of the word "debt" by stating that ‘Debt very clearly = Money’. I don't think it's clear at all. You are using a metaphor of money, it's not real debt.”

Shall we see who has the biggest willy!?

Comments lot of wasted investment. Does this debt become a credit?”

No – but the debt is removed.

Think of it in terms of buying a car. You buy a 2004 BMW M3 with 20k miles on the clock for $10,000. Sounds like a great deal – but did you take into account the hidden enterprise debt? After you buy it, you find that you need to replace all the tyres ($$$$) and that it wasn’t serviced last year ($$$$) the service finds that brakes discs are badly scored ($$$$). Maybe you should have found out about the enterprise debt before you bought the car.

Again, a lot of highly paid people are going to be annoyed. But they will go eventually, replaced by people who can make them selves successful because their company is truly success in the long term not just today. Maybe linking bonus payments to future company returns linked with paying those bonuses as pension contributions would be a good idea……you know…..screw up the future of this company and you also screw up your own future……. ────────────────────────── @Zahid: “Here would be response to you the CEO: “

direct

Again with my CEO hat on… (Thinks – if this guy tries to get any farther up my ass he’s going to be wearing my toupe!) Look – we’ve been very successful for the last 30 years without EA so I don’t see why I need it now

Alternatively you buy the same car, but knowing that the tyres need replacing, you budget $1,200 to replace the tyres and offer $8,200. When you take the car in to replace the types you find that they are on special offer if you but 4 all at once for $800.

You haven’t made a credit as such but the debt you thought existed was reduced.

@Andrew: “Scenario#2: The CxO decides to to improve his bonuses by removing knowledgeable and experienced staff involved in EA. The impact of this decision will only be realised in the longer term when he no longer plans to be in the company. Will the CxO want this decision to be honestly evaluated and its enterprise debt costed?”

No – that’s one of the main cultural problems with EA. EA can expose things that some people may not want exposed.

Yes they do!

@Zahid: “Obviously, he thinks I am from "IT" or some other dungeon. Well, first task is to win him over, and then his circle. I will have to rely very heavily on engagement here and influence him - the "client account" interaction model is a useful tool here, as is NLP.” Hmmm – if you see his ears bleeding you should stop talking! @Zahid: “However, I will have to pay attention to how I am perceived, and perhaps my only shot will be to boldy ask to give a 15min presentation”

The parallel with the credit crisis is that it occurred because peoples bonuses were paid on this years results not next years. Thus massive “enterprise debt” was built up to the point where it reached critical mass and the entire system imploded.

@Zahid: “My private thoughts about you the CEO: ALARM BELLS: This CEO has defo got his riot shield up (truth is that any credible CEO don't become a CEO and have a leadership vision like that! He's lying).

This is why governments are taking steps to change bonus structures so that bonuses are paid not only on today’s profits but on tomorrows too.

Any mention of a presentation, and you’ve lost him. If you have to use PowerPoint he’s thinking about his golf handicap before you

Comments

even managed to launch the app - especially on Vista ;-)

@Zahid: “As I am sure you'll agree Kevin, like we've demonstrated, winning over hearts & minds to EA is the first step...and that truly will be different from organisation to organisation. It may seem impossible, but this is where the EA will need to exercise skill in persuasion and influence...in short an EA in this type of situation needs to have thought leadership, gravitas, and the acumen and awareness of how to politically maneouvre along the nodes of influence. Now that is my kind of challenge!” Absolutely and that is why I say Communication is the key to EA. IF you’re not spending 80% of your time communicating you will fail. ──────────────────────────

Yes - but only when the term is being misused.

IT Architecture is a part of what an EA model contains but EA is more encompassing and includes everything else in the enterprise that is not IT. e.g. people, processes, departments, buildings, suppliers, customers, motivation models, etc, etc, etc. An EA model is also only part of the wider EA perspective. So, EA = EA Processes + EA Products

===========

EA Operate Phase = Strategic Planning + Modelling the Current State + Performing Governance EA Products ========== EA Products = EA Foundation Products + EA Culture Products + EA Model Products + EA Governance Products EA Foundation Products = EA Vision + EA Maturity + EA Risks + EA Metrics EA Culture Products = EA Communication + EA People EA Model Products = EA Metamodel + EA Tool

@Tru: "to designate IT architecture for enterprise "

EA Processes

the Metamodel + EA Tool Evaluation & Selection + Set up EA Governance + Mitigate the EA Risks

EA Prepare Phase = Gain Agreement to adopt EA EA Implement Phase = Provide Education + Change Motivation Model + Create/Update

──────────────────────────

@Ian:

I agree generally with most of what you say but this word "design" I think is not good.

In the same way as people think of IT when they hear the word architecture, so many people I believe will think of IT when they hear the word design. I know the word design has many uses but anything that even smells of IT at 100 yards is not good. Let's take another tack......all enterprises/companies/organisation's have a balance sheet right? On one side there are ???? assets? on the other side there are ??? Liabilities? lets use the terminology of the CFO?

EA Processes = EA Prepare Phase + EA Implement Phase + EA Operate Phase

EA Governance Products = EA Principles + EA Waivers

What would an organisation call all of their liabilities added up? Not Enterprise Debt - so what would they use as the collective term?

Comments ….. ──────────────────────────

@Zahid: “1. Whether a company does or does not do EA is not the issue, the value & results it delivers IS” Of course But that’s the same thing as saying “whether a company utilise SCRUM or MSP or PRINCE2 or SixSigma is not the issue, the value and results they deliver are.” I’m not sure it helps. @Zahid: “2. The definition of what EA is is one thing, but embedding it into the culture of the org is something else”

Absolutely –EA is a cultural adjustment as as such is why it’s so difficult. A lot of it comes down to communication.

1) An IT centric view of the enterprise is perfectly valid but it is only one possible view. People who are interested in only that view (IT) have misinterpreted the term to mean only their view. 2) EA has the word “Architecture” in it. And since for the last 30 years 90% of the use of that word has been in IT (Application Architecture, Solution Architecture, Technical Architecture, Data Architecture, Infrastructure Architecture) many people immediately think IT when they see the word next to the word “Enterprise” 3) There is, logically, an IT term “Enterprise Architecture” that is used to mean Enterprise “Class” Architecture – I’e’ large, mission critical, multi-location. 4) Large numbers of people talking about EA only because they have heard other people talking about it rather than intrinsically understanding it.

@Zahid: “3. Is EA relevant to any one organisation? - most certainly. But is the culture that exists conducive to adopting EA in ways that have been described? I believe the actual practice of EA in an orgainisation will need to fit with the current culture, or else culture change will be required”

Absolutely – see above.

@Zahid: “4. It is possible for an organisation to progress perfectly well without a TOGAF style implementation of EA - because "good performance" is already part of the culture possibly informal or a non-TOGAF style implementation exists”

Absolutely. (putting aside the fact that TOGAF is not an EA framework) Frameworks are guides. Using them does not guarantee success, . Not using them does not guarantee failure.

──────────────────────────

I think we have to be careful not to say principles in general are bad as opposed to saying that certain sets of principles are bad. And don’t worry I have no problem with the word bad. I don't think anyone would argue that having principles is a bad idea so long as those principles are correctly defined and have a good chance of achieving what they set out to do.

@Zahid: “5. So why does an IT-centric view of EA exist? Because there is a demand for it - right or wrong (I believe it's actually atrocious). ”

5) TOGAF and associated accreditation. Many people and many organisation have used TOGAF as an EA badge. But more and more people are now beginning to see that the king has no clothes on!

I believe it is for various reasons all coming together

When I set out to write a set of principles, I also saw a mass of rhetoric out there and vague statements. This is why I created the PEAF principles with structure; Rationale (Why does the principle exists? What is the “pain” it is trying to alleviate?), Implications

Comments

(What will it mean to the organisation), Metrics (How can we measure the effects of the principle) and Tasks (What tasks are required to implement the changes necessary to operate that principle.

So - since I am always wanting to apply things and move forward in concrete ways (be pragmatic you might say), rather than just have esoteric discussions (which I also like but only while I have a supply of alcohol in one hand and a supply of carbohydrates in the other)I would love to have you and Paul go through the PEAF principles and tell me where you think they fall short or how they should change to be more useful.

This is not a challenge but a real invitation to make some existing "principles" true principles. So they can be used as a standard bearer to others if they want to define principles correctly.

Personally I'd like to have a chat with Mr Clinger or Mr Cohen (If your reading this guys!) I know its IT biased, but I think if all private, listed and federal government departs had to evaluate and disclose there Enterprise Debt, it would make a massive difference. One thing on my list this year is to poll all 700+ PEAF licenses to find out how they are using (or not) it. And also what parts they find compelling or not. ────────────────────────── I guess it's time I posted my description of the purpose of EA, so here it is as defined in v2 of PEAF. The description has been structured in a way to allow different levels of description. So.... The purpose of EA is to... The Level 0 Description.

You can mail Kevin@PragmaticEA.com

==================

──────────────────────────

@Doug: "I am interested in whether your clients are tying this into their overall accounting scheme? In that world there are assets, liabilities, and owner's equity, and assets are offset by the sum of the other two to achieve balance in the balance sheet. Do you follow through with this sort of doubleentry bookkeeping? Is enterprise debt as you know it actually one of the categories of liability, in this accounting sense? " This is a new concept.

The Level 1 Description.

==================

Increase the Effectiveness, Efficiency, Agility & Durability of the Enterprise by supporting the management of the Cost, Risk, Agility & Quality of Change The Level 2 Description.

==================

all it with easy, be a

The problem, of course, is getting the message out there. It will happen. It will be adopted. It's just a question of time.

It's very simple. It's very easy. But if took was someone to come up something that's useful, simple and every inventor in the world would billionaire.

Increase the Effectiveness, Efficiency, Agility & Durability of the Enterprise.

The Level 4 Description.

==================

Comments

Increase the Effectiveness, Efficiency, Agility & Durability of the Enterprise by supporting the management of the Cost, Risk, Agility & Quality of Change by Using Structural Models to aid Strategic Planning, Performing EA Governance to manage alignment to the Strategic Plan and Managing Enterprise Debt to balance short term tactics against long term strategic aims., Or,

Put another way, a conversion with the CEO may go something like this… CEO: What’s the purpose of Enterprise Architecture? ADVISOR: To increase the Effectiveness, Efficiency, Agility & Durability of the Enterprise.

affect the target state design and Total Cost of Ownership.” Hmm. Very interesting. I see where you are coming from now, and I think we are both correct... EA is about strategic planning. ITIL and service management is all about operations. (Of course they have to be designed and built too) I agree that service levels should be based on criticality to the business and that and TCO could be seriously affected by that. I see the definition of business services and the assignment of those services to different service levels (along with a definition of those service levels including cost) as part of the information you would model in an EA model (note that an EA model is only one part of EA) and therefore I can see why you say ITIL is part of EA. You can see this echoed in the PEAF Metamodel (http://www.pragmaticea.com/displaydoc.asp?DocName=peaf-model-metamodel) on page 7 which defines and entity called a service and an attribute of that entity is Tier - ” The service tier the services sits in e.g. Tier 0=B2B/B2C, 1=Business Critical, 2=Business Significant, 3=Business Support, 4=Business Management”

CEO: How?

ADVISOR: By supporting the management of the Cost, Risk, Agility & Quality of Change CEO: How?

By Using Structural Models, Performing EA Governance and Managing Enterprise Debt. CEO: Why?

ADVISOR: To aid Strategic Planning, manage alignment to the Strategic Plan and balance short term tactics against long term strategic aims. CEO: Wow it’s really simple to understand isn’t it ADVISOR: Yep!

──────────────────────────

So, I see Enterprise Architecture and Service Management as two separate entities but they do have an interface. This interface is not a straight line though. I.e. Instead of drawing two boxes butted up to each other, one labelled "Enterprise Architecture" and one labelled "Service Management" I see those "boxes" as jigsaw pieces. Each having a defined domain but with some overlap.

@Darin: “When executing Business Process Re-design or simply implementing a new technology for an existing process (which would probably cause some BPR), the process should have a service level based on it’s criticality to the business. This then will

Since ITIL is a service management framework we can't talk in terms of ITIL and EA we have to talk in terms of Service Management and Enterprise Architecture. (We could talk in terms of ITIL and PEAF)

──────────────────────────

Comments

@Richard: "I have already expressed my preference for the word "liability". James has said it very well. "

PR Yep - sorry I missed that. So your vote would be for Enterprise Liability. (EL)

@Richard: "I happen to think that pragmatic CEOs will find this more persuasive if calculation of enterprise liability is grounded on the structural risks to the enterprise strategy, rather than dependent on conformance to a set of theoretical principles. "

Me: Using Structural Models, Performing EA Governance and Managing Enterprise Debt. CEO: Why? Me: To aid Strategic Planning, manage alignment to the Strategic Plan and to balance Tactics against Strategy. CEO: Why? Me: To increase the Effectiveness, Efficiency, Agility and Durability of the enterprise. ──────────────────────────

OK - I have no problem with that - so let's try to work that through a little....

@Mark: "Enteprise Architect.....Solution Architect....Technical Architect...."

I have proposed that principles are forged from the enterprise strategy, and that EL is then calculated on whether those principles are being followed or not.

@Tom: "technical architects ....work at project level, within a single specialist domain.....Solution architects ...work at a programme or portfolio level....Enterprise architects ....work across _all_ portfolios and programmes in _all_ domains"

How would you "grounded [the calculation of EL] on the structural risks to the enterprise strategy, rather than dependent ....principles"? ────────────────────────── CHALLENGE:

What is your 30 second elevator exchange with the CEO to explain the purpose of Enterprise Architecture in a way that will make him/her ask to have a meeting with you to discuss further. Here is mine as a reference...

CEO: What is the purpose of Enterprise Architecture

Me: To increase the Effectiveness, Efficiency, Agility and Durability of the enterprise.

Me: By supporting the Management of the Cost, Risk, Agility and Quality of Change. CEO: How?

with

both

Have a look at page 17 of http://www.pragmaticea.com/docs/v2/peafoverview.pdf and let me know what you think. Page 18 provides more detail....... ──────────────────────────

Everyone, thanks for all the submissions – it’s taking my brain in very interesting directions… Serge has kindly agreed to mark it as a featured discussion to keep it at the top of the list and so hopefully get more people involved – Thanks Serge.

@Ian: “design debt”

I understand your journey to those words but I still find that this “design” word really sticks in my throat.

CEO: How?

I think I would agree complimentary defintions.

@Ian: "…..to be made good at some time in the future.” and “…..the promise to repay” Both are assuming the debt will be paid off.

Comments

This is not necessarily the case in my experience (not that people equate their decision to debt as yet because the concept is new). In my experience, organisations take on this “debt” that we are discussing with no intent to pay it back at all. (Implicitly or explicitly). This might sound mind blowing but…in my book this constitutes either deception, theft or fraud or all three!

It sounds like a joke – but it’s not. I am deadly serious. But back to the naming thing…. how about "Strategic Debt" ????? ──────────────────────────

@MARK: “effective communications.”

make a bank a more effective, efficient, agile, durable bank. Essentially we are trying to “sell” something that is not missed. It occurs to me that things like EA and improving communications is something you do to either to steal a lead over your competitors or (if they have already stolen lead against you) to play catch up. It’s potentially more to do with the general maturity of the organisations and the sector they exist in. e.g. initially companies tend not to care too much about efficiency, agility or durability…it’s all about effectiveness, sell sell sell. But as they and their market matures they have the time to think more about their future they start to consolidate, improve and think a bit more about tomorrow. That’s when efficiency kicks in and organisations try to drive out as much efficiency as they can.

I think you have a massive point there.

I believe that communication is the key to any relationships and especially marriage, and a marriage is just like the arranged marriage between the different groups with an organisation (business to business as well as business to IT).

I also think that organisations that try to help people with (communication) is as a difficult "sell" as what EA's try to "sell". On the face of it both are just so gobsmackingly obvious it's strange that know one "buys" them. I think the problem with both is that all organisations can get along reasonably well without “paying” to do either.

We don’t say EA is all about agility though (because it also has to balance effectiveness, efficiency and durability also) but agility is probably the thing that will drive the use and adoption of EA. So, maybe a pertinent question is How do you sell something that solves a problem, to someone who doesn’t know they have the problem or doesn’t see it as a problem?

If you don’t improve communications, and if you don’t adopt enterprise architecture – the organisation will not die, it will still make money, people will still make bonuses, customers will still get serviced.

I think that is where most organisations are in the world today, Some have begun to think a bit more about durability and have begun to make inroads into that area, but the vast majority have not even thought about tackling agility – and in today’s faced paced world agility can (and will even more so in the future) really bring massive rewards.

EA and improving communications does not make a bank, a bank. it can only HELP to

────────────────────────── @ASHLEY @FRED

Comments

Agreed change (being able to and being able to adapt to) is important, therefore agility is important.

EFFICIENCY

DURABILITY

Apologies for cross posting but I just posted this on the 30 seconds with the CEO challenge...

It occurs to me that things like EA and improving communications is something you do to either to steal a lead over your competitors or (if they have already stolen lead against you) to play catch up.

then AGILITY So, maybe a pertinent question is… How do you sell something that solves a problem, to someone who doesn’t know they have the problem or doesn’t see it as a problem? ────────────────────────── I know its a bit off topic but I couldn't resist...... On the subject on TOGAF and whether it is or is not an EA framework (I happen to think it's not) I noticed a tool vendor release which was titled "TO GAF or not to gaf"

It’s potentially more to do with the general maturity of the organisations and the sector they exist in. e.g. initially companies tend not to care too much about EFFICIENCY, AGILITY or DURABILITY…it’s all about EFFECTIVENESS, sell sell sell. But as they and their market matures they have the time to think more about their future they start to consolidate, improve and think a bit more about tomorrow. That’s when EFFICIENCY kicks in and organisations try to drive out as much EFFICIENCY as they can.

then

I think that is where most organisations are in the world today, Some have begun to think a bit more about DURABILITY and have begun to make inroads into that area, but the vast majority have not even thought about tackling AGILITY – and in today’s faced paced world agility can (and will even more so in the future) really bring massive rewards. We don’t say EA is all about AGILITY though (because it also has to balance EFFECTIVENESS, EFFICIENCY and DURABILITY also) but AGILITY is probably the thing that will drive the use and adoption of EA.

EFFECTIVENESS then

So the next time someone asks me about my opinion on using TOGAF for EA, I shall reply

To use TOGAF for EA is TO GAF! Petty and juvenile I know, but it just tickled me – synchronicity. ──────────────────────────

@ZAHID: "Have we a consensus on what is the PURPOSE of EA?" Err no!

It seems like as organisations increase in age and maturity their focus needs to change – the other things are not ignored but the focus changes…

I have long felt that "EA" organisations that still push TOGAF as an EA framework are putting their foot in their mouth a little because it sends out the wrong signals. They are effectively making a gaff (English colloquium meaning to make a mistake.

But I do think the discussion has alerted some understanding and that more people are starting to march to the same tune.

@ZAHID: "To enable stakeholders in question to achieve the enterprise purpose,

Comments from its current state, in the most effective and cost-efficient way" "

Yep that’s a good one. But don't forget agility and durability... @SEAN: " EA's core purpose is to reduce cost and increase quality by being better prepared and better organised" Yep that’s a good one. But don't forget agility and durability... @SEAN: "but mostly it's about reducing cost." Yep that’s a good one. But don't forget effectiveness, agility and durability...

There are four plates that EA helps to keep spinning... EFFECTIVENESS EFFICIENCY

DURABILITY AGILITY

@RODERICK: "I look forward to the time when we realize that frameworks for EA implementation are not about standardization but about styles. " I respect your views, but in a world where no one can even agree on the purpose of EA, I believe we need a simple, pragmatic EA framework to guide people towards a common understanding. Of course I am not saying that any framework will solve all your problems, but frameworks are a useful starting point and context. If everyone one knew what to do and how to do it we wouldn't need frameworks. MSP, SIX-SIGMA, PRINCE2, LEAN, etc etc are all frameworks. For people who know what to do and how to do it, they don't need these frameworks. The same is true for EA.

That’s one of the major problems organisations have. They concentrate on cost largely to the exclusion of agility and durability and then they complain later on that "why does it cost so much and take so long to change things" or "Why do we need to replace that process/system again, we only replaced it last year"

Concentrate too much on one, and the others will slow down and begin to crash to the floor.

When a plate hits the floor is usually when a director hits the road….

That is why I created PEAF – it’s a reasonable stake in the ground at a "proper", "usable", "complete", “understandable” pragmatic framework to a) help people understand and agree on EA and how to “do it” and b) to provide them with as much collateral as it can to allow them to “do it”. v1.1 was a good step, v2 to be release in 3 weeks is a big step forward. I don’t want to force people to use PEAF. I am an EA and therefore all I do is to expose the truth and pertinent information to people so they can make informed choices.

@MARTIN’s BOSS “"to translate business vision into effective change."”

The problem, I humbly believed that there is no "proper", "usable", "complete", “understandable” EA framework out there and that is one reason why so many people and organisations are so confused.

I like it. I like your boss. I think I’d like to work for a guy like that. ──────────────────────────

Please have a look at the diagrams on pages 6 to 9 of this document http://www.pragmaticea.com/docs/v2/peafoverview.pdf

Comments talk about CHANGE then it will not have a place for EA. "

Strategic vs Project Level

Correct, that’s why PEAF defines the mission of EA is to...

It illustrates a comparison between some “EA” frameworks in terms of: -

===================

This is an indication of how much the framework is focussed on Strategic Planning compared to Project Level work. Organisation vs IT

==============

This is an indication of how much the framework is focussed on the entire organisation compared to only IT. Coverage

=======

Complexity =========

Check out pages 10 to 22 of http://www.pragmaticea.com/docs/v2/peafoverview.pdf @FRED: "Another key role of Enterprise Architect is to educate people about CHANGE. " I absolutely agree. That's one of the reasons I created PEAF and the training courses and certification that goes with them. ──────────────────────────

This is an indication of how complete the framework is based on the features you would expect to find in a framework (i.e. Maturity Model, Metrics, Presentations Materials, Metamodel, Tool Evaluations, Principles, Governance, Processes and ready to use Templates.

"To increase the Effectiveness, Efficiency, Agility and Durability of the enterprise, by supporting the Management of the Cost, Risk, Agility and Quality of CHANGE"

This is an indication of how complex and large the framework is and therefore how difficult it is to come to terms with understanding it and using it. ──────────────────────────

@FRED: "I don't think EA framework can be standardized."

Do you also think project management cannot be standardised into frameworks?

@FRED: “CHANGE...CHANGE...CHANGE...CHANG E...CHANGE... If an organization does not

If you think what PEAF states is incorrect please let me know. @FRED: "and focus on what we have started " "We" didn't start anything. I did. But I am exceeding grateful for all those that have taken part. I think those people have advanced understanding with their positive comments. @FRED: "Is someone doing any analysis of the submission so far? Let someone put forward a summarized statement and we can all try to refine it. " Yes - that has been done already - you may have missed my post some pages back where I posted the results of a simple analysis http://www.pragmaticea.com/160challenge.as p

Becuase it has, its called PRINCE2.

@FRED: "I just wish Kevin will stop promoting PEAF"

──────────────────────────

Comments

@FRED: "I am just saying if you want to promote PEAF then you should start a new discussion. I thought we are trying to define the meaning of Enterprise Architecture HERE. " Absolutely, so go ahead and stop bring up the subject of PEAF. @GREGORY: "I really appreciate this and have a top 10 for what this has shown and taught me: " Excellent. And don't be afraid to criticise me or others too. I only learn and grow through people telling me when I am going wrong. That’s why my views, I believe are possibly useful. They have grown out of failure – understanding it, rather than out of invented suceess.

@IAN: "Any experienced project manager will tell you that just following PRINCE2 won't get you a successful project. " Exactly. And I say exactly this in the presentation "EA - Why I Don't Need It !" http://www.pragmaticea.com/displaydoc.asp?DocName=peaf-comms-ea-why-idont-need-it Slides 14 - 16. IAN: "It gets people started on doing roughly the right thing practically - by telling them, from the framework's perspective, what to do. " 100% Agree. When I looked for that - it didn't exist. TOGAF was IT Architecture and Zachman is just a Metamodel. So I created PEAF for just the purpose you describe. To get people doing the right things - practically – pragmatically – for free. ──────────────────────────

Sometimes people are mistaken or misunderstand and I point it out. However, that to me is boring. I look for those glimmers of gold in the rock - that take me into new ways of thinking about things.

I like your top 10. They are very good points I think even if I/we discount #9. I am humbled by your comments.

──────────────────────────

@KIRK: "But an EA is a "deep generalist", knowing, at least conceptually, a great deal about everything. An EA may not be able to actually perform any one of the things they understand, from a concrete perspective, but knows how they are supposed to work and how they are supposed to interact with everything else." You have a way with words sir, that doth make a young girl giddy with anticipation!

Agreed. No one ever should say that EA or an EA makes decisions. They facilitate and provide information for the CEO or whoever he/she devolves power to, to make decisions. He/She may devolve power to an EA but seriously I don’t believe any organisation needs to employ an EA – apart from helping them adopt it in the first place. ────────────────────────── @NICK:

Good points but It's made me realise I didn't couch the challenge correctly. The context for the challenge is: -

Seriously though, you know what I'm going to say....here, here. Agree 100%

@CHARLES: "One thing's for sure: unless something's _seriously_ wrong with the business, the 'Captain' role should be taken by the CEO - not the EA" Agreed.

──────────────────────────

1) You don't organisation.

already

work

the

Comments

2) There are no EA people processes or products at that organisation or if there are, they are not “real” EA i.e. it’s all in IT.

PR So the challenge is not to justify keeping EA's on or continue "doing" EA.

The challenge is to make the CEO interested enough that he wants to hear more. Kind of “How does EA get it’s foot in the door”

because organisations that adopt what I do, don’t want to sing it from the tree tops for fear of their competitors finding out and them losing the massive competitive advantage it creates. <4th floor > CEO: Really. Sounds like a lot of mumbo jumbo to me. Snake oil.

I also realised that my original response to my own challenge is not good. So here’s my second attempt….

Me: Yep – And that’s exactly what the people I work for want their competitors to believe.

=============================== ========

<5th floor>

Me: Hi, how are you doing today? CEO: Fine thanks. And you?

Me: Anyway, nice to talk to you. Goodbye. =============================== ======== ──────────────────────────

Cheese!!!!

CEO: Yes.

Now you're talking.

Me: Fine too thanks. It’s been really cold this last month hasn’t it? It’s amazing how people go on about global warming and we end up having the coldest winter for years!

Me: Do you work her?

CEO: Yes I’m the CEO of <A company> <1st floor>

Me: Wow! Really? That must be a really tough job right? CEO: Yes. It has it’s moments <wry smile> <2nd floor)

Me: Yeah I know what you mean. There’s good and bad in everything I guess. CEO: Yes.

Me: Take my job – It’s good because what I do can have massive positive effect on an organisations bottom line, but on the downside, it’s very difficult to publicise

There's nothing that gets a CEO's juices flowing more easily that the promise of a piece of Wensleydale or particularly mature Cheddar! Throw in some grapes and a vintage port and he’ll let you lick his model! ────────────────────────── @KIRK: "And Zachman never intended EA to be enterprise IS architecture. Here is a quote from a recent email from John.......CLEARLY, it NEVER meant "IT Architecture" or "Hardware and Systems Software" or anything technology oriented. "

<3rd floor>

@ASHOK: “I can demystify EA and help you cut to the cheese quickly.”

I am a bit confused why he would say this as the bottom 2 or three rows are clearly 90% IT oriented????

Comments In fact the 4th row is titled "TECHNOLOGY MODEL (PHYSICAL)" and the 5th row includes "Network Architecture" etc, etc

I am totally open to being educated here so if I misinterpret the Zachman model somebody better tell me quick?!!!!! Otherwise I'd like to understand why Zachman says his model which includes technology architecture has nothing to do with technology??? ──────────────────────────

OK - I'm open to changing my opinion always am - but my opinion changes because of understanding and asking questions. So, if the Zachman framework is "The underlying Zachman framework is generic: it's a taxonomy of primitive components that apply at different levels of abstraction"

So, where is the Zachman framework described? documented? drawn? If Zachman never intended his framework to be IT centric then where is his more abstracted framework defined? @KIRK: "Systems existed before IT" Yes of course. So, where is the Zachman framework described? documented? drawn? If Zachman never intended his framework to be IT centric then where is hs more abstracted framework defined? @KIRK: "Get rid of everyone in your company EXCEPT the IT staff. What does your production output look like??" Absolutely, IT is the key to the "How" of organisations today. And this is what makes IT a special case, not because its IT but because so many parts of the organisation depends on it to satisfy the “How”.

If this

http://apps.adcom.uci.edu/EnterpriseArch/Za chman/zachman.jpg is not the Zachman framework, where is the Zachman framework described.

I accept that the columns are abstract, there are in the above "example" so where are the rows defined is not in that diagram? ──────────────────────────

@RICHARD: "the sheer size of this discussion seems to indicate that the EA community is not collectively capable of agreeing a short and succinct purpose for EA. " Yes. Sad isn't it. But sadder for the organisations that could benefit from it and won't :-(

This is why the relationship between IT and the rest of the organisation is so important. In a lot of organisations IT does support the business but to such a degree that how they use IT (compared to their competitors) is absolutely crucial to their success and continued existence. ────────────────────────── MATTHEW: “To facilitate the integration of IT architecture strategy, planning & execution into the business model strategy, planning & execution.” It's a good start but as Kirk points out in the discussion it's too IT centric.

EA is all about getting all business units of the organisations and all players in the wider enterprise to be integrated.

Yep.

Because of it's pervasiveness IT is a big part of it but it's only a part. IT is also only apart at all levels above the project level (although

@TOM: "what's shown there is hopelessly IT-centric, and a very narrow subset of IT at that."

Comments

the governance piece obviously goes down to project level) - I.E. It's 90% Strategic planning and 10% project level.

PR ──────────────────────────

@TOM: "Probably _the_ core problem in enterprise-architecture today is that IT is made out to be 'special and different', the necessary centre of everything. It's not, and you _know_ this too - you've said so yourself in our face-to-face conversations. So please don't make that problem any worse! " Hang on!

Let's separate the two things I am saying because I think you probably agree with the first but not the second. I make two statements.

────────────────────────── @TOM: "it is essential to understand that in enterprise-architecture, nothing, and no one domain, is ever 'the centre'. " Agreed. That is exactly what I said. But all the parts of the enterprise deserve special understanding. It is only by understanding their differences and what makes them "special" can we understand how to make them work better together. None is more “special” than the rest, but they are nevertheless or all special in their own ways. I offered a reason why IT is special. Because it is.

#1. All organisations are made of various parts, departments, business units, whatever we call them. Some are going to be more important than others. Some will be "special" because of what they are. E.g. In a hospital, if we treated operating theatres’ the same as goods lifts then we would get the NHS ( joke! - Isn't it just!) Ahem! - Anyway. Operating Theatres are "special" in some way and we have to recognises that and address this in strategic planning and in operations. (not that EA goes into operations)

called IT. This “how” is becoming more and more inflexible and is beginning to paralyse organisations from the centre outward slowly turning them to blocks of stone.

There are reasons why each part of the enterprise are special. Because they are. On another strand, on of EA’s problems is the ivory tower and confusing use of complicated terms, I note you used… - 'deus ex machina'

- 'Enlightenment' period

- 'the god in the machine'

- reductionist analytic thinking - Taylorism

- 'scientific management'

#2. In my opinion (and this is where we probably differ) in a lot of organisations (because of it's pervasiveness) IT is "special" and we need to understand why and how it's special so we can address it correctly. In the same organisation, the Finance department is also potentially "special" and we need to also understand how they are special. Just because something is special doesn’t mean its the necessary centre of everything. And it also doesn’t mean other things also cannot be special. IT may not always be special. In my opinion, in today’s world, IT is often special and what makes it special is that the organisations tend to have embedded 80% of the “how” they do something in this thing

There are reasons why Finance and HR are special. Because they are.

- Newtonian time-and-motion studies

- network-theory

- non-linear interaction

- disordered-probability.

Comments

Working everything back to first principles is good to make sure things are grounded and it makes sure discussion like this don’t go off into la la land, but I’m not sure if it might frighten off other people.

────────────────────────── @MATTHEW: “Actually it is complete nonIT centric. That's so funny. Most IT guys think it is but it is ALL about the business. I guess my years on the business side give me a different perspective than most pure IT guys.” I do not think EA is IT centric.

I think your statement of purpose is IT centric. I think it's the use of English… You said

units of the organisations and all players in the wider enterprise to be integrated. Because of it's pervasiveness IT is a big part of it but it's only a part. IT is also only apart at all levels above the project level (although the governance piece obviously goes down to project level) - I.E. It's 90% Strategic planning and 10% project level.”

@ MATTHEW: ”Actually it is complete nonIT centric. That's so funny. Most IT guys think it is but it is ALL about the business. I guess my years on the business side give me a different perspective than most pure IT guys. Of course EA is getting the organization to be integrated and exactly why I stated integrated and not supporting or enabling. As I pointed out too, I use the term business since the enterprise expands beyond the physical enterprise walls thus the integration applies to customers, suppliers, partners, etc. am not certain what you me about projects and project levels so, I have not comment about those statements.”

"To facilitate the integration of IT architecture strategy, planning & execution into the business model strategy, planning & execution. " Since IT is only one business unit in an organisation you should have said... "To facilitate the integration of all business units architecture strategy, planning & execution into the business model strategy, planning & execution. "

To use the term IT, you singled that one businesses unit out to the exclusion of all others, which is incorrect.. ──────────────────────────

@ MATTHEW: “Correction IT people should NOT be EAs because of they have a IT view of business.”

@ MATTHEW: “”To facilitate the integration of IT architecture strategy, planning & execution into the business model strategy, planning & execution. Does that work for you? Thanks for posting the question. “

@KEVIN: “I do not think EA is IT centric. I think your statement of purpose is IT centric. I think it's the use of English. You said "To facilitate the integration of IT architecture strategy, planning & execution into the business model strategy, planning & execution. " Since IT is only one business unit in an organisation you should have said... "To facilitate the integration of all business units architecture strategy, planning & execution into the business model strategy, planning & execution. " To use the term IT, you singled that one businesses unit out to the exclusion of all others, which is incorrect.

@KEVIN: “It's a good start but as Kirk points out in the discussion it's too IT centric. EA is all about getting all business

@MATTHEW: “Obviously you having an IT only career look at business in discrete terms. I am not talking about business units, organization units or any physical construct to define a business such as you have as stated below. Business is the interaction of

Comments

people, information, goods and services to generate value. That is what a business is to most business people not some organization unit or construct of people or process. I never singled anything out, you did in your IT centric interpretation of my words. I said business and you interpreted business unit. Please ask for a definition before drawing conclusions. It only furthers my point that IT people should be EAs.”

@KIRK: “These "rules, beliefs and (moral) codes" can be effectively articulated in principles, and, through an EA process, be applied to the actions across the enterprise.... "the principles governing its design and evolution". That piece of work is core to principles based architecture. If you can create an environment where people's actions are performed based on a common understanding of why, their decisions broadly supported, then massive change can effectively be accomplished in very short time.” I and PEAF agrees 100% @BARD: “It takes more than just making principles explicit to change this.” Absolutely. But principles are still important. @JAMES: “I wonder if we all agree on what "principles" means. Anyone care to offer up the following combination: “

@ MATTHEW: “After reading your statements a third time, you think when I say IT I am referring to some sort of organization. IT is Information Technology. This applies to all technologies no matter what state of maturity or form that deals with information. I think again, you have developed your own interpretations on my words predicated on your experiences with other about definitions of IT. I look at it much more from a systems theory view than a traditional view. Hope my further elaborations have help clarify your misconceptions.”

──────────────────────────

@KEVIN: “OK - I don't know why you are so angry with me. I will post this on the discussion - please make sure any responses are in the discussion so everyone can hear you.” ──────────────────────────

@TOM: "I just people would be less quick to criticise me for doing so. :-( :-("

Cheer up mate! I'd buy you a beer but I know you're not allowed! I definitely owe you a gammon eggs and chips though ;-)

The only way to fail (which would be very sad) is to not take part and so I solute everyone for taking part in this discussion and for voicing their opinions whatever they may be.

Actually these principles have been reduced in v2 due in 2 weeks, as a lot of these are really IT principles not EA principles.

PEAF also states that whatever principles you operate, some are “best practice” i.e. tend to be the say in most enterprises and those that are born out of the strategic planning exercise and knowing the target models and the roadmap to get there.

@MARK: “Principles are general rules or guides to promote consistent decisionmaking, in any relevant decision-making context….many organizations apply the principle of buy before build - but sometimes deliberately build to gain an advantage that could not be delivered by a purchased option.”

For all the tears and joys, all the criticisms, disagreements and moments of agreement tings, I think things are moving forward.

http://www.pragmaticea.com/displaydoc.asp?DocName=peaf-governanceprinciples

I and PEAF agrees 100%

Comments @KIRK: “Kevin (PEAF) and I disagree on principle(s) :-),”

Errrrr do we?!!!? Is it that we agree on the principle of principles but we differ on what each principle is? You previously said…

“These "rules, beliefs and (moral) codes" can be effectively articulated in principles, and, through an EA process, be applied to the actions across the enterprise.... "the principles governing its design and evolution". That piece of work is core to principles based architecture. If you can create an environment where people's actions are performed based on a common understanding of why, their decisions broadly supported, then massive change can effectively be accomplished in very short time.” …which I agree with 100%

@TOM: “Note to Kevin as thread-owner: some helpful person has shunted this thread into 'Job' again. Any chance of rescuing it before it expires, please?” Done. ────────────────────────── @TRU: "Kevin. I have been walking through PEAF. Practical and impressive" Thanks for the compliment. v2 is due out in 2 weeks and should be even more understandable, useful, usable and of course pragmatic. @TRU: "How about placing PEAF definition of "IT governance" into the peer Challenge ? (no more than 160 characters)"

When you say this do you mean PEAF's definition of the purpose of EA? to be posted in this discussion? If so, I already posted it and it's different levels of detail, but for you here it is again....

@KIRK: “I see "build before buy" as an outcome of a value.”

The purpose of EA is to…

I think “Buy before build” is a principle. And as such is a general feeling backed up by rationale and implications as to why that principle exists. @KIRK: “WHY did you chose one or the other? Some value drove this decision. This value varies with the company.”” The “WHY do we have the principle” should be documented wit the principle as the rationale for having it. The “WHY did you chose one or the other” is different on a case by case basis when you apply the principle.

========================= Increase the Effectiveness, Efficiency, Agility & Durability of the Enterprise. The Level 2 Description. (154 chars) ========================== Increase the Effectiveness, Efficiency, Agility & Durability of the Enterprise by supporting the management of the Cost, Risk, Agility & Quality of Change The Level 3 Description. (233 chars) ==========================

@TOM: “'Why' is also just about the only item that's missing from almost all conventional EA models.”

The Level 1 Description. (79 chars)

Not in mine! Every principles has a rationale to explain why it exists. If you cannot articulate the why of having a principle then you don’t have a principle.

Increase the Effectiveness, Efficiency, Agility & Durability of the Enterprise by supporting the management of the Cost, Risk, Agility & Quality of Change using Structural Models,

Comments

Performing EA Governance and Managing Enterprise Debt

The Level 4 Description. (366 chars)

==========================

Increase the Effectiveness, Efficiency, Agility & Durability of the Enterprise by supporting the management of the Cost, Risk, Agility & Quality of Change using Structural Models to aid Strategic Planning, Performing EA Governance to manage alignment to the Strategic Plan and Managing Enterprise Debt to balance short term tactics against long term strategic aims. @PAT: “I see the buy vs build is a decision based on values. It goes along with insource, near source or outsource. These are decisions not principles.”

────────────────────────── @KIRK: OK - I am wanting to understand… @KIRK: “Principles are NOT "general intent" but the reason that that intent exists. That is a big different." In my "principles" the "the reason that that intent exists" is documented in the rationale. The rationale defines why the principle exists. I agree that cultural change (which is what EA is all about) comes from people not following rules but by doing things because its just right and integral to their behaviour.

You can have (as many companies already do) a principle that is buy over build. Principles are not rules, they are a general intent. Sometimes it may be quite valid to not comply with a principle, that’s fine, sol long as that non compliance is documented and any risks and issues that decision creates are identified and managed.

Sometimes it is valid to not adhere to a principle, that does not make the principle superfluous.

This is what I would call a generic or best practice principle – i.e. it applies to 90% of organisations.

Principles are guidance not laws.

I absolutely agree that other people "principles" are not worth the paper they are written on for 3 reasons, all of which I deal with in the PEAF principles... 1) Most "principles" are just statements of intent. PEAF counters this by providing each with a reason that the intent exists, and in the training of people to use PEAF and the principles, that training is all about getting people to understand the reason why the principle exists. 2) Most "principles" get written down and then forgotten because no one effects the changes in the organisation required to operate them. PEAF counters this by describing the tasks that need to be completed in order to operate each principles.

Regarding Insourcing,/near sourcing/outsourcing or HP sourcing for that matter – these are what I would call organisational specific principles that flow from a particular organisations current, target and intermediate states and overriding enterprise strategy. If the organisation does not have any long term plans or strategies that impact where and who does what then they don’t have a principle that talks about insourcing etc. If on the other hand, an organisation has decided that generally, in principle they do not want to go down the outsourcing route for anything, then they would have a principle that says that.

So, you could say I have a documented set of things of "general intent" along with "the reason that that intent exists". I happen to have given each a description and called them principles but they are statements of intent couched in reasons for that intent exists.

Comments

3) Most "principles" even if they do get operated cannot be tracked in terms of delivering the value they were supposed to deliver. PEAF counters this by defining metrics for each principles so that the positive/negative effects of the principles can be measured and therefore adjustments made over time.

OK - now I have tried to explain a bit more from my perspective, let me know where you think I'm going astray - and really I do mean it, I have no problem with being wrong or misguided. @TRU:

The Governance in PEAF is not IT Governance. It is EA Governance (which includes IT but is not limited to IT)

time we therefore cannot discuss the merits or de-merits of a particular principle, right? OK, so….sorry but I got totally lost in your posting (had too many long words in it for my simple brain!) Can you elucidate explanation?

with

simpler

Please believe me when I say I am not trying to be difficult, I genuinely want to understand. ────────────────────────── @Stuart: "So enterprise architecture has to support and enable changes, which it can't necessarily predict. Adaptability is therefore a characteristic of a good enterprise architecture. (That's a bit abstract but I'm trying to keep this short). " Not abstract at all - And very very very true and is one of the major overlooks by most organisations today.

As to your suggestion to create a 160 char challenge to get people to define governance - that’s a good idea, but I would probably want to do that separate from this thread.

There are lots of 160 char challengers I would like to do ;-) ──────────────────────────

Driver --- The Past --- The World Today

==============================

Changes in Legislation --- Happened rarely -- Year on year

@MARK: "<everything you said>"

I couldn't have put it better myself. I could have tried but would have made a mess of it! @KIRK: "<everything you said>"

Competitors strategic moves --- Happened rarely --- Weekly.

Let's just make sure we a discussing the same topic right?

Introduction of new products and services -- Happened rarely --- Daily.

This point is about whether principles are a good or bad thing to have, right?

The wax and wane of suppliers --- Happened rarely --- Monthly

We are not discussing whether a particular principle is good or bad right? Because whether a particular principle is a good or bad one is 100% down to a particular organisation at a particular point in time, and since our context for discussion is not a particular organisation at a particular point in

The creation and demise of market and customer segments --- Happened rarely --Bi-annually

Errrmmmmmmmmmmm!

The possibility of mergers and acquisitions -- Happened rarely --- Monthly

The creation and demise of market and customer Channels --- Happened rarely --Bi-annually

Comments to change in a timely and commercially sensible fashion.

The introduction of new machines (and technologies) --- Happened rarely --Monthly

Transformational Efficiency is becoming, and will grow even more to become, a key business driver and differentiator. This importance continues to grow year on year.

Changes in scale --- Happened rarely --- By the minute.

The Past

=======

Things that could change which would require the enterprise to change only changed very slowly.

@Kirk: "A principle - a core decision value must be applicable to each and everything in an enterprise." Aha! - OK – Now I understand why we have a disconnect. You are talking about values. I am talking about principles but you are responding as if they are values. Both are useful.

When an enterprise did need to change (since processes were largely carried out by people who are extremely easy to change) it could make those changes very quickly by telling those people to do different things, by employing more people or by sacking people.

──────────────────────────

The World Today

=============

When an enterprise needs to change today it cannot rely so much on the limitless adaptability of people to effect that change.

Yes probably - and that is an area I will do some work on, to distill the values out fo the principles because I think they have worth too. FYI the rationale behind

A8: Buy (for reuse) Before Build” is:-

============================= 1) There is no reason to re-invent the wheel. 2) Where possible, the organisation should lever existing and future functionality offered by software companies instead of bespoking services, applications and systems.

This is because so much of how an enterprise does what it does, is now either completely or partially automated and the complexity of those automated systems and business processes is causing a severe bottleneck in the enterprises ability to react

KIRK: "I believe (I have not looked myself) that if you look at your rationale in PEAF behind "build vs. buy" you will find a set of values that are applicable across the enterprise landscape. "

3) Please see the sub principles for more detailed Rationale. The sub principles (and their rationale are): -

Comments A8.1 Buy a COTS service (targeted at reuse) rather than a COTS application.

=============================== =====

1) Externally supplied services managed through SLA’s tend to be cheaper and make an organisation more agile.

2) This should be tempered by the commodity vs specialist nature of the system being sourced and the security, resilience of the service and the company providing it. 3) Services that can also provide programmatic access (e.g. using web services technologies) should be favoured over those which provide a purely user interface. A8.2 Buy a COTS package (targeted at reuse) rather than building an application.

required does not exist in the market place. If this is the case, it may be prudent to consider a partnership with a software house to jointly develop a new package that can subsequently be sold. @KEN: “Guiding principles are especially useful, I've found, when one is operating in international (or cross-cultural) environments.” Yep – I would agree wholeheartedly with that. ────────────────────────── ────────────────────────── @PAT: "Also, why not put it somewhere that we can access and download as a pdf (or is that the 160challenge.asp)?" Yes - When it has reached it's natural death I will be formatting the whole and putting it into a PDF for easy distribution.

1) Packaged applications tend to be far cheaper to produce and to support and maintain than bespoke applications.

I will probably host that on the http://www.pragmaticea.com/160challenge.as p page.

2) However, this should be tempered by the commodity vs specialist nature of the system being sourced.

I will then email everyone who has been involved to get a copy.

=============================== =========

A8.3 Embark on bespoke development (targeted at reuse) only when all other options are not available. =============================== =====

1) Bespoke development tends to be the most costly option in terms of up front costs and support and maintenance costs.

No problem.

@PAT: "So...on the difference and relationship between values and principles...have we come to an agreement or agree to disagree? " Yes. Value are not Principles but Principles are related to Values and vice versa.

2) Bespoke developments tend also to be the most risky for non-software house based companies.

@MARK: "My email is Mark.Reynolds@rseg.net. Thanks for all the work, let me know if there is anyway I can help. "

3) Bespoke development can produce significant competitive advantage and so tends to be only considered for USP type functionality or when the functionality

I think Mark Toomey said it best in his post….. <QUOTE source=”Mark Toomey”>

Comments

@Pat, @Kirk: "Principles are based on core values to be used as guidelines to encourage behaviour".

I have seen this happen in 99% of the companies and work I have ever been involved in.

This brings to mind and example from last September when I was battling with a Programme Manager who started making technical decisions. When challenged, quietly at first but then more robustly, the bullying tactics came out (i.e. he started talking rubbish and expected me to swallow it) he called the designs he was creating requirements!...(He didn’t like the fact that I wanted to follow a process for making sure the design was fit for purpose because it was taking too long)

Yes! Example:

Value (or fundamental belief): All human beings are created equal. Principle: Avoid doing business with companies and individuals that exploit people.

</QUOTE>

When I finally managed to corner the CTO and told him how broken his processes were and how out of control this guys was, his response was "Well, you know, the thing is, this guys very good at just cutting through things and getting things done"

That principle applies when I make purchases and perhaps when I select employers. It doesn't apply when I make decisions about which shirt I will wear today. Principles guide behaviour in a context where we want to exhibit consistent behaviour. In terms of dressing, the "Loud shirt principle" (don't wear loud shirts if selling to conservative decision makers) might apply when dressing for work, but not for a day hiking in the mountains.

──────────────────────────

You echo my feelings entirely but have put it in clearer words and more succinctly than I could ever have done.

Power to the revolution brothers!!! ────────────────────────── @ALEXANDER: “Maintain discipline, make it simple, strive for balance, and keep is stable.”

Well, well well!!!!!!! That’s sounds like one of the best definitions of the purpose of EA to me!

@DOUGLAS: "In many organizations (not just IT, but definitely IT), despite any rhetoric to the contrary, people are rewarded for dealing with crises and problems. The MVP in the IT world is the one who came in at 3 a.m. to fix a problem, or who reacts instantly to the customer's complaint. Such an organization overlooks the fact that these MVP's are putting out fires that either they set themselves (even if by accident or incompetence) or at least they failed to do anything to prevent. Then when we promote the MVP to run the operation, we wonder why nobody follows any processes and everyone is always to overloaded to get anything right the first time. Answer: because that is the behaviour that is rewarded."

Short termism brought down the banks. It will also bring down many organisations over the next 10 years unless they take a more long term view of their organisations and projects and recognise the Enterprise Debt these idiots are creating every minute of every day. Part of this is changing the motivation model and regard structure (which I believe is why the UK government is trying to do just that with the banks)

And its in 76 characters.

This is why I think open uncensored discussion is so valuable. Every now and again a little nugget of gold pops out.

Comments @MARK: “Governance management”

NOT

I agree.

This is an indication of how much the framework is focussed on Strategic Planning compared to Project Level work. Organisation/IT

@TRU: “i would feel that the value add of PEAF on top of TOGAF is its metamodel.”

============

Whilst I do not agree with your opinion I will fight to the death, your right to express it.

This is an indication of how much the framework is focussed on the entire organisation compared to only IT.

Synopsis Comparison

Coverage

================

=======

MAGENTA

A comprehensive framework but due to it’s size and complexity is very difficult for organisations to start with. TOGAF

Zachman

Is an IT Architecture framework not an Enterprise Architecture Framework. It’s quite big and complex and therefore difficult, time consuming and costly to adopt.

Is only a Metamodel. The top 2 levels are the domain of Enterprise Architecture but the 3rd level is project level Solution Architecture and the 4th and 5th levels are Technical architecture. PEAF

For the complete comparison of TOGAF to PEAF (and Zachman and MAGENTA) have a look at the “Framework Comparison” .PDF at http://www.pragmaticea.com/v2preview.asp

=============

This is an indication of how usable it is in terms of both understanding and applying it. It tends to be inversely proportional to the size and complexity of the framework. You can also download the “Framework Comparison” .XLS and adjust the scores and weightings if you disagree with them.

@IAN: "Many EAs seem to tend towards the 'hard-sell' approach. Kevin's imagined dialogue I think falls into that category (sorry Kevin :-)) - to such an extent it is unrealistic."

No problem.

If you are referring to what I said in the title of the discussion, I would agree whole heartedly with you which is exactly why I changed it and posted a new one (unfortunately my original horrible one is still there at the top of every page of course!)

Strategic/Project

=======

──────────────────────────

Is a complete EA framework which is concise and allows for fast adoption.

The comparison covers these areas: -

Usability

Comments

In case you missed my updated one, here it is.... or do you think this is to hard too?

=============================== ========

Me: Yep – And that’s exactly what the people I work for want their competitors to believe. <5th floor>

Me: Hi, how are you doing today?

Me: Anyway, nice to talk to you. Goodbye.

CEO: Fine thanks. And you?

=============================== ========

Me: Fine too thanks. It’s been really cold this last month hasn’t it? It’s amazing how people go on about global warming and we end up having the coldest winter for years! <Doors Closing. I press 5, CEO presses 7> CEO: Yes.

Me: Do you work her?

CEO: Yes I’m the CEO of <A company> <1st floor>

CEO: Yes. It has it’s moments <wry smile>

Me: Yeah I know what you mean. There’s good and bad in everything I guess. CEO: Yes. <3rd floor>

@IAN: “I may have been a little too cynical :-)” I doubt it! People always tell me I’m being to cynical, but actually after a while they usually realise that I was just being a realist! Actually I think your “<<thinks>>” additions are spot on. Exactly what I thought he would be thinking during the conversation. Although he is slightly more paranoid than I had anticipated! (His name isn’t Marvin is it?)

Me: Wow! Really? That must be a really tough job right?

<2nd floor)

──────────────────────────

<4th floor > CEO: Really. Sounds like a lot of mumbo jumbo to me. Snake oil.

Ah well, the first casualty of war is the plan (the 2nd is the truth). ──────────────────────────

@IAN: "Marvin the CEO has been around and fought his way up politically through organisations. He knows for sure they're out to get him - or to get something out of him. He has maybe 30 spare minutes per day, spends 12 hours at work, 2 hours with his wife and 5 hours sleeping on an average day. He last read a novel - or anything purely for pleasure - in 1986. He also happens to have a brain the size of a planet - and he's had

Me: Take my job – It’s good because what I do can have massive positive effect on an organisations bottom line, but on the downside, it’s very difficult to publicise because organisations that adopt what I do, don’t want to sing it from the tree tops for fear of their competitors finding out and them losing the massive competitive advantage it creates.

The only place I would differ is that when I say “Goodbye” I was of course expecting him to stop me and ask what it is….This of course wouldn’t happen, which is probably why the 2nd encounter may get more traction, although having said that he would probably think “Oh my god not that bible basher again!”

Comments hundreds of people try to tell him what to do in the past five years. "

Hmm – you must know a different Marvin to me!

I understand where you are coming from, but you still must say something to the CEO right? So what would you say? I can think of a few very large companies where they will ask you in the interview what would you say to the CEO of a company if you were in a life with him for 30 seconds….and you’d better have a good reply. So, I take you point but what would you talk about? say? @PATRICK: “it was more along the lines that the CEO asks *you* what EA is all about!” Yep that’s fine. The CEO is going to be very cynical, perhaps even dismissive but what would you say to him…that’s the crux of the question. ──────────────────────────

The Marvin I know doesn’t care much about the company he works for. He has spent years battling through the ranks kissing whatever needed to be kissed. Bullying those below him and sucking up to those above him. He usually has about 8 hours free a day although no one seems to know what he does as he always seems to be very busy meeting important people and having important meetings although achieving little apart from making large number of people redundant and planning how to parachute out of this company into the next one when the going gets tough. He has long since stopped listening to people lower than senior executive level as they tell him things he doesn’t want to know about because if he knows about them he’ll have to do something about them, so best to avoid the facts wherever possible. He has surrounded himself by people who agree with him, having ejected others for having attitude problems when they pointed out he was making serious mistakes, mistakes that cost them their jobs but cost the organisation tens of millions of pounds.

OK – both our Marvins are at opposite ends of the continuum, but they both exist and I would bet that most people would recognise the latter rather than the former. ──────────────────────────

@ANATOLI: “How someone be a president – without glasses?!” Nice one!

I agree but I don't think that's so much of a problem with team members as management. It's been mostly my experience that management (UK management mostly) are the biggest culprits of forcing to do things "because I said so". I worked for a large company some months ago and the CTO's deputy was forcing me to not look into certain solution options. I tried and tried to get some explanation as to why, and the answer was always "because I don’t want you to". So that's what I wrote in my solution options document. The solution was listed but with a one liner saying "this solution was not investigated or quantified because <name> said so"

EA – Xray Spec’s for your Enterprise!

MICHAEL: "to keep the team members from selecting what they like,"

@ART: “What I like about the selling EA in a 30 second conversation with a CEO... Nothing.”

Strangely he came to see me and asked me to take out that statement.

Comments

Power with no accountability. Excellent principle. And the cancer of British Management. (Of course there are some good ones too!) ──────────────────────────

The purpose of EA is "To give the business answers to questions it didn't know it needed to ask." People vilified Donald Rumsfeld for this supposed "gaff" but although its sounds like something from a cheap tv comedy series, it is, in my humble opinion, painfully insightful.

"There are known known’s. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know." government a next man (or do say useful to heed their

So, is there anything wrong with 64 pages here??? or on the CM definitions of SA????? I say no. Who cares. Its not a question of how many definitions you get or whether everyone agrees with a certain set of words to describe it. What matters is how many fundamentally different definitions there are. Unfortunately this now means that I will have to go through them all and categorise them. Well it’s going to be a bit mind numbing and will require a certain amount of subjectivity but I think doing that will provide us with a small number of fundamentally different definitions that we can then vote on and for each, can say why a definition is correct or not.

I am up for giving someone in good kicking as much as the woman) but sometimes they things and we would be wise words.

Analysis, Risk Management, Turning the lights off when you're not in the room, Cooking, Chairs, a Business Strategy, Crisps, etc, etc, etc....I would expect that it would also generate (over time) the same number of definitions.

As Aristotle Onassis said “the secret of business is to know something that nobody else knows” I would stand very small in his shoes and am not fit to breath the same air , but I would improve slightly on his quote thus.

“the secret of business is to know something that nobody else knows, unfortunately that initially includes you”

I am an architect, so I must do what architects do…abstracting complex things into higher level structures to aid understanding. I feel good. I have a plan. And the plan is good. Watch out for the next update of the PDF sometime soon…….. ──────────────────────────

@ALEX: "The same goes for "software architecture"

@MICHAEL: “I am using it to understand what we need to consider in purchasing an EA / BPM suite. The diagram has been created in relation to the Zachman framework so I think it should cover everything."

Hmmm. That makes me wonder.

Are we asking an invalid question? For example, if I were to post in a discussion group for people to post their short definitions of the purpose of; Business

──────────────────────────

Looks good but you are missing a few things and also I think getting too detailed in some instances.

Comments

Have a look at the Metamodel document here http://www.pragmaticea.com/peafproducts3-model.htm for a pragmatic starting point. Since you are sourcing an EA modelling tool, I would also suggest you look at the Tool Requirements, Tool Vendors and Tool Evaluation documents. Don't forget however that there is no point modelling anything unless you have a question you need to answer. So although you need a very high level Metamodel to start with that you should be able to populate in a week or so, any serious population of you model should be driven by this sequence/process : -

One of the major problems I have with getting organisations to understand EA is that is has a massive amount to do with strategic planning, but the problem is usually non one is interested in strategic planning as everyone is, as you say, fire-fighting, including senior execs and C-Suite people which is strange because I would have thought that was (a big part) of their job. If those senior people are not doing it, who is????? The answer is no one and that’s why most organisations are in a fire fighting spiral into oblivion. The problem is, they don’t know it and they can’t see it. They think the more panics and the faster everyone is working the better it is ignoring the fact that theres an awfult lot of pedalling going on, but not much forward movement. I can't speak for the rest of the world, but in my experience, in the UK, generally speaking, Directors do not Direct, and Managers do not Manage.

1) Identity a high level business question that the management wants an answer to, that they either a) Currently cannot answer, or b) Can get an answer but the quality and confidence in that answer is too low to be useful. 2) Determine the data (entities, attributes & relationships) you need to be able to answer the question. 3) Source the data and populate the model,

Integrate the original data sources are remove them 5) Answer the question

This is a looping iterative process. More detail can be found in the "Modelling the Current State" Process defined in the "Operate" phase here http://www.pragmaticea.com/peafprocesses3-operate.htm ──────────────────────────

My thoughts exactly.

I would also add that, in my experience, large organisations can operate and work in mindblowing stupid ways but still make money. And if they are making money, everyone’s happy, there is no problem so why would they want to change.

When I pointed out to one CEO that, yes there are making a nice profit, however if they did a) b and c) they would make even more profit and provide even better customer service, their response was – “Kevin we are already making a huge profit. If we make any more its going to start to look bad”. I have lost count of the number of large organisations I have gone to work for thinking that they must be really good at what they do and it will be a great place to work, only to find out when I get there that a lot of them are fundamentally broken and seem to waste millions upon millions of pounds without caring. An in spite of this, they are “successful”.

@KINSHUK: "Why are C-suite people always fire-fighting ? It is complete mystery to me. "

Comments

EA is not about making an organisation successful. It’s about making an enterprise more successful.

have any time to make sure that the next thing coming down the road does not turn into a panic.

EA is not about making an organisation profitable. It’s about making an enterprise more profitable.

It is a downward spiral that you need to break out of and Strategic Planning is the key to that.

EA is not about making a bank, a bank. It’s about making a bank, a better bank.

There is nothing wrong with doing tactical things but you also need to balance that by doing strategic things and you only can do strategic things today if you planned to do strategic things yesterday.

──────────────────────────

@ALYSSA "Let's talk Rapid ROI for EA sometime.. " No! No! No!!!!

We do not want to talk about rapid ROI.

Rapid ROI is what everyone in the company is already striving for.

EA is about strategic planning not Rapid ROI.

Strategic Planning is part of the whole of what they call Enterprise Architecture which is a discipline to help organisations do that balance tactical expediency with strategic intent (amongst other things). And like with any discipline (like PRINCE2 for example project management) there are frameworks to help you do that.

EA over time will enable Rapid ROI for free but it's a by product of proper strategic planning.

If you do a survey of the percentage of people in an organisation who were concerned with strategic planning as opposed to tactical firefighting, operations and Rapid RIO I am sure you would find the ratio to be close to 1%:99%. That is the problem.

When I am talking to C-Suite people and executive management about Strategic Planning (aka EA) and they start to go down the "but I've got problems today I need to solve, what quick wins can you give me?" route, I say this...

@KIRK: "Cultures that punish the losing side of a debate, are also caustic - no one participates, as the loser is punished. Nothing is ever questioned, so the alpha dog makes the rule, and everyone follows... highly dysfunctional. " ... and everything else you just said. Agree 100% although I would replace you word “caustic” with “cancer” as something caustic is usually easy to spot whereas a cancer can remain hidden for years and then when you notice it is probably too late to do anything about it. And unfortunately that is the culture I have experienced is every company I have ever worked for. I know because, being an architect in my heart, I work for the common good and question things when non one else will. And I have born the consequences, but kept my integrity.

The reason you have all these problems and need quick wins is because no one is doing any (worthwhile) strategic planning. Things coming down the road which are not panics are largely ignored until they become problems. Usually problems that turn into panics, so these panics have to be dealt with. And in dealing with these panics you do not

──────────────────────────

It is usual in (mostly UK) companies for a manager to get people in a room and to tell them something, and then, when he asks for

Comments

comments and get's total silence he (its usually a he) take that as an indication of total acceptance of what he just said and that what he has just said is therefore totally correct.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The purpose of Enterprise Architecture is to...

God point about the Jedi (not that I am a Star Wars fan by any means, and I hadn’t noticed that before) However, it strike a serious note with me because, when I do the same and get silence, I prompt more for comments and if none are forthcoming say “no one is leaving this room until I have heard at least 3 people tell me problems to do with what I have just said.”

allow an enterprise to thrive

I have learned more things and earned more respect by that simple action than in anything else I have ever done.

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<

──────────────────────────

applying Strategic Planning, Architecture and Governance using a Framework.

the more detailed definition is... >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>

@KIRK: "From a Larry DeBoever (Meta Group) presentation: 10 executive turn offs for EAs"

I think I would agree with all of those apart from "Emphasize that EA’s ‘ROI’ is really down the road."

In my experience, if you don't make that clear up front, you will be forever chasing quick wins and not doing any strategic work at all - much like 99.9% of the rest of the company. Quick wins treat the symptoms. EA treats the problem.

──────────────────────────

The latest analysis of this thread can be downloaded from http://www.pragmaticea.com/160challenge.as p.

The purpose of Enterprise Architecture is to… enable an enterprise to realise its Vision through the execution of it’s Mission, whilst enabling it to respond to change and increasing its effectiveness, profitability, customer satisfaction, competitive edge, growth, stability, value, durability, efficiency and quality while reducing costs and risks by

Strategic Planning, Architecting and Governance supported by a Decision Support framework in the context of aligning all parts of the enterprise using

Models, Guidance, Processes and Tools.

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<

There is a new detailed analysis, (page 11-40) the output of which offers the following as the shortest most succinct definition of the Purpose of EA...

────────────────────────── I would agree that "SOA’s key strength is that it is the first IT approach that blends or unifies business and technology"

100

Comments

Unfortunately, as with EA, SOA has been hijacked by the technology guys (and the vendors) so its all about ESB's and Web Services and Canonical Data Models and Adapters etc etc, i.e. 100% about technology - which is totally wrong.

It's refreshing to hear someone else out there who sees SOA as at least 50% business.

Regarding your points about EA frameworks - the problem is that (like SOA) most of them only deal with IT but as you rightly understand "… doing EA is FAR MORE than creating a reference architecture, creating a physical architecture or picking a technology to standardize on. Those are parts of the puzzle but not the whole puzzle by any stretch."

It is also 100% free for those who wish to lever EA to improve their business (i.e. EndUser Organisations, Government Bodie and Academic Institutions) . A commercial agreement is only required for those that would profit from PEAF by using it (i.e. Consultancies, Tool Vendors, Training Providers) Go have a look and let me know what you think. www.PragmaticEA.com

────────────────────────── Hi Adrian,

I'd like to address each our your points.... --------------------------------------------@ADRIAN: “I found that people graduating from certification courses were unable to define what Enterprise Architecture (EA) is. Well that is the root problem, isn't it? How do you certify someone for something you can't properly define? Let's not accuse the newly certified alone. Asked an EA architect then. You shouldn't be surprised to discover that some don't have a clue.” Pragmatic can define it, and people going on PEAF course can also properly define it. Not only from the point of view of some words that they can say when people ask the question but from the heart and soul where the true meaning of EA lies.

That's why I created PEAF - Pragmatic EA Framework. Not only does it press all the correct EA buttons, its approach is 100% pragmatic (hence the name) providing people with 90% of what they need to start on the EA journey.

who wants to use it to improve their organisation, be that a private, public company or a government agency).

Your comments are precisely why I created PEAF (which is, don't forget FREE for anyone

@ADRIAN: “I make a distinction between EA training and certification. While any sort of EA training may be all right for a starter, one would only be certified for a particular method anyway. And there are many.” The thing is this, if you want to “teach” someone about EA theire are effectively two levels. Level 1 is general EA stuff, what is it, why would you want it, what would you get from it, what its not, etc etc.

Level 2 is actually understanding how to go about doing it, when and with what. This level is therefore (or should be) grounded in processes and products (i.e. things that you need to produce to execute the processes) This level is what you would call a framework, therefore to get a detailed understanding and to be able to “do it” you have to get down to the framework level.

I believe you are correct in almost everything you say. I have felt that way for a number of years. There is a way forward though.

---------------------------------------------

PEAF differs however from other EA training because a) it really does provide everything

Comments you need, and b) because it provides those things in a concise easily understandable and easy to use way.

PR ---------------------------------------------

@ADRIAN: “ In fact most true EA architects build their own because the existing "frameworks" are rather incomplete. For instance: *)Zachman is only a mere taxonomy or ontology, if you listen to a self assessment. That is, it is not really a framework. It doesn't give a structure for the Enterprise or a method to transform it. *) TOGAF is an (IT) development process framework if you really insist to call it a framework. It addresses a program management rather than architecture audience. As a process without a structure, it does not really guarantee a result.”

PEAF does not provide such useless shelf ware. PEAF provides a full set of documents you can use from day 1. In fact, in the professional course delegates actually spend time using the documents such that when they leave they course they have already begun to “do” EA, rather than thinking “ok., I went on a course, no what???” --------------------------------------------@ADRIAN: “Assuming that one is trained, the new EA architect has to browse now EA books (each and everyone is different, do we really write about the same thing?) and articles, stay put in the EA community, publish own view, and do work” I wouldn’t agree with that, personally to do EA you just need a good grounding and then going and “doing it” ---------------------------------------------

True - This is where PEAF steps in to fill this gap. You can see how PEAF and TOGAF and Zachman compare (in different categories) at http://www.pragmaticea.com/docs/peafoverview1-framework-comparison.pdf

---------------------------------------------

@ADRIAN: “ It might be worth getting trained in abbreviated courses but the certification what is it worth? If all you are after is a job solely, then do it because some jobs descriptions require it.”

I would agree that some certifications may not be useful, but from an individuals point of view certification hopefully at least demonstrates to themselves that they have understood what was being taught” ---------------------------------------------

@ADRIAN: “And after all, anyone who pays becomes a certified EA architect. That shows in our EA groups discussions. This is why we have so many EA architects and so few Enterprise Architectures with so much secrecy surrounding them.” I believe this is true for many of the current certification and frameworks but this is absolutely not what PEAF certification shows. Certification is also pragmatic. Our aim is not to get as many people through the door as possible, our aim is to create as many knowledgeable and rounded Enterprise Architects as we can. Going on a PEAF course and taking a PEAF exam does NOT guarantee you pass. --------------------------------------------@ADRIAN: “How do you distingusigh the real EA architect? First you know what you want, and compare to what EA can do. EA is a set of integrated blueprints. That is what your architect should generate. Stakeholders then would use them for their own purposes. Just ask the question: what are you going to deliver? If the answer is long and

@ADRIAN: “ But they won't help you do the job. As in most cases your manager does not know what to expect then that may be OK. You should deliver large and great documents full of side knowledge. Everybody does that. Nobody uses the documents afterwards because they are just a collections of observations, facts, methods, disclaimers, quotes...”

101

102

Comments the "EA Framework Comparison" document at www.PragmaticEA.com

I hope I have.

@BRIAN TURNER: "They are similar, only SABSA is more complete with a layer for security, as well a manual for building a riskmanagement dashboard. "

circuitous then you surely found a certified EA architect. But convince me otherwise.”

---------------------------------------------

@ADRIAN: “EA means more Business Architecture nowadays but certifications are still IT based.”

This is not true of PEAF - PEAF is true EA not IT EA. ---------------------------------------------

@ADRIAN: “Nevertheless, if you work for the US government, for instance, there is sense in being certified in their method, FEA.” Agreed.

I think SABSA looks great but it’s only a sliver of an EA framework and in my view too much of a sliver to be called an EA framework, hence it is called an ESA Framework. Yes it maps onto Zachman, which is good but it only provide the security layer/tier of that model. You can view Zachman as the general categorisation model that does not represent system things such as security. SABSA adds that, which is good.

──────────────────────────

Yes I agree they are similar in that they both contain a taxonomy although the SABSA taxonomy only deals with Security (which is not a problem because that what it has been designed to do) However you could also say they are not similar because SABSA also contains processes.

@BRIAN TURNER: "SABSA is indeed an Enterprise Security Architecture. "

Yep - And the question in this discussion was "Which "EA Framework" is best at ......." not which ES Framework..... I was just pointing out that I thought it's not really related to the question.

I think it’s a great addition as for too long security has been a) thought of only in terms of IT - which is wrong, and b) tacked on at the end - which is also wrong.

I'm not saying it's not good at what it is aimed at, it's just not aimed and helping companies do EA.

@BRIAN HOPKINS: “Gee Kevin, a loaded question?”

@BRIAN TURNER: "Do you consider the Zachman Framework to be an Enterprise Architecture? "

I don’t understand why you say that? Unless you are saying the question is loaded because it assumes that you need to use and EA framework in order to do EA.

Have a look at the framework comparison of Zachman, TOGAF, PEAF and MAGENTA in

I guess from this point of view it is loaded and actually it doesn’t agree with my belief or the teachings of PEAF. I.E. In PEAF training/communication products we ask the following question…

Zachman is not an EA. Zachman purports to be an EA Framework. In fact it comprises only one of the things that you would require in an EA framework. Basically it only provides a taxonomy and that taxonomy is very IT centric. There are no processes, principles, governance structures, tool help, etc, etc, etc.

“Can you achieve all these things that EA purports to, without utilising an EA Framework?”

Comments The answer I and PEAF gives is,,,

“YES! Absolutely you can - if you know what your doing” It also poses…

“Will utilising an EA Framework guarantee we achieve these things?” The answer I and PEAF gives is,,,

“NO! Absolutely not - if you use it incorrectly” We teach that frameworks are there to guide people and help people achieve something. There are in effect a tool. And like any tool, just because you use a tool does not guarantee success nor does not using it guarantee failure. But it can help if used in the right way.

complex and difficult implement and use.

103

understand,

PEAF solves both of these problems. So, while I would agree that the framework is not the point (and I say that if a company thinks it understands enough already about what EA is and how to “do it” then they don’t need a framework. It’s the same as other frameworks such as PRINCE2, SixSigma, LEAN, MSP, etv, etc, etc. PRINCE2 is a method for doing project management and having successful projects… Can you mange and have successful projects, without utilising PRINCE?” “YES! Absolutely you can - if you know what your doing” “Will utilising PRINCE2 guarantee we have successful projects?”

In fact I, and PEAF first words on the subject on EA are in presentation entitled “EA Why I DON’T need it!” as I was so fed up of people trying to explain why people need EA and EA frameworks, when in fact they don’t - so long as they already know what to do and are achieving their goals. You can see the whole slide set in the Culture section http://www.pragmaticea.com/peaf-products2culture.htm ──────────────────────────

@BRIAN HOPKINS: “IMO, EA organizations tend to get lost in Frameworkville and miss the point of EA.” Oh - I would absolutely agree with you on that one. But I ask - Why is that the case?

“NO! Absolutely not - if you use it incorrectly” So why would you want to utilise PRINCE2? One of the problems with EA (as with many things also) is that people (me included) like things to be simple but this trips us up because the world is not simple - things are made up of many things which come together, so an EA framework is important but it’s not the only importa thing, you need commitment, understanding, resources, time, etc etc. I don’t say using an EA framework is the only thing you need to be able to “do EA” it’s just an important part of doing EA for people who don’t know how to “do it”.

@BRIAN HOPKINS: “See http://practicingea.blogspot.com/2010/02/wel come-to-frameworkville.html”

I believe it is because the frameworks and training available prior to PEAF caused that. The existing ones were either incomplete and contain only a taxonomy (which is about 20% of what you need in an EA framework) or they are very IT centric and massively

Yep - you make a lot of very good points and I agree with almost everything you say.

104

Comments

But my view is that the tools (frameworks) that people have used in the past (not including PEAF) were, essentially, not very good for many many organisations.

Have a look at this analogy and let me know what you think… http://www.pragmaticea.com/pragmaticgardener.htm

──────────────────────────

@BRIAN_H: “My point of the Frameworkville blog was that any EA Framework, including PEAF, is not the magic bullet to EA."

@BRIAN_H: “When my organization is ready for a Framework, PEAF will be a strong contender, but we've much growing and maturation to do before its worth the time.” But this is exactly were PEAF can help you. Just look at the prepare/foundation section it would take maybe 10-20 mandays using that to have a good chance of getting understanding and buy in from the board. After that full framework adoption may help, but remember one of the main tenets of PEAF is that it recognises that the first step has been so difficult up until this point so it’s there to help with that very important first step. Even if that first step goes no further.

Absolutely, I couldn't agree more. In fact I would go one level deeper and also say that EA itself is also not a magic bullet - but some think it is and when it turns out not to be they tend to blame EA and it gets a bad name.

Yep I can see what you are saying, but maybe where we differ is that I believe PEAF can help in that process before full blown framework adoption. That’s something that no other framework has ever even tried to do.

BRIAN_H: “I speak with many budding EAs who are struggling to improve their practice and often think, "hey, if I just adopt this framework, I'll get better at how I do EA." I say, NOPE"

────────────────────────── @GEOFF: "RBV, Ashby et al..." Cool - but what's the ABV of the Beer?

Yes - I think I would also agree you with there. But I would make a small distinction that it's my belief that before PEAF the frameworks on offer couldn't really help them. Now I think PEAF can. Not to turn water into wine, but to give people who are reasonably intelligent (and organisations) a better chance.

To be honest - to me it all sounds fine and dandy, and having read about it I now have the knowledge.

It's not a magic bulley but it is at least, an Aspin.

"shouldn't we have a model/diagram" that shows how your enterprise is comprised such that when you want to change a part of it you know what other parts will be affected and how so you don’t inadvertently either kill the organisation or seriously compromise it"

BRIAN_H: ""At the beginning of the journey is all about building credibility, culture and synergy. Once the business and the CIO are coming to EA because the team that can identify opportunities and clear obstacles, then you are ready to say, “if you think this is good, wait till you see what I can do with a Framework!”."

But bearing in mind the organisations I have worked for over 30 years have had serious problems understanding very simple things like...

or working in sensible ways...

"yes we know what we are going to do is destined to fail and cost the organisation millions of pounds and waste years of time,

Comments but we are going to do it anyway because I say so and if you were just positive about it everything will be fine"

I am pretty sure that if I had started talking to them about systems theory, the law of requisite variety, cybernetics, systems thinking concepts, emergence and recursiveness, etc I would have seen their ears start to bleed. I am not saying that these things are worthless or that they are not used, but when most of the time you are trying to sell water to a tribe, I'm not sure that they would be interested in buying broadband. ──────────────────────────

The problem is in most organisations (hence the need for EA) that everything is interconnected in one way or another and therefore to only look at one part will almost certainly have potentially disastrous consequences on some other part. This is a true if you only consider IT as it is if you exclude IT. ────────────────────────── Hi Tom, Yep - same to you - always good to talk to someone who can give my mind some exercise to stop it turning to glue. Thanks for the pic - thanks I think I will use it. Did you take it? If you did I'll attribute it to you. BTW, here's that Einstein quote I couldn't remember.

@PAUL: “Has there been much in the way of experience in applying EA (or DODAF) for efforts that are not primarily for driving technology e.g. for business planning/strategizing?”

105

IMHO true EA is never only about IT. EA probably needs to address IT but not because its IT, but because it's an important and integral part of the functioning wider Enterprise. Having said that, EA should include Finance and HR as they too are important and integral parts of the functioning wider Enterprise. Everything is special in it's own way.

All parts are equal (it’s just that some parts are more equal than others when you add people and politics to the mix!)

Many (most) EA frameworks are very IT focussed which unfortunately perpetuates the incorrect view that EA is all about IT.

Sorry for my memory but actually, I think that’s another part of being an Architect (or maybe just me justifying my inadequacies!) Personally speaking the actual words as quoted are not important to me hence I don't fill my mind or expend any energy remembering the exact words. What's important to me is the sentiment behind the words. And here’s another Einstein quote that I think sums me up perfectly… “It's not that I'm so smart , it's just that I stay with problems longer .” Cheers,

However, there are frameworks out there that I would call true EA frameworks.

"We can't solve problems by using the same kind of thinking we used when we created them."

EA is all about business planning/strategising (mostly referred to simply as strategic planning)

Kevin.

────────────────────────── @GEOFF: "Go away and learn about business strategy and systems thinking."

106

Comments

Hmmm. Not sure I would call that a positive statement…

Honestly, you are obviously very angry about something - what is it??? Really - I want to know. Do you talk to business leaders like this???

@GEOFF: "You don't have any knowledge of systems thinking and stratgey." So what!

At least I know how to spell strategy (there’s an “e” after the “t” by the way)

See how easy it was for me to find something to pick on and vilify you about?

Anyway, you obviously know a lot of stuff but I think you need to come down from your ivory tower every now and again and help poor pathetic souls such as myself instead of throwing thunderbolts. Cheers, Kevin. ────────────────────────── @DOUG “Just my as-ever-not-so-humble opinion ... :-)” Cool - It’s an opinion I can understand and provides a platform for me to resond to and thus the discussion continues in a positive vain.

Actually I couldn’t care less about how you or anyone else spell things or how bad peoples English is (although there are many people that are much more concerned with style over substance - a function of the world we live in today) I’m interested much more in the substance and in intelligent debate.

Partnership” for 10 years - unfortunately the link to your website goes nowhere and the domain is just a parking page and there is no UK company listed with a name “The Elliott Partnership” So I'm none the wiser.

Sorry, but if you keep setting them up, once in a while I’ll have to hit one out of the ball park ;-) As I (Einstein) said before - "The true sign of intelligence is not knowledge but imagination." I would add my own quote "Those who use knowledge as a stick are the least suited to use it intelligently" (The knowledge I mean not the stick!)

I went on to Linked In to understand more about your background but you have posted almost no information about yourself, other than having worked at “The Elliott

“EA is a homeostat for an enterprise.”

aka

It exists to “hold an organism within the internal balances needed to for it to keep on living” OK - you can get all complicated and detailed etc, but fundamentally it kind of sounds right to me.

When I find someone who doesn't know something that I do, I spend as much time as they want helping them to understand it and how it fits into their context. The only thing I need in return is their appetite to understand.

I think the homeostat stuff is really excellent and it immediately makes me think of a statement that describes what EA is (and thereby it’s purpose) - this assumes that people know what a homeostat is (but that’s just knowledge right, which is easy to attain so long as there are people there to share it.)

That’s sounds like the perfect thing to spend hours discussing over copious amounts of beer washed down by a particularly hot Prawn Karahi ;-)

Comments

But can you tell me (bearing in mind that mere mention of the word architecture sends the management scurrying into their holes like some panicked Meerkat) how do you broach such things such as “the law of requisite variety, cybernetics control theory, management cybernetics, information channels, amplifiers, filters” with the management? @DOUG: “this body of EXTREMELY relevant to EA.”

work

I think I would agree - so I need to know more about it. For me I don’t learn by being told to go read a book or a blog or a website. Life’s to short for that, I want to utilise the hard work put in by others who have more depth than I ever will, so I want to understand the big picture and how that may help.

@Doug: “On the point you raise about talking to clients of EA about such things, I generally don't.” Yep - I was kind of getting that feeling. It’s more an internal anchor and sextant I guess. @Geoff: “Please explain how knowledge can be shared? Data and Information yes but not knowledge, absolutely NO. See the work of Polyani. Knowledge is not found in Books on or the net and cannot be transferred.” Please see my response above. That should give you a small example of how knowledge can be shared. Of course, I am but a simple man and am using the definition of the word “knowledge” as described in the dictionary (Websters in this instance) and how it has been used throughout my life which may not be what you understand to be the definition of “knowledge”, and if so please let me know your definition so we can have a meaningful dialogue otherwise we are talking apples and pears.

After all, I am an Architect.

Although this is great stuff, I fear we are hopelessly off topic - can you or someone who has appetite to help others understand and is willing to explain things start a new thread…something like “EA and <stuff you said> working together for a better future??” ──────────────────────────

@Doug: “I will think about how to position a separate thread around cybernetics and systems theory.”

Cool. I’m always looking to expand my horizons.

By the way, I am sure you are aware of the act of “Doing the Knowledge”…I would be interested in observing a conversation between you and a London Cabby. (The best in the world). Geoff, I can see by your comments and your previous groups that you regard yourself as a bit of an anarchist. Interestingly so do I. I have suffered the slings and arrows of outrageous fortune, and have taken arms against a sea of troubles and all my sins will be remembered. Brain the size of a planet and they ask me to pick up a piece of paper…. ────────────────────────── @Kevin_I: "Not sure why you mentioned Zachman is only taxonomy, the taxonomy is one very small component of the Zachman framework. It does handle the other parts that you mentioned - process, governance, roles, etc. "

And a discussion about it in this group would be a great way for yours (and others) knowledge to be shared with those that currently do not have the knowledge, such that in one sense the knowledge will be transferred from one place (aka you and others) to another place (aka me and others) in a way that could probably be defined as knowledge transfer ;-)

107

108

Comments

Happy to be proved wrong - where can I go to see the processes and governance provided by Zachman?

PR @Kevin_I: “I'm not sure why you state that security wouldn't be in there. Security could be in every box of the Zachman framework, if that is important for you to document." The words you use prove my point “Security COULD be in every box of”.

So if someone asks the question “Is security covered/catered for in the Zachman Framework?” your response would be “No, but it could”, not “Yes, and it is - here I will show you…”. ──────────────────────────

You are using the word framework in it’s narrowest of senses - nothing wrong with that - a kind of set of pegs to hang stuff off nothing wrong with that - in other words, it’s a taxonomy - which is all I am saying Zachman is. This is well known. There are 2 massive misunderstandings out there regarding what EA is, what it consist of and how to do it. No 1 ==== Misunderstanding: “EA is all about IT” Cause: Mostly caused by TOGAF because TOGAF is mostly and IT centric framework, and its growth which has caused many people to regurgitate this incorrect view. So many people trying to understand what EA is and what an EA framework is, look at TOGAF and go - oh so EA is all about IT. Cool!

@KEVIN_I: “The columns for the "How" works for processes (with motivations), and the why / who provide placement for governance areas. "

Take PRINCE for example - it’s a “framework” for how to do project management better, and as such it contains guidance and products and processes for how to do project management.

Ah now I see where the misunderstanding is...

I am talking about the processes of doing EA not the processes of the business that we model using Zachman (which is only part of “doing” EA)

For example, where are the processes in Zachman that describe what should be done in order to garner support and budget to embark on an EA initiative? Or the processes and tasks for implementing the changes required to operate EA or the processes or tasks for "doing" EA.

Truth: EA covers the entire enterprise not just IT. The word Enterprise means the organisation and the ecosystem it operates in aka the “enterprise” (shareholders, customers, suppliers, partnerships, etc, etc) not “big” No 2

This is why I say that Zachman is a taxonomy/categorisation framework to model an enterprise. - Which, is only one small (albeit important) part of "doing" EA.

====

@KEVIN_I: “ I'd state that a framework should support security, but not necessarily dictate it. Otherwise it would be a guidance or pattern and not a framework.”

Cause: Mostly caused by Zachman because Zachman is just a Metamodel/taxonomy so many people trying to understand what EA is and what an EA framework is, look at that and go - oh so EA is a taxonomy. Cool!

“EA

all

about

But that’s what a framework (IMHO) is Guidance.

Misunderstanding: Modelling”

Comments Truth: Modelling is a key deliverable of doing EA but EA is much much more than just a model.

────────────────────────── @Kevin I:

If you don't believe me when I say that Zachman is just a taxonomy (another word meaning categorisation or schema), you can see "The Official Concise Definition By: John A. Zachman" here... http://www.zachmaninternational.com

where the first words are…

"The Zachman Framework™ schema..."

is a

enterprise to use it to develop a shared approach to business strategy.” Yes - I can relate to that on a high and abstract level, but in the real world (Oh how I hate that phrase!) whenever anyone does anything using something and there are choices as to what is used, there will be things that are more helpful than others. I guess it also depends on what someone wants to get out of using the framework as not all frameworks are composed of the same things. (Framework meaning a set of things you can use which includes but is not limited to a taxonomy, not just a taxonomy. If all you want is a taxonomy, then Zachman is the best on a very high and abstract level or alternatively one of the tool vendors how grown ones that they have spend many thousands of man years developing like Troux’s Semantic model.)

When I say is "just" a taxonomy, I am not saying it in a negative way. It's just that, that is all it is. It's very useful but to think of it as a complete "EA frameowrk" in my eyes is missing some massively important things about EA.

109

As a classification model, of course it can be mapped to different things and different slices (or perspectives) added in 3D like SABSA which adds a security perspective.

But lets call a spade a spade, not a framework for building a house. It doesn’t take any importance or usefulness away from the spade to call it a spade.

“It is NOT a question of which "Vehicle" is best. The important thing is to have one and for the people in your enterprise to use it.” This is plainly wrong as the important thing is not to have a vehicle but to have one that does what you need it to, and therefore some “vehicles” will be “better” than others.

────────────────────────── @Michael: "There has to be a level that is more detailed than zachman where it does not matter which company you go to where they would all be recording the same information. " That is what the PEAF metatmodel (one part of EA) was built to achieve. Have a look at it in the Model section at http://www.pragmaticea.com/peaf-products3model.htm

There are two (at least) usages of the word framework. One meaning a set of pegs to hang things on, the other meaning a more compassing thing which probably does include a set of pegs, but also provides, products, processes, guidance, communication materials, etc, etc, etc.

If I were to ask you which vehicle would be best for travelling, would you say...

──────────────────────────

@Bruce: “It is NOT a question of which "EA Framework" is best. The important thing is to have one and for the people in your

If you or anyone thinks it is deficient in that respect (for its stated purpose which is to provide a pragmatic starting point for

110

Comments As at best it’s unfair and at worst misleading.

──────────────────────────

“Is only a Metamodel and as such although it covers the entire breadth of an EA model, it contains no information about how to prepare, implement or operate EA or provide help with EA products such as vision statements, maturity models, principles etc, etc”

organisations to get started. Not too high level as to be useless, but not too detailed and extensive to be confusing), please let me know and it will be changed.

KEVIN_I: “I was looking over your comparison document across Peaf, Magenta, Togaf and Zachman and I do disagree with the viewpoint that the top two levels are only EA specific, and bottom three are proeject level. That makes the model almost lifeless and useless in my opinion. The beauty of Zachman is that it is not really meant to be a single model to rule it all. It is sort of like an onion, you can have 6 levels at a higher level structure for the whole org and then IT could have it's own Zachman, where the lens would be scoped - for all layers - in terms of IT and the stakeholders.”

────────────────────────── @Geoff: “I cannot transfer my experiential learning into some ones head.” Why not? I can, given time. Can you give me a specific example of knowledge held somewhere that cannot be transferred? Please, please answer this one question if none other because this will allow us to figure out our disconnect in the most efficient manner.

The act of "doing" EA is all about strategic planning and then governance on projects to make sure that strategic plan is followed or if it is not that the implications are exposed so the business can make valid decisions.

I’ve uploaded an amended version which now says…

An EA model, models the entire enterprise from the high level strategy and objectives down to the applications and technologies.

Since Zachman is only a metamodel/classification/taxonomy, (i.e an instantiation of which is the EA model - not the act of "doing" EA, one could say therefore that EA maps to all levels of Zachman.

This is a bit complex and doesn't come out properly in my comparison document so I thank you for making me see this.

This is not a process of reading a book. It’s a process of driving round the streets of London with a map learning all the streets and landmarks (entities) but also learning all the different ways of getting from various A’s to various B’s (relationships). Actually not a very good example because the “knowledge” is not being transferred, it is being regenerated. On the other hand you could say that knowledge is being transferred because the knowledge was in 1 persons head, and now it is in 2 peoples heads…. @Geoff: “If knowledge can be held in an IT system then why have only 2 may be 3 companies built a KM system?”

However if you consider EA to be the act of "doing" EA then it's only (mostly) concerned with strategic planning plus a bit of project level governance. I.E. The majority of work is done to figure out what programme and projects are required, hence non-project work, hence the top 2 rows. When we get into the project level work EA is only there to review and guide.

@Geoff: “As for doing the knowledge a la a London cabbie tyhgis is highly contextural and read ing his book does not tell me what he knows.”

I’m not sure I said knowledge can be held in an IT system. But anyway, since you bring that up….

Comments

My view is that knowledge can be simple but knowledge can also be massively complex. Therefore, whether that knowledge COULD be held in an IT system is a function of its complexity. Whether you CAN actually build an IT system to hold knowledge is a function of it’s complexity and the resources (including time) you have to build it. Of course, with an infinite number of monkeys…anything is possible, even recreating the entire works of Shakespeare… Are you judgement?

confusing

knowledge

with

@Geoff: “polyani”

@Pitagorsky George: “Polanyi”

Just so I’m clear, are we talking about Michael Polanyi, or Karl Polanyi?

Apologies to eugene_oz for getting massively off topic. ──────────────────────────

@MATTHEW: “As you can imagine, they spent all morning trying to plaster the wall, with little success, however many times they read the book.” All your story proves is that If you do not do knowledge transfer correctly you will not transfer the knowledge. Get your master plasterer to work with them for a few months, years, whatever, and they too will become a master plasterer. Knowledge transferred.

Armstrong can transfer the knowledge but he cannot transfer the experience. Perhaps this is where confused?

you are getting

────────────────────────── @Eugene: “What makes - in your opinion an EA team ‘best of breed’?" Of course it depends what you mean by an “EA Team” but “EA Team” seems to suggest to me that you are talking about a group of people doing EA. IMHO organisations do not need “EA Teams” For me, EA is about making the necessary adjustments to an existing Enterprise and the existing teams and people there, and definitely is not about introducing an “EA Team” Enterprises already “have” an EA, and already “do” EA. For a lot of them the EA that “have” is not particularly good and the EA the “do” is also not very good. My view is that EA is all about helping organisations adjust themselves to work better together based on the products, processes and doctrines of EA. Of course that doesn’t mean that they may need extra resource to help them every now and then. I do not believe that there is a group of people (team) who are EA’s while everyone else in the organisation is not. I would say that a small part of every single person in the organisation is (and should be) an EA.

──────────────────────────

@GEOFF: “the Open University has an excellent MBA module on KM. Please sign up for the the course" Ouch!

@GEOFF: “also noting that knowledge is time based and can be illustrated using stories and metaphors but this does mean i can transfer context. Eg how can Armstrong transfer the knowledge of walking on the moon to yourself "

111

112

Comments

So, to answer your question, "What makes an EA team ‘best of breed’?"….

One that is not made of individuals but one that is systemic throughout the entire organisation.

@Kirk: “I find it amazing that you could actually distill this conglomeration of inputs into anything cohesive :-)”

Accepted. I know the original posting gave this as a reason for defining the purpose, but I think now things have moved on.

I know I tabled the "Combined (Simplified)" description, but this is just an abstraction of the "Combined" fuller description, so please keep that in mind also.

Once that has been achieved and we are not arguing “amongst ourselves” we will then be in a position to collectively discuss and agree on various hooks to grab the exec’s attention.

──────────────────────────

Thanks for all the comments guys (where are all the gals??!)

The main problem that the analysis highlighted was that different people answer the question in different ways. The key point to understand is that each persons view is just that, a view, into the full definition.

Think of the results of the analysis as an EA model of the purpose of EA. Different people will generally only see part of this whole through a particular lens.

@Kirk: “At this point, I can't see using this value statement as my "hook" in grabbing an executive's attention to "sell" EA into an organization ..."

I would now define the reason for this challenge and analysis as not to use it to grab an executives attention but to allow anyone and everyone involved in EA (learning about it, doing it, improving it etc) to agree on a common definition of its purpose. I believe that this is a key step in grabbing the executives attention as the more people that are singing from the same hymn sheet the better for the executives and the better for the EA profession as a whole.

I think this is a key point for people discussing and trying to understand the purpose of EA, otherwise people will constantly only be putting forward their lenses view of the whole and we all disappear down the rabbit hole.

Thanks Kirk - I don’t know how my brain works but

One last thing, I would also suggest that people read the whole of the “Analysis Results” section (pages 38-44) as it tries to convey these potentials for confusion. ──────────────────────────

@Nick: “I think this thread should be aware of how the sausage was made. That helps to create understanding and hopefully get some buy-in. "

The problem in abstracting something to a higher level means that by definition things tend to get missed out and the potential for misinterpretation increase.

I synthesised a shortened form but it’s the longer form that is the real definiton. Have a look at the longer definition…does that do it for you?

I think you are absolutely right and thanks for your concise summation, and thanks too for your kind words.

@Dennis: “Enabling an enterprise to realise its vision, through sustained leadership, governance and innovation, now and in the future, through guidance, models, processes and tools.”

──────────────────────────

Comments

@George: “Kevin, may I also commend you for the valuable effort you put into this. I for one however go for the long definition. It is just not right to think that one can summarize all the input you got from so many people into 160 miserable characters. You're bound to lose most of what was contributed. With all due respect, in my opinion the short version now says nothing and is way inferior to many of the contributions you got: “ Yep - I think you are right there.

@George: “- "To enable an enterprise to achieve its vision": hollow. The objective of any and every enterprise is to achieve its vision.”

Yep - Agree, I was trying to think of a term to roll up the long WHY and I think you’re right, its become almost meaningless.

113

He he! Fluff! I like it ;-) OK - Guidance is a term I used to roll up the longer grouping of “Principles, Policies, Standards, Guidelines, Metrics” - see page 37, and Models refers to all the models (and parts thereof) that people refer to e.g. as-is, to-be, roadmaps, business, technology, etc, etc, etc. @George: “- ..."Processes and Tools": the first is a true value add that makes you think. The second reminds you of the movie '2010: A Space Odyssey" and how early humans (still apes) started using tools. Tools? everyone uses those: pens? PCs? cell phones? Or did you mean some special tools? Which?”

I am flattered to be compared to ACS (although I’ve always thought 2001 ASO was largely overrated) but I can see how the word “Tools” conjures up a whole load of bad connotations. I agree it’s not really made clear what tools and this is a deficiency but tool to support everything else in the description is the intention.

@George: “- "Through Strategic Planning..": of course, what else does any management do, with or without EA? Are you saying that without EA there is no strategy and no planning?”

Actually - Yes! In my 30 years of professional life I have seen lack of strategic planning over and over and over again. 99% of organisations spend 99% of their time fire fighting and coping with operational issues. And yet they seem not to know or are incapable of realising that the “mess” they are in is due to a lack of strategic planning “We don’t have time for that airy fairy strategy stuff, I have important firefighting to do….” In my experience, most Directors do not Direct and most Managers do not Manage. It’s a cancer that is rife in the UK - less so in other parts of the world I believe.

If you look back at the statements that caused me to put them in the “Tools” bucket the meaning does become clearer but you can’t see that because that info is in the analysis xls - I think I will have to publish that info too… @George: “So what stands out in the short definition is Architecture, Governance and Processes. And you tend to agree. Should the definition be shorter? Not really. I still say even if it is long, the longer definition, through all the decoration that's added to every single term, really stands on its own two feet. I like it. Thank you Kevin. “ Yep - I think I have to agree with you there. No problem. @Richard: "PRINCE2 is a structured method/process for delivering projects and managing change."

@George: “-.."Using Models and Guidance": aargh! (sorry Kevin, but that's fluff!). Guidance? You are telling a CEO or anyone contemplating adding EA to their organization that you will provide them with Guidance? Who are you? And Models?...”

Yes that's what it is, but I asked what is its' value? "Hey Mr Executive, this is why you need PRINCE2..."

114

Comments

Using/Adopting/Operating PRINCE2 will not guarantee you have successful projects, not using/Adopting/Operating PRINCE2 will not guarantee failure. So why would anyone use PRINCE2? How can you convince someone that PRINCE2 has value?

@MrExecutive: "We've been running projects for years without PRINCE2, why should I bother with PRINCE2?" The value of EA is in what it purports to provide, i.e. the purpose of EA, hence the 160 challenge which produced....

Yes - I understand what you are saying but…. I excluded them for two reasons 1) initially because I wanted to people to think in terms and 2) when I was filtering out the words its would mean a lot of work to filter out those contained in sentences like “the purpose of Enterprise Architecture is” but keep those like this “…this applies to the whole enterprise as well as the discipline of doing architecture” I guess I was trying to exclude the term “enterprise architecture” rather than the specific words on their own that have well defined meanings (enterprise = “the organisation/company/agency and the external contributors/stakeholders such as customers shareholders, legal context, suppliers, partners, etc, etc” and architecture = “structure”)

...…to enable an enterprise to realise its Vision through the execution of it’s Mission, whilst enabling it to respond to change and increasing its effectiveness, profitability, customer satisfaction, competitive edge, growth, stability, value, durability, efficiency and quality while reducing costs and risk’s…

@Jeffrey: “ Using the words Enterprise and Architecture in the definition of EA seems a little odd. The original thread that asked for these 160 word definitions of EA required you to exclude those words from the definition, I think you need to do the same.”

Using/Adopting/Operating EA does not guarantee you will achieve these things, not using/Adopting/Operating EA will not guarantee failure. So why would anyone use EA, how can you convince someone that EA has value? PRINCE2 does not introduce anything new to an organisation. Organisations have been running projects for years without using PRINCE2. PRINCE2 just allows organisations to those things better.

EA does not introduce anything new to an organisation. Organisations already have business and IT strategies, do strategic planning, have project and portfolio definitions, do governance, reviews, etc, etc.

──────────────────────────

@Jeffrey: “ Let me know what you think of this definition. Enterprise Architecture - The modeling of a business and it’s processes in order to optimize both the business operations and the delivery of value to the customer.” I think it’s a good definition but only part of the definition of the whole of EA. For example this definition does not include governance or strategic planning, which are definitely part of EA.

EA just allows organisations to those things better.

So now I think its reasonable for those words to be included in the definition….although as always, I am open to being convinced otherwise.

Also, I don’t think generating totally new definitions will move us forward. We need to move toward consensus and that it what I am trying to achieve. If you or anyone else

Comments

115

created and not get sidetracked again into other (very valid) discussions.

@Stiles: “ I offer this which I have used for some years: "The purpose of Enterprise Architecture is to minimize the impact of change on the organization. It is not a definition of what EA is but only its purpose. I may not have understood your question. Since it is not a definition I can use EA in it. :))”

It depends on the organisation and the board you are talking to whether you can mention the words “Enterprise Architecture” but that’s not important…

Again, I think it’s part of the EA picture but not the whole. Also, I’m not sure that we always want to minimize the impact of change. If that was our goal then we may not do things that may provide business benefit just because doing them would not minimize the impact of change.

The definition that has been arrived at through analysis covers the WHY, HOW and WHAT. If you don’t want to, or don’t need to use the HOW and WHAT parts of the definition you don’t have to.

@Atiila: “When I talk the board of directors of corporation, I would never dream to talk about EA.”

@Atilla: “They are not interested in the HOW, but in the RESULT! “ Yes - I agree with you.

So to concentrate on the WHY rather than the how you would say…

thinks the definition that has been produced is missing something, or contains something that is not part of the WHY, HOW and WHAT of EA then I am completely open to discussing it with a view to updating the definition.

Therefore, like cost, risk, quality and agility, we have to change our words and say (using your definition) “The purpose of Enterprise Architecture is to MANAGE the impact of change on the organization”

That sits better with me, but as I said, managing the impact of change is only part of EA - whatr about strategic planning, etc, etc….. ────────────────────────── @ALL: “Guidance, Guidance, Guidance…..”

Then, they may say (either because they are interested and want to know more or because they mistrust you and think you are just spouting consultancy speak) “Oh yes! and how do you propose to do that”. Then you can tell them…(but only if they ask)… “by Strategic Planning, Architecture and Governance supported by a Decision Support framework in the context of aligning all parts of the enterprise” Then, they may say (either because they are interested and want to know more or because they mistrust you and think you are just spouting consultancy speak) - Oh yes! and how do you propose to do that? using what? Then you can tell them…(but only if they ask)…

Just to reiterate - Guidance is a term I used to roll up the longer grouping of “Principles, Policies, Standards, Guidelines, Metrics” - see page 37. This is what the word “Guidance” means in the context of the definition, not the generic definition fo the word “Guidance” as found in the dictionary. I am using it as an abstracted term to replace 5 other words.

“I can enable your organisation to better respond to change and increase its effectiveness, profitability, customer satisfaction, competitive edge, growth, stability, value, durability, efficiency and quality while reducing costs and risks”

This doesn’t mean that Kirks “Guidance” is wrong - In fact it’s very much right, but we need to discuss the definition the analysis

116

Comments

“using Models (Structural Models, Blueprints), Guidance (Principles, Policies, Standards, Guidelines, Metrics) , Processes (Practices, Processes, Disciplines, Frameworks) and Tools (Modelling, Analysis, Portfolio Management)” ──────────────────────────

@Jeffrey: “My intent in craftin the definition (The modeling of a business and it’s processes in order to optimize both the business operations and the delivery of value to the customer ) was to avoid the use of the typical buzzwords and provide a plain english definition that non-technical people would understand..”

I agree that’s a good thing to do, but for example you only mention delivery of value to the customer as the end goal…what about stability, growth, profitability….

@Jeffrey: “Also, I think the definition that you have presented leans more to describing the 'how' of enterprse architecture rather than the 'why',” The definition that has been arrived at through analysis covers the WHY, HOW and WHAT. If you don’t want to, or don’t need to use the HOW and WHAT parts of the definition you don’t have to. So to concentrate on the WHY rather than the how you would say… “I can enable your organisation to better respond to change and increase its effectiveness, profitability, customer satisfaction, competitive edge, growth, stability, value, durability, efficiency and quality while reducing costs and risks”

@Jeffrey: “ The prevailing buzzword laden definitions I have found are a turn off to senior management because every new idea coming through the door uses this same jargon”

I understand that but unfortunately it’s very subjective and we cannot avoid using buzzwords or phrases - neither can you! How many companies/products have used the buzz words that you have used in your own definition (that supposedly does not contain any buzzwords) “optimize business operations”…”deliver value to the customer” I would be interested to know which words you consider to be buzzwords and therefore cannot be used and which words you perceive to be OK.

Then, they may say (either because they are interested and want to know more or because they mistrust you and think you are just spouting consultancy speak) - Oh yes! and how do you propose to do that? using what? Then you can tell them…(but only if they ask)… “using Models (Structural Models, Blueprints), Guidance (Principles, Policies, Standards, Guidelines, Metrics) , Processes (Practices, Processes, Disciplines, Frameworks) and Tools (Modelling, Analysis, Portfolio Management)”

Be mindful also that your list of allowed and disallowed words will not be the same as anyone elses, so whilst your list of allowed words are not buzzwords in your eyes, when you use them to talk to people, some of those people will consider some of your words to be buzzwords.

“by Strategic Planning, Architecture and Governance supported by a Decision Support framework in the context of aligning all parts of the enterprise”

──────────────────────────

@Ramchandhar: "I would like to know how to start a career into Enterprise Architect,

Comments

Since i am more focused on the technology and business, what parameters needs to be assesed before taking up the Enterprise Architect roles and responsibilities." Of course experience is key, but how do you get experience. It’s the usual chicken and egg problem. I would suggest that if you want to know more about EA not only in terms of generalities but also actually how to do it and set of products, you should have a look at PEAF. Unlike TOGAF, PEAF is an EA framework whereas TOGAF is and ITA framework. Unlike TOGAF, all the PEAF PDF's are free to download.

Just be aware from the outset that many many many people will tell you that it’s mostly all about IT. This is incorrect. The “E” in EA stands for Enterprise and means “everything that makes entire enterprise including partners, customer, suppliers, shareholders, legislation - I.E. a superset of the organisation) “Entrprise” in EA DOES NOT mean large scale IT. Have a look at the slidesets at http://www.pragmaticea.com/peaf-products2culture.htm ────────────────────────── @Carlos: "What are the differences between Enterprise Architecture, Enterprise IT Architecture and Enterprise Architecture Framework or Methodologies?" Enterprise Architecture (noun)

@Ramchandhar: "Are there any Training programs which can help me in achieving the required knowledge with case studies in and around London or In India"

117

If you wish to then move on and be certified there are PEAF training and certification course available worldwide provided by other companies. ──────────────────────────

@PNNM: "Can Project Manager or Business Analyst become Enterprise Architect? Does this makes sense? and Worth? If so what skills they need to build to become EA?"

================== Enterprise = Everything that makes entire enterprise including partners, customer, suppliers, shareholders, legislation - I.E. a superset of the organisation Architecture = Structure Enterprise IT Architecture (noun) ==================== Enterprise = Large scale

Absolutely! It's not rocket science.

However, it's not easy because it' been cloaked in confusion and misinformation for many years.

Architecture = Structure Enterprise Architecture Methodology ===========================

As said back in May last year to become an Enterprise Architect you first have to be very clear about what it is and what it is not.

IT = IT

This is the most important, but most difficult step. But, once you get it straight in your own head, everything else is much much easier.

(1) A set of processes, products, templates and guidance to allow organisations and people to prepare for, implement and operate EA including a structure/taxonomy

118

Comments

Enterprise Architecture Framework ==========================

PR (1) a structure/taxonomy used to hold/structure a description of the enterprise (i.e. Zachman)

(2) a structure/taxonomy used to hold/structure a description of the enterprise PLUS a set of processes , products, templates and guidance to allow organisations and people to prepare for, implement and operate EA (i.e. PEAF) Enterprise IT Architecture Framework

============================

────────────────────────── @Priya: “Is TOGAF an Enterprise Architecture Framework or an IT Architecture Framework?” TOGAF is definitely not an EA framework. TOGAF is an IT A Framework. It's all about architecture on projects. To see how TOGAF compares to Zachman and others have a look at http://www.pragmaticea.com/docs/peafoverview1-framework-comparison.pdf

(1) a structure/taxonomy used to hold/structure a description of the organisations IT PLUS a set of processes, products, templates and guidance to allow organisations to take an architecture centric view of projects (i.e. TOGAF)

To understand a bit more about what EA will do for an enterprise, have a look at the Vision document at http://www.pragmaticea.com/peaf-products1foundation.htm then you will be able to decide whether EA is of use to you now or in the future.

──────────────────────────

@Cowboy: “Am I just projecting my personal likes and dislikes onto the company, and we should be getting more organized? Or am I right in thinking trying to comply with these methodologies would slow us down to a crawl and take away the only competitive advantage we have?”

EA exposes complexity to enable understanding which then enables strategic planning and governance. If you don’t have the complexity or need for strategic planning then you don't need EA.

At that point (or preferably as you approach it) EA will help you preserve the flexibility and agility but not at the expense of longevity or profitability.

Of course if you think that EA means Enterprise Class IT Architecture, then you could call it an EA framework but I would not condone that because it reinforces THE main issue with getting organisations to understand and recognise what EA is, and that problem is exacerbated by people thinking and regurgitating that TOGAF is an EA framework. Don’t get me wrong. I don’t hate TOGAF. I think TOGAF is great and has probably done more to bring architecture to the fore in IT than anything else and for that I applaud it. TOGAF dovetails nicely with PEAF actually. Use PEAF to bring in EA and TOGAF to carry that down into IT.

It sounds like currently your USP is your agility, which is great for now, but as you grow in size and complexity that speed of change and ultimate flexibility will turn from a virtue into a millstone.

As you say, with v9 it is becoming more EA but I think it still has a long way to go.

────────────────────────── @Ritesh: “EA leads to BPM and vice versa.”

Comments Processes sit at the heart of any business and therefore any enterprise.

(Although in many cases, unfortunately, inflexible IT sits at the heart and business processes have to sit and adapt around them!) Since processes sit at the heart of the enterprise, they also sit at the heart of EA. The purpose/aim of Business Process Management (BPM) - the discipline - is exactly the same as the aim/purpose of EA but it comes at it from it from a business process perspective, recognising that business processes are not just things people do, but are strategic assets and should therefore be treated and managed as such.

The fact that business processes do not or may not relate to IT is of no consequenze toe “true” EA as it covers everything even it its not related to IT. @Konstantin: “business process analyst and process owner should be aware of any minor detail of a business process...” Agreed. @Konstantin: “BPM is not a part of EAM, these are two separate management disciplines touching the same assets of an enterprise.” So therefore I would agree with your devils advocate view - EA therefore provides the big picture/context to BPM as it does to ITSM, the stack/relationships in terms of levels of detail therefore are like this… +-----+------+

Some people see BPM and EA as two sides of the same coin, one coming at it from the people perspective and once coming at it from a technology perspective.

119

Personally I see EA as encompassing BPM. EA = BPM + ITSM + Culture???

+-----+------+

| BPM | ITSM |

──────────────────────────

@Konstantin: “Seeing how EA is implemented in practice, I would rather call what is actually practiced as an Enterprise IT Architecture.”

I agree that many people implement/confuse EA with EITA but I am speaking from the pov of view of “true” EA. i.e. breadth not depth of the entire enterprise. @Konstantin: “why should an EA architect bother about low-level details of business processes, larger part of which is not anyway related to IT at all?”

Some may say BPM overlaps with EA because it also covers the high level context as well. ────────────────────────── @Konstantin: “I call your true EA as a "Holistic EA", but even Holistic EA does not encompass BPM, because these 2 different management disciplines have different objectives (sure on top they have the same goals of any enterprise - revenue and ebita).”

OK - but names aside, I don’t think EA encompasses BPM, i.e. I don’t believe that EA is composed of BPM. I believe its more to do with context.

Regarding low levels of business processes absolutely agree, this is an important distinction I think you make. EA is not concerned with the low levels of anything including business processes, whereas BPM is concerned with the low level processes.

+-----+------+

@Konstantin: “While BPM strives for operational efficiency in business lines, Holistic EAM supports a coherent

120

Comments =============================== ==========

Yes - I would agree about that, an striving for operational efficiency is a laudable objective but this has to be tempered I believe by transformational efficiency. These two can be, and often are, in opposition - i.e. the more efficient you make something operationally the more difficult (and inefficiently) it tends to be to change it, and being able to cope with change is probably the most important driver for businesses today.

The Past

enterprise-wide strategic change addressing company mid and long term targets.”

Operational efficiency (whilst still important) is the drive of the last century. Operational Efficiency (along with others things) is the drive of the new century.

Operational Efficiency (also referred to simply as “Efficiency”)

------------

Efficiency of change was not really important at all because things didn’t change very much. Enterprises tended to do produce the same products in the same way using the same people and the same tools for long periods of time. Things that could change which would require the enterprise to change only changed very slowly. When an enterprise did need to change (since processes were largely carried out by people who are extremely easy to change) it could make those changes very quickly by telling those people to do different things, by employing more people or by sacking people.

============================= The Past

------------

The World Today

-----------------------

In the past, operational efficiency was a key business driver and differentiator.

This led to production lines, mechanisation and automation The World Today

Those that can will grow and prosper. Those that don’t will succumb to those that do.

-----------------------

In today’s business world, efficiency is still important.

Enterprises today exist in an environment of constant and fundamental change, and therefore enterprises need to be able to adapt and change quickly to cope with this maelstrom.

operational

However, as enterprises have got more and more efficient in this area the scope for further gains is reducing.

Transformation Efficiency (also referred to as “Agility”)

In addition, because of a lack of attention to Transformational Efficiency, operational efficiency has been slowly and quietly adversely affecting Transformational Efficiency.

When an enterprise needs to change today it cannot rely so much on the limitless adaptability of people to effect that change.

Comments

Transformational Efficiency is becoming, and will grow even more to become, a key business driver and differentiator. This importance continues to grow year on year.

1. delete all style="font-family:Arial"> all other SPAN’s

<SPAN

delete all

and

My response is the EA does not make a bank, a bank. EA makes a bank, a better bank.

A more agile bank.

5. change all MsoNormal styles to Answers

A more durable bank. EA.... (from the 160 challenge) …increases the banks effectiveness, profitability, customer satisfaction, competitive edge, growth, stability, value, durability, efficiency and quality while reducing costs and risks.

6. change all ^p&nbsp; to <HR>

Classic words I have also heard before by dinosaurs who have drunk too much port!

A more efficient bank.

shareholder value around here?', a bank executive once asked. "

A more effective bank.

3. delete all &nbsp;^p

121

Change all @ to

──────────────────────────

@George: "Since TOGAF includes a business architecture component, why would it not be applicable to EA as well as IA? "

Just because an EA model covers some business entities does not make it an EA framework.

It is applicable to EA but it's not an EA framework. It's an IT frameowrk with a business component.

Organisations can compete without it, but those that do will get leaner and meaner, and at some point those that do not utilise EA will either bite the bullet and start to utilise it, or they will, liked the dinosaurs die out because they failed to adapt to a changing environment. EA is very, very much alive. The few organisations/government who understand it are making massive gains on those that do not. EA is also set to get ingrainined in the new generation of graduates also..... http://ea.ist.psu.edu/index.html ──────────────────────────

──────────────────────────

@Mogorosi: "'i ran this bank without EA for 15 years; how is EA going to get me more corporate banking clients that drive

@James: "Is there a relationship between Enterprise Architecture and Organizational Transformation ?" Yes.

122

Comments

EA is a discipline and cultural change for an organisation.

EA does not (should not) introduce a whole new set of processes, people, structures, processes, etc, etc. EA makes subtle changes to the existing organisation.

It's almost like fine tuning something not creating something...

...better enabling it to respond to change and increasing its effectiveness, profitability, customer satisfaction, competitive edge, growth, stability, value, durability, efficiency and quality while reducing costs and risks.

──────────────────────────

See the "Tool - Evaluation" document at http://www.pragmaticea.com/peaf-products3model.htm which compares 26 different EA Tools. ────────────────────────── @Deborah: "Kevin, I have to disagree with you on this statement - EA does not (should not) introduce a whole new set of processes, people, strcutures, processes, etc, etc......It can do this if that is the strategic objective " Ahhh - I see the confusion here - we are taking about two different things, and I think it's my misinterpretation of the question that is at fault. There are two things here: -

@Yves: " Given what EA tools do today, what is normal effort to keep the EA repository content up-to-date for a mid-size enterprise ($7B, 320 apps, 25 on-going projects, $50M in projects)?".

@Yves: " What is realistic to expect in terms of what EA tools do well and what they should but don't do well?"

The effort to keep an EA repository up to date is a function of the complexity of the enterprise and it's rate of change, so it's not possible to give you an answer. However, I would say the important things to recognise are: 1) There should be no 1 group that is responsible for updating it.

#1) The act of implementing the changes required to adopt Enterprise Architecture Processes and practices. My statement " EA does not (should not) introduce a whole new set of processes, people, structures, processes, etc, etc " is directed towards this context. #2) The act of implementing the changes required for an organisation to meet its strategic objectives. Your statement " It can do this (introduce a whole new set of processes, people, structures, processes, etc, etc) if that is the strategic objective " is directed towards this context.

3) Updating their parts of the model should effectively cost no more effort than is currently spent updating the information they are responsible for, the onlt difference is that they are all contributing to one centralised store of information about the structure of the enterprise.

@Deborah: "I would not expect an EA team to do this when there is no strategic driver but even with the implementation of a large enterprise system like ERP you may also have to create roles, structures and processes. "

2) Different parts of the model should be "owned" and updated by different groups of people; finance, strategic planning, business units, HR, IT, etc….

Absolutely agree.

──────────────────────────

Comments

@Michael: "Is there any guidance on deriving meaningful dollar values for Enterprise Debt Value and Ratio? The PEAF material isn't detailed enough. I thought I'd ask here as others may be interested." Apologies for not responding sooner but I have been buried in various other discussions and issues…better late than never! Enterprise Debt Value is calculated whenever a change is contrary to accepted principles. Not complying with a principle will create issues (things/problems that will occur) and risk (things/problems that may occur).

where you are on the curve so you can transfer to better tools as required. Have a look at the graphs on pages 7 and 8 of http://www.pragmaticea.com/displaydoc.asp?DocName=peaf-model-toolrationale ────────────────────────── @Andrew Galletly: “ Togaf does state that the inputs to the Architecture Vision "such as the enterprise mission, vision, strategy, and goals - have been documented as part of some wider business strategy or enterprise planning activity that has its own lifecycle within the enterprise", however, they are still an input and as such form the scope of any subsequent architecture work. Is the omission of this Business Context-type work your rationale for stating Togaf is not an EA Framework?"

The debt incurred is simply the dollar value of what it will take to either solve any issues introduced or to mitigate any risks created (the residual risk remains) These dollar values will of course be estimates.

Enterprise Debt Ratio is not a dollar amount figure as its a representation of the ratio of the work on each project in terms of strategic vs tactical vs remedial.

123

Yes.

But that’s not the only difference/reason why I say TOGAF is not an EA framework.

The figures are important, but what is more important is that this debt is being exposed instead of hidden. Once it is exposed it can be discussed, evaluated and managed.

As soon as you get down to project level work, it's not EA. EA does exist at that level but only regarding governance and the identification and management of Enterprise Debt.

As time goes by the dollar amount of the issues and risks raised may change as other things in the enterprise changes, this is part of managing the debt.

EA is much much more about strategic planning and about connecting the entire breadth of the enterprise but not the depth. EA (IMHO) is a cultural approach.

──────────────────────────

You can have a look at how I contrast TOGAF with other EA frameworks at http://www.pragmaticea.com/displaydoc.asp?DocName=peaf-overview1framework-comparison

@Esther: “I think it is good to start with Excel, Visio and the like." I agree, but as the complexity and volume of information increases so the ability to use the information decreases and the time required to maintain it increases.

Page 10 gives you a comparison using 6 axes.

At some point you reach a cross over, and it's a good idea to a) know that a cross over exists and b) make sure you are aware of

──────────────────────────

dimensional

124

Comments

@Michael: "Is it fair to say that the purpose of the "enterprise debt" concept is to ensure that while tactical or other imposed constraints may restrict movement towards strategic goals in the short-term, that executive focus does not stray from the strategic direction for too long. i.e. it's a constant reminder of the need to progress along the strategic axis (or to change the strategy)." Yes. Couldn't have put it better myself apart from changing " or other imposed constraints may restrict movement towards strategic goals in the short-term" to " or other imposed constraints WILL restrict movement towards strategic goals in the short-term"

It's a bit like buying a car - if you buy a car for what you think is a pretty good price, but then find out that the tyres need changing, the brake discs are worn and the head gasket is blown, then thatâ&#x20AC;&#x2122;s all inherent debt that you were unaware of and would have reduced the price had you known. Of course, with cars people check these things, its all pretty simple and easy. The problem is organisations these days are massively complex things and the debt (especially because its usually not physical) can be very difficult to spot. @Michael: "Assuming we have a project accepted and delivered which has generated some enterprise debt, how is that debt either paid off or written off? Should each project be analysed for its potential to reduce enterprise debt (as well as to increase it)?"

@Michael: "If the above is a fair representation, then enterprise debt can be seen as representative of the effort required to "get back on track" after an expenditure of tactical effort not aligned with the strategic direction. In that sense, could the value be used in a forward planning/budgeting sense over the long-term?

finds is usually only 30% of the inherent problems (debt) Having companies forced (through legislation in the future) to expose this currently hidden debt will only help everyone in the long run.

Absolutely. Review of EDV during annual Strategic Planning informs and makes the business review the "damage" caused over the last year, with the business deciding whether to do anything about it in terms of their re-evaluated target state and the projects and programmes they select for the coming year. @Michael: "Could the concept be developed far enough to appear in financial reports or even on the company's "balance sheet"?"

It is a debt. It's especially pertinent for companies being taken over or wanting to take over othersâ&#x20AC;Ścurrently some kind of "due diligence" is done to asses the other companies IT and general health, but what it

In addition, as I wrote above, annual Strategic Planning also has a remit to review and reduce EDV (if the business wishes to). This may be in the form of a specific project to specifically deal with certain EDV, or adjustments to many projects.

Absolutely! That was the prediction I made 18 months ago. See Slide 21 in the "EA EDV" slideset at http://www.pragmaticea.com/peaf-products2culture.htm

Yes all projects should always look to the greater good of the enterprise where possible and this included being aware of all current EDV. This kind of work is usually done but the Architect on the project as the PM and the BA are usually blinkered big time (as it should be). Additionally all projects are reviewed by the EARB who's remit is also to look for opportunities to minimise, reduce or eliminate EDV so if it's not happening at the lower level it should get picked up at the higher level.

@Michael: "From a process point of view, the approval of waivers (from EA principles) is the mechanism for registering enterprise

Comments debt, but at what point (and how) should we assess whether a project reduces enterprise debt?

That is part of the process of managing EDV which is the remit of the EARB. @Michael: "Which brings me to the enterprise debt "register". What should be recorded here in light of the above?" The EDV Register is a high level summary of all the waivers including the cost of compliance and the cost of non compliance. e.g. A Wavier is a statement of EDV, the EDV Register is just a register of all waivers indexed by project, business area, etc. @Michael: "Is it asking to much for a worked through example?"

Actually I see Management Consulting and EA as extremely close bedfellows. When I say EA I mean "true" EA - tEA! That is, strategic planning. In terms of the qualities someone who purports to be and EA has…This is my list, and I think it's probably identical to the traits of a MC… Pragmatic ======== They are always looking to understand what the perfect solution can be but tempering that with a more commercial and tactical view that relates to the realities of getting things done. Enthusiastic =========

I guess it's possible, but would just take time to put together. If you can start to record EDV (i.e. Waivers) then you will have the beginnings of the whole circular process…..

125

Strategic Planning -> Current State + Target State + Current EDV -> Intermediate States + Principles -> Project and Programmes -> Waivers (EDV)

This doesn't really give you the full effect of the lifecycle of EDV - I feel a visio diagram coming on….I'll let you know when I've created it…

@Michael: "Overall, I would say that (subject to some more refinement), the concept of enterprise debt has the potential to be a real game-changer in EA. The combination of simplicity and power reminds me of Roger Session's work in measuring "solution complexity". Keep up the good work." Thanks. Any improvements, let me know. and keep the questions coming!

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

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

=======

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

Persistent

──────────────────────────

@Lisa@ "What do you envisage the demand of an EA in the industry? Can people jump from being an EA to a Management Consultant?"

========

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

126

Comments ========

=======

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

Strategic

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

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

========

Abstract ====== They abstract levels of detail to a higher levels to aid understanding and to see relationships and patterns. Expose ====== They seek to expose pertinent information to business leaders to enable them to make more informed decisions.

Open

Facilitate

====

They are sensitive to other peoples drivers and the political context.

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

They have a Broad base of technical and business experience. Persuasive =========

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

Investigate

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

====

The lead, motivate, inspire and enable others to reach their potential and create the environment where people want to follow them. ────────────────────────── @Michael: "If a project is cancelled prior to development starting, should we add the cost of the project to the EDV? (I'm guessing yes)"

No - EDV is a measure of the inherent debt that exists. Any waivers that the project had created however get closed and therefore EDV would decrease (assuming there is >0 waivers for that project)

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

=======

Any money spent on the project that was cancelled is just wasted money - its not a

Comments debt because you haven't broken any principles because you haven't done anything.

@Michael: "Is it possible for the EARB (in response to a waiver request) to find the proposed increase in EDV unacceptable AND to decline to provide resources to avoid the need for the waiver (i.e. to do it right?)." No - they are mutually exclusive.

In a perfect world the ratio would be 100:0:0 - i.e 100% of the work on projects executing is strategic work. i.e. we are satisfying all our strategic objectives, there are no panics and fire-fighting to do. In the worse world, the ratio would be 0:100:0 - i.e. 100% of the work on projects is tactical. i.e. we are coping with today's problems but completely ignoring the strategic goals. In the real world the ratios will never be this extreme. In the pragmatic world, but capturing and then monitoring these ratios over time is important. Example ====== Let's assume a company that doesn't do EA very well. (All companies do EA but most do it really badly). They are locked in a firefighting spiral where 99% of the company is fixing operational problems. There no time to do anything right, everything is rushed, general planning is very light. Strategic planning is almost non-existent becauseâ&#x20AC;Ś

The EARB will push a project to not create/increase EDV. If agreement cannot be reached and the project (i.e. the PM and the project board) will not or cannot comply with the principle(s) in question then the EARB, if they feel it is warranted, will escalate the waiver to the SIB (who own strategic budget - the EARB holds no budget) for the SIB to make a decision. the SIB will look at the waiver which defines the costs and risks of compliance vs the costs and risks of non-compliance and will make a business decision. If they decide to accept the waiver (non-compliance) then the Waiver is accepted and EDV is created. If they decide to reject the waiver (compliance) then they release the resources/funds/time/scope that the project needs to comply with the principle.

@Michael: "I'm guessing that they are mutually exclusive states. (Its why I asked the previous question - to force exclusivity). Either fund the "right way" or approve the waiver. Right?" Correct. You either give a project what it needs or you document and accept the debt.

"We don't have time to think about all this airy fairy strategic stuff. I've got important fire-fighting to do which is more important than you talking to me about strategy and what happening in 5 years!! You want me to think about upgrading my car for the future??? Are you mad? The car is in the river <pauses for dramatic effect> and the only thing I want to think about is how to get it out" Problems that are approaching do not get dealt with until they become problems. And those problems do not get dealt with until they become bigger than the biggest problem that is being given all the money and resource.

@Michael: "Also, I'm still a little fuzzy on the purpose of the EDR (ratio) metric. EDV is clear - literally a balance sheet item. What am I suppose to get out of EDR that I'm not seeing out of the EDV value and its trend over time?" EDR is a representation of the current project portfolio.

127

128

Comments

Now, let's say that this company adopts EA (let's say they use PEAF as their methodology!)…

PR Year 1 - Their annual strategic planning is a little better, they start to consider more (because they have been given some more resource and more time because it has been accepted that this is a good thing) their target state and how they may move toward it. And they decide on a portfolio of projects and programmes for the coming year. However, because this is only their first year (iteration) they still have to deal with a lot of short term tactical problems and issues and therefore the EDR of this years portfolio is 90:10:0.

i.e. strategic and remedial work rising as tactical work decreases - a positive spiral into success. This is all part of the Enterprise Strategy. Or should be. So EDR is used to measure how "good" or "bad" your portfolio is, but also, and perhaps more importantly how it's changing over time. If you could go back in time and document the EDR of many companies, it would probably look something like this… Today -4 years: 25:50:25 Today -3 years: 20:60:20 Today -2 years: 15:70:15

Year 2 - Annual Strategic planning is better than the previous year. This time (because of the strategic work they did last year) they have less fire-fighting to do (although there is still a lot of it) and therefore they can do a bit more strategic work and also, now, a little remedial work to clean up some of the EDV that has accumulated over many years) so the EDR of this years portfolio is 70:20:10.

etc……

Year 3 - They now have more breathing space to clean up a lot more of the EDV so the EDR of this years portfolio is 50:10:40. Year 4 - The EDR of this years portfolio is 30:60:10 Year 1 is a "For God's sake let's start to take control and lay the ground work to give us a bit more elbow room next year

Year 2 is a "Now we have a little elbow room we can do bit more strategic stuff to give us even more elbow room for next year"

Year 4 is a "Now we can really let rip on some good strategic stuff and get some massive returns"

Today: 5:90:5

i.e. strategic and remedial work falling as tactical work increase - a negative spiral into failure. Pragmatic Moral

=============

If you never plan to do any strategic work, you will never do any strategic work. Or put another way, to reap the corn, you first have to sow the seed.

────────────────────────── @Pitagorsky: "The integration of all aspects of the enterprise into an architectural vision is a logical extension of an architecture approach. It is a challenge to make the transition from IT architecture supported by business architecture for use in governance and expense control to a true enterprise architecture that sets a stage for ongoing process optimization. To make that transition, there is need for cultural change."

Year 3 is a "Now we can attack the EDV which will lay the ground work for massive strategic work next year"

Today -1 years:10:80:10

Comments 100% agree.

@Joseph: "Hmmm... what according to you would be an Enterprise Architecture Framework, Kevin? ;-) "

Hmmm…I'll have to get back to you on that one ;-)

@Joseph: "Just look at TOGAF 9 Part III Architecture Principles, towards the suggested Business Principles. All the "Business" Principles seem to be about "information management decisions". I

level and then used TOGAF for the IT and bottom layers. I am an Architect in my heart and therefore I do not like reinventing the wheel. This is why I created PEAF - to fill the EA gap above TOGAF. Future plans were to also create Pragmatic Frameworks for the Solution, Technical and Process Architecture level (the bottom layers) as I have intellectual capital in that area, but since TOGAF fills this space, I am not too enthusiastic about doing so. The only down side I see in TOGAF at those layers is that it needs to go on a diet and become more concise, to the point, usable, for want of a better word….pragmatic. So at the moment I suggest PEAF + TOGAF to people. PEAF to get he ball rolling in the right direction at the "true" EA level and then when things are moving forward and more time and effort can be expended to look at TOGAF to fill the bottom layers.

would have thought the "information management decisions" would be within the scope of Application Principles or Technology Principles. Architecture Principles are a corner-stone for the whole of the Enterprise decision-making agenda. Not all decision-making is about "information management" alone."

129

It is hard (especially if you come from an IT background) to not get drawn into principles that are just essentially IT principles.

In fact I have to eat some humble pie, because the principles in PEAF v1.1 suffered from this also. That is why in v2 a lot of principles have been removed (and will appear again in PSAF and PTAF when published) Out of 30 principles in v1.1 only 17 remain. Yes, some of these still are IT related but the IT related ones that are left are so important I believe they should be set and the EA level.

100% agree.

@Pitagorsky, @Joseph Are you guys related! ;-)

──────────────────────────

Scott: "For several decades we've heard that effective enterprise architecture programs are a critical success factor for medium-tolarge size IT organizations. …..So I decided to find out what's actually working in practice, and what's not working for that matter, in my January 2010 State of the IT Union Survey."

@Joseph: "TOGAF9 has made a lot of progress towards focussing on the Enterprise layer, but there is still a lot of ground to be covered, and some to be discarded. You can't be top-heavy and bottom-heavy at the same time. And TOGAF needs to make up its mind where it wants to be - focus on the details at the bottom layers or focus on the decisionmaking at the upper layers of the enterprise."

@Joseph: "IT ignorant decision makers are a key business risk! But, I am very much saying that IT (and anybody else sitting on sidelines) should not be running the enterprise. "

Agreed. In fact, I tell people that they can use PEAF for the "true" Enterprise Architecture

It's sounding a bit like you in the camp that says that EA is all about IT.

130

Comments

I'm not admonishing you and I doesn't matter to me what you believe but I'd just like to be sure I understand what you mean by Enterprise Architecture. Can you give us a paragraph or two on what you believe the purpose, role and scope of EA is, and is not? ──────────────────────────

@Eugene: “What makes a "Best of Breed" EA team?”

First we have to understand what you mean by the “EA Team”.

We don’t need to go into a massive amount of detail but I believe there are 2 differing views on what makes an EA team and who “does” Enterprise Architecture.

There should therefore be metrics for these 3 areas/phases. These metrics are defined on pages 4-8 of the Metrics document at http://www.pragmaticea.com/peaf-products1foundation.htm In addition, you could also see your question in terms of what qualities the EA’s on the “EA Team” should possess. These qualities are defined on page 23 of the Relationships document at http://www.pragmaticea.com/peaf-products2culture.htm

1) Vertical - A group of Enterprise Architects who “do” Enterprise Architecture. (80% Vertical, 20% Systemic)

Also, this “EA Team” has 3 phases of work they are involved in, preparing to initiate and EA initiative, implementing the changes identified to be able to operate EA, and thirdly operating or “doing” EA.

2) Systemic - Everyone in the organisation “does” Enterprise Architecture . There are some people called EA’s but not many and their role is more to orchestrate and guide and make sure the whole EA community is operating correctly. (80% Systemic, 20% Vertical) My view is that EA is Systemic.

In that case, when I answer your questions I am not viewing the “EA Team” as a small number of people called EA’s but the entire organisation who do the things associated with EA…Strategic Planning, Governance or contribute or use information in the EA models that are used.

I would therefore say that a best of breed EA team is the team that delivers on the metrics defined for their success, otherwise success is subjective. and therefore not measurable.

@Rob: "However, if EA weren't primarily an IT discipline, then it would be indistinguishable from those practices, and the moniker would be misleading. " I disagree.

Without IT, EA still exists - in terms of a thing (i.e. models) and in terms of processes (i.e. strategic planning and governance.) In reality, because IT is prevalent and core to 99.99% of businesses and government bodies, IT is definitely part of the Enterprise. But it's presence does not invoke EA. Complexity invokes EA.

────────────────────────── @James: “Using a social-technical systems perspective, EA is about fostering jointoptimization (see http://en.wikipedia.org/wiki/Sociotechnical_sy stems ).”

@Eugene: “Can this be measured in any objective way? (e.g., % of practitioners with industry certification, conference presentations and case studies, etc, etc)”

──────────────────────────

Comments That’s cool. It’s nice to put a name to my views also.

@James: “For me, EA is about helping the organization to align all its dimensions (people, process and technology) in order to meet organizational visions and objectives” Also agree.

I see two distinct but important areas/levels here…

Secondly there are other things that exist to cope with change. Outside their control

Changes in legislation

Let’s assume for the sake of the scenario that there is never any change. No new laws, no new technologies, no growth, no threats, no opportunities, no need to acquire any companies, no need to increase quality, people do not resign etc, etc, etc. In this world, there is only operations, people and systems doing the same thing over and over again and no requirements or need to change anything. In this world, Enterprise Architecture (the thing and the processes) has no place. Has no reason to exist. This doesn’t mean that there is no EA (the thing). There is an EA because the EA is just the structure of the enterprise whether it has been written down or not, it still inherently exists. I exist therefore I have architecture.

Economic climate change

EA - Enabling Change/ Transformation

Climate change

People wanting leave the company Inside their control

People need to have their training

Reduce cost Reduce risk

EA - Enabling Adjustment EA - Enabling Alteration

EA - Enabling Amendment

──────────────────────────

Salaries and bonuses rise and fall

Now, if we add into the scenario the concept of change…Anything can change. Some things are out of the enterprises control like changes in legislation or threats from competitors, some things are changes within the enterprises control that either the enterprise has decided it wants to make on its own or changes it wants to make as a result of change that is not in their control.

It would follow therefore that the purpose of EA is to enable change/transformation for without change it has no reason to exist.

Threats from competitors

updated

Increase efficiency.

Firstly, there are the things that happen in an organisation that are required to happen in order for it to fulfil it’s objectives. For a bank, for example, things like taking in and paying money out, ATMs working correctly, front office and back office staff processing information sometimes using various technologies from paper and pens to electronic systems. HR making sure people are happy, finance department making sure bills and salaries are paid, IT department making sure that data is flowing correctly through systems and in an out of the organisation, etc, etc. Basically, operations.

131

@Rob: “Respectfully, if the focus is solely on organizational concerns (i.e. no IT), I would just call that classic "business management". EA didn't introduce these disciplines.”

Hmmm.

132

Comments

Now we have to agree on what we mean about “Business Management”

If we take it to mean “Managing the Business” then that is part of EA (i.e. governance - but operationally)

Businesses Management existed long before EA and still continues to do so.

But like a lot of other things, EA does not introduce or replace these things but supports them. Enables them. Enhances them. EA, for example, brings the notion of modelling a set “things” that are connected in complex ways. For you can only change something if you first know what it looks like.

Conceptually think of EA like PRINCE2. Introducing PRINCE does not introduce project management to an organisation. An organisation already does and has done project management for years. PRINCE just allows them to do PM better. @Rob: “As Gerald Weinberg said, "It's always a people problem".” 100% agree.

Type1’s purpose is to effect the changes required in the organisation to allow it to utlise EA to it’s advantage. Type 2’s purpose is to “help the executives who are responsible for those areas?” EA is all about guidance, support and facilitation not about taking decision making powers away from where they should be…in the business. It’s a systemic cultural approach supported but the adjustment of the current organisation.

A big big part of EA is strategic planning. Strategic planning has also been around for decades. So, EA does not introduce Strategic Planning. Every organisation does strategic planning, a lot do it very very very badly though. EA just makes it more effective.

There are two types of Enterprise Architect. Type 1 is responsible for “selling” EA and then effecting the changes required to operate it. (i.e. mitigating the risks, educating people, setting up the Metamodel and tool, setting up governance) Type 2 is involved in the “Doing” EA (i.e. Strategic Planning, Governance, Modelling, Educating, Measuring)

That’s why I say that EA is more about cultural change than anything else. And that is why it’s so difficult to effect the changes necessary to operation it.

Neither do I.

When I said “In reality, because IT is prevalent and core to 99.99% of businesses and government bodies,” I mean it is present in 99.99% of organisations, not that it makes up 99.99% of a business. @Faith “IT can (and should) be viewed as a tool to support the business, not as the business.” 100% Agree.

@Faith: “You can refer to my Synergetic 7 Change Model (a pop-up) at synergeticsolutions.com for a visual” I’ve had a look. Cool! Alignment at various levels and between various levels. That’s EA although you don’t refer to it as such.

@Rob: “In other words, is our core job really about changing the organization's culture, structures, accounting procedures, marketing programs, etc? Or is our job to help the executives who are responsible for those areas? There's an important nuance here I think.”

@Faith: “I do not believe that IT is 99.99% of a business.”

@Faith: “To me it's not about organizational titles and resources; it’s about a way to think.”

Comments 100% agree. ──────────────────────────

@Les: “EA = IT Strategy meaning: Your Enterprise Architecture group is your IT Strategy Group” No, no, thrice no!

EA <> IT Strategy.

EA Group <> IT Strategy Group

EA encompasses the entire enterprise.

The word Enterprise means the entire enterprise not “big” IT. IMHO.

──────────────────────────

crash is imminent or whether they do anything about it, is up to them. Don’t ask me what they say when the car crash occurs because by that time, I have usually been removed or not renewed (“That Kevin - he’s a real loose cannon, he’s bringing the rest of the team down with his negative talk. Let’s get rid of him and all think positive thoughts - that’s what we need to succeed”) and hear about the carnage later from ex colleagues. Whilst the German fable rewards the little boy up the lamp post who points out that the king has no clothes on, in the UK, the little boy is torn from the lamppost, beaten up and exiled. ────────────────────────── @Dennis: "the word viral comes to mind, a small team of thought leaders, who listen, influence, guide and when necessary provide transformational leadership. It's those kind of people, who make up a high performing EA team. "

@Adrian: “A couple of people I talked to thought that it was OK to just make a note of the issues raised and then make a decision without explaining why particular issues were being ignored.”

133

Viral - I like it!

Oh dear me. Yep - I’ve seen that many times too. Power without responsibility. A Guaranteed recipe for disaster.

@Adrian: “By allowing those issues to be ignored we also potentially allow the avoidance of the really difficult questions which generally means that someone else gets significantly more pain later.” Agreed. I have seen that happen so many times now it’s just a given.

EA - “The vaccine organisations….”

for

today’s

Now I have reconciled myself (so I can sleep at night - literally) to making sure the most senior people know of the implications of their decisions. Whether they believe a car

sick

EA - “The immunisation that stops them getting sick tomorrow. ….” ────────────────────────── @James: “I also believe that EA doesn’t introduce anything new to “business management”. My opinion differs with regards to the word “classic”. Classic management is based on a tacit assumption that organizations can be compared to machines. Consequently, divide-and-conquer strategies are promoted both in organizational design as well as task responsibility/accountability distribution. This is to be expected because most “classic”

It used to get me really wound up (that I could see the car crash down the road but everyone else thought I was being too negative).

That makes me think of virus’s with mostly are not good - however, in small doses they are very good - vaccines / immunisation.

134

Comments

management principles date from the industrial revolution. The consequence of all of this is that “classic” management doesn’t take a systemic approach to management (I’m using the term systemic from the perspective of Senge, Demings, etc.). In addition, as stated by Peter Drucker, classic management is about doing things right, it isn’t about doing the right things… that’s leadership. “ For me “Classic Management” has pretty negative connotations in todays world too. It’s too confrontational and master servant oriented for me. I believe today’s goverments and organisation need to, as you say, a systemic approach.

Yes - but it’s my view that, that is one purpose of adopting EA and (initially) having and EA team - to effect the cultural and mindset changes required. I don’t think it’s about introducing a “strategic leadership/management committee” because most companies already have one, it’s just that its not working properly and the reason for that is probably because of the culture/politics. @James: “because of classic management, these units often do not work in collaboration because, driven by a culture of silos, they fight for limited resource in order to do what they believe is “locally” right instead of working together in order to do what is “globally right”. This is also sustained by a tacit assumption that accountability cannot be giving to a group but only to a single person.

I think organisations find things not working and so increase management people are doing what we want so lets force them even more which causes more problems which leads to more management….

systemic optimisation and organizational learning. “

If you have good leadership - you don’t need management. Someone on one of these discussions (apologies for not remembering who it was) said something about an experiment that was done on two groups of IT people. One group had Project Managers, the other “team” did not. The team with no PM’s consitently out performed the “team” with PM’s in time, cost, quality, etc, etc. When I am elected, Project Managers will be first against the wall, along with Travel Agents, Estate Agents and Hair Dressers! You could also probably include people who say they will give you tickets to something and then change their mind ;-)

@James: “EA is probably in IT because IT is always “stuck” in the middle of all the other units fighting for limited resources. Consequently, for IT to function efficiently, it has to compensate for the silo culture… hence the need for an EA team.”

I agree this exists in many organisations but wouldn’t call this an EA team. I know people do and that causes us to go down the “EA is all about IT” rabbit hole again. All it is, is IT trying to take a cross business unit view of the world (note that this does not mean it’s

@James: “If organizations were managed using a systemic approach, there probably won’t be a need for an EA team. The EA team would be replaced by a strategic leadership/management committee with representatives from across all units (IT would be one). These representatives would work in collaboration in order to insure

Agreed. The problem is that the people/groups that need to change the most have the most to lose. Classic management is about building empires, EA is about breaking them apart. The thing is, this doesn’t mean that empires will not exists though. It’s not all doom and gloom for the go getters who want to earn big bucks with large empires. The difference is that those empires should be horizontal/system rather than vertical/silo’s.

Comments strategic as the time component is all too often short term and not long term)

@James: “re: As Scott said earlier, the business should probably drive EA efforts, but this doesn't always happen because they don't quite understand it. It appears that we're sorting it out too ;-) “ Probably???? Not probably. Definitely!.

I agree it doesn’t always happen, the reasons are many, but if IT tries to “do” EA (which is cannot do on it’s own) and calls it EA, then IT, IMHO, is causing “true” EA more harm than good and cementing in the execs eyes the EA is all about IT - it’s just another IT fad that they want us to spend money on and won’t deliver.

@James: “When systemic management will be used, EA will no longer be called EA… it will be just good organizational management/leadership.” 100% agree. ────────────────────────── @Brian: “Enterprise architecture in smaller organizations? One size does not fit all! - I've had a number of discussions lately with smaller organizations that are wanting to get started in EA but struggling with the most popular EA frameworks which are really designed for larger and more complex organizations. Smaller organizations do not have the resources to create a full EA as described in most of these frameworks. My advice to clients is to take a light approach to EA. The key is to apply the resources available in the organization to solve the most important EA issues on the table, and not to try to create a fully fledged EA. Any thoughts or alternative approaches?”

@James: “The business doesn’t understand EA because understanding it would put into question there ways on managing/thinking. IT is trying to sort it out… which it will probably never be able to do because it goes well beyond IT… like you said, it’s about management. “

135

Exactly. The management is the problem, but they cannot/do not want to see/hear that. It doesn’t make them bad people, its just some knowledge that they do not understand which is why I say that EA is all about communication (amongst other things!)

An alternative is to take a Pragmatic approach to EA using PEAF - the Pragmatic EA Framework. It is designed for exactly the purpose you describe. To allow organisations (actually of any size) take their first steps on the EA road.

@James: “I believe that our job is about helping executives make the right decisions from a systemic perspective. Consequently, I believe that IT is just one of those executives…hence EA is not IT. “

It is concise, complete and very pragmatic.

100% agree.

By the way, PEAF is also FREE for End-User Organisations and Government bodies, i.e. those organisations that want to use EA to improve their businesses.

@James: “All in all, yes EA is about people problems :o)”

Have a look at the overview docs at www.PragmaticEA.com to get big picture view.

100% agree.

──────────────────────────

@James: “We are facilitators not decision makers. “

It is only commercially licensed to organisations that want to use it to make money i.e. consultancies, training providers and tool vendors.

100% agree.

136

Comments

@Phil: "Enterprise Architecture enables organizations to execute their strategies by leveraging the capabilities of IT."

PR I believe this is the IT centric view that is causing “true” EA and the understanding of it for many organisations massive amounts of pain and confusing.

Business processes are nothing to do with IT, but leveraging Business processes is also an important part of EA. So you could say…

Enterprise Architecture enables organizations to execute their strategies by leveraging the capabilities of Finance. Enterprise Architecture enables organizations to execute their strategies by leveraging the capabilities of other business units.

@Phil: “If you don't have a picture of what your trying to manage, it is very hard to be successful.” 100% agree. Or to put it another way, how can you change something if you can’t see what you are changing. ────────────────────────── @Phil: “@Kevin: "I believe this is the IT centric view that is causing “true” EA and the understanding of it for many organisations massive amounts of pain and confusing. Business processes are nothing to do with IT, but leveraging Business processes is also an important part of EA."

@Phil: “I am not sure I understand your comment here as the practice of EA is centered around 4 major domains (Business Architecture, Information Architecture, Technology Architecture, Application Architecture). The primary responsibility for three of these domains exists within IT and the process piece of EBA is usually facilitated by IT.”

Enterprise Architecture enables organizations to execute their strategies by leveraging the capabilities of their partners.

Enterprise Architecture enables organizations to execute their strategies by leveraging the capabilities of HR. Enterprise Architecture enables organizations to execute their strategies by leveraging the capabilities of the Strategic Planning department. All of these are too narrow, so, to modify your definition I would say…

Enterprise Architecture enables organizations to execute their strategies by leveraging the different parts of the organisation - is a better definition.

The problem I have with that statement is the “by leveraging the capabilities of IT."

Your comment makes it sounds that EA is only about helping “organizations to execute their strategies” by ONLY “leveraging the capabilities of IT." It makes it sound that only thing EA is about is changing/implementing IT. This is not true.

I still don’t agree with it totally because I think it’s missing a lot (See http://www.pragmaticea.com/160challenge.as p) which collates and analyses 1,200 definitions of EA.

My comment was based on your comment which said “"Enterprise Architecture enables organizations to execute their strategies by leveraging the capabilities of IT.”

@Phil: “Can you expand on why this is confusing and causing massive amounts of pain?”

Comments Because telling people that EA is not an IT discipline and that EA is not all about IT is a constant battle.

137

It is the integration and cultural co-operation and guidance of the entire enterprise that is at the heart of EA.

People (especially business people) completely turn off because they think its an IT discipline and that EA is all about IT.

──────────────────────────

The business people are exactly the people we need to turn on. That’s why it’s causing massive amounts of pain.

@David: “…you will need to de-Tech your definition into terms that answer the question from a business stakeholder "What does it do for me ? otherwise you'll EA will be lost in a sea of despair”

@Phil: “Also, who do you believe in an organization should be driving EA?” There are two “jobs/things” that need “driving”.

100% Agree. Doesn’t the purpose part do exactly that with no Tech… “I can enable your organisation to better respond to change and increase its effectiveness, profitability, customer satisfaction, competitive edge, growth, stability, value, durability, efficiency and quality while reducing costs and risks”

1) Preparing and implementing the changes required to improves the EA products and processes in an organisation. The person who does this is an Enterprise Architect, usually a transitory consultant role, that brings EA to an organisation and gets them set up and working correctly. The person who should drive this is the CEO and executive management team.

------------------------

2) “doing” Enterprise Architecture. There is not one person that “does” EA. EA is a cultural adjustment to the people and processes within the organisation not the introduction of a big new team of people called Enterprise Architects. The person who should drive this is the CEO and executive management team. @Phil: “I believe the reality here is Enterprise Architecture is about the entire organization including IT.”

Is there any Tech speak in that? They then may want to know how……… to which the current definition says… “by Strategic Planning, Architecture and Governance supported by a Decision Support framework in the context of aligning all parts of the enterprise” Is there any Tech speak in that? Only the word Architecture.

@Phil: “IT becomes a strategic enabler of the business by following the practice of EA.”

Again, they may want to know how again….to which the definitions says…

Yes, but not just IT. So does HR, Finance, Partners, Suppliers, etc, etc, etc.

100% agree.

So is it the single word “architecture” the thing you are referring to when you say “you will need to de-Tech your definition”?

IT is special, but other things and other departments are also special.

138

Comments

Is there any Tech speak in that?

Can you point out which parts of the definition(s) you believe to be Tech speak? It’s not a challenge, you have a very good point in that we need to de-Tech things, but I am at a loss to know how to de-Tech something I believe has already been deTech’d!!

http://pragmaticec.com/downloads would like to check.

you

As I said, it was produced after analysing more than 1,200 responses from various people as an attempt to try to bring some agreement and common agreement between a large number of people as to the purpose of EA.

──────────────────────────

@David: “Either way, good luck”

------------------------

Thanks, but I don’t need any luck.

@David: “Kevin.... That statement although not techie is just a list.”

I believe in slogging my guts out for the benefit of a wider community and engaging in positive critical debate to advance myself and the EA profession in general.

Good - I’m glad we agree that it’s not techie, which makes me wonder why you said “you will need to de-Tech your definition”??? @David: “It reads consultant/sales pitch.”

any

other

────────────────────────── -----------------------@Zahid: “Persevere with the "de-teching"”

So what. I believe it describes the purpose of EA. If you disagree I will gladly listen to and discuss your views But only views that will move the debate forward rather than those aimed at scoring points.

@David: “Is this for your CV?”

No it’s not for my CV - it’s the results of analysing 1,200+ posts by a massive number of people on what they believe the purpose of EA is.

As I said, it’s not for my CV. You can have a look at my CV here

@Zahid: "The purpose of Enterprise Architecture is to provide decision-support for direction & change at any level of the Enterprise" I don't have a problem with people ignoring the results of the analysis and creating their own definition, but totally new definitions are the input into the analysis that was done. (and at some point new ones that have been tabled since the analysis will be added) not the way to move the debate forward.

If all we do is ignore the consensus (analysed) definition and start creating (or re-stating) our own we will never arrive at consensus. Your definition Zahid is already encompassed in the analysed definition essentially decision support. This mean you believe EA’s purpose is only that. You are effectively saying EA’s purpose is NOT <all the other things in the analysed definition> are you really sure that’s what you mean?

@David: “If so you may be better turning it on its head.... e.g. by using x,y,z I can help your company achieve a, b or c; ensuring that deeper into your CV you can show evidence of how you used x to achieve a. Evidence is what people will be searching for.. IMHO the list thing (when you've read quite a few in CVs) comes across as blah, blah, blah. I'm currently wading through 25+ CVs and it is evidence that is key, not a generic I can do all things for all people.”

What in the analysed definition do you suggest needs de-teching?

Comments

139

@Zahid: “I don't believe you'll realize the value unless you've understood it's purpose and where it fits in the thing called the "enterprise", who uses it, who does what with it, and who embraces it.”

Your “new” definition also misses the point in that it’s not in the WHY column (i.e. purpose) it’s in the HOW column (how we will achieve the purpose). HOW is important but not as important as WHY because WHY is the PURPOSE and it’s the PURPOSE we are trying to define.

100% agree.

e.g. you think EA’s purpose is NOT “effectiveness, profitability, customer satisfaction, competitive edge, growth, stability, value, durability, efficiency and quality while reducing costs and risks”

There is nothing wrong with your definition above, but you need to be able to see that what you say is already covered in the analysed definition and therefore I don’t see why you would not just agree with the analysed definition rather than @ALL:

That is why I am trying to get a large number of people to broadly agree on the purpose. ────────────────────────── ------------------------

@Frederic: “A good EA team is therefore created from a multi-disciplinary set of people that can transpose signals that are not necessarily visible into a set of standardised models. For example, I can see people capable of discovering (engineering) intimate business processes, another one capable of describing in simple terms "obscur" operational procedures, another one capable of identifying what does not work in a given organisation model, etc.”

People have to understand that in order to arrive at consensus everyone will have to compromise and adjust their favourite set of words and/or definition otherwise the exercise is pointless.

So, we have a definition on the table, the way forward is for people to take that definition and decide what (from their pov) is fundamentally wrong with it, then table a new one that includes a solution to their fundamental problem, not some rhetoric or a long winded monologue. The key here is that people should only be thinking in terms of fundamental problems it is the fundamentals we are interested in here because if we don't concentrate on fundamentals then everyone will differ in their definition in some non-fundamental, and therefore insignificant, way.

I take that one step further, it’s the people you already have in the enterprise - EA just allows them all to work together more effectively - EA is an adjustment of culture and mindset not the introduction of a new team called “The EA Team”. You can view the everyone in the enterprise being part of the TEAM, and what sits at the heart of a good team ? not separate from it but part of it???? tEAm.

@David: “Frederic, One of your comments I almost agree with. "very few people capture the many dimensions of what forms the enterprise." In fact, I would argue that none truly do.”

While I encourage discussion, it is pointless if that discussion just creates more and more unstructured information and we all descend into the rabbit whole of general EA talk yet again.

I would agree with that. It’s a large number of people with different perspectives, views, opinions, information, backgrounds, goals, etc, etc.

140

Comments

I would agree that no one person can capture the many dimensions, this is why that an EA model is a living breathing description of the enterprise that many many people contribute their sphere of knowledge to which is then available for use by the entire enterprise. The sum of the hole is greater than the sum of it’s parts.

@David: “That is why I believe Architects need to stop thinking they are this rare and wise breed that know more than everyone else. They need to start seeing themselves more as facilitators of a common vision - the vision that belongs to the business leaders.”

100% agree. I couldn’t have put it better myself. Very eloquent.

100% agree.

When populating a model, it is absolutely imperative that this be done in a sustainable and manageable way. i.e. when information is placed into the model, either the original source of that information is deleted and the people and processes using that information then directly use the mode, or, some kind of automatic, semi-automatic or even manual processes needs to be put in place manage changes between the two. Without this, all you are doing is adding to the existing problem. The second important area is the population the model - Process The model should not be populated wholesale with every piece of data that can be found. Attempting to do this will take a very long time and therefore not deliver any business benefit for a long time either.

@David: “The Architecture of an Enterprise is the culmination of ideas and efforts of a plethora of people in the organisation”

therefore address - Sustainability. Introducing a tool is actually a data migration exercise.

@David: “The Architecture Team might only be the scribes who are trying to interpret and archive the vision so that it can be passed from executive to middle levels and all the way to clerks.” I think the “architecture team” are not the only people interpreting though, everyone is. Using analysing and interpreting; finance, HR, business managers, IT, Partners, Suppliers, etc, etc. ────────────────────────── -----------------------------------

100% agree. This is one of the most important aspects that many organisations fail to recognise and

Based on the principle that the only reason to build this model is to use it for something, and that "something" is to find answers to questions, each iteration should be composed of short pieces of work that answers 1 or more specific business questions. Depending on the complexity of the question and the resulting volume of information required to answer it, it may be possible to answer more than one question in each iteration. The first iteration (Iteration 0) is starting from an empty model and so choosing the initial question is extremely important because ALL of the information to answer it will need to be loaded into the model because none currently exists. Subsequent iterations should be less and less onerous as subsequent questions can then begin to reuse information that is already present in the model.

@Dave: “I agree with Wyn that an attempt at tool implementation also has to be accompanied with ownership and change management on the part of maintaining the artefacts/assets that are created.”

The process for populating the EA model is iterative.

Comments

For this reason an overall plan should be defined detailing a set of questions in sequence and a high level view of what data will be required in order to answer them. ────────────────────────── -----------------------------------

@Rob: “Kevin ... I hope you don't take offense to any of my responses. They are all proffered with the utmost respect.” Absolutely no problem. I don’t mind if people think I am wrong, all I ask is a chance to discuss and the opportunity to either accept and change my views if they turn out to be inconsistent or wrong, or the opportunity to put my case.

be composed of short pieces of work that answers 1 or more specific business questions. Not getting this right is (one of the many reasons) why many EA initiatives fail dismally. @Rob: “EA didn't invent this. Business folks & IT do it too without training.” IT folks have been modelling for a long time I would admit, but I’m not sure the business has, or not at least to the same degree. Yes, many businesses have a few “models” here and there but I have never seen any organistion that has not adopted EA but still has the business using modelling. @Rob: “re: "If you have good leadership you don’t need management.” - Can you give me a link to that company? Maybe my "old age" has made me cynical. As an Apple Exec once said, there are two types of companies ... those who are just like Dilbert and know it, and those who are like Dilbert and don't know it yet.”

@Rob: “re: "EA, for example, brings the notion of modelling" Plz forgive me ... but this is an inevitable response ... "so EA = business management + pictures".

141

Not pictures, models. Pictures are static and cannot be interrogated and are a nightmare to maintain. Models (or rather the visual and textual views) are essentially reports on the information in the model. And in order to buld and maintain models you need to use tools. And when I say tools, I mean tools that allow you to deal with models not pictures. @Rob: “Modeling is a useful tool, but it's just a means to an end. EAs often spend too much time in this activity. Models are simply a communication device.” 100% Agree.

The model should not be populated wholesale with every piece of data that can be found. Attempting to do this will take a very long time and therefore not deliver any business benefit for a long time either. The process for populating the EA model is iterative. Based on the principle that the only reason to build this model is to use it for something, and that "something" is to find answers to questions, each iteration should

I’m not sure here if you agree with me or not, but in my experience in the UK, this is the case. I can honestly say, the main reason any project that I have worked on has been the due to either the project manager or the management above him. It’s very depressing when IT people tell the PM something cannot be done in time without seriously affecting quality, only to be shouted over to just get on with it, then the system goes live and dies like a dog, only for the PM and senior management to blame the IT people. Really, seriously, generally, management in the UK is fundamentally broken. Yes, there are “good” guys out there and there are some good projects, but the hype always outweighs the actuality. If you do a root cause analysis on failed projects you will find that 99% of the time the failure is with process and not technology, and who is responsible for process?

@Rob: “re: Project Managers - Whether a team has PMs or not, politics and interpersonal dynamics always exist. This is a

142

Comments

part of being human. Strong personalities will dominate unless the group is able to establish and enforce rules that ensure equanimity. This is easier said than done.”

Yes but the problem in my experience is that PM’s are allowed to dominate. Every project I have ever worked on has a project manager leading it and then underneath the project manager sits the architect and the business analyst. Generally speaking, the PM overrules the TA and the BA 99% of the time…this is a recipe for disastrous projects. In order to explain more I need to use pictures, but unfortunately pictures seem to be beyond LinkedIn’s technical barriers! and therefore can I ask you to go and read the “Projects” section in the “Culture - Relationships” document at http://www.pragmaticea.com/peaf-products2culture.htm

Yes - I believe it does. EA is all about exposing information and the implications of decisions so that those who are responsible for making decisions can make better and more informed decisions. I don’t believe management makes bad decisions because they want to. I believe management makes bad decisions because many decisions are actually made in the dark…..the management mantra is…….the only bad decision is not to make one. Decisions will get made. Everyday. Regardless of whether the appropriate information is known or not. @Rob: “Are we more capable than they? I've found, in most cases, these folks are pretty damn smart, know the problems, and choose their paths deliberately.”

@Rob: “re: "The EA team would be replaced by a strategic leadership/management committee with representatives from across all units (IT would be one)." - I've worked with C-level and senior execs for too many years. They all have major egos & agendas, & are master politicians. That's how they got to where they're at.

@Rob: “Does the practice of EA somehow shed more light on their problems?”

Yes I agree (although the quote you are referring to was from James not me - I only commented on his quote.)

But I think his point is valid if only at a conceptual level. If you take the idea that EA is pervasive and systemic (when done correctly) then ultimately his statement is true. Whether politics allows it to happen, and over what timescale however is open for debate. @Rob: “Why do we think that somehow we'll get them to see the light?”

e.g. when Six-Sigma or LEAN, were first being “sold” to management were the people “selling” these approaches more capable than the managers? No. They just had a “tool” that they knew could help.

@Rob: “fwiw, the approach I've found to work is to clue in to what they want, help them realize that goal, & let them take the credit.” 100% agree.

Because we are Architects and therefore we are; Pragmatic, Enthusiastic, Agnostic, Articulate, Persistent, Strategic, Altruistic, Diplomatic, Open, Generalist, Persuasive

No I don’t believe we (EA’s) are more capable than they. If we were in their positions we would probably make the same decisions because we would only have access to the same information. What we (as EA’s) know is that there are processes and products that can help them make much better decisions. These are the processes and products of EA.

@Rob: “However, also I've found that it's all too easy for an EA to lose credibility with their constituents because they can't possibly be experts in everything, yet they are expected to provide leadership for specific

Comments

business domains and IT concerns. This is really hard to do when your constituents (i.e. the business or IT) live and breathe this stuff each and every day. How can an EA ever achieve their level of competence in the areas they concentrate on?” This is because this is exactly how NOT to do EA and exactly what EA is NOT about! EA’s do not make decisions. EA is all about exposing information and implications so that the business people can make better decisions/ This is why I say that EA is NOT about employing a large team of people called EA’s.

Rob: “As for the IT side, well, they specialize in finding chinks in the armor of any proposal.” Well, yes, that’s as it should be. The further you get into the world of IT the less black and white things become and you could say that IT is all about finding problems because if they don’t the customers will. @Rob: “The following video provides some insight into the IT perspective, but you'll have to sit through 10 minutes or so before the point becomes evident.” I think the biggest point they raise (and they raise many good points a lot of which I have thought for many years) is to accept that change is inevitable. Not a new thought by any means, (“The only constant is change”) but the thought that we need to work in ways that not only accept that change will happen but also embrace that change and making change, and the ability to change, systemic in systems, processes and people.

EA’s and EA models provide a context and visibility of the entire enterprise at a high level of it’s constiutuent parts and (much more importantly) the relationships between these parts. It’s like a spiders web….if I “wiggle this bit” what other parts “wiggle”. If I remove this part, what oher parts collapse, in what ways….etc, etc.

143

@Rob: “EAs can often spot problems that span business divisions, departments, etc. They can also propose high-level solutions to these problems.”

Yes because even without formal models, as architects they have intuition and can see a car crash many miles down the road.

@Rob: “The real test occurs when you are probed for how to turn your grand solution into an actionable plan. This is where things can fall apart. The business folks may find flaws in your approach.”

────────────────────────── ----------------------------------@Mark: “Enterprise architects design a building that is robust enough that it can be used by the business to develop and enable future capabilities and yet efficient in how it supports the current capabilities.” I’m not sure I agree withy that. In 99.9% of cases the building already exists.

Yes, this is why I say EA is all about exposing the problems and implications of decisions to the management for them to make better decisions. It’s about creating the environment for them to find and see these problems themselves. People will never agree to anything if they do not see or believe the problem, therefore we must concentrate on exposing the problems for them to understand there is a problem - only then will they take avoiding action.

I agree and that is one of the tenets of EA (IMHO) in that the ability and efficiency of change has been not recognised or prioritised correctly by the business and EA is trying to make that a goal in the same way that operational efficiency is always a business goal.

The role therefore becomes more one of someone who cares about the entire building and wants to make the decision makers aware of how their (potential) decisions affect the building.

144

Comments

I don’t see Enterprise Architects as people who design stuff. I see them more as a supporting those that do effectively implicitly design it by their decisions and actions and making them aware of their actions. For me EA Nirvana is when everyone in the organisation has a little Enterprise Architect inside them, thus EA is part of the culture, not in the hands of a select few who call themselves Enterprise Architects. That doesn’t mean that there are no roles called “Enterprise Architect” however.

But then people would probably say that its too high level, same old words etc etc. One of the problems, I believe, in defining the purpose of EA is that on the one hand a definition can sound too detailed and in need of simplification, but then when it’s simplified it becomes too high level and people want more. Having said that, and as I stated in my points to Mark, decision support (strategic decision support) is a very good definition I think.

@Bo: “Although being late to the party I still want to present my view on the purpose of EA, fairly easily explained to managers and opening up for further elaboration on 'how', 'when', etc.: “

──────────────────────────

No problem - but next time, can you bring a bottle? (Johnny Walker Black Label will do nicely!).

Hey - if you don’t agree with something you gotta let it out dude!

@Rob: “I'm everything”

not

sure

agree

with

@Bo: “we don't create real value unless we (the decision makers) make good decisions”

I don’t agree with that. we (Enterprise Architects) do not make decisions. The business (aka management) does. The minute the business hears Enterprise Architects say that they will make decisions is the minute they ring security. (unless they have devolved some decision making powers by proxy of course)

@Bo: “The purpose of Enterprise Architecture is to continually supporting decision makers in making high quality, holistic decisions which enterprise stakeholders will have to live with for a long time"” Blimey! I like it.

-----------------------------------

@Rob: “It's interesting that we all bring a perspective of EA that is coloured by our own unique experiences. I think the danger here is that we may start to think that our view of EA reflects "the way the world is".

Yep - that’s one of the reason I issued the 160 challenge (see the postings and analysis at http://www.pragmaticea.com/160challenge.as p) The main things that I gained from doing that was the reasons why people fins it so hard to agree on the purpose ot EA…namely… Split of Why, How, and What ======================

Of course, I (being an architect and therefore always have to put my mark on something) would reword it slightly to “The purpose of EA is to support decision makers in making decisions”

Seriously, that’s how I grow - by hearing when people disagree with me. Some people grow with a pat on the back. I grow by kicks up the pants

Why 26%, What 31%, How 43%

Observation: As can be seen, there is generally speaking an equal split between those who define EA in terms of its purpose

Comments

(WHY), those who define EA in terms of “doing” it (HOW) and those who define EA in terms of what things are produced or used (HOW). Problem: This is the first thing that can confuse the issue when people are discussing or trying to understand what EA is because at any one time three fundamentally different things can be being discussed as if they were the same thing. Lesson: Any definition we create or discussion we have should always address these three perspectives. WHY Split

========

Observation: In general terms the same small number of actions are put forward time and again. There is no “clear winner” to speak of with all being tabled generally equally. Again, it is not that one of these is correct but they all are. Problem: This is the third thing that can confuse the issue when people are discussing or trying to understand what EA is because in general a person will list 1 or possibly two, maybe occasionally even 3 of these but never all of them. Again, this means that any one person only has a piece of the overall picture. Lesson: Any definition we create or discussion we have should always address this fact and any argument and counter argument about some of these things is futile. Let’s stop argueing about which ones are addressed and agree that all of them are valid.

Mission, Agility, Efficiency, Costs, Effectiveness, Value, Durability, Growth, Profitabillity, Competitiveness, Customers, Risk, Stability, Quality.

145

Observation: In terms of why people think we do EA and it’s purpose, there are many different ideas. The truth is that not one of these is correct but they all are.

WHAT Split

Problem: This is the second thing that can confuse the issue when people are discussing or trying to understand what EA is because in general a person will list 1 or more of these things but never more than 5. This means that any one person generally only has a piece of the overall picture.

Observation: It can be seen that the vast majority of people think of Models as the main artefact or thing to be used when thinking about EA. Processes are also very well represented. Again, it is not that one of these is correct but they all are.

Lesson: Any definition we create or discussion we have should always address this fact and any argument and counter argument about some of these things is futile. Let’s stop argueing about which ones are addressed and agree that all of them are valid

========

Models, Processes, Guidance, Tools.

Problem: This is the fourth thing that can confuse the issue when people are discussing or trying to understand what EA is because in general the vast majority of people will only talk in terms of models, which only represents 50% of the whole. Again, this means that any one person only has a piece of the overall picture.

HOW Split

=========

Decision-Support, Strategic-Planning, Architecting, Governance, Alignment.

Lesson: Any definition we create or discussion we have should not be about models to the exclusion of processes, guidance and tools. ──────────────────────────

146

Comments

-----------------------------------

@Bo: “The (more?) correct wording should be "we don't create real value unless the decision makers make good decisions"

Yep - I did think that you had probably just worded it wrong (or that I misinterpreted. We are on the same hymn sheet.

@Bo: “Well, I hope you're not being sarkastic here” Nope. I am not being sarCastic either ;-) Sorry - but you did set that one for me to hit out of the park. Actually, I can be a pretty horrible sarcastic sob (I know because my wife tells me) but not this time. To be honest though, I think your English is probably incomparably better than my Danish!

“The role of an Enterprise Architect is to ensure that such an inherent property is nurtured and protected.” - Bo Klausen Big pat on the back. I think your thinking and the thinking of Pragmatic EA and PEAF are very much in line. ────────────────────────── ----------------------------------@Oana: "but I am still to discover which tools are best to use for modelling rows one and two. Methodology wise"

@Bo: "... continually supporting decision makers in making high quality, holistic decisions which enterprise stakeholders will have to live with for a long time. We do this by Strategic Planning, Architecture and Governance, using Models, Guidance, Processes and Tools."

“The purpose of Enterprise Architecture is to continually support decision makers in making high quality, holistic decisions which enterprise stakeholders will have to live with for a long time by Strategic Planning, Architecture and Governance, using Models, Guidance, Processes and Tools.” - Bo Klausen

Yep - its keeps the parts in the original that I think are still good but you’ve changed the WHY part - and I think you’ve made it better.

@Bo: “I concur with that! This is what I hint at in "...applies to all levels in an enterprise where decisions with far-reaching, long term effects on stakeholders are made" although only addressing decision makers. And having dedicated Enterprise Architects should ensure that such an inherent property is nurtured and protected.

I like that too. I think you have really helped move this on. Really…. To re-state your words…

So I would therefore say your question should not be what tool is best to model rows 2 and three but which Metamodel can I use to model rows 2 and 3.

But again, I would ask you - what business question are you trying to answer by your modelling? Tell me the question(s) and I will tell you the Metamodel that is required to allow you to populate the model with the information your need to answer the question(s).

Absolutely... The role of an EA is to “ensure that such an inherent property is nurtured and protected.”

Most of the tools (not all) are completely Metamodel independent. You can model anything you like. From this poit of view any tool that allows you to create/augment the Metamodel will be able to model the domains in rows one and two of Zachman.

One more thing I would add - don’t be fooled into thinking the EA is only about modelling. Communication is the key, and if you are not expending as much money/time on communicating what EA is and how to “do it” to the stakeholders and everyone

Comments else in the organisation as you are on modelling you are doomed to failure.

Have a look at the EA Risks document at http://www.pragmaticea.com/peaf-products1foundation.htm. Are you mitigating these risks? And don’t forget, collecting the data is the easiest thing to do. Integrating or subsuming the sources that produce it is a million times more important unless you don’t mind the data you put in your model turning into shelfware in a month or two. ────────────────────────── -----------------------------------

I agree.

Yes, but I believe it is deeper than that. And understanding and working with the differences in outlook is where Enterprise Architects can add value. See Page 12 - “IT and the rest of the Organisation” of the Culture document at http://www.pragmaticea.com/peaf-products2culture.htm @Stephen: “If IT is providing a service to the rest of the organisation, i.e. the rest of the organisation is an internal client, why do IT insist on speaking their own language?” EA (the products and processes) is (should be) the language that allows “the business” and IT to communicate effectively. (If EA is being used and being sued effectively) @Stephen: “The business doesn't want to be "aligned", they want to achieve their business goals. If IT as an "enabler" gets in the way of that, or can't help them, IT deserves to be ignored...”

@Rick: “In the past year I have come to the decision that so many people think tools first and framework second it is likely Zachman will be relegated to the theory and education arena whilst tools friendly software/methodology packages such as TOGAF continue to gain market share. I saw that first hand last year with TOGAF 9. My analogy is in relational databases. I liken Zachman to Dr. Codd’s relational model and TOGAF to Oracle’s implementation of SQL.”

There is another way though., If Zachman is Dr’ Codds relational model, and TOGAF is Oracles Implementation of SQL, you can think of PEAF as the glue between them. ────────────────────────── -----------------------------------

I agree, and this is what happens in organisations that do not level EA products and processes effectively. Without EA the business cannot control IT effectively and loses faith in IT. The business and IT become frustrated partners in a marriage they cannot be divorced from. Usually in that situation the only control mechanisms the business has is time and money. That’s why they rely on Project Managers so much, time and money is continually limited and the processes that IT need to follow to work effectively for the business are paid lip service to with, often, disastrous results.

The number of times I have heard the business (directly and through the PM) asking IT “Why are you doing it that way?, why will it cost so much when I’ve seen a pretty application that will do what I want for 1/10th of the price is in the hundreds?” etc, etc, etc. And when they do not understand the answers (why should they) or do not believe them (because they have already lost

@Anandasubramanian : “Its the difference between what Business Wants and what Business Needs. IT expects fixed requirements, sign-offs, and baselined functional specifications. Business wants a system that closely mirrors what they are doing manually. Business needs a system that improves their system by a large magnitude. This is where the conflict is.”

147

148

Comments

trust in IT) they ignore IT and restrict timescales, resource, scope, process and money.

PR How crazy is that ? If you employed a bricklayer to build a wall, would you then tell him how to build the wall? If you asked him why he was building it a certain way, would you understand his answers about load bearing points and footings and the exact composition of the mortar?

I do not blame the business for this though. It’s not their fault because they don’t know any other way to control IT. (unless they utilise EA) The PM has become (and it is widely accepted) the conduit between the business and IT. It is my firm view that this is totally wrong. The interface between the business and an IT project should be an Architect.

Con-Fused as in melted together, alloyed, etc." So... If your organisation is confused, EA can make it Con-Fused! ────────────────────────── @Rajat: "What practical steps can be taken to avoid EA becoming too 'artifact' centric and sustain focus towards concrete outcomes?" Concentrate o the key processes. Identify what they are and then (as with everything to do with EA) those processes are put in place and communicated effectively to those that operate them.

For example, the main artefacts of EA are the EA models, however if you get the process wrong the artefact is likely to be useless, i.e. pick a question you want to answer, determine the information you need to answer it, gather that information, populate the model, integrate the information or replace the data sources, answer the question.

That thought however is way too radical for 99.999999% of organisations, so what are we left with. How can we allow the business to have reasonable and proper control of IT?

The answer is Enterprise Architecture in general and Enterprise Debt (or rather the exposure and management of it) in particular.

This process is iterative.

I think we also should see EA not as bridging the gap between the business and IT but between strategy and execution. IT is definitely part of execution but not the only part.

──────────────────────────

@Nic: “’Glue’ implies too much close connect with execution for my liking, but i have swallowed worse things in my life.”

@Erik: “Really? I can think of many things of being the glue between strategy and execution but EA? Can you give some body to your quote?

────────────────────────── @Nic: "It is where we get con-fused (as in amalgameted) with other things that practioners loose their forward momentun. -

@Bob: “I gotta second Erik in wondering where the "body" is to backup that quote. It's pithy and it sounds cool, but IMHO it doesn't ring true. How is the practice of EA the "glue between strategy and execution" in a way that other, more traditional disciplines aren't? What, if anything, makes EA unique?”

EA is the continuum/process/doctrine/linkage/balance/ culture between Strategy and Execution?

@Kevin: “EA is not the glue between IT and "The Business". EA is the glue between Strategy and Execution. ”

Comments

149

thing which the board really doesn’t care about, and concentrate more helping the board to formulate and execute its strategies.

For many years, when people have be trying to explain what EA is, does, and where it sits, it has been described as bridging the gap between “The business” and IT, where “The Business” is everything else that’s not in IT.

This is why I believe EA is much more about connecting the strategic intent and the executing projects than just between “the business” and IT.

The main concept here is looking at “the problem” from a process (verb) point of view instead of from a thing (noun) point of view.

“The business” and “IT” are essentially things, whether you think of them as departments or in terms of architectural descriptions they are still things. So to talk about something as bridging this gap doesn’t make so much sense to me. The business and IT already work together otherwise the organisations and the wider enterprise would not operate.

Yes I agree governance is a key part of EA that is the control mechanism between strategic intent and tactical expediency, and this is where Enterprise Debt (IT’s identification and management) comes in as a way for the business and management to make better decisions based on pertinent information.

The area where I see EA really helping and “bridging the gap” is the chasm between the high level strategy / objectives of an organisation (which includes business, it, hr, finance, etc, etc) and the executing projects that are effecting change (which includes business, it, hr, finance, etc, etc).

@Jan: “Only thing I would add is mention about governance, which is needed for implementation but on the other hand, a governance is required for any successful implementation.”

I believe this disconnect comes from projects being very very blinkered and single minded about their purpose and almost completely overlook wider, more strategic issues. This is how projects tend to be controlled. As projects execute I have seen many many man times (usually the architect) will identify some synergy with a wider context, some possibility to get better value but those thoughts and desires are quashed by the project manager and the project boards a) single minded drive on that particular project and b) the limited resources allocated.

@NEW DISCUSSION GARTNER: "A FOOL WITH A TOOL IS STILL A FOOL" I was dismayed to hear this same staid, tired and, IMHO, damaging catchphrase at this weeks Gartner EA summit in London (May 2010). And it always seems to be proffered with a wry smile and the feeling that they have just said something really radical, deep and meaningful. My belief is not that it is wrong (I cannot disagree with it) it’s just totally meaningless. If it were just meaningless I wouldn't have a problem with it.

EA is all about exposing information and showing implications and raising that information to the appropriate level so that better business decisions can be made.

──────────────────────────

I believe that to progress, EA has to start to lose it’s hanging on the “the business” and IT

I have a problem with it because the inference is that if you want to start to do “EA” then you shouldn’t start with a tool. I would counter the “A fool with a tool is still a fool” rhetoric with “True, but a

150

Comments

business with a tool can see the implications of their decisions before their decisions become reality and it allows them to understand problems and therefore what they need to do to solve those problems.” Who is this “fool” anyway? the organisation???? the management??? the architects??? the person who suggests using a tool? If that is the case then I gladly admit to being a “fool”. My view is very simple….

1) EA is all about exposing information and (more importantly) the relationships between that information so management can make better more informed decisions.

pragmatic approach to the process you use to adopt it is important. I believe my view is evidenced by Colin Birchenalls presentation at the conference where starting with a tool was the absolute best approach for Serco and Glasgow City Councils LLP and for the many successes they have achieved in growing up to the full EA level by delivering massive and real value to the business by modelling using a tool. I believe this "A fool with a tool is still a fool" mantra is doing serious and significant damage to EA in general and it’s adoption with enterprises if it is turning people off from taking that as a valid approach to begin the journey of EA adoption.

2) The information that EA exposes, EA does not create. It already exists within the organisation. The problem is not a lack of information, the problem is too much information…inconsistent, duplicated, out of date, information that is stored in many formats in many locations that also has no consistent meaning (e.g. one persons definition, and therefore information, about a service can be very different from someone else’s definition, and information, but these disparate things are called the same)

What do you think?

3) Since the information is stored all over the place, seeing and using information about the relationships between this information is at worst impossible and at best, impossible.

I like your definition because I believe change is at the heart of enterprise architecture, or rather the enablement of change.

──────────────────────────

@Pat: “I'm new to this discussion and don't know if you are interested in new alternatives.”

4) This is a real problem that tools are designed to solve.

6) Like any tool, if you use it in the wrong way the tool will not “work” and so a

@Pat: “The purpose of the EA is to assist in the planning and management of change.”

@Pat: “I've worked with a lot of clients to do a wide variety things with the EA, and I can't think of anything that didn't fit nicely into the framework of either planning or managing change.” Yep - Agree 100%.

For me…in relation to EA…

5) The tool will not tell you what to do with the information once you have it but it provides the environment to expose the “problem domain”. Once exposed, what to do about the problems become much much easier because the first step in solving the problem is seeing and understanding it.

Of course I/we are interested in alternatives. And the more alternative the better!

Planning operates at many levels from strategic planning and project portfolio planning, down to planning of change with regards to processes and technology. Roadmapping etc.

Comments

Managing Change is about governance and making sure that either the strategic intent is being carried out/followed or, if people, programmes, projects start to deviate, that those deviations are identified, quantified (Enterprise Debt) and raised to management (at the correct level) for them to make informed decisions about whether they will allow the deviation (and accept the resultant increase in Enterprise Debt) or they will not allow the deviation in which case they have to provide whatever is required to remove the barrier that is causing the deviation. ──────────────────────────

@Eswar: “What is the best practice of developing an Enterprise Architecture "Architecture Strategy first and Tool second" or "Tool First and Architecture Strategy second".”

asks what have we gained and the answer is nothing. Don't blame the tool is you use the tool incorrectly. Don't blame the screwdriver if you try to hammer nails in with it. The successful process for using a tool is actually very simple... Stage 1 – Determine the Question Identity a high level business question that the management wants an answer to, that they either: a)

Currently cannot answer, or

b) Can get an answer but the quality and confidence in that answer is too low to be useful. Stage 2 – Determine Required Data

Using and or starting with a tool is an eminently valid approach to start the adoption of EA and EA practises.

151

It has been used successfully by many many organisations, for example, by Colin Birchenalls presentation at this weeks Gartner EA conference in London, where starting with a tool was the absolute best approach for Serco and Glasgow City Councils LLP and for the many successes they have achieved in growing up to the full EA level by delivering massive and real value to the business by modelling using a tool. There are many people who have completely failed by starting with a tool. The reason for this failure is NOT because starting with a tool is wrong or bad.

The reason is (as with many many things that EA seeks to address) is process.

Having understood what the question is, this stage identifies what information will be required to answer it. It should be noted that the temptation to try to answer the question should be resisted. Stage 3 – Populate the Model

The third stage of the iteration is to find and populate the model with the information identified. This sub-process is described in detail in the next section

Stage 4 – Integrate the Model This phase ensures that the work that has been done and the information loaded into the model is sustainable. For each of the Datasources there are two alternatives (which were identified in the Analysis Phase).

a) The Datasource is removed – The processes and people using the original Datasource will stop using it and will use the information in the model.

Many people incorrectly start to use the tool (one example of bad process but there are many other ways of failing) by modelling the heck out of everything and after 6 months (or years for some failed attempts) the CEO

b) The Datasource is preserved – The necessary interfaces are built to enable the synchronisation and management of the data going forward.

152

Comments

Stage 5 – Answer the question

Having populated the model, it is now possible to use the mode in concert with the tools and analyses provided by the modelling tool the answer the business question. After this, another iteration is possible.

£70+ Million. This then gave the more credibility to the business which then allowed them to start moving up the food chain towards the strategic planning area. It’s not a case of this not working. It has worked.

fyi, I have just started a related discussion the EA Network Linked In discussion group (http://www.linkedin.com/groups?home=&gid =36781) entitled …

It’s also not a case of that’s it - that’s the end of the journey - the point is, that is it a good way to start the journey as evidenced by Serco et al.

GARTNER: "A FOOL WITH A TOOL IS STILL A FOOL"

Unless you have the luxury of a CEO who know what he is doing and mandates “proper” EA you are more than likely going to have to introduce it through the IT route and building credibility (which IT has usually complete lost) is a very very good first step.

I was dismayed to hear this same staid, tired and, IMHO, damaging catchphrase at this weeks Gartner EA summit in London (May 2010).

There is usually massive opportunity for rationalisation and cost savings just by initially (because EA is much more that this) looking at IT. The problem is its difficult to rationalise what you can’t see. That’s the purpose of a tool - to model the problem domain - once the problem is modelled the solutions of what to rationalise etc etc etc are usually very simple to see.

http://www.linkedin.com/groupAnswers?view QuestionAndAnswers=&gid=36781&discussi onID=20329940

──────────────────────────

@ mjdebeer: “Yep being guided by the tool is a silly as buying a service desk and

then saying "OK, let's do ITIL". Looks like you are missing some vision and strategy wherein which the tool can add proven value.” @Derek: “To me, starting an EA capability by selecting a tool would be a little bit like starting the process of making a new home by buying a hammer, or starting driver's ed with visits to car dealers. Valid, but way premature, and creates the impression that EA is just about modelling. " I respect what you guys are saying but I think you are missing my point.

One way that has been proved to work is modelling just enough of the current state to provide real savings (I believe this approach saved Serco and Glasgow City Council about

Imagine walking into a dark room and being asked to rationalise it’s contents. Using a modelling tool helps you to shine a light in the places you want to look into so you can then see what you are doing.

@Alan: “Hi - the discussion should not focus on "THE tool" .. should it not talk about a set of tools with their instruction manuals and case studies. Engineers would not attempt to build a house with just an electric drill. one would assume one they have a complete set of tools, understands them, knows how they can be used to advantage and has investigated case studies to see what is possible and how mistakes might be made.. "the operational application of tools" so to speak”

There are various ways to “start” the EA journey.

A modelling tool is a way to bring clarity and understanding.

Comments Absolutely. Instruction manuals. How to use the tool(s). To do what? To what? When? How? In which order?

Basically, processes - hence the high level process I stated in an earlier post. ──────────────────────────

@Eswar: “Kevin - Don’t you think you are contradicting yourself in this mail. Your steps suggested clearly defines that Identifying Business Objectives is the first step and determining Information (what kind of information repository to be built) is the second question and then go to populate tool with models. But initial part of the mail you seem to suggest that there is no harm to start with tool.” I think we are talking at cross purposes.

from not understanding enough about your question and it’s context. @Eswar: “I am not denying that one should not have business objectives for EA. But the fact is defining business objectives is the first step and whiteboarding them is the right approach. But conducting EA like a tool service shop is a wrong approach is what am trying to find answer for with case studies/examples/practitioner viewpoint.” Can you start again and restate your question in different terms and give us more information ? @Eswar: “Thanks for your steps - they make sense and universal for any EA approach/framework” Yes, but rarely followed - that’s shy many EA initiatives that start by modelling things fail. Starting by modelling things is not the reason they fail. Failure to follow this process is the reason.

The question I was answering was "Architecture Strategy first and Tool second" or "Tool First and

153

Architecture Strategy second".

You don’t need an Architecture Strategy in order to obtain and buy an EA modelling tool.

In fact, how can you write an Architecture Strategy (when a strategy is a high level plan of where you are, where you want to be and how you are going to get there.) before you understand where you are.

@Joe: “According to a new statement from Gartner, most enterprise architecture (EA) initiatives “remain trapped in the IT department,” and the consultancy recommends a new approach it calls “hybrid thinking” to break EA out and into the wider organization.” Yep - I listened to their presentation on that also. You know what I thought?

I thought - but this is nothing new - this is EA. This is how I have been thinking and working for the past 10 years.

When going on a journey the first thing you need is a map. The second thing you need to know where you are on the map. The next thing is where you are going, but if this approach is at the IT level (and that is the level believe this thread is running at rather than the strategic “proper” EA level) , you don’t need necessarily to be told where you are going because the top CIO priorities have remained unchanged for the last 40 years - rationalisation, cost reduction, increased quality, etc etc, etc.

──────────────────────────

Taking this thinking and applying it to this discussion, I think our confusion is arising

Are the Emperors New Clothes made from the most fantastic material ever that is so wonderful only the intelligent important people can see them???

154

Comments

I am afraid that I am but a humble Architect. To me, the Emperor is naked.

──────────────────────────

@Derek: “What I'm going to suggest to my current client (where I may be helping them to set up an EA capability) is not to worry about tooling until we've taken a full iteration through the TOGAF ADM and really understand where the value's going to come from.” You could do that, personally I wouldn’t. I believe you need to show value as early as possible.

A lot of people start directly here and forget that in order to be able “do” EA you first have to make changes to that organisation to be able to “do” EA… Phase 2 is Implementation - I.E. making the changes to the organisation required in order for it to “do” EA. Things like Mitigating the risks of EA, Education, Changing the Motivation Model, Setting up a Modelling Tool and a Metamodel, setting up Principles and Governance and a Strategic investment Board. A lot of people (because they have tried to jump in at phase 3, omit most of this, as shown by some thoughts on this thread where people want to do strategic planning (“Phase 3 - Operate” first instead of sorting out the tool. (“Phase 2 Implement”)

I can’t back up my feelings with hard facts, but the general background hum I hear is that many people have tried to do it that way and failed (of course that may be down to the process - but if you are following TOGAF’s processes…..)

Phase 3 is “Operation”. Things like Strategic Planning, Modelling the current state, Reviewing Solutions and Options.

@Derek: “However, if you don't know what you're trying to accomplish, how do you decide what the boundaries of the enterprise are, to what level of detail you need to model, and which models / views you need to produce?” Excellent question - I believe there is a simple answer.

The key is to start generating value for the business ASAP.

If you are (likely) trying to “introduce” EA from within IT then there are the usual easy questions / things the businesses want to do that you know already - reduce costs is obviously the big one. So, depending on you organisation/environment you can start with application rationalisation or hardware rationalisation.

There are 3 structured phases to be able to operate EA.

The board then decides (with it’s eyes wide open) whether to provide the money and resources to implement the changes or not.

Obviously I think the phases should go in order of 1, 2, 3 (top down) as that is how many organisations fail with their initiatives, however, there is the possibility to also simultaneously go about EA from the modelling perspective, especially when there are modelling tools out there that are free

I know I am pushing this from the bottom up (IT) and the modelling side, because that’s the context of this question, but I believe EA should also be driven from the to down.

Phase 1 is “Preparation”. This is a short piece of work (anything from 2 to 6 weeks depending on the size of the organisation and the availability of the people required to take part - so getting the money to do it should be much much easier ) which culminates in a presentation to the board of a) What the vision and purpose of adopting EA is, b) What their level of EA maturity is, what level is proposed to go to, what benefits that will bring, c) What are the associated risks and how will they be mitigated, d) a costed project plan for the next phase “Implementation” to effect the changes necessary to continue the EA journey.

Comments

(e.g. Iterplan from Iteratec) or very cheap. Having said that, I believe any tool vendor will allow any organisation to use their tool for a couple of months trial without any payment and a couple of months should be long enough to try to show some value with the tool. Actually, the problem with tools is not really their cost - the problem is the time take to be able to effectively use them - training. So if you are wanting to start your EA journey I would suggest you start with the tasks in the “Prepare” phase, but noting that you can also surreptitiously do some modelling too.

155

Hehe. I know what you mean though! Glue has negative connotations, like running through treacle, a disabler rather than an enabler. @Mridul: “not glue.. but the capabilities required to execute the strategy ?” Yep - I could add that to the list of words to use instead of glue… continuum/process/doctrine/linkage/balance/ culture/capabilities

@Alan: “Is EA and its tool set evolving fast enough to look after its own customers?

Excellent - you just have to keep plugging away at it.

There is a revolution in EA approaching.

@Martin: “Now how can we make EA focus on strategic execution (Time to Market) both in regards of the IT Business Model and the Service Value Proposition?”

──────────────────────────

@Jan: “I daily work in such environment and we try to overcome and manage these issues.”

I can see it.

I can taste it

I hope I am doing my bit to further the profession and to cut though all the rhetoric and fancy words used by massive companies with vested interests in making it look complicated. But one man does not, a revolution make.

We have to show that all the things that EA can help with are already in the Enterprises Strategy - Goals like Effectiveness, Efficiency, Agility and Durability and Strategies to achieve them such as managing Cost, Risk, Agility and Quality.

We need to stand together on a platform of common sense and pragmatism.

EA does not introduce a whole new set of organisational goals, it hangs off and supports the things already there.

If not - Today our lives, tomorrow our souls.

──────────────────────────

@Alan: “Just views though”

@Tom: “It's not so much the glue itself, as tells you what that glue is - and how strong that glue is, too.”

And very important views.

────────────────────────── @Mridul: “Glue sounds a bit sticky ! ”

Cool ! …….Viscosity - lubricant - oil BINGO!!!

Everyone’s views are important and the more we expose and discuss peoples views the faster things will move forward.

OK so you can only take analogies so far before they turn round and kick you in the wedding tackle but it feels nice.

156

Comments

EA is the oil that lubricates the enterprise allowing all parts to function well and stopping them burn out and wear down too fast. Maybe a thesis……if I knew what a thesis was!

@Dennis: “Today, most EA work is IT centric” I would slightly change that and say that Most EA work is beginning in IT.

@Dennis: “Generally, EA demonstrates that IT is aligned with the corporate strategy and shows a way to execute some aspects of the strategy.”

Here here. Other things get thrown in the mix but general if I have to choose one word I always tell people EA is about efficiency. I would only add that for many many years organisations have concentrated on operational efficiency (e.g. cost cutting mostly) in the 21st century they had better start doing something about transformation efficiency (aka agilty) or die. The 20th century mantra was… “The only constant is change” The 21st century mantra should be… “The only constant is the acceleration of change” © Kevin Smith! @Eswar: “Suggesting that both the way will do depending upon the situation is not acceptable :-) :-)”

I would also change that slightly “Generally, EA demonstrates that the enterprise is aligned with the corporate strategy (only one part of which is IT) and shows a way to execute the strategy.”

@Nic: “..efficiency..”

@Dennis: “IMHO, the statement should say; EA is a binding force between strategy and execution ( but not the only one). Tomorrow, EA might encompass much more than it does today.” OK - we have to be clear when we are discussing that the discussion does not flip between what EA is (in terms of what is actually should be) and what it is (in terms of what’s actually happening in lots of companies)

When I say it is, I mean it should be, not what it is, because what it is, is dependant on a specific organisation and we are not talking about specific organisations here.

100% agree.

If I had a choice I would suggest people follow the PEAF process and approach which is… 1)

Prepare

Implement

Operate

The mandate to do EA is covered in Phase 1 The buying and setting up a tool is in Phase 2 (among other things) The using the tool for lots of different things is in Phase 3 (among other things) If you already have a tool (it may or may not be the most appropriate tool) then you can still follow the process above.

@Nic: “ With a good governance function, some adequate portfolio management, a clever S&P team, a responsive ICT dept/partner, and non-jerk leadership, you can probably get by without a specific person or group called "an EA" - because together those capabilites add up to the EA function.”

OK - let me try.

If you are following the process above, but you also already have a tool they you can start to use the tool to model things in

Comments parallel with the process for getting wider EA buy in and agreement.

Now you probably won’t be able to start modelling target states but you sure can start modelling the current state - so think of a question that needs answering - what applications and data and services are used by department (A) may be a question because a current project may want to rationalise them. So you are starting modelling in IT (which is pushing EA from the bottom) , but the process above is also being followed (which is pushing EA from the top)

I hope I am making myself a little clearer.

──────────────────────────

@Michael: “I am still at it putting the new model together and its really hard. I find that all Meta models in the end say the same thing. Has anyone dealt with the big granularity problem?” Why not approach the problem from another angle. Stage 1 – Determine the Question

Identity a high level business question that the management wants an answer to, that they either: -

Stage 3 – Populate the Model The third stage of the iteration is to find and populate the model with the information identified. This sub-process is described in detail in the next section Stage 4 – Integrate the Model This phase ensures that the work that has been done and the information loaded into the model is sustainable. For each of the Datasources there are two alternatives (which were identified in the Analysis Phase). a) The Datasource is removed – The processes and people using the original Datasource will stop using it and will use the information in the model.

Currently cannot answer, or

b) Can get an answer but the quality and confidence in that answer is too low to be useful. Stage 2 – Determine Required Data

b) The Datasource is preserved – The necessary interfaces are built to enable the synchronisation and management of the data going forward. Stage 5 – Answer the question Having populated the model, it is now possible to use the mode in concert with the tools and analyses provided by the modelling tool the answer the business question. After this, another iteration is possible.

fyi, I have just started a related discussion the EA Network Linked In discussion group (http://www.linkedin.com/groups?home=&gid =36781) entitled … GARTNER: "A FOOL WITH A TOOL IS STILL A FOOL"

Having understood what the question is, this stage identifies what information will be required to answer it. It should be noted that the temptation to try to answer the question should be resisted.

If the process above cannot be followed, then you use the low level modelling in IT to deliver real benefit and show management that benefit, then ore people will want to use the information and more benefit will be generated, etc, etc, etc. the more benefit you generate the more the business will listen. This is the approach that Glasgow Council and Serco adopted used and it is working.

157

I was dismayed to hear this same staid, tired and, IMHO, damaging catchphrase at this weeks Gartner EA summit in London (May 2010).

158

Comments

http://www.linkedin.com/groupAnswers?view QuestionAndAnswers=&gid=36781&discussi onID=20329940

PR ──────────────────────────

@Art: "the most important quality of an Architect is....courage....when EA is at its best we are independent, calling it like we see it, separate from narrow individual interest"

I could not agree more. I call it altruism - but it boils down to the same thing.

An an EA, I have on more occasions that I can remember, been the only one in the room to stand up and say it how it is. Not in an arrogant way, but in a “here are the facts” way.

C’est la vie. Either I tell the truth or I stop being an EA. It’s as simple as that.

I would have to say (at the risk of sounding arrogant) that everything I have said would happen at organisations has happened after I “left”

If I add up the lost time and lost money caused by people not following my advice (I hasten to add that my advice is rarely mind blowing, but generally common sense) I think I have seen organisations probably collectively lose around £300M and waste over 10 years of time and effort. The cause?

For them… “You reap what you sow” - God.

For me… ’Better to die on your feet, than to live on your knees” - Emiliano Zapata, Jose Marti, Che Guevara ────────────────────────── @Nic: “A good EA is born, not made.” 100% Agree. Being an EA is not something you learnt (in the traditional sense), it’s something you are. @Nic: “First of all, unless you are an INTP/INTJ/ENTJ myersbriggs personality type, this is not the career for you.”

I know that has, a lot of times, brought me into direct conflict with my superiors, sometimes with the result that my contract is not extended.

money to those that get rid of loose cannons that will disturb the calm)

Politics - pure and simple.

@Nic: “Secondly, if you are not borderline ADD or autistic, it is probably not the right career for you - you need to be a bit of a renaisance man, fliting from one thing to another, and comfortable with never "finishing" stuff.” 100% Agree.

@Nic: “Thirdly. if you are an alpha-type person, you are better off looking at CEO roles - EA's are viziers, not sultans - you get to work most often behind the scenes, as it were. This suits beta-type people.”

100% Agree. I think this is why I say that Project Mangers cannot be architects (although of course it doesn’t stop a lot of them trying!).

But I don’t blame the individuals, I blame the directors of the organisations that have allowed this cancerous culture of hiding information and selfishness to grow. In many cases, this culture has grown because they effectively punish those that would reduce or remove it (those that speak out) and reward those that proliferate it (more power and

100% agree - Thius is why I show my Myers Briggs classification on my resume - INTJ.

@Nic: “Lastly, you need to have a thirst for knowledge. There is no branch of human endeavour that is *irrelevant* to EA. Maths, economics, psychology, accounting,

Comments

engineering, law, and many many more disciplines will feed into the sub-strata of knowledge that may become relevant suddenly for you in a particular situation.” 100% Agree.

Nic, I think you have said more in these words than many others (including myself) have said in the last 10 years. If people read your words and still do not understand the type of person an EA is then there is no hope for them!. ──────────────────────────

What do you reckon? Deserving of a separate discussion ?? “If we accept that Enterprise Architects are not the best people to explain and “sell” the benefits of EA to organisations, then who is”????? ────────────────────────── @Joseph: “However, I would venture to say from the example he gives that they started EA before they started with the tools. All it means is that they started using the tool, before they had a complete EA vision populated.” Not sure what “started EA before they started with the tools.” means - but as I understood it (after sitting through the presentation) they only way they started was to buy a tool, figure out a good question they wanted to answer that would give a big return (application portfolio rationalisation), populated the tool with the data required, made some changes, save d a lot of money, modelled some more, etc, etc.

@John: “I am chronically autistic mastermind artisan architect without a formal myersbriggs personality type! Check out the Keirsley_Temperament_Sorter [http://en.wikipedia.org/wiki/Keirsey_Temper ament_Sorter ] - usefully it has a category for architect. Reflect on how your abilities map against the architect role. ” Cool - Seems I am a Introspective, Rational, Co-ordinating, Mastermind!

So Mr Bond….we have been expecting you ;)

Of course we have the other traits is less abundance but I think it’s more accurate than astrology!

159

They started at the application /infrastructure level then moved up into solution architecture, then project portfolio then strategy. The point being they did stuff that saved money. The question, of course is…

@Nic: “That also, by the way, should show why this particular area has the issues facing it that it does - the person type i have described very very seldom makes a good communicator.”

“OK - but you needed a mandate/money etc to buy the tool, have some training, and the people to do some modelling etc right? So how did you get the mandate/money ?”

Hmm -I think you have a point there.

Which is why I asked Colin Birchenall after the presentation. Hi answer was - “Yes, exactly right - the catalyst was the formation of the LLP between Serco and Glasgow City Council. Serco had basically said, OK - you want us to be in partnership with you in terms of provision of IT? = no problem - the only way we can work with you and generate a return for all is to start modelling stuff, so we can

As you say, this doesn’t mean that we all can’t communicator but it if that is an underlying trait it goes a long way to explain why EA’s are no good at “selling” EA. Which leads us to a very interesting question - if not us, then who? “Marketing” people, “Sales” people???????

160

Comments

understand stuff, so we can kill stuff where we don’t need it, and strengthen stuff where we do”

PR Colin also agreed that what they had done was not rocket science and simply common sense and that many many organisations have many people who already know what should be done and how it should be done but they don’t get the remit/budget/mandate to do anything.

Which is why I have started thinking that the best way to get organisations to adopt EA is to marry the education and awareness approach with a catalyst approach. There are many… - Mergers & Acquisitions

- Business Unit Consolidation

@Joseph: “Just because you have an EA team using an EA tool, doesn't mean you are actually performing EA.” I would say yes and no. My higher level view is that EA is generally about strategic planning, modeeling and governance. Based on this, I would say that 99.9999% of organisations are already “doing” EA. They already do strategic planning (it may be terrible), they already do modelling (it may be terrible) they already do governance (it may be terrible).

- Introduction of New Products, Services or Lines of Business

Sort of. some things you can some things you cant; For example, you can just start modelling stuff before buying a proper tool, however you can’t start doing governance using principles (operate) until you a) have agreed what they are and b) made the changes in the organisation required to operate them (Implement)

- Outsourcing a Business Function - Divesting a line of Business

- Operational Cost Reduction - Business Transformation - Building Relocation - Strategic Planning

- Increase Business Agility, Efficiency and Effectiveness - Streamlining Business Processes

They may do everything terribly, but they still have an EA and they still do EA.

If you don’t use a project management methodology (e.g. Prince2, MSP) does this mean you don’t do project management? No. Frameworks help people to do what they are doing in a more efficient, better, structured way.

EA is no different to Prince, MSP, Six Sigma, LEAN, ITIL, COBIT, etc etc etc. They are frameworks/.methodologies/methods improving thngs.

- Business Process Management

They just scratch different itches.

- Business Process Re-engineering

@Joseph: “But, all your efforts would be towards populating the as-is with lowerlevel details more useful for support/operations rather than architecture. Not a wasted effort, IMHO. But, I wouldn't want to be spending all my architecture efforts in documenting the complete as- is. I

- Off shoring - Market/Shareholder Pressure @Joseph: “, EA …..is an iterative process. You could start anywhere in this circle”

all for

- Consolidation of Suppliers, Technologies or Applications

Comments would never hope to complete this task... :)”

Correct - which is why you don’t approach modelling that way. A lot of people do and they mostly fail because it’s the wrong process. ────────────────────────── @Nic: “Facilitators.”

@John: “What we need are not marketing or sales people but linguists, philologists, occupational therapists.”

Yeah - ok - but who? how? You can’t tell an organisation to pay a load of facilitators, occupational therapists to explain to them how EA can benefit them!

161

The day that organisations hire an architect first and then a PM (when the architect has defined what the PM needs to manage) will be a day when architects are truly recognised as the key component for successful projects. @Deborah: “EA identifies the program of change required and within the program” Maybe a semantic point but I would say that is Strategic Planning aka Annual Business Planning. That is part of what EA helps organisations to do better but I still think that it’s a support role to allow the organisation to do its strategic planning better.

Should we explain it to the CFO and let him take up the challenge? The people in HR? ???

It may be that some organisation just do not have the calibre of people to do the strategic planning for them and in that case they may employ someone to help/do that for them - I would say those are the roles that you have had and I would distinguish them as being Strategic Planning being supported by EA rather than EA.

I have no answers only questions at this stage.

I could be misinterpreting your comments though, so if I am, apologies.

──────────────────────────

I think this is the problem with EA though. EA consists of strategic planning and governance supported by models….

I was hoping for something a bit more…. pragmatic ;-)

@Brian: “Even when I point out real life situations that clearly needed an architecture at a more hollistic level to Project Managers, they still either cannot get an EA position to be funded, or they simply say that they will avoid the mistakes in the past by "being more careful" and they continue to push forth with more technical solutions. In other words, its hard to get hired for Enterprise Architecture work when programs continue to only hire developers and technically savy PMs.”

I can help you with your strategic planning. I can help make sure your projects are aligned to your strategic goals rather than…

I can help you with Enterprise Architecture. I believe there is no role called Enterprise Architect in the same way that there is not role called Quality.

Yes - I have seen this time after time after time.

If we try to “sell” EA in those terms we may have better results….

Senior management seem to think that if they hire s hard nosed PM (who has done some IT sometime in their dim and distant past) everything will be fine.

EA, like Quality, should be systemic in an organisation.

162

Comments couple of days, stick it on a website and sell it" - Phil Allega.

Hmmm - that brings to mind that Simon and Garfunkle song about bridging the gap between business and it / strategy and execution…….

Can anyone volunteer suggestions as to what these 75 "frameworks" are?

@Deborah: “I was a punk rocker (with flowers in my hair): “

Like a bridge over troubled waters…….

@Martin: “Hence to prove that EA is a worthwhile activity this has to be drawn out and measured: “

I know my thinking is a bit radical but I honestly believe that EA is not an activity. EA is an approach like Prince2 to help organisations do what they are already doing, (Strategic Planning and Governance) better. You wouldn’t hear people saying “how do I convince someone that Prince2 is a worthwhile activity”

────────────────────────── @Gowthaman: “I am curious to understand the scope an Enterprise Architect will be having in his profession with the advent of cloud computing.” An Enterprise Architect cares about anything that is architecturally significant. Cloud Computing (internal or external) is one of those things.

@Tom:

Note that I believe they are using the word framework to mean Metamodel rather than my use of the work framework to mean a set of products processes and guidance (one component of which is a Metamodel).

Brain the size of a planet and they ask you to pick up a piece of paper…. ──────────────────────────

@Neetan: "I just wonder how to get all these models et all out of EA offices to add value to business managers and senior business executives." It's easy - just find a question that they want an answer to i.e.

When the Current structure of the enterprise is understood (The Enterprise Architecture) and the Target and Intermediate states have been defined, use or not of Cloud Computing will either be ruled in or ruled out by virtue of the principles and roadmaps produced. Don't forget the Target, Intermediate and Roadmaps are reviewed and probably change year on year.

Stage 4 – Integrate the Model

──────────────────────────

Stage 5 – Answer the question

@Michael: “I suppose your only a fool if you believe it is damaging.”

Stage 2 – Determine Required Data

────────────────────────── @NEW DISCUSSION GARTNER: "I am tracking 75 frameworks Anyone can knock up a framework in a

Stage 3 – Populate the Model

So, to answer your question Cloud computing will not have any effect on the profession, but it will be just one of the many things considered at the strategic planning level.

Stage 1 – Determine the Question

I guess I am a fool then.

@Michael: “you should definition of a fool”

explain

your

Comments

I think it’s probably their definition of a fool that’s more important here although I must admit I only interpret the definition to be that defined in the dictionary.

But, I think you are right - actually what do they mean by their statement? From hearing the words and seeing the gestures and body language surrounding the statement I got the serious impression that the gist was that they believed that starting with a tool was a very bad decision. The only other way I could interpret the statement would be, as you say, “if you buy such a tool and then don't intend to learn how to use it.” or if you buy a tool and then use it in an inappropriate way you are a fool.

minimum that is going to answer 85% of our questions” Yes but tat 85% should be produced over time and over a number of iterations in my view. If do not have a question to answer stop. If you do have a question to answer, only model what you need to model in order to answer the question. Then find another question. If do not have a question to answer stop. If you do have a question to answer, only model what you need to model in order to answer the question. Then find another question. etc… @Michael: “Stage 2 assumes that you have completed you list of information that you want to record. I find that when you get the information you then end up back at stage 1 asking more questions.”

I assumed this was not the meaning because it is so obvious that the statement would have no merit.

163

It would be similar to them stating to the numerous intelligent people gather there that to use a oen without any ink in it would not be very productive.

This may be the case but those questions should be saved for the next iteration.

Of course, I could be wrong.

──────────────────────────

@Michael: “you know enough about the organisation and EA to be able to know what questions to ask.” Not enough about EA but yes, enough about the organisation. @Michael: “We have already started with a key number of questions” That’s good.

The only thing I would say though is that all these questions would be questions that finding answers to will add value. I.E. there has to be some purpose to asking the question… e.g.

Asking “How many applications do we have” is not a very good question.

@Michael: “however I am trying to make sure that when we start recording the information we will not suddenly realise that we missed something. EA answers a lot of questions but it will only answer them if you have the information, I would realy like to make sure that we at least collect the

The key here is to iterate and get value fast. An interation shold ony take a couple of weeks not months and if you finish an iteration with some more questions that now need tro be answered then that’s great.

Asking “How many applications can we remove from our portfolio and how much money would that save” is a valid question. ──────────────────────────

164

Comments

@Joseph: “..."

I get the impression that whatever I say you are going to say that they didn't start with a tool. e.g. before they bought a tool, they had to choose one therefore they didn’t start by buying a tool...

The point I am trying to make is that starting point for all was to buy a tool. They couldn't and didn't build a business case showing the ROI etc etc etc.

They started by saying the only way we will work with you is if you first agree we need some investment to buy a tool.

If you are starting (to adopt EA practices and products) with a model and a tool and you want to know what questions you want answers to or you want to know what to do today then you can rely on the top CIO priorities that have stayed the same for the last 20 years.... - Reducing Costs - Improving Quality - Improving the Business IT relationship - Improving IT Governance - Providing value to the business

They didn't start by trying to "sell" them EA.

- Identifying and implementing process improvements

To try to make my point even clearer let me quote Colin Birchenall….

- Delivering projects to enable business growth

“You have heard today a lot from Gartner about not starting using a tool. Well I can tell you that we have found that this is in fact a very effective way of starting…….”

Yes you need to have a pc to run the tool, yes you need to have people that understand what a tool can do, but honestly, it really is a total no-brainer…if you cant see the problem space you can’t effectively understand or suggest how to improve it.

If I give you a box with opaque sides and ask you to tell me the ROI of buying a tool that will allow you look inside the box you would not be able to. But it’s just plain obvious that being able to see inside the box would be a really good thing to do. That’s what (one of the things) modelling tools allow you to do.

@John: “The conversation about questions and answers is on the right track, but with all due respect "What do you want to do today?" should be the first one. “

- Attracting, developing and retaining staff

The priorities change but the generally remain the same - the most pertinent one today for most organisations is reducing costs. And looking at business priorities... - Reduce costs

- Reduce complexity - Reduce risk

- Reduce cost of ownership - Reduce the time to make valid decisions - Increase ease of change

- Increase flexibility

──────────────────────────

- Linking business and IT strategies

- Sweat the assets - Growth

- Compliance

Comments None of these are new - so why cannot organisations satisfy them?

Because they need "proper" EA practices and products because all these things depend and rely on EA practices and products to produce them.

And guess what, yes - you are going to have to spend some money first. Shock horror! If you continually run projects badly you may want to look into a PM framework such as Prince or MSP to help show you how to improve. If you continually manage and support IT services badly, you may want to look into an EA framework such as ITIL to help show you how to improve.

At the end of the day, it doesn’t really matter which one you choose. If you use a Metamodel that is already supplied by the vendor then you will automatically get, out of the box, a whole load of reports and dashboards, if you go with your own you will have to set these up yourself. Personally, I would choose the tool that is easiest for your organisation to use and that produces all of the analyses and reports ~(or most of them) that you require. So, to answer your question, I would image that yes, a lot of people have created their own “ERD” or Metamodel, but I’m not sure that, that is the best approach. @Michael: “What are everyone’s thoughts on this as an approach? : Break down the Company Business and Strategic Objectives Level to a level of granularity that is not ambiguous.”

If you continually do strategic planning and governance badly you may want to look into an EA framework to help show you how to improve.

165

──────────────────────────

@Michael: “Has anyone every created an Enterprise Architecture Entity Relationship Diagram? In the following location is a my version of an Enterprise Architecture Entity Relationship Diagram.” OK - let’s get back to the original question.

Firstly, when you say and EA ERD I think you mean a Metamodel - correct me if I am wrong.

@Michael: “From there determine a the list of EA objectives similar to those posted above by Kevin and link these up to the strategic objectives.”

These are not EA objectives, there is no such thing as EA objectives only business/organisation/enterprise objectives. Those that I list are probably part of the strategic objectives above. @Michael: “Get these prioritised by the executives …”

Most tools either come with their own fixed and very complete Metamodels (e.g. Troux) that allow some mapping of terms to transfer their names into names your organisation more naturally use, other tools are basically Metamodel agnostic and totally data driven and therefore allow any Metamodel to be setup. These tools often come with a variety of Metamodels already pre-setup up such as TOGAF or PEAF or their own proprietary model.

I’m not sure what this means in practice the strategic objectives should be reasonably clear. However, these objectives should consist of long term objectives (that drive the “Target” state, and shorter term objectives that drive the “Intermediate” states.

This will never happen because (in my experience) executives prioritise everything as priority 1 because they want everything. @Michael”…and then begin listing all the questions we should be asking about the

166

Comments • Technical Entities (Applications, Databases, Devices, Technologies)

I don’t think that’s going to work either.

This should take no longer than 10 days. If it takes longer than 10 days you are modelling at too low a granularity.

enterprise that would help us to answer how we achieve each of the EA objectives.”

Here is my (PEAF’s) approach.

First of all, in terms of modelling there are two equally valid approaches. an organisation can take. Either one can be taken on their own or both at the same time. Although, Since the Top Down approach tends to be annually, it is likely that the bottom up approach will be adopted first and the Top Down approach used added the next time Annual Business Planning comes around.

Top Down - Strategic (aka Annual Business Planning) =============================== ==========

This is the same structure as the (Current) but is an expression of a 5-10 year target structure. 4) Create as many Intermediate models “Enterprise Structural Model” (Intermediate) as required depending on how many short term and mid term objectives there are. 5) Create a Portfolio Model defining the programmes, projects and initiatives required to move from the current state to the first intermediate state, and high level plan of subsequent programmes, projects and initiatives.

1) Model the “Enterprise Strategy Model” in terms of :-

3) Analyse all objectives and Model the “Enterprise Structural Model” (Target)

• Ends – What the organisation wants to achieved (What). (Vision, Goals, Objectives)

6) Execute the programmes, projects and initiative portfolio.

• Means – How the organisation will achieve its Ends (How). (Mission, Strategies, Tactics)

================

• Drivers – What is driving the Means to be defined (Why). (Influences, SWOT’s)

Stage 1 – Determine the Question

• Guidance – What will guide decisions and change. (Policies and Rules) This should take around 3 days.

2) Model the “Enterprise Structural Model” (Current)

This is the entire enterprise in terms of breadth but not in depth such as: -

•

Shared Entities (Locations, Services)

For 1 or more executing projects: -

Stage 2 – Determine Required Data Stage 3 – Populate the Model Stage 4 – Integrate the Model Stage 5 – Answer the question Iterate….

---------------------------------------------------------------------

• Business Entities (Customers, Products, Activities, Departments, Functions)

Bottom Up - Tactical

If both approaches are adopted the model will grow from the bottom up and top down and meet in the middle.

──────────────────────────

Comments @Kinshuk: “ But what does the "business" think of an EA's role ?”

@Stuart: “In my experience, the business has no clue whatsoever about what an enterprise architect does”

Correct! I have an explanation…..

167

So I believe there is a job/role for someone called an Enterprise Architect but 90% of this role is to bring EA practises to organisations not do “do” EA. 90% of the act of “doing” EA is done by the board, executives, management and workers already in the organisation.

My explanation is that this is a problem because there is no such role as an Enterprise Architect as such. (Now that may sound like a complete load of tosh - but stay with me on this…. and see where it get’s us….)

I reserve 10% for the EA who has “brought” EA to the organisation to hold their hand and work with them for a time until they become proficient - some organisations may require this, some may not.

The only role an EA has is to “bring” EA to the organisation in much the same way that someone may “bring” Prince2 or MSP or ITIL to an organisation.

@Mahantesh: “Where do i start developing skills for enterprise architect” I believe that there is no such role as an Enterprise Architect as such. (Now that may sound like a complete load of tosh - but stay with me on this…. and see where it get’s us….)

For example, once someone has “brought” Prince2 to an organisation is there a role called a Prince2? No.

──────────────────────────

Before Prince2 “arrived” there were project managers, business analysts, technical architects etc etc etc. After Prince2 “arrived” there are still project managers, business analysts, technical architects etc etc etc.

The act of “bringing” Prince2 to an organisation has not introduced a lot of Prince2 roles, it has “adjusted” the organisation to adopt Prince2 practices. I believe it is the same for EA….

The act of “bringing” EA to an organisation has not introduced a lot of EA roles, it has “adjusted” the organisation to adopt EA practices.

For example, once someone has “brought” Prince2 to an organisation is there a role called a Prince2? No. Before Prince2 “arrived” there were project managers, business analysts, technical architects etc etc etc. After Prince2 “arrived” there are still project managers, business analysts, technical architects etc etc etc. The act of “bringing” Prince2 to an organisation has not introduced a lot of Prince2 roles, it has “adjusted” the organisation to adopt Prince2 practices.

This is a massive and fundamental point of understanding what EA is - and is not.

The only role an EA has is to “bring” EA to the organisation in much the same way that someone may “bring” Prince2 or MSP or ITIL to an organisation.

And because the “business” is not hearing this, this is why they still cannot understand EA.

I believe it is the same for EA….

The act of “bringing” EA to an organisation has not introduced a lot of EA roles, it has

168

Comments

“adjusted” the organisation to adopt EA practices.

This is a massive and fundamental point of understanding what EA is - and is not.

And because the “business” is not hearing this, this is why they still cannot understand EA.

@ALL: I have started a separate discussion “THERE IS NO SUCH ROLE AS AN ENTERPRISE ARCHITECT....” where this is being discussed… http://www.linkedin.com/groupAnswers?view QuestionAndAnswers=&discussionID=21004 247 (As always, you will probably have to cut and paste the link into your browser since linkedin urls get messed up in linked so they don’t work when you click on them (Their encoding of the &’s) ────────────────────────── @Venu: “…there will be a person who is in charge of EA along with a team of architects enabling and governing solutions …I worked in a Healthcare organization…to align their IT and are very successful.”

Everyone contributes their domains knowledge to the model, everyone can then query the whole for their own purposes.

Massively political? Yes. True? You decide...

──────────────────────────

@Jeffrey: "maybe developing and maintaining the organizations enterprise architecture! "

If your are referring to the EA Models - I would say no.

The EA models should not be developed and maintained by one person or one group of people. This is one of the things that causes EA to fail.

@Peter: “how would an enterprise manage the evaluation and introduction of new technology architectures as they become available” That would be done by the people in IT Exec Management and Architects.. Some people call the senior architects in IT Enterprise Architects but these are not “true” Enterpriser Architects, they are Enterprise IT Architects. @James: “If organization would step away from "classic management" to "modern management, we would then call EA "business management". “

They should be developed and maintained by multiple people in multiple departments. HR should be responsible for the departmental structure information, finance for the financial information, TA's for the applications, Business groups for the processes, directors and executive management for strategic goals and objectives etc, etc, etc, etc.

If I understand you words correctly this is what I would call Enterprise IT Architecture and not Enterprise Architecture.

100% agree.

Comments We may even say that “EA is IT’s awakening to Business Management” and “EA is Businesses awakening to IT Management. “

I cringe a bit when I say that because we are back on the Business vs IT debate when I think its more about Strategy vs execution but I think it’s an interesting point nonetheless. @James : “Often, business management doesn’t understand EA because understanding it would put into question there ways on managing/thinking.” Yes. And I think therein lies the problem… @ALL:

To concentrate the mind I would ask this question…

────────────────────────── @Bob: “@Kevin, 3 days for an “Enterprise Strategy Model” assumes that there's organization wide consencous (at the senior and middle management level) on what the ends, means, drivers and guidance are. Oh and they've been documented.” Correct - but not necessarily that they have been documented. @Bob: “10 days to model “Enterprise Structural Model” assumes that the Business Entities, Shared Entities and Technical Entities are known to, agreed upon and documented within the organization.”” Correct - but not necessarily that they have been documented. Don’t forget we are documenting the breadth not the depth here. At the high level every organisation has people that can answer these questions. e.g. if you go to each business unit and ask them to list their highest level business processes, they will definitely know that they are. IF you got and talk to the IT director and ask him the main 5 or 10 applications and technologies in use, he will definitely be able to tell you.

“What tasks would you list as being the tasks done by an Enterprise Architect?”

I first posed that in another thread and here is a question and a reply…

@Jeffrey: "maybe developing and maintaining the organizations enterprise architecture! "

If your are referring to the EA Models - I would say no.

The EA models should not be developed and maintained by one person or one group of people. This is one of the things that causes EA to fail.

I accept that some organisations may be so fundamentally broken that these people will not know the answers to these questions, but at this high level 99% or organisations will know. ──────────────────────────

@Tony: “what about - Thought leadership, vision, innovation, ideas, seeing the future and explaining to others how we will get to that future?” That’s the job description of Directors. So we don’t need an Enterprise Architect for that either” Admittedly the current crop of Directors may need some help and coaching, maybe even some of them replaced - but that is still part of “Implement” not “operate”

Everyone contributes their domains knowledge to the model, everyone can then query the whole for their own purposes.

169

170

Comments

@Tony: “I guess when Tom describes himself as a futurist, this encompasses my list of attributes.”

PR I agree - and Tom can perform that role of getting the directors thinking in better ways again it’s an “Implement EA” role not and “Operate EA” role. An this does not preclude a “Tom” coming back every now and then to light more fires.

@John: “I have to say that I am not really happy with the term EA. It seems to have too much 'handwaving' in its frameworks to be real architecture.” Sorry John but I don’t understand you point can you rephrase?

100% agree.

Google “famous people without degrees” you will get 20 million results… @ALL: I have started a separate discussion “THERE IS NO SUCH ROLE AS AN ENTERPRISE ARCHITECT....” where this is being discussed… http://www.linkedin.com/groupAnswers?view QuestionAndAnswers=&discussionID=21004 247 In the EA Network Group http://www.linkedin.com/groups?home=&gid =36781

@Tom: “One of the key points we need to imbue throughout the organisation/enterprise is that architecture and innovation - like safety, security, quality and all the other 'pervasive services' - are the responsibility (and authority) of _everyone_, not solely a select few stuck away in a backroom at Head Office. :-)”

EA is more about intelligence than knowledge and information. When universities start to teach intelligence rather than knowledge and information I would then agree with you.

@Bran: “Start with University Systems Engineering / System Science degree (BSEE) with minor in Computer Science (BSCS). Experience 15+ years in many verticals is assumed. Attending courses like TOGAF etc., without on-the-job experience (enterprise-wide projects) is futile.

I have to massively disagree. There are many intelligent and successful people who did not opt for the academic route. Steve Jobs, Bill Gates, Warren Buffet, Barack Obama, Donald Trump….

────────────────────────── @John: “My dissatisfaction arises from EA's seeming more evangelical, than down to earth. Architecture is about art, about science. That should be where our focus should be, and not making out that it is something completely different.”

Aahh - Yes and I concur. That is why I created a Pragmatic EA Framework.. “Cutting EA to the Bone”. Bridging the gap between minimal "EA Frameworks" which do not provide a complete set of what is required or huge monolithic “EA Frameworks” that are too difficult to understand and difficult to use.

If you want to proceed to Chief Architect role, you should also enrol in a University MBA Strategic Management & Finance and/or Marketing Management program, or MFE (Master of Financial Engineering) program. Good education foundation is the key in any professional career and EA is no exception”

(As always, you will probably have to cut and paste the link into your browser since linkedin urls get messed up in linked so they don’t work when you click on them (Their encoding of the &’s)

@Tony: “My Experience with most board level execs is this: "I don't know what i don't know, you need to tell me what i don't know" I spend my whole life working out

Comments

171

I don’t agree. What that creates is a bottleneck.

Yes - I don’t have a problem with that, but I put that in the “Implement” bucket not the “operate” bucket.

@Jeffrey: “Without this coordination and integration, all you wind up with is a bunch of disjointed pieces.”

I would also say that just because there are some organisations out there who need people to do the work they have been employed and paid to do (nowhere is this so rife in the realms of boards and senior management) that generally, the roles is a more of guide/mentor than a dooer.

I don’t agree. You wind disjointed pieces when central repository/tool information that people it stays in their silos.

what people don't know and describing what, how and why”

I believe that EA helps…

@Jeffrey: “Also, the individual departments are responsible for the lower level architectures that drive implementation” Agreed. But they are also responsible for the higher level abstractions of their domains.

Directors to Direct better.

Managers to Manage better.

@Jeffrey: “the EA team develops the higher level strategic models that drive these lower level architectures.”

Planners to plan better.

Workers to work better.

EA does not do the work of Directors, Managers, Planners or Workers.

@Nic: “"But really, at the end of the day, how much money are you earning or saving for your client or org? Can you track P&L or balance sheet results back to your efforts"?” “You”?

up with a bunch of you don’t have a to manage all the contribute because

You (or anyone) cannot measure the ROI of “doing” EA and when people counter EA by challenging people to produce an ROI for EA you had better stop them right there and then because if you accept the challenge a) you will lose and b) it is an invalid question. I don’t often agree with Gartner but on this point I do. They did a presentation at last weeks EA summit in London that dealt with exactly this point

@Jeffrey: “I would say that you are probably the only person on this thread that does not realize the importance of having an EA filling this role.”

I am used to being in a minority - that’s where new thinking and advancement lies. Just because only one person can see the earth is round does not mean that the earth is flat. @Jeffrey: “While the EA may have a number of people with skills in particular areas working for him on the EA team, there must be one person that coordinates everything and brings it all together into a cohesive model and strategy.”

Yes - in IT. And he should be called the Chief IT Architect although some people refer to him incorrectly as an EA.

──────────────────────────

What do you mean by “higher level strategic models” models of what ?

@Jeffrey: “Kevin - There needs to be a person or group that coordinates the architecture activities and brings all the information together.”

@Jeffrey: “And BTW - your link does not work.” Appologies - it should have been -

172

Comments

http://www.linkedin.com/groupAnswers?view QuestionAndAnswers=&gid=36781&discussi onID=21004247 - but you may need to copy and paste it. ──────────────────────────

@Nic: “Actually, Kevin, I disagree. Hard to measure, sure. Almost impossible to measure directly in fact - but measured it *can* be.” No problem.

@Jeffrey: “Kevin - I guess we are just going to have to agree to disagree.” Well we can, or, we can discuss it. I sense a large amount of anger and frustration in your post. I have met this behaviour many times before and it usually is exhibited by people who are very entrenched in their thinking and find it difficult to understand and take on board new ideas.

I read your examples and analogies but I’m still not convinced.

I don’t have a problem with that, but I do if they then close down and don’t want to discuss it.

EA is an enabler. A paradigm. A Method.

So, to answer your points…

Just as you cannot determine the ROI of Project Management, so you cannot determine the ROI of EA.

@Jeffrey: “You think that by piling things in one repository you get a cohesive whole. Good luck with that strategy. In my experience all you will wind up with is a pile of unintegrated garbage. It would be like dumping a bunch of disjointed thoughts into a repository and hoping to come out with a book.”

These are systemic disciplines that enable other stuff to happen. Now this other stuff definitely can have a ROI - portfolio optimisation, reduction in duplication, etc, etc. But the ROI is connected to those actions not to the supporting/enabling action.

To try to be a little clearer, I offer a conversation based on my view… Q: What is the ROI of EA?

A: It depends what you use EA to do?

aka you cannot determine the ROI of EA as such, only the ROI of things you want to do utilising EA. And even then it’s sometimes difficult. e.g.

Q: What’s the ROI of improving out Strategic Planning?

──────────────────────────

@Jeffrey: “If you do not know the difference between high level strategic model of the various domains and implementation level architectures I can not explain them to you here.” I think I do understand the difference but thanks for you offer not to explain them to me. @Jeffrey: “If you do not know what a strategic model is I suggest you do some reading.”

A: It depends what we do with our improved Strategic Planning.

Err no! I don’t think that at all. Have a look at the Strategic Planning” & “Modelling the Current State” Processes I have defined. That’s is the approach that I would advocate, not piling things into a repository and hoping as you suggest I am saying - which I am not.

I do know thanks.

@Jeffrey: “If you think that individual departments can develop their own strategic

Comments level guidance and have them come out as an integrated business strategy, again good luck with that.”

No I don’t believe that. That is the job of the Strategic Planning department in concert with The Board. @Jeffrey: “If you agree you need this coordinator to bring it all together in IT, why do you think it is unnecessary in the EA arena.” I don’t think it is unnecessary. I think that it is very necessary. However, I think that is the job of people already ion the organisation, namely The Board, Strategic Planning, and Executive Management, not some new group of people called “Enterprise Architecture”

Correct.

No. I didn’t say that. So I have no idea why you think I did. Fundamentally, for many thousands of organisations, the information that constitutes the architecture of the enterprise (aka the EA Model) already exists within those organisations. The problem is not that enough information exists, the problem is that there is too much information. It is also extremely likely that this information is stored/located in many and varied locations and in many different formats; excel spreadsheets, word documents, PowerPoint’s, Visio diagrams, access databases, corporate databases, on the intranet, diagrams on whiteboards or pasted to walls, in peoples heads, etc, etc, etc.

@Jeffrey: “If you think having a person to coordinate activities at the top creates a bottleneck, you must think that project managers and anyone else with broad responsibilities creates a bottleneck.”

173

@Jeffrey: “I would like to know how you would structure things. With no top level guidance, how do you ever get all the parts to come together.”

By using EA to make the adjustments to the organisation necessary for them to all work together more cohesively, not by introducing some new group of people called “Enterprise Architecture” ──────────────────────────

•

Be duplicated

•

Be out of date

•

Be stored in different formats

•

Owned by different people

•

Not have clear responsibilities

•

Utilise different sematics

Essentially populating the Current model boils down to a data cleaning and migration exercise with all the attendant problems, risks and issues that usually go with data migration. The data to be migrated is the information that already exists within the organisation, in peoples heads, in diagrams, lists, databases, etc, etc. The place the information is to be migrated to is the EA Tool’s repository.

@Laurent: “@Kevin: "You wind up with a bunch of disjointed pieces when you don’t have a central repository/tool to manage all the information that people contribute because it stays in their silos. " Would you assume that the simple use of a central repository and a common set of tools can preserve the coherence of the Information System? I wouldn't.”

In addition the information that exists will almost certainly: -

This is a serious problem and that problem is solved by utilising a centralised repository/tool to manage that information.

174

Comments Agreed.

@Laurent: “Shared repositories and tools are just tools helping to achieve information sharing.”

No. They don’t need to do architecture modelling, they need to (like everyone else in the enterprise) utilise what want and contribute what they can from the repository of information and models..

When the information is brought into one place, the elements can then be related which is where the massive benefit of models comes from - not the “boxes” but the “lines”. When the “boxes” are all over the place you can’t draw any “lines”.

100% agree.

@Laurent: “But they don't prevent people to design and build solutions that are not consistent with the global IT Strategy.”

Correct. That’s what governance is for,

100% agree. But I am not saying that.

@Laurent: “This is what governance is about: checking that individual behaviors don't put at risk the global IS or don't penalize others at a larger scale of the enterprise.” 100% agree.

@Jeffrey: “It makes far more sense to introduce an EA role or small EA group into this organization (where it exists) rather than try and train the existing people on processes and methodologies that take years to learn to do well.” I don’t agree - trying to get budget to employ a “small EA group” is next to impossible in most organisations. Helping them adjust what they do with training and mentoring is much more viable.

For instance, if you have 30 projects, each choosing a different application server or application platform you will have extra CAPEX and OPEX (and consider the mess for the Operations team), even if those projects are well documented in the repositories.”

@Jeffrey: “If you are proposing that we teach existing people in this 'strategic planning department' how to do archiecture modeling, I think you are asking a lot.”

──────────────────────────

@Jeffrey: “Very few companies have a 'Strategic Planning Department", while most do have strategic plans. “

@Jeffrey: “EA brings a disciplined approach to the strategic planning by introducing modeling to guide the actions needed to achieve the stated goals.”

If a Strategic Planning Group does not exist then one should be set up, not an EA group. In my experience one of the major problems with EA adoption is senior execs thinking that Strategic Planning will be done by some other group - called EA. Enterprise Architects do not do Strategic Planning, Strategic Planners do. @Jeffrey: “The EA group can then feed the information from the architecture efforts to the senior leadership in the company to make the strategic decisions.”

Correct - therefore there are people who do strategic planning. EA does not wrest this responsibility from these people and put Strategic Planning in the hands of someone or group called EA.

@Jeffrey: “Where no strategic ppanning department exists, it is just as easy to call this new organization an EA organization as it is strategic planning. In fact, where no strategic planning department exists, it makes more sense to call it EA s that senior execs do not feel llike their authority is being usurped.”

I don’t believe this fictitious EA group does that. Every part of the organisation feeds

Comments architectural (aka structural) information into the repository.

@Jeffrey: “It seems like you are pushing your own organizational approach which competes with the EA concept and are doing so through your responses” It’s not my concepts. It’s called “proper” EA. @Jeffrey: “I also think you are confusing the process of building the models of the enterprise which is the role of EA with the making of decisions based on those models and their outputs which is the role of the senior managers.” Again, I disagree. All groups in the enterprise contribute to the models. All groups utlise the models.

Again. All groups in the enterprise contribute to the models. All groups utlise the models. @Jeffrey: “Another question - How do you propose to keep things organized and running properly on a project wihtout a project manager? I have seen what happens to projects where there is no effective management, they fail miserably. I do not know what background you come from, but in my world good PMs are crucial to success.” I have only been in industry for 30 years and in all that time I can honestly say that the majority of projects I have worked on have failed to one degrees or another. Sometimes catastrophically. the reason is always politics in general and the PM in particular. In closing, someone sent me some information (I can’t find it now) about a study where two IT teams/groups were set up. One group had Project Managers and the other did not./ The group without any project managers consistently out performed the group that did in time, cost, quality and fitness for purpose.

@Jeffrey: “The EA group merely presents recommendations for changes to structure, processes, etc. based on the architecture efforts, they do not make the decisions.” I call that the Strategic Planning department.

@Jeffrey: “To expect senior managers to have the time, sklls, or inclination to pull together models from various departments into a cohesive whole to drive decision the making is a little unrealistic.” I don’t expect that. All groups in the enterprise contribute to the models. All groups utlise the models.

Now I am not saying there is no room for a “good” PM, and I have worked with a couple, but anyway - this is a completely different conversation - projects, project managers, and failure. @Jeffrey: “I do not know how you run a business without mangers to plan and oversee the work as well as set direction for the organization.” Correct - managers. Not EA’s

@Jeffrey: “ I am also not sure if you understand what an EA does. Your resume lists your title as Enterprise Architect in many posiions when you were working in IT. There really is no true EA in the IT arena, there are those that are called enterprise IT architects (a co-opting of the EA term) which are not true EAs. True Enterprise Architecture is much more than IT and

@Jeffrey: “I am not espousing the introduction of some huge new EA organization into a business. The EA organization, depending on the size of the company, could vary from a part time consultant for a small outfit to a group of maybe four or five good architects for a large company. This group is not designed to usurp the authority of any existing organization, it is merely to develop and maintain the high level strategic models, processes, etc. that are needed to make good strategic business decisions and optimize the operations of a company.”

175

176

Comments

encompasses all aspects of the business enterprise.”

Ooooh! Gettting a bit personal now. It’s OK though. I can take it. I am an Architect.

Yes - I think I know what “true” EA is. I have created an EA framework, that is being utlised all over the world and I receive compliments every week from the others who also understand what “true” EA is. @Jeffrey: “I am also confused by your disdain for the EA title”

You confuse disdain for pragmatism and altruism.

@JD: “Kevin as you say "a complete load of tosh". Its like saying that an enterprise has no need of ongoing business architecture and technology architecture.“ I don’t agree. @JD: “Clearly there is a need for both these architectures, and they have to be created and kept aligned by somebody.” 100% agree. @JD: “Otherwise, who ensures that business strategy is supported by business architecture which, in turn, is supported by the vatious technology architectures? The title is unimportant, but the role is critical.” 100% agree. However, that role is carried out by multiple people in the enterprise not by one person or group called an Enterprise Architect.

When your resume refers to you as an EA in many positions, including your current one. It really seems like you are trying to push your own organizational ideas and your own consultantcy with little hard metrics or evidence to back up those ideas.”

──────────────────────────

Do you think we could keep the discussion to the point?

@Jeffrey: “ You even seem to directly contradict yourself when you say there is no such role as EA, but then turn around and call yourself one. Which is it, does the role of EA exist or not - or is it that you think EAs can only exist as consultants?”

There is a role for an EA and that is the role of “bringing” EA to an organisation. This may or may not also include a degree of hand holding and mentoring for a time until the swimmer is more confident of the strokes. The Enterprise Architect may then return once in a while to review progress and introduce new strokes.

But then again, just because others agree with me doesn’t mean I am right in the same way that being in a minority does not mean I am wrong.

Cool - At least that puts to bed one of the accusations I have heard that I am the only one who believes this. To help others understand more I would also ask them this question (my figures are pulled out of my head and we could quibble about them however intent remains….) Let’s take a pool of all the enterprises in the world that are not “small” - say over 300 employees…. I would suggest that at the very least 90% of them do not have a group called Enterprise Architecture and do not employ people called Enterprise Architects. (I do not include those called EA’s but in fact are doing E-IT-A.)

I would only say this in closing, I do not stand alone. There are other who believe the same as me more or less. Including Gartner (with whom I don’t normally agree)

@Kirk: “Kevin - I agree completely.”

Question: How could these organisations possibly exist, let alone be successful, if they do not emply Enterprise Architects.

Comments

Answer: Because they are “doing” EA already. They just don’t call it EA. They are either a) “doing” it very well already - in which case they have no need for frameworks or Enterprise Architects, or b) be doing it very badly - in which case frameworks and EA consultants that can help them adopt EA practices can be of massive help to them, or c) sit somewhere in between. @Jeffrey: “You say this, but then list your own job title in your profile as Enterprise Architect for a number of postitons you held. Make up your mind, either they do exist or they do not.”

Some of the positions that are tagged as “Enterprise Architect” are what I would consider to be the role of an EA, that is, the role was to “bring” EA to the organisation.

I was trying to make a point and used a bad analogy. This is why I hate (but also love) analogies - If they are taken in the spirit that they are meant, they can be an aid to understanding. If they are not, they can easily be turned into a stick with which to beat someone. @JD: “It is often the case that processes and technology are more of a problem than "people not playing together nicely". In fact all three people, processes, and technology are of equal significance within enterprise architecture.” I would say that "people not playing together nicely" aka politics and process (bad or a failure of good) are the two things that I have seen that cause projects to fail and millions of dollars to be wasted (which is bad enough, but the worst crime is the time these projects waste - you can always get more money, time you cannot get back)

Some of the positions that are tagged as “Enterprise Architect” are what I would consider to be E IT A roles.

177

Some of the positions morphed into a mixture. My resume has to list the job titles that were given to me by that client, not the job title that’s I thought they should have allocated me. The reason for the ambiguity is the ambiguity in the marketplace and in organisations all over the world.

This is true of other roles where I performed as a Solution Architect even though the title provided (and therefore I have to list) was of a Technical Architect and vice versa.

True.

@JD: ” <@Kirk: “governance process, a behavioral modification effort, a steering effort, and a "remove impediments" function”> are all associated with organizational culture which, traditionally, is not even considered a part of enterprise architecture (except for Kevin who as it in his pragmatic approach.)” I believe it is considered to part of “true” EA by all “true” Enterprise Architects out there. I know I am in a minority - but I am not alone. Even I was the only one, do you really think that I care? I am but a humble man but I believe that progress is usually born from minority.

@Jeffrey: “And your Prince2 arguement is a red herring. Prince2 is a project management framework. There is no such role as Prince2, the same way there is no such role as DoDAF or FEAF, that does not mean there is no such role as Enterprise Architect.”

I have never ever seen a project fail because of technology. I have seen technology be a symptom of an underlying problem, but if you do a root cause analysis it always comes back to people and process issues.

@JD: “Culture is the people part of people, processes, and technology.”

178

Comments

I don’t agree. IF I had to choose from those 3 words I would say that Culture is the people and processes part.

PR @Kirk: “once in place, everyone participates.... everyone is an enterprise architect. EA has just defined the rules of engagement, conditional on business initiative requirements.” 100% agree.

Murali: “Unless we have a clear common definition for EA, every one tries to define the roles and responsibilities of their own.”

True - did you see the 160 Char Challenge and analysis? http://www.pragmaticea.com/160challenge.as p @Tony: “Once you have brought EA to an organisation, what happens then?”

@Tony: “Just because a board should be thought leaders doesn't make it so.(Board member: "I don't know what i don't know, you need to tell me what i don't know")” Board members don’t necessarily need to be thought leaders. They need to be Directors. Thought Leaders (am I one???) can be brought in by boards every now and them to help them to think perhaps in different ways and show them paths that they didn’t not know existted, but if you work with a though leader everyday you will have some great conversations but never do anything. @Tony: “As part of "Operate" in your implement / operate model, the Operate could loop back to implement (of a fashion) if there is a paradigm shift in the business operating model.”

As I explained above “Operate” can link back to “Implement” but only through “Prepare”. You can’t implement changes if a) you don’t know what they are and b) have not got the remit and budget to “Implement” the changes identified.

They operate their enterprise utilising the adjustments that were made.

@Tony: “I agree at a level about bringing EA to organisation, but isn't EA iterative?”

Yes - Well the adoption of EA is iterative / based on maturity. EA maturity is itself a journey and, initially, an organisation may want to determine some small steps (Prepare), make some adjustments identified to their enterprise (Implement) and the operate utilising those adjustment (Operate). After some time (6 months, 12 months, 2 years….) they may wish to take more steps down the EA maturity path and hence there is another iteration: Prepare->Implement>Operate.

I’m not sure what you meant by invent something. Are you saying the EA’s invent something? What?

No.

@Tony: “We have agreed that EA are born not made.” 99% agree. Conceptually.

@Tony: “I agree that the Need for an EA in some organisation can be limited to times of immense change” I would say that the need for a documented Enterprise Architecture (i.e. models) is definitely needed in times of immense change. That’s why some of the catalysts that cause organisations to start to build one are basically all about large change…(Mergers &

@Tony: “As i have said before you can teach anyone to maintain something, it is quite different to invent something, which, in my opinion is incumbent on an EA.”

@Tony: “If a set of consultants arrive, implement EA, teach member of staff to maintain the EA, then go, are you suggesting the need to bring the consultancy back when you need innovation, invention, thought leadership etc.”

Comments

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

Regarding the need for an Enterprise Architect - yes, because building an EA model is part of “doing” EA and therefore they are making their first step to adopting EA practices and products and would therefore need an EA (and probably a framework) to help them.

role as Enterprise Architect, you just think it only exists as a consultant.” I’m sorry If I gave that impression - What I am countering is that there should be a team of people called EA’s that do strategic planning, modelling architecting etc. This is what I mean when I say there is no such role. There is a role for EA’s to bring EA practices and products to enterprises. This is a transitory/consultative role. Part of that role may be to mentor the adjusted enterprise for a time. But like I said - happy to continue this discussion - but in the proper thread where you will find other people that agree with me you can discuss with (aka http://www.linkedin.com/groupAnswers?view QuestionAndAnswers=&gid=36781&discussi onID=21004247 - but you may need to copy and paste it.)

It is also true that perhaps that person can also be a trusted advisor/thought leader.

179

@Tony: “and therefore keeping a true EA on staff may not be value to either the EA or the organisation, in other organisation having a permanent EA capability is worth it weight in gold (or time cause that's more valuable!)” Agreed - but that EA is mostly concerned with making sure that the well oiled machine is still working properly rather than doing the strategic planning etc- sort of like an EA Quality Manager???? ──────────────────────────

@Jeffrey: “Kevin - I give up, you have an answer for everything.” If I have an answer to a question, then I give it. If I do not know something, then I say so.

EA is a methodology/culture with associated processes and products that enterprises can use to improve everything they do. Introduction of EA tends to be a subtle change to the existing enteprise rather than the imposition of a group called Enterprise Architecture.

I would encourage you not to give up, but to continue to discuss things as this is the only way that you will change others minds or have your own changed.

@Francois: “@Kevin - when you are stating "proper EA", i do believe that you have experience in this domain, and you have challenged existing practices to come up with a reference. You said that you have created an EA framework which is distributed all over the world, and you are getting positive feedback about it. Congratulation. I'd therefore appreciate that you elaborate on, according to you, what EA should be (vs what EA shouldn't be). So that I'll benefit from your experience. Which is one key expectation I have when reading posts.”

@Jeffrey: “Of course you have now backed off on your statement that there is no such

EA is pervasive and everyone in the enterprise will be a little bit of an “Enterprise Architect” EA is nota vertical, it is a horizontal, systemic culture.

180

Comments

EA in scope covers the entire enterprise not just IT. This is counter to what many people think EA is (made worse by frameworks such a TOGAF that sell themselves as EA frameworks) Most people erroneously think the E in EA means Enterprise Class IT - i.e. large scale. This is not “true” EA. ──────────────────────────

@Tony: “Yes i am saying that EA SHOULD invent stuff, maybe not products (but maybe). Usually i see thing other don't, a way of operating more efficiently, ways reaching new customers etc. Isn't that Invention, combing things to do something new? Or at least coming up with an idea of how to achieve that, and then selling that into a board for funding?”

In fact what I advocate is the only way to utilise and EA repository otherwise you get a massive bottleneck which has to be staffed to alleviate it. Better to allow the people who “own” the information, to maintain it. @Larry: “We then got a CTO, a group of enterprise architects (with a chief architect), application, database, security and infrastructure architects. The enterprise architects set the strategy and vision, the other architects took the vision further down into design models to be used and worked with the solution engineers and lead to developers to implement the shared vision. This isn't to say that the enterprise architects didn't communicate with the developers, but they also had to be in lock step with the business executives to be able to provide solutions when the business is ready to implement new products or strategies. All while keeping abreast of emerging technologies and trends that could provide ROI and benefit to the enterprise.”

Agreed that you could do this because as Architects we could probably do everyone’s job. (I know I could!) And will almost certainly add value in anything we do.

What I am saying is that the EA Repository is contributed to by all and used by all. Not one group called Enterprise Architecture.

However, all the things you describe is what Directors and Executive Management are for. Sometimes the Board and Management will seek the advice of a thought leader or management consultant. Sometimes not, But at the end of the day, that is their job. That is what they are paid to do.

@Tony: “EA are not librarians, not to me anyway. I think its part of the job, defining artefacts, ensuring they are upto date, contextual and accessible.” Hmmm - actually I think that maybe they are more like librarians - making sure the knowledge flow happens as and when required……. ──────────────────────────

No - I am not advocating that.

This is not what I mean when I talk about EA. @Larry: “The belief that an enterprise repository will make everything all right. We had several in management who advocated that approach and it was tried. And failed miserably. Because what we found in a large enterprise is that, like you said, there is so much information and so much disparate process that it all becomes a big mess when you try to make something cohesive out of it.”

@Larry: “In small enterprises you can, like Kevin suggests, allow the departments to each provide vision and strategy for their areas that will then flow into the whole.”

This isn’t “true” EA. What you describe is absolutely necessary and what is called E-ITA although many people call the EA.

An EA repository is a tool. For those who use it incorrectly (like you suggest by having

Comments a central group of people tasked to maintain it) it will definitely fail.

@Larry: “Enterprise Architecture isn't a tool or a technology. It's not only rebuilding an organization's technology and design approach, but its also about process reenginnering around things like a standard SDLC process, source control, release management, controlled builds and deployments and all the other things that go into providing support for a very large scaled environment to be able to build and deploy applications that meet business objectives with good quality, on time and on budget.” Your totally IT centric view of EA is what I (and others) are trying to change. @Francois: “I'd like to refer to some known framework. Since framework was part of a post. Call it TOGAF.”

181

100% agree. @Francois: “an EA architect is one of the key contributor for making this decision framework to become reality. And to be governed.” An E-IT-A yes. but that is only 10% of the people contributing to the EA model. But can any further posts on this subject now move to the “THERE IS NO SUCH ROLE AS AN ENTERPRISE ARCHITECT” discussion as I am aware this is totally off topic. http://www.linkedin.com/groupAnswers?view QuestionAndAnswers=&gid=36781&discussi onID=21004247 (Note you may have to cut and paste the link) ────────────────────────── @Nick: “With respect, Bob's objection stands. The fact that a consensus is not documented is a symptom of a deeper problem: that the senior management level PREFERS that lack of clarity. Either the culture doesn't support validation, or that validation would reveal problems that senior leaders do not want to solve because some will win and some will lose.”

#1 TOGAF is not an EA framework.

#2 When you say framework - are you referring to a Metamodel or a methodology with processes and products (one of which is a Metamodel)? @Francois: “ “EA addresses 4 architecture domains. Business, data, application and technology. To design EA, it requires to define baseline and target for each of these domains. from business (strategy, core processes, organization, governance) down to technology (infrastructure, middleware, network, processing, standards,...)”

This is E-IT-A. Had you included the Enterprise Stratetegy, Portfolio and governance models then it would be closer to a full EA model. But even then it also needs to extend to include the enterprise (as distinct from the organisation)

100% agree.

@Nick: “The primary resistence to enterprise architecture rigor is not ignorance. It is an inability or unwillingness to be accountable, consistent, collaborative, and interdependent.”

100% agree.

@Nick: “Therefore, in situations where the business motivation is not documented, very few companies will reach consensus in a very short period of time.”

@Francois: “One EA key deliverable for me, again , is this decision framework provided by the (ideal) holistic view of the enterprise. Decision makers are then having materials to support, assess their decisions.”

This short period of time is based on being asked by the organisation to do this work. Ergo, whilst they may have not wanted clarity in the past, they have decided that a) they want it going forward and b) they

182

Comments

believe that an EA approach may help in this and other regards. To that aim, they have employed the services of an EA to take their first step.

For an organisation who’s board and executive management do not want to be accountable, consistent, collaborative, and interdependent they would not have commissioned the work in the first place.

@Nick: “<@Kevin"At the high level every organisation has people that can answer these questions"> And they will usually conflict with one another. If you get one answer, you are probably asking too few people :-). Companies that don't have difficulty on a particular question are companies that have answered that question before. In that context, the answer IS DOCUMENTED.”

@Nick: “This is management consulting, but not sustainable enterprise architecture. It is useful, but doesn't support a long-term goal of simplifying the complexity that drags large corporations down.” In a way, yes, it is Management Consulting. However “simplifying the complexity” although generally a good aim is not a valid approach in some cases. EA does not simplify the complexity. EA provides a culture and environment for the people emplyed by it to make better and more informed decisions - one of which may or may not be to simplify the complexity.

100% agree. I never said that there would not be conflicts. I would be massively surprised if there were no conflicts, for, as you say, that would indicate that it is already documented and agreed.

I disagree. I operate on value not cost. Efficiency is Key. Just because something is costly and takes a long time does not mean it produces large value. Just because something is cheap and takes a short time does not mean it produces small value.

@Nick: “I have seen literally dozens of projects where consultants come into a company, spend 90 days, and produce a quick set of questions and answers, produce a report and leave.” Yes - I have seen this many many times also. It is truly shocking.

@Nick: “The process you describe is followed by a wide array of consulting companies. It is not unique to your process library. (that's a compliment of sorts).” The process I describe is not the same however. It is well documented on the site so I will not paste it here.

Hi Johan,

No I did not read the rest of your article. Many apologies :-)

But I Have now.

You're post here touched a nerve but that nerve is only really in name more than substance. We are coming at tools from 2 different perspectives and my perspective and the mental baggage I carry as a result is based on a quote from Gartner, in the context of Enterprise Architecture. (Note that Gartner still thinks of EA as largely an IT centric discipline which is not my belief) There are many problems with organisations adopting “true” EA (tEA????).

@Nick: “Unfortunately, the insight produced is as valuable as the amount of time spent to produce it. E.g. this kind of effort is short term and ad-hoc. It has no real impact on the company processes. You can only influence a small set of decisions at one point in time.”

──────────────────────────

What Gartner seems to be saying is that don’t’ start by buying/using a tool - even though many organisations have very successfully adopted this approach as evidence by a presentation by Colin

Comments

Birchenalls at last weeks conference where starting with a tool was the absolute best approach for Serco and Glasgow City Councils LLP and for the many successes they have achieved in growing up to the full EA level by delivering massive and real value.

But to answer your question “What are your experiences in successfully adopting a tool?” Having spent over 30 years in industry and growing up through the IT route I have seen many IT tools in use and mostly with great benefit. Maybe it’s because IT people just “get” tools. IT people tend to be able to just generally “use” tools without any training apart from a quick look in a help file every now and then.

If you want to see the EA Tool discussion I referred to, its on this lineked in group http://www.linkedin.com/groups?home=&gid =36781 and on this thread http://www.linkedin.com/groupAnswers?view QuestionAndAnswers=&gid=36781&discussi onID=20329940 ────────────────────────── @Nic: “after about a week or two of looking at an operation, I would feel confident enough (if i can get the data and answers to my questions) to put forward an action plan, and some measurable KPI's for raising the EA game within any particular company.” Yep - I agree. Not the ROI for doing EA but the ROI for (whatever you find out) utilising EA methods and tools. @Choukran: “I’ll add, it’s a problem solving, out-of-the-box thinking, vision, get familiar with EA framework (such as TOGAF, DoDAF), forget about Zachman, and the most important is your users.”

Business people, however are a different kettle of fish and, since EA tools are meant to be used by just about everyone in the organisation and the more senior and business oriented the better, EA tools perhaps have a harder time in terms of acquisition and also in terms of being used correctly.

In terms of just EA tools, my experience has been very bad. There have been only 2 places I have worked that adopted a tool (Casewise in one and System Architect in the other). In both instances they had been acquired long before I arrived and were very old. They were either not being used or being used incorrectly.

TOGAF is not an EA framework. (yes it’s a framework because it has methodology, products and guidance - but its E-IT-A not EA.

Zachman is not an EA Framework. (Yes it’s EA because it covers the enterprise, but not a framework because its is just a MetaMetamodel. with no products, methodology or guidance) @Robert: “everything should be process driven and that includes architecture,” 100% agree.

@Robert: “Businesses think in terms of vision, strategy, information and processes, i.e. Suppliers, Inputs, Processes, Outputs and Customers. Enterprise Architecture brings coherence across an organisation, rather than specifically focusing on a particular process and/or project.”

Acquisition of EA tools also have cost problems as people perceive them as expensive. Some of them are, but some are free. However, the expense of the license is actually not the problem. The expense of training and integrating (culturally) the tool is the much bigger problem and where many companies that swallow the license cost come unstuck. Ultimately the “project” fails and then people think that adopting a tool was a bad idea, when in fact it’s not the tool that is at fault but their adoption processes.

183

100% agree.

184

Comments

@Robert: “It’s the coherence that EA brings to the organisation that’s important: TOGAF, DoDAF, Zachman, and Archimate means nothing to the business, are far too technical and only serves to confuse and cause disillusionment.” 100% agree.

@Robert: “EA should be thought of as part of the Quality Assurance of an organisation; quality is not free but its practice should more than pay for it or to use another old Quality mantra from The BSI, "get it right, get it right first time, get it right first time every time" and this is one of the objectives for EA” 100% agree.

──────────────────────────

the Operate phase(s) definitely should not be done by a consultant, however the Prepare and Implement phases could be done by a consultant or a mixture of the two. @JD: “Who within the business is responsible for the necessary cross-discipline and cross-domain coordination and integration? Who is responsible for the ongoing iterations of future EA. To suggest that this might be the responsibility of a ‘steering committee’ is to turn a racehorse into a camel! The ‘committee’ approach would create the same sort of siloed, suboptimal systems, processes, and practices that have plagued IT for these last many years.”

Better a committee of board members and executive than one person calling himself an EA. Of course there may be a “EA” group but since this would consists of more than one and would definitely have to include representatives from all over the enterprise isn’t this a committee?

@JD: “Prince2 and EA are not equivalent, one is a method and the other is a concept.” @JD: “EA is, in large part, a method”

So do you believe that EA is a method or a concept?

@JD: “Having introduced the EA methodology, trained people in its use, institutionalize EA practices and processes”

That’s great This is what I would call the Prepare and Implement phases - which methodology did you choose? An existing one? One you created? A mixture?

That’s great too. What I would call the “Operate” phase. I would disagree though that a consultant should not do all of these. I would say that

100% agree.

And actually you have now hit the nail on the head that I was rather surreptitiously driving at. There is actually a role for someone called an EA, but as you say their role constitutes only 10% of the act of “doing” EA. Many people do not understand this. Many people think that EA is not systemic but in the hands of the god’s who call themselves Enterprise Architects. This is actually one of the (many) risks associated with EA that must be mitigated especially with the business as if they misunderstand this there is no way they are going to even look at EA.

@JD: “built the various models current and future state models and architectures, developed a future vision and an implementation roadmap, what then? All of these activities could (but should not) be done by a consultancy.”

@JD: “By training people in the EA method, institutionalizing EA practices and processes, 90% of EA is ‘done’ by everybody. The remaining 10% is the responsibility of enterprise architecture. Some people, and I am one of those, would argue that this approach is EA done right.”

Comments

185

Enterprise Architect Type 2 (EA Operation) – Job Description

And so, to make people sit up and take note, I reduced this 10% to 0% (which is still possible actually) to make people think about this radial idea that turns out to be not so radical at all.

=============================

Thius is why identifiying and dispelling these myths is part of the Prepare phase.

Now you may say that this is a U-Turn or a climb down, and I fully agree that it may seem like that.

• Duties will involve the ongoing maintenance of the business and IT Strategy, participation in annual business planning, and chairing the Architecture Review Board. • Must be able to analyse complex business and IT environments and determine various solution scenarios. • Must be able to home in on key and core issues and then propose unique scenarios and roadmaps for their resolution. • This is a senior role and therefore excellent interpersonal skills are mandatory.

However, to dispel that thought, I would like to point out that since PEAF first coalesced in November 2008, it has (and therefore I) have defined type 2 “types” of EA….One is a methodologist that can also be an Architect. The other is an Architect, that can also be a methodologist. In software terms you can think of one being the architect/developer who uses tools/frameworks to do write business software and the methodologist as the architect/developer who produces the tools/frameworks for others to use….

• Enterprise Architect required to work closely with the Strategy directorate.

Enterprise Architect Type 1 (EA Prepare & Implement) – Job Description =============================== =

• Enterprise Architect required to design and instigate an EA initiative.

• A wide experience is required of all technologies and as many vertical applications as possible coupled with a deep understanding of the clients business. • Personal qualities required: Pragmatic, enthusiastic, agnostic, articulate, persistent, strategic, enduring, open, altruistic, diplomatic, curious. Typically this is a permanent role.

• Must be able to articulate and gain buy in from business and IT leaders across the organisation, and be able to convince the board of the benefits that EA will bring.

You can see these in the Culture section of PEAF at page 22 in http://www.pragmaticea.com/displaydoc.asp?DocName=peaf-culture-relationships

• This is a senior role and therefore excellent interpersonal skills are mandatory.

You can also see the role of the Enterprise Architect in the processes of EA at: -

• Experience of multiple frameworks required such as PEAF, MoDAF, FEAF, Zachman, TOGAF, etc.

Prepare - http://www.pragmaticea.com/peafprocesses1-prepare.htm

Implement http://www.pragmaticea.com/peafprocesses2-implement.htm

• Personal qualities required: Pragmatic, enthusiastic, agnostic, articulate, persistent, strategic, enduring, open, altruistic, diplomatic, curious. Typically this is a transitory consultative role.

Operate - http://www.pragmaticea.com/peafprocesses3-operate.htm

186

Comments

Can we all be friends again? ──────────────────────────

PR @Larry: “@Jeffery - can't argue with you.We had all the "big boy" consulting companies in with their methodologies. Needless to say, we got some great looking Powerpoints about "future state" and no real roadmaps on how to get from where we were to where we needed to be.”

Yep - I can relate to that. I have also seen it many times.

One of the problems with EA is that some parts of industry and even some analysts (who look like analysts but are in fact consultancies) have a vested interest in making it look big and expensive.

@Larry: “Most of the companies I have worked for and the companies I have worked with as federated partners have pretty much a similar approach when it comes to "architects".” I agree - but that doesn’t mean they are doing “true” EA. They are all mostly doing EIT-A. You can see this with the widespread adoption of TOGAF which although many think is an EA framework is, in fact, an E-ITA framework. More and more people are realising this and the appetite for “true” EA is growing. You are probably doing Architecture if you are…

Enterprise

1. Talking to the CEO/MD and CIO

It’s a shame to see one of the main cancers affecting organisations (politics and personal greed) infecting the EA profession which mission is to counter the politics and personal greed that crucifies many organisations.

objectives with good quality, on time and on budget.”

2. Concerned with strategy and planning 3. Working at an enterprise level giving direction to all projects.

@Larry: “I wouldn't say my view is "totally" IT centric,”

4. Working with strategic planning

Yes I would agree not totally IT centric, but IT centric. (Isn’t Totally IT centric an oxymoron?) I was only going on your previous words, 99% of which were IT related and what you are talking about is IT Architecture….

You are probably doing Enterprise IT Architecture if you are…

@Larry: “Enterprise Architecture isn't a tool or a technology. It's not only REBUILDING AN ORGANIZATION'S TECHNOLOGY AND DESIGN APPROACH, but its also about process re-enginnering around things like a STANDARD SDLC PROCESS, SOURCE CONTROL, RELEASE MANAGEMENT, CONTROLLED BUILDS AND DEPLOYMENTS AND ALL THE OTHER THINGS THAT GO INTO PROVIDING SUPPORT FOR A VERY LARGE SCALED ENVIRONMENT TO BE ABLE TO BUILD AND DEPLOY APPLICATIONS that meet business

1. Talking only to the CIO 2. Concerned implementation

with

design

and

Comments

187

in one 160 character SMS message (including spaces, punctuation and carriage returns)?”

3. Working at individual project level 4. Working with project planning

5. Working with the IT of the enterprise (Processes, Services, Applications, Databases, Technologies, Networks) 6. Working largely at a physical level

7. Working with HR on Technical role definition. 8. Focus - Operational

@Larry: “If there is another discussion that goes more in depth, let me know and I'll take a look.” There have been many (and I suspect there will also be many in the future) in the EA Network Group as well as the TOGAF groups.

It has over 1,300 posts and contains a lot of what you are looking for from some very eminent people in the EA world. http://www.linkedin.com/groupAnswers?view QuestionAndAnswers=&gid=36781&discussi onID=8240387 As always because LinkedIn is almost dying on its legs, you will have to cut and past the link as linked in cannot handle links to its own discussion. Strangely, linked also doesn’t seem to be able to count, as, if you go to the main EAN page and click on the “Most Comments” tab (I assume to see a list of discussion that have the “most comments”) it’s not listed.

One that contains a lot of good stuff is “CHALLENGE: Describe the purpose of EA

188

Comments

Appendix

189

APPENDIX Sources

Book cover: Tropical Storm Lee - NASA/NOAA GOES Project Science Team. Technical Debt - www.wikipedia.org/wiki/Technical_debt Zachman Framework - www.wikipedia.org/wiki/Zachman_Framework TOGAF (The Open Group Architecture Framework) - www.opengroup.org/togaf/ Business Motivation Model - www.omg.org/spec/BMM/ Enhanced Business Motivation Model - www.MotivationModel.com ITIL (IT Infrastructure Library) - www.itil-officialsite.com COBIT (Control Objectives for Information and Related Technology) www.wikipedia.org/wiki/Cobit

♦ ♦ ♦ ♦ ♦ ♦ ♦ ♦

Resources

♦ The Pragmatic EA website (www.PragmaticEA.com) is the official source for all PF2 related materials.

PR F

,!7IB9A8-ecefbi!

Without proper preparation, every Enterprise is sailing full speed into their own perfect storm.

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

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!

EA on Arguments & Apologies, Diatribes & Debates. Volume I

Kevin Lee Smith

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.

Arguments & Apologies, Diatribes & Debates. Volume I

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.

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.

EA on LindedIn

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.

Kevin Lee Smith

ISBN 978-1-908424-51-8

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

The Pragmatic Gardener

https://www.linkedin.com/in/kevinleesmith/

Connecting the DOTS

Part of the Pragmatic Family