Why Architecture is strategic

Every once in a while when we engage our clients/prospective clients on a consulting engagement they question the involvement of an technical architect in the engagement, cause they find that its an unnecessary expense and that the architecture can be developed/recommended by one of the existing development resources. Well that brings an interesting question. What is software architecture? Ask a bunch of people and a common response you get is that a software architecture defines the high level design and components to be used in the proposed system. Its correct but unfortunately that’s a very narrow perspective into what goes into defining an architecture, architecture is not just a technical decision of various software components - its strategic!. Its strategic because the architecture defines how you can monetize the product/service, the software architecture you define is what can help your product compete with other vendors in the same space and give you that edge. Not thinking of architecture as something that’s strategic is being shortsighted. To illustrate this let me give you an example.

Early this week we were on a call with Microsoft and a large enterprise in financial services to identify the high availability and disaster recovery (HA/DR) solution for their MOSS environment. The discussion finally lead down to identifying a suitable product for DR and we were discussing the many DR product options available in the market that work with MOSS. Microsoft with System Center Data Protection Manager 2007 (DPM 2007) presented a strong candidate for the client to consider from the sheer integration/understanding of the product and MOSS, however there were other vendors in DR space for MOSS as well and the financial service client was in favor of picking one of the other vendor, Microsoft sales knows how to play their cards well and dealt the trump card - Data Protection Manager (DPM) had architected their solution to leverage only the exposed MOSS APIs (which if your familiar with MOSS tells you that there are several limitations to this approach) and hence DPM is supported under Microsofts premium support where as several of the other DR vendors did not leverage the (limited)APIs but instead did direct DB access, this "hack" was easier to do and gave the vendors products more features to sell - however their product would not be supported by Microsofts premium support, i.e. if the client has any problems with their MOSS solution and calls Microsoft for support, Microsoft can deny support because they were using a DR product which is using an approach that is not supported by Microsoft. Bummer. The various DR vendors didn’t think about this in the architecture design, the "hack" they decided on which seemed technically appealing did not help them in the sale.

To the financial service client this was like a show stopper and immediately decided against its previous DR vendor selection. In the past several consulting engagements we have helped ISVs architecture their solution that avoid these kinds of pitfalls.

The next time your thinking of building an architecture are you thinking of how the architecture can empower your sales team with the strategic "battle card" to help win the deal? Is your architecture strategic?