Slalom is a leading, purpose-driven company that helps organizations use technology to address business problems and build for the future.
“Building for the future” often involves integrating with the legacy systems of the past. And the more entrenched those legacy systems are in your core business processes, the more likely you’ll need to adopt an iterative legacy modernization strategy that results in your data straddling two worlds, both legacy and the future.
The Open Group Architecture Framework (TOGAF) calls this a transition architecture, which is a fancy way of acknowledging what the industry has learned over decades of big-bang, cut-over approaches. HINT: They don’t work (very well).
Legacy Modernization and Publish/Subscribe Architectures
If only there was an architecture that helped us hide system-specific data models and behaviors between legacy and future IT systems. What if this architecture also allowed us to broadcast the same business event, whether it originated in a legacy system or using a future technology. And what if it also ensured everyone’s data store was updated appropriately with the same information they’re used to receiving, effectively hiding the introduction of the future system?
Ok, we’re getting ahead of ourselves a bit. Let’s start by defining what we mean by publish/subscribe architecture.
A publish/subscribe architecture is built upon four major features: a “publisher” (1) that performs the work of detecting changes in a source system (or systems, particularly important for our legacy modernization use case).
It then publishing the change to a channel (2) or “message bus” where “subscribers” (3) can pick up the change and react appropriately for the application(s) they represent.
A publish/subscribe architecture also provides a “canonical” data model (4) that abstracts away application-specific data models and provides a common language across those subscribers.
Migrating to Salesforce From Legacy Systems
What does a typical legacy modernization plan look like if we’re migrating from a legacy system to Salesforce.
If the legacy platform is not integrated with anything, it’s a relatively painless data migration, combined with some organizational change management to retrain folks on the new Salesforce platform. No sweat, right?
But how likely is it your legacy platform doesn’t have existing integration dependencies? The answer is not very likely at all. And this is where the complexity comes in. Now we must figure out how to introduce a new system of record, while not disrupting existing downstream dependencies long enough to complete the transition from legacy to new.
This is where publish/subscribe can be a useful tool in our toolkit. Imagine if we could have both legacy platform and Salesforce together, side by side in the (transition) architecture. We could define a canonical data model that abstracted away system-specific data models for objects like leads, contacts and accounts.
We could also build a publisher that detected changes from Salesforce and mapped the message into our canonical format. And we could publish that message to a message bus, where it could be picked up by multiple subscribers. The bus would act on behalf of the dependent systems, transforming the message to a format they understand and taking the appropriate actions. These subscribing systems don’t have to know where the message originated from.
This is in a nutshell how we can use a publish/subscribe architecture to bridge old to new.
To be fair, this pattern introduces its own set of challenges in a transition architecture. The biggest challenge is how to avoid duplicate processing in the case where a subscriber sends data back to the publisher. There are other strategies to solve this problem that are a potential topic for a future blog post. Suffice to say, these are easier problems to solve than trying to plan a big-bang cutover.
A side benefit of this architecture pattern is with standardized data interfaces. Enterprises are spared the complexity and cost of traditional time-consuming integration projects. New applications can become subscribers without developers needing to build both sides of a new integration.
And if the publish/subscribe model is built using a modern, low-code platform, the time and cost savings are even larger.
Reducing the number of complex, custom point-to-point integrations improves the reliability of the enterprise’s integrations. If data objects in a legacy application change, the published data feed isn’t necessarily affected. By design, it publishes only the select data requested by subscribers.
Using legacy modernization and publish/subscribe designs, Slalom is helping enterprises in a wide range of markets integrate legacy applications with Salesforce using Boomi. We’re helping them make the most of both their new and old applications. Together with Boomi, we help our clients use Salesforce to serve as an information hub for customer data other critical information.
Legacy Modernization in Action: Helping SightLife Migrate to Salesforce
To more fully appreciate the benefits of the publish/subscribe model, let’s consider a recent integration project Slalom carried out in the healthcare market. The key technologies were the Salesforce and Boomi low-code, native-cloud platforms.
SightLife is a nonprofit, global health organization focused on eliminating corneal blindness by 2040. The company and its for-profit subsidiary, SightLife Surgical, are the largest providers of corneas for transplant in the world.
To fulfill its mission, SightLife works with hospitals, donor families, surgeons and patients. It helps hospitals and surgeons find matches for patients.
Cornea matches are complex and difficult. Data and data integration make this work possible. Surgeons register and can search cornea banks around the world to find a cornea with the characteristics they need for a patient.
As in so many areas of healthcare, time matters when it comes to cornea transplants. If registration is slow or if donor data is out of date, transplant opportunities may be missed and transplant efforts can suffer.
SightLife had been using an eye-transplant management application and a custom data warehouse to organize its surgeon registration and donor material records. The warehouse received batch updates daily.
But batch updates turned out to be too slow and unreliable, often taking more than 48 hours to sync information. Surgeons were unable to register quickly, and data in the data warehouse was often out of date.
To address these problems, SightLife turned to Slalom, which helped with a native-cloud application architecture using Salesforce and Boomi. Instead of relying on overnight batch processes, the application uses a publish/subscribe model that keeps data up-to-date. It also improves data quality.
Now surgeons can register quickly and focus on their search for a donor match, knowing that the search data is complete and up-to-date. Some tasks that use to take more than 24 hours now take only a few minutes. The publish/subscribe model and its data objects are now part of the company’s infrastructure.
SightLife is also preparing to migrate from its old transplant management application to NetSuite. The transition is expected to go smoothly, thanks to the integration architecture driven by Boomi. Slalom also built out various Salesforce processes that SightLife can easily extend as it rolls out the Netsuite platform.
Now SightLife has the application and data integration infrastructure it needs to ensure its vital services can help more patients around the world regain their vision.
About the Author Shane Fisher is a solution principal with Slalom. Slalom is a Boomi partner specializing in helping organizations drive digital transformation and build for the future.