SAP for Public Sector Blogs
Read and write blog posts showcasing creative initiatives, technology advancements, and success stories in public sector transformation powered by SAP.
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member188577
Participant

Introduction

The Social Protection industry aims to reduce poverty and vulnerability by promoting efficient labour markets, diminishing people’s exposure to economic and social risks such as unemployment, exclusion, sickness, disability and old age, and enhancing their capacity to manage these risks. Unfortunately the service delivery practices of many Social Protection agencies are encumbered by layers of legacy applications and platforms, built up over years (even decades) of bespoke development and point solutions. Legacy modernisation is essential to enable agencies to realise the potential of digital government, including support for low-touch, real-time service delivery models. The challenges for agencies are where to start and how to minimise/mitigate risk in their digital transformation program. This paper presents a start anywhere, go everywhere approach to digital transformation for Social Protection agencies and illustrates how this approach can be enabled by SAP for Social Protection capabilities and technologies.

Legacy modernisation approaches

There are three alternative approaches to incremental modernisation of legacy applications and platforms: backend consolidation; program transformation; and frontend modernisation.

              

There is actually nothing new here, and experience has shown that no single approach is superior in all circumstances. In practice, it is most common for Social Protection agencies to adopt a hybrid strategy, combining two (or even all three) of the above approaches in parallel to minimise the overall time spent in the painful and costly transition period.

But wherever an agency might choose to start in their digital transformation program, eventually all three aspects will need to be addressed to achieve the ultimate objective of legacy replacement. Indeed, the business cases for such programs are almost always based on the promise of future savings from retiring costly legacy applications and platforms. In reality however, most fall short of this central objective due to a failure to address one aspect in particular – backend consolidation.

Backend consolidation

A common desire of Social Protection agencies is to provide business users with a single view of customer. More often than not, customer data is distributed and duplicated across multiple legacy applications, making it difficult to find customer records and to know whether similar records in different applications refer to the same or different customers. This can result in a myriad of issues for Social Protection agencies, including partial update of customer circumstance data and duplicate payments being made to a single customer. These problems can be reduced by implementing federated search, data indexes, integrated frontends, etc., but backend data integration is the only permanent solution.

Another common desire of Social Protection agencies is to provide business users with a single application platform. It is not unusual for agency case workers to have to switch between multiple legacy applications to complete a single transaction. Beyond the obvious impact to efficiency, it can be difficult to orchestrate a process across distributed platforms and there are significant costs associated with training users in multiple applications. Single sign-on, workflow automation and other strategies may reduce the extent of these issues, but backend consolidation is the only real way of delivering a single application platform.

It is important to note that backend consolidation strategies are by definition enterprise-level initiatives and therefore require enterprise-level funding. This can be a challenge for Social Protection agencies that have traditionally been funded at the program-level. Another inherent challenge with this approach is that the impact is at the backend, where return on investment may not be visible to customers, business users or government stakeholders. So while starting legacy modernisation with backend consolidation is the most sensible approach from an architectural perspective, the delayed time to value of this approach can make it difficult to sell to the business.

Of course, retirement of legacy applications and platforms can only be achieved when the digital transformation program includes backend consolidation. But all too often this aspect is deferred to the later – or even final – stages of the program, on the premise that the agency will (somehow) be able to ramp-up to tackling this challenge through the experience it will gain through program transformation and frontend modernisation activities. In practice however, many things may change during the course of a multi-year program – budgets could be reduced or reallocated; a new government with a different agenda could be elected; the program itself could experience cost overruns; etc. Any of these could result in the agency never getting around to consolidating the backend and ending up with the legacy-retention anti-pattern, which will be prohibitively expensive to maintain. So while it is possible to start anywhere in the digital transformation program, where the business case has been built on the promise of future savings, it is risky to delay backend consolidation.

Program transformation

In contrast with backend consolidation strategies, program-level initiatives typically have the fastest time to value as a result of their singular focus. This siloed approach is perhaps the most traditional, since it is a hallmark of the locally directed, single program agencies of the 20th Century, which have largely been amalgamated into today’s meta-agencies. Nevertheless, so long as funding within these meta-agencies continues to be controlled at the program-level, siloed projects will continue to be commonplace. It bears noting that program-level initiatives may include limited modernisation of legacy presentation and data layers, but what distinguishes this approach is that the project scope is defined by the target program.

Often what drives program transformation strategies is the need to be responsive to government initiatives, including changes in social policy. Governments increasingly have a desire for dynamic social programs, directing social policy initiatives to assist target cohorts and adjusting the levers of social policy in response to rapidly changing economic conditions. All too often, legacy ICT platforms encumber social policy initiatives by restricting what and how quickly something can be achieved. It is therefore sometimes necessary for an individual line of business to assume project control in order to deliver a high priority program-level initiative in the required timeframe. This works particularly well for large, well-funded lines of business that have sufficient resources to operate somewhat autonomously to transform their own programs.

That said, transformation of individual programs will only contribute to the overall legacy modernisation objective when they are implemented in accordance with the target enterprise architecture. Strong top-down governance is required to avoid an autonomous project creating the siloed-application anti-pattern, which will forevermore require separate maintenance and support. This governance needs to go beyond traditional Enterprise Architecture constructs, to incorporate a Design Authority with the ability to review proposed application designs at a level of detail and the authority to reject designs that do not comply with the target enterprise architecture.

As a consequence of the above, program transformation without backend consolidation will almost always be the most costly strategy in the long run. This is because each project bears the overhead of data and application integration, rather than distributing the cost across the enterprise. And with each new program deployed the cost of such integration multiplies – eventually to the point that cross-program changes become prohibitively expensive. So while it may be necessary to implement a high priority program-level initiative at the outset, continual program transformation without backend consolidation is not a sustainable legacy modernisation strategy – it’s actually just business as usual.

Frontend modernisation

Frontend modernisation strategies are often adopted as a quick fix to the issues outlined with program transformation and backend consolidation strategies. This is chiefly because it is possible to deploy a modern presentation layer on top of legacy application and data platforms quickly and relatively cheaply. Further, the output of frontend modernisation will be highly visible to customers, business users and government stakeholders, making it easier to justify the required investment.

In the case of customer facing applications, frontend modernisation can deliver an improved user experience (UX) and increased customer engagement. These outcomes are key to empowering customers to help themselves through self-service, thereby enabling Social Protection agencies to reduce call centre waiting times and shorten queues at government shop fronts. Another driver is that today’s digitally empowered citizens expect to access government services quickly and conveniently, at times and in ways that suit them. This expectation is prompting governments to adopt digital by default service delivery models, with due consideration for availability, performance, accessibility and omni-channel UX capabilities.

It should be noted that many of today’s functionally rich UX technologies include data stores in the presentation layer, introducing yet another copy of customer circumstance data that needs to be managed. Where there is data persisted in the presentation layer that is not mastered in the backend, the presentation-data anti-pattern has the potential to erode the benefits of backend consolidation. It is therefore imperative that any data captured in the frontend be persisted in the backend and that the backend maintains its rightful position as the source of truth for all data – even if a copy is retained in the frontend data store.

A final consideration when starting with frontend modernisation, is that a modern presentation layer will tend to hide the underlying ICT problem from business and government stakeholders. This can make it difficult to maintain the momentum and funding of a legacy modernisation program after the new UX is deployed. So again, while it is possible to start anywhere in the digital transformation program, consideration needs to be given upfront to the backend consolidation strategy and enterprise-level data management principles need to be enforced by an empowered Design Authority.

Hybrid approaches

Hybrid approaches seek to balance delivery of priority outcomes with the longer term objectives of a legacy modernisation program. There are four possible permutations of the three legacy modernisation approaches, all of which can be viable depending on the circumstance…

The combination of backend consolidation and frontend modernisation is the most strategic approach from a purely architectural perspective. This approach creates an application framework that can be used to rapidly deploy social programs, so will potentially be the most cost effective in the long run.

The combination of program transformation and frontend modernisation is the most responsive to the needs of customers, business users and government stakeholders alike. This approach may be particularly suited to Social Protection agencies with a legacy backend platform that continues to serve their needs, but that has an outdated interface for customers and business users.

The combinationof backend consolidation and program transformation is appropriate when the objective is to deliver an integrated service delivery platform. This may include government-as-a-platform initiatives, where commercial organisations and other government agencies connect their own frontend to the provided platform services.

The combination of all three approaches in parallel is certainly the most ambitious and is akin to a big bang cutover. This approach may be adopted by large Social Protection agencies to implement sweeping reform initiatives, or by smaller agencies with a need for wholesale replacement of their legacy ICT platform.

In addition to the aforementioned benefits, hybrid approaches can reduce the overall time spent in the painful and costly transition period between legacy and target platforms. This significant benefit stems from the ability to apply separate teams to work on the distinct layers of the architecture in parallel. These teams may also be specialised in particular solution areas (UX for example) or program aspects (data migration for example), which may further improve efficiency.

Enabling SAP capabilities and technologies

More than any other enterprise software vendor, SAP has the capabilities and technologies to enable Social Protection agencies to start anywhere, go everywhere in their digital transformation program. Unlike monolithic applications, SAP’s modular architecture facilitates incremental modernisation in line with business priorities. And unlike pure CRM solutions, SAP for Social Protection offers an end-to-end platform that provides the opportunity for wholesale legacy replacement.

SAP’s approach is aligned to the principles of Service-Oriented Architecture (SOA), promoting flexibility and reuse through standard interfaces and loose coupling. Business-level interoperability is enabled through process orchestration, while technical integration is possible via SAP, industry standard and open standards technologies (including OData, RFC, SOAP, JMS and JDBC).

SAP for Social Protection components can be aligned to the aforementioned legacy modernisation strategies (or combinations of those strategies) as follows…

Backend consolidation:

  • SAP Master Data Management – A master data management solution for consolidating and synchronising data across heterogeneous systems. This component can be applied to consolidate circumstance data across programs, thereby delivering a single view of customer.
  • SAP Replication Server – A solution for data integration and synchronisation, including real-time replication to SAP HANA. This component can be applied to enable a side car co-deployment model, thereby eliminating disruptive data replication.

Program transformation:

  • SAP Social Service Management – An industry solution built on SAP CRM and ERP, supporting the automation of Social Protection transactions from application to determination. This component can be applied to support integrated case management across social programs.
  • SAP Decision Service Management – A framework for externalisation of business rules, including rules for eligibility and entitlement determination. This component can be applied to separate rules from code in support of dynamic social programs.

Frontend modernisation:

  • SAP hybris – A platform enabling cross-channel customer engagement, incorporating master data management, product content management, application orchestration and mobile engagement. This component can be applied to deliver a personalised user experience for customers.
  • SAP Fiori – The new UX for SAP solutions, built using SAP UI5 and designed to be role-based, responsive, simple, coherent and delightful. This component can be applied to deliver a consistent user experience for business users working across multiple social programs.

Between these and other components, SAP Process Orchestration enables automation and optimisation of intra- and inter-agency processes. The solution spans from simple workflows, through to integrated processes that cross application, organisation and geographic boundaries. The capabilities of SAP Process Orchestration extend to:

  • Orchestration of SAP services (internal workflows);
  • Orchestration between SAP and third party applications;
  • The ability to define event, time-bound or message-dependency based workflow processes;
  • The ability to monitor, log and trace messages and resend if necessary; and
  • Support for a variety of message patterns (request-reply, request-delayed reply, fire-and-forget, synchronous and asynchronous).

SAP Process Orchestration is delivered using the following SAP products:

  • SAP Business Process Management (BPM) – A configurable tool for modelling and managing business processes, enabling business and IT professionals to jointly compose executable processes using standard notation.
  • SAP Process Integration (PI) – A configurable tool to choreograph the exchange of data between application components, enabling orchestration of business processes across system, organisation and geographical boundaries (as illustrated).
  • SAP Business Rules Management (BRM) – A configurable tool for composing, externalising and managing business rules that support workflow automation.

SAP for Social Protection also offers a target platform for legacy modernisation – SAP HANA. While perhaps best known as an in-memory data platform, SAP HANA has also been designed to serve as a development platform for real-time applications.

SAP HANA capabilities include:

  • Application Platform Services – The application platform services contained within SAP HANA simplify the development of real-time applications with a scalable web server, business rules and user interface library.
  • Integration and Data Virtualisation Services – High volume data replication, event stream processing and smart data access enable real-time applications with high speed data provisioning for faster response and interactivity.
  • Database and Data Processing Services – SAP HANA unifies end-to-end data processing with search, text, geospatial and predictive analytics on top of the in-memory columnar foundation, extending the benefit of redundancy and latency elimination to all data processing workloads.

Conclusion

Legacy modernisation is a foundational enabler of a digital government strategy and there are several viable approaches to achieving this objective. Whatever approach might be determined to be the most appropriate in a given circumstance, what is needed is a target platform that is both flexible enough to enable the agency to start anywhere and comprehensive enough to enable the agency to go everywhere in its legacy modernisation program. In particular, this includes the ability to address the challenges associated with backend consolidation, which is the key to legacy retirement and future savings. SAP for Social Protection provides such a platform.

Top kudoed authors