Automation – Serving 'run the business' and 'transform the business' portfolios

Image: Shutterstock

Automation is too wide a topic. It includes simple script based automation to monitor a server and running a maintenance script to make sure storage does not get full or it could mean automating a complex business process like loan origination in a bank. For now, let us limit it to automation in the context of software engineering and look at what the main objectives of automation are in this context.

As depicted in the diagram below, most enterprises still spend 70 percent of IT budget to “Run the business (RB)” with only 30 percent of IT budget at disposal for “Transform the business (TB)” initiatives. We usually see significant inefficiency in RB portfolio. Automation plays a major role in bringing efficiency in RB portfolio and reducing the total cost of ownership (TCO) thereby making more budget available to TB portfolio. While driving TB initiatives, it becomes critical to stay ahead of competition and hence “time to market” would be the main objective.

Let us look at these in bit more detail. Run the business portfolio
In most enterprises, this portfolio can be very complex with many software systems supporting the business using varied set of technologies; including Mainframe, Legacy ERP systems, Client-server systems, Web portals and applications , Multi-tier systems using JEE / .NET, multiple RDBMS databases, multiple integration technologies, etc. Key objectives of automation here would be to bring efficiency in the portfolio and reduce TCO thereby enabling more investment to be made available to “Transform the business” portfolio.

Let us look at various types of automation that one can introduce in “run the business” portfolio.
As you can see, the higher the level of automation, the higher the efficiency one would get allowing that money to be moved into “Transform the business” portfolio.

Transform the business portfolio
As highlighted before, in all the programs driving digital transformation, achieving better time-to-market is very crucial to stay ahead of the competition. Therefore, increasing the velocity of features to production will be the main objective.

What this means to Software Engineering & execution approach is as follows:

• Higher deployment frequency – Higher frequency of deployment of features to production
• Lead time for changes – Time taken from code commit to code successfully running in production
• Mean time to recover (MTTR) – How long does it take to recover service when a service incident occurs?

Let us look at what the expectations are from enterprises and ISVs (Product / Platform / SaaS companies).
These expectations can be met if the below aspects are taken care of:

1. Cloud-first thinking – New age applications should be built with Cloud-first thinking. All the leading cloud providers today allow the environments to be created with a click of a button in seconds/minutes. In the traditional world, this used to take weeks/months sometimes. Apart from the basic environment, if we use native cloud capabilities to build applications, development time can be shrunk some more. For example, using AWS SQS (Simple Queue Service) instead of ActiveMQ or RabbitMQ.

2. Microservices based architecture – This is going to be crucial to enable moving new features to production without affecting the other features that are already running in production.

3. Automation from the word go – Automation of builds, integration & validation should be thought through from the beginning and should never be an afterthought if we have to meet the above said expectations

4. Teams owning vertical slices of architecture – Gone are the days where teams would own horizontal slice of the architecture coding parts of the feature using a specific technology; this could be front-end or back-end services or integration. This is very inefficient because different teams will have to come together to integrate the code. To meet the above said expectations, teams should be given responsibility to build feature(s) and should be allowed to push them to production and eventually support. This will require team members/engineers to have full-stack capability. However, most enterprises will have multiple checks and balances before moving to production. Hence, teams should have access to promote code to pre-production environments. Similar scripts can then be used to promote code to production.

Summary
Automation serves different objectives in “Run the business” portfolio compared to “Transform the business” portfolio. In “Run the business” portfolio, different levels & types of automation to be deployed to gain efficiency. To achieve better time to market in “Transform the business” initiatives, enterprises, ISVs and service providers will need a very different approach towards engineering and a completely new set of skill sets with “full-stack” mentality.

The author is Madhusudhan KM, Chief Technical Officer, Mindtree.

The thoughts and opinions shared here are of the author.