Architecture is about appropriate context
I reviewed an architecture capability model from a colleague recently and one of my responses was that I didn’t like the categorization that was used for the capabilities. While I had no issue with the capabilities themselves, the way that it was organized didn’t make sense to me. I probably spent more time trying to figure out why those categories existed rather than focusing on the capabilities themselves, which were the more important factor.
Enterprise architecture is all about context. EA, by itself, doesn’t deliver technology solutions. A traditional architect delivers a model of a structure, someone else goes off and builds that structure. The architecture provides the context that constrains the decisions made by the builders. Provide poor context, and you increase the chances you’ll wind up with a poor building. My wife has been watching Design Star on HGTV, and it’s very interesting watching the home owners interact with the future designers. A key thing these designers are being judged on is their ability to understand the needs of the home owners. This includes not just what the home owners say (and don’t say), but also the entire space around them. The designer could come up with a great design when evaluated in a vacuum, but if it’s out of context of everything around it and the wants of the home owner, it is a failure.
The same holds true in the world of IT. Provide poor context, and you increase the risk that the developers will build something that just doesn’t work well with everything around it. As Enterprise Architects, it is our job to provide appropriate context for the enterprise concerns. Project sponsors are provide context of their functional needs, it all must be balanced together.
Getting back to my opening statement, as technologists, often times we wind up focusing on providing a context, rather than the right context. It is easy to get caught up in the categories rather than the things being categorized and the purpose for which they are being categorized. I strongly believe that there are always multiple ways of categorizing something, and whether it’s appropriate or not is based on the purpose of the categorization. This is consistent with the multiple viewpoints approach emphasized with TOGAF. Don’t get caught up in coming up with one good categorization for one purpose and then trying to cram that same categorization into everything else you do, because it probably won’t fit. The context must be appropriate, and it’s the job of enterprise architecture to deliver it.
3 Responses to “Architecture is about appropriate context”
Leave a Reply
Todd,
What you called context I would call framework.
Capabilities are used by some to model the Enterprise. It is not clear what they are. I would say they are what an Enterprise “can do” in an external view.
I use the busines function concept (to model the Enterprise) which is a logic unit of the Enterprise.
I think that a high level categorization is useful. I proposed a business reference map (template), as generic as possible, which is a result of own experience, Porter’s value chain concepts, value streams design and an own business structure, partitioning the Enterprise in Governance, Operations, Development and Support (GODS) funtions.
Adrian
Adrian-
I specifically did not use framework in the discussion because they sometimes can be part of the problem. A framework like TOGAF does provide a context, however, it should be considered a starting point. Too often it becomes the end desination and the conversation shifts to force fitting things into the framework rather than adjusting the framework to fit what the customer needs. When the framework becomes an inhibitor rather than a supporter, it’s a problem.
Todd,
I agree, the framework discussion is daunting and does not fit in here. Still the framework is approximately that: the “model of a structure, someone else goes off and builds that structure” to quote you.
According to TOGAF, any business has a structure that, is the result of an architecture continuum starting from a generic view, then industry tailored and ultimately company specific. This structure, revealed by an EA framework, cannot change, at least in the as-is form, no matter what the customer’s needs are.
The aspects of the Enterprise you model and the future Enterprise state and transformation roadmap change though with the customer’s needs as you pointed out, but not the framework.
TOGAF is, unfortunately, more of a process view rather than a structure or context, for most.