 |
|
|
 |
||
 |
||
 |
||
 |
||
 |
||
 |
 |
|
 |
||
 |
||
 |
||
 |
||
 |
||
|
||
 |
Your independent resource on business integration and network computing through middleware and message brokering
Chaos: charting the seas of information technology
Jim Johnson
Chairman, The Standish Group
Management introduction
The Standish Group International, Inc. conducts market and technology research for users and vendors in the mission critical OLTP and open systems marketplace. Its research draws upon extensive real world industry experience and years of proven market research and consulting which are published in its COMPASS (Comprehensive OLTP Management Planning and Strategy Service).
In particular COMPASS focuses on selected technologies (several of which are regarded as middleware) that the Standish Group believes are critical to implementation of distributed applications. These include:
- transaction management technologies, whether transaction processing monitors and database management systems
- application life cycle technologies, including application development and enterprise-wide system management capabilities
- high availability system technologies, including fault tolerant and fault resilient solutions.
In this summary of some recent research about how and why projects succeed or fail, Jim Johnson the founder and Chairman of the Standish Group examines the results of that research. The results are shocking in their implication.
Bridges and project failures
"The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone and, as a result, far too much labor to build. Over the years we have learned to build bridges more efficiently, using fewer materials and less labor to perform the same task." Tom Clancy in The Sum of All Fears
In 1986, Alfred Spector, President of Transarc Corporation, co-authored a paper comparing bridge building to software development. The premise: bridges are normally built on-time, on-budget, and do not fall down. On the other hand, software never comes in on-time or on-budget. In addition, it always breaks down. (Nevertheless, bridge building an early form of middleware did not always have a stellar record. Many bridge building projects overshot their estimates, time frames, and some even fell down.)
One of the biggest reasons bridges come in on-time, on-budget and do not fall down is because of the extreme detail of design. The design is frozen and the contractor has little flexibility in changing the specifications. However, in today's fast moving business environment, a frozen design does not accommodate changes in business practices. Therefore a more flexible model must be used. This could be and has been used as a rationale for development failure.
But there is another difference between software failures and bridge failures, beside 3,000 years of experience. When a bridge falls down, it is investigated and a report is written on the cause of the failure. This is not so in the computer industry where failures are:
- covered up
- ignored
- rationalized.
As a result, we keep making the same mistakes over and over again. Consequently the focus of the latest research project at the Standish Group has been to identify:
- the scope of software project failures
- the major factors which cause software projects to fail
- the key ingredients which can reduce project failures.
Figure 2: Cost overruns
Figure 3: Project success factors
Figure 4: Project challenged factors
Figure 5: Project impaired factors
Figure 6: Success criteria
Management conclusion
As Jim Johnson describes, application software projects are in trouble. What is also increasingly clear is that distributed systems contribute to complexity and, therefore, the difficulty in delivering projects on time, within budget and with appropriate functionality. By definition, as part of the distributed system equation, middleware is part of the problem.
Indeed empirical research also suggests that one of the added explanations (not discussed in the Standish Group work) is that the development paradigm for distributed systems remains firmly locked into the mind set applicable to centralized systems. Unless middleware can be separated ("decoupled') from the components (applications, operating systems, etc.) so that multiple, parallel developments can be undertaken in small manageable chunks, we may have to get used to what Jim Johnson describes chaos, or continuing trouble on the information technology seas.