The pre-conditions for making BPM and SOA possible

Namaste,

Of course I won’t talk here about every single condition. I will discuss, however, two critical issues regarding motivation, technology, and achievement.

Why? In the last few weeks, I’ve had very interesting discussions with some architects and senior developers. They are part of bigger architect and/or development teams and had addressed me as a may-be specialist that could assist them on finding the sense of their lives I summarize the several interactions in three logical groups. They are NOT physical groups of people, and most of them qualify at least in two logical groups.

Actually, they did not find the approach of their teams very correct however not wrong either. It was just that some doubts remained in their spirits, relentlessly distracting them from executing the tasks assigned to them. They could not only follow the same savanna corridor drawn by others without much thinking about where they were heading to.

The first of this groups presented me the following scenario: for several years, they had been developing a number of applications and wrappers for other applications in a big, corporate-wide effort to create a Service-Oriented Architecture. This SOA grows incrementally, and each new service (and the refactored ones) is integrated some time later in workflows and portal that were used by one or more parts of their organizations. So, what? many more years coming…

This is a really critical issue. Actually, they did not really understand what they were doing. When looking back, they felt that the effort done for so long by so many people did not really pay back. The project was late, more costly… the same history than before. So what? All this SOA stuff was just a ton of mumbo-jumbo, a lot of marketing.

This is something to avoid: projects should be shorter, incremental, ROI calculated rapidly, process owner satisfaction should become an upfront issue. Of course, this is an enormous change as for the projects in the past this was the thing to avoid. Please, this is a critical issue for SOA projects indeed. People should perceive the added value. Technical folks should be able to compare the final result.

The second logical group, a bit smaller, was constituted by people who either:

• wanted to know whether it was possible to create geo-spatial applications, or
• wanted to know whether it was really useful to create such applications for, for example, do inventory management

As you can see, there is a problem understanding the scope of a) the technical side of the architecture, as well as of b) the project. Why were they attracted into the geo-spatial applications? why YYYY-maps or GGGG-maps?

Hey! this obsession with mashups and Ajax make the technology the only issue. BPM is not about that. SOA enables this, but you only need a couple of web services for many cases and not a whole architecture. BPM and SOA are about the essentials of enterprise applications, not about the accidental issues such as information representation and interactivity of the user interface (but for applications whose goal is this one). BPM and SOA are intended to reduce complexity and decouple the architectural components. The process-based view of the world allows to map the business activities. If your solution requires visual geospatial components, just use them. If not, do not do it. Don’t mix what is not mixable and don’t compare what is not comparable.

The final, third group is about people that struggle with too many technical issues. Is this really necessary? is it useful? why so much complexity added? wasn’t it supposed to be the contrary? Hey, that hurts!!!

These guys pass their time solving issues about XML binding by hand, XML validation, doing the right messaging implementation for the routing, writing components for authorizing access, … the terms changed, but the fashion did not: the same well-known, vintage approach to architectural design and application development. They did not understand when I talked about performance metrics, about ROI, not even about BPMS like the ones provided by Intalio or PegaSystems (or BEA or Lombardi or MS). They have a daily battle with BPEL coding, SOAP coding, XML validation: the IT view only. They’ll never speedup.

BPM and SOA are more than that: they allow integrating the Biz- and the IT-worlds. They put the IT to the service of Biz, as it was in the old days. The tools are essential, but also understanding what really has to be measured. But… how to continue if we’re not sure all the exchanged XML docs are completely consistent? Well, I think you’re completely missing the point!!! As for everything else in the universe, there are a number of basic preconditions: your computer has the virtual machine installed and working correctly, the application server executes, it reads inputs and writes outputs,… and the computer is ON. You cannot suspect & validate everything!! Nevertheless, if you’re binding XML by hand everywhere and creating sockets by yourself instead of using the appropriate tools for parsing & validating XML and for creating the web services, and you also have to take care of the 13×5 XSL Transformations since people in the 5 independent development teams do not agree on what the XML schema is and, in addition, everybody wants to manage the round-trip exchange and persistence, first re-think your project very seriously: this is neither BPM nor “managed” SOA because you positively missed something in the process of selling it.

You know? I feel just like all these people. That’s why I already saw, experienced, studied, and read about many cases just like these. I know what it is and I want others to avoid it. I saw a bit too many organizations investing money on things they did not really understand. BPM is finally there, and I invite you to make the maximum profit from it.

We can conclude, then, that the pre-conditions for making BPM and SOA:

1. Communicate well: correctly and timely; do not overstate what can be done, do not let people go onto technical issues only; put the business process as central actors; show the roadmap. Integration requires agreement.
2. Focus: Do not let people wander in the woods, having crazy ideas of what can be done; do not let them concentrate a bit too much on technology. They will solve the wrong problem.

Aloha!

Evaluating the need for BPM and for SOA

Ni Hao,

Standard approaches define two sources for initiatives of projects on this domain: the Business(?) and the IT(?).

This is just a simplification but –unfortunately– people tend to take it as “the reference”. This becomes, then, a reductionist view of the world that does not allow to understand correctly the real diversity of scenarios. You should create a less constrained view of the enterprise, their products and their services, in the way that the Systemic Enterprise Architecture Methodology (SEAM) recommends.

As the terms business and IT are too fuzzy, let us first establish more precisely what standard approaches mean:
* Business:
- Operations
- Higher Management
- Internal Control
- …

* IT:
- Architecture
- Infrastructure
- B2B
- …

If we create the extended view of the enterprise, then another trigger becomes evident:
* Industry regulators:
- Compliance
- Traceability
- …

Of course, each of these organizational actors aims to improve a specific area of the organization, or to make explicit some factor as an indicator. We will discuss this subject further in an entry some time in the future. For the moment, I propose you to read the Beer Game; a short introduction can be found here.

Now, what can you obtain from an initiative of this type? well, the idea is to change the organization (only that ). I consider that there are at least 3 different types of result that can be obtained:

• Business Improvement ( on revenue or on operational performance)
• IT performance
• Process transparency

Revenue improvement is the fact that the systemic qualities of the solution allow you can now sell more to existing customers or to new customers, or that you can create new products (as a mix of existing ones); a more classical alternative is to increase the customer retention. A different beast here is when your organization is able to integrate a newly acquired organization quickly, in a transparent way. Most of the solutions on this area require what is called agility, a combined result of BPM and SOA.

The operational performance can be improved when the system is able to do things that it was unable to do before, when the flow of the processing is smoother because many things have been either done automatically by a built-in set-of-rules, or done quickly because all the required information “is just at your fingertips” (not spread through a diverse universe of IT systems and physical archives). This is a direct consequence of BPM.

The IT performance can be seen as the reduction of the cost of infrastructure, maintenance or reduction in the cost of new projects. How can this be achieved? because the infrastructure allows to interconnect/exchange information more easily, or is decoupled in such a way that changes become less and less critical to the environment of the associated application. More SOA than BPM.

Finally, the process transparency is the possibility to track the evolution of a request, and also of finding the hot spots that make its performance slower than expected. Also, the fact that the person that has been designated a specific task can be determined easily, in order to correct/add information for the process that can help in the decision process (contextual help for beginners, for example). Of course, this is BPM.

In a future entry, I will present some arguments that talk more to practitioners.

再见