Last night, I attended a panel organized by Softech and SD-Forum in San Francisco which was tasked to answer the question BPM: fact or fiction? The panel was moderated by Paul Harmon, editor of BPTrends.com. Here are some of the arguments I presented.
The market of BPM is healthy but relatively small considering that BPM is about helping companies better innovate, adapt or optimize. So we might wonder why BPM efforts remain marginal in most companies instead of being the focus of IT.
For quite some years, I have argued that the key to BPM was a business-process centric application model. Let me explain why.
Most IT organizations look like the picture represented Figure 1. This picture represents in X, the business objects of the company (orders, customers, products...), in Y the systems in a given IT department, and in Z the number of attributes of a given business object, in a given system. What this picture shows is that the footprint of any given BO spans multiple systems, often dozens of systems.
Figure 1. A typical data model in a modern IT organization
The consequence of this picture is that it is difficult to extend and compose existing functionality when you need to innovate, adapt or optimize something in your organization. As a matter of fact, it is often more cost effective to build entire new systems and integrating them with the existing ones, rather than reusing functionality already present in your IT organization. The annoying point is that the bigger this picture is, the bigger it will get.
ESA is about regaining control of this picture.
How? well, let's first look at the state-of-the art application construction (Figure 2.) as it is portrayed by so many leaders of the software community. This figure shows a complete misalignment between the way we specify requirements, the best practice architecture, the concepts and abstraction we use to write code and the technologies we use to finally implement software that matches these requirements.
Figure 2. State of the art application construction
Considering figure 2, who would believe that 1) any code written has any success of matching the requirements? 2) that any code produced can be reused an composed when requirement changes or new systems need to be build? Yet, this is the way some vendors recommend building your applications.
ESA is about providing a modern model-driven service oriented architecture where all these aspects of software constructions are aligned. ESA integrates the fact that Figure 1. is inevitable, ESA aims at making it manageable such that you can innovate, adapt and optimize at a reasonable cost, with a reasonable response time.
How does ESA achieve this? At the core is the concept of Enterprise Services. What is an Enterprise Service? this is a service that represent a logically normalized view of the data model AND the business logic (Figure 3). The Order Service exposes enterprise level logic that can be reused to write new applications. Because Enterprise Services provide a well defined and stable contract between the model-oriented business logic and the process-oriented business logic, enterprise services become highly reusable in new projects, or enable either the optimization or adaptation of the process, or the service implementation itself. Of course, a business process platform (EAS's BPP) is best suited to take full advantage of Enterprise Services, and ultimately regain control of your IT.
Figure 3. Create_Order operation of the Order Enterprise Service
ESA's Composite Application Model is inherently process-centric, but the BPM vision would remain a fiction without Enterprise Services.
The conclusion of the panel was that whatever you do, don't write your business logic in code, but write code that can execute your business logic captured as metadata, such as business process or business object definitions.