Flexibility
I can’t help but wonder what Steve Jobs would have thought of the iPhone X (I still say “X”, not 10): wireless charging, facial recognition to unlock the phone, no home button, and a silky edge-to-edge screen.
I’ve gotta hand it to Apple. The iPhone, as a core innovation platform, has afforded Apple the flexibility to respond to changing demands of the connected consumer. Whether it’s streaming Netflix on the bus, Facetiming with the kids when I’m traveling, or using my face to pay for food at WholeFoods, the iPhone is there, keeping pace with my life.
While we have covered other important topics in this blog series, flexibility is where the rubber meets the road. And it’s a very curvy and hazardous road.
In chapter one, I said that flexibility should be your north star to guide your software evaluation process. Without it, challenges mount every year that your company uses the same software. Change is not always predictable but it is certainly coming. Flexibility is how you support that change.
Many people believe flexibility is being able to customize software to your specific needs. This is not wrong. Software should be tailored to your business needs. After all, we’re all “special”, right? But the wrong type of software customization can lead to inflexibility.
If you hire or contract enough developers, you can customize software to meet your exact needs. These are your needs today, but what about a year from now? Will your needs stay exactly the same? What will need to change?
Even with predictive tools, we cannot control where every change will come from, or how it will impact us. So we are all constantly reacting or preparing for the changes we predict or know about. A software application should be no exception.
Four Flexibility Factors
Here are four questions you should ask to determine if the software you are evaluating is truly flexible to keep pace with change.
1. Is it flexible to meet the needs of different users or applicable business units?
This is especially important for large or global organizations. As they design processes to meet applicable standards, organizations inevitably come to reality that only some things can work the same way across different departments and/or in different countries.
Many processes need autonomy to support product classes, local business value, different business units, and even regional specific needs. The ability to take a global view along with the flexibility to tailor it locally: I call it GLOCAL ….Trademark.
Take Proposition 65 for example. Prop 65 is a series of chemical safety standards specific to the state of California. It is unique. If your software is meant to support compliance processes, you should not add complexity to core and common functionality to support outlier needs like Prop 65.
Flexibility should support a healthy balance of standards with autonomy. And if this balance managed the right way, it can have a great positive impact on usability. Why should a user in Germany have to do things or see data in the software to support processes that have no relevancy to them? Governance can make things go faster, but too much governance can stop progress dead in it’s tracks. Software that is not easily flexible leads to the iron fist of governance which can cause you to regress.
2. Is the flexibility enabled via configuration, custom code, or a combination of both?
Configuration means point and click adjustments of the software. Most people can point. Most people can click. So configuration is always the fastest and more cost effective approach. But software configuration has it’s limits.
Some software companies offer an software development kit (SDK) or development framework to support needs that go beyond native configuration. This is a good thing. And as a recovering Texan, this makes me think of the saying, “It’s better to have a gun and not need it than to need a gun and not have it.”
But beware, code is code. Code written for a bespoke need can become a liability. For example, you need to make some adjustments to your software that requires code modifications. But it was written by some guy that is now seemingly in a witness protection program and can’t be found. You either need to do a full rewrite or make a dangerous amount of assumptions. Business disruption is almost certain.
If custom code is how your software is “flexible” than it’s time to get modern software. Cloud software.
3. How easy is it to change, modify, or enhance the software?
As changes come your way, sometimes you have advanced warning. Other times it’s a five-alarm fire. You need software to be agile to keep pace and avoid 3rd degree burns.
If it takes six months to make material changes to your software by then the train has already left the station and your software’s inability to flex has just impacted your top and/or bottom line.
To help assess this, put the poor guy or gal demo-ing potential software on the spot by asking them to make a change to a workflow or a security setting. If it’s a cloud vendor, look at the release notes for the last release to see what enhancement came out that support greater flexibility.
People tend to look at cloud software releases as just new features coming or enhance functionality. Those tend to grab the attention of customers the most. But flexibility enhancements far exceed the impact of just some new flashy feature. It’s like getting better suspension in your car to stick the sharp turns.
4. Can the software application be extended?
Changes that require extending a software application can be difficult to navigate. If you can’t extend the application, you need to either get a one way ticket to the forbidden dark forest of Excel or buy yet another technology to integrate into your current system.
The extendability of on-premise software is accomplished via custom code or paying for a new module. Sometimes that module needs to be integrated, as it may use different technology from the same vendor.
With cloud software, the big difference isn’t about whether it’s private or multi-tenant cloud. What matters is if the application is built on top of an extendable application platform.
You may be wondering - what is a application platform? How can you tell a good platform from a bad one?
Thanks for opening up another can of worms Frank (ya’ jerk!).
Applications and Platforms
When evaluating software, you should know if the solution is a purposed built software application (built only for what it is supposed to do) or is it a software application built on an application platform.
An application platform is a set of capabilities and an infrastructure to build one or more applications. Either applications packaged by the vendor or custom built by customers or services partners.
To be clear, I’m not talking about infrastructure platforms like AWS, Azure, or Google Cloud. Otherwise known as Infrastructure as a Service (IaaS). That is simply where you put an application or an application platform.
Many vendors will refer to their software as a platform, so here is a quick way to get to the truth.
- How many applications have been built on the platform?
- Are those distinct applications or just modules or features of a single application?
- Can customers build their own custom applications on the platform?
- Do you have any partners building applications on your platform?
- How do you separate your applications on the platform?
- How does licensing work if I want multiple applications on your platform?
The answers will reveal more than you might imagine. A good application platform is versatile and flexible. It also enables your organization to change or modify the applications through configuration.
Expert's Guide to Evaluating Software Series:
Chapter 1: What Really Matters When Making Software Investments
Chapter 2: Defining Software Models
Chapter 3: Security & Scalability
Chapter 4: Total Cost of Ownership
Chapter 5: Innovation
Chapter 6: Flexibility
Chapter 7: Conclusion
Chapter 8: 20 Questions You Should Ask Vendors
--
Frank Defesche began his software career at Trilogy Software in Austin, TX, an on-premise software company. In the summer of 2000 he joined salesforce.com as one of their first consultants. In a world dominated by on-premise and home grown software, he was faced with the challenge of translating traditional software processes to an emerging cloud paradigm. He was part of the cloud’s first chapter and has lived it ever since. He currently serves as the SVP and General Manager of Veeva Systems and is responsible for expanding Veeva’s solutions to industries beyond Veeva’s life science beginnings.
Subscribe
