Your “New” Digital Systems are Now the New Legacy Systems…

  • February 22, 2018
  • Scott
  • 2 Comments

The Old Legacy

Once upon a time, Legacy software was simple: it was that stuff on a green screen.

More recently, the legacy systems were still pretty clear. Legacy was the old stuff:

  • Mainframe systems with green screens (true story, these were cutting edge software systems back in the day) – let’s throw AS/400 and the like in there as well.
  • “Departmental software” like Infopath, Sharepoint, and Lotus Notes.  I am old enough to remember how remarkable it was to have synchronizing user-defined local databases with usable interfaces – Notes – running on a laptop with 8 MB – not GB – of RAM – it was amazing – 20+ years ago.  But now, most firms would refer to it as part of their legacy portfolio.
  • On-premise custom applications built in VB or Java or even intranet-oriented web apps.
  • COTS (Commercially-available Off The Shelf) applications that didn’t evolve with the times.
  • ERP systems and Financial systems from the big “integrated” software vendors.

The New Digital Systems

And over the last decade, many businesses have invested in platforms to digitize their business – addressing the parts of their business the old legacy systems didn’t:

  • SaaS CRM platforms, to digitize their CRM and sales data
  • SaaS ITSM platforms, to digitize internal IT management.
  • SaaS Marketing automation/management systems
  • SaaS Social Media Management
  • New mobile apps for consumers
  • New digital experiences on the web

And the truth is, a lot of these new “digital” systems that we’ve bought and deployed over the last ten years are now our new legacy systems. Worse yet, that system we just finished rolling out may be legacy already. 

The New Legacy Systems? And Business As Usual

Legacy isn’t how old the software is, legacy is friction.  Legacy is holding us back from your objective and goals.  Legacy is slowing you down when we need speed.  Legacy systems have their budgets cut because they’re considered a cost-center.

Age may be correlated with legacy – the older a system is the more likely it is to have become a source of friction rather than enablement in our business.  But an older system – properly reinvested in – continues to be relevant and a driver of success in our business for years to come.

Non-legacy systems support our goals, objectives and imperatives. Non-legacy systems are vital to our future, rather than our past.  Non-legacy systems are what we invest in for the future.  If these new digital systems are driving your future, rather than creating friction, then congratulations!

That shift from greasing the skids of your business to being sand in the gears can be a harsh reality for all of us that believe in investing in tech.  No one wants to see that happen to the systems that they have embedded into their operations and organizations.  No one wants to see their systems ossify from neglect.

But neglect is exactly what happens when we move things into a “BAU” (Business As Usual) operation.  It is the natural outcome of moving all of the ongoing work to a new team that has never seen any of the code – and calling it “maintenance”.  And that’s what happens when we squeeze the budget for enhancing a system year after year until there’s nothing left to spare.  It is news to some, but in most organizations, the word “maintenance” means that the application will not be kept current with changing business needs – only explicit defects will be addressed.  And that’s not good enough over time.

Right now, if we’re building systems in-house that we don’t see as critical to our business, we’re likely building new legacy systems.

There has to be a Better Way

There has to be a better way.   How do we achieve these non-legacy systems, how do we make them evergreen? The answer is to think about these systems more like perennials.  Every year we have to invest to keep these systems relevant to our new business imperatives and conditions.

For Mission-Critical Systems, how do we build perennial systems?

  • Make sure we leverage a platform that has the agility to adapt as our business adapts.  We don’t want to re-write our mission-critical apps from scratch every few years. Nor do we want to be stuck with a static application as our market and business change rapidly around us.
  • Make sure our platform and anything we build on it, has a good set of APIs.  Simple and complete coverage is better than highly-specific and incomplete coverage.
  • Make sure that platform modernization is someone’s core business – ours or another vendor’s.
  • Design assuming change will happen
  • Keep investing in our critical systems.  Note: shipping these duties to offshore maintenance contracts that focus on minimizing cost-per-head is not how we “keep investing in our systems”.  This isn’t a labor arbitrage opportunity, no matter what investors or finance folks tell us.

For Non-Mission-Critical Systems, how do we build perennial systems?

  •  One idea is to build these apps with a partner, who may see the applications as their core business (note, this is exactly what we are doing when we put our CRM system in Salesforce’s hands for example, we are letting it be someone else’s  core business to build CRM systems, rather than ours): 
    • First, find a partner for whom that application will be mission critical to their business.
    • Second, set up conditions for success that align with our organizations goals and imperatives – and align our partner with those conditions.
    • If we can, find a partner who makes it part of their core business
  • Design for future replacement:
    • Keep selecting platforms built for agility.  Make sure these systems leverage prescribed methods of integration to our legacy and non-legacy digital systems-  APIs or via RPA for example.
    • Make sure we have access to all of the data in the applications and that exporting that data isn’t difficult and comes in a format that we’re happy with. (Or that its native storage format is already a good “externally available” format, such as a well-designed database or Elastic Search schema).

If our business depends upon Salesforce or ServiceNow, a BPM Suite, an ECM suite, an Application platform, or one of the many SaaS systems out there – good news: these systems generally have reasonable APIs that will let us include them in broader views of our company’s people, processes, and systems.  We’ve likely picked vendors that will keep investing in the platforms because those systems are their core business.

Just realize that the job isn’t done after these systems go into production for your business – the work is likely just beginning – because we want these systems to be perennials – adding increasing value every year to our business.

The truth is, the fight against becoming legacy is ongoing. The world isn’t standing still for us, or our new systems.

Related Posts
  • October 24, 2018
  • Scott
  • 0 Comments

A recent Deloitte report (reported here by Artificial Lawyer) has some encouraging details about RPA: A new r...

  • October 17, 2018
  • Scott
  • 0 Comments

There's more than one way to build a UI for process. At BP3 we always look at simplifying and speeding up the ...

  • October 3, 2018
  • Scott
  • 0 Comments

Horses for Sources is a great read for those of us in enterprise tech.  A recent article in particular takes ...