chris - Fotolia
How to simplify IT integration
Pressure on IT is mounting and point-to-point integration does not scale. Opening up APIs is one of the approaches now being considered
Among the challenges for IT going forward is what will happen when organisations run thousands of software-as-a-service (SaaS) applications, most of which will be beyond the IT department’s control.
It is all very well creating tight integration between Salesforce, WorkDay or Concur and back-end systems, but this only works if IT keeps tight control of the SaaS products being used.
During the MuleSoft London Summit, the API (application programming interface) management company’s founder, Ross Mason, pointed out that there are currently 3,500 SaaS applications supporting marketing.
And it is not just marketing. Hundreds of startups are developing applications for blockchain, he said.
“Most organisations are using only five to 10 SaaS applications now, but they need a strategy for integration as more applications are taken on,” said Mason.
Without integration, much of the real value of the SaaS products being used is lost, because their data is kept in silos and often does not touch the core back-end systems. “Enterprises have a goldmine of value in back-end systems,” he said.
For instance, connecting customer relationship management (CRM) with the billing or order processing systems can help to build a greater understanding of the customer and customer experience, said Mason.
But point-to-point integration with back-end systems is costly, time-consuming and cannot keep pace with the imminent explosion of enterprise SaaS deployments, he said. His view of how the IT landscape will change is that IT will need to reconsider its role. “There is no extra funding, but IT is getting more efficient,” he observed.
“Our role in IT isn’t to build. Working harder is not sustainable. Agile is not sufficient. We need to change what we build. Our world is becoming hyper specialised.”
Rather, just as in the manufacturing sector, the role of IT is about setting standards and co-ordinating an ecosystem of specialist suppliers, said Mason.
MuleSoft sells API management middleware, so it is no surprise that Mason suggests APIs as a way to reboot IT.
But he says CIOs should consider a strategy to offload the integration work that has traditionally been the preserve of the IT function. The industry has tried to simplify IT integrations before, but without much success, said Mason. “SOA [service-oriented architecture] was on the right track but failed because it was very difficult,” he added. “It also failed to get the consumer of services on board.”
Read more about managing APIs
- To avoid internal conflict and drive revenue gains, organisations need to properly manage, secure and authenticate their APIs.
- Technology has always been a differentiator for Addison Lee and API management is the next stage in its roadmap.
Rather, Mason believes that an application network comprising open APIs is the way forward for IT integration. “It emerges from the applications you build,” he said. “Open up an API every time you access data from a back-end system. It becomes a set of principles.”
For example, one of MuleSoft’s customers, Coca-Cola, took a bottom-up approach for its first API project, Customer One, when the beverages company needed a 360-degree view of its distributor customers.
“Rather than stage all data in a database, Coca-Cola instead provided a set of APIs to access this customer information,” said Mason.
It began benefiting from the open APIs in its second project – allowing bottling companies to process order requests using the APIs. “Coco-Cola created a centre of enablement, and communities of developers with bottlers to support reusable IT assets,” he said.
Atom Bank has also benefited from taking an API-led approach to developing its mortgage application. The bank’s middleware, built around MuleSoft, has become a key differentiator for Atom Bank. CTO Damian Roberts said: “We have true straight-through processing for mortgage applications, without human intervention. The other big banks can’t do this.”
Going forward, Roberts said he expects APIs to be key to supporting forthcoming regulations such as GDPR, and Open Banking from the Bank of England and the Competition & Markets Authority.
Moving data to support banking regulations can be extremely challenging, said Roberts, but he hoped the middleware would help to simplify compliance.
API-enabled digital ecosystem
During its Barcelona Symposium, analyst Gartner recommended that businesses start looking at how they fit within a larger digital ecosystem. This is the sort of business model that companies such as Airbnb and Uber have exploited to offer their customers compelling services, it said.
Gartner fellow Mark Raskino said: “Every industry will be digitally remastered. Every company will compete as part of a business ecosystem.”
In many ways, this is how modern car manufacturing evolved from Ford’s Model T production line, according to MuleSoft’s Mason, with car makers no longer building all the car’s components, but choosing specialist partners for everything from wheels to engines.
Gartner’s idea for remastering IT digitally is about shifting the focus from managing big, monolithic systems such as enterprise resource planning (ERP) to being much more like a car manufacturer, integrating software and services to deliver IT fit for business.
Mason argues that this integration should be done from the bottom up, rather than having the IT department do all the integration work. There is less integration work for IT to do if everyone in a digital supply chain, from individual business functions to external partners, can access core back-end systems through APIs.
Rather than have a big plan to open up back-end APIs, which could end up being a massive project, organisations that embark on an API roadmap recommend that these APIs should be made available as and when needed. This means that IT only needs to spend time on the ones that will be useful, rather than spending a lot of time opening up a bundle of APIs that may never be used.
