Orchestration-Driven Development (ODD) represents a direct evolution of Object-Orientation (OO), with the emergence of Service-Oriented Architecture (SOA) and Business Process Management Suites (BPMS) as its catalyst. The philosophy behind ODD is relatively simple: a business application should be a direct translation of the business process it supports. Build your process model first, then derive your application components from this process, re-using existing components where possible. Seems pretty straightforward, right? You would think adoption of such a philosophy would be far more widespread. And perhaps it would be, except for modern software engineering conventions getting in the way.
Figure 1 Orchestration-Driven Development (ODD)
To understand why this paradigm shift is struggling to gain momentum, it is helpful to examine its historical precedent. When Software Engineering shifted from predominantly procedural programming to object-orientation in the 1980s, there were many who resisted the transition. Despite the intuitive notion of modeling software after real-world objects and using these objects together to “simulate” the business system being supported, there were those who had difficulty comprehending this new approach to what they still viewed as transistor manipulation. Despite these initial challenges, object-orientation is now a fundamental requirement of any modern general purpose programming language.
Just as object-orientation sought to decompose monolithic procedural programs into discrete software components that could be re-used throughout an application, so orchestration-driven development seeks to decompose large, unwieldy business processes into flexible service orchestrations that can be adjusted and re-composed on the fly. Over the past several years, Business Process Management Suites (BPMS) have matured to the point where process orchestrations can be aligned directly to the lines of business they support and can move from visual design to execution more easily than ever!
Traditionally, business software design has involved an often cumbersome translation of user requirements into software components that can easily lead to undesired program behaviors and unnecessary rework. In fact, research has shown that the leading causes of software project failure can be linked directly to a misunderstanding or misrepresentation of the business requirements. This is why ODD is focused squarely on the business process from the very beginning. It is fundamentally imperative that IT developers are in synch with the end users of the business system, in order to deliver a system that will meet the business need. With the recent advent of Business Process Model & Notation (BPMN) 2.0, a business-savvy process modeler can design a comprehensive BPMN 2.0 process that can be understood and approved at a high level by the business stakeholders, and then driven directly to implementation using modern BPMS tools.
Orchestration-driven development is also fundamentally based on the principles of SOA in that it relies on the service-enablement of software components that can be composed in a uniform fashion. As a modeled process is refined into a series of service invocations and/or human interaction points, the real value of SOA is realized. Organizations with an existing SOA infrastructure may be able to immediately leverage existing services within the enterprise to perform certain functions within the process. In most modern BPMS packages, mediation components can be used to transform internal data structures into the message formats required by these existing services. Services that do not exist yet can be easily identified from the process model and an interface for invoking them can be designed long before implementation even begins. These interface specifications can then be handed off to a service development team for implementation. Figure 2 illustrates some of the differences between the “Same Old Process” of software development and the ODD approach.
Figure 2 Same Old Process (SOP) vs. Orchestration-Driven Development (ODD)
ODD relies on close interaction between the business and IT teams, in order to reach a common understanding of the system’s goals. Rather than accumulating an often disorganized and sometimes overwhelming mass of functional requirements, the business process is modeled first. By working directly with business stakeholders to refine this model, it essentially becomes the foundation of the system architecture. Technical constraints and infrastructure considerations are still addressed, but jointly with the modeling activities, rather than as a purely IT function performed after-the-fact.
Once a model has been agreed upon, Business and IT architects can begin decomposing the model into its constituent services. If the organization already has a mature SOA in place, some services may already be available within the enterprise and can be directly integrated into the final product. Interfaces are defined for any new services that are required, and one or more service development teams are assigned the responsibility for developing them. The loose coupling inherent to this approach allows service teams to work relatively independently, provided the interface specifications are well-defined ahead of time.
Detractors of the ODD approach will claim that reliance on sophisticated process engines and SOA middleware introduces too much additional overhead. While the introduction of overhead is indeed a concern in some cases today where performance is paramount, as BPMS platforms continue to improve, and computing performance ceases to be a barrier to the efficiency of process-based systems, we are sure to see ODD become a more widely accepted paradigm.
