What's Wrong with Application Software? It's the Economics

  • Written By:
  • Published:

Event Summary

The recent TEC article, "Should You Modify An Application Product" resulted in an unusually high number of e-mails. Most agreed (end-users, IT professionals) with the analysis presented in the article and a few agreed (vendors) with the exception of when their favorite product or tool set was used for the modifications. We received a single e-mail that was absolutely hostile towards the position. This e-mail started with "Wake up!!! It's the 21st century" and went down hill from there, even suggesting that the article must have been "submitted via telegraph." We invited the hostile commentator to write his views in TEC, and we are waiting for his contribution.

While ignoring the fact that most enterprises are not buying new applications to replace older solutions, our critic did have some very good points. These points got us thinking about why modifications to packaged software are bad. While most of us are stuck with the application products and technologies we have, why is it that we still having problems with application software what's wrong with application software?

Both the e-mails that said that their favorite tool set or product is the exception and our hostile critic say the problem is the technology, and it is. At the root of the problem is the underlying architecture. The vast majority of application products were developed on enterprise architecture that stems from the late 80's or early 90's. At that point in time, the architects did a very good job given the realities of that point in time. Most have also done a good job of evolving their enterprise architecture to address evolving needs and the availability of new technologies. But evolution does have limits, no matter how brilliant the architects or much money is spent. The limits come from a number of decisions, well made at the time, that are now not practical or even impossible to change. At the root of the problem is the underlying enterprise architecture of application software.

However, the enterprise architecture is a technology problem, not the business problem. The business problem is time, money, and quality. Focusing on modifications as an example, the reason that modifications are bad is that they take too long, cost too much, and often have quality issues. These reasons exist both originally and throughout the lifecycle of the application software. If we could significantly change the cost, time, and quality of software development, maintenance, support, implementation, etc. we could change a lot of the "rules". For example, maybe modifications would go from being bad to being OK if they are the results of real business needs. What kind of enterprise architecture will this be? Today, many have ideas and we will leave the technology decisions to the technologist. We are interested in the business impact of the total enterprise architecture, across the entire lifecycle of software.

Lessons Learned

We can learn a lot from application software itself. Listen to most application vendors today and they are preaching integration, advanced functions and technology. Integration, advanced functions and technology offer us lessons for the future and these lessons should be part of the new enterprise architecture.

Manufacturers are using Product Lifecycle Management (PLM) to design products from automobiles to clock radios to TV dinners. PLM takes an integrated approach to the product lifecycle, from idea to development to production to retirement. PLM covers the entire lifecycle, from the idea to create a new VCR or flavor of ice cream to the specs, to the design, to production, to engineering changes to retirement. Before PLM, we had a number of tools that helped, but they were not integrated, for example, CAD helped in design, PLM helped manage a product in production.

We can look at today's enterprise architecture and typically see islands of automation. We have a series of development tools that help us with initial development, but little or no integration exists across the software lifecycle. Most development tools are like CAD systems helping with development but not across the lifecycle. The new enterprise architecture should learn from PLM and take an integrated, lifecycle view of the effort.

A number of key issues exist which have typically not been adequately addressed in the existing enterprise architecture that should be considered.

  • Reduce cost and time but not at the cost of poor quality, in fact the quality must be "built in" in the same way that manufacturers have designed for quality. Marginal cost advantages will not result in major changes in the impact of software on the business. Cost advantages must be significant. Time must be reduced such that the software can be more closely aligned with business needs on an on-going basis. To cut both time and cost and increase the impact, quality must increase.

  • The software lifecycle is a series of steps that are, in real life, very dependent upon each other. Our enterprise architecture should reflect this dependency. The solution consists of the code, but also other elements required across the lifecycle, for example the specifications, test cases, initial and "as installed' documentation, training materials, etc. These various elements should be part of a whole that is integrated and maintained or generated from a single source, a model of the software.

  • A key to the successful implementation of a new or upgraded system has always been the acceptance by the user community. The new enterprise architecture should consider the user across the entire software lifecycle by giving the business user functional and strategic control over changing business processes and on-demand alignment of the supporting applications. Also, end-uses need help in visualizing the system and changes before the majority of the investment is made. Only then can they state, "Yes, that is what we need to improve the business."

  • The lifecycle has several important decision points and the enterprise architecture should this support decision-making. Perhaps the most important decision point exists between the design phase and the development phase. The question is, does the design meet the intended business purpose. This is not only a question of the design meeting the specification; it concerns the acceptability of the resulting software to the user community. What about the value? Should we do this modification or not? Modifications are not good; they are only acceptable if they are done in a sustainable way. This go/no-go decision is an important part of ensuring that the software is stable and in control. The second major decision point is the decision to actually deploy the software, does the resulting code meet the requirements, prove acceptable to the users and therefore get deployed?

  • The same enterprise architecture should help deployment. Tailoring should only exist within the architecture and be integrated with the design, generating the appropriate documentation of the "as installed" system.

  • Enhancements (new functions) and maintenance (keeping the existing functions working) should be done within the enterprise architecture. Enhancements and maintenance should be undertaken with the same processes as the original development, with the enterprise architecture enabling the same cost, time and quality characteristics. The design, documentation, etc. should always be in synch with the operational system.

  • What we call advanced function today will be mature in the near future and out-of-date in a very few years. Our architecture should be "future-proof" -- allowing us to both add business functions and change the underlying technology platform as justified.

Who Will Get There?

Which vendors will get to the next step in enterprise architecture? If history helps us predict the future, very few vendors will go from the current architecture to the next generation. How many mainframe leaders (i.e. - Dun & Bradstreet, McCormick and Dodge) survived to move to mini-computers? How many mini-computer vendors (i.e. - ASK, SSA) are still leaders today? The answer is that some, but very few, software vendors make it from one generation to the next.

Can a vendor evolve from their current architecture to next? Evolving means a slower process where incremental changes are made to the existing architecture such that it eventually meets the demands of the next. Again, if history helps us predict the future, most existing vendors will not be able to pull it off. The problem includes the issue of being limited by the past, making it more difficult to truly break through to a new architecture.

Is this still important given the lower cost of offshore development? Many vendors are doing development offshore. This approach attacks cost by lowering the cost per person day but unless the offshore partner uses a new architecture, it will have minimal impact on time or quality. The cost advantages of offshore development are important, but since these advantages will be eliminated through time (as the cost of living in these countries rises) offshore development should be considered a valid tactical approach to addressing cost with a limited life span. Of course, the limited life span may be significant as these economies evolve. Moving to a new enterprise architecture is a strategic decision, developing offshore without changing technology is a tactical decision.

Will the big guys make it? The big guys have the advantage of money. The big guys also have the mixed blessing of a large customer base. Will the customer base support the move? Will the customer base transition to the newer architecture? Can the big guys adequately articulate the benefits of their new enterprise architecture to make the move critical/justifiable to the user base? The big guys also have the mixed blessing of an existing product. They have to enhance and support that product while spending on a new technology. Business judgment tells them to minimize risk by evolving from the existing product to a new one, but that has proven very difficult for most in the past.

Will the smaller guys make it? The smaller guys have all the issues of the big guys but with less money. However, with a smaller user base, the practical reality is that it may be easier for them to move forward. For a smaller vendor to make it, they need money and the willingness to risk what they have.

Will a start up get there first? Start-ups have a tough time in mature markets. The new enterprise architecture will take a significant investment in technology and in marketing. A better mousetrap will not be sufficient, superior marketing is a must to break into the market. Also, startups tend to lack the industry expertise required.

If The Economics Changes How Does It Impact Our 'Rules'?

Looking at different approaches to application software, from pure custom to a vanilla package, we see that the basic shape of the cost curve does not change; custom or modified approaches still cost more. However, the slope of the curve changes resulting in a lower penalty. What was impossible with traditional architecture may become practical for the business with next enterprise architecture. This will allow us to rethink and challenge some of the basic rules of application software. We can look at places where the application software rules of thumb do not match the realities of business. In follow-on articles, we will examine some of these realities, for example:

  • Business changes, software must change with the business.

  • The world is not "single vendor" and never will be.

  • Businesses really are unique one size can never fit all

  • Business processes do not follow application boundaries

  • Custom software is a requirement for many

About the Author

Olin Thompson is a principal of Process ERP Partners. He has over 25 years experience as an executive in the software industry. Olin has been called "the Father of Process ERP." He is a frequent author and an award-winning speaker on topics of gaining value from ERP, SCP, e-commerce and the impact of technology on industry.

He can be reached at Olin@ProcessERP.com.

comments powered by Disqus