Business Analyst Point of view - SOA versus BPM

Why is there such confusion between BPM and SOA? Whose on first? Well both of them are on first.

Recently in working with our partners it is very evident that the overlap between the engines can be explained in terms of architectural approach to a process execution need. Neither type of engine can perform all of the functions required to execute a process. This is the dirty secret. This also explains for some of the reasons behind the consolidation in the industry, which just makes the design iteration issue more important.

When talking about a process and its details people rapidly get mixed up between, what is in a box (if it is drawn in MS Visio or any BPM application) and what is the detail within that box/node. So they map the process steps horizontally, but they think about the detail or "how to logic" - vertically.

Well for BPM the box represents the requirement to bring information to a human to do something with. And it is the detail within the box or the execution of a series of steps (vertically - from an architecture perspective) - in connection with other systems to retrieve data that a SOA application executes to bring that information to the screen for the human to decide upon.

In CMMi terms the BPM can be understood as the Level II or III and maybe a little of IV, but most definately the Level IV and V are completed by the SOA or middle tier in the architecture of the systems.

The interesting part about this for the business analyst is that the vertical steps are "jobs". These jobs are common scripts written by the IT architects and ready for use in an "almost" plug and play manner. Each SOA vendor is trying to "verticalize" these "jobs" as offerings for their prospects and clientele. These "jobs" are essentially "integrations" across multiple systems. (I will talk about this more later).

A classic example is a BPM step to search for a customer record to being the process of assisting a client. The script to search for example the Social Security Number (SSN) is used many times for searching multiple applications to assess the proper data to lead the customer service rep to the next correct screen. This is the vertical (logical) search for data from many disparate systems. The average BPM engine needs to go outside to get the information via a SOA application and bring the information to the customer service rep.

But as this relates to 'design iteration' we are still in the same problem set where the business analyst is asked to provide both the horizontal and vertical (logic) without any context to the process.

We think we have an answer to this problem, which is two fold.

1. How do you provide a methodology to capture process information by the business analyst while enabling both the 'horizontal and vertical' documentation for the business people to understand?
2. How do you iterate through the process of documentation and execution to get the systems up faster to increase top line revenue?

Lastly, when we speak of execution in the design phase - we do not speak of it as "no coding necessary". And execution is not a live production system. There is no silver bullet as some would have you believe. The business problem is design iteration.

Waterfall / Agile / Where are the Practical Tools?

In the continuing dialogue of design iteration - why is it that in software do we talk about the methodology without the tools to implement them? Yes people and organizations need structure and controls around what is built. But methoolody controls are not tools which enable creativity or efficiency.

The next logical step is the desire to conform to a design iteration process methodology and over lay it on the team to produce faster iterations. A design iteration process methodology such as, "Agile" or CMMi or ITIL or UML/BPMN methodologies are essentially the same. Process driven, data capture rules with a limited number of shapes or project steps that add "structure".

What are the weaknesses in these methodologies? They are highly subjective to project steps with command and control requirements that have little getting the creative work done. Business analysts and IT architects share a need, even more so a desire to do well, to do the right thing. It is in their interests to work together for the common good, yet we put artificial barriers between them, such as different design tools, communication jargon, project deliverables which mandate primarily individual effort or steps and not team efforts. These methodologies provide very little tools to improve team effort in process or use case design.

We at Zynium have taken the best of the BPM structure for process design and placed it within an inexpensive yet widely used and understood application. To date the largest "problem" with Visio has been the "lack" of structure. Well it now no longer lacks structure, and on top of that it can integrate to reduce the cycle time for implementation of BPM / SOA or other software solutions. All while producing methodolgies in the document de jeur above.

Two Types of Design Iterations

In the continuing dialogue of the Design Iteration process shows that a limited amount of research has been performed here. Professor Smith of MIT nails it with his definition of the types. He talks at length about hardware issues and at a cusory level of the software design iteration process. The process is essentially the same. The problems especially so. What are the types he talks about.

1. Expected Iteration: Or the time it takes the team to create the first pass - a nomimal design. That time which it takes the team to perform the first pass and anticipatated time of the internal design process of each sub-team. Or those iterations which are expected and planned for.

For instance, a business analyst can anticipate some of the steps that may be occuring in a process at high level and present to the business owner a "archtectural" draft or blueprint of the selected process. So some of the design can be attempted even though sufficient information to complete them is not known. So as the input information becomes known and documented the design capture process is repeated until the process information draft is improved.

Many business analysts can relate that this is a difficult task which requires effort to negotiate information from the business client and then renegotiate with IT the documentation of the requirements. There has to be an easier way!

2. Unexpected Iteration. Here again Smith nails it. "The unanticipated iteration in the internal design including re-work due to interanl errors, errors by other groups (read IT, or other business clients who think they know) and changes in product (business) strategy." So the original design unexpectedly fails. When has that ever happened?

This failure occurs most likely, during the execution testing phase. What if we could test sooner and more often maybe we would succeed more quickly? Thomas Edison said, "Results? Why, man, I've gotten lots of results! If I find 10,000 ways something won't work, I haven't failed. I am not discouraged, because every wrong attempt discarded is often a step forward...." .

Our point is that historically we have disassociated the design phase from the execution phase. This is crazy because the one effects the other. Engineers have agreed to be monitored from a testing perspective, because they take macho pride in one uping one another on software development efficiency, and it is measurable by time. But all of us know that efficiency is not quality. Let's begin the dialogue again, anew!

So what Zynium is saying that all of the eoteric features that have been developed in the IT solutions (BPM, SOA) and that may be done, really doesn't mean anything, unless you can prove that you understand the basic steps of the process, first.

Design Iteration

Deisgn Iteration is the process of repeating tasks and is common to all types of software engineering projects. You can get this definition from most any quality assurance or engineering text. What you also find in these texts for engineering is almost a complete lack of information defining the design iteration process. Also you do not get is tools focused on the design iteration process to fix this problem of repeating tasks.

There are examples of applications which have sought to address this in the manufacturing area are, AUTOCAD and PTC . These solutions are focused on the design process of widgets.

Software testing applications have tried to focus on the back end of the process, and only on controls primarily to measure the efficiency and not the accuracy of the design of the software. Solutions such as Rational Rose and Mercury Interactive now HP, Segue - now Borland. By the way none of them take a process centric view. Nor do they focus on the "CRM " of the design process. The analogy is CRM is the front end of a business. Or the sales side. Managing the sales process can lead to increased sales and higher margins. The CRM of the Design Process is the critical component of development which is ignored for a variety of reasons. We will explore these reasons both real and imagined in this blog.

Process Improvement

Process Improvement

We are gathering information on the types of day to day tools that the following functional employees use to gather information prior to any IT implementation:

• business analysts,
  
• systems architects
• Six sigma
• IT architects
• Compliance documenters

By tools we mean the average application which is most commonly utilized to gather information. These tools may include the following:

• MS Suite of applications - detail which ones and why
• Plotters to print process maps in large format for hanging on the conference room wall
• Methods of collaboration - which tools
  
• Methodologies or combinations of methodologies - which ones
  
• Other modeling tools
• Tools which the group can all agree to work in and share information