Many battles have been fought, and continue to be fought, over which IT product to choose for a particular project or business function.
Should we use Salesforce? Or, SAP? What about IBM? So many decisions…
I’m not a product person. But I have learned, over time, that simply looking at functionality is not sufficient anymore.
It is very unlikely that an organization will use the product “as-is” and the application architecture part of the product will continue to evolve.
The concept of an end-state-architecture is just not valid anymore: Each component must be evaluated based on how easy it is to evolve and replace. That’s why architecture and engineering play a much larger role than in the past.
This puts a very different spin on product choice.
Of course, the choice is always contextual, and for each company and each area of business, the decision might be different.
What I can do is provide a “Technology Decision Framework (TDF)” to help you to think more broadly about technology choices.
A while back, I wrote in this space on DevOps tooling. Similar thinking applies now.
My TDF is based on three dimensions:
In this blog, I’m going to tackle functionality and architecture maturity. Let’s start with functionality.
As I said initially, often the functionality provided by the software package has been the key decision factor. The closer the functionality aligns with the process that you want to support, the better a choice it would be.
To determine whether a software package is suitable for you, or whether to build a custom system (which hopefully leverages open source libraries and modules to not start from scratch), it’s a good idea to take a hard look at your organization.
Two factors will be important in this decision: Flexibility in the process you are trying to support and your engineering capabilities.
If you are not very flexible and you have a bespoke process, then leveraging a software product will likely require a lot of expensive customizations.
If you don’t have a strong engineering capability, either in-house or through one of your strategic partners, then perhaps leveraging a software package is the better choice.
Be sure you understand where you stand on the continuum: From flexible process, low engineering capability (a package, in other words), to a bespoke process and high engineering capability (a custom solution).
If you land on the side of a software package, then create an inventory of the required functionality, either as requirements or user stories, and evaluate the candidate packages.
Ideally, you want real business users to be involved in this evaluation. The idea is, a package provides a lot right out of the box and it shouldn’t be too much hassle to get a demo installed in your environment for this purpose. If it is a hassle, that’s a warning sign.
This element is critical to support your application: The better your IT capability is, the more you can build these capabilities yourself and the more you can rely on custom applications.
Otherwise, the product needs to provide maturity out of the box. These are four aspects through which you start the assessment:
Autoscaling - When your application becomes successful and used more then you need to scale the functions under stress, the architecture should support the flexible scaling of different parts of the applications. It should do this intelligently (e.g., not just scale the whole application, but rather the functions that require additional scale).
Self-healing - When something goes wrong, the application should be able to identify this and run countermeasures. This might mean the traditional restarting of servers/applications or spinning up a new version of the application/server.
Monitoring - You want to understand what is going on with your application: Which elements are being used and which parts are creating value for your business? The application should allow you to monitor as many aspects as possible and make that data available externally for your monitoring solution.
Capability for change - You want to understand what it takes to make customizations: How modular is the architecture for you to make changes? If there are a lot of common components, you’re hindered from making independent changes, likely increasing your batch size due to dependencies on those common modules.
We’ve now covered two of my top Technology Decision Framework dimensions, which still leaves a third critical component: Engineering capabilities. In part two of this blog series, I’ll explain why the right capabilities allow you to quickly scale up delivery to support greater and faster change. Stay tuned.