Business Process Analysis with SOA: A Case Study

Process Service Matrix

Originally conceived by Pulier and Taylor [REF-1] as a Service Map, this concept has been extended into a Process Service Matrix that shows the use of high level services by different business processes. In order to arrive at a set of core services that address the business goals related to each business process, the identified services within Table 2 are grouped into the most appropriate contexts under which these services operate. The resultant matrix is depicted in Figure 1 that provides a simplified high level view of COC's emerging SOA. Each business goal has been grouped under the actual business process which helps to visualize the services' relationship with each business process while keeping the business goals in perspective. Contrary to goal service analysis where the focus is on the goal-service relationship, process service matrix focuses on the process-service relationship in order to get an architectural overview of SOA.

Figure 1: Process Service Matrix (Circular rectangles represent the services used by the processes on the right side. Colored lines are used only to depict the services used by a particular process and to make navigation through the diagram easier.)


Value Chain Analysis

The process service matrix (Figure 1) provides a preliminary set of services for starting an SOA initiative. However, it is necessary to focus on specific business processes whose automation would address the most pressing needs of COC so that the SOA initiative is a targeted development bearing one to one correspondence with the actual goals that it needs to address. By taking on these business processes in terms of their value to the organization, the ROI from the first set of developed services is maximum, fulfilling the most important business requirements of the organization. In order to establish such a process, SOA Drivers are identified that are derived from the current business as well IT challenges [REF-3]. These drivers provide the underlying cause for undertaking an SOA initiative, in other words why to opt for an SOA instead of a traditional development as far as COC's IT systems are concerned. Once identified, these drivers are prioritized against the business processes for identifying those processes that deliver maximum return value, resulting in a value chain matrix as depicted in Table 3. The outcome of this analysis identifies Contract Acquisition process with a potential to address most of the SOA drivers. Consequently the analysis phase focuses on this particular business process.

The outcome of BPA presents the business analysts and the architects with a list of artifacts that forms the basis for upcoming service-oriented analysis. By already having a list of high level services along with their logical operations as well as the prioritized business processes with respect to the business goals, analysts could be sure of the fact that they are heading in the right direction and not wasting time in the pursuit of an SOA that either might not be required after all or although addresses the business requirements eventually but not soon enough thereby losing the agility touch which forms the basis of SOA.

Conclusion

In order to reduce the complexity associated with the SOA development, BPA remains a key element of the SOA development lifecycle. Incorporation of BPA within the development lifecycle provides a high level view of potential SOA and a set of matrices both of which lay the foundation of the required SOA and steer the SOA in the right direction right from start.

BPA helps deciding whether it is worthwhile to adopt SOA development style or to stick to the traditional application development by observing the cardinality of a service within process service matrix i.e. if functionality is ever to be used by one single process then it would be more efficient not to expose such functionality as a service. It is a great tool in securing IT budget for an SOA project by orchestrating the reusability element of SOA and the relevance of services to the business goals, something that the management is more concerned with. At the same time by prioritizing the business processes in terms of their relevance to the business goals, business analysts and architects are both clear on the SOA line of action and the order of goal-fulfillment as the SOA initiative progresses.

However, it is important to keep in mind that as the business goals are always in flux so a periodic update of matrices involved within BPA stands quite necessary whenever there is a change in business goals in order to guarantee that the SOA is always aligned to its business requirements and that the developed services always carry maximum reusability.

References

[REF-1] "Understanding Enterprise SOA", Pulier, E. et al, Manning Publications Co, 2005.
[REF-2] "Service-oriented modeling and architecture" by Ali Arsanjani, IBM.
[REF-3] "Service-oriented Architecture: A Planning and Implementation Guide for Business and technology", Marks, E. A. et al, John Wiley & Sons, Inc, 2006.

 This article was originally published in The SOA Magazine (www.soamag.com), a publication officially associated with "The Prentice Hall Service-Oriented Computing Series from Thomas Erl" (www.soabooks.com). Copyright ©SOA Systems Inc. (www.soasystems.com)