Last month, I was delighted to be able to give a presentation to the Enterprise IT Strategy Forum, an event at Heythrop Park in Oxfordshire attended by IT decision makers from many large organisations. My presentation, on how to leverage existing IT assets to support the delivery of digital transformation was well received, and I promised to post a transcript of sorts here.
One of the first questions I often get asked when starting a conversation about implementing an Integration Centre of Excellence model is "What should its scope be?". The answer to this question is, unfortunately, "It depends".
Now I appreciate that, coming from a consultant that answer doesn't really cut it, as that's often viewed as consultancy code for "I'm not going to tell you the answer until you pay me to do a piece of work to work it out for you." In this case, however, it happens to be true. In this post I want to explain the many factors that determine what the scope and shape of the integration capability of your organisation should be.
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.
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.