Is your SOA stuck in Groundhog Day?

In the movie "Groundhog Day," Bill Murray's character is forced to relive the same day over and over again until he learns some valuable lessons that had been awaiting him all along. If you're an IT person in the middle of an SOA project, you can likely relate to this dilemma. You might even be wondering whether you're becoming the Bill Murray character and noticing that your boss is looking more and more like Punxsutawney Phil who casts a long and dark shadow that can drastically alter your next six weeks, if not more.

With so much emphasis on SOA these days, there's a heightened focus on its deployment, success and demonstrable ROI. In fact, Gartner states that the worldwide market opportunity for SOA, including software and services, will continue to grow through 2008 when it's expected to reach $143B. Further, Aberdeen recently underscored the growing value of SOA with its findings that companies can save up to $53 billion in IT spending over the next five years by implementing a service-oriented architecture.

Clearly, SOAs hold enormous potential to more closely align IT with the needs of the business. And with this potential comes the realization that IT can't burrow through the deployment and still expect it to be successful by relying on a parochial create/reuse strategy.

If this scenario sounds familiar and you're relying solely on traditional, existing Web services to build your SOA, you may be creating your own Groundhog Day. As you know, an SOA is far more than a collection of Web services. Its success requires governance to establish the ground rules and make sure that all the hard work associated with modeling, assembling, deploying and monitoring your SOA is not all for naught. Without modeling your business and fully understanding the SOA that you wish to deploy, you may risk limiting the effectiveness and full potential that can be derived from an SOA.

Creating a repository of Web services will always be a critical and inherent part of your SOA. Further proving this is the proliferation of industry-specific Web services that are being made publicly available in an effort to streamline SOA development efforts and share best practices.

The point here is not to diminish the value of reuse throughout your organization. Rather, it's to inspire you to extend your architecture to include the latest industry standards when creating services.

This becomes especially important in light of the fact that SOA developers and architects today are challenged by the need to:

By tapping into new standards, you will be able to accelerate your SOA deployment and begin to take advantage of greater business flexibility that will be built into your architecture.

While there a number of hot, emerging standards in various phases of ratification, let's take a closer look at three of the newest advances in standards that will significantly and positively impact your SOA's success. These three include the Service Component Architecture (SCA), Service Data Objects (SDO) and the Tuscany project.

SCA and SDO, recently announced together, are the result of a collaborative effort driven by IBM, Oracle, BEA, SAP and several other industry leaders to simplify how you create and implement applications in an SOA.

SCA and SDO can greatly reduce the complexity associated with developing applications because they provide a way to unify services regardless of programming language and deployment platform.

SCA is specifically designed to simplify how service oriented business logic is represented. One of the key benefits of SCA is that is provides developers and architects creating the SOA with the ability to represent business logic as reusable components that can be easily integrated into any SCA-compliant application. Additionally, SCA differentiates itself because it has been created specifically for SOA, unlike J2EE which has been adapted SOA.

Developers and architects can gain greatly by leveraging SCA because it makes building applications significantly easier. For example, SCA allows a developer to focus on writing business logic instead of being overly concerned with the programming language. This becomes especially critical as organizations strive to more closely align IT with the business – which is, as we know, at the heart of an SOA.

SDO helps users specify a standard way to access data and can be used to modify business data regardless of how it is physically accessed. This is especially beneficial to the creation of an SOA because users don't need to know the technical details of how to access a particular back-end data source in order to use SDO in their composite applications.

Complementing SCA, SDO provides a common way to access many different kinds of data. The key benefit of SDO is that it reduces the skill levels and time that is required to access and manipulate business data. For example, developers today must tap into a multitude of APIs in order to access and manipulate data. The challenge here is that these same APIs tend to tightly couple the source and target of the data. As you can imagine, this approach increases the chances of error and is subject to breaking as business requirements evolve. SDO practically eliminates that problem because the specification makes it easier to realize the value of APIs without having to code directly to them.

Through SCA and SDO, you can more easily create and transform existing IT assets into reusable services that can be rapidly adapted to meet changing business requirements. The additional benefit of tapping into SCA and SDO is that these standards can greatly reduce the complexity associated with developing applications because they offer a way of unifying services regardless of programming language and deployment platform.

SCA and SDO will play an especially critical role in SOA governance. Since governance is primarily focused on the development process and on the tracking and control of development artifacts, SCA and SDO can help integrate applications in a non-intrusive manner while helping oversee the entire development process.

On the heels of the SCA and SDO news is Tuscany. Tuscany provides the community with a Java based implementation of SCA – so that these specifications go far beyond paper exercises – but exist in real code that the community can experiment with in parallel with completing the standardization process.

SCA, SDO and Tuscany, working in concert, will continue to evolve through the industry-wide commitment to easing SOA deployments. With their evolution will come the dissipation of the former burrowing approach to SOA. Customers who are interested in getting the benefit from these standards will also want to consider deploying an ESB.

An ESB provides a connectivity infrastructure that you can use to integrate services within an SOA. The value of an ESB can't be overestimated. Gartner findings report that ESBs will supersede several types of traditional middleware because they are better-suited to modern application styles, such as service-oriented architecture (SOA) and event-driven architecture (EDA).

Together, SOA and an ESB help to reduce the number and complexity of interfaces, enabling you to focus on your core business issues, rather than on maintaining your IT infrastructure.

As SOAs continue to dominate the landscape, SCA, SDO and Tuscany will help accelerate deployment and success while alleviating some of the challenges presented by the traditional approach to reuse. Using a standardized programming model will help SOA developers and architects with the portability of services and in particular the ability to gain interoperability between various tools for creating services and mixed deployment platforms.

With SOA as the strategy and an ESB as the glue supporting myriad new and proven Web services that are in adherence with your overall approach to governance, you're sure to reap greater rewards from your IT investments.

And who knows, maybe you'll be glad to see Phil's shadow after all.