Given that background, I was blown away by the application integration technology from Kapow Software. It even made me question the 10% rule.
The conventional scenario goes something like this. Within your organization, there are various software development projects underway at any one time. Some of them involve creating new applications that pull data and capabilities from other systems. Examples include content migration, mobile applications, and process automation. If you sell products through a chain of distributors, perhaps you want to keep an eye on current pricing levels or the prices for competing products. The systems of interest could be internal or external. How do you build them?
[ Learn how one tech vendor is getting social. Read IBM Eats Its Own Social Dog Food. ]
The dominant approach is to throw software developers, time, and money at such projects. A recent project highlighted by Kapow required 40 developers, 24 months, and $2 million. Kapow claims that by using its integration software, its customer completed that same project with only a few developers, in six weeks, for $200,000. That's an order-of-magnitude reduction on all three dimensions. Even if Kapow is overstating the savings, its software has me questioning the 10% rule.
If you're creating an application that draws on data in other internal and external systems, some with great integration points and others with no integration points at all, Kapow may be the answer. Its software interrogates a target system or website, and provides capabilities for importing and transforming its data into the application being built. For example, you can capture the title, description, and price for a range of products that meet certain criteria from an online store, and import those into your application for further analysis. Once the application has been designed in Kapow's design client, it's transferred to a server to run.
Here's how I resolved the dilemma on the 10% rule. If you just look at the technology and compare two products, one will be cheaper, or better, or faster (or sometimes two or three of those) than the other. If one technology (for instance, Kapow's) is significantly better than the current approach, you can gain significant savings in process time, cost, and business risk.
But in order for the technology to be used effectively, the other success factors--governance, process redesign, executive support, and more--must come together in an appropriate way. If not, the current, embedded ways of working and thinking will prevail.
Kapow’s tools are ideal for systems that lack APIs, because they can provide a method for integration beyond using manual coding outsourced to consultants. For systems with robust APIs, organizations could alternatively use tools from IBM CastIron or Boomi (now owned by Dell). But even robust APIs may be insufficient in practice.
Clearly, Kapow isn't for all software development projects. If you're building a new system, Kapow's not the answer (as I wrote about recently, you should be checking out iRise for that). But if you're building an application that integrates data from different systems, check out Kapow's new way of development.
Michael Sampson is a collaboration strategist and author. You can reach him at firstname.lastname@example.org or +64 3 317 9484 (New Zealand).
InformationWeek is conducting our third annual State of Enterprise Storage survey on data management technologies and strategies. Upon completion, you will be eligible to enter a drawing to receive an Apple 32-GB iPod Touch. Take our Enterprise Storage Survey now. Survey ends Jan. 13.