Business Process: Sweetness & Light or Evil Hellspawn?
Sometimes it seems that everyone in IT is a cynic. ZapThink frequently discusses how through the power of abstraction, loosely coupled interactions, and composition, IT can finally respond to changing business needs in the time that the business requires those changes. The cynics are only too happy to point out that we’ve heard those promises before, and then they ask what’s so different this time?
Our response to the cynics centers on the role of business process within the organization. Business processes have always been an important, if understated, asset of enterprises. The nature and methods that a company runs its business with changes on a daily basis at various different levels in the company — from high-level strategic changes to lower-level implementation details. As a result of these changes, enterprises constantly struggle to make their companies more responsive to business changes by connecting their business requirements to the IT and human capabilities at their disposal.
And there’s the rub — it has traditionally been very difficult to encode changes to business processes in an agile way so that IT systems can understand how to execute them. Yet, business processes and the businesses themselves are inseparable — you can’t have one without the other. One of the keys to the success, or failure, of Service-Oriented Architecture (SOA), therefore, is the ability to map the activities and tasks that a business depends on to the IT capabilities that automate or enable those activities. So, how can we silence the cynics and fulfill the promise of SOA where previous attempts to automate business process failed?
Attempts at Automating Business Processes
Companies think first and foremost about business processes, not the individual tasks, resources, activities, or systems that comprise the enterprise. Organizations dedicate considerable sums of money and resources to developing and enhancing their business processes in a constant quest to deliver the most competitive services and products for the least cost. In fact, enterprises can be thought of as an aggregation of processes and the resources that comprise those processes. Such processes use operations, information, roles, and sequencing of tasks to carry out specific objectives in the enterprise. It is the role of business management, then, to make sure that their organizations perform those processes adequately or to change them to meet new business requirements. As a result, when companies look to effect change in their organization, they look first at the processes that comprise the organization and then to the tasks that support those processes.
High-level business requirements must eventually filter down to actual activities connected to both human-based tasks and IT systems. Yet, when talking with IT and business managers, it is clear that many organizations consider today’s IT infrastructure to be a bottleneck to operational efficiency. It is not that these systems do not work, but rather, that they were not designed with change and flexibility in mind. Furthermore, many organizations create and plan their processes in a form that amount to nothing more than reference documents. However, very few organizations are able or willing to maintain these documents to reflect the day-to-day reality of their operational processes. As a consequence, this valuable process knowledge soon becomes obsolete, and key process knowledge disappears altogether as soon as the expert leaves the building. In essence, process definition lacks the necessary connection to process implementation.
For decades, different technological approaches have solved various different pieces of the business process puzzle. Indeed, there are hundreds of products on the market that enable companies to translate their business processes into tasks that an IT system can implement. Such traditional solutions, alternatively known as Business Process Management (BPM) or workflow tools, often present a flowchart-type visual interface or natural language business rules engine that enable business analysts or their proxies in the IT organization to build a representation of the business process in a step-by-step fashion and then attach individual activities in a process to the company’s operations.
However, this approach to business process development and creation often suffers from the problem that the person who is responsible for creating the representation of the process either doesn’t know all the details of the business process at hand in sufficient depth, is not up-to-date with the current state of how a business process is actually working in the company, and/or doesn’t have knowledge of the whole process from end-to-end. As a result, most business process definition exercises often produce little more than “shelfware” — that is, they end up creating nothing more than writing on paper that represents either the business process as it used to be, or the business process as it’s supposed to be, but never the business process as it actually is or will be.
Given that today’s organizations require IT that is agile and flexible enough to meet ongoing, changing business requirements, how can we possibly implement business processes unless they are actual representations of the business as it’s currently running? Basically, companies need a runtime business process model that reflects the current state of the business — one in which a change to the model will in turn change the way that the business and its systems operate, and vice-versa, where a change to the business will automatically appear in the business process model. This bidirectional, runtime vision of business process should therefore be a key goal of any SOA implementation.
The Contract is the Key
Understanding the best practices for implementing such Service-Oriented processes is essential to any successful SOA initiative. One such practice for solving our long-lived problems with IT-enabling business process is to separate the notion of business logic and process from the underlying code that implements an individual task or step in a process. Moving process from the underlying code into a separate process layer considerably facilitates business agility for a number of significant reasons. First, a change in the process definition does not require a modification of underlying application functionality. People can rapidly amend and redeploy processes as business requirements demand with minimal, if any, programming. Companies won’t have to constantly rip into the technical plumbing each time they want to change or implement new business processes. Second, businesses can easily monitor, audit, and escalate critical business processes, since they have greater visibility into the overall end-to-end process, rather than having the processes hidden by discrete application functionality.
Companies have separated process-control logic from application logic for many years, the cynics reply, so what is different about how SOA approaches this problem? The most important concept in a Service-oriented approach to business process is that processes themselves are composed of Services, and are in turn exposed as Services, allowing for recursive definition and distributed control of business process throughout the organization. The key to this “processes as Services” aspect of SOA is the Service contract.
A Service contract is a document that reflects an agreement between Service consumers and providers as to what each component must provide and under which conditions they will interact. A properly defined Service contract will specify as few requirements on the other party as possible in order to maintain loose coupling, while detailing the necessary terms of their interaction in the form of metadata that describe the Service. Thus, in SOA, a process consists of metadata that govern the interactions between Service consumers and providers. Those metadata might specify a controlled form of process, such as an orchestration that specifies a well-ordered series of steps, or it might specify a looser form of process flow that designates only the preconditions and post-conditions for each Service interaction (often called a choreography). In either case, the metadata only specify the requirements for Service invocation, and not specifically how the underlying software components must control or execute the process.
The ZapThink Take
Today’s dynamic enterprises require technologies, products, and solutions that rely upon agile processes, or more specifically, composite Services, rather than inflexible application functionality and business processes that traditional BPM and workflow tools offer. But that is the current problem, or perhaps opportunity, with regards to SOA. Many such products on the market are stuck in the programmatic, traditional mindset of encoding business process as a pseudo-programming language, and designing tools that are meant mostly to build well-orchestrated, flowcharted, yet inflexible business processes. In many instances, we’ve just taken the horseless carriage approach of adopting our old forms of doing programming and flowcharting to new technologies — Rather than programming in Java or C#, we’re now coding in XML. How can this be helpful in a world where we’re trying to shift the burden of process development to the line-of-business user who has little knowledge, or interested, in coding, regardless of the language?
Instead of falling back to our old patterns of implementing business process as a program, companies should expose business processes as metadata in the Service contract. The movement to SOA challenges cynics — both end-users as well as software vendors — to break their current patterns of thinking. We won’t be able to silence the cynics entirely, however, until we have the right tools to create these metadata, especially in the case of ad hoc, non-orchestrated flows and the appropriate runtime environments that enable runtime changes to business processes represented as metadata.