Reference Models, Reference Architecture, and Enterprise Architecture…Oh My!

Some of you may have tuned into the Shared Insights Webinar on “Marching Toward SOA: Does EA Lead the Band?” I can’t find the archive of it, by the way. However, there is a good summary article here, by Rich Seeley.

So, this is the larger issue, as I see it, and is very visible to me working both within the world of SOA and the world of Enterprise Architecture. So, why are they different worlds? Moreover, what is Enterprise Architecture, and how does it fit with reference models and reference architectures, as discussed in my two previous blog posts?

From Wikipedia:

“Enterprise architecture is the practice of applying a comprehensive and rigorous method for describing a current and/or future structure and behavior for an organization’s processes, information systems, personnel and organizational sub-units, so that they align with the organization’s core goals and strategic direction. Although often associated strictly with information technology, it relates more broadly to the practice of business optimization in that it addresses business architecture, performance management, organizational structure and process architecture as well.”

Thus, the notion has morphed from something that’s been more of a technology concept to a management concept, if you’re using this definition. I’ve blogged about that issue several times. Indeed I think the government is driving some of this, thus expanding the definition and reach of the notion of Enterprise Architecture.

“Enterprise architecture is becoming a common practice within the U.S. Federal Government to inform the Capital Planning and Investment Control (CPIC) process. The Federal Enterprise Architecture (FEA) reference models serve as a framework to guide Federal Agencies in the development of their architectures. The primary purpose of creating an enterprise architecture is to ensure that business strategy and IT investments are aligned. As such, enterprise architecture allows traceability from the business strategy down to the underlying technology.”

Also, from Wikipedia.

So, if we go with this definition we are moving from a high-level management notion, including strategy, business optimization, budgets, etc., to information technology, including SOA. EA is more holistic, where SOA is a more specific approach for building an IT infrastructure.

I’m not sure that I can do anything to change the definitions here, or eliminate the confusion when considering the number of ways everyone is slicing and dicing SOA and EA. At the end of the day, it does not matter as long as enterprises find the right approach that works for them. Typically that takes some effort and planning. Truth-be-told, there are no canned SOA solutions out there, at least, not ones that will have significant strategic value.

Besides ending the debate about unified semantics and vision, it’s also helpful to consider the “loop” as well, or, mechanisms we put in place to understand and create best practices based upon experiences with building and deploying SOAs. The key issue here is sharing information, something we’ve not been good at in the past. I can understand within certain industry-specific competitive situations where it’s not in the best interest of the company to share information.

There are a few issues as I see things:

First, as already stated, we need to clearly define use cases for SOA-RA and SOA-RM, and learn to adapt these models to the very different problem domains I’m seeing out there. Like any new notion, this will come with use, and these models and architectures will only be as valuable as the data points that are fed back to the creators, and the changes made to accommodate the “real world.” As a SOA practitioner I’m finding that a huge chasm still exists between those who define the concepts of SOA and those who actually do the work. That chasm needs to narrow significantly.

Second, what’s the uptake thus far when considering the concepts of SOA Reference Architecture and SOA Reference Model? It appears to me that most of my clients are pressing forward with their SOAs, formal models and architectures be dammed. Unfortunately, defining something in a formal way does not mean the rank-and-file will use it. I think the recent debate is a clear indication of that. I can go back in history and point to many instances where good formal models existed, but nobody leveraged them, opting for models that were more ad-hoc, understandable, and available. I do promote the standards effort, however. Please don’t misunderstand me.

Finally, SOA, at least in my mind, is a bit more systemic to enterprise architecture than just an “architectural approach.” Indeed, if SOA is to be successful, those responsible for enterprise architectures need to understand SOA. Many do, some do not. If SOA is going to provide the proper benefits, SOA needs to layer deeply into business processes, business strategy, information technology, and even capital planning. In essence, it becomes a new foundation in many respects, and as to the point I made many times before…a good SOA is a good enterprise architecture, and not a mere instance of technology or another silo. We need solutions, not another “bolt on” that just adds complexity, and hinders agility.

Hope this helps. On to more technical topics next.