A search on the term "software architecture" on the web as it existed in 1992 yielded 88,700 results. In May, during a panel providing a 20-year retrospective on software architecture hosted at the SEI Architecture Technology User Network (SATURN) conference, moderator Rick Kazman noted that on the day of the panel discussion--May 9, 2012-- that same search yielded 2,380,000 results. This 30-fold increase stems from various factors, including the steady growth in system complexity, the increased awareness of the importance of software architecture on system quality attributes, and the quality and impact of efforts by the SEI and other groups conducting research and transition activities on software architecture. This blog posting--the first in a series--provides a lightly edited transcription of the presentation of the first panelist, Linda Northrop, director of the SEI's Research, Technology, & System Solutions (RTSS) Programat the SEI, who provided an overview of the evolution of software architecture work at the SEI during the past twenty years.

20 Years of Architecture at the SEI as Presented by Linda Northrop

In 1992, the SEI was working on structural modeling and applying this concept to flight simulators for the purpose of re-architecting Air Force systems that had become brittle and unmodifiable. Others at the SEI were then studying what we called "quality attributes," looking at such attributes as performance, reliability, and modifiability and trying to determine what the underlying analytic models were.

Soon after, we started a software architecture project at the SEI that studied architecture description languages, definitions of software architecture, and ways to evaluate software architectures. Around 1995, we were asked by the U.S. Department of Defense (DoD) to write something about software architecture. In response, Paul Clements and I wrote Software Architecture: An Executive Overview. Then Len Bass, Paul Clements, and Rick Kazman wrote the first edition of the book Software Architecture in Practice. We considered a number of existing definitions of software architecture, but in the end formulated our own:

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

Architecture is concerned with the public side of interfaces; private details of elements--details having to do solely with internal implementation--are not architectural. This work constituted the beginning of a cohesive body of SEI research and transition efforts focused on software architecture.

We started our research with architecture evaluation, because we reasoned that by evaluating software architectures early, we could alleviate subsequent testing and integration problems. We developed the Architecture Tradeoff Analysis Method (ATAM ) and from this grew many other methods based on questions that people asked during our application of the ATAM , such as, "What are the significant quality attributes?" (Quality Attribute Workshop) and "How should an architecture be documented?" (Views & Beyond method). Over time, we created a repertoire of methods, technologies, and techniques that grew into a discipline that we now call architecture-centric engineering (ACE). Characteristics of ACE discipline include

• an explicit focus on quality attributes
• direct linkage of architecture to business and mission goals
• explicit involvement of system stakeholders
• a grounding in state-of-the-art quality attribute models and reasoning frameworks and a firm foundation in how these frameworks can guide architectural decisions

Other organizations, such as Bosch, Raytheon, Siemens, and Lockheed Martin, were also exploring and embracing practices in software architecture during these years.

In 2006, I led a study on ultra-large-scale (ULS) systems, which we defined as a system at least one of whose dimensions is of such a large scale that constructing the system using development processes and techniques prevailing at the start of the 21st century is problematic. This study included panelist Doug Schmidt and a number of other experts from an assortment of disciplines. We studied the characteristics of software-reliant systems of the future and learned that

• these systems would be inherently decentralized
• that you'd never be able to fully know the diverse range of requirements, many of which will conflict
• that they'd be continuously evolved, developed, and deployed -- in other words they can't be completed shutdown and restarted
• they'd be heterogeneous and developed and governed by many organizations and stakeholders
• failure will be a normal part of system operation
• people would be a part of the system, as opposed to being "mere" users.

ULS systems were a complete mind change for me. I was thinking that, if we are going to architect these systems effectively, what aspects of our current body of knowledge on software architecture could be applied and what new breakthroughs would be required? Much of what we described in the study report has come to pass; there are ULS systems today with the characteristics we identified. In addition, several game-changing technologies, such as cloud computing, social media, mobile computing, and multicore have emerged that can be used to improve ULS system qualities, as well as to gain competitive advantage.

Many people here at the conference have talked about what's next. Jeromy Carriere said that you can't nail everything down about the architecture when you have an inherently distributed team and everyone has to operate autonomously, but you can agree on the hard decisions and consistent boundaries. So in the future we have to understand

• What are appropriate architectures for socio-technical, cyber-physical systems (especially ones that form critical parts of systems-of-systems and ULS systems)?
• What are quality attributes of these systems that apply today? We need to consider attributes like privacy and we need to incentivize humans in these system to do the right things.
• How to get stakeholders involved when they are so numerous and widely distributed we can't get them in a room to hold a Quality Attribute Workshop or conduct an ATAM? Perhaps we can exploit social media - "crowdsource" the applications of our methods.

Our charge as software architects is to take all the ULS system characteristics and challenges and figure out how we architect successfully in that space.

What's Next

In my next blog posting, I'll provide a transcript of the presentation by Douglas C. Schmidt, former CTO of the SEI and currently a professor of computer science at Vanderbilt University, who will talk about advances in software architecture practice for distributed real-time and embedded systems. Subsequent blog postings will present the talks by Ian Gorton research and development R&D lead Data Intensive Computing at Pacific Northwest National Lab; Bob Schwanke of Siemens Corporate Research; and Jeromy Carriere, chief architect at X.commerce, a subsidiary of eBay.

Additional Resources

The abstract and slides for Linda Northrop's talk are available at
www.sei.cmu.edu/library/abstracts/presentations/northrop-panel-saturn2012.cfm.

The Ultra-Large-Scale Systems report is available at www.sei.cmu.edu/uls/.

For more information about the book Software Architecture in Practice, please visit
www.sei.cmu.edu/library/abstracts/books/0321154959.cfm.

SATURN 2013, presented in collaboration with IEEE Software magazine, will be held April 29 through May 3, 2013 in Minneapolis, Minnesota. For more information see the SATURN 2013 software architecture conference website at www.sei.cmu.edu/saturn/2013.