A long time ago a colleague said that his ideal would be a job where every day you started anew with nothing from the past intruding on your new day. I guess that’s a fair description of the way most of us regard our relationship to ‘legacy’ systems? Not surprisingly this came up in a survey of Retailers, who regarded their legacy systems as the biggest barrier to their development of cross channel online systems, but does it have to be so, or can we start to figure out a more logical approach?
I have been talking to my colleagues; we reckon that rather than a one size fits all approach to legacy, and to planning a path forward, it’s best to recognise that there are actually three separate activities and development paths. The goal of the separation is to ensure that each gets developed to separate goals to maximise their capabilities for the enterprise, as this is more effective (practical?) to achieve than a full on portfolio rationalisation.
In the first group is everything to do with using technology for cost containment where the controlling, or management issues, are predominantly based on technology issues. Here the decisions are based on change affecting the cost base positively, or negatively, as an example whether an upgrade should be implemented on the basis of reduced operating cost as there is no business functionality case. The ultimate question for this group, the real ‘legacies’ that are unlikely to change, is should the enterprise be operating these things at all, or should they be treated as ‘utilities’ and put out to be operated externally as part of an exercise to continue to drive costs down.
In the second group are those things that are business services where there is a very direct link to revenue making business activities with the pressure for change driven by Line of Business managers requiring changes to functionality. It’s not only that these applications will continue to change it’s also that they are likely to be the ones that may at some stage be required to be integrated with new Web based solutions. However there is a further defining feature that separates this group from the other two groups, and it’s the extent to which they are enterprise ‘transaction’ based. As an example an order entry system is enterprise business activity that will require periodic changes, but its role is based on data integrity, and its integration with other systems is through data. Upgrades and changes need to be a balanced decision on several criteria, but at the end of the day operating efficiency is the overall criterion.
Which perhaps makes the description of the third group as those critical business activities based on ‘interactions’, or process centric, easier to understand. In this group are the solutions that really are not legacy at all, they are the newer systems dealing with information, ‘real time’ decisions, events, etc and this is the group that will continue to expand, probably rapidly, and its here that its possibly to take full advantage of the new technologies to support business requirements. But just think about this for a moment, it’s the interfaces between the groups that are the place to base rationalisation upon. Between the first and second groups it’s a mixture of customised and Enterprise Application Integration, EAI, where as between the second and the third it should be Service Oriented Architecture, SOA.
The goal is to standardise the services exposed from group two in such a way that the processes in group three can be extremely flexible and can connect through SOA to group two applications without any new implications. Now portfolio rationalisation in group 2 can be based on the cost, time, and difficulty of exposing the services as a logical program for modernisation.
This approach can also help with another issue, the perceived resistance by the IT staff to users and enterprise adoption of Web 2.0. I deliberately say perceived as I believe that in most cases the objections are well founded around the impact on carefully structured legacy systems, and the consequences comprising a substantial risk. The approach above, though not as simple in real life as the description I have given, allows not only risk management, but the allocation of colleagues to work in the group where their skills and value are best delivered cutting down on the ‘pressures’ of trying to cope with ‘challenges’ which really do lie outside core competencies.