I’m not saying that lightly. I’ve read a Bible’s worth of copy on integration, and then some. What I’ve learned over the years is that integration is under appreciated. It’s something that’s seen as a one-off job on a bigger project, so it’s done quickly, often without long-term thinking about how the integration could be done better or smarter.
And then everyone prays it doesn’t break … which, of course, it inevitably does.
To push the religious metaphor, underestimating integration may be IT’s original sin, and just as in the fall from Eden, the ramifications just keep resurfacing.
Smart companies know you can do better when it comes to integration, and after hundreds of conversations with analysts, industry experts and IT pros, I’ve come to appreciate integration as a strategic practice.
But it’s a hard sell and most people just don’t get it — even in IT, maybe especially in IT.
Hill gets it. He points out that integration is a problem that never goes away, that, in fact, always resurfaces with every new technology trend, whether it’s mobile, cloud, Big Data or the next big thing:
If you the take even more of the ‘buzz stuff’ away — outsourcing, insourcing, BYOD — it almost doesn’t matter. Integration is the key thing — the thing that will keep you safe from change.
Then he proceeds to offer six ways a well-designed integration strategy can help you solve common problems with new technologies and IT projects.
CIOs and other IT managers will appreciate that he also manages to balance best practices with reality in his list.
For example, he acknowledges that you have to balance designing for architectural re-use against project deliver:
Planning and realising re-use typically takes more time, therefore be pragmatic enough to focus on today’s problem but be savvy enough not to close off extension and enhancements for future re-use. Design and build discrete chunks of functionality so that you can separate out business rules, technical procedure and operations giving you flexibility when you need to change them.
He also recommends that end-to-end processes like integration involve cross-functional teams and that there be an integration owner responsible for the whole process and each transaction point.
He does mention a few specific middleware products in the piece and he’s clearly a fan of a middleware/integration layer. But honestly, it’s hard to argue against that, given the well-documented reasons to use an integration layer rather than hand-coding everything. Overall, I thought his advice is non-vendor-specific and well worth a read for anybody involved in integration.
In other words: It’s a must-read for everybody involved with IT these days. As Hill points out, “Integration touches and connects all areas of the business, its customers, suppliers and partners.”