Home > business process, service oriented architecture, software development, software industry > Will packaged applications sink under their own weight? Five recomendations for change.

Will packaged applications sink under their own weight? Five recomendations for change.

I have been researching and thinking about the problem of the packaged application for many years now.  Over the years I have had conversations with many CIOs who are planning to implement large complex ERP systems as part of their initiative to streamline their operations.  There is an assumption that implementing one of these systems will simplify corporate IT. There is also the assumption that it is possible to implement an ERP system as is – in other words, without complex customization.  The sad reality is that this just doesn’t happen in the real world.

This brings me to a conversation I had about a month ago with a CIO.  He was in charge of the IT organization in a relatively large corporation (I am not at liberty to mention the company name).  The company had decided to replace its assortment of corporate business applications with a comprehensive ERP system. The idea was correct – the company needed a system that would implement business process and best practices to support the business in a uniform and efficient manner.  The problem, in my mind was two fold – first the cost.  To purchase and then implement this software cost the company $500 million dollars. Obviously, a considerable part of this expense was for professional services.  And maybe that is the point. The idea that a company can purchase a packaged ERP system that is really packaged software is a misnomer. In reality, packaged software is not really packaged.  It is a set of tools, a set of templates and processes that are linked together based on marketing and promise.  The CIO I was speaking with provided some insight into the complexity of this implementation. It required a lot more customization than anyone had anticipated. The promise of out of the box implementation was a myth.  Once the customization was applied to this package, the concept of a packaged environment was gone.  Therefore, it should not have come as a shock when the next time the base platform of processes and tools had to be upgraded; it cost the company an additional $50 million.

So, what am I saying here? Should we throw the bums out? Should we declare that the concept of packaged software is dead and flawed? Probably.  Now, let’s get real. Obviously, companies cannot and should not go back to paper based processes. However, I think that we need to get real about what it means to package software.

Here is what I propose. Let’s not pretend that packaged software is packaged.  The reality is that good software that is designed to meet a specific corporate goal should have the following five components:
1. Business best practices should be component based.  Packaged software should be a set of business services that implement well-tested business processes that are either industry or practice based. For example, accounting practices are fairly well understood and well codified.  Accounting best practices may be different between industries but it is straightforward to create modular components that are populated with processes.  It should not be constructed as a set of complex intertwined code. It should be independent modules that can be linked to each other and that can exchange data.
2.  Create standards based links. Well defined interfaces that enable the customer to link these components and other components without complex coding, including easily usable interfaces to all data files and databases.
3. Separate business rules from code. Business rules should be contained in a separate set of components or a rules engine so that they can updated easily. These rules should have a visual interface so that management can easily review them and map them to corporate governance
4. Implementations should be configurable. It should be straightforward for an organization to change the details of a process or a service without recoding.
5. Modularity is the key. Company specific rules, configurations, and services should be modular and separate from the connective tissue that links the components of these environments.  In this way, when a system foundation needs to be upgraded, it can be done without impacting the value that is the lifeblood of a company.

The bottom line: the packaged software market is at a transition point

The state of the packaged software market is complicated.  Companies across the globe have spent trillion of dollars trying to automate business practices.  Some implementations have been successful. But even those companies that have had the good fortune of implementing packaged software to streamline their business have done so at a steep financial and organizational price.  I predict that we are entering a new stage of evolution of software.  Many of the CIOs I have spoken with lately are beginning to rethink the conventional wisdom about packaged applications.  They are beginning to take the concept of business services that is the foundation of a service oriented architecture and applying that to the packaging of codified best practices.
One CIO I spoke with has started methodically to peel away key business services from packaged applications.  This might be an order to cash process that is rewritten hundreds of times across hundreds of applications.  Now, the company has created one business service called order-to-cash.  This order-to-cash service will be used anywhere in the company where this capability is needed.  This very patient CIO plans to replace duplicated services locked in inflexible packaged applications with well-constructed and very independent business services.  And some day, there will be no more complicated, inflexible, and repetitive packaged applications.  I think this might lead to a lot more innovation at a fraction of the cost.

  1. January 30, 2009 at 4:26 pm

    Judith

    Thank you for the post and especially for sharing CIOs views.

    Of course business rules should be externalized from code but why do you pay attention only to this particular kind of artefacts? Isn’t the same true e.g. for business processes, shouldn’t they be externalized from applications?

    • January 30, 2009 at 4:59 pm

      I absolutely agree with you — business processes must be externalized since that is the foundation for business practices and strategy.

  2. March 2, 2009 at 3:03 am

    nice post! , great site!

  3. June 24, 2009 at 8:48 am

    Well said, I have seen many of these in my SAP classes. SAP works on business management and scheduling.

  4. December 5, 2009 at 7:32 pm

    Judith another Informative Post, thanks Jon Purcell

  5. July 5, 2010 at 9:57 am

    Your 5 components apply not only for packaged software but should also apply for customized software. You’ve mapped out a middle-ground for these two forks in the development of business software.

  6. Joe
    August 5, 2010 at 6:39 pm

    Wow, that was great🙂

  7. September 25, 2010 at 7:44 am

    nice post thanks mate

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: