A couple of people at work use the term strategy tax when referring to compromises or similar decisions a product team makes that are less than optimal because they have to satisfy the corporate strategy. More and more, I see this term coming up with regards to what Microsoft has termed "integrated innovation". If you are unfamiliar with this term a good description of it can be found in the Microsoft press release 'Integrated Innovation' Provides Partners with Roadmap to Success  where its states

The pursuit of Integrated Innovaton pertains both to product and process. Integrated innovation is manifested in the Microsoft platform but it extends beyond the technology stack. It's Microsoft's approach to building software: simultaneously innovating in product design and development and tightly integrating products, each one with all the others.

Before pointing out the obvious cons of such an approach its benefits should be highlighted. Many would argue that the reason Microsoft Office became the multi-billion dollar business it is today is because it applied to doctrine of integrated innovation. Microsoft took what used to be considered disparate applications (word processing, presentation software, spreadsheets, etc) and turned them into a cohesive productivity suite that worked seamlessly together. The fact that one can design a chart in Excel then cut and paste it into Word with no problems was a big deal when it was first implemented and it still is today. As the saying goes, a lot of effort went into making this look effortless. This combined with the fact that you could purchase these tools in a single box made it the killer application for businesses all over the world.

With that out of the way, let's discuss the cons of this approach. Many students of software engineering will tell you that the goal of any systems architect is to increase cohesion and reduce the coupling in the software architecture. The problems with tight coupling (or tight integration) are well known. As mentioned in Object Oriented Software Engineering Knowledge Base, tight coupling causes a system to be hard to understand and change because changes in one place will require changes somewhere else. Requiring changes to be made in more than one place is problematic since it is time-consuming to find the different places that need changing, and it is likely that errors will be made. 

Those are developer-centric reasons for why tight integration is disadvantegeous but what do these mean in practical terms? The first thing it means is projects take longer. This is basically the Mythical Man Month effect. If you have two teams of 10 people working on separate projects that will take six months to complete and tell them to combine their efforts, it will take them more time to complete their joint tasks not less. As implied above this also means a bug in one component is a bug in all the components, a security flaw in one component is a security flaw in all the components and a slip in one component's schedule is a slip in the schedule for all the components. Finally, it makes the systems more complex to manage and understand which means it makes them harder to maintain.

In today's world where the majority of Microsoft's software is competing with the products of the Open Source community whose mantra of "Release early, release often" and increased threats from malicious hackers make security a primary concern the doctrine of integrated innovation seems almost anachronistic.

The effects of integrated innovation on product schedules shouldn't be underestimated. Although Microsoft Office is an example of integrated innovation when considering its constituent parts it also is an example of eschewing this practice when taken as a whole. The Office team releases a cohesive product with minimal dependencies on external products. The Office team has also consistently released software every 2 to 3 years over the past decade; Office 95, Office 97, Office 2000, Office XP, and Office 2003. Certain other products at Microsoft which are at the forefront of integrated innovation do not seem to have such consistent release cycles. These products are paying the strategy tax.

The main reason for writing this blog entry is so that next time someone asks me what I mean by "strategy tax" I can just give them a link to this entry instead of repeating myself.