Feature

First, as you might have gleaned from that last thought, I'm a huge believer in SOA. But I've been a believer in what SOA represents for years. Heck, when I got started it was called structured programming. Everybody talked about it, but not many people did it. Why? It was hard to do. It actually took time to build structured and reusable code. But it paid off. Programs were far easier to maintain. And it was possible, if not easy to implement back then, to reuse pieces of logic. Wonderful pieces of logic that acted like standard business services. Wow, we were building services? But in reality the overall development environment wasn't up to the task. Think of a six-year-old with the intelligence of an adult and the emotional maturity of, let's say, a six-year-old. You can't really put those smarts to full use.

Well, our six-year-old has grown up quite a lot. The environment has changed and now we have a layer of technology that can effectively orchestrate these services. Let's call this BPM. We now have wonderful standard interfaces that let us deploy these services so they can be used across heterogeneous orchestrated flows - Web Services became the answer. All is well.

Well, not exactly. We still have a long way to go. And I'd like to touch on a few topics of what we still need to do. These are things you should consider in your own service-based architecture. I'll briefly illustrate due to allotted space what needs to be considered.

Explicit and Discoverable Service Contracts
This one has lots of tentacles. First, how do you make a service that other applications or application developers can discover that lets them effectively reuse the service? Seems simple right? Just implement a service registry. But it isn't simple, so you need to consider this topic. There is a tremendous amount of complexity in making a service usable by someone who doesn't understand the inner workings of the service. It's not just the syntax of the interface to the service; it's the semantics. There's work going on in this area; but for services to be truly decoupled and leveraged, developers have to be able to find a service that exists that truly meets their needs. Otherwise, we'll again have multiple groups in a company, basically replicating the same code but this time in a service wrapper.

Atomic Services
In my opinion, this is the hallmark of a well-designed service. No, you can't wrap your entire legacy application with a Web Service and say you're done. Services are supposed to have a purpose that is unique. In an insurance company a service that processes a completely new life insurance policy isn't atomic. It's a process. The activities in the process have to be broken apart. Unique services should be constructed for each component part of this process. Like a service to determine the risk of an applicant (Risk Score), and the value of the applicant to the insurance company (Customer Value Score), and the cost of the policy based on the applicant's risk and value (Policy Cost); now each of these services is most likely atomic.

Why should you care? Because atomic services have attributes that are critical to a well-designed SOA. First, they can most likely be reused without negative effect. This service, that determines the applicant's value to the insurance company (e.g., Customer Value Score), can be reused in making marketing offers, or in real-time call routing applications. Do you really want that code coupled with Policy Cost code? Second is the topic of agility. When made atomic, we have the greatest chance that the specific business organization that owns the service, the organization that determines Customer Value Score in this case, can independently maintain and change the service as needed. These changes can be made without breaking other pieces of the application, injecting agility to the process. If our service isn't atomic and deals with all of these underwriting functions (risk score, customer value score, and policy cost) then we'll feel required to test each of these functions when we change our customer value score function, since we all know that when you change any code, there are unexpected consequences.

Services with a Point
Freud once said that sometimes a service is just a service. Actually that's the problem. Not all services are the same. We should know what kind of service it is. Is it a data service designed to get data needed for the application? Or is it a decision service designed to provide an answer such as Customer Value Score?

Generally the industry hasn't provided a clear definition of the kind of services that should exist. Don't wait for the industry to solve this one for you. Your organization should do this. This would make it easier for the business to think about what happens in its business process and for developers to build services that are explicit and atomic. Consequently it will be easier for consumers of services to understand exactly what the service does.

I could write a paper on this well-defined set of services, but for grins I'll pick on one. Decision Services are near and dear to my heart (that's what my company does). I saw a wonderful quote that said decisions should be the first-class citizen in all of application development. Other than data, which is the history and reality of an organization, what we do as companies is make decisions (which transforms data):

• We review incoming applications to determine if they're correct
• We approve these applications
• We allocate machinery to manufacture product against forecast
• We determine how to ship and store this product for optimal cost against our demand chain

All of these action items are decisions. Other questions to consider are: Has your organization identified decisions as a kind of service? Or routing of work as an explicit service? Does your organization have a clear definition for the types of services you are building? Is each critical decision that exists in your application environment identified as a unique decision service? By defining service types, it becomes much easier to identify services and service boundaries when building a service-oriented application.

So where is this all leading? To get the value out of SOA, we have to continue to invest in clearly defining the architecture and components of the architecture. Building a house without plans usually ends with a pretty messed-up house. For SOA to thrive, we have to be clear about the definition of our services, their interfaces, and how to simplify so that we can reuse them.

In SOA reuse and agility are key. But the combination of all of these new atomic services creates new complexity. The complexity should be dealt with in the definition of the architecture so that we can have simplicity in execution and use. To march down this road effectively and get the value we're seeking, we need to ensure that are services are atomic so that they can evolve independently. We need to make sure they have a purpose that's clear so that the consuming users know what the service does. And we need to make sure that the service interface is explicit and simple so that when the service changes we don't have a negative cascading effect on all of the applications that have come to depend on the service. If we don't deal with this subject, we're doomed to see articles about new architectures (What Next After SOA) because this one (SOA) has failed. To make SOA successful, we need to continue to invest in refining what's next in defining and implementing an effective service-oriented architecture.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...