About six weeks ago I started talking to you about an application portfolio analysis approach based on a simple model looking at the application type and importance for the organization. Since I’ve been refining the model and had the opportunity to test the approach with a couple CIOs. We discovered it actually works not just for application retirement, but as a tool to identify how to analyze your application portfolio to digitally enable your company. Over the next couple blog entries, I’ll walk you through the different aspects we reviewed. We started defining the future infrastructure, then looked at automation and finally at the type of transformation required for the applications to run in the new environment.
The Digital Enterprise
Before discussing the first of these three points, let’s review the increasing importance of “digital” in today’s business. Everything, everywhere is becoming digital. Music, video, communications, even money, they are mostly bits and bytes on computers. 2016 has demonstrated the importance of social media to shape the thinking of populations, driving society choices. Start-ups have used digital technologies to disrupt existing businesses and industries. Existing companies are confronted with a fundamental choice, change the way they operate, disrupt their industry or be disrupted by others.
This trend leads to two new phenomena, the increased use of data to gain insight and understanding in market behaviors and trends (big data) and the growth in automation. Slowly but surely decision making is evolving from reactive to a proactive. Sensors are placed everywhere to understand and predict. Being it driver assistance in cars, stock market analysis models, the objective is the same, predict to either avoid incidents or take advantage of specific evolutions.
In this approach the consumer is in charge, he defines the next move by choosing the service. Brand loyalty is disappearing fast so companies need to constantly battle for mindshare. That is the new digital world.
The opportunity for existing businesses
Existing companies have a good understanding of their market and a series of processes geared to respond to market demand. These are embedded in their application portfolio. This can be an asset or a liability, depending on how the enterprise looks at these assets. If they are prepare to jeopardize their current way of working and re-assemble the pieces in new and innovative ways, they are well placed to become disruptors in their market. If they let “devil’s advocates” drive them, they will be lost.
How should we evolve applications?
At the core of the digital enterprise we find innovative processes that use digital functionality to quickly and efficiently deliver first class services in an intuitive manner to end-users. As already describes in several blog entries, processes consist of a series of activities that are performed in a given sequence. Many of those activities are automated and use functionality, often embedded in existing applications, to perform the job. So, the first thing to do will be to expose the functionality so it can be called up by the business process. We will come back to that point in a later blog entry.
One important question is the granularity level of the activity. Within the frame of microservices, I described a typical approach to identify an adequate granularity level. Although activities do not have to follow all characteristics of microservices, the points I made are still relevant.
Let’s start by looking at systems of record
Systems of record support the core transaction processing and manage the organization’s master data. Most often these systems have been in existence for many years and are used by a rather stable user base. The demand on these systems is well known and it is very seldom that the functionality contained in these applications is directly exposed to end-users and clients. But these applications are important as they support the working of the enterprise.
Some of these applications differentiate the company. These are the core applications. The main supply chain operations systems are a good example as many manufacturing companies differentiate themselves through their supply chain. What do we do with such systems? Where should they be hosted?
Utilization patterns are a key decision point here. Applications that are used on a daily basis can easily remain in their existing legacy environment. There is no need to migrate them to the cloud or any other fancy technology. Being core, you probably want to keep a close control on the environment, being used daily you may want to have them running on dedicated infrastructure as this is probably the cheapest way to operate them.
On the other hand, the applications that are only used occasionally, for example the month-end closure functions, should move to the cloud so they only consume infrastructure when required. By shutting them down when unused, cost is saved. These applications are hosted in the cloud, but operate as usual. They are cloud hosted. We’ll come back to that when discussing the transformation of applications.
If the functionality is context, does it makes sense to continue operating and maintaining specific applications in support of the functionality? As there is no differentiation, choosing a SaaS service or at least a COTS (Commercial of the Shelf) package – with as little customization as possible – is probably the cheapest approach. One question that remains is around the data. If a SaaS service is consumed, where is the data located, who owns it, how is it managed and how easily can the data be recouped if you decide to change provider? These questions have to be asked and taken into account. If the data does not need special protection (the data may be core), such applications should run in the public cloud. It’s the cheapest option.
What about the systems of engagement?
Systems of engagement allow peer to peer interactions, support collaboration between employees, partners, suppliers and customers. They change more often, and in an ever more digital world, their utilization patterns become unknown and unpredictable. This means that applications delivering the systems of engagement functionality need to coop with variable demand. As we highlighted the importance of user experience in the digital enterprise, the applications must be able to deliver this quality regardless of the number of concurrent users. This leads to cloud technologies in general and the capability to scale-up and scale-down portions of the application directly in contact with the users. These applications need to be cloud aware.
If the applications are core, you will want to keep them in an environment that is closely controlled by you. So core systems of engagement should probably be hosted in a private cloud, while context ones can easily be hosted in a public one.
Two elements may actually make the move to the public cloud difficult. One is the sensitivity of the data accessed by the application, the other is the interactions with other applications.
In some situations, context applications interact with core data. The context CRM system may need real time access to the status of orders in the supply chain system which may be considered as core. It’s all a question of latency. If we put the context CRM application in the public cloud, how fast can it get a response from the supply chain system running in a private cloud? Or if a direct database query is performed, how quickly can that be executed when the data is in a private cloud? The response to those questions will influence the decision taken for the context application.
And finally, systems of innovation
Systems of innovation are new applications that are built on an ad-hoc basis to address new business requirements or opportunities resulting from the evolution to a digital enterprise. The approach is fundamentally the same as the one described above for the systems of engagements. The applications will need the agility and responsiveness provided by true cloud capabilities as they are directly involved in delivering the new, disruptive, business approaches. Core applications should go to the private cloud while context ones can go to the public cloud. The data and integration aspects discussed above remain valid.
Identify the landing zone for each application
The first thing to do is to identify for each application in which of the 6 boxes the application belongs. This is actually not an easy task as it requires a clear understanding and agreement on what is “CORE” for the enterprise. But once that is done, the decisions become quite easy to agree upon.
In the next blog entry we will look at the automation that should be put in place for the applications in each of the 6 boxes and what that implies. Hope you enjoyed the reading. A happy 2017 to you. May this year be the one where you evolve to the digital enterprise.
Next Blog: Improve your application agility