Reference data: How you doin’?
The Central Perk of Enterprise Applications
The one where enterprises are Chandler.
“When I first meet somebody it’s mostly panic, anxiety and a great deal of sweating” said Chandler Bing.
Most men start off as Chandlers — awkward around women, desperate to interact with others, and interesting, so does the enterprise. The first tech stack of most enterprises (aka greenfield implementations) are bound by the limitations of time as there is a hurry to go-live as soon as possible. Such enterprises fear the process of getting a best of breed systems landscape, and in the end, settle for a monolith core that handles everything (read: Janice). While the purpose is met initially, as the enterprise grows, the monolith doesn’t cater to all its requirements. Getting out of this is painful, and if enterprises may simply be chicken enough to make the difficult decision of separating themselves from the monolith. In the TV series, Chandler has to fly to Yemen to break up with Janice.
The one where everyone wants to be Joey.
Every enterprise quickly yearns to have a best-of-breed set of applications, each catering to their specific purpose. They dream of being agile and interoperable, where adding and removing applications are as easy as can be. They want these applications to seamlessly co-exist without getting treading on each other’s toes; that helps the enterprise fulfil its true potential. It allows them to live with their quirks, yet be the favourite of in the crowd.
The one where most end up being Ross.
Sadly, not all wishes come true. While the ambition is high, the execution sometimes is so poor that these applications end up tied to one another in a complex, muddled spaghetti of interactions, such that the enterprise often finds itself in trouble when it needs to replace one application with another. Over time, they get married to their bad decisions and have to go through the painful process of divorce to finally move on. Worse, the enterprise chaos is so terrible that even after moving on, their thoughts are still filled with that of their previous applications as they haven’t truly put them out of the mix.
On paper, every application starts as an independent system. As they grow along, they start to interact with other applications, sharing data and wardrobes alike. However, these applications never intended to and were never designed to, behave this way, yet they somehow end ou getting coupled together, and moving in without even realising it. By the next major release, these applications would send out holiday cards together for all you know.
Imagine three applications, handling data related to loans, cards and customers, respectively. When the customer’s self-service mobile app requests for a 360-view with a mobile-number, many poorly designed enterprise architectures — with good intentions of sending out a quick response — move data that is unnatural to applications that shouldn’t have it. For instance, loan and card information in the customer systems. This makes all three applications grid-locked, and any attempt to replace any of these applications is exhausting in this spaghetti of relationships that are complex to manage.
The one how Chandler became Ross.
In the above example, customer contact information inside card and loan applications are corrupt data.
These data should ideally be kept outside of these systems. The contact information should only be maintained in the customer application. When the online channel request with mobile-number, the customer-number to be retrieved from customer application and the loan and card details to be pulled out and stitched to give a 360-view through an Integration layer.
The one where Chandler can become Joey.
Joey doesn’t share food. But he gets to eat everyone’s data.
The clean way of being a Tribbiani is to implement a strong integration layer and a reference data store (Joey’s social quotient and social network, respectively). The reference data store will have the customer-number, loan-number and card-number mapped to one another. The integration layer fetches the mobile-number in the request, will first have to look into the customer app to get the customer number, and then fetch the appropriate information from the loan and card systems. The integration layer finally stitches the data together and responds to the mobile app.
The one where anybody can be who they want to be.
With this approach, applications can have the free will to decide what they want to do without worrying about the data from external applications unless the business wants them to. It makes the enterprise Monica-like organized, it makes the IT landscape clean enough to attract Rachel-like attention, and companies can go about growing their business with the bare minimum fuss you normally associate with Phoebe Buffay. The integration layer and the reference data store helps enterprise be who they want to be.
— — — — — — —
The author is a nocturnal tech creature and a midnight snacker who works with multiple financial institutions to help them achieve their enterprise goals with integration and data management. For more information, visit this link to learn all about what a Tribbiani-class reference data store can do for your platform.
