Elvis has left the ivory tower
Pragmatism now rules in team structure, technology, engineering practices, and operational innovation.
Elvis Presley impersonator (source: Gary Bridgman - Wikimedia)
Ancient history in computer science (2004) provides a gem about the personas that Microsoft envisioned as users of the development environment Visual Studio. They developed three:
- Mort, the opportunistic developer, likes to create quick-working solutions for immediate problems. He focuses on productivity and learns as needed.
- Elvis, the pragmatic programmer, likes to create long-lasting solutions addressing the problem domain, and learning while working on the solution.
- Einstein, the paranoid programmer, likes to create the most efficient solution to a given problem and typically learns in advance before working on the solution.
These designations received a lot of negative press, particularly around the Mort persona, but I want to focus on Einstein and Elvis.
Learn faster. Dig deeper. See farther.
Formerly, software architects exemplified the Einstein persona: isolated from day-to-day development details, focused on building abstractions and frameworks. The isolation is so common that it spawned its own “Ivory Tower Architect” derogatory phrase. But the realities of building systems that scale as fast as the business does invalidates that approach. Now, Elvis, the pragmatic developer, has ascended to architect while simultaneously descending from the Ivory Tower. Modern architects don’t have the luxury of isolation from the gritty realities of software development today. Pragmatism now rules in team structure, technology, engineering practices, and operational innovation because:
Architecture is relevant outside IT
Software architecture was once thought of as an arcane bit of overhead that companies must endure to have computer systems. Like plumbing, why focus on innovation when things seem to be moving along? However, companies Like Netflix and Amazon show that architecture can be a competitive advantage. Netflix has such a market lead that they can afford to open source most of their infrastructure. Amazon rents their excess operational capacity to the world. But architecture is relevant on a smaller scale, too.
Many companies discover that traditional monolithic architectures fossilize shockingly quickly, making change increasingly painful. Architectural decisions that seem expedient at project inception contain hard-to-anticipate long-term implications. Additional failure to keep infrastructure and practices up to date compound the pain, making inertia stronger. By contrast, companies that invested in more flexible architectures suddenly have a competitive advantage that is quantifiable.
For instance, continuous delivery, a set of engineering practices for software projects that include metrics to measure efficiency, doesn’t track lead time because it includes too many subjective activities (estimation, prioritization, etc.). Rather, it tracks cycle time: the total elapsed time to move a unit of work from the beginning to the end of a physical process (i.e., software development). For software development, cycle time measures the amount of elapsed time from when a developer starts coding a feature until that feature appears in production. In other words, cycle time measures engineering efficiency.
It is not uncommon for cycle time to go from several weeks (planned releases) to several hours (continuous deployment). If your company moves to continuous deployment while your competitors languidly release every so often, you suddenly have a leverage-able advantage. Modern deployment techniques require designing architectures that anticipate and mesh with operational capabilities. Change beyond technical infrastructure is also required, like rethinking team structure.
Dismantling of silos
A decade ago, software architects didn’t think much about operations beyond formal communication via ticketing systems. Operations was like the weather: an environmental given, to be endured, but no amount of complaining will fix it. The DevOps revolution showed that modern architectures must embrace operational concerns, forcing a beneficial collaboration between architects and DevOps. Continuous delivery encourages architects to think about operational concerns as early as possible (rather than the previous practice of as late as possible).
Every company is now a software company
In an influential 2011 article, Forbes stated that every company is now a software company. Their point: if you are an airline and your iPad application sucks, you have serious problems. The quality of online presence is now a factor in the economic viability of a company. Companies that pay attention to details like software architecture build competitive advantages.
Architecture is cool (again)
For a long time, it seemed that architecture was a mysterious activity that only happened within ivory towers. Architecture is now more democratized and ubiquitous: you cannot work with microservices or reactive architectures without understanding how they work. At the same time, new architectures are solving problems in bold, elegant ways.
Editor’s note: O’Reilly is hosting its first-ever Software Architecture Conference in March. If you find yourself making the transition from developer to architect or just want to keep up with the latest approach, the conference includes a rich variety of cutting-edge topics aligned to the modern reality of software architecture.
Cropped public domain image of the hypostyle hall at Karnak by Blalonde via Wikimedia Commons.
