Architecture enabling business

Below is the abstract that I submitted as a presentation proposal for the Software Engineering Institute‘s SATURN 2011 conference.

In my career as an “architect” (the need for the quotes will become apparent), I’ve worked on developing software in environments including 6-person startups, defense contractors, large private financial services companies, software vendors and large internet/media companies.  In some of these environments “architecture” enjoyed significant success, and respect – particularly the large enterprises and government contractors – mostly in the late 90′s and early 00′s.

Unfortunately, “big-A” architecture, as most notably characterized by EA frameworks, formal architectural documentation, centralized technical oversight and top-down (or inside-out) standards setting and enforcement, has been aggressively resisted or rejected by agile, fast-moving companies.  Dominantly, these companies are those that enjoyed the internet boom and the “coming again of the internet” through the uprise of the social network and real-time web.  And ironically, these are the companies that would most benefit from strong architectural thinking.  Why?  Because an “architectural” mindset will ensure the successful among these companies are able to scale to enjoy the benefits of their market positions and transition from startup to sustainable company. Unfortunately, therein lies the problem: how do you know when to invest in architecture? Except at enormous cost, you can’t code in quality (maintainability, scalability, reliability) later, but investing too much in these quality properties at the wrong time in a company’s lifecycle guarantees failure.

This presentation shares something of a case study of adopting a consistent architecture practice in an agile, successful company exiting hypergrowth and looking to build a scalable, sustainable technical organization around a robust business model.  This company carried the quintessential symptom of architecture rejection, the cultural immune response to the diagram-drawing, standards-setting, system quality-focused, structuralist definition of architecture.  Why? Failed attempts and low demonstrated value.

Successful adoption of an architecture practice at this company was initiated with a key first step: the redefinition of “architecture” from the usual components-and-their externally-visible-properties to: “… a framework for informed and visible decision-making that explicitly trades off among traditionally competing quality properties such as time to market, performance, flexibility, maintainability and testability”.  This definition had the effect of making every engineer (and, for that matter, every project manager) accountable for practicing sound architectural reasoning.

The change in definition was followed by process and organizational changes, including the “architect diaspora” – distributing domain architects into development teams, while maintaining a centralized tools-and-frameworks team that demonstrated the inherent value in standards.  There was also, critically, a set of architecture practices to be adopted: valuation of transformative/refactoring projects, a technical review process and oversight model, a portfolio-oriented technical debt management approach, architecture evaluation for transparent and rational technical decision-making and identification of autonomy boundaries to manage growing organizational and systems complexity.

This presentation will discuss the motivations for, and experiences with, the adoption of “low ceremony architecture” in software development organizations.