We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion

How do you keep legacy systems from holding your business back?

Vote 0 Votes
As reported by Chris Taylor from a recent Gartner Keynote, "The single biggest problem most organizations have today is exactly what to do with legacy systems that are crucial for the business as both systems of record and as business process support."  So what's the solution?

13 Replies

| Add a Reply
  • Wow, what a loaded question.

    The assumption that the legacy systems are holding back business raises another question - holding business back from what? Moving to the cloud? Growth? Reducing margins?

    The problem is that there is a significant amount of business and operational value locked up in those "legacy" systems. These are "old" systems, well tested, with proven processes. The cost to transition them to modern systems is not just in hours and systems but the potential problems introduced during such a transition.

    Just as is the case with legacy ERP and CRM systems, one of the best ways businesses can make legacy systems more agile and fit into modern systems is to enable them with modern APIs that will lay the foundation for an admittedly longer but much safer and less disruptive transition. Put into place modern APIs and then slowly transition systems to modern architectures and models behind the scenes. Abstraction is the answer for businesses that rely heavily on legacy systems.

  • I think most organizations know exactly what to do with legacy systems as they really only have three choices: continue, upgrade, or replace. What troubles organizations is the value proposition of each of those choices. Can they swallow the cost and effort of replacing it? How long can they continue putting it off? Is an upgrade viable? Can I get by with a workaround?

    I still have firms running systems long since sunset for a number of reasons with cost far and away being the primary driver and need of features/capability secondary. As features/capability tracks closer or overtakes cost as the driver, firms will find the money and time to address their legacy system(s).

  • Holding Back? You meant "Holding up"? :-)

    The dirty little secret of large organizations is that even with "technologically progressive" organizations, many functions like Payroll are still run on Mainframes and older minis like Solaris systems! Even with virtualization, you can buy an IBM AIX system and emulate older mainframe operating systems on them! If ain't broke, why fix it? Especially with stuff like Payroll? Many organizations have built Service-Oriented Architecture interfaces to mainframe systems, developing new stuff on new platforms and integrating them together!

  • Eclipse them (legacy applications) by making coordination explicit as described in this blogpost http://improving-bpm-systems.blogspot.com/2013/06/enterprise-patterns-eclipse.html


  • The fact is that business is constantly changing and adapting to the business requirements on a yearly basis, and organizations change even faster: people get promoted, change groups, leave old teams, form new teams, on a monthly basis. What can you do about IT systems which are put into place for 5 to 10 years or more?

    The solution is 60% terrible, but 100% necessary: You make new applications to support the new business and organizational functions which are integrated to the legacy systems "as a service". Yes, SOA comes to the rescue and allows you to "paint over" the old infrastructure with a new layer of applications that meet your current need. Here is my presentation on the topic:


    It works, and it allows you to support your current business needs without ripping out the old technology which might otherwise hold you back. Why is this so terrible? For exactly the same reasons: it does NOT require you to clean house and so you don't. Legacy systems will continue to collect. There is a hidden cost, but it has been kicked down the road a ways. Yet there is no denying that it costs less to embrace and extend than to rip and replace. There is an esthetic side of me that would rather see the old systems cleaned out, but this kind of house cleaning does not necessarily make business sense.

    • Keith is right - the approach he describes is the worst approach, except for all the others :)

      Most of the spectacular IT failures have been rip-and-replace projects - not incremental change projects.

      Paying down technical and process debt is hard, disciplined work, and it isn't work that gets done when you keep your IT department and budget on survival rations.

      Companies need to stop looking at IT as a necessary and unfortunate expense and instead look at technology as the lifeblood of their business (along with people, customers, products).

      • Co-rrect. It's been an axiom in IT for years that they should align with and support the business, but the reciprocity is usually not there from the business side of the house. It takes focus and discipline both and with those "promotions, old teams, new teams," etc., that usually doesn't happen.

        Just my tuppence.

  • Legacy contains valuable data..... which is almost certainly duplicated! So what you do is select a platform technology that supports BPM thinking i.e. start with a "green-field" “outside in” approach with the focus on how people create information. This will be a granular step by step exercise recognising all business logic which will include need to use existing data and existing good functional applications.

    The supporting BPM technology will (or should) be able to directly support this approach orchestrating not just the adaptive "green field" system but also the access to legacy as required. This includes MDM content management etc direct to the “new” system or the user interface as required, Do not try and modify legacy just use as required. Over time it will be possible to eliminate duplication and reduce/retire legacy where with careful planning the one version of the truth can be stored within the new agile and adaptive system.

    Do your research seek out that next generation BPM supporting Enterprise Adaptive Software which should result in future proof systems and over time reduce reliance on legacy which will be that valuable store of historical data yet retaining those useful functional applications in context of supporting people at work. It will be an evolutionary approach to minimise disruption but most importantly take your users with you on this journey – it is their process but the knowledge belongs to the business…..

  • I would interpret 'holding-back' as limiting the ability to supply the solutions that the business departments need to deal with a changing marketplace.

    In fact it is not just legacy but also modern BPM or ERP platforms that have the same drawback. Smart Process Apps too are a wired-together conglomerate of products with merged-in vertical process knowledge, creating an ad-hoc legacy solution that defies the needs for change. Most legacy platforms are systems of record and there is little need to change them except if the core business model changes.

    The need for change is strongest in areas of customer experience providing a single view of the customer to the business. Replacing old systems won't give you that integration and even an MDM effort just aligns the underlying data. Keep your HR, ERP, insurance, and banking systems and just interface what you need. Some VERY old systems might not have such interfaces and it might be cheaper to replace them than adding the interfaces.

    You will need a system of engagement that federates all the data and content from the legacy systems and allows the business to collaborate towards the process goals with in a Single View of the Customer. The customer could be an external or an internal one, or it might be a project or a program.

    Only if the business people are able to create and adapt the processes that they want without needing IT, you are not creating new legacy applications.

  • I do not think that there is a major problem with Legacy Systems as "systems of record". I do think that there is a big problem as far as Business Processes are concerned.
    The solutions may vary. In many cases legacy Modernization or Legacy Rejuvenation is the solution.
    Modernization includes SOA. After moving to SOA it is less difficult to change and innovate processes. Sometimes the solution is Migration or replacement of legacy Systems by Developing Applications or by Buying and Adapting Applications.

    Do not expect easy solutions or one size fits all solutions.
    read more: Modernization with SOA the EDS Way http://avirosenthal.blogspot.co.il/2008/06/modernization-with-soa-eds-way1.html

  • I have to agree with Avi, most systems are great as a system of record and it would be quite an undertaking to move that wealth of customer data and functionality. With SOA, it is so much easier to "Wrap and Renew", existing technology with bright and shiny BPM solutions.

    At my current client, a large UK bank, we have agreed a design principle that business and process logic will, over time, be migrated to the new BPM platform. We see this as a safer way of migrating to a new platform giving the business the greater flexibility and agility they need in the future. This effort is split over a number of projects, without the risk of a huge big bang effect.

    The legacy system over time will be come simpler and with logic trimmed back to the principal function of managing customer and product data which, it was originally designed to do.

Add a Reply

Recently Commented On

Monthly Archives