In the previous article, When traditional application maintenance won't work anymore, we ended with the question how to improve todays traditional application management.

Let's start with some general thoughts, examples and then be a little more specific about how to solve the problems with AD/AM in traditional IT.

A long time ago, I went to a sales course and one of the first lessons was that the sales process always was the same. This was regardless if you sold a bottle of milk to a consumer or a factory producing milk to a company. We as attendees didn't agree, as our point was when you came to reality it did matter. On a very high level, the sales process is the same, but on the other hand, it's on a to high level to be practically useful.

In the early days of ITIL (v2) the was always one and only one way to handle all Change Requests. Everything was managed in the same way. With v3 of ITIL, they introduced Service Request, i.e. changes that were simpler to implement and with less risk.

If we look at the telecom sector, standard processes have been defined by TM Forum since a very long time ago. The talk about fulfillment, i.e. when a customer have a service provisioned. This is rather similar to the Service Request in ITIL and a lot of information about all details could be found on TM Forums's site, (members only). The next type of change is when you have to change your production environment. For telcos is it the network, for a manufacturing company is the plant and for healthcare a new hospital. Then you have changes to your offerings, products and services, i.e. what you sell to your customers.

The challenge with both these to approaches is that were developed in the pre-mobile-internet-available-everywhere-for-everybody era. Today, the need for fast changes is much much higher than before and I wouldn't say that either eTOM or ITIL are very agile by default.

In an ideal world, everything should be agile, but theory and reality doesn't always match. The question is what needs to be agile and gives a huge business benefit, and what doesn't. If we go to a telecom operator as discussed earlier, the need for make huge changes in mobile or fixed networks comes when there is a new technology-standard as VoLTE or 5G. But, in order to succeed in a very competitive market, you have to have a very agile process for developing and implementing new offerings and products.

So my first statement, for now, that traditional AM still works for back-end systems supporting the production, but we need a more agile approach for those systems supporting the market.

By coincidence, this is the separation of systems we have in the telecom-sector for ages. We talk about BSS and OSS, Business Support Systems and Operational Support Systems. The third area is Enterprise systems, covering supporting functions as finance and HR. The challenge now is to have a clear separation of systems and avoid huge monolithic systems that could be either bespoke or COTS solutions.

My other statement is that you have work much more closer between application development and application maintenance. To make new software development with one group of people and then let another group handle application management, including ITIL type CR's and SR's have it's challenges. There are difficulties with prioritization between stakeholders and communication between the groups. You need to have a more agile appoach to change in software development as it's the only thing that is constant.

The question then arise how to organize such a separation of different types of systems. The options spans from one IT-organization responsible for both parts to a green-house approach were the new agile systems are separately from CEO-level and down. In the article Perils of architecture governance, I wrote about different organizations models and the impact of changes to IT. As always, it trickles down to money and where responsibility for P&L lies.

Well aware of the human nature and the urge to resist to changes, I would recommend that you separate the more customer driven systems from an organizational point of view from more production oriented systems in order to be more flexible where you really need it. I know that there are both pro's and con's with this approach, but you have to make a bet instead of doing nothing.

Disruptive architecture