I’ve heard “business led integration” mentioned a few times in the last month or so, usually as part of a presentation at a conference or trade event. The idea seems to be that getting the business directly involved in our integration projects will make the projects more successful. The problem is that this seems to describe a desire from IT rather than a real solution to a problem. If the business was actually interested in integration, then they would already be involved. Inviting business folk into our integration world might help them understand the challenges we deal with on a day-to-day basis, but this seems to have the problem the wrong way around. Or as Ron put it, there is no spoon. The business has bigger bunch of problems that they are dealing with, and what they’re worried about is that we’re going to help them solve their problems. How we do it is our problem. In an application-centric world, justifying an integration project was always going to be hard. We’ve built our IT organisations on the assumption that they will be delivering applications into the business, and we use applications to define how we engage with the business. Each business problem is addressed by a solution, with a business case built around a (usually quite long) cause and effect chain used to connect the solution to any benefit it delivers. We’ve had some success with business led application development, but then the business cares about applications as they are the vessel for realising business logic. Integration, on the other hand, typically delivers little business value relative to the investment required. The same is true for any infrastructure project. While we might like the idea of business led integration, I’m yet to meet a business person who is interested. As my old circuit theory lecturer said if you don’t like the problem, then change it. I think we need to change the way we engage with the business. A few months ago I came across a brilliant blog post by Andrew McAfee. In a nutshell, he points out that we need to deliver capabilities into the business, not applications. It’s the same technology, but a different way of thinking about it. Rather than engaging the business on the basis of delivering IT assets, we need to engage on the basis of realising the business capabilities they require. Our focus needs to shift away from the challenge of negotiating a (hopefully) complete set of requirements and then engineering a solution. Instead, our job is to take the capability and determine the technology footprint required to support it. For example, the business might be worried about improving time from sale to revenue turn on. Doing this could require creating joined-up IT support for the complete quote-to-cash business process—a project involving some integration, a little BPM, updating the employee portal, possibly upgrading the CRM application and replacing the aging provisioning solution, deploying a rules engine, and so on. Deliving the IT footprint involves a little bit of this, a little bit of that, and will deliver a clearly defined capabilty with a measurable benefit. The approach also has an obvious synergy with SOA and business-centric approaches to enterprise architecture. We need to re-engage with the business, focusing on realizing capabilities rather instead of delivering IT assets. Projects will be defined by the capability delivered, instead of the type of technology involved (application development, integration …). This connects what the business wants (the capability) directly to the IT required to support it. The business will be interested now.