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