> Archive > Issue XXIII: October/November 2008 > Business Process Analysis with SOA: A Case Study
Wajid Khattak

Wajid Khattak


Wajid Khattak is a software developer at Keynetix. In his current role he is responsible for the development of GIS solutions (including HAGDMS) used by the Highways Agency UK.

Prior to this in his two year tenure at Pinewood Computers (UK), he was engaged in the development and maintenance of dealer management system (Pinnacle)mainly using .NET based technologies.

In 2003, Wajid completed his BSc (Hons) degree in Software Engineering from Birmingham City University. Feeling the urge to increase his skill set and to gain advanced knowledge of issues within software development, he left his job in order to pursue a Masters degree.

Consequently, he completed his MSc in Software Engineering and Security from Birmingham City University in 2007. It was during this degree that he acquainted himself with SOA and wrote a thesis on "A Methodology for Enterprise Application Development".


rss  subscribe to this author


Business Process Analysis with SOA: A Case Study

Published: November 17, 2008 • SOA Magazine Issue XXIII

Abstract: The success of any IT initiative could be measured in terms of the actual business goals that it fulfills. However, when it comes to SOA based projects, it becomes imperative that such an initiative bears close correspondence with the business requirements as SOA is usually an enterprise wide activity, so any slight deviation from the actual business goals could result in an SOA that is misaligned with the enterprise wide goals. So in order to achieve this required alignment, it stands necessary that before starting off with the service-oriented analysis phase, a high level view of required SOA needs to be in place that ensures that the subsequent analysis phase concentrates on business processes in the order of their preference with respect to the business goals linked with each business process. Business Process Analysis (BPA) offers matrices that help in drawing a correspondence between business goals and high level services. BPA also helps in prioritizing the business processes in terms of the most pressing needs of an organization. This article presents the rationale for BPA, its importance and more importantly it describes the actual steps involved within BPA with the help of a case study.


The importance of BPA within traditional application development accounts for a successful end product that is more aligned with the business requirements. However, within an SOA, being inherently an enterprise wide initiative, the requirement for conducting BPA becomes more prominent and warrants an individual development activity on its own unlike a traditional SDLC where it is more embedded within the analysis phase. The basic tenet of SOA is to align IT with the business processes; consequently BPA's rationale is to align SOA with the true business needs so that the services created at the end of the SOA development process fulfill the actual business requirements.

BPA helps focusing SOA initiative on the set of business processes whose automation would address the most pressing requirements of an organization. It helps in drawing a one to one correspondence between the business goals and the required services. Without a BPA, there is a strong possibility of SOA's development efforts to be focusing on issues that although need addressing but are not an organization's priority, thereby not bearing the required results. Unlike traditional software development, where analysis could be performed by following an established set of techniques (e.g. use-case analysis, data flow diagrams, ERDs), SOA requires a discrete set of business analysis activities that establish the baseline for the actual service-oriented analysis & design.

Organizations are always faced with the classic dilemma of scarce development resources in order to address ever growing list of business requirements. Consequently for an SOA, that already faces opposition from the traditional software development hardliners, these scarce resources need to be focused towards addressing the actual business requirements starting with the most important ones. This focused development is only possible when one can justify the required services by drawing a one to one correspondence between the business processes and a set of high level services. BPA helps to draw this correspondence and thereby guides the SOA development efforts towards the creation of services that actually address the business requirements.

One of the misconceptions about SOA includes the presumption that the SOA follows the big-bang theory as a result of which architects try to service-orient every other process without prioritizing them according to the needs of the business requirements. Those that have followed this route already know the consequences when it comes to reviewing the fulfillment of business requirements from the first set of developed services. However, all this could easily be avoided by performing a Value Chain Analysis that prioritizes the business processes in terms of their importance to the business. Although the techniques presented here do not constitute a complete set of steps involved within business process analysis by any means, however, these do help in providing a basis for such an analysis. These techniques have been described by using a case-study as an example as it helps to draw a better understanding of the actual process.

Case Study: Carry On Calling

Carry On Calling (COC) is a UK based company that provides post-paid mobile connections with subsidized line rent. It acts on behalf of major mobile phone network providers and works on a commission basis. It subsidizes the line rent by giving cash-back to its customers. Customers can get a connection directly from the network providers, however, what makes COC's deals appealing is the fact that not only does it provide subsidized connections but also provides free handsets to its customers. Although it started off as a small company, because of its low cost deals, its customer base is growing exponentially resulting in quick expansion of the company. This quick expansion means increased profits but at the same time it brings along a plethora of problems which are hindering company's productivity as well as its targeted growth.

What COC offers to its customers is a post-paid phone contract including free cross-network minutes. COC combines the contract with a specific handset and presents it to prospective customers in the form of a deal. Various deals are available to its customers having different combination of free minutes and handsets.

The net profit earned by COC is calculated by deducting handset's price, which COC purchases from various handset suppliers, from the commission earned. Although the commission provided by the network providers seldom change, it is the price of handsets that changes quite frequently mainly owing to the introduction of new handsets every other month. Other companies are joining the same line of business that get the same percentage of commission from the network providers. So to remain profitable, this puts the entire burden on finding the cheapest handset and then combining it with the most favorable contract in order to make the deal an attractive offer. This requires real time information regarding the commission offered and the price of handsets.

Current State of Affairs

The company's main business processes are as follows:

Contract Acquisition Process

A prospective customer gets information about current deals over the telephone or in person. If interested the customer fills in a form that includes name, address details of the past three years, the chosen package and the bank details. If the customer has contacted via telephone, then he is informed by the sales agent that he would be contacted back shortly, however, if in person the customer is asked to wait. The sales agent validates the form and if all the details are correct, the details are forwarded to the relevant network provider (depending upon the chosen package) over the telephone by the agent. While the agent waits over the telephone, the network provider processes the application and informs the agent of the outcome. The outcome could be (a) accepted or (b) rejected. The prospective customer is informed of the decision. If accepted, customer account is created in a client-server based sales application, a handset is allocated, then the customer signs the contract (form) and is given (sent in case of telephone enquiry) the handset, contract details are sent to the relevant network provider and the details from the form are entered in the sales application. In case of (b), the prospective customer is simply informed of the decision. In both cases, the form gets filed at the end.

Where the application is made over the phone, in case the application is successful, the contract is sent to the customer by post for his signature and is filed once received back. In case of a successful application, a request is sent to the accounts department to open customer's account in the accounts module of the Enterprise Resource Planning (ERP) system.

Cash-Back Process

Each month, upon receiving the telephone bill from the network provider, the customer sends a photocopy of the bill to COC. When received by COC, this gets recorded against the customer account in the accounts module of the ERP system for that particular month. COC takes two weeks to send the cash-back to the customer through bank transfer. On the other hand, the network provider deducts the billed amount through direct debit each month.

Commission Claim Process

An invoice, consisting of the owed commission, is first created within the sales module of the ERP system for the past fourteen days and then sent twice a month to the network providers via email. This gets reconciled by the network provider and if there are no discrepancies between the invoiced amount and the network provider's records, the invoiced amount is credited to COC through bank transfer. However, in case of discrepancies, there is an exchange of emails between COC and the network provider until the matter gets resolved.

Stock Management

Each month a price list is sent by different handset suppliers to COC. These price lists and the current deals get reviewed manually by the manager. A profit analysis, including different combinations of deals and handsets, provide basis for ordering different handsets. A purchase order (PO) is created within the ERP system and is sent to the supplier via email. The supplier sends an advanced shipping notice (ASN) stating the estimated delivery date . Once received, the delivery note is filed and the stock is manually updated within the stock management system (ERP). The stock is followed by an invoice from the supplier. The invoice is paid subsequently by COC, relevant journal postings are made and the supplier's account is updated within the accounts module of the ERP system. In case the supplier cannot fulfill the order, same PO is sent to a different supplier and the whole process is repeated.

Deals Management

Network providers send details of their packages. These packages include details such as free minutes, free sms, contract length, validity of the package, line rent, commission and the length of the contract. The manager reviews these packages along with the price of handsets from the price lists. New deals are created or existing ones are updated after performing a profitability analysis. Once created/updated, the sales agents are informed of these deals. Currently the deals are managed using hard copies of packages and price lists.

Business Issues

In the near future, network providers would cease to support manual processing for:

  • Contract Acquisition
  • Claiming Commission

The new automated processes need to incorporate electronic exchange of XML documents (contracts and invoices) based on schemas specified by the network providers.

New regulations have been imposed by the network providers. This requires keeping track of customers' history so that:

  • A declined customer should not be able to re-apply within 3 months.
  • A customer already having a contract is unable to apply for another one.

No real time information about the price lists from various handset suppliers is available at the moment. As a result of this, new deals are created without knowing if the current price list is the latest one or not, which can decrease profit margins if the same handset is available cheaply from another supplier. A contributing factor to this inefficiency is that fact that currently the import of price lists is done through a slow and error-prone manual keying-in process into the ERP system.

The stock ordering process is inefficient and cumbersome. Current manual process involves looking at existing stock levels and the commission offered on different contracts (which requires accessing two systems at the same time), from this the best package is worked out and a PO is sent via email to the supplier offering the cheapest price (price lists are viewed using the ERP in order to find the cheapest supplier). Once the stock is ordered, the ordered quantity has to be manually updated in the inventory control system within the ERP system.

Creation of new attractive and cheaper packages is a time consuming task as no real time information is available regarding the commission offered on different types of contracts and the prices of handsets from various suppliers. Contrary to this, competitors have employed automated systems (that present all the required information as a single view) because of which they can come up with cheaper deals in less time, thereby gaining competitive edge.

Allocation of handset is cumbersome. During the final stage of contract processing, once an application is successful, the simple process of allocating a handset requires logging into the ERP system, checking the stock level and then posting a journal transaction in order to decrease the stock quantity and to keep the accounts balanced. All of this overhead not only contributes towards the inefficiency of the contract acquisition process but also stands in the way of fully automating the process.

Business Goals

  • To achieve compliance with network provider's new regulations that includes performing different customer checks as well as enabling electronic exchange of documents. This entails not only automating the contract acquisition process but also the commission claim process.
  • To reduce application processing times by fully automating contract acquisition process. This would not only achieve conformance to business partners' requirements but at the same time would help in increasing customer base in less time.
  • To increase revenue by providing online application processing for contract acquisition. This would also help in keeping the number of application processing agents to a minimum.
  • To have end-to-end business visibility by having real time information about current commissions offered, the cost price of handsets from various suppliers, number of successful applications each day, pending invoices and pending stock replenishment requests.
  • To have real time information about stock levels so that only optimum stock levels of handsets are maintained at any point of time, thereby decreasing spending on unwanted stock. This also helps towards making the contract acquisition process more efficient as the sales agent would exactly know what the stock levels are before actually allocating the handset.
  • To automate stock ordering process so that no exchange of emails is involved. The whole process from placing an order to receiving an invoice should be as efficient as possible involving no human mediation. Handset suppliers do offer electronic exchange of documents e.g. invoices, one objective of automating the stock ordering process is to make use of this facility as it would make the stock ordering process more efficient and less error prone.
  • To automate price list import process as manual keying-in of price list takes a long time. This would also help increasing the efficiency of creating cheaper deals as up to date prices would be available while the deals are being created or updated.
  • To eliminate paper based cash-back process. The automated process would eliminate the need for the customers to send copies of bills. Instead customer's bank account would automatically get credited once an electronic notification has been received from the network provider that it has deducted the billed amount through direct debit.
  • To increase customer base by contacting customers whose contracts either expired or those who were declined a contract in the first place.
  • To have a consolidated view of business data including network providers' packages, deals, price lists and the stock levels. A consolidated view would help to extract the relevant information within less time.
  • To automate commission claim process. An automated system would not only decrease the time it takes to get payment from network providers but would also release manager from manually creating invoices for each network provider.
  • To make deals management efficient. The manual process of deal management, which requires logging in to two systems at the same time, needs to be replaced with a more efficient process whereby performing a profit analysis is far easier. This is only possible if information about price lists, commissions and current deals is available within a single application.

Goal Service Analysis

The aim of Goal Service Analysis is to create a matrix (Table 1) which maps business goals to the required high level services that are identified from the processing steps involved during the execution of each business. This technique is based on work done by Pulier and Taylor [REF-1] and Arsanjani [REF-2] in the area of business process modeling. By listing the intended users of these services, security requirements and processing needs of these services could also be derived. A service only to be used in-house would usually require less stringent security requirements as compared to the one accessed from outside. This can also help in determining the communication format of the service e.g. in case of using .NET, the in-house services could be built using the binary protocol (net.tcp) instead of using the ws-http protocol in a bid to make service communication more efficient.

Similarly, in terms of processing load, the in-house services could be hosted on a shared server as compared to inter-company services that could be hosted on dedicated servers. It is important to keep into perspective that the processing steps stated against each business goal do not necessarily constitute a complete business process i.e. each business goal might require processing steps borrowed from more than one business process. This implicitly backs up the modular nature of SOA where by the intent is not to build a full fledge system rather the actual building blocks that are reusable among more than one business process.

Table 1

Once preliminary services are identified, the very first step towards developing reusable services is to analyze which business goals could be addressed by these services. Such an analysis indicates possible service reuse across multiple business processes. Table 2 shows the resulting matrix. This matrix provides the business analysts and the architects a chance to preview the resulting SOA and the tangible benefits of SOA development with respect to the business requirements.

Table 2

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.

Figure 1

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.


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.


[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.