RSS Feed
Thursday, September 3, 2009 | 
In response to tremendous volume of requests from analysts big and small, we've spent a few days 'cleansing' a mature EA Capability Map and cross-referencing it with the EA Services posts that Todd Biske (@toddbiske) has been collecting on his blog (posts here, here, and here) from various thought leaders in this space. We also considered Mike Kavis' (@madgreek65) thoughts on whether Enterprise Architecture is a good idea for smaller companies.
Before diving into insights learned (and shared with Forrester's Jeff Scott (@logicalleap)), a few notes about the diagram.
- We use the standard SenseAgility Bullseye that includes four perspectives:
- Business - defined as the business of the department in question, not the organization as a whole (upper left);
- Organization - who is required to operate all perspectives (upper right);
- Technology - what tools are used to operate all perspectives (lower left);
- Risk - what controls are in place to mitigate threats to all perspectives (lower right)
- The dependency lines are omitted on this Capability Map. There are other, more appropriate diagrams that capture these relationships.
- For illustration purposes, we used one of the capabilities to show how services aggregate into capabilities. EA Education Capability (Org Perspective) breaks down into 5 services, with further dependencies to EA Tools Capability (Tech Perspective) and its two services.
So a first batch of insights:
- As with any complex animal, it is the dependencies that drive the value of any EA organization. Inter-dependencies between EA Capabilities, Services, Processes, and external dependencies based on stakeholder alignment are the key to capturing, monitoring, and reporting on the value of EA.
- Any Enterprise Architecture functions performs all of these capabilities - whether formally or informally. And formality is not really determined by organization size. The real dependency on organization size is the extent to which these capabilities are executed. Formal education program and engagement management functions, for example, would not be necessary in a small company like Mike's. They would be critical in a Fortune 50 company.
- The Capability Map is an operating model for EA. It is not a roadmap on how to build or source capabilities. Since each set of stakeholders is a set of unique individuals, each organization is unique. Hence, healthy skepticism is warranted when someone presents a one size fits all EA roadmap.
- Enterprise Architecture has very little to do with Technology perspective. Only 1/14 capabilities in our vanilla model deals with technology. By contrast, fully half (7/14) are organizational capabilities. This result should not be surprising - while a strong foundation in technology is a necessary skill set for any Enterprise Architect, business acumen, organizational awareness, and risk management are even more important.
More thoughts to come, especially with everyone's participation!
5 comments:
This has been posted in several areas, and we'll be collecting various thoughts and re-posting them here with links, since in some cases, the links are protected.
Todd's initial reaction:
toddbiske .@aleksb6 The capabilities shown map reasonably well as a level one view, while my services view would be a level 0.
toddbiske .@aleksb6 I don't like the bullseye model. I found it very confusing. Those viewpoints may work for other topics, but not so here.
toddbiske .@aleksb6 Just read your blog: http://bit.ly/q8G0A Two comments to follow in individual tweets.
Interesting conversation (via Twitter) with Johan Lindberg (@johanlindberg) on how ITSM fits (or doesn't fit) into Enterprise Architecture Capability Map:
johanlindberg @aleksb6 interesting, but shouldn't it include an ITSM/operations perspective, or am I missing something?
johanlindberg @aleksb6 meant to write ITSM/operations capabilities, not perspective.
aleksb6 @johanlindberg ... ITSM is there - Tech Asset Mgmt, Engagement Mgmt, and Demand Mgmt should sound familiar ;)
johanlindberg @aleksb6 sure, but that's quite a small subset and all of them within org perspective what about change/incident/service level mgmt etc?
aleksb6 @johanlindberg ... are those really #EA concerns?
johanlindberg @aleksb6 but then again, maybe we're just using different labels on stuff
aleksb6 @johanlindberg ... not really, we're using similar labels (#ITIL is ITIL). I don't think #EA should 'do' operations - leave that to IT Ops
johanlindberg @aleksb6 Perhaps not. But then where do you draw the line? In my mind EA is about making the business work better and that includes IT ops
aleksb6 @johanlindberg ... IT Ops is part of Tech Ref Arch, just like #appdef #infosec or any other technical domain
I find it surprising that you list capabilities to manage reference architectures, but not the capability to manage the repository of implemented architectural models, or the development of alignment and funding guidance from the implemented architectural models.
In other words, it appears that you missed "business-IT alignment."
Of course, it is possible that you are using the term "reference architecture" in a manner that is different than I am. However, fairly well understood definitions of reference architecture are clear: A reference architecture describes a pattern. It is not a directly implemented model. You can implement a reference architecture... or not. Your implemented model nearly ALWAYS varies from a reference architecture.
Yet most, if not all, of your key architectural decisions, and the roadmaps that reflect and embody those decisions, are based on the gradual change in implemented architectures.
Why is that idea not captured?
Note: the bullseye viewpoint is not useful for this context, IMHO. That is not to say that it is not useful in other contexts. I just don't see the use of the bullseye to add anything at all to the conversation, especially since some of the circles are sparse or empty.
To comment on the twitter conversation, IT Operations does have a position in EA, but only in defining and roadmaping of IT Services.
That maturity of that capability is dependent on the quality of information managed by IT Operations processes like change management and incident management.
Measurement of IT services, problem identification and resolution, configuration management, and most of the other ITIL processes are, IMHO, outside the concern of the Enterprise Architect.
Nick -
A couple of thoughts.
1. Business/IT Alignment is a Goal, not a capability. It can be achieved by integrating multiple capabilities from this map.
2. While I don't necessarily disagree with your thought on what Ref Arch is, it needs more delineation: In our view Reference Architecture includes the following:
a. Framework - e.g. classification of thought in organization's local language
b. Architecture (logical) Patterns - e.g. here's how others in the organization have solved a problem that requires ...
c. Physical (design) Patterns - e.g. here are the tools, bricks, etc. that you need to apply to solve your problem
d. Applied Methods - e.g. analysis methods like capability assessments that connect the reference material to project-level artifacts
How these are implemented as services and processes is sufficiently unique from client to client. So while the idea is actually captured in those boxes, for brevity and readability sake, the map couldn't be published with all goals, services and dependencies between all levels. The bullseye in this context is useful to show that EA is really not about technology.
3. Agreed on ITSM. EA has a role in planning, but not delivery or operations (outside of assurance). That doesn't mean that EA couldn't incubate this organization if it didn't already exist and spin it off. That can be a very successful MO for identified capability gaps.
Post a Comment