SOA is an acronym for Service Oriented Architecture. SOA is an approach to building software in a way that allows components to be reused across a large organization. So what does this have to do with process modeling? Process modeling involves analyzing all the various participants of a process such as people, systems, and other processes. Often a process modeler will overlook the fact that systems are involved in a process.

For example, an employee submits information to be reviewed by his manager. But how does this happen? Does he physically hand a paper document to the manager? If it’s any type of electronic document, there is a system involved, which should be considered a participant of the process. All participants must be considered in the diagram. Otherwise, pockets of inefficiency exist in your process model, and major details might be completely overlooked when it comes time to re-engineer the process. However, we don’t want to spend time documenting the inner workings of system activities. This responsibility falls on the IT Information Technology) development team that created the system. Documenting the internal processes of system activities should be done when a system is created. Therefore, documentation should already exist. As a process modeler, you should focus with how to use this system as a service to the process.

Systems built with the SOA approach are said to be consumable, meaning they are readily available to be used in an automation system. Typically a BPMS is used (business process management system), but it could be any number of other applications that also consume services. Before SOA became popular (around 2005) IT engineers had to write software code called middleware that binds one system to another. The problem with middleware is that it often became a roadblock to progress, because before updating the system on either end, the middleware must also be updated.

Some examples of SOA might include CrUD operations (Create, update, and delete of data), login/authentication services, calculators for common functions such as interest rates or insurance premiums, and common data retrieval such as stock quotes, the weather, etc. Since all of these examples can be generic in nature, a service is created to support a wide range of activity. For example, if I want to get the weather, the service is not tied to any specific location. Instead I must provide the location to the service, and it returns the requested information. An so, often the context of the service activity is left open ended, which allows a service to be created once and used often in many other systems.

In a SOA system, certain parts and pieces are offered as a service to the entire organization. The role of the IT engineer shifts slightly to where their primary responsibility is to create services, and reuse existing assets before purchasing or building new ones. If a service is needed that doesn’t already exist, the first step is to determine if the organization already has a system that performs a similar function. If so, then there are ways to expose an operation (activity) as a service with minimal impact to the surrounding IT environment.

Going back to the process model, I want to send information from an employee to a manager for review. What is actually happening is that the employee is submitting information electronically to a service. The service then determines how to route the information. The service might also perform a query to determine who the submitter’s manager is. If I am modeling this process I might want to stick to the idea of the data submission and what to do with the data when a reply is received from the manager. But the data service should still be part of my diagram.

It is often the case that the data service required by a process model does not exist yet. The process modeler can easily define what is needed for a system to perform the desired activities, such as look up the manager and forward the request. Some of the parts and pieces of this process might already exist. For example, the lookup manager activity might be available as part of the security system. However, we don’t want to build a direct integration into the security system. We just want to leverage some of it’s basic functionality. We don’t want an entirely new system either, because this will likely result in duplication of data that already exists somewhere else.

Figure 1: A system pool shows the requirements for a lookup manager service and a routing service
Figure 1 is a simple BPMN diagram showing the need for a request router service. When the IT engineering team sees this diagram, they should immediately spot the need for two services. 1) The request router. 2) the lookup manager service. The lookup manager service would probably be not be directly used by the process. Instead, we would use the lookup manager service as part of the request router. The request router would most likely be created as a generic service that could also handle the manager response. Since the submitter is already known, we don’t need to query for him. The request router service would simply forward back to the submitter.

The process model in figure 1 is very simple, but might be very valuable. After further developing this diagram with good text annotation, data artifacts, and good labels, we can replace an equivalent requirements document that might have been 10 – 20 pages in length. Provided that your IT organization understands BPMN, it’s very easy to determine system use cases from this diagram. Each scenario we model might create another use case. For example, as part of the first scenario of submitting to the manager we created the diagram in figure 1. When we add the manager’s reply to the service requirements, the diagram might look like figure 2.

Figure 2: Diagram refactored to include the reply from manager

From an IT perspective, the service is created to route messages in a generic way. If I have an address I send it directly to the person. Otherwise, I have to determine the person to route the request to. The service could be created with operations such as “Send to person jdoe@mycompany” and “Send to my manager”. In the process we automatically know now to send something to anyone’s manager by consuming this service.

This approach to managing processes and services is very efficient for both the business analyst that models the processes and the IT engineer/architect that creates and maintains the services. In fact, the role of both IT and BA becomes much easier, and better, more accurate requirements documents result. This method promotes collaboration between IT and BA staff rather than putting up walls of responsibility. The IT staff is more efficient because instead of creating a huge, monolithic application that takes years to implement, they are only creating one more service that is compatible with their infrastructure. On the business analyst (BA) side, you don’t have to spend weeks or months negotiating with the IT staff on what can and cannot be delivered in time. Much of the functionality might already exist, and what needs created is very small in scope so it shouldn’t take as long as the traditional software development approach.

In summary, SOA and BPM need each other. BPMN is the language that bridges the gap between the business process world and the IT world. IT creates services that have high-level documentation in BPMN that is easily readable by business people. Business analysts create diagrams in BPMN that are easy for IT to interpret into technical requirements.