lustratus LiteBytes

JP Morgenthal has come up with 3 rules when buying an enterprise application.

While I am not sure he necessarily excludes integration software/middleware, I thought I would have a go at drawing up three more (semi-tongue in cheek) rules.

JP’s rules are (shortened from their original form):

“1. There will always be a customization requirement: You’re not purchasing Quicken. If you have special requirements for how that software will be used in your business, expect that some level of customization is going to be needed.
2. You’re buying the company and its people: At the end of the day, most enterprise software applications can be made to do anything you want–that part is a matter of time and cost
3. Going with the leader is not always the best decision:  These companies’ offerings are, often times, bloated, cost more to customize and maintain and cost more to procure simply because they know they are the leader.”

My rules for integration software/middleware are:

1. There should always be a more bleeding edge alternative to your approach; otherwise you are too bleeding edge.  To put it another way, if you are thinking about an approach that is the newest thing on the block then you need to be sure that it does something pretty amazing for your organization to counter-balance the risk of being the proving ground for something so new.

2. The customization will be much greater than the software budget. JP politely played this one way, way down.  Any enterprise software project spends much, much more money on implementation than on integration software licenses.  If you remember that many integration projects are part of a larger application project, the comparison between integration software versus total project cost escalates again.  Unfortunately, the relatively small size of the integration software line item in the budget does not reflect the reality that picking the wrong tool for the job here can cause the whole project to fail.

3. There are always many ways to skin the integration cat. There have always been a number of different approaches to solving any middleware problem.  Just think of the regularly erupting REST versus Web Services debates or EDA versus SOA or even .Net versus J2EE.  Picking the correct cat skinning approach is far more complex as there are rarely clean answers. You must consider organization history, culture, legacy, appetite for risk, available skills etc etc.  This was very apparent on the recent Integration Consortium call on EDA and SOA as it was clear that EDA and SOA were often both needed in any given organization.

Ronan