This article written by Alex Matthews (@remembermytweet)
OK, so here is a quick brainstorm of key concepts that every EA should know. It is literally a 5 minute brainstorm exercise so I expect that there are huge gaps. I strongly encourage you to comment and let me know what (glaringly obvious things) I have missed. 
Once the list is settled I plan to go on and provide a brief overview of each of these concepts. I use at least a part of each of these models in just about every project.
(Please note that these skills deliberately ignore the technology skill set that an EWITA will need. Tom Graves has already written the definitive explanation of the Enterprise Wide IT Architecture (EWITA) vs Architecture of the Whole Enterprise (AWE) debate, so please go there if you aren’t yet aware of what I’m getting at here.)
- Porter’s value chain
- Allee’s value networks
- Porter’s 5 forces or 6 forces model
- Tracey & Wiersema value disciplines
- Kaplan & Norton’s Strategy Maps & Balanced Scorecard (see video link below)
- Green’s VPEC-T model
- Ostwalder’s Business Model Canves & Graves’ Enterprise Canvas
- Beer’s Viable System Model & POSIWID (the purpose of the system is what it does)
- McKinsey‘s 7-S model
- Boston Consulting Group‘s Growth Share Matrix
- Kim’s Blue Ocean
- John Kotter‘s 8-step change method & ADKAR
- Rockart’s KPI’s, Drucker’s Management by Objectives, Jenner’s Realising Benefits & Ward andDaniel’s Benefits Dependency networks
- Boyd’s OODA loop
- Mintzberg’s 10 Strategy Type’s (Strategy Safari)
- Analysis by acronym: PESTLE, SWOT, STEEPLE
- Scenario Planning
- ISO 31000 Risk Management
- Venkatraman’s Strategic Alignment
- Stakeholder Analysis & mapping
- Industry standard project and program management methods (PRINCE2, MSP, PMBOK, etc)
Other people’s suggestions.
22. Process Management: Basics at least. Lean and Six Sigma useful. – Thanks to Doug Newdick
23. basic accountancy concepts (opex vs capex, depreciation etc) – Thanks to Doug Newdick
24. Pacelayering: Different parts of the enterprise evolve at different rates. An important and often neglected dimension of enterprise architecture is time. Often, architects assume a constant rate of change across their entire architecture; or worse, fail to address the issue of rate of change at all.- Thanks to Richard Veryard
25. Deconfliction: designing systems and operations to reduce conflict and interference. – Thanks to Richard Veryard (http://rvsoapbox.blogspot.com.au/2008/03/what-is-deconfliction.html)
26. Multi-sidedness: A modern enterprise often operates in multiple markets, and satisfies overlapping needs for numerous stakeholders. The emerging architectural response to this challenge is to configure the enterprise as a platform of services, rather than as a traditional value chain. – Thanks to Richard Veryard (http://rvsoapbox.blogspot.com.au/2012/02/talks-on-enterprise-architecture-next.html)
Related articles
- Management with Metrics: Understanding the Balanced Scorecard (dartonequation.com)
- A Real-Life OODA Loop (aleksandreia.com)
- What Is Strategy? (mikearauz.wordpress.com)
- Change Management Models, Stakeholder Analysis & Capacity Building in Corporate Reforms (slideshare.net)
- The Future of the Balanced Scorecard (bjconquest.com)
Nice list – some I don’t know and will need to look at! I will quibble and suggest that many of them are techniques or tools as opposed to concepts though. One technique that I am looking at now that isn’t on your list is: lean (Toyota management method). A couple of other techniques that I use regularly are: proper cost benefit analysis (taking probability and future discounting into account) and basic accountancy concepts (opex vs capex, depreciation etc.)
Cheers,
Doug
Depreciation is a good one. It is amazing how many organizations I have helped that don’t capitalize and depreciate their application assets. Almost none have capitalized and depreciated their information assets. Such a waste!
Zachmann Framework?
Anders,
Thank you for your comment. The list is certainly non-exhaustive and please note that I was pitching this at the Architecture of the Whole Enterprise camp rather than at the EWITA camp.
I know that John will be upset at me for implying that his ontology isn’t equally applicable to both but I was really looking to pick out a few things that are slightly less obvious than Zachman.
The Zachman ontology and most frameworks are useful for EA but enterprise architects can and do practice EA without using Zachman. Particularly business AWE people.
If you’re not sure what I am carrying on about when referring to AWE and EWITA I would recommend the post that is linked above called “explanation of the Enterprise Wide IT Architecture (EWITA) vs Architecture of the Whole Enterprise (AWE) debate.”
Alex, I’m struggling a bit with this for a few reasons.
I understand your desire to scope this away from EWITA but that doesn’t mean there are not a lot of very useful concepts to be found in more IT oriented documents, which are not to be found elsewhere (or more accurately, which I am not aware of elsewhere). Apart from Zachmann, there are things like the Enterprise and Solution Continuums (Continua?) in TOGAF. Then there’s the concept of an architectural description in ISO 42010 (formerly IEEE1471) and in particular the associated metamodel/ontology linking stakeholders, concerns, viewpoints, models, views etc. The source documents may be IT oriented but these concepts are in my opinion equally applicable and more than just casually useful in AWE.
The other problem I have is my own problem. Apart from what you’ve already listed (and the couple of things above), I can’t think of many more “things” people ought to know. I’m sure there must be. It just reflects my own approach to EA, which is more one of continuous learning driven by context (or tweet:-)). A form of osmosis perhaps. It is definitely a weakness sometimes, so please do go ahead with your effort.
Ah! I thought of something. How about Deming? Not just the famous cycle but also the 14 principles. One could argue that he’s implicit in some of the more recent work but he’s so wonderfully concise and clear.
Stuart,
Thank you for your input. I totally agree with you. There is vast amounts of EWITA content that is great.
I wrote this post with an obvious and deliberate bias towards the AWE world view. The truth is that there are still people out there that only have the EWITA view. So I thought I’d share some more business focused concepts with folks. The C-level execs I work with are vastly more interested in P & L and risk than “continua”. :-p
The list is also deliberately non-exhaustive. It is meant to stimulate input and comment. For example I left out the Business Motivation Model (BMM) from BRG. The ‘ends’ and ‘means’ concept in BMM is my personal favorite EA idea. I love it simply because the language and the idea is so simple and intuitive. Everybody gets it.
Deming is another good suggestion but I have to admit to another bias there. For no apparent reason Deming’s Plan-Do-Check-Act cycle doesn’t work for me. I can’t see the need for the “Act” part. I think it should be implicit in the Check. It’s one of those pointless semantic things that that just about every EA I know gets caught up in from time to time. *smile*
“I can’t see the need for the “Act” part. I think it should be implicit in the Check.”
LOL, I have the same feeling and I use parts of Deming for my KISS for architects model at http://peterbakker.wordpress.com/kiss-for-architects/the-kiss-for-architects-model/
I’ve replaced the separate Check & Act steps in a single “Evolve” step which is in my opinion more natural in a world of continuous change.
Alex
I understand the motivation – and I support it. I was looking at it more from the perspective of what are the things that a lot of EAs don’t appear to be aware of (and should be).
I still think those concepts (continua and, more importantly, the 42010 metamodel) are essential underpinning for any EA. I don’t expect C level folks to be interested but I don’t expect them to be interested in VPEC-T either. I do expect an EA to understand these concepts and why they matter in order to get some element of rigour into the work. And I expect an EA to be able to explain to the CEO (assuming s/he ever gets near such a person) why the answer they want to hear is wrong!
And, as it happens, I don’t see any empirical evidence that the majority of EWITA folks really get 42010 either.
But it’s your call. I promise not to sulk.
Maybe you can write the EWITA version. *grin*
Here’s a few more …
Multi-sidedness
Deconfliction
Pace Layering
POSIWID
Alex,
It strikes me that this knowledge is pretty standard for an MBA which is not necessarily an EA architect. There is not much, if at all about simple architecture in there.
Is there no tool coming from IT or BPM?
You don’t mention any EA framework? Is that the intention?
Since most EA architects work in IT, where is this architect going to work? Is this the executive architect of the future? Can an EA qualified in all the above do an EA IT architecture, you think?
You did not mention organizational design.
You may need more on the strategy side.
Since the list grows larger and larger, are there any business concepts or tools that should not be on this list?
Not one design methodology. Nothing on technical writing.
Nothing on information science. Nothing on visualisation.
No serious analytical methodologies (some of the management tools listed here barely rise abobe the spot-and-name level of analysis.)
Something seriously wrong here.
Ric,
Perhaps you could suggest a few specific additions. It would be great to have some constructive input from you.