Customers on-the-go appreciate their service providers delivering meaningful, useful information to them – directly to their mobile devices. For example, imagine the effect of sending a congratulatory message when a bank customer has finally finished paying off a loan. Imagine, as well, the opportunity to offer a new investment or savings plan to maintain the momentum and offer more value to the customer. But what if this message delayed? Engaging, by definition, requires a nimble response-time. Otherwise the customer moves on. The opportunity is taken elsewhere and the customer has forgotten completely about you, the loan and the new investment opportunity.
One current manual solution could involve ESBs:
- Set up a client-server connector to the loans system and map the COBOL parameters into a usable web service that can be fed to the ESB and transformed into a RESTful API. But before you can do that, you must:
- Create an XML schema. And before you can do that, you must:
- Define the data items in the central data dictionary.
- But before you can do that, you must clear everything with the data security team.
- And before you can do that, you must change the connection to the loans system into a secured VPN.
- This requires a static IP address, which renders your disaster recovery procedures useless. . .
This approach is not agile or efficient. A different approach must be implemented for those cases where speed is of the utmost importance and the opportunity or threat has to be dealt with as soon as possible. Big architectural IT changes aren’t necessarily wrong. But there are other alternatives, for example, using “RESTish” protocols instead of ESB to connect legacy and modern systems can make solutions a lot simpler (Martin Fowler). And when the job of connecting legacy and mobile solutions can be automated using tools that have been pre-checked and proven safe and effective – it is a lot easier to choose which way to go.