SERVICE-ORIENTED ARCHITECTURE IS HERE TO STAY...FOR NOW

You can't pick up a technology publication today without seeing articles that mention web services and service-oriented architecture (SOA). Are these the "next big thing" in technology? Do we have something new and exciting happening? Or...are these re-packaged ideas we've heard before?

Of course, technology alone cannot be a "big thing". The technology must be embodied in a practical and useful product. There is something new and worth talking about in SOA but there is also some re-packaging going on that you should know about.

SOA is not an entirely new concept. In fact, as far back as the 1970's software engineers were thinking about encapsulating software functions to separate logical flows. Do phrases like modular design, reusable components, object-oriented programming or application programming interfaces sound familiar? These concepts are not identical to SOA but they are similar to it in some way.

Over the years the idea of software encapsulation has undergone several evolutions. In the 80's we had CORBA. In the 90's it was J2EE and DCOM. Today it's SOA. And this won't be the last incarnation.

So what do these concepts have in common?

They are founded on the idea of distributed software modules or components. That is, creating a software application as a collection of building blocks where the blocks exist almost anywhere on a computer network.

In today's world, the network can be as small as a local workgroup or as large as the Internet. Managing all these building blocks is the core problem that has escaped a solution - until now.

Each software component must have a documented way to invoke it. The function it performs must be well defined leading to a proven result. The key to making distributed software components work is having a structured way of managing the pieces and enabling them to exchange data. The components must be loosely coupled, that is, independent of each other. Yet they must also integrate seamlessly.

In the 70's, 80's and 90's, we simply did not have a powerful and flexible way to define and manage components and their data. This resulted in software applications that were tightly coupled internally. That is, the components and data were interdependent making it cumbersome and costly to make changes to the software.

Today is different. We have eXtensible Markup Language (XML), Simple Object Access Protocol (SOAP) and the Web Services Description Language (WSDL). XML is a standard way to describe data. SOAP is a standard way for components to exchange messages based on XML. WSDL is a standard means of describing a software component, commonly called a web service, using XML. At last we have a way to loosely couple software components, locate them anywhere and manage them effectively.

Now, let's get to why this matters to you.

SOA is a framework for structuring a software application. It requires that the software engineers design a set of components called web services that communicate via messages. Unfortunately, there is no immediate payback. So why bother?

The payback occurs over time. The software application should be simpler to test, easier to maintain, and quite durable. The business benefits are higher quality, lower cost, and reusable software.

This logic applies whether the software is built in house or purchased from a third party. Either way, the web services should provide more value for a longer period of time than traditional big-iron software.

Here are some things to keep in mind as you plan future application development projects or consider the purchase of software that claims to be built using SOA.

The best SOA implementations are founded on business processes. In other words, the software segmentation should be aligned with business functions not technology elements. If you don't have a documented definition of major business processes and associated rules, your SOA implementation will not deliver full value.
Application software vendors are delivering ready to use web services. However, you may need to modify your business processes and rules to achieve the alignment mentioned above and get full value out of the software.
SOA is not an all or nothing solution. You can continue to use the software you have today while you migrate new software toward SOA. It is even possible to wrap legacy software with a SOA front end to avoid re-writing major existing components.
System software vendors such as IBM, Infravio, Flashline, Microsoft, Oracle, Sun and Systinet can supply the infrastructure needed to manage web services. Question these vendors on their compliance with industry standards. Interoperability is essential to a successful transition to SOA.
Pay added attention to security and business continuity. Because web services can exist anywhere on the network, security becomes more difficult. The components may be distributed across multiple computers and network segments providing additional points of entry. Similarly, disaster response can also become more complex because a larger number of systems are involved.

SOA is not the "next big thing" but it's not just another re-packaged idea either. As software becomes more complex and spread out across multiple network servers, we need a way to reduce redundancy and improve quality. SOA holds out the promise of helping us meet these business objectives.

Vin D'Amico is Founder and President of DAMICON, your ADJUNCT CIO™. He is an expert in IT Business Continuity Planning, Network Security Policies, and Freelance Writing focused on white papers, case studies, and handbooks. DAMICON services firms worldwide.

This article appeared in Vin's monthly Virtual Business column for the IndUS Business Journal in December 2005.

To learn more about how DAMICON can help your business, please take a look at our service programs.