Integration is all too often seen as an added cost to another major IT programme, usually a systems upgrade or refresh. Successful organisations are however starting to understand that integration is, in itself, a capability. If executed effectively, it can deliver real benefits back into the business. In this guide I explore the ways in which integration can reduce cost and enable transformation.
Over recent weeks the Wheeve team have attended a number of industry events and the 'hot topics' seem to be fairly consistent when it comes to CIO challenges and digital transformation. Here's our view on the top three: GDPR, cyber security and the mobile workforce, shadow IT and microservices.
You hear it all the time in the press; there’s a massive IT skills shortage. Indeed, at the recent Gartner Application Architecture, Development and Integration Summit last week, analysts were still predicting that demand for IT resources will outstrip supply five-fold for at least the next five years. A good thing for IT professionals but a disaster for companies looking to invest in a digital platform.
Unfortunately, IT demand is notoriously difficult to plan, particularly for fast moving industries where the business priorities change on almost a daily basis. The tendency is for IT teams to oversimplify or inwardly focus their demand management process because painting a more accurate picture is a complicated affair. The impact of this is that IT is either grossly over or under manned to deal with the incoming challenges and is viewed either as an overblown and expensive department full of geeks twiddling their thumbs or, as incompetent butterflies who are always working on the wrong things and never getting the important stuff done.
On 5 June, Wheeve will be joining circa 100 IT leaders at Global Business Intelligence's CIO Summit at Said Business School, Oxford. The theme of the event is 'Digital Transformation and the Future of Cyber Security' and Wheeve will be hosting a round table.
Picture the scene - your project has been running for a few months, and each team has been building their features and testing them; the website team have been proudly showing off the gorgeous new site; the database team have been fine tuning for performance; the ERP team have added new features to maintain the new stock items; the CRM team have added attributes to capture the new customer data; and the integration team have been building their interfaces. Everyone has been working from an overarching high-level design, and from interface specifications so that the website guys can work independently of the integration guys, who can be independent of the CRM guys. This is good practice for managing the project, whether it’s a small enhancement or a massive transformation; whether it’s being delivered waterfall or agile .
I often find myself helping integration managers justify their existence to the wider IT department. It seems the problem is that integration is often an afterthought tacked onto the end of a systems implementation project. This approach, in which integration costs are hidden within projects and programmes, reduces the integration team to nothing more than a necessary cost of system implementation.
Furthermore, hiding integration in systems implementation projects prevents the organisation from seeing the opportunities a more open systems approach to integration offers. After all, why would project X pay for the additional cost of making components that were reusable by other projects? It is only by elevating the middleware integration platform to the same status as other systems, and separating the responsibility for these aspects of implementation from endpoint systems projects, that your systems integration capability can be moved from simply being a cost centre to being an opportunity to drive down the costs of systems implementation by reuse, data sharing and even opening up the possibility of monetising your data via exposure of APIs for 3rd party consumption.
Integration is a complicated business. Tying together the IT landscape means lots of connections, interface points, APIs, protocols, messaging types, data formats, etc... There are plenty of patterns and area’s of best practice that can be applied to simplify your approach to integration and reduce the complexity, however, one inevitability of being in the middle of all these connections is that when there is an issue with what has (or has not) arrived from system A to system B, the integration platform is usually the first port of call.
If digital transformation is viewed as 'another IT project', you could be losing out on the chance to maximise success if you focus on traditional metrics.