Closing the Business-IT Gap Once And For All

It has been almost impossible to open a business or IT-related magazine for the past decade without seeing an article about the infamous gap between Business and IT and the misfortunes caused by it. So, let us skip the description of these misfortunes and concentrate on the gap itself.

We shall first try to define what this gap actually is and then show how modern Computer Science (CS) approaches allow for the creation of a formal methodology that closes that gap once and for all.

It is evident that a gap exists between the functional and non-functional capabilities a business wants and how IT is able to understand these requirements and create their exact, effective, and efficient computer simulations. So, it is possible to summarize the business complaints about this gap as follows:

1. The resulting functionality of computing solutions differs from those originally intended.
2. The whole process of creating such solutions is too long, costly, and difficult to manage.

To analyze the source of the problem, let us first consider the process most successfully adopted by IT: the Object-Oriented Analysis and Design (OOA&D). The OOA&D-based Software Development Life Cycle (SDLC) is trying to formalize the problem in the following way (very roughly):

1. There are two Problem Domains: Business and IT;
2. People from the Business Domain (Business Analysts) Analyze the Business Problem and create textual requirements for it, both functional and non-functional;
3. People from the IT Domain (System Analysts) take these requirements, analyze them from the OOA&D point of view, and try to extract the main problem entities like Actors, Activities, Types, etc. Then, based on these entities, they try to create a description of the future system’s functionality: first the textual, i.e. Use-Cases, and then graphical – Use-Case diagrams.
4. At this point the problem is completely immersed into the IT Domain, which should provide an exact computing simulation of the original business problem.

As we all have already learned, this is not exactly what happens. The resulting solution usually differs somewhat from the initial business intentions. It becomes very difficult to establish where and why this gap occurs because the business logic of the BAs is now fully immersed in code and is very hard to analyze.

Now, why does this happen? Why has the seemingly perfect SDLC of OOA&D often failed? In a perfect world, the tasks (1) and (2) in the SDLC would be performed by teams of IT-savvy BAs and business-savvy EAs together. In the real world this does not happen: BA’s and SA’s are not savvy enough in their partners’ areas to make it a mutual effort. It is especially hard for BAs, because OOA&D formalism is pretty complicated and difficult for a non-technical person to follow. So, let us say we have found the point and the reason of rupture that creates the Business/IT gap in OOA&D SDLC: it is between BA-formulated business requirements and SA-created Use-cases and it is caused by of the human factor. The gap in this methodology is very hard to close due to the huge differences in the semantics used by both parties. Now, we can call as long as we want on companies to have more perfect personnel, we can use pure managerial efforts to move this immovable object, or we can try to create and then use a design methodology that eliminates this point of rupture.

Surprisingly, Computer Science has already created a methodology that offers common semantics for both groups. Anybody who is familiar with the work of BAs knows that they do not start with textual requirements: it is too complex to come out right away with them. Instead, they usually start with simple graphic diagrams, specifying ‘what should be done first’ and ‘what should be done next’ based on whether the outcome of the first operation is a success or a failure. And these diagrams happen to be exactly (or almost exactly) the same as UML Activity or OOA&D SDLC Use-Case Diagrams. This situation quite resembles the situation in one of Moliere’s plays where a hero suddenly realizes that he had been speaking in prose all his life without even knowing it! Likewise, BAs have been using UML activity diagrams all their professional lives without ever knowing it.

This might look like too specific, technical, and narrow an explanation. One might ask: What about the more general issues of the enterprise’s business strategy and IT alignment? The answer is: let us try to be very specific in defining what this alignment is. What if Enterprise were capable of creating a formal internal process for making strategic decisions, translating them into specific business solutions, and then precisely transforming them into effective and efficient computing solutions? Wouldn’t that be the desired alignment? And if we want IT to be an equal player in defining business strategy let us just make this process a closed loop, thus providing business management with all the objective feedback and innovative ideas from the computing solutions being run by IT.

This is exactly what Computer Science is offering with its Business Process Developing Life Cycle (BPDLC). It proclaims Business Process (BP) as the basic element of an enterprise’s functioning and defines it as a sequence of logically connected business activities providing a valuable result to an external or internal actor. The main idea of this approach is that Enterprise does nothing but create and run its business processes. Let us note here that the definition of BP is practically identical to that of OOA&D use-case scenario (UCS), which makes it possible to formalize BP with the same UML Activity Diagram as UCS, just naming it a Basic Business Process Flow (BBPF).

Let us explain how BPDLC works by following its phases, which are marked blue in Figure 1:

1. Formulate: Business Management Team (BMT) formulates an enterprise business strategy on the basis of internal BP analysis, market conditions, and other input factors as output textual artifacts.
2. Design: Business Analyst/Designer Team (BADT) receives input artifacts from BMT, analyzes them and creates new or enhances existing BPs in the form of BBPFs by specifying the BP’s logic as BPF routes. BBPFs are the BADT’s output artifacts. No BPF routes may be changed outside of BADT.
3. Develop: IT Systems Designer Team (SDT) receives input artifacts from BADT, analyzes them, and transforms them into Executable BPFs (EBPF), which are analogous to UML’s State-Chart Diagrams, by specifying states, transitions, events, message signatures and all other necessary EBPF features. If they consider changes in the logic, they consult with BADT and let them make the changes, then repeat phase (3).  After specifying all nested levels of BPFs, SDT creates all necessary services supporting the BPFs’ execution. EBPFs and services are the BADT’s output artifacts.
4. Deploy: IT System Admin Team (SADT) with cooperation with SDT creates BPM System (BPMS)/Enterprise Service Bus (ESB) infrastructure and deploys the EBPFs and services into this infrastructure.
5. Execute: SADT tests, runs, and maintains the resulting solution.
6. Discover: BADT, in cooperation with SADT, specifies points and parameters for running BP analysis, called Business Activity Monitoring (BAM). BAM points enable a feedback data flow that describes the real-time behavior of an enterprise’s BPs. This data flow results in output artifacts in the form of reports and diagrams;
7. Analyze: BADT uses these artifacts along with Business Intelligence (BI) data analysis to provide BMT with all the information necessary to adjust the company’s business strategy.
8. Optimize: BADT uses the results of the analysis to create propositions regarding Business Process Optimization in the boundaries of the current strategy as well as providing BMT with all the necessary information to adjust the company’s business strategy. Then the BPDLC repeats itself.

Of course, real BPDLC is executed in a more iterative rather than waterfall manner. A full analysis of BPDLC is outside the scope of this paper. Just note that its phases form one of the sets of parameters that shape ESOAF 3-D matrices.

As seen from the description of BPDLC, the most sensitive transition between Business and IT, which is represented by phases (2) and (3), is no longer a problem. By eliminating textual requirements as the Business’s output artifacts and using BBPFs that are native to both BADT and SAT teams instead, we can really put Business in charge of the processes that Enterprise runs. Remember that nobody specifies the business logic that enterprise is running but BDT. So, as the author used to say to his BDT team: “What you model is what we run”. Of course, there will be some IT guys who find the very idea of Business running business logic humiliating and unacceptable. But who cares what IT guys say nowadays?