2: Business Process Management and SOA
Business Process Management is a key driver of SOA, as BPM deals with designing the processes, and SOA provides an infrastructure for supporting those processes.
(EN: In this chapter, the author seems to depart from the topic of SOA and discusses business analysis, with scant reference of how it is relevant to SOA. While the two are related, there are better sources to consult on this topic.)
WHAT IS A BUSINESS PROCESS?
A "process" is a sequence of tasks and events that achieve a goal for the business. Processes apply not only to information systems, but to tasks performed by personnel within an organization in order to get something done (e.g., the things that must be done to get a box from the factory to the retail shelves)
Generally, a process includes
- Trigger events - which start the process in motion
- Inputs - Information or actions that must be provided for the process to succeed
- Tasks - Actions that must be taken as part of the process
- Sequence - The order in which tasks must occur
- Outputs - The final goal achieved by the process
- Exceptions - How the process reacts to unusual situations
BECOMING PROCESS ORIENTED
New businesses or new operations within an established business tend to proceed without well defined business processes, as they are in an entrepreneurial/discovery mode and the process are not well established or understood. It may be counterproductive to impose a formal process during an evolutionary stage. However, patterns should emerge over time, which develop into a repeatable process, at which time it should be formalized - the alternative is a constant seat-of-the-pants management with no consistency or stability.
The transition from a freewheeling and chaotic culture to a more orchestrated operation is a significant cultural change, and making this change is prerequisite to defining process (specifically, no point in defining processes or procedures if no-one will heed them).
The author describes a five-stage model of "maturity" of business processes:
- Level 0 - There is no regularity to business activities at all
- Level 1 - Regularity exists in the activities of the workers, and there is some consistency, but there is no recognition of a process
- Level 2 - The process is recognized and possibly document, such that there is now the notion of "proper way" to do a given task
- Level 3 - The process is standardized - i.e., others within the organization who perform the same task are required to follow the same procedure.
- Level 4 - The process is quantitatively managed: data is gathered to monitor the performance of the process.
- Level 5 - The process is optimized, generally with an eye toward improving its efficiency as indicated by quantitative measurements.
(EN: I object to the use of "maturity" as it has the implication that all processes should be fully matured. Not every process should be taken to "level five." In some instances, standards are misapplied where they do not make sense or provide value, the factors that are quantifiable aren't necessarily the most important, management to the numbers is often a very bad practice, and a great deal of expense and effort is wasted in monitoring and management aspects of tasks that simply do not matter.)
BUSINESS PROCESS AND SOA
From the IT perspective, business processes are necessary for developing systems and services, as systems design depends on definition and predictability to tasks in order to develop solutions. It's worth noting that most business have remained largely unchanged, but the technology to facilitate them has evolved considerably in recent years.
While integrating their legacy systems with the Internet, many organizations noticed benefits to the workflow in making the capabilities of black-box systems accessible to outside processes. To accommodate new media, systems architects were compelled to consider tasks and workflow rather than the capabilities of a system, and recognized the redundancy and inefficiency of back-end systems.
The "middleware" they developed during this era was a primitive form of SOA, and resulted in more efficient and effective information systems, but it also changed the fundamental perspective of IT toward a more service-oriented mindset, and helped better align and integrate the IT department with the rest of the business.
BECOMING SERVICE ORIENTED
The prevailing mindset in most successful businesses is already service-oriented: the goal of serving the customer leads to the definition of tasks that are organized into processes, with supporting tasks (such as payroll) centralized rather than duplicated in each department.
A problem in IT management has been focus on systems rather than user needs - or when service was considered, each business unit was treated as an isolated customer, for whom IT developed a self-contained system that failed to consider redundancies or synergies with other parts of the same organization.
The SOA approach seeks to understand information systems as they support the organization as a whole, seeking to assist business units in providing tools that model their role in the environment of the business, and orchestrating these capabilities as a whole.
A side note: automating a process does not always improve performance of that individual process, even if the system is well designed. In some instances, it is necessary to implement a service that is inefficient to fulfill the needs of the processes it supports - such that the inefficiency of one process creates greater efficiencies in others to achieve an overall positive effect.
A bit of disambiguation: in the computing world, "object oriented" refers to a programming method - defining sets of data as "objects" that have "properties" and "methods." Becoming service-oriented does not mean abandoning object oriented programming techniques.
BUSINESS PROCESS MODELING
Business process modeling is a practice of creating a mathematical model of a procedure in order to compare the efficiency of current processes to proposed future processes.
It begins with defining the current (as-is) process and diagramming it in a flowchart that shows the activities, actors, flow control (conditional logic), and error handling. Following that, the analysis investigates the resources and time necessary to perform each task in the process and develops a simulation that, when run, results in an outcome that is close to "reality"
After that, the analyst defines a future (to-be) process and subjects it to the same tasks: diagram, resource allocation, and testing. However, in this instance, "testing" proceeds resource allocation, as the time necessary to perform a task is not known and must be estimated (by comparison to current tasks, testing a prototype, or running a field test).
The two process models are then run on the same data set to determine the difference between them, as a method for assessing whether the proposed "to be" state is worth pursuing.
(EN: This all seems clean and mathematical, but I have some misgivings. It emphasizes efficiency over effectiveness, efficiency of process over the efficiency of organization, ignores the opportunity cost of resources, and is comparing an model based on actual observed data to another based on hypothetical data.)
ESTABLISH THE BUSINESS PROCESS
Establishing a business process requires software development, employee training, and many other tasks - none of which has anything to do with SOA. However, when those tasks are being planned, attention should be paid to the services that are currently in place (to avoid duplication and redundancy) as to ensure that any new systems development is done in a service-oriented manner, such that other processes can leverage the services created for the present one.
There is also a division of authority: which the business analysts are responsible for determining their process, it should be left to information technology to define the tasks that it will do to provide the data and capabilities that the business architecture requires. Business Process Exception language (BPEL) is a diagramming technique used to communicate in this middle ground.
Fundamentally, the tasks in a business process can be characterized by three main components: the tasks that the service can perform, the people or systems affected, and its location within the business. This enables the analysts to function specifically on the function, separating it from the person/department who performs it or "owns" it (which can be politically charged topics).
It's also worth noting (again) that the business process covers all functions performed by all actors, so it will include not only system tasks, but also tasks performed by humans.
MONITOR AND CONTROL THE PROCESS
In any process, there is the potential for things to go astray - whether through operator error, corrupt data, system malfunction, etc. For that reason, it's important to constantly monitor processes, providing reports that indicate performance levels and instant alerts when an individual error occurs that merits immediate attention.
Monitoring mechanisms merely detect problems, but do not automatically deal with them. The latter is a more complicated task, as if an error can be handled programmatically, it should never have occurred. Human interaction is generally necessary to correct a mistake immediately and where a given kind of error becomes common, to troubleshoot and implement preventative measures.
The key performance indicators (KIP) are metrics that relate to the most mission-critical services, the malfunction of which will be damaging to the organization, in terms of having a financial impact (increasing costs or decreasing revenues) or harming relationships with customers, suppliers, and employees. KPI should be isolated or highlighted from less important data.
IMPROVE OR ALTER THE BUSINESS PROCESS
Business process management is not merely a maintenance task, but focuses on the continuous improvement of operational efficiency as well as reacting to environmental changes. SOA supports improvement by facilitating service reuse and providing service abstraction.
"Service Reuse" pertains to creating a single service that is used by many processes, thereby enabling the company to avoid redundant operations. Any improvement to a shared service theoretically improves all processes that include it.
"Service Abstraction" pertains to divorcing a business function from the means that are used to accomplish it, such that a service can easily be replaced by another that has the same inputs, outputs, and functions .