Implementing an SOA often proves difficult in practice and, ultimately, it’s not possible to deliver on all the promises associated with the subject. Failing to close the gap between operational and IT departments is one of the most common problems encountered, with the service-oriented application landscape not being fully aligned with the organization’s business processes.
There has been much speculation about why things pan out the way they do and a great deal of ink has been expended on the subject. But in my view, one possible reason has been ignored. The theory I’d like to put up for discussion is this:
“We can only successfully bridge the gap between the functional (business) and technical (IT) worlds if business management courses become more geared toward service-oriented concepts”.
The following points led me to this conclusion and will hopefully form the basis for a lively discussion:
- Business and IT speak different languages and have a different understanding of things, such as flexibility and accuracy/consistency. Here’s an example: EPC is successful at the business level due to a high degree of flexibility and being relatively undemanding with regard to consistency. Increasing automation, though, calls for greater rigor. More stringent standards, such as UML and BPEL, and even BPMN, are thus required for successful implementation (machines don’t like flexibility and need consistency). Attempts to apply these standards in a business modeling environment have, however, met with failure.
- Standards can’t solve this problem because they are either on one side of the divide or the other. There are no workable approaches that aim to reconcile the two worlds via standards (formalization only seems to work in IT environments).
- Despite their claims to the contrary, tool providers have so far not been able to solve the problem of having two different languages. IDS Scheer is currently focusing on a transformative approach (which nevertheless creates problems with redundancy and synchronizing content—and things are rendered even more complicated if different tools and repositories are involved). Other players, such as IBM, are working on a view concept (but so far, the complexity of handling extensive, simultaneous changes at the various abstraction levels has turned out to be too challenging).
- Conventional business management courses focus mainly on hierarchical structures and procedures/workflows. Unlike IT courses, issues like service orientation, encapsulation, object orientation, and event processing just aren’t covered. A fundamental question that needs to be answered here is whether people think in terms of procedures (as in many standards, like EPC and BPMN) or more like a state machine (activity diagram).
- Are both sides willing to meet halfway? Or are the historic barriers between them so great that it’s no longer possible to bridge the gap?
- IT resents it when operational departments encroach on their territory by being allowed to influence service design.
- Increasing automation leads IT organizations to fear they might become less important—or even superfluous.
- IT often tries to seize responsibility for processes.
- Due to a lack of awareness and insight into service orientation, operational departments fail to understand what IT can and can’t do. They fail to realize that implementing an SOA can also involve dramatic changes in the operational domain.
I hope you’ll share your views with us, and I look forward to my points being challenged. So, do we need service-oriented business management courses?
