This is the second in a series of eight articles that should see the light of day on both BPMInstitute.org and SOAInstitute.org during 2009. It looks to the author like the perfect opportunity to build a profound methodological case for two fundamental parts of the modern Enterprise Development Methodology (EDM): Enterprise Architecture & Processes. The first such article, making the basic case for EDM, was just recently published on SOAInstitute.org1 .
This is the second in a series of eight articles that should see the light of day on both BPMInstitute.org and SOAInstitute.org during 2009. It looks to the author like the perfect opportunity to build a profound methodological case for two fundamental parts of the modern Enterprise Development Methodology (EDM): Enterprise Architecture & Processes. The first such article, making the basic case for EDM, was just recently published on SOAInstitute.org1 . The two aforementioned publishing sites ideally cover the two components of EDM: Architecture and Processes. Thus, a series of papers, published alternately on each of the sites (one for architecture, another for processes), makes it possible to incrementally elaborate the case for both parts and for the methodology as a whole.
The goal of such an effort is quite ambitious: to elaborate and establish EDM as an objective, science-based discipline, able to completely, cohesively, and non-contradictorily describe not only the state of contemporary IT-based Enterprise but also its processes and the tendencies of its advancement. A C-level Business or IT decision-maker might ask: “Why should I care about these abstract matters when my hands are full with real practical problems, especially in these harsh times?” The answer is simple and clear: “To make informed decisions”. If you need to go north and you have a compass, but there is an impassable mountain preventing you from going directly up there, you can try to find a detour that will eventually lead you to your goal despite the initial hard circumstances. However, if you do not have a compass, you can end up where you absolutely do not want to be; you just lost. This is the difference between informed and uninformed decisions – life and death. Unless, of course you have a government bailout helicopter coming for you, then you are safe no matter what (until your next trip!) For other C- and M-level practitioners, who are still only mortals, knowledge is a matter of survival.
Now that we have, hopefully, convinced those who still can be convinced, let us talk about what constitutes the goal of EDM: the enabling of an Enterprise Business Model (EBM). While Enterprise Architecture (EA) teaches what Enterprise is, EBM encompasses what both what it is and what it does. As was shown in 2, the only process in an Enterprise that cannot be formalized is the general formulation of an EBM. This and only this has elements of an ‘art’ and heavily relies on a CEO’s experience and talent. This is why CEOs have their huge salaries and ‘golden parachutes’. Their decisions, based on numerous factors, define a company’s success or failure. However, once EBM’s basics are identified they can and should be translated into formalized structures and processes following objective methods. This is where EDM as a science starts.
We presuppose that all Enterprise does is run its External and Internal Business Processes (EIBP), constituting, together with EA, its EBM. To understand EBM, like any other complex object, better we should try to analyze it by deconstructing it into its underlying entities and their relationships. We shall call such a deconstruction Enterprise Business Process Architecture (EBPA). One might ask:”We have Enterprise Business Architecture (EBA), Enterprise IT Architecture (EA), why, for the Methodology’s sake, do we need another one”? The answer is: ”Exactly for this reason, for the Methodology’s sake”. Only by being methodologically sound, can we build a structure that will hold under the pressure of challenging practical circumstances. Besides, if we understand correctly what Architecture as an approach is, it becomes much less frightening. As we have shown many times before, any Architecture is just Meta-Design. It is a framework that describes and organizes the lower-tier, Design-level sub-artifacts of a discipline. Somehow, it always has a three-tier hierarchy: Architecture-Design-Primitive (Development) entities. For example:
- Biology/Anatomy:
- Organism;
- Organ;
- Cell;
- Microbiology:
- Cell;
- Super-molecule (e.g. DNA);
- Organic molecule;
- Chemistry:
- Organic molecule;
- Primitive molecule;
- Atom;
- Nuclear Physics:
- Atom;
- Particle;
- Quark;
Everything is relative. The meaning of the same objective entity depends on the framework within which the entity is considered. Thus, for a chemist an atom is a primitive artifact that is used to describe more complex systems (molecules) that constitute the heart of the discipline. For a nuclear physicist, though, an atom is a very complex system whose architecture can be identified via a description of its nuclear and electron particles. Thus, the term Architecture standing alone, specifies the approach only. We need to specify an area of study, a highest-level object of interest to which we apply an architectural approach, in order to start getting meaningful results from its analysis. This is why we need to be very specific in defining not just an entity but also the framework within which it is being considered. A BPM framework, for example, usually deals with the lifecycle, features, and behaviors of a specific Business Process Flow (BPF) and its sub-flows. In this framework BPF is a high-level architectural entity. EBPA, however, considers business processes first and foremost in their Enterprise context. In this framework, it is interoperations of BPFs that have a primary, architectural value. We call this architecture-level artifact of EBPA Enterprise Business Model.
Figure 1 Enterprise Business Process Architecture
Figure 1 shows EBPA as a hierarchy of its entities. The root entity – EBM – has two sub-entities: External and Internal Business Domains. Note, that we put two out of the triad of Enterprise Process types, Business Process Development Lifecycle (BPDLC), which defines how Enterprise creates and runs its EIBP, and Enterprise Business Transformation (EBT), which shows how Enterprise evolves over time, under Internal Business Domains (IBD) along with such obvious domains as HR, Legal etc. We do not include the understructure of BPDLC and EBT here, despite of their vital importance, only because we have already discussed them earlier (see, for example, ).
Under EIBD we see the hierarchy of Enterprise Business Process Flows (EBPF), starting with super-flows, which might or might not coincide with the corresponding Domains, and becoming a more and more wide-spread tree of sub-processes. The Process Flows represent Design-level artifacts of EBPA.
Business Process Flows, in their simplest variant, are represented by UML Activity Diagrams. The main element of such a diagram is, of course, Activity, which is just a request to do something: Create Account, Delete Customer, etc. As their inter-relations constitute EBPF, Activities, according to our definition of architecture, are Primitive/Development-level artifacts of EBPA.
At first glance, this would appear to be the end of the EBPA hierarchy, but it is not. Somebody or something should answer a request from Activities and actually perform the operation. This is why Services and their Domains are included in the diagram, and not just for the sake of comprehensiveness. From the methodological point of view, Process Flows and Services are entities of the same nature, just expressed by different means. On the one hand, every process flow can be considered as a service, providing a valuable response to some actor, on the other, any given business service is not only a part of some business logic, it contains a chunk of the business logic itself, just expressed by means of a code.
We see Business Rule Engines (BRE) in the same way. As opposed to typically simple code-based services, BRE might contain very sophisticated business logic and actions. Due to the fact that, historically, they were originated earlier than BPMS and were initially developed independently of the latter, having obtained some of their functions, their incorporation into EBPA sometimes causes confusion. The detailed consideration of the nature, role, and inter-operations of BRE and BPM is the topic of another article. Here we just state that we consider BRE to be service-providers for BPMS. Of course, everything said above about the dual nature of services is true in the case of BRE.
The very reason for Service-Orientation and one of the reasons for Process-Orientation is their ability to create reusable and replaceable components. The architectural decision to stop modeling activities as sub-processes at some sub-level usually means that this activity is a good candidate for reuse and/or replacement. At this point it is very important to establish un-coupled relations between such a service candidate and the rest of the world. It is, of course, achievable via implementation of Enterprise Service Bus (ESB) which makes it one of the critical components of the Enterprise Business Process Architecture.
1 W. Rivkin. Technology Does Not Matter, Methodology Does. SOAInstitute.org. March 10, 2009.
2 W. Rivkin. Closing the Business/IT Gap Once And For All. BPMInstitute.org. December 12, 2008.
