No Big Bangs
Integration isn’t a big bang deployment exercise.
The kind of project I love is the kind that is small in scope; you have a tricky piece of integration that you can’t do with your current piece of software. It starts off small, but when you see the business value, you start using the software more and more. We had exactly this kind of project about 10 years ago. The customer put our software in place, and the first time we hear from them again was Jan 2015. Their license had expired. They had never upgraded; they’d never raised any support calls; our software had been working quite happily in the background extracting and sending all their documents. For me; this is great advert for Interlok. It just works.
I’m seeing a lot more customer engagements that want to replace their whole integration/services stack. Getting this kind of headline deal is great for marketing and I enjoy the pressure you’re under when trying to deliver proof of concepts for these kinds of projects; that said, I wouldn’t want to work on the actual deployment though. The customer starts off all bright eyed and optimistic; the vendor thinks they’ve learnt from the last big roll-out and they’ll have this one under control. It’s a roomful of optimists thinking only about the happy path. This will not be the path the project takes. You see it reported all the time in the media; choose virtually any large public sector roll-out.
Do the small scale stuff first; get the interactions between the existing components working properly and it will make everyone’s life easier. This improves the actual business processes that the organisation uses. This will bring value in the short and medium term; it isn’t a case of jam tomorrow, never today. I see it as part of our role as integration specialists to make you realise the business value quickly. We can’t do that with a 12-18 month delivery cycle.
If you’re going to put these out to tender then make sure that the vendor you select shares your culture and values. Ideally, the vendor’s team will work at your offices, sit with your people, build a relationship, get to know them and understand that what’s written down in the requirements document really isn’t what’s required. They’ll start to understand the business and will make the right adjustments and tweaks at the right time. This is resource intensive; and integration has never really fitted well with the current software-development-is-like-a-factory-production-line thinking. Ultimately though, it’s about the people as much as it always has been.