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.

I like to think of the integration capability as just one piece of a jigsaw puzzle of capabilities that make up your enterprise. We’re all familiar with the idea of capabilities I’m sure, but the challenge here becomes how to define the boundaries between them. What functions, processes, RACI, technologies, etc. fit in each capability.

For integration, there are a lot of decisions to be made and no one right answer.  Here are some of those decisions:

1.  Governance only, full-stack tower or somewhere in-between?

One of the most fundamental decisions to make is the scope of the project lifecycle to cover; whether to implement an integration capability as a soup-to-nuts capability that covers the complete project lifecycle from architecture and design to delivery and support – a microcosm of the IT department, as it were – or alternatively to keep it light, taking a governance and guidance approach but leaving implementation to project teams.

This is a critical decision because the approach must be aligned appropriately with the rest of the IT organisation for success. Delivering a full-stack capability into an organisation where projects and programmes are king will be fraught with problems; alternatively, simply offering guidance when the delivery arm has no real capability for enterprise integration will not get you very far.

This isn’t a binary decision either; there is a gradation of options between these two extremes; providing an integration build factory but still handing over finished code to the IT ops team is a common model too.  Equally, organisations that choose to implement the full-lifecycle option often start “small”, with a governance capability, before growing a build factory and then a support operation at a later date.

The point is that none of these options is, in and of itself, wrong; each can be just what a particular organisation in a particular stage of growth requires.  What is much more important is to ensure that the chosen model gels well with the wider operating model.

2.  Centralised, federated, or mixed?

Where should integration decisions be made and at what level?  Generally speaking, big picture architecture decisions should be made centrally, by a core team, but what about the myriad of lower-level design decisions?  Who should decide what an API should look like and how it should evolve, for example?  These are knotty questions and generally the way you tune the architecture/design decision making-process becomes a trade-off between big-picture centralised governance – good for consistency but not great for scalability and terrible at staying agile and supporting the needs of the far-flung corners of your business – and local decision making – brilliant to support project needs but not conducive to the development of a coherent enterprise landscape.  I would argue that the best trade-off combines a top-down approach to setting governance and standards with a bottom up evolutionary approach to API development, but the precise option that is best for any particular organisation will very much depend on the needs of that organisation.

3.  IT- or Business-owned, or Digital?

Integration, at the coal face, is still, in the main, hard technical work.  However, that doesn’t mean it has to remain the doyenne of the IT team.  Whilst the established model is proven and will work for any traditional organisation, if your organisation is digital, I would be the first to argue that your integration efforts should at least be subject to some ownership from the business units that benefit from their services.  Who best to be the product owner for a marketing API?  A business-savvy digital native in the marketing team or John the Tibco expert who can code a mean message queue handler?  It’s not such an easy call in today’s digital economy, but the signs are there and the future’s Digital.

4.  In-sourced, outsourced or mixed?

I have argued for a long time that your integration capability makes an excellent candidate for outsourcing.  For organisations that wish to use a factory model to deliver integration, it is possible to package up integration requirements and get them delivered by a specialised middleware team and this has been shown to be viable many times over, at scale.  Integration in today’s complex IT landscapes is still a very specialist field and it can make sound economic sense to give this to a specialise rather than to maintain an in-house team of highly skilled – and consequently highly paid – integration professionals.

However, to outsource a function it has to be extremely well-defined; this is true of any outsourcing project, not just integration, and this is where many organisations come unstuck.  Integration delivery is a critical component of all modern IT projects and messing it up will have catastrophic consequences for any business.

Furthermore, as discussed in point (1), decisions of lifecycle scope must be addressed.  Do you, for example, outsource integration solution architecture, or do you package up lower-level integration work and send it out to a 3^rd party?  If so, how do you ensure that the many levels of complexity are not “lost in translation”?  At Wheeve, we have experience working with a variety of variations here; indeed, we offer a complete integration service that can “take this problem away” completely for clients that wish to do this.  Again, the right option for your organisation will depend on how much of your IT department is currently outsourced, what your current skills based looks like and so on.

6.  Project approach: waterfall, agile, or flexible?

In this article I’ve touched on the project lifecycle a number of times without being prescriptive as to which flavour to use.  If your IT department is an “agile shop” with epics, stories, sprints and burndown charts being very much part of day-to-day parlance, it makes perfect sense to deliver an agile integration delivery team.  Likewise, there can be real clash of cultures if one attempts to land an agile integration spaceship onto the surface of a waterfall planet.  However, it is very much something that can be achieved; indeed Wheeve have had great success using our agile delivery methodology to support wider waterfall projects and programmes.  Furthermore, if as an organisation you are considering the adoption of agile practices, the integration team makes a great place to start.

Pulling it all together

I hope these questions illustrate the point that there is no one “right answer” to the integration operating model question.  Attempting to make these decisions in isolation of each other is not effective as they are linked.  For example, deciding on a governance only model impacts the effectiveness of, feasibility of and opportunity for outsourcing the function in ways that need careful consideration.

Furthermore, making these decisions in isolation of the wider organisational context is a mistake.  Just like when completing a jigsaw – you don’t know where the pieces go until you have reviewed the pieces around them.

At Wheeve we have helped many organisations work their way through this minefield of decisions to design Integration Competencies that work for their unique requirements.  Why not have a conversation with us to see how we can help you too?