Service Oriented Architecture (SOA) has gained an increasing amount of attention among technology executives, especially when it comes to squeezing extra life out of legacy systems or technology investments. While SOA can be a technology enabler, too many times its implementation does not realize the full benefits within business operations. Why? Because it is viewed as a technology tool instead of an enabler of a world-class customer-centric organization.
It is common for many organizations to bypass holistic business systems design and use SOA as purely an integration platform. In fact, poor processes remain poor processes, but the cost of the process has increased because the total cost of ownership for the tool is more expensive.
Imagine starting down a road with many forks and twists and no map to efficiently lead you to your destination. You may end up where you wanted to through trial and error or luck, but your odds would be considerably better if your route was mapped out in advance.
The relationship between business process design and SOA is very much like that. The IT environment is typically complex. SOA provides the underlying structure supporting integration between services. It defines how two entities, such as programs, interact in such a way as to enable one entity to perform a unit of work on behalf of another entity. SOA provides the context that allows enterprise capabilities to be composed together into business processes across application and organizational boundaries.
A client I worked with is, I believe, a good example of this concept. The company grew through multiple acquisitions within a short period of time. Each business unit had its own legacy application and its own set of business processes around the system. These disjointed systems did not share operational data with the exception of back end financials.
Before embarking on an SOA initiative, we identified several critical problems. A primary one was the need to find a way to more quickly link acquired companies to provide information such as customer data or a consolidated view of the financials. There was also a need to create a repeatable process to integrate operations, including applications, for future acquisitions. Each time, the company built a business case for the acquisition based on assumptions it made about the time needed to integrate the operations. If this took longer than expected, which often happened because there were no standardized and repeatable processes, the payback period to realize the acquisition ROI was longer than the business case called for. By implementing an SOA, executives thought that they would create efficiencies that would, in turn, lower the cost of each integration and give the company a more realistic view of the cost to integrate an acquisition.
In helping this company, we started with its current processes by identifying process inefficiencies and mapping out the future designs. Once the processes were mapped out, we designed the SOA initiative to streamline the processes and seamlessly integrate legacy applications. The end result was that the company was able to more quickly adapt the SOA to link acquired companies. This allowed the parent company to receive consolidated financials and establish more consistent metrics from a Balanced Scorecard perspective. In addition, because it had redesigned the overriding process, the company could it again with future acquisitions. This meant that the parent company could quickly manage acquired companies the way it wanted to from the start.
An SOA implementation can have positive business benefits for customer care. For example, by better integrating processes with an SOA architecture, a customer service representative can go from using three applications to retrieve various levels of customer data to being able to find everything through one interface. Customers can get better access to their historical data (orders) and get their customer requests (orders and inquiries) resolved more quickly and efficiently.
How can IT incorporate BPM into the next SOA initiative to increase the chances that the organization reaches its figurative “destination”? Asking some key questions will help you set expectations and provide a backdrop for IT’s initial analysis of the processes connected to the initiative. Questions to ask your business-side sponsor or executive advocate include:
- What was the driver for SOA?
- How do you expect the tool to be used?
- What processes or customer interactions will this impact?
The IT side should have these conversations with the business side when the processes, themselves, are going to change. Another conversation that should occur is between IT and the end user or someone on the front lines of the process.
These conversations should provide IT with an understanding of the pain, the scope and the end goal. Particularly when it comes to knowing what processes will be impacted, IT can zero-in on a starting place from a process analysis and improvement standpoint. This will save time and help IT to identify the key stakeholders for the change.
Get your processes in place first, then configure the tools to meet the need based on your understanding of the needs of the processes. BPM should be considered an automatic part of any SOA initiative. By optimizing your processes first, then creating the technology interfaces to support these processes, you will ensure that the business side of the organization benefits from a well-thought-out execution strategy. Open communication with the business side and the engagement of a business-side sponsor will further improve the chances that the path IT is going down with the SOA initiative will not take your organization to a dead end.