Capability Analysis
Enterprise architecture has a major function of developing artifacts on current and future state. The TOGAF ADM describes artifacts like target architectures, reference architectures and domain architectures. In my experience as an Enterprise Architect, we attempted a new way of looking at the domains that we supported, namely Capability target architectures. These were targets that absolved the solution portions of the targets and basically said that in to support this specific domain, certain capabilities had to be in place. We then took those capabilities and mapped them against the domain in which we were responsible and began to look at them across the enterprise. During the effort we also attempted to show wasted investment through duplicative capabilities.
Several issues arose with this approach. First we found that the capabilities that were captured not consistent in granularity. This led to false-positive duplicative capabilities in the enterprise. Additionally, once we tried to level the granularity, what was missing was the context of each of the capabilities. In business architecture, we managed to get the capabilities to a relatively stable format through the use of verb-noun and vet-adjective-noun relationships. Once we tried to link in technical or data capabilities from the other tiers, we ran into the granularity problem once again.
Eventually these views did not prove as useful as originally thought but led to interesting conversations about investment. What I am looking to answer, is this a viable means of articulating value in the enterprise? In retrospect, was the granularity correct, should we have captured more data to link it all? How were these capabilities to be measured?
Digging deeper, I wonder if enterprise architecture could take a few pointers from the process gurus, black belts, who conduct kazens, gemba walks and often assess process capabilities. I found them to align with what we were looking to do, but using a process lens to do it. Harvard business review talks about process capabilities and how to assess them. How much can we reuse from other disciplines as enterprise architects?
https://hbr.org/2007/04/the-process-audit, Michael Hammer
http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap05.html
Views: 3
Mike,
Thank you for your post. Instead of a disheartening frustration, I found inspiration in the story that you have shared.
The issues themselves wouldn't have come out, if the team was not trained with cross-discipline techniques which — to my mind, are all essential tools needed to bring clarity by methodically going through steps, towards identifying the sticky spots.
Many years ago, learning early to program only from books, I later wondered in formal school why we needed to draw data flows, flow charts, etc. I really came to understand the answer, much later, when the systems we were developing became monster complexities, and I was no longer tasked with just a small specific piece. As architects, the only way we could have seen the elegant paths, was when we have identified specific areas to dissect through the discipline and communication of the models.
Thus, I agree completely — The nature and name of the beast is Complexity. The EA discipline cannot work through this complexity as an isolated practice, but rather, a practice that needs to collaborate with project management, systems engineering, behavioral science, general business administration, and many others.
I have placed a related comment on Scott O's blog for this week, which complements this, and perhaps you will also find interesting.