17 June 2008

Avoid the alignment trap

I stumbled upon some very interesting research by Bain that studied the link between getting IT right and the result on business growth and performance (via InfoQ). I’ll summarize the Bain study hereunder and give my thoughts on it.


One of the results of the study was that while some companies reached performance gains by using IT, other companies get stuck in what Bain calls the “alignment trap”. A company is in an alignment trap when increased investments in aligning IT with the business actually hurt growth and performance. IT becomes an obstruction in stead of an enabler. Costs are higher than expected and projects take longer to complete, if ever. There is an over-alignment that causes high fragmentation, redundancy and low scalability.

The solution to get out of the alignment trap Bain proposes is getting effective first and then getting aligned. This may involve temporarily getting lesser aligned to be able to provide more effective solutions. Unnecessary complexity should be avoided, IT capabilities should be, in Bains words, “rightsourced”: the right capabilities should be sourced, from the right source, from the right shore, at the right cost, and the quality of IT delivery should be high.

Only when high effectiveness is reached it is time to get better aligned. Business strategy should be supported and enabled by IT capabilities, IT investments must be made in the right place and business results must be monitored, and both business and IT accountability should be ensured and clear.

Bain research results


I have seen my share of IT projects trying to bridge the alignment gap before effectiveness is reached, especially in SOA environments. This might be one of the most important reasons SOA attempts fail. Although a service oriented architecture removes redundancy by creating reusable services, there are problems that must be dealt with before improving alignment. One of these problems is creating a good technical foundation upon which all future services can be built. I am not talking about problems like choosing what constitutes a service, what granularity to apply, getting business support and commitment; these are alignment issues in my opinion. I am talking about building a performing, not overly complex, technical foundation, or architecture so you will, using IT capabilities from the right source that effectively enables the creation of value adding services. I have seen companies building an architecture and then quickly moving on to implementing value adding services on top of this architecture. On the way flaws and design errors of the foundation are found and fixed, often resulting in adding complexity to the same design. Another complexity issue is the fixed choice for a specific platform and/or product a company enforces. This product must be used, even if it adds only complexity, not value. Performance issues arise, integration problems prevent implementing business scenario’s, etc.: IT has become an obstacle.

Lightweight 'Guerilla' SOA

The design of the SOA foundation could be Big Design Up Front, something I would not advocate for developing a business service (apply agile methodologies there), but pay attention on keeping complexity low and effectiveness high. Try not to create barriers, like performance bottlenecks. This does mean designing and measuring for performance. I’m not a fan of premature optimizations, but this core technology determines for a great deal whether the SOA/IT is a business strategy enabler. I know you cannot anticipate everything beforehand, but I agree with Joel Spolski that thinking things out in advance can reduce the chance having to solve a non-functional issue in an established architectural landscape. So, my advice is: first get effective by creating an enabling foundation, secure non-functional requirements and keep it lightweight! When that is in place, agilely create value adding services. Of course, the technical foundation is not a static thing, it should evolve to keep enabling business strategies. Create a Guerilla SOA. This might seem controversial to my advice of designing up front and creating a solid foundation before delivering business processes, but it isn’t. Designing a lightweight foundation up front may take more time than jump-starting an increasing complex, heavy-weight middleware solution (although often this takes more time and money), but a clean and lightweight foundation is more manageable in the long term and keeps being an enabler.
This way, IT should result in increased business growth and performance, while getting costs lower.