Our last post on integration demand management focused on managing the delivery throughput for a centralised integration competency centre, however the centralised delivery model is not the only solution for an effective integration strategy. These approaches may be more appropriate for you depending on your strategic outlook and IT objectives, but these will present different and often less obvious demand challenges that need to be addressed.
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.
A lot of things are built every day in every corner of the globe, from enormous skyscrapers to tiny plastic widgets and they are mostly useful things that are built efficiently with the end customer in mind. Many Information Technology (IT) things are also being built but it seems to be a little harder to quantify how efficiently they are built and how useful they are going to be. There often seems to be a disconnect between what the users want and what is delivered.
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.