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!
7 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.
The problem with this map is clearly laid out in the nature of the comments that follow. The business capability map is a picture, not a model.
The first clue is in the fact that the specification of the capability map is that it is a "hierarchical decomposition". this in and of itself leaves too much to the judgement of the analyst. For this reason alone I seek to avoid such decompositions at all costs.
To be a model, there must be a "grammar" attached to the representation, which each shape carries meaning and where the relationships between the shapes leads to valid and meaningful statements about what is being represented. I see no evidence of that in this "model"
I have no doubt that creating a model that links the facilities and resources to the enterprise value proposition or some other goal, but I sure don't see it here
@Nkemp
Thanks for your comments. You are right on several levels but since we don't spell out everything is a single post and you probably don't have the time to go through each post either let me clarify some things that you bring up.
1. The capability map presented is generic and not specific to a particular IT or business. Therefore it will lack specifics that some readers may expect.
2. We separate presentation from proof. So it is a picture and not a formal model. See our post http://www.agilityissensible.com/2010/09/what-business-architecture-and-pudding.html to read more on this.
3. There is nothing wrong with decomposition. Most design and analysis depend on it. Other models such as a capability dependency diagram are behind the one presented as are CBA spreadsheets. Much socialization is required for this picture/model and any other models required for any business architecture approach. Formal diagrams also require such socialization to avoid the 'judgement of the analyst'.
4. The grammar behind the model is presented in our Capability Based Business Architecture (CBBA) course although if you are mathematically minded regarding your model definitions then you would probably be dissatisfied. But there is a meaning to each symbol as in Goal, Objective, and Capability. This is fairly strict but as you point out it is not in evidence in the model itself. I would only ask should the model's notation or the metamodel be described in a model instance? I suppose not.
Post a Comment