It's undeniable that the field of software architecture has grown during the past 20 years. In 2010, CNN/Money magazine identified "software architect" as the most desirable job in the U.S. Since 2004, the SEI has trained people from more than 900 organizations in the principles and practices of software architecture, and more than 1,800 people have earned the SEI Software Architecture Professional certificate. It is widely recognized today that architecture serves as the blueprint for both the system and the project developing it, defining the work assignments that must be performed by design and implementation teams. Architecture is the primary purveyor of system quality attributes, which are hard to achieve without a unifying architecture; it's also the conceptual glue that holds every phase of projects together for their many stakeholders. This blog post provides lightly edited transcriptions of presentations by Jeromy Carriere and Ian Gorton at a SATURN 2012 roundtable, "Reflections on 20 Years of Software Architecture."

Jeromy Carriere
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=19318

In 1999 and 2000, I had just left the SEI to join a startup company that I co-founded. I came out of the SEI with great respect for software architecture. This (please view Slide 2 from Carriere's presentation) was the top-level, logical view of the back end of my startup company's software. Not many startup companies then--and certainly not now--do architecture models of this sort. This was an early model-driven design; it actually drilled down into mechanisms between components, and it generated code. That was cool, I had a little experimental testbed, and it was fun.

All of these factors led me to develop a different working definition of architecture: A system's architecture codifies a set of decisions that are both hardest to change and that have the most significant impact on the way the system manifests its quality attributes.

This diagram (please view Slide 6 from Carriere's presentation) helped us sell the company for $200 million to AOL. This is completely informal, but it reflects what's important about architecture; that it was quality-attribute driven. We were making decisions as a small startup company based on what was important. What was paramount for us was flexibility. Above all else, we knew that we didn't know where the business was going. In the very short life of the company, the business model changed substantially four times; the software architecture did not change once. Because the software architecture of the system was designed specifically to adapt--from a physical-device company to a voice-based thing, B2B, B2C... But this (refers to architecture diagram in slide) was maintained throughout.

And that was enough to get us the deal. We sold the company to AOL, and then it failed. To put it bluntly, it was designed to be sold. We built our first product--AOL By Phone--in 90 days. From the day that we did the deal to the day that we deployed the system, including deploying hardware, it was 90 days.

Later in my career, I still loved diagrams. This (please view Slide 7 from Carriere's presentation) is a fantastic diagram labeled "critical systems interrelations overview," but it is useless. What good is that (refers to slide 7) besides being decorative? I wanted to be able to find a reason to use it in my day job, but it didn't have any use. This was a period in my architectural career where I came to this conclusion and started to take on a different perspective. Last year at SATURN, I talked about low-ceremony architecture, which is how do you architecture like a startup. This is based on my Quack.com experience. [For more information about Carriere and his experience co-founding Quack.com, read the article "SEI Architecture Practices Propel Successful Startup."]

If you want to get a job at Facebook, Twitter, Google, or Netflix, do not put "architect" on your resume. You will not get hired. Call yourself a lead engineer or something else, but not architect. In Silicon Valley, there's a lingering allergic reaction to "Big A" Architecture, which is characterized by setting standards and making rules and drawing diagrams, those kinds of activities that we have all experienced. That disconnection from the actual engineering practice of developing software and what became architecture in some companies that were predecessors in the net space is deeply rooted in Silicon Valley. What I find most ironic is that these kinds of companies need architecture practice the most. This goes back to the Quack [Quack.com] story; we needed a perspective on quality attributes, prioritizing for flexibility, thinking about how you're prioritizing architectural decision making because you're living in a very uncertain world.

Ian Gorton, Pacific Northwest National Laboratory
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=19986

We've seen our profession mature over the past 20 years. We've made advances in methods, processes and tools, but the scale of systems has grown enormously. But has there been anything truly innovative in the past five years in practice or research? While we apply the methods and tools that we know and love, the software world is getting more complex, and our solutions are very much based on qualitative engineering approaches. In the future, maybe we need to become more quantitative, applying more objectivity in our assessments and designs.

There has been some initial work in many areas. I've done work in combining decision theory with optimization techniques to enable architects to quantitatively assess complex, multidimensional design alternatives. There are tools for modeling performance with multiple modeling approaches built into the tools, which makes them easy to use. So I think there's a lot of work we can leverage and extend here if we actually look toward future problems. It's not that we have to invent any mathematics or statistics; there's a rich body of math and stats that we can exploit. We just need to know when and how quantitative methods can be usefully applied.

Quantification is in some ways harder, but it doesn't stop others from addressing really hard problems. Climate modelers, for example, build simulations that are being used by governments around the world to predict future climate and mitigating policies. These climate models are tested and validated against historical data. When they don't produce results that exactly match the historical data, they are calibrated to provide reasonable outputs. But there's no guarantee that these calibrated models are going to be able to predict the future. So if climate scientists can do this, we can too. Our current and emerging design and quantification models and methods may not (or may never) produce 100 percent accurate predictions of software architecture characteristics, but they will be much better than our current qualitative approaches.

We have to move toward quantification because there are challenges in the exponential growth of system scale. There are huge software systems being employed in clouds that are so complex that our current architecture design methods are inadequate. To more rigorously address these systems of massive scale, we need concerted R&D [research and development] to move software architecture to more quantitative foundations. This is hard because, as you get to larger scales, things we know and understand well (such as design approaches, technologies, platforms) must be reexamined to address scale. This community is perfectly positioned to discover underlying principles and make these available in systematic approaches that can be broadly adapted to build the highly scalable systems of the future.

Additional Resources

Carriere's presentation may be viewed at
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=19318

Gorton's presentation may be viewed at
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=19986

For more information about Carriere and his experience co-founding Quack.com, read the article "SEI Architecture Practices Propel Successful Startup."