WebServices dot org

3 SOA Predictions for 2005

You know the old saying: “I’m still writing 2004 on my checks.” Fortunately, I pay all my bills on line, and the date and time on my computer is synced with the atomic clock in Colorado.

2005 promises to be the year of the SOA, again, and there are a few things that I see happening in this space. Perhaps I’m wrong, but I guess you can send me this link a year from now if I am.

First, the focus will move from the capabilities of this technology, to the value. Let’s face it, most companies are not driven by the “sizzle” of the technology, but more from the “steak.”In other words: How will implementing SOAs save use money, short term and long term?

In the past, ROI was difficult to define, and clearly not on the mind of those pushing newer, cooler tech…I call these guys the “manage-by-magazine” crowd.While it’s always good to be ambitious, we’ve seen many get burned by technology that seems cool on paper, but could not deliver value when in place. Example are, network computing, push technology, and AD-Cycle.I’m sure you can name a few, perhaps have the scares to prove it.

Today, you have to justify any changes to IT, and when building a SOA within your organization it’s pretty easy to define the value or savings, including:

Dollar savings from a proper SOA strategy within a large organization, if designed and implemented correctly, could be a fifty percent reduction in cost over a 5 year period. This good cost justification in my book.

Second, the rise of true service-oriented approaches and technology, and the fall of information-oriented approaches and technology. Truth-be-told, we’ve been focusing far too much on information-oriented technology recast as service, such as JMS-based messaging systems with service interfaces, and not enough on true service/behavior-based capacities that provide much more value.

True service-oriented approaches and technology focus on the capabilities or behavior of the participating applications or services (local or remote), as well as the information bound to those services or behaviors. Information-based technology may indeed leverage services, but only a mechanisms to access information. However, their approach is still information-oriented nonetheless.

Little by little those building SOAs are learning about the differences, and that the most value exists when using a true service-oriented approach, including the ability to reuse services/behaviors to create new composites, as well as the ability orchestrate these services into meta-, sub-, and composite-processes, that may also exist as services. Thus, in 2005 we will learn to understand that ESBs have a place in a SOA, but are only part of a complete SOA solution, and in some cases are not needed.

Finally, in 2005 I think that ontologies will become more of a focus as larger organizations plan for a SOA. When dealing with SOA, as you know by now, we are dealing with much complexity. We have thousands of data elements that we have to track, hundreds of domains, and the need to map the differences.Moreover, with the added complexity of service oriented mechanisms, we are also tracking meta services as well, or behavior as well as information.

The notion of ontologies helps the SOA architect prepare generalizations that make the problem domain more understandable. In contrast to abstraction, generalization ignores many of the details and ends up with general ideas. Therefore, when generalizing, we start with a collection of types and analyze commonalities to generalize them.

Clearly, semantic heterogeneity and divergence hinders the notion of generalization, and as commonalities of two entities are represented in semantically different ways, the differences are more difficult to see. Thus, ontological analysis clears the ground for generalization, making the properties of the entities much more clear. Indeed, ontological analysis for SOA encourages generalization. Thus we can say, “Within an ontological framework, integration analysis naturally leads to generalization.”

Considering that statement, it’s also clear that application independence of ontological models makes these applications candidates for reference models. We do this by stripping the applications of the semantic divergences that were introduced to satisfy their requirements, thus creating a common SOA foundation for use as the basis for an SOA project.

Returning to the core problem we wish to solve within SOA domains, we are looking to achieve semantic interoperability between very different systems (information as well as services). The solution to this problem is based on our ability to leverage formal ontologies required to account for the different types of ontologies for any business reason. For example, we can have resource ontologies we leverage to define semantics used by our SAP systems, but we may also have personal ontologies defining the semantics of a user or a user group. In addition, we have the notion of shared ontologies, which are common semantics shared between any numbers of information systems.

2005 appears to be the year that architects, developers, analysts, and DBAs, get to the valuable work of building a strategic SOA, and there is much to do with planning, architecture, as well as creating business cases for those that pay the bills.This is good work that will produce good results, and I can’t wait to see the efficiencies that we bring to IT in 2006. But that blog is a year away.