Choosing an IT Application for Your Architecture
My TDF (Technology Decision Framework) is based on three dimensions for you to evaluate: functionality, architecture maturity, and engineering capabilities.
Join the DZone community and get the full member experience.Join For Free
Near religious wars have been fought over which IT product to choose for a project or business function. Should you use SalesForce, SAP, or IBM? I am not a product person, but I have learned over time that just looking at the functionality is not sufficient anymore. It is very unlikely that an organization will use the product as-is and the application architecture the product is part of will continue to evolve.
The concept of an end-state-architecture is just not valid anymore. Each component needs to be evaluated on the basis of how easy it is to evolve and replace — which is why architecture and engineering play a much larger role than in the past. This puts a very different view 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, though, is provide a technology decision framework that helps you to think more broadly about technology choices. I wrote about DevOps tooling a while ago and you will see similar thinking in this post.
My TDF (Technology Decision Framework) is based on three dimensions for you to evaluate:
- Architecture maturity.
- Engineering capabilities.
As I mentioned in the introduction, very 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. For you to determine whether a software package is suitable or whether you should rather build a custom system (which hopefully leverages open source libraries and modules to not start from scratch) requires you to take a good hard look at your organization.
Two factors will be important in this decision:
Your flexibility in the process you are trying to support.
Your engineering capabilities.
If you are not very flexible with the process you are trying to support and you have a bespoke process, then leveraging a software product will likely require a lot of customizations that are very expensive. 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. You need to understand where you stand on the continuum from a flexible process, low engineering capability (= package) to a bespoke process and high engineering capability (= 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. The idea is that a package is giving you 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, then that’s a warning sign for you.
2. Architecture Maturity
Architecture maturity is important to support your application. The better your IT capability is, the more you can build these capabilities yourself and hence you can rely on custom applications. Otherwise, the product needs to provide it out of the box. Four aspects that you can start the assessment with are the following.
When your application becomes successful and is being used more then you need to scale the functions that are under stress. The architecture should support the flexible scaling of different parts of the applications. It should do this intelligently (i.e., not just scale the whole application, but rather the functions that require additional scale)
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 the spinning up of a new version of the application/server.
You want to understand what is going on with your application. Which elements are being used, which parts are creating value for your business? To do this, 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 to? If there are a lot of common components, this will hinder you from making independent changes and will likely increase your batch size due to dependencies on those common modules.
3. Engineering Capabilities
Engineering capabilities increase in importance the more you believe that the application will have to evolve in the future, which in turn is often driven by the strategic importance of the application for your customer interactions. Good engineering capabilities allow you to quickly change things and to scale up delivery to support increasing volumes of change. The better-skilled your IT department is, the more it will be able to leverage these capabilities.
If you don’t have strong IT capabilities, then you will focus more on the in-built architecture features. Here are a few things to look out for.
All Code and Configuration Should Be Extractable
You want to be able to use enterprise-wide configuration management to manage dependencies between systems. To do that, the exact configuration of an application must be extractable and quickly be able to be restored. Inbuilt or proprietary solutions don’t usually allow you to integrate with other applications, hence breaking the ability to have a defined state across your enterprise systems
You should be able to recreate the application in its exact state from the external source control system in case it is required, this means no configuration should be exclusive to the COTS product.
The ease with which the extract and import can be done will give you an indication of how well this can be integrated into your delivery lifecycle.
The extracts should be text based so that SCM systems can compare different versions, analyze differences, and support merge activities as required.
The App Is Built With Automation in Mind and Provides Hooks
This includes code quality checks, unit testing, compilation, and packaging. None of these activities should have to rely on using a graphical user interface.
The same is true for the deployment and configuration of the application in the target environments; there should be no need for a person to log into the environment for deployment and configuration purposes.
Build and deployment times are short (i.e., definitely less than hours, ideally less than minutes).
The Application Is Modular
This reduces the build and deployment times. It also allows for smaller scale production deployments and overall smaller batch sizes by reducing the transaction cost of changes.
It minimizes the chance of concurrent development and developers having to work on the same code. This, in turn, reduces the risk of complicated merge activities.
The Application Is Cloud-Ready
First of all, it's not monolithic so that required components can be scaled up and down as required — not the whole application. Licensing is flexible and supports cloud use cases. Mechanisms are built into the system so that application monitoring is possible at a granular level.
I hope this differentiated look at things will help you make the right choice — a choice that you won’t regret down the line. Next time you have to make a choice, use this framework to help you decide.
Published at DZone with permission of Mirco Hering, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.