The acquisition and implementation of enterprise-level marketing software involves a substantial commitment of time, energy, and financial resources for any large organization. Marketing leaders who are responsible for selecting such software must consider many factors as they move through the evaluation process. Ultimately, however, the decision comes down to answering two fundamental questions:
- Does the proposed solution provide the functionality that will meet my company’s current needs and identifiable future needs?
- Does the proposed solution provide sufficient flexibility to address unpredictable future needs?
It’s relatively easy to determine whether a software application will meet your company’s current and identifiable future needs. You can collect appropriate information about existing marketing requirements and processes, develop a functional specification for the solution, and carefully evaluate the capabilities of alternative offerings.
It’s much more difficult to determine whether a software application has sufficient flexibility to handle unpredictable future needs. This is a critical decision factor because it largely dictates how durable a software solution will be. I’m using the term durability here to mean how long a software solution will function effectively and meet your business requirements. The equation is simple: The more durable a software solution is, the greater the value of the solution.
Assessing the ability of a software solution to meet unpredictable future needs is difficult because this capability results primarily from technical features of the software that are not usually visible. In short, the ability of a software solution to address future needs depends mostly on how the software is designed and built, on the underlying architecture it uses. Because of the importance of this issue, I’ll be devoting several future blog posts to a discussion of the architectural features and attributes that make a software solution durable. I’ll start next week with a discussion of system scalability.
. .
