We recently did some work with one of the UK’s largest building societies and banks. Their challenge was to update a legacy system that was used to allow account transfers between other UK banks.
A system to permit such account transfers was introduced in 2013. Each bank that participates has a common interface so that bank account holders have a straightforward means of migrating from one bank to another. This is similar to the way that mobile phone and broadband services can be moved from one provider to another.
While this is simple for the end user (or is intended to be), the backend technology required to make it happen is rather more complex.
Each bank has its own internal way of dealing with such requests. In the case of our client, their system was based on Windows AppFabric. This is a collection of services all talking to each other and running on Windows Server.
AppFabric hosts workflows, unifying technologies such as Internet Information Services (IIS), Workflow Foundation (WF) and Windows Communication Foundation (WCF).
The bank’s existing application was large (200+ workflows) and took a year to develop.
The problem
Though the bank’s system was functional, it relied on Windows AppFabric, which was deprecated in 2015 and moved out of extended support in April 2022.
All Windows AppFabric technologies ran under .NET Framework, which is no longer being extended (.NET Framework 4.8 being the last official version) and is now being gradually phased out. Microsoft is porting many, but not all, of the core libraries to .NET Core (currently .NET 6).
WCF (a SOAP technology) is still fully supported in .NET framework 4.8 and partially in .NET Core. Support for hosting WCF services is not officially supported and even consumption of existing services is not to the full WS.* standard which WCF is based on.
Workflow Foundation is still supported in .NET framework 4.8 but not going to be officially ported to .NET Core.
Microsoft now has other, newer workflow technologies such as LogicApps and Azure functions, but there is no direct migration path to these and there are many detail differences in the capabilities offered.
In short, every service provider using Windows AppFabric is now impacted because it’s out of support and there is no direct migration path available.
The task
We were engaged to review the way the current system worked and to look for the optimal way of moving from the deprecated AppFabric system to an alternative setup that would be supported.
We knew that the bank had a lot of valuable business logic tied up in its existing system. Our job was to preserve as much of this while separating it from the workflow logic. It’s this workflow logic – what we think of as the “engine” – that we needed to rehouse with new tech.
The aim of this part of the project was to produce a proof of concept (PoC) to achieve this separation as efficiently as possible while avoiding the need for a total redesign and implementation, which would take a lot of time and money to implement.
An essential requirement is for the bank’s system to support the persistence, restartability and replayability of workflow actions especially if they are long running and asynchronous.
In simple terms, when transferring a bank balance as part of the switch, for example, the banks would need to be sure that the old account is being correctly debited and the new one correctly credited.
In the event of a system failure, the bank would need to be confident of restarting from the same place, to avoid duplication. This is essential to prevent double crediting and double debiting of accounts. In practice this type of challenge occurs many times in any long running workflow system.
This means any solution would require a system that would offer atomic actions. The existing system running on AppFabric provides this out of the box and was durable, so any suggestion for replacement would need to offer parity with this.
Findings and solutions
The deliverable so far has been a PoC, relating to the hundreds of thousands of lines of code across the original project.
One of the key findings was that we were able to extract more value than expected from the business logic in the existing application.
This confirmed to us that trying to reinvent the wheel would have been a bad idea. Instead, we can focus on which parts of the engine we can provide ourselves, while keeping that business value in the business logic already present.
A couple of different options were considered.
- Low Code: The bank could move to Low Code like LogicApps or Azure Functions. However, this would require rearchitecting the whole application.
- Microservices: The bank could use microservices to handle each workflow. This would allow them to retain process chronology. Again, this would require rearchitecting the whole application and the existing solution was already well architected and provided separation between each of the many workflows.
Potential future
Although the bank has decided not to move to the cloud for this system just yet, the new architecture proposed in the PoC means that the system could be migrated to the cloud in the future.
This is because it moves the technical solution to a modern stack that can be both containerised and virtualised.
Have you invested in Windows AppFabric? There is probably value in your code base that we can extract. Starting again may not be necessary. If you’re unsure about whether to wait or to invest in updating your systems, drop us a line and let’s have a chat.