Demystifying SOA for Architects, Devs

2005 is setting up to be a banner year for SOA -- Services Oriented Architectures. This week Integration Developer News begins a series on SOA for architects and developers, with an eye toward looking at how to prepare your IT enterprise -- and your careers. This week a look at the core concepts of SOA, and why they can let architects/devs be more creative with less risk.

Tags: SOA, Developers, Business, Architects, Applications, Solving, Investment,

This is to be the first in a series of articles aimed at helping developers, architects and managers navigate the ever - shifting SOA landscape as you search for solutions to your SOA issues. Let's begin by taking some time to come to a common understanding of what SOA is -- and what it is not.

Getting the an understanding of SOAs right is the key to grasping how SOAs may be relevant to your software development challenges, and play a role in your next career move.

Not since the emergence of Java has a movement in the software industry gained as much traction as quickly as the idea of SOA. But just want are they? It seems as though there are as many definitions of SOA as there are people talking about it. [Even the World Wide Web Consortium, W3C, has published a standard, formal definition of SOA.]

Defining SOA for Architects, Devs

For our purposes, however, a more informal but practical approach to SOA may prove more useful. Let's start with what an SOA is not…SOA isn't a specific technology, such as web services; nor is an SOA a product that you can purchase from a vendor.

Rather, SOA is an architectural philosophy that promotes the development of applications not as single units with tightly couple business logic but rather as loosely coupled services, each of which perform a logical, discrete, business function. It is these loosely-coupled services, (that are the building blocks of SOA. [Sometimes, these services can even often stand alone applications in their own right]

Why SOAs Provide Key Benefits?

In today's cost-constrained IT environments, it will be "business value" that drives technology spending, which in turn will drive the next wave of career opportunities for architects and developers. Done correctly, SOAs will provides some key business values through SOA's ability to increased reuse of existing components, existing applications and especially newly-built software assets.

The distinction between the development of a tightly-coupled application and a set of loosely-coupled components (ready for assembly in a variety of ways), is one way to look at the powerful business values that SOA approaches can deliver.

Let's look at this "business value" in the context of a frontline development project. When a business driver -- such as better customer support, easier transactions with partners or tighter security for e-commerce -creates a demand for a new software application, that application can be created as a service or it can be developed as a stove piped application. The architect/developer has a choice of what approach to use to build that new software, and over time that choice will add to overall "business value" of that software.

For instance, if the application is developed as a stove piped application, than the application is only able to provide as much value as can be gained by addressing the single business need that prompted its creation. While this may be a significant return on investment, it is a potentially far smaller return on investment than could be realized if the application was created as a reusable service. In this case, value is realized not only from solving the immediate business need but by making the service easily available to solve other business processes.

SOA takes that investment in a software project, and extends the "business value" longer term. Using an SOA approach, new application can be created as a "service," which in turn provides the architect/developer with the opportunity to reuse (or more effectively leverage) that software IP in other projects. . This is especially true within large organizations where different organizational units share common business needs but are often unaware of these common needs.

Good SOA practices will not only help organizations create services instead of stove piped applications, they will create an infrastructure for discovering those reusable services within the organization. Through this two-fold process of service enablement and discovery, organizations implementing Service Oriented Architectures see far greater returns on their investments than do organizations who have yet to begin the transition to a SOA.

SOA -- More Creativity, Less Risk

Now that we have begun to explore the business value provided by SOA it is appropriate to talk about the technical value of SOA.. Put simply, SOA allows developers and architects design and build more interesting, feature laden applications with less risk. Let's step back for a second in order to examine why SOA provides these benefits.

Complexity has always been the demon against which developers are constantly struggling. The entire field of object oriented programming arose in attempt to deal with, among other issues, the inherent complexity of creating useful software. [The degree of their success (or failure) can be argued at length but the fact remains that enterprise applications have grown increasingly complex, often outpacing the growth of tools developed to reduce that complexity.]

Today we have more powerful programming languages, more complex and feature laden IDEs and more robust application servers, yet the enterprise systems we are called on the develop with these tools are still overwhelmingly complex. Requirements documents can often be measured by weight, as opposed to by number of requirements. Legacy systems have to be integrated with the new system under development. The system must have the highest possible security but also support single - sign - on in a manner that is nearly seamless to the end user. And oh, by the way, you have six months to design, build, test and deploy the solution. Have fun!

While the above scenario may hedge towards the extreme, it does serve to illustrate the very real issues. SOA can help us combat these issues in two major ways.

  • First, instead of attempting to build a monolithic application addresses all of the problems in an entire business domain, we can often focus on creating more reasonable sized services that focus of solving a particular problem within a business domain.
  • Next, we can plumb those previously built and tested services together in new and interesting ways to solve complex business problems.

    As developers, this gives us the opportunity to stop rewriting code that we have already written for multiple applications in the enterprise, because that code is now a separate service that we can reuse instead of being an embedded portion of a larger stove piped application.

    Freed from the burden of reinventing (and retesting) the wheel, we can move on to solving new problems. As we create these new applications that consume our existing services, we do so with a greater degree of confidence as the services that we are consuming have already been tested and shown to work. We can now focus our development and testing efforts on solving the new problem at hand, and maybe even sleep a little at night.

    In upcoming installments of IDN's "Demystifying SOA," we will look in-depth at specific techniques and technologies that are making a difference for SOA early adopters. and provide a road map to SOA success that can be used by managers and developers alike.