Platform consolidation

A key parameter for being able to launch solutions in a time-to-market manner is avoiding a forest of applications that basically all have the same or overlapping features. Businesses should thus work on consolidating systems and platforms to make it easier to initiate digital projects that utilise the potential of the application landscape.

If there is only one system for browser-based communication towards customers, one solution for internal communication, one internal collaboration tool, one CRM and so on, there will be no discussion about what to use and how to use it. In this scenario, it is possible to launch small, fast, MVP-based development sprints, so it is possible to release new services and solutions at a high pace. This is why the consolidation of platforms and systems is decisive for the pace of innovation.

Initiating expensive infrastructure projects as a condition for pace of innovation is not recommended. The architecture strategy with the to-be scenario and launching wide-ranging consolidation projects as an end in itself will never be approved by an investment board, since the business case for such infrastructure projects usually is poor. There is no return on investment (ROI) if these activities are not incorporated as part of commercial, ROI-driven projects initiated by the business units.

In most cases, corporations and organisations can incorporate their activities in the commercially-driven projects that nevertheless have to be executed. Naturally, some determination at executive level is required to shut down systems that do not fit into the strategy, or which are unnecessary, because the business is going to focus on other systems. The process of taking the hard, but necessary decisions can easily be part of these commercially driven projects.

Consolidation

Once the business has defined its strategy for the architecture, and defined a to-be application landscape around its reference points with the aim of enhanced pace of innovation, work is needed to consolidate the platforms.

By mapping every tower, we know which systems are in use in each tower, and hopefully it also becomes possible to identify any shadow IT that might exist.

By considering cloud vs on-premise, best-of-breed vs best-of-suite, and the running and development costs per application in each tower, the business will have gained a good idea of which card in each tower it wants to focus on. The process of consolidating its activities on a few, strong applications can then be planned.

Application Strategy

The architecture must support changing requirements, including the provision of effective and time-to-market solutions for customers, employees and partners. If the architecture is not geared to doing so, then the digital processes will be perceived as being slow, complicated and resource-intensive.

One way of orchestrating your architecture to counter this problem is to use Gartner’s Pace-layered Application Strategy. As the name indicates, there are various roles and different paces of development in the various layers of the architecture.

There are several problems with a bimodal IT strategy. Remember the problems concerning the tendency towards a long development mode involving legacy and core systems which are neglected in commercially driven projects? Consequently, data from legacy and core systems will not be employed in the new development, innovation and extension of the existing business. Put simply, old systems can disappear from the radar, and business units thus forget to bring data, processes and that part of the end-to-end value chain into play when shaping and designing new innovative projects. The bimodal IT strategy has thus the regrettable side-effect of forming silos that do not bring into play data from legacy and core systems. Hence, digitalisation is only performed halfway. This will eventually raise costs, as the justification for core and legacy systems is still present, but the core and legacy system can disappear from the digitalisation of business processes.

And this is exactly what Gartner’s Pace-layered Application Strategy is designed to avoid, by putting the entire application landscape into one concept.

That concept can be illustrated as follows:

System of Innovation
The System of Innovation is characterised by new applications which are built on an ad hoc basis to address new business requirements or opportunities. These are typically short life cycle projects (0-12 months) using departmental or outside resources and consumer-grade technologies. Consolidation projects within ‘System of Innovation’ are centred on concentrating customer-focused applications on a few, safe options for customer communication. It is often in this layer that shadow IT is identified.

Considerable savings can often be made by consolidating all web, app, marketing automation etc. onto a few strong cards. This is often referred to as omnichannel. To achieve cross-channel consistency, the different customer-facing channels must use the same master data through a well-defined IT architecture.
System of Differentiation
In the layer called ‘System of Differentiation’, one can also identify possible gains and potential consolidations. In this layer, applications that enable unique company processes or industry-specific capabilities reside. They have a medium life cycle (1-3 years), but need to be reconfigured frequently to accommodate changing business practices or customer requirements. In this layer, the applications and concept reside which can differentiate the business from competitors within the same industry. In other words, by utilising customer data, analytics and product information management, a business in the e-commerce industry can outperform its peers from the same industry through the determined governance of these applications and consolidate its activities on the applications and concepts that will differentiate the business from its peers. One example of consolidation in this layer is if your business is working with two different CRM systems following acquisitions or mergers, but has not yet standardised the use of customer data into one system.

You might also have a data warehouse, a Power BI solution and an Adobe analytics service without considering whether it might be possible to use only one tool for analytics. This is another chance to optimise, and to accelerate pace of innovation through consolidation.
System of Records
A System of Record is characterised by established packaged applications or legacy homegrown systems that support core transaction-processing and manage the organisation’s critical master data. The rate of change is low, because the processes are well-established and common to most organisations, and are often subject to regulatory requirements. In this layer you will rarely find two systems with the same features and thus with a potential for consolidation.

There may be COBOL systems that are irreplaceable because there is no standard system, or the business’s domain is so specific that there are no alternatives to a tailor-made application. The focus here should be on ensuring that these systems are geared to a higher volume of traffic, more transactions from an omni-channel set-up and new digital initiatives. Microservice architecture will ensure that your business can increase readings and writings to such systems through a narrow cloud-based microservices layer which can ensure, for example, that orders are not lost, but put into a queue, and that data can always be sent to and retrieved from the systems.

One method worth considering is a ‘strangler pattern’ – a strategy through which a business can break down its monolith into microservices one at a time. The idea is that the business gradually transforms a monolith application into microservices by replacing a given functionality with a new service. When the new service is ready, the business can ‘strangle’ the old component.

This principle will gradually create better ways of bringing data from legacy systems into play through innovative and commercially driven projects in the System of Innovation.

Consequently, reorganisation using a strangler pattern is not recommended for executing one single project. This task should be part of the design of the projects implemented in a System of Innovation. They are thus financed through business-critical innovation projects. As such, older legacy systems which are still required will not represent a bottleneck in the overall digitalisation, which means that packing your legacy systems in a microservice architecture can accelerate pace of innovation.

The Crucial Power Between IT and Business

If IT and the business have conflicting objectives and success criteria, the company's pace of innovation will suffer. To unlock the synergy, a shared understanding between the two is important.

The IT architecture of the future is here

One of the biggest impediments to accelerating pace of innovation is older legacy systems. They are not geared to becoming part of a modern, scalable, and digital omnichannel solution. Instead Microservice as an IT architecture principle represents a refreshing break with traditional development.

Improve your business through platform consolidation