SOA Implications

By Ed Fenwick
Senior Vice President

Much has been written about the promise of Service-Oriented Architecture (SOA) for system development and integration. Having read a fair amount of the published literature but only having the slightest grasp of what SOA was, I found myself recently at an industry conference where there was a presentation on SOA. I decided to attend as a final hope of gaining true insight.

Two self-confessed “Data Architects” gave the presentation. It was a case study of a large, complex, and successful transformation of a group benefits business model. This was a technology-oriented conference, and I could tell from the audience’s reaction that they really were interested in what these guys had to say. I, on the other hand, sadly found my hope of learning diminishing at the same rate my headache was growing. As I pondered walking out with mission unaccomplished, I heard the following from the podium: “and that is when the business side realized they needed to own the business processes and IT needed to own the technology that delivered the processes”. Finally, something I could understand and appreciate. I asked my fellow attendee next to me, a true techie, what preceded that statement. He said, “I don’t know, I think something about Use Case.”

In search of learning more, I spent the rest of the day stalking the presenters who were kind enough to advance my understanding. Here is what I learned: To develop or integrate systems using a Service-Oriented Architecture approach, you need a concise, complete, and consistent definition of the business processes to be enabled by the technology. As this organization undertook the challenging effort of defining their business processes, they adopted a common format of Use Case. As IT worked closely with their business partners to finalize these Use Cases, they realized the conversation was consistently moving from “we need the system to do X” to “then the process should do X.” What had happened is that through the disciplined effort of defining business processes the business side had a tangible representation that they could better own, communicate, and manage—something they had not had before.

The business Use Case is described in technology-free terminology, which describes the business process that is currently used by its business actors (people or systems external to the business) to achieve their goals (e.g., payment processing, application processing, enrollment, etc.). The business Use Case describes a process that provides value to the business actor, and it describes what the process does.