“Faster Horses – Henry Ford and Customer Development” on CitizenTekk

Henry (“Any customer can have a car painted any color that he wants so long as it is black”) Ford was not an advocate of customer development. Although there’s no evidence that he actually said “If I had asked people what they wanted, they would have said faster horses”, it’s definitely congruent with other statements he did make.

My inaugural post on CitizenTekk discusses how to meet the needs of your stakeholders by defining the architecture of the problem rather than jumping straight to the architecture of the solution.

Advertisement

Finding the Balance

One of my earliest posts on Form Follows Function, “There is no right way (though there are plenty of wrong ones)”, dealt with the subject of trade-offs. Whether dealing with the architecture of a solution or the architecture of an enterprise, there will be competing forces at work. Resolving these conflicts in an optimal manner involves finding the balance between individual forces and the system as whole (consistent with the priorities of the stakeholders).

At the scale of an individual solution, concerns such as performance, scalability, simplicity, and technical elegance (to mention only a few) can all serve as conflicting forces. Gold-plating, whether in the form of piling on features or technical excess affects both budget and schedule. Squeezing the last drop of performance out of a system will most likely increase complexity, making the system more difficult to change in the future and possibly impacting reliability in the present. As noted by Jimmy Bogard, “performance optimization without a clear definition of success just leads down the path of obfuscation and unmaintainability”.

At the scale of an enterprise’s IT operations, the same principles apply. Here the competing forces are the various business units as well as the enterprise as a whole. Governance is needed to insure that some units are not over-served while others are under-served. Likewise, enterprise-level needs (e.g. network security, compliance, business continuity, etc.) must be accommodated. Too little governance could lead to security breaches, legal liability, and/or runaway costs while too much can stifle innovation or encourage shadow IT initiatives.

A fundamental role of an architect is to identify and understand the forces in play. In doing so, the architect is then positioned to present available options and the consequences of those options. Additionally, this allows for contingency planning for when priorities shift, requiring a re-balance. In a highly variable environment, having fragile balance is almost as bad as no balance at all.