The long journey for legacy application evolution

The CTO of Sungard recently authored this article on Sungard’s technical strategy for its large and diverse portfolio of financial applications:

http://www.bankingtech.com/247292/how-to-build-a-better-sungard/

The technical strategy is shockingly simple on the surface:

  • All products are to provide hosted solutions, and
  • All new products must use HTML5 technology

This (one assumes) reflects the changing nature of how Sungard would like to support its clients – i.e., moving from bespoke shrink-wrapped applications deployed and run in client environments, to providing hosted services that are more accessible and cheaper to deploy and operate.

Executing this strategy will have, I believe, some interesting side effects, as it is quite difficult to meet those to primary objectives without addressing a number of others along the way. For example, the development of key capabilities such as:

  • Elasticity
  • Dev-Ops
  • Mobile
  • Shared Services
  • Messaging/Integration

Elasticity

Simply put, hosted services require elasticity if cost effectiveness is to be achieved. At the very least, the capability to quickly add server capacity to a hosted service is needed, but – especially when multiple hosted services are offered – the ability to reallocate capacity to different services at different times is especially key.

For legacy applications, this can be a challenge to do: most legacy applications are designed to work with a known (ahead of time) configuration of servers, and significant configuration and/or coding work is needed when this changes. There is also a reliance on underlying platforms (e.g., application servers) to themselves be able to move to a truly elastic environment. In the end, some product architectures may be able to do no more than allow products to host a replica of the client’s installation on their data centres, shifting the operational cost from the client to the provider. I suspect that it won’t be long before these products become commercially unviable.

Dev-Ops

Dev-ops is a must-have in a hosted environment – i.e., effective, efficient processes that support robust change from programmer check-in to operational deployment. All SaaS-based firms understand the value of this, and while it’s been talked about a lot in ‘traditional’ organisations, the cultural and organisational changes needed to make it happen are often lagging.

For traditional software vendors in particular, this is a new skill: why worry about dev-ops when all you need to do is publish a new version of your software for your client to configure, test and deploy – probably no more than on a quarterly basis, or even much longer. So a whole new set of capabilities need to be built-up to support a strategy like this.

Mobile

HTML5 is ready-made for mobile. By adopting HTML5 as a standard, application technology stacks will be mobile-ready, across the range of devices, enabling the creation of many products optimised for specific clients or client user groups.

In general, it should not be necessary to develop applications specifically for a particular mobile platform: the kinds of functionality that need to be provided will (in the case of financial services) likely be operational in nature – i.e., workflows or dashboards, etc.

Applications specifically designed to support trading activities may need to be custom-built, but even these should be easier to built on a technology stack that supports HTML5 vs more traditional 2-tier fat client & database architectures.

Traditional 3-tier architectures are obviously easier to migrate to HTML5, but in a large portfolio of (legacy) applications, these may be in a relative minority.

Shared Services

In order to build many more innovative products, new products need to build upon the capabilities of older or existing products – but without creating ‘drag’ (i.e., software complexity) that can slow down and eventually kill the ability to innovate.

The way to do this is with shared services, which all teams recognise and evolve, and who build their products on top of their shared capabilities. Shared services mean better data governance and architectural oversight, to ensure the most appropriate services are identified, and to ensure the design of good APIs and reusable software. Shared services pave the way for applications to consolidate functionality at a portfolio level.

Messaging/Integration

On the face of it, the Sungard strategy doesn’t say anything about messaging or integration: after all, HTML5 is a client GUI technology, and hosted services are (in principle) primarily about infrastructure.

And one could certainly meet those stated objectives without addressing messaging/integration. However, once you start to have hosted services, you can start to interact with clients from a business development perspective on a ‘whole capability’ basis – i.e., offer solutions based on the range of hosted services offered. This will require a degree of interoperability between services predicated primarily on message passing of some sort.

On top of that, with hosted services, connection points into client environments need to be more formally managed: it is untenable (from a cost/efficiency perspective) to have custom interface points for every client, so some standards will be needed.

Messaging/Integration is closely related to shared services (they both are concerned with APIs and message content etc), but are more loosely coupled, as the client should not (to the fullest extent possible) know or care about the technical implementation of the hosted services, and instead focus on message characteristics and behaviour as it relates to their internal platforms.

Conclusion

The two objectives set by Sungard are a reflection of what is both meaningful and achievable for a firm with a portfolio of its size and complexity. Products that choose to adopt the directives to the letter will eventually find they have no strategic future.

Product owners, on the other hand, that understand where the CTO is really trying to get to, will thrive and survive in an environment where legacy financial applications – feature-rich as they are – are at risk of being outed by new internet-based firms that are able to leverage the best of the latest technologies and practices to scale and take market share very quickly from traditional vendors.

Portfolio owners on the buy-side (i.e., financial service firms) should take note. A similar simply stated strategy may be all that is needed to get the ball rolling.

Advertisements
The long journey for legacy application evolution

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s