For various reason I've started looking at this issue again and have just refamiliarized myself with TOGAF (The Open Group's Architecture Framework). I had forgotten how much I liked it: it is pragmatic, highly tailorable and focused on open cross-organizational solutions. I'm not going to do a detailed analysis of TOGAF vs. other frameworks -- it's not really my interest as I'm definitely in satisficing mode here. What follows is my (long) elevator pitch of the TOGAF take home message.
The top level graphic of the TOGAF process captures the flavor pretty well
The preliminary phase is key but very easy to overlook. TOGAF suggests that this phase consists of defining the overall objectives and scope
- Define Objectives
- Assure that everyone who will be involved in or beneﬁt from this approach is committed to the success of the architectural process
- Define the architecture principles that will inform the constraints on any architecture work
- Define the ‘‘architecture footprint’’ for the organization — the people responsible for performing architecture work, where they are located, and their responsibilities
Define Scope and Assumptions
- The business units that are involved
- The level of detail to be deﬁned
- The speciﬁc architecture domains to be covered (Business, Data, Applications, Technology)
- The time horizon that should be addressed by the architecture.
- The business units that are involved
What I find attractive about this whole approach is its focus on getting getting buy in from the key players in the organization, defining their roles and developing a shared set of expectations around what's going to be done as part of the architecture effort. The preliminary steps give the team some initial criteria for driving the architectural vision, but then TOGAF immediately requires them to ground it as supporting the needs of the business users. I find this grounding critical; often the business thinks that architecture efforts are worthless and often they are right because the architectural model hasn't been grounded in the business process. Note: in this case "business process" and "user's scientific process" are equivalent.
The key to the success of an architecture effort is to address current pain points as they will be reflected in the business processes that will be in place when the architecture rolls out. Sorry if the tense of the last sentence was a bit torqued. What I mean is that the architecture needs to hit a mark to support business operations as they will be in the future, not as they are now, and that some of the problems that are being experienced now will only be exacerbated by these planned changes.
The dialog with the Business Unit leader sounds something like
We're planning to do more collaborations in the future, but with our current collaborations we have a terrible time registering new users and tracking responses to our questions about the data. However, if we put an architecture in place which uses our new authentication mechanism that supports OpenId it will radically simplify the process of adding new users.
In addition, if we use vendor X's implementation of the Life Sciences Industry Architecture, queries will be automatically tracked.
Our ability to handle more collaborations on the back end is increased as our new system allows us to share extra capacity across multiple business units, thereby sharing the cost of reserve capacity to meet any unanticipated surges in demand.
Such a "political/operational" model for rolling out an architectural analysis implies that everyone who contributes to the effort should get something out of it (this is a goal, but the closer you can come to meeting the goal, the more self-organizing the system becomes).
As one proceeds around the TOGAF loop, you pick and choose what makes sense given the decisions made previously (which of course you are always free to revisit) analyzed to the level of depth that is appropriate.
Think of TOGAF as providing a (partial) checklist of processes to use and things to consider that help you reach the end state of
Boundaryless information flow (tm)
I think of it as being similar in spirit to the way the Software Engineering Institute's Risk Management Taxonomy provides a comprehensive checklist of things to consider when undertaking a project -- it keeps you from forgetting something that would be obvious in retrospect.
My favorite quote from one of their pages:Another company is developing a flight control system. During system integration testing the flight control system becomes unstable because processing of the control function is not quick enough during a specific maneuver sequence.
The instability of the system is not a risk since the event is a certainty - it is a problem.