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.

Technologists believe that SOA can help businesses respond more quickly and cost-effectively to changing market conditions. It probably is also essential to simplifying interconnection to, and usage of, existing IT (legacy) assets. But, if SOA requires Use Case development, it has another major benefit. It can help managers on the business side significantly improve their business processes through better documentation and understanding.

The Robert E. Nolan Company announces the release of a new report containing research and original articles on the topic of service improvement and differentiation.

In the financial services arena, service excellence has proven to be the dominant market differentiator. Strong, sustainable relationships with customers and agents are essential for long-term success. This new report from the Nolan Company provides a diverse, real-world perspective on this complex topic.

Request the Nolan Service Differentiation Report

We welcome the opportunity to meet you in person at this event. Click "Meet Onsite" to send us an email with your contact information. We'll be in touch to arrange a convenient time to meet you at the event.