Professionals all over the world in Information Technology are fighting the never ending battle against project creep, missed deadlines and cost overruns. The lack of success in doing so seems to indicate that there is a deeper problem that has to be solved first. After analyzing customer projects for 20 years, I may have discovered a key element of this problem. Well, it actually is not a unique discovery, because it is likely that every professional in IT has run into the same situation but has looked at the consequences and not at the cause.

It seems that process fragmentation is the root cause of most unsolved IT problems.

It starts with the meta-process of IT Change Management that requires that a business application (made up from processes, tasks and actvities itself) is first analysed, then developed, tested, integration tested, rolled out and then put into production by different IT departments that distance themselves ever more from the business user. Current Change Management has however emerged over many years because of a quality requirement that is totally unreasonable in its expecations and thus has driven IT applications off the cost scale. 99.99% availability makes sense for infrastructure but not for a business service front-end. It is also not necessary as we can see from Internet use.

Here a more human problem enters the landscape. What is it that management wants from IT? One of the interests is higher productivity, meaning that less people can achieve a certain amount of throughput. The second is ensuring the quality of the work performed independant of the people and ideally enable an untrained person to perform the work needed. People are in fact put last, and that creates the problem for IT. Putting people first – employees AND customers – would make a world of difference. People are actually seen seperated from the business when they really are the business.

The current approach to the above is to analyse the business process and encode decision making into rigid rules. The resultant simplistic 2D-flowcharts and IF/THEN rules can however not properly represent the business activity that the user needs to perform his job well and to user satisfaction. It is pretty obvious that a fragmented, rigid 2D flowchart cannot represent a 4D event-driven, dynamic world that is not fragmented. Process or application monitoring does not help, as it only tells you if the defined processes are executed as defined. Business intelligence might tell you that some expected numbers are wrong but not where to improve the process. Even if you know how to improve the process, you then need it developed, tested and put into production. This loop is long and expensive as mentioned before. The business also looses its ability to adapt to market changes.

Right here, IT Change Management has to change and consolidate with application or process development. Ideally, it would already include application or process analysis with the resultant documentation that becomes part of the application. Right here, it too becomes obvious that state-of-the-art application development using programming languages such as Cobol, Java or C++ with APIs are unable to cope. This is where the SOA concept developed that tries to create a flexible definable layer between the front-end application and the back-end service. But current SOA approaches do not deliver these aspects of Change Management and are built on either Java programming with UML modelling or jBPEL with BPM modelling. Extactly that creates another even more complex layer of fragmentation and spoils the potential benefits of SOA. Adding additional fragmentation layers such as outsourcing and governance simply does not seem the right approach to achieve shorter projects and more agility.

The application solution is to see business process not as step-by-step fragments but as a collection of business services that do not much more than bundle and hold the case related business communication and information content. The content is state/event driven and implicitly creates the progression of the business case to its completion. Business professionals must be able to interactively define the business services they need (I propose by recording or training) without the use of flowchart analysis tools that are completely abstract to a business user and do mostly require later use of programming tools anyway.

The current IT process segment of defining and testing such services (processes) must not be seen as a programming effort but as part of normal business activity. The business department must be agile enough to provide the input to the power users defining services and be willing to test and fine-tune such applications. A gradual and interactive development approach like that it not really new but was first suggested in 1990 as Extreme Programming using programming languages. The difficulty of achieving reasonable system stability with compiled languages ended that approach. The project benefits of Extreme Programming can however be achieved with an application platform that includes analysis tools, deployment and monitoring/tuning as part of it‘s Change Management.

In short, what IT needs is a defragmented approach to Change Management and a defragmented approach to creating business services (a.k.a. as processes). In fact, that implies that a much further reaching consolidation of user frontend processes is necessary, and that includes BPM, CRM , ECM and SOA.