- @chrisdpotts Appearing to not know the difference between a strategy and a roadmap can damage your reputation and influence.
There are several different reference models that attempt to answer such questions, at varying levels of detail and abstraction. Here are just a few of these models.
- ISEB Enterprise and Solution Architecture Reference Model (BCS Version 3.0 pdf)
- CBDI Service Architecture and Engineering Reference Framework (recently updated to include Cloud Computing)
- SOA Reference Model (OASIS pdf)
The Wikipedia page on Technical Architecture contains the following paragraph on Meta-Architecture, lifted practically word-for-word from a white paper on the Visual Architecting Process (Bredemeyer Consulting, pdf) by Ruth Malan and Dana Bredemeyer. Malan and Bredemeyer also appear to be behind the EWITA (Enterprise-Wide Information Technology Architecture) initiative.
"First, the architectural vision is formulated, to act as a beacon guiding decisions during the rest of system structuring. It is a good practice to explicitly allocate time for research in documented architectural styles, patterns, dominant designs and reference architectures, other architectures your organization, competitors, partners, or suppliers have created or you find documented in the literature, etc. Based on this study, and your and the team’s past experience, the meta-architecture is formulated. This includes the architectural style, concepts, mechanisms and principles that will guide the architecture team during the next steps of structuring."
Yawn. I can see that this kind of thing might be necessary for architecture management, especially across a large organization or sector. Tom Graves points out that we can view a reference model as a set of job descriptions. But explicitly allocating time to meta-architectural research??
My worry about meta-architecture is that it distracts from real architecture. If I have a lump of business activity, I'm not sure I understand it any better whether I label it as a function or a process or a capability or a service. What really helps me to understand this lump better, and to use that understanding in improving the business, is analysing how it varies by context (differentiation) and how it interacts with other lumps of business activity (integration). And it's more important to see whether a strategy or roadmap is any good than whether it's been correctly labelled. The challenge of architecture isn't classification, it is coordination and quality.
For my bootcamp next week, I don't want to spend any time on Functions versus Capabilities, Goals versus Objectives versus Principles, Strategies versus Roadmaps, and all that meta-architecture stuff. Some architecture courses seem to spend so much time on meta-architecture that they don't have any time left for real architecture. And one can waste a lot of time on the Internet trying to promote one's favourite definition of any of these terms. My winter's resolution - to keep out of these debates. (I may not always manage to do this.)
book now Business Architecture Bootcamp (November 22-23, 2011)
book now Workshop: Organizational Intelligence (November 24th, 2011)
Hello Richard
ReplyDeleteI agree that we musn't waste time on definitions. I was referring to actual behaviours.
If a conversation about behaviours is misunderstood to be about definitions - or vice-versa - it's a contraint for sure.
Mind you, there's only so far we can depart in our behaviours from what something actually means (e.g. strategy, architecture), before we're no longer doing that something.
---------
It's easy for motives to be misunderstood on Twitter. Thanks for the alert!
All the best
Chris Potts
Hi Richard - good points all (and yes, I know I'm one of the 'offenders' here...)
ReplyDeletePerhaps don't be quite so quick to write off all meta-architecture, though. To paraphrase some famous person whose name I have long forgotten (Patton, perhaps?), the plans - or, in this case, the actual 'definitions' from the meta-architecture - are less important than that planning (the process of meta-architecture) has taken place, and that people are familiar with both the process itself, and the need for it at real-world speed.
Just to take one seriously-problematic example, look at all the trouble we've had over the word 'complexity'? We need to engage people in questioning their assumptions about definitions and the like - otherwise we can find ourselves in real serious mess later on, when we find that different have been using fundamentally-different definitions on the design of the same project or process.
(Apologies - I used the wrong identity for the post - above is from Tom Graves)
ReplyDeleteHi Richard,
ReplyDeleteI pretty much agree with everything you said in this post. From my point of view, working as an enterprise architect in a large government department, I don't care about the meta-architecture, I am to busy trying to understand what the business is trying to achieve and lining up IT to help that. I beg, borrow and steal anything to get the appropriate actions to occur and generate the right outcomes. Good modelling or architecture correctness is far down my list of things that matter. To defend the Bredemeyers, their discussion of meta-architecture is in the context of software architecture, specifically large scale software writing projects, and in that space I think it makes much more sense. When it comes to enterprise architecture I think it is of significantly reduced value.
Cheers,
Doug
I appear to have misinterpreted Chris's tweet. Sorry.
ReplyDeleteAnd Doug defends the Bredemeyers, and thinks I've taken their material out of context. I am happy to acknowledge that most of their material is about much more interesting topics than this.
I take Tom's point about the importance of surfacing assumptions, but I am not sure that our misunderstandings about complexity (say) are ever going to be resolved by coming up with a standard definition of "complexity".