Frameworks and Methodologies and Styles, Oh My!
The management team here at ZapThink likes to joke that we get along together better than most married couples, but that doesn’t mean we don’t have the occasional argument. A recent spat centered on the question as to whether the Department of Defense Architecture Framework (DoDAF) was relevant to Service-Oriented Architecture (SOA). One perspective was that as an Enterprise Architecture (EA) framework, DoDAF was at a higher level than SOA, and didn’t have any SOA-specific content; another perspective was that the US Department of Defense (DoD) strongly supports DoDAF and SOA, and thus interested parties both within the DoD as well as at defense contractors would be quite interested in learning how architects might apply DoDAF to SOA.
The moral of this story, of course, is that both perspectives are correct, and as a result, ZapThink recruited a DoDAF subject-matter expert to help us present our upcoming DoDAF for SOA course. Our altercation, however, brings up some interesting questions that apply to EA frameworks in general: how do such frameworks apply to SOA, and more importantly, how should you use an EA framework to support your SOA efforts in order to increase your chances of success with your SOA initiatives?
EA Starting Point: The Enterprise Architecture Framework
Ever since ZapThink first called out the elusive Enterprise Architect (also abbreviated EA) back in 2003, we’ve been challenging EAs to step up to the plate and come out swinging at their organization’s SOA projects. Even today, as SOA becomes a mainstream approach or style of Enterprise Architecture, many EAs still think that SOA and EA are separate, mostly unrelated initiatives — to their organization’s detriment.
We know we’re preaching to the choir here, since if you’re an EA who’s reading this ZapFlash, you no doubt recognize the close connection between the two topics. The fact still remains, however, that for many practitioners, the connection between EA and SOA is tenuous at best. You’d think that because SOA enables organizations to better organize IT resources to better meet changing business process needs, EAs would be fully supportive of their organization’s SOA efforts. Unfortunately, for many seasoned EAs, the tools and approaches they’ve been using for years have little or no connection to the best practices that are the SOA architect’s stock in trade.
To understand the EA’s point of view, a good starting point is the EA Framework. Starting with the Zachman Framework for Enterprise Architecture, EA frameworks have provided general best practices for EAs for many years. Today, there are many such frameworks, including The Open Group Architecture Framework (TOGAF), the Federal Enterprise Architecture Framework (FEAF), as well as DoDAF and several others. While each of these frameworks has a different focus, there is also substantial overlap, in large part because one has influenced another, starting with the first, the Zachman Framework.
An architecture framework is a tool for assisting in the acceptance, production, use, and maintenance of architectures, according to TOGAF documentation. The architectures that definition refers to may be different types, including business architecture, data architecture, application architecture, technology architecture, etc. When the architecture framework is an enterprise architecture framework, then, it provides tools for any or all of these narrower architectures, depending upon the broader needs of the enterprise as a whole.
SOA, on the other hand, is a style of enterprise architecture. In other words, SOA best practices are a subset of all EA best practices, but don’t fall neatly into a narrower type of architecture. Herein lies much of the confusion: an EA framework provides tools for various architectural activities independent of whether those activities fall into the category of SOA best practice, even when an organization is implementing SOA. Furthermore, as an EA style, SOA best practices fall under each of the narrower architecture definitions. For example:
- Business architecture: best practices for applying SOA to the organization’s governance framework
- Data architecture: best practices for specifying and maintaining the Data Services Layer
- Application architecture: best practices for abstracting legacy application capabilities as Business Services
- Technology architecture: best practices for designing and deploying the intermediary pattern
The tools an EA framework provides are largely orthogonal to such style-specific best practices. In other words, the EA framework might provide data architecture tools that architects might see fit to use to put together their Data Services Layer, but then again, they might use those same tools for tackling data architecture in a non-SOA way as well. Furthermore, the EA framework will let such architects have it either way.
On first glance, the natural conclusion might be that EA frameworks are too high-level to be of much use for SOA projects. While that perspective might be true of some frameworks, it doesn’t necessarily follow for all of them. Rather, the tools that make up the framework apply to different architectural styles by design, and as a result, leave many of the specifics up to the architects to work out for themselves.
Methodology: The Missing Piece
Perhaps the greatest issue with many EA frameworks is that they are not sufficiently prescriptive — that is, they provide tools but they don’t tell you how you should use them. The processes the architecture team must follow to successfully create and implement an architecture is more of a methodology than a framework per se. You can think of a methodology as a recipe, or more precisely, many recipes that an organization can follow to achieve specific results. Methodologies are familiar from the software development world, where techniques such as the Rational Unified Process, the Spiral Methodology, or Agile methodologies like Extreme Programming or Scrum are now quite mature. Such methodologies are explicitly prescriptive: they tell various members of the software development team what they should do in particular situations.
Architecture as a practice, however, doesn’t lend itself to a methodological approach the way that software development does. There is no simple recipe for good architecture. As we say in our Licensed ZapThink Architect course, it would be great if there were a “SOA wizard” — you know, click, click, click, and voila! You have a SOA! But that will never happen, because there is no such recipe. The actual steps you must take to design and implement SOA properly vary too widely from one organization to the next, because such steps depend upon the specific business problems, the existing technology environment, as well as cultural and political issues within the enterprise.
Just because there are no wizard-like recipes for how to do SOA, or any architecture style for that matter, that doesn’t mean that it’s impossible to come up with an effective architectural methodology. After all, architecture consists of best practices, so a resource that delineates such best practices in sufficient detail might be considered a methodology. The problem, however, is that architecture best practices aren’t absolute, but rather, dependent upon the problem at hand — what we call the right tool for the job.
This point brings us back to the discussion of EA frameworks. The fact that architecture consists of problem-dependent best practices is inherent to what it means to do architecture, and all useful EA frameworks reflect this fundamental point. Remember, an EA framework is a set of tools, and as with any complex task, the tools themselves don’t complete the task; rather, people that know how to use the tools do. A methodology may be a set of recipes, but no cookbook transforms you into a cook. Furthermore, as an architectural style, SOA cuts across frameworks and methodologies to provide specific techniques — the ingredients in the recipe, if you will. Successful architecture depends upon all of these: tools, recipes, ingredients, and most of all, skilled architects who have the knowledge, experience, and common sense to put them all together.
The ZapThink Take
Some architects make the mistake of focusing more on theory than on practice, choosing to remain high level. Such architects are typically comfortable with EA frameworks, but often lack the practical experience or predilection to succeed with SOA. At the opposite extreme, other architects are more comfortable with the technical details. These professionals are often developers or integration specialists who’ve moved into the architect role but are still more at home with ESBs and lines of code than with tools like EA frameworks. The most successful SOA architects, however, are the ones that combine both skill sets, people who are comfortable taking an EA framework, selecting the tools it provides based on the problems at hand, and applying them in the context of SOA best practices.
This bit of advice is not new, however — we first presented it when we discussed how to apply the Zachman Framework to SOA back in 2006. Today, we can expand that insight to EA frameworks in general, especially now that they are all taking the SOA style into account. Work still remains to be done, however, to connect EA frameworks to SOA in a way that also offers a methodology that leads to successful implementations of the architecture. Stay tuned — this area is central to ZapThink’s research for 2009.