Comments on Agility is Sensible: Enterprise Architecture Capability Map

@Nkemp Thanks for your comments. You are right on ...

2011-01-03T12:58:16.419-06:00

@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.

The problem with this map is clearly laid out in t...

2011-01-02T11:09:51.940-06:00

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

Nick - A couple of thoughts. 1. Business/IT...

2009-09-11T07:39:58.309-05:00

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.

I find it surprising that you list capabilities to...

2009-09-09T20:42:42.780-05:00

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.

Interesting conversation (via Twitter) with Johan ...

2009-09-06T09:27:35.886-05:00

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

Todd's initial reaction: toddbiske .@aleksb6 ...

2009-09-06T07:48:47.144-05:00

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.

This has been posted in several areas, and we'...

2009-09-06T07:46:01.791-05:00

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.