usage policy business analyst and technical writer

 Home  Who We Help  Services  Approach  Case Studies  Resources  Contacts  About Us


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.

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.

Virtual Business

Virtual Business

This column appears monthly in the IndUS Business Journal.