If your IT is supposed to make your business more agile, then you need to turn to SOA, right? I do not agree. Why? Because everyone is once again mixing up cause and effect! An agile organization will fully utilize IT with or without SOA. SOA will not make a business or its people more agile.
Agility will only come from business and IT being willing to innovate and empower their users by doing away with rigid business processes and the straightjacket like impediment of BPM, CRM and ECM. Encoding your processes into rigid Java for SOA is a business killer.
Why the incredible SOA hype?
The SOA bandwagon is overloaded and subsequently bogged because everyone has jumped on to sell products and services. No surprise that Network Computing Magazine has named SOA the most despised buzzword in November 2006. The ‘If You Can’t Sell It, Rename It Game’ played by the likes of IBM (with Tivoli and WebSphere), Oracle (with Fusion), BEA (with Aqualogic) and others. Something has to change, and it’s not just the product names.
Do we even know what is wrong?
I seriously doubt it. The influential quantum physicist David Bohm wrote in 1980: “Fragmentation is so widespread in our society that it interferes with our perception and stops us from solving the simplest problems.” Sounds familiar, right? We put everything in little boxes, buy best-of-breed software solutions for each and every business problem and now we are surprised that they won’t work together.
On the process level we dissect work into little process pieces because they seem easier to manage this way. Process fragmentation was described by Thomas Davenport in 1993 as such: “A process is thus a specific ordering of work activities across time and space, with a beginning and an end, and clearly defined inputs and outputs: a structure for action. Taking a process approach implies adopting the customer’s point of view. Processes are the structure by which an organization does what is necessary to produce value for its customers.”
I can go along with that but what IT implemented was more aptly described by Foote and Yoder in 1999, who wrote: “A ‘Big Ball of Mud’ system is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated.” This perfectly describes most SOA-Java application servers. Why? Because the clean object-oriented encapsulation is destroyed by an irrational requirement to use XML messages. XML conflicts with SOA, because Metadata has to be managed in a repository and not inside the data file.
I propose that David Bohm is right and that fragmentation is needed for our ability to think, organize and plan. However, the world around us is not built in process fragments and thus the current SOA approach will not solve fragmentation but rather, create a software engineering nightmare at a higher level. Business processes and process change management needs to be first looked at before IT systems can be defragmented.
Business Process 1911’s Style
There are those who say that SOA is an extension of process management. BPM proponents are however stuck in 1911’s-Taylorism and SOA makes it worse because there is still fragmented change management. Frederick Taylor believed in fragmentation and specialization and proposed rigidly structured corporations. Hence, each and every IT application represents such a business process fragment, because if not, according to Davenport, we don’t need it. But what is a business process? Rummler and Brache (1990) proposed that ”a business process is a series of steps designed to produce a product or service for a customer.” And that is quite simply, incorrect.
Yes, there are rigid processes and some Ad-Hoc approaches giving more room to the user to choose the course of the process. Strangely enough, hardly anyone seems to realize that the need for an agile enterprise is created by the dynamics inherent in process related business communication. It is obvious that the state of the communication content controls the process and not its meaningless steps. Business communication is not just a document or an email, but can be anything: a selection menu, a web page, a sticker on the document, a data record, images, or even a voice recording or video. No matter how much time and money is spent on business process analysis, there will always be one more communication item needed for a business process once it gets going. This is why collaboration tools and email are now so pervasive. They don’t require analysis to communicate.
In ‘Reengineering the Corporation’ Hammer and Champy made a very important suggestion: “Not the individual task or process is important but only the outcome.” BPM systems and BPR projects miss the ability to adjust to the dynamics of goal-orientation.
Damelio writes in ‘Basics of Process Mapping’: “Maps and flowcharts make work visible … they represent a snapshot in time …” And that is all that business process is supposed to be, as Bohm said. We need fragmentation to understand, but life does not work this way.
