How governments can generate mainframe savings and delight users by "freeing their data"

Make the most of your mainframe and data with an application speed layer

illustration-currency-value-scale-1680x980-midnight.png

Governments around the globe are looking for ways to balance books while also answering the call to improve citizen engagement and trust through enhanced digital service delivery. But how can they achieve both? 

A proven way to quickly reduce cost and increase customer experience is to add an application speed layer between user-facing systems and mainframe applications. Using this approach could potentially save millions of dollars.

We see financial institutions leveraging this approach to drive down costs and enhance the user experience. Royal Bank of Canada, for example, estimates a cost savings of C$2.4 million per year just in mainframe transaction (MIPS) fees. In addition, once in place, this capability allows services to deliver greater value through enhanced user experience. As a result, Royal Bank of Canada’s applications have become more responsive and can provide front-line staff with more relevant information faster.

We will examine how this pattern delivers value and why using Elastic provides the point of differentiation to make additional benefits possible.

Why create an application speed layer?

Studies done by customer-facing teams provide valuable insights to governments. For instance, Barclays Bank found that 85% of traffic from its top 25 transactions was read-only; Royal Canadian Bank showed a similar number at 80%. 

Think about your own experience when using a digital government service. Once you log on, the system presents you with information about yourself, the services available to you, the list of your subscribed services, and an inbox of messages sent to you. These initial interactions are almost exclusively read-only. It is not hard to imagine that the 80/20 ratio for read/write transactions equally applies to government-delivered services.

This 80/20 read/write ratio, combined with the need for faster and more optimized services, is why the speed layer pattern exists.  

How to implement the application speed layer

The mainframe still does what it does best: highly resilient transaction processing. As illustrated below, we inject a data layer between the mainframe and the end-user application, responsible for serving data to your users. It is crucial that you choose a highly scalable and performant data access layer for read transactions.

The benefits this model delivers are:

  • Reduced operational costs in MIPS savings by easing mainframe load. Read interactions can be simple single record lookups with minimal load impact. More often than not, they are complex queries, requiring historical data assembled from multiple tables with an extra processing burden. Offloading this to Elastic reduces this processing overhead, speeds up data access and delivery, and creates a more predictable system profile, as with Royal Bank of Canada.
  • Increased user satisfaction and decreased interaction costs. The performance improvement gained from an application speed layer often delivers a step change in improved user experience. For example, Rabobank could only provide customers with 16 months’ transaction data for a single account served directly from its core banking system. If customers wanted more information than that, they were required to head into a branch. Now, with Elastic, Rabobank can provide eight years’ worth of transaction data across hundreds of accounts digitally, increasing customer satisfaction and reducing transaction costs.
  • Increased developer productivity and agility. The team at Royal Bank of Canada used the term “freeing our data” to express the potential value Elastic created from its data. The product teams could innovate and respond faster using Elastic APIs and real-time analytics capabilities than they previously could when tied to the mainframe.
  • Increased predictability, adaptability, and flexibility. Elastic provides a distributed data store that scales with your data. Service delivery teams can manage peak demands predictably due to the distributed-by-design architecture of Elastic. For example, it provides the flexibility to move data closer to the user using geo-replication to support genuinely global use cases.

Search combined with real-time analytics gives you the edge

Previously, we looked at some of the generic benefits of the application speed layer pattern. Elastic provides some unique points of differentiation, powered by search to deal with massive data sets combined with real-time analytics. 

What does that mean? 

You get relevant results faster when querying across massive unstructured and structured data sets. You quickly fuse and ingest new data sets using connectors and drive insights from all the data within seconds of ingesting. It means you no longer have to wait until tomorrow to answer yesterday's questions.

Uber, for example, uses real-time analytics and machine learning powered by search to drive insights across structured, unstructured, and geospatial data at a global scale. Similarly, BlackSky makes structured, unstructured, and geospatial data accessible to business users and analysts to deliver strategic, operational, and tactical insights using a single platform.

There are some quick wins that you should consider after implementing our application speed layer model:

  • Provide search to increase user satisfaction. Elastic provides an intuitive search experience that will quickly surface results to user queries. You will have happier users and also possibly reduce the load on your brick-and-mortar workforce, as the Rabobank example illustrated. 
  • Use real-time analytics to derive user behavior and experience insights. Emirates NBD and UK Digital Tax Platform are examples of organizations that used transaction logs and machine learning to help gain insights into user behavior to inform innovation and service development. 
  • Store data in a way that is queryable and accessible for long-term cyber forensics for more secure transactions and compliance. A European police force is quoted as saying it can store 10x more data than with its previous tooling.

With your data now free, what else can you do?

Organizations that start this journey with Elastic come for cost savings but stay for faster insights and a platform for innovation.

You do not have to stop with the low hanging fruit. Innovation happens when you remove friction. Elastic's APIs, data exploration, and ability to correlate across large volumes of data open up unique possibilities.

This ability to fuse different data sources, as illustrated above, and then apply search and real-time analytics makes it possible to: 

  • Deliver personalized service delivery and "Know Your Customer" initiatives. Customized service delivery is a growing trend in government, where we are having conversations about enabling multi-agency services to simplify the user experience. Examples include entity resolution and matching, eligibility assessments for grants, tax assessments, and border risk assessments for passengers and goods.
  • Strengthen fraud prevention and detection capabilities. Effective fraud prevention requires a single view of customer information and interactions on a real-time platform. The speed and scale that Elastic delivers made it an excellent choice for organizations like PSCU, which prevented US$35 million in fraud over 18 months. By preventing fraud, PSCU avoided costly recovery processes. For governments looking to build and keep citizen trust, getting this right while providing assistance to the right people and preventing untoward behavior is critical.
  • Develop a data abstraction layer for inter-agency for federated data sharing and machinery of government changes while applying strict security attribute-based access control.

The application speed layer pattern started with the mainframe to reduce costs and increase single-use case customer interactions. But if you choose the right platform and bring in data from other core systems, you can quickly build on that to realize even more service delivery and cost benefits. 

Where should you start?

Start by looking at applications that depend on the mainframe or other core systems for data. The following questions will help:

  • Do you have user and customer facing services struggling to scale and perform during peak times? Or do you require a lot of planning and effort to ensure the scale of the services? If yes, what is the cost of outages and the current attempt to scale?
  • Is the agility of your user and customer facing services hampered by interactions with core systems? 
  • Can you change systems fast enough with low risk to respond to user requirements? 
  • Are you running mainframe modernization initiatives, and are you realizing the benefits? If not, why not? Would this pattern provide a lower-risk approach?
  • Do you have multiple user-facing systems that use a single traditional data store to read or write data?

These questions will help you prioritize a list of services with congestion points with information on the business impact of solving them. In particular, capture the most impacted user interactions and prioritize them. The next stage would be a proof of concept; this type of innovation can be done quickly, with minimal risk and an immediately visible impact.

Questions?

Feel free to reach out to the Elastic Public Sector team. We would love to help you "free your data."