The Four Pillars of a Successful Application

When working with OpenEdge partners, it is not unusual to hear some statement like, "It's a great product, but I just can't through the demo."  Or perhaps, "We have better functionality, but we still lose deals."  These laments point to a common problem with business applications, particularly those applications that might have, to be polite, "a little age on them."

For an application to have both initial success and longevity, it must be built of four pillars of strength:

1. Functionality:  The domain-specific capabilities addressed by the software.  It might, for example, be about inventory, or order management, or credit management.
2. Features:  The non-domain capabilities of the application.  These usually include user interfaces, integration capabilities, search and navigation methods, reporting or inquiry systems, etc.
3. Architecture:  The under-the-covers construction methodologies used by the application.  Like most things in the world, applications should be build on a solid base with a solid design.
4. Technology:  The basic technologies and infrastructure components that support the application.

All four of these areas are worthy of full discussion and we'll try to hold that discussion in future postings.  But right now I'd like to talk about balance.  Here's an old story from my past that perfectly illustrates the concept of application balance.  About a dozen years ago my sister was on a committee to select new software for maintaining accounts and processing information for the university alumni association where she worked.  The were down to J.D. Edwards and another specialty vendor - one that I'd never heard of and that you won't know either.  She wanted some advice from her brother in the software business (tell me that never happens to you!).  I told her that she was likely to see some very good looking software from J.D. Edwards with some very impressive technology underneath.  But I told her to press them hard on functionality that truly fits the nooks and crannies of her job.  I also advised that they would probably come up short.  My advice on the other vendor was the opposite:  That the software would probably be a perfect fit for the business, but would not look as impressive and that the salesrep would likely shy away from technology questions.

Needless to say, she called back a month later and her first words were, "How did you know?"  Right now, your heads are nodding up and down because you've seen the same thing; software companies that focused on functionality to the exclusion of the other three areas, and software companies that focused on features but didn't real have good, industry-specific functionality.

In the OpenEdge world, application partners have always put the greatest weight on functionality.  It's an easy thing to do.  New functionality keeps current customers happy, helps close the next new deal, and further cements the partner as an expert in their field.  But if the imbalance is taken too far for too long, serious damage occurs.  The application becomes unwieldy, non-competitive, and eventually, obsolete.  Let's look at those four areas again:

    Functionality:

• Keeps current customers happy
• Provides advantages over other industry competitors
• Belongs 100% to the partner (Progress doesn't contribute)

    Features:

• Keeps prospects happy during demonstrations
• Provides advantages over other general-purpose competitors
• Is enabled by Progress, but must be implemented by the partner

    Architecture:

• Makes IT departments and development departments more productive
• Adds longevity and agility to the application
• Is enabled by Progress, but must be adopted and evolved forward by the partner

    Technology:

• Can become a barrier to future sales if not kept current
• Adds interoperability and flexibility to the application
• Is primarily addressed by Progress, but partner can adopt and extend

When you look at the four areas from this perspective, the importance of balance becomes immediately obvious.  Sure, you might put more weight on functionality overall, and there might be periods of time when one of the four areas gets the lion's share of your attention, but overall every application must keep these four areas in relative balance. 

Last summer, I had a customer ask me when an application becomes obsolete.  My answer was this:  With proper attention to all four areas, an application never need become obsolete.  After all, applications are just bits and bytes.  But if any one of the four areas is ignored for an extended period of time, the result will be application that faces the need for massive overhaul.  And that's when applications become obsolete.

We'll explore this idea of the four areas and the balance between them in future postings.  In the meantime, I'd love feedback on this and any other topics of interest.