This page lists all the questions, answers, comments and statements Pragmatic EA have made in response to a multitude of postings on numerous discussion boards.
The postings are in date order (oldest first, newest last) and begin with an initial question or comment made by someone (shown in bold with a grey background). The responses are show in normal text with any other sub questions shown in bold.
Thank you to the many people who asked questions or raised issues about EA in general or PEAF in particular. It is only from full, frank, and open discussion that we advance our thinking and hence the profession.
Carol: "are you saying that all artefacts in the boxes outlined in black belong within the domain of EA?"
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.
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.....
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.
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."
We can learn a lot of lessons from TOGAF , but sometimes you have to bite the bullet and start again. TOGAF is touted as being "open" which all sounds very 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: "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."
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.
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 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.
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.
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.
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.
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. "
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 terms of flexibility I wouldn't agree, I think all three are just as flexible.
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."
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."
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.
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.
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 create intermediate states and the associated plans.
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.
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.
We, therefore, do not need to impose on ourselves any more.
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.
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 selfinterest 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.
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.
Kirk: "1-Companies are ignorant of what enterprise architecture really is?"
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?
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.)
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.
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.
This of course had the really bad effect of completely confusing people and describing EA as something that it is not. I really think 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 3-6 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.
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.
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.
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.
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.
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.
Steve "...less an issue of desired result and more one of the politics and background of the players."
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?
Bob "WHAT criteria were used for this comparison?"
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.
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.
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?
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 wrong and if so what they should be and why?
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."
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.
Steve "Is the value of any EA Framework really determined by the size of the documentation?"
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.
It is one of the reasons organisations repeatedly make the same decisions and then are surprised by the same outcomes.
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.
Churchill was only one man but is testament to what 1 fat man and a big cigar can do!
"Men occasionally stumble over the truth, but most of them pick themselves up and hurry off as if nothing had happened." Winston Churchill
Bob: "What did you mean by "business value"?"
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?"
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 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.
Srinidhi: "Your tenacity to pursue PEAF should be acknowledged."
Thanks! But, I am not really pushing PeaF per se although that is how it is coming across.
Essentially I am like anyone else here putting forward my views about all things EA.
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.
It just so happens that I have also given it a name.
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.
Bob: "What did you mean by "business value"?"
I mean when someone in the business says "that's useful, thanks".
Bob: "You're joking...right"
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.
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/display-doc.asp?DocName=peaf-comms-ea-enterprise-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.
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 long term costs and impacts were not thought about (because there was no incentive to do so)
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.
PeaF Pragmatic ea Framework (www.PragmaticEA.com) can do all these things.
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.
It may be hypothetical in practice in a lot of organisations but this is the structure I put forward for effective EA.
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)
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.......
Here in the 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 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
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)
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 investigative work to determine requirements and specify effective business processes, through improvements in information systems, data management, practices, procedures, organisation and equipment.
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.
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.)
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.
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..
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.
Regarding leveraging this forum the only thing we can all do is keep plugging away and educating other posters as and when they arise.
For my part: -
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.
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.
Another way to look at it is as a vehicle for learning how to do EA but also to provide a 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.
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?
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.
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.
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.
Pragmatic EA – Cutting EA to the Bone.
Please do not think I am pushing a product....
Knowing what EA is and how to do it is so simple it hurts.
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.
This is what PeaF does.
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:"
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 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/peaf3-governance.htm and a set of these standard principles can be found at the same location in the "Principles" document.
It's not complicated.
The 2nd set of principles are organisation specific and come from modelling and understanding the target state of the enterprise.
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.
This doesn't mean you can't pick some if you come across them.
Have a look at page 8 of http://issuu.com/pragmatic-ea/docs/peaf-overview-v1.1.4/8 where does it say "picking low hanging fruit"?
SP = Strategic Planning
BA = Business Architecture
TA = Technology Architecture
GO = Governance
MA = Management
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."
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.
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.
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 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.
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.
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?"
Yes, but not exclusively IT. Is a business process IT? Is an Office location IT? No – but we include them in EA.
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.
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!!!!!!
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 focused.
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.
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 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...
Did you know that Dell is evaluating PeaF in order to potentially provide it as part of EA training to over 100 EA’s?
Steve "Then again....I suppose you are selling PEAF"
Interesting Steve Can you tell me how much I am selling it for??
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.
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 efficacy of this group by using it as a commercial bill board to advertise, acting otherwise."
If something is better than TOGAF why are you afraid to hear about it?
You cannot buy PeaF You can use it for free so long as you are not a consultancy or training provider.
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.
I see politics coming more and more into the EA community and the sooner this cancer is cut out the better.
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
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."
PeaF is not a tool, it's a framework.
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 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.
Bob "From what I've seen of your tool, you've got pretty diagrams (the kinds execs like..."
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?
Bob "...but you lack tons of detail in how to use and apply PeaT."
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.
Bob " "If I were you I'd get myself an EA contract and use it to test out and
IMPROVE on your tool. You'll find out real quick the problems with what
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.
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 EA FRAMEWORK REALLY PRAGMATIC?
Cited from a Forrester paper written by Henry Peyret, Principle Analyst, reproduced courtesy of Forrester Research...
"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
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.....
OK this sort of thing keeps coming up so let me explain where I am coming from.....
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 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.
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."
Joseph "Apologies to Kevin for going off-topic."
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.
I quite like the quote which seems to be widely associated with Voltaire – Now there’s a guy with an electric personality ;-)
"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"
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.
#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"
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.
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.
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 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."
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.
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 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.
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 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."
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 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 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.
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."
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.
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.
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!
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........]
Go have a look at them at them in the principles document at http://www.pragmaticea.com/peaf3-governance.htm
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? …"
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.
EA metrics should not be measuring how well a project achieves its goals. This sort of thing is usually already being measured.
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?"
Go to any Gartner / Forrester et al EA event and you will be bombarded with Case Studies.
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.
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"
For a pragmatic concise and actionable approach – have a look at PeaF at www.PragmaticEA.com It 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.
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.
Renaud "TOGAF is free"
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"
Hmmm. Not sure what this means either.
Renaud "TOGAF is ...... used
So is PeaF!
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 ...... community-supported (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
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.
In other uses, Enterprise means really big i.e. Enterprise Class/Scale.
Many job advertisements ask for an Enterprise Architect, when actually they are looking for someone who can architect Enterprise Class/Scale applications.
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.
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."
Search CIO says that "An enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives."
TOGAF says that an Enterprise is The highest level (typically) of description of an organization and typically covers all missions and functions. An enterprise will often span multiple organizations.
The Agile folks define Enterprise architecture is a set of models describing the technical implementation of business strategy and processes.
According to Gartner " Enterprise architecture is the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key principles
and models that describe the enterprise's future state and enable its evolution. Gartner went further and define enterprise as a collection of organizations that share a common set of goals and objectives. In this context, an enterprise can be a business unit, an entire corporation, a government agency or a collection of businesses joined together in a partnership."
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.
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?
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.
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.
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.
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
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?
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.
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….."
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.
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.
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 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.
This is what is defined for the PeaF principles.
I like it!
There are obvious downsides of course but as a method of communication and for answering peoples questions I think its a really good idea.
I think the question(s) and answers(s) arrived at can then be posted here for all to see.
I wouldn't see this as a replacement for this group but more of an addition.
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.
It's as simple as that.
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.
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 so that informed decisions can be made, and so that they can be managed.
The waiver records effectively two pieces of information: -
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.
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:
Have a look at the Enterprise Debt slides at http://www.pragmaticea.com/peaf-products2-culture.htm and the explanation of principles in the process document at http://www.pragmaticea.com/peaf-processes3-operate.htm for more info.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
How about these top 19 EA risks?
1) "It’s a Silver Bullet"
EA is perceived as a perfect fix for all of an organisations problems, with little or no work or cost.
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.
4) "Are we there yet?"
EA is perceived as a destination rather than a journey, and/or as a deliverable rather than a process with deliverables.
5) "…I have important fire firefighting to do..."
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!"
EA modeling tools are perceived as expensive and "nice to have" but not mandatory.
9) "I don’t want another maintenance nightmare"
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 not being able to define a Future state because no one knows what that is and its always changing anyway.
13) "Techy, techy"
The perception is that because EA contains the word architecture it must be all about IT and nothing to do with the business.
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 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!"
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/peaf-products1-foundation.htm
Does SaaS Diminish the Need for Enterprise Architecture?
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.
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.
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.
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?
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.)
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.
Q: Can I redact a submission and if so how?
A: Yes, repost the same submission preceded by the word REDACTED
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!
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.
You can also approach the analyst community Forrester, Gartner, et al.
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.
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.
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."
Again, I don’t want to restrict because its applicable to everyone, but thanks for the offer.
Matt: "By the way, see Sue Johnson's enlightened discussion to understand EXACTLY the reasons why LinkedIn groups 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-to-end"
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 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.
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.
The fact that 160 is the SMS limit for one message is not really relevant its just "a small number"
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.
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.
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.
Please help everyone (and EA in general) take 1 step forward by only posting 160 Character definitions.
I like your idea but that was the thinking behind PeaF !
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.
XP is proprietary should the world dump it because it is? Of course not.
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.
Of course we then get into the discussion about it’s me who decides and therefore that’s bad etc etc etc......
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 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.
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?
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.
I have always been willing to listen to others views.
I actively seek out people who disagree with me as that is where there is possibility for learning.
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.
I apologise if I gave you and Leon the wrong impression, my only intention was to keep the discussion on topic.
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…
You are the only person I have responded to so far about the content of their post – Well 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.
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.
It sounds facile, but its deeply important.
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.
The key is not being clever and thinking of the solution.
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.
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)
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.
It is these "things" that I am terming the "solution"
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.
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.
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.
I hope this makes it clearer.
There are three iterative phases associated with EA which should be adopted in an iterative manner
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/peaf-products1-foundation.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/peaf-products1-foundation.htm in the Metrics document.
3) Operation You can measure how effective the organisation is in it's operation of EA. For this you can utilse metrics associated with the EA principles you have determined/adopted. These can be found here http://www.pragmaticea.com/peaf-products4-governance.htm in the Principles document.
How do you know the Enterprise architecture is failing?>/P>
If Enterprise Architecture is the architecture of the enterprise (business+IT and not just IT) then...
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
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 the EA Enterprise Debt slideset at http://www.pragmaticea.com/peaf-products2-culture.htm
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."
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.
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!)
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)
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."
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: "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!
Kinshuk: "If all the risks in the project were added, what would be the timeline ?"
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!"
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. "
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"
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.
Managing Cost is only one of four plates management need to keep spinning, the other 3 being Managing Risk, Managing Quality, Managing Agility,
Have a look at the ready to use Vision Document at http://www.pragmaticea.com/peaf-products1-foundation.htm
It's part of the Foundation section of PeaF.
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…….
You need to write a vision statement, to define why you are doing EA and what you will get out of it.
Or, you can use the ones provided for you at http://www.pragmaticea.com/peaf-products1-foundation.htm
You need to develop a maturity model so you can evaluate where you are and where you want to be wrt EA maturity.
Or, you can use the ones provided for you at http://www.pragmaticea.com/peaf-products1-foundation.htm
You need to develop a plan of what to do.
Or, you can use the ones provided for you at http://www.pragmaticea.com/peaf-products1-foundation.htm
You need to develop a list of associated risks to maximise success.
You need to develop a set of metrics for measuring whether you are getting the benefits from EA that you expect.
Or you can use the ones provided for you at http://www.pragmaticea.com/peaf-products1-foundation.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)
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.
Or you can use the ones provided for you at http://www.pragmaticea.com/peaf-products2-culture.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 a process for populating the model.
Or you can use the ones provided for you at http://www.pragmaticea.com/peaf-products3-model.htm
You need to develop a set of EA principles.
Or you can use the ones provided for you at http://www.pragmaticea.com/peaf-products4-governance.htm
You need to develop a governance model/process for operating them.
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.
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.
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/peaf-products2-culture.htm
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.
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.
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.
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 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.
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
Governance to manage alignment to the Strategic Plan
Metrics to measure execution of the Strategic Plan
@Sharon: "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. "
Yes I do.
It's split into 3 phases: -
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.
The end of this phase culminates in going to the board with a request for funding to implement and operate the identified actions.
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.
These parts of the plan are therefore very dependent upon the particular organisation in question.
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.
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"
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.
Then, someone suggests utilising EA to improve matters, so you create an initiative to plan, implement and operate EA.
My point is that asking if this EA initiative is aligned to Business Strategy doesn't make sense.
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.
The pertinent question is "is the PRINCE initiative delivering on the objectives set out for it?"
I am not saying the content is wrong, its just the title doesn’t sit well in the psyche.
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"
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.
This is also true of PRINCE2, MSP, SIX-SIGMA, LEAN, etc, etc.
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!)
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"
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.
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).
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.
This thread is a challenge not a discussion. It was specifically designed not to be a discussion because, in my experience, I have witnessed hundreds if not thousands of discussions like this.
And I asked myself, what did those discussions achieve. I have to say, IMHO, I think they achieved nothing.
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.
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.
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 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.
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.
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.
It was even discussed/agreed with a lot of EA experts at the summers Open Group TOGAF Forum!!!!
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.
The key thing is being pragmatic.
Does everyone remember this quote (you can apply this to anything, an application, a process, and enterprise, 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…
"Q1: What is the purpose of an EA Framework?
Q2: What products should comprise an EA Framework?"
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.
#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.
#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 1 st birthday (25 th 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?"
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 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.
Tony: "Enterprise Architecture is about a way of thinking"
However, when considering frameworks you have to agree 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.
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.
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.
Zachman is a metamodel not a framework. A metamodel is an important part of an EA framework but IMHO 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.
It’s not black and white, but I think this would help people with understanding the distinction.
Heres my list …
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.
6. Working mainly at the logical level. (Projects develop the physical expressions of the logical.) "
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.
You are probably doing Enterprise Architecture if you are…
You are probably doing Enterprise IT Architecture if you are…
Roderick: "What do you think of EA sitting in the corporate office, "
I don't see as EA a thing that sits somewhere.
EA is a process, a culture.
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.
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.
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 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 make a bank, a bank. EA makes a bank, a better bank.
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.
This thread is meant to show, expose, quantify the problem.
I believe this process is "a good precise way to pin down EA."
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 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.
I have added the focus to the list as I think it does add something…
You are probably doing Enterprise Architecture if you are…
You are probably doing Enterprise IT Architecture if you are…
Matt: "I don't think that there is such a thing as Enterprise IT Architecture."
I think there is , there are many examples.
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.
Also the terms "Enterprise IT Architecture" or" Enterprise Application Architecture" are the two terms that most commonly people mean when they say Enterprise Architecture.
The are just using the word enterprise to mean large scale or big.
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.
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.
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.
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 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……..
WOLF: "Your discussion has brought absolutely the same results."
It hasn’t brought any results yet apart from an initial statistical anaylsis of the source data.
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.
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….
"To allow the business to see the elephant"
"To allow the enterprise to realise it is an elephant"
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.
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.
EA = Efficiency Applied.
Any enterprise has "To be efficient" as one of its Goals.
Being efficient breaks down into 2 main areas :
To understand more, we can look at the "The Past" compared to "The World Today".....
The World Today
If you believe that…
"The only constant is change" Heraclitus of Ephesus
then enterprises need to…
"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?"
I always have my views, but I choose when to express them.
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.
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.
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"
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.
Censorship (self inflicted or applied) is the cancer of the business world.
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."
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
a) allow THEM to understand the purpose of EA which would them allow THEM to
b) decide that they should be doing something about it (or not).
This is effectively recursively applying EA to itself!
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.
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.
I am a TOGAF Certified Practitioner (one still has to pay the bills) so I see no problem in anyone learning about TOGAF
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 thing, Pragmatic will come into direct competition with TOGAF because later this year will see the release of :
The reasons for that is 3 fold.
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 proves it is a collaborative effort.
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."
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"
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...
"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"
ADRIAN: "Or that there is no forum to sanction and drive EA."
ADRIAN: "So architects employ own views, not only producing their own definitions but probably specifying their their ideal jobs according to definitions. "
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. "
ADRIAN: "Let's help narrow the diversity down."
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."
There may not be one single purpose but the purpose should be able to be described succinctly so other people can understand it.
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."
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)
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. "
But, how do you propose to decide which are "the best"?
Who will decide which are "the best"?
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.
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."
Agree. That the whole point is to "narrow the "why" down to one sentence supported by the majority."
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.
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)
I’m interested in your view on my opposite view and to understand more why you see it opposite to me.
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.
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.
People can (and will) disagree sometimes.
People can (and will) misinterpret what you say sometimes.
People can (and will) react with knee jerk reactions 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.
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.
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.
Even if the resulting definitions are still wildly different that won’t matter, because since they will all be coming from a restricted list, it will allow much easier and better analyses of the posted responses.
SIMPLE ANALYSIS RESULTS – TAKE 2
I have updated the simple analysis in two ways.
Out of a total of 777 words, 147 were ignored (is, a, at, on by, etc, etc) leaving 630 distinct words
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: -
Using the first 10 in one sentence it seems to produce the following: -
The purpose of Enterprise Architecture is
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.
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.
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.
This happens in failed IT projects the only difference being that the 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.
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....
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.
People will not "do" EA if they do not know the answers to these questions.
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.
Purpose: Brings EA to an organisation and gets them set up and working correctly.
Works with: The Board and Executive Management.
Term of employment: Typically this is a transitory consultant role.
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 team, Architecture Review Board.
Term of employment: Typically this is a permanent role.
Projects dig the hole. EA tells them where to dig.
I like it ! Post it.....
I would make a slight enhancement though...
This last point is where things break down because 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.....
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::
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.
In other words sometimes increasing risk and/or cost is a good thing. Sometimes reducing quality and/or agility is a good thing.
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.
EA does not make a bank, a bank. EA merely helps to make a bank a better bank
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….)
James; "I am saying, what if the enterprise didn't have an EA group..."
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 the EA - Why I Don't Need It slideset at http://www.pragmaticea.com/peaf-products2-culture.htm
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'."
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.
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.
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 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.
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)
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.
In order to "sell" any "solution" you first have to get people to admit that there is a problem.
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"
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"
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 they are problems that EA would help with and most could)
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.
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."
I think you're being a bit too narrow and, dare I say it slightly, naive.
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 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.
Efficiency is very easy to measure (output / input)
James: "Enterprise Debt in PEAF"
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.
3) As projects begin to define solutions to problems they are assessed as complying with these principles or not.
4) For a project, if all principles are complied with no problem no Enterprise Debt is created.
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.
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.
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...."
To me it is debt.
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.
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 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 "Principles at each level of abstraction are guides and guides are just that...not always followed. "
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.
The business wants cart blanche to change its mind at a moments notice. And so it should.
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.
Can we take this Debt discussion to the new topic though…
One of the fundamentals about EA is that is not there to make decisions and it is not there to say NO.
It is there to expose information so that the business can make more informed decisions.
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".
Enterprise Debt Ration is a complimentary concept to Enterprise Debt. Maybe it’s a bad name again, maybe not. We could call it Ermintrude!
What it means is that we recognise that work/change carried out on projects can be categorized as a ratio between :-
So that one project may be 10 : 50: 60, (i.e. Strategic:10 Interim: 50 Remedial: 60) another may be 0: 100: 0.
So The full "Enterprise Deb" concept consists of: -
"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)
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!
Doug "Do groups receive more budget or better access to resources if they contribute less than others to the debt?"
No – it doesn’t work like that.
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 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…
Failure to do this will create a massive bottleneck.
#2 Do not populate a model without integrating or removing the data sources where the information came from.
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.
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 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.
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.
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"
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"
The PEAF principles are not vague. There are defined, and supported by rationale, implications and metrics.
Richard: "but would this kind of compliance make any significant reduction to the quantity of enterprise debt"
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.
in 99.9% of enterprises the project manager "wins", he looks successful and the debt that has been created is now hidden.
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. "
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.
Both of these are very easy to do for the people on the project in question.
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.
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.
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.
Yes, yes I know that brand, customer satisfaction and other intagiables are also on 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."
Don’t worry – wade in – the more the merrier.
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.
Pat: "So, who pays to have the map updated?"
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.
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.
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."
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.
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."
Ask 100 people what debt means and they are likely to tell you that it means they owe money.
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?"
How many have you presented on the concept of enterprise liability?
Shall we see who has the biggest willy!?
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 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.
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.
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.
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.
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 my direct response to you the CEO:"
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
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).
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"
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 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.
Tru: "to designate IT architecture for enterprise "
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 Processes = EA Prepare Phase + EA Implement Phase + EA Operate Phase
EA Products = EA Foundation Products + EA Culture Products + EA Model Products + EA Governance Products
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?
What would an organisation call all of their liabilities added up? Not Enterprise Debt so what would they use as the collective term?
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.
@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.
@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). "
I believe it is for various reasons all coming together
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.
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 (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.
You can mail me on 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 double-entry bookkeeping? Is enterprise debt as you know it actually one of the categories of liability, in this accounting sense? "
This is a new concept.
It's very simple. It's very easy. But if all it took was someone to come up with something that's useful, simple and easy, every inventor in the world would be a billionaire.
The problem, of course, is getting the message out there.
It will happen. It will be adopted. It's just a question of time.
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.
Kevin: 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.
Increase the Effectiveness, Efficiency, Agility & Durability of the Enterprise.
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.
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, Performing EA Governance and Managing Enterprise Debt
The Level 4 Description.
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.,
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.
ADVISOR: By supporting the management of the Cost, Risk, Agility & Quality of Change
By Using Structural Models, Performing EA Governance and Managing Enterprise Debt.
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
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 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 on page 7 of the PEAF Metamodel document at http://www.pragmaticea.com/peaf-products3-model.htm 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"
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)
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.
Richard: "I have already expressed my preference for the word "liability". James has said it very well. "
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. "
OK I have no problem with that so let's try to work that through a little....
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.
How would you "grounded [the calculation of EL] on the structural risks to the enterprise strategy, rather than dependent ....principles"?
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.
Me: Using Structural Models, Performing EA Governance and Managing Enterprise Debt.
Me: To aid Strategic Planning, manage alignment to the Strategic Plan and to balance Tactics against Strategy.
Me: To increase the Effectiveness, Efficiency, Agility and Durability of the enterprise.
Mark: "Enteprise Architect.....Solution Architect....Technical Architect...."
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"
I think I would agree with both complimentary defintions.
Have a look at page 17 of PEAF Overview document http://www.pragmaticea.com 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.
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.
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."
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.
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.
EA and improving communications does not make a bank, a bank. it can only HELP to 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 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.
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?
Agreed change (being able to and being able to adapt to) is important, therefore agility is important.
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.
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 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.
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…
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"
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.
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?"
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, 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...
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"
There are four plates that EA helps to keep spinning...
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….
MARTIN’s BOSS ""to translate business vision into effective change.""
I like it. I like your boss. I think I’d like to work for a guy like that.
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.
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.
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.
Please have a look at the diagrams on pages 6 to 9 of the EA Framework Comparison document at http://www.pragmaticea.com
It illustrates a comparison between some "EA" frameworks in terms of: -
Strategic vs Project Level
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.
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.
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?
Becuase it has, its called PRINCE2.
FRED:"CHANGE...CHANGE...CHANGE...CHANGE...CHANGE... If an organization does not talk about CHANGE then it will not have a place for EA. "
Correct, that’s why PEAF defines the mission of EA is to...
"To increase the Effectiveness, Efficiency, Agility and Durability of the enterprise, by supporting the Management of the Cost, Risk, Agility and Quality of CHANGE"
Check out the EA Vision document at http://www.pragmaticea.com/peaf-products1-foundation.htm
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.
FRED: "I just wish Kevin will stop promoting PEAF"
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.asp
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.
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!
Seriously though, you know what I'm going to say....here, here. Agree 100%
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 !" at http://www.pragmaticea.com/peaf-products2-culture.htm
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.
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.
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.
Good points but It's made me realise I didn't couch the challenge correctly. The context for the challenge is: -
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"
I also realised that my original response to my own challenge is not good. So here’s my second attempt….
ASHOK: "I can demystify EA and help you cut to the cheese quickly."
Now you're talking.
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. "
I am a bit confused why he would say this as the bottom 2 or three rows are clearly 90% IT oriented????
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"
If this http://apps.adcom.uci.edu/EnterpriseArch/Zachman/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?
Yes. Sad isn't it. But sadder for the organisations that could benefit from it and won't :-(
TOM: "what's shown there is hopelessly IT-centric, and a very narrow subset of IT at that."
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".
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.
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.
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! "
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.
There are reasons why Finance and HR are special. Because they are.
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…
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 non-IT 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…
"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: ""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. "
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. 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 non-IT 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."
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.
MATTHEW: "Correction IT people should NOT be EAs because of they have a IT view of 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 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."
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."
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.
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:"
See the Principles document at http://www.pragmaticea.com/peaf-products4-governance.htm
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 decision-making, 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."
I and PEAF agrees 100%
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%
KIRK: "I see "build before buy" as an outcome of a value."
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.
TOM: "'Why' is also just about the only item that's missing from almost all conventional EA models."
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.
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?"
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....
The purpose of EA is to…
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."
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.
This is what I would call a generic or best practice principle – i.e. it applies to 90% of organisations.
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.
Principles are guidance not laws.
Sometimes it is valid to not adhere to a principle, that does not make the principle superfluous.
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.
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.
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...
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.
The Governance in PEAF is not IT Governance. It is EA Governance (which includes IT but is not limited to IT)
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 ;-)
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>"
Let's just make sure we a discussing the same topic right?
This point is about whether principles are a good or bad thing to have, right?
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 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 with a simpler explanation?
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.
Driver --The Past --The World Today
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 World Today
Enterprises today exist in an environment of constant and fundamental change, and therefore enterprises need to be able to adapt and change quickly to cope with this maelstrom.
Those that can will grow and prosper. Those that don’t will succumb to those that do.
When an enterprise needs to change today it cannot rely so much on the limitless adaptability of people to effect that change.
This is because so much of how an enterprise does what it does, is now either completely or partially automated and the complexity of those automated systems and business processes is causing a severe bottleneck in the enterprises ability to react to change in a timely and commercially sensible fashion.
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.
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.
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. "
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:-
The sub principles (and their rationale are): -
A8.1 Buy a COTS service (targeted at reuse) rather than a COTS application.
A8.2 Buy a COTS package (targeted at reuse) rather than building an application.
A8.3 Embark on bespoke development (targeted at reuse) only when all other options are not available.
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.
I will probably host that on the http://www.pragmaticea.com/160challenge.asp page.
I will then email everyone who has been involved to get a copy.
MARK: "My email is Mark.Reynolds@rseg.net. Thanks for all the work, let me know if there is anyway I can help. "
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.
I think Mark Toomey said it best in his post…..
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."
You echo my feelings entirely but have put it in clearer words and more succinctly than I could ever have done.
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)
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"
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)
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!
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.
MARK: "Governance is NOT management"
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.
For the complete comparison of TOGAF to PEAF (and Zachman and MAGENTA) have a look at the EA Framework Comparison document at http://www.pragmaticea.com
The comparison covers these areas: -
This is an indication of how much the framework is focussed on Strategic Planning compared to Project Level work.
This is an indication of how much the framework is focussed on the entire organisation compared to only IT.
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.
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."
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!)
In case you missed my updated one, here it is.... or do you think this is to hard too?
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?)
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 2 nd encounter may get more traction, although having said that he would probably think "Oh my god not that bible basher again!"
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 hundreds of people try to tell him what to do in the past five years. "
Hmm – you must know a different Marvin to me!
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?!"
EA – Xray Spec’s for your Enterprise!
ART: "What I like about the selling EA in a 30 second conversation with a CEO... Nothing."
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.
MICHAEL: "to keep the team members from selecting what they like,"
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"
Strangely he came to see me and asked me to take out that statement.
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."
I am up for giving someone in government a good kicking as much as the next man (or woman) but sometimes they do say useful things and we would be wise to heed their words.
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"
ALEX: "The same goes for "software architecture"
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 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.
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 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……..
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."
Looks good but you are missing a few things and also I think getting too detailed in some instances.
Have a look at the Metamodel document here http://www.pragmaticea.com/peaf-products3-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 : -
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/peaf-processes3-operate.htm
KINSHUK: "Why are C-suite people always fire-fighting ? It is complete mystery to me. "
My thoughts exactly.
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.
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".
EA is not about making an organisation successful. It’s about making an enterprise more successful.
EA is not about making an organisation profitable. It’s about making an enterprise more profitable.
EA is not about making a bank, a bank. It’s about making a bank, a better bank.
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.
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...
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 have any time to make sure that the next thing coming down the road does not turn into a panic.
It is a downward spiral that you need to break out of and Strategic Planning is the key to that.
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.
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.
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.
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 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.
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."
I have learned more things and earned more respect by that simple action than in anything else I have ever done.
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.asp.
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...
the more detailed definition is...
I would agree that "SOA’s key strength is that it is the first IT approach that blends or unifies business and technology"
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."
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.
It is also 100% free for those who wish to lever EA to improve their business (i.e. End-User 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.
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.
Your comments are precisely why I created PEAF (which is, don't forget FREE for anyone who wants to use it to improve their organisation, be that a private, public company or a government agency).
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.
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.
PEAF differs however from other EA training because a) it really does provide everything you need, and b) because it provides those things in a concise easily understandable and easy to use way.
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."
True This is where PEAF steps in to fill this gap. You can see how PEAF and TOGAF and Zachman compare (in different categories) in the EA Framework Comparison document at http://www.pragmaticea.com
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:" 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..."
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"
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 circuitous then you surely found a certified EA architect. But convince me otherwise."
I hope I have.
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."
BRIAN: "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'm not saying it's not good at what it is aimed at, it's just not aimed and helping companies do EA.
BRIAN: "Do you consider the Zachman Framework to be an Enterprise Architecture? "
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.
Have a look at the framework comparison of Zachman, TOGAF, PEAF and MAGENTA in the EA Framework Comparison document at www.PragmaticEA.com
BRIAN: "They are similar, only SABSA is more complete with a layer for security, as well a manual for building a risk-management dashboard. "
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.
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.
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.
BRIAN HOPKINS: "Gee Kevin, a loaded question?"
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.
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…
The answer I and PEAF gives is,,,
It also poses…
The answer I and PEAF gives is,,,
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.
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-products2-culture.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?
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 complex and difficult to understand, implement and use.
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?"
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/welcome-to-frameworkville.html"
Yep you make a lot of very good points and I agree with almost everything you say.
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…
BRIAN_H:"My point of the Frameworkville blog was that any EA Framework, including PEAF, is not the magic bullet to EA."
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.
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"
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.
It's not a magic bulley but it is at least, an Aspin.
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!"."
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: "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.
GEOFF: "RBV, Ashby et al..."
Cool but what's the ABV of the Beer?
To be honest to me it all sounds fine and dandy, and having read about it I now have the knowledge.
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...
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.
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?"
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.
However, there are frameworks out there that I would call true EA frameworks.
EA is all about business planning/strategising (mostly referred to simply as strategic planning)
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.
GEOFF: "Go away and learn about business strategy and systems thinking."
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."
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?
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.
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!)
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 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 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.
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.
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.
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.)
"EA is a homeostat for an enterprise."
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.
That’s sounds like the perfect thing to spend hours discussing over copious amounts of beer washed down by a particularly hot Prawn Karahi ;-)
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 work is EXTREMELY relevant to EA."
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.
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
Cool. I’m always looking to expand my horizons.
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 ;-)
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.
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. "
Happy to be proved wrong where can I go to see the processes and governance provided by Zachman?
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…".
KEVIN_I:"The columns for the "How" works for processes (with motivations), and the why / who provide placement for governance areas. "
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.
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."
But that’s what a framework (IMHO) is Guidance.
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.
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!
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 - Misunderstanding: "EA is all about a Modelling"
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!
Truth: Modelling is a key deliverable of doing EA but EA is much much more than just a model.
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...
where the first words are…
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.
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.
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.
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 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.)
If I were to ask you which vehicle would be best for travelling, would you say...
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-products3-model.htm
If you or anyone thinks it is deficient in that respect (for its stated purpose which is to provide a pragmatic starting point for 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."
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.
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.
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.
This is a bit complex and doesn't come out properly in my comparison document so I thank you for making me see this.
As at best it’s unfair and at worst misleading.
I’ve uploaded an amended version which now says…
"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"
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.
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."
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 re-generated. 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?"
I’m not sure I said knowledge can be held in an IT system. But anyway, since you bring that up….
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 confusing knowledge with judgement?
Geoff: "polyani", Pitagorsky : "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.
GEOFF:"the Open University has an excellent MBA module on KM. Please sign up for the the course"
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 "
Armstrong can transfer the knowledge but he cannot transfer the experience.
Perhaps this is where you are getting confused?
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.
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.
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.
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.
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.
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. "
I think you are absolutely right and thanks for your concise summation, and thanks too for your kind words.
Kirk:"I find it amazing that you could actually distill this conglomeration of inputs into anything cohesive :-)"
Thanks Kirk I don’t know how my brain works but
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 ..."
Accepted. I know the original posting gave this as a reason for defining the purpose, but I think now things have moved on.
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.
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.
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."
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?
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.
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.
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?..."
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.
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."
Yes that's what it is, but I asked what is its' value? "Hey Mr Executive, this is why you need PRINCE2..."
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....
...…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…
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.
EA just allows organisations to those things better.
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."
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")
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.
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.
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 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.
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. :-))"
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.
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….."
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.
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 created and not get sidetracked again into other (very valid) discussions.
Atiila: "When I talk the board of directors of corporation, I would never dream to talk about EA."
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…
Atilla: "They are not interested in the HOW, but in the RESULT! "
Yes I agree with you.
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…
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)…
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)…
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:" 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.
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.
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…
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)…
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)…
Ramchandhar: "I would like to know how to start a career into Enterprise Architect, 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.
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"
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?"
Absolutely! It's not rocket science.
However, it's not easy because it' been cloaked in confusion and misinformation for many years.
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.
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.
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-products2-culture.htm
Carlos: "What are the differences between Enterprise Architecture, Enterprise IT Architecture and Enterprise Architecture Framework or Methodologies?"
Enterprise Architecture (noun)
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
IT = IT
Architecture = Structure
Enterprise Architecture Methodology
(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
Enterprise Architecture Framework
(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
(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)
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.
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.
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.
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-products1-foundation.htm then you will be able to decide whether EA is of use to you now or in the future.
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 the EA Framework Comparison document at http://www.pragmaticea.com
As you say, with v9 it is becoming more EA but I think it still has a long way to go.
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.
Ritesh: "EA leads to BPM and vice versa."
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.
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.
Personally I see EA as encompassing BPM.
EA = BPM + ITSM + Culture???
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?"
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.
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..."
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 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.
Konstantin: "While BPM strives for operational efficiency in business lines, Holistic EAM supports a coherent enterprise-wide strategic change addressing company mid and long term targets."
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.
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")
Transformation Efficiency (also referred to as "Agility")
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.
@Mogorosi: "'i ran this bank without EA for 15 years; how is EA going to get me more corporate banking clients that drive shareholder value around here?', a bank executive once asked. "
Classic words I have also heard before by dinosaurs who have drunk too much port!
My response is the EA does not make a bank, a bank.
EA makes a bank, a better bank.
A more effective bank.
A more efficient bank.
A more agile bank.
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.
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.....
@James: "Is there a relationship between Enterprise Architecture and Organizational Transformation ?"
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.
@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)?".
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: -
Yves: " What is realistic to expect in terms of what EA tools do well and what they should but don't do well?"
See the "Tool Evaluation" document at http://www.pragmaticea.com/peaf-products3-model.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: -
#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.
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. "
@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).
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.
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 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.
@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.
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 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 the Tool - Rationale document at http://www.pragmaticea.com/peaf-products3-model.htm
@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?"
But that’s not the only difference/reason why I say TOGAF is not an EA framework.
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.
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 in the EA Framework Comparison document at http://www.pragmaticea.com
Page 10 gives you a 3 dimensional comparison using 6 axes.
@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"
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?
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"?"
Absolutely! That was the prediction I made 18 months ago. See Slide 21 in the "EA EDV" slideset at http://www.pragmaticea.com/peaf-products2-culture.htm
It is a debt. It's especially pertinent for companies being taken over or wanting to take over others…currently some kind of "due diligence" is done to asses the other companies IT and general health, but what it 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.
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’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)?"
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.
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.
Michael: "From a process point of view, the approval of waivers (from EA principles) is the mechanism for registering enterprise 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?"
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…..
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!
@Lisa@ "What do you envisage the demand of an EA in the industry? Can people jump from being an EA to a Management Consultant?"
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…
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.
They are passionate and enthusiastic about what they do and how they do it.
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.
@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)
Any money spent on the project that was cancelled is just wasted money its not a 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.
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.
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.
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.
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 fire-fighting 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…
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.
Now, let's say that this company adopts EA (let's say they use PEAF as their methodology!)…
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.
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.
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 3 is a "Now we can attack the EDV which will lay the ground work for massive strategic work next year"
Year 4 is a "Now we can really let rip on some good strategic stuff and get some massive returns"
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
Today -1 years:10:80:10
i.e. strategic and remedial work falling as tactical work increase a negative spiral into failure.
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."
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
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."
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.
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 decision-making at the upper layers of the enterprise."
Agreed. In fact, I tell people that they can use PEAF for the "true" Enterprise Architecture 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.
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. "
Are you guys related! ;-)
Scott: "For several decades we've heard that effective enterprise architecture programs are a critical success factor for medium-to-large 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."
It's sounding a bit like you in the camp that says that EA is all about IT.
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.
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.
Eugene: "Can this be measured in any objective way? (e.g., % of practitioners with industry certification, conference presentations and case studies, etc, etc)"
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.
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.
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-products1-foundation.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-products2-culture.htm
@Rob: "However, if EA weren't primarily an IT discipline, then it would be indistinguishable from those practices, and the moniker would be misleading. "
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 joint-optimization (see http://en.wikipedia.org/wiki/Sociotechnical_systems )."
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"
I see two distinct but important areas/levels here…
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.
Secondly there are other things that exist to cope with change.
Outside their control
Inside their control
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.
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.
@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."
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.
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.
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"."
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.
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."
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)
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.
Faith: "I do not believe that IT is 99.99% of a business."
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."
Faith: "You can refer to my Synergetic 7 Change Model (a pop-up) at synergetic-solutions.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.
Faith: "To me it's not about organizational titles and resources; it’s about a way to think."
@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.
@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."
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.
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).
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 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. "
Viral I like it!
That makes me think of virus’s with mostly are not good however, in small doses they are very good vaccines / immunisation.
EA "The vaccine for today’s sick organisations…."
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" 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 today's world too. It’s too confrontational and master servant oriented for me. I believe today’s governments and organisation need to, as you say, a systemic approach.
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….
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 consistently 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: "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 systemic optimisation and organizational learning. "
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.
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.
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 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: "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. "
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!)
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. "
James: "All in all, yes EA is about people problems :o)"
James: "We are facilitators not decision makers. "
James: "When systemic management will be used, EA will no longer be called EA… it will be just good organizational management/leadership."
@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?"
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.
It is concise, complete and very pragmatic.
Have a look at the overview docs at www.PragmaticEA.com to get big picture view.
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.
It is only commercially licensed to organisations that want to use it to make money i.e. consultancies, training providers and tool vendors.
@Phil: "Enterprise Architecture enables organizations to execute their strategies by leveraging the capabilities of IT."
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.
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.
I still don’t agree with it totally because I think it’s missing a lot (See http://www.pragmaticea.com/160challenge.asp) which collates and analyses 1,200 definitions of EA.
Phil: "If you don't have a picture of what your trying to manage, it is very hard to be successful."
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.”
My comment was based on your comment which said “"Enterprise Architecture enables organizations to execute their strategies by leveraging the capabilities of IT.”
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.
@Phil: “Can you expand on why this is confusing and causing massive amounts of pain?”
Because telling people that EA is not an IT discipline and that EA is not all about IT is a constant battle.
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.
@Phil: “Also, who do you believe in an organization should be driving EA?”
There are two “jobs/things” that need “driving”.
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.”
@Phil: “IT becomes a strategic enabler of the business by following the practice of EA.”
Yes, but not just IT. So does HR, Finance, Partners, Suppliers, etc, etc, etc.
IT is special, but other things and other departments are also special.
It is the integration and cultural co-operation and guidance of the entire enterprise that is at the heart of EA.
@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”
Doesn’t the purpose part do exactly that with no Tech…
Is there any Tech speak in that?
They then may want to know how……… to which the current definition says…
Is there any Tech speak in that?
Only the word Architecture.
So is it the single word “architecture” the thing you are referring to when you say “you will need to de-Tech your definition”?
Again, they may want to know how again….to which the definitions says…
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 de-Tech’d!!
@David: “Kevin.... That statement although not techie is just a list.”
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 like any other consultant/sales pitch.”
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.
@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.”
As I said, it’s not for my CV. You can have a look at my CV here http://pragmaticec.com/downloads if you would like to check.
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.
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.
@Zahid: “Persevere with the "de-teching"”
What in the analysed definition do you suggest needs de-teching?
@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? 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”
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.
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
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.
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.
@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.”
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.”
I would agree with that. It’s a large number of people with different perspectives, views, opinions, information, backgrounds, goals, etc, etc.
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????
@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.”
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.
@David: “The Architecture of an Enterprise is the culmination of ideas and efforts of a plethora of people in the organisation”
@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.
@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.”
This is one of the most important aspects that many organisations fail to recognise and therefore address - Sustainability. Introducing a tool is actually a data migration exercise.
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.
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 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. 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.
@Rob: “re: "EA, for example, brings the notion of modelling" Plz forgive me ... but this is an inevitable response ... "so EA = business management + pictures".
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.”
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 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 organisation 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.”
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 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-products2-culture.htm
@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.
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?”
Because we are Architects and therefore we are; Pragmatic, Enthusiastic, Agnostic, Articulate, Persistent, Strategic, Altruistic, Diplomatic, Open, Generalist, Persuasive
@Rob: “Does the practice of EA somehow shed more light on their problems?”
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.”
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.
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.”
@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 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.
EA’s and EA models provide a context and visibility of the entire enterprise at a high level of it’s constituent 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 other parts collapse, in what ways….etc, etc.
@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.”
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.
@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.
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.
@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.
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.
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.
@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!).
@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.
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”
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.
@Rob: “I'm not sure I agree with everything”
Hey - if you don’t agree with something - you gotta let it out dude!
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
@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.asp) 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
@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!
@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."
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.
Absolutely... The role of an EA is to “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…
“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
“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"
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.
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).
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 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-products1-foundation.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.
@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.
@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.”
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-products2-culture.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...”
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 trust in IT) they ignore IT and restrict timescales, resource, scope, process and money.
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.
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.
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.
© 2008-2013 Pragmatic EA Ltd