Olaf Geyer's picture

I Love SOAThe blog posts form my colleague Sebastian (and here) and the comments to it suggest that this is an interesting topic. There are many right answers to the same question. I will address this topic from an architecture point.

First we need to distinguish between business architecture and application architecture. The business architecture describes the enterprise from a business view linking strategy and goals to the supporting processes and organization. Processes define how the business goals are archived and measured. This will result also in a description of requirements or capabilities required to execute those processes. In theory the business processes do not care how they will be implemented on a technical level.

The application architecture describes the business applications in support of the processes as well as the applications and infrastructure in support of the business applications. Let’s ignore the information architecture for today.

This is where black and white ends and grey starts. How do we describe the execution oriented processes that run on a specific application? And whatyawannacallit?

First we can make a distinction between to types of execution processes – one runs on legacy applications and the other is targeted for software services. The first uses home grown applications, ERP systems and other COTS. Here it is more important to define what feature of the application is used in the processes and what the general process logic is. Design level detail is usually not required. The process is already implemented and also most COTS applications have all this detail build in and it may not be relevant for the processes. There are of course always exceptions. It is not unusual to have the same process running on multiple legacy platforms. There are many ways in ARIS to describe those cases including the Process support map.

Processes that are defined to be implemented on new applications including software services are a little bit more difficult. The requirements need to spell out technical detail that will be relevant for the design of the application; including exception and error handling, data inputs and outputs, roles, security and much more. Where does it belong?

Some say not in the business process and I say rightfully so. Other say but we need it and that’s also true.

The first problem is terminology. Are there processes other than business processes? Of course there are. For the sake of this blog I will concentrate on what we call technical processes. Those processes describe execution level details that spell out how we want the supporting application to behave in regards to the process requirements. They go way beyond what a process owner may know or be interested in defining from his perspective. How do those processes align with the business processes? We support three practical ways to get from a business process to a technical process:

  • Assignment of technical detail in the underlying description of process steps: Using a ‘Function allocation diagram’ in ARIS allows technical detail to be hidden from the overall business process. This is an easy and quick solution that is also used in the Oracle BPA Suite.
  • Parallel definition of a technical process: Once the business process is defined the solution architect (or whatever you call this role) will create one or more variations of the process using a technical sufficient language. This provides for: the business and technical process can have independent lifecycles, the design notations can be different, alternative design scenarios can be developed and the process could be supported by multiple applications.
  • Assignment of a technical process: This methods uses business processes on a higher level and technical processes on a lower level to describe the implementation detail of a process step. It supports the same advantages as the previous solution.

The different methods can of course be combined. This is an issue if a process uses legacy applications and services at the same time.

The approach that is used in our business-driven SOA solution uses the second methodology. This results in at least three processes on the same hierarchical level: the business process – usually EPC, a technical process – as EPC or BPMN and the execution process – as BPEL.

The take away is that you should distinguish between business process level and execution level detail. Both can be described within their own space but have to relate to each other. That may result in some more work but provides much more design and architecture flexibility. As always you should be guided by the purpose and the value of your design activities.