Skip to main content Skip to Footer

BLOGS


May 02, 2017
How to choose an IT application for your architecture—Part 2
By: Mirco Hering

In my previous blog, I discussed the importance of functionality and architecture maturity when one is making technology choices. Now, I will cover the third dimension of a “Technology Decision Framework (TDF): Engineering capabilities."

Engineering capabilities increase in importance the more you believe that the application should 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, the more it’s able to leverage these capabilities. If you don’t have strong IT capabilities, then you will focus more on the in-build architecture features. A few things to watch:

  1. 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 so, the exact configuration of an application must be extractable and quickly can 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.

  1. The application is built with automation in mind and provides hooks (for example, APIs) to fully automate the lifecycle.

    • 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 (e.g., less than hours, ideally less than minutes).

  1. 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 reduces the risk of complicated merge activities.

  1. The application is cloud-ready.

    • First, it is not monolithic, so the 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’re faced with such a choice, review the dimensional framework of functionality, architecture maturity and engineering capabilities to help decide.

Popular Tags

    More blogs on this topic

      Archive