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.