Last week, we presented the first posting in a series from a panel at SATURN 2012 titled "Reflections on 20 Years of Software Architecture." In her remarks on the panel summarizing the evolution of software architecture work at the SEI, Linda Northrop, director of the SEI's Research, Technology, and System Solutions (RTSS) Program, referred to the steady growth in system scale and complexity over the past two decades and the increased awareness of architecture as a primary means for achieving desired quality attributes, such as performance, reliability, evolvability, and security.

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 posting--the second in a series--provides a lightly edited transcription of a presentation by Douglas C. Schmidt, former chief technology officer of the SEI and currently a professor of computer science at Vanderbilt University, who discussed advances in software architecture practice for distributed real-time embedded systems during the past two decades.

Reflections on 20 Years of Architecture for Distributed Real-time & Embedded Systems as Presented by Douglas C. Schmidt

My talk focuses on advances in software architecture practice for distributed real-time embedded (DRE) systems, with a retrospective of the past 20 years in that space. The essence of a DRE system is that the right answer delivered too late becomes the wrong answer. There are many military examples of DRE systems, such as integrated air and missile defense, as well as civilian examples, such as SCADA (supervisory control and data acquisition), air-traffic management, and electronic trading systems.

Twenty years ago, many engineers developing DRE systems didn't understand what architecture meant from a software perspective. I'll never forget the first time I went to a meeting at McDonnell-Douglas where I was employed to help develop a common software architecture for their legacy avionics mission computing systems, and I asked, "Show me your architecture?" They put up a circuit diagram, and I thought, "Boy, this is going to be a challenging project!" In legacy DRE systems, operational performance was paramount, whereas software issues were secondary, so there was much uncertainty and confusion about key software design and implementation concerns. It was hard to sort those things out 20 years ago since we lacked a common vocabulary and organizing paradigm for reasoning about software architecture for DRE systems.

Perhaps due to the lack of awareness of software concerns, engineers developing DRE systems in the early- to mid-1990s tended to substitute adherence to particular standards or products for a thorough understanding of software architecture. For example, there was a push to apply standards, such as early versions of the CORBA (Common Object Request Broker Architecture) standard. Unfortunately, the CORBA specification initially de-emphasized implementation details to the point where standard CORBA object request brokers couldn't be used effectively for DRE systems because they were woefully underspecified with respect to key quality attributes that Linda mentioned in her panel presentation.

Another thing that was occurring in the early 1990s was a focus on domain-specific approaches to architecture. For example, there was a project at DARPA called Domain-Specific Software Architecture (DSSA) that examined how to structure software by focusing on domain-specific entities such as radars, trackers, launchers, etc. DSSA was a useful paradigm; in fact, it foreshadowed today's interest in domain-specific modeling languages, model-driven engineering, and domain-driven design. There was a tendency 20 years ago, however, to overlook the underlying reusable domain-independent abstractions that weren't adequately captured by the DSSA paradigm. These domain-independent abstractions included reactive event demultiplexers and active object concurrency models that exist at a lower level than a specific application domain.

During the latter part of the 1990s, key advances in software architecture for DRE systems stemmed from the growing focus on design and architecture patterns. The classic Gang of Four patterns catalog was published in 1994, followed by the first Pattern-Oriented Software Architecture (POSA) volume in 1996. As a result, engineers developing DRE systems began adopting common vocabularies to reason intentionally about software architecture from a practitioner perspective. For example, experience gained from work at Boeing, Lockheed Martin, Raytheon, Siemens, and many telecom equipment providers showed the benefits of applying patterns to describe product lines and common software architectures for DRE systems.

The growing awareness of patterns more clearly differentiated design aspects from implementation aspects. Combining this distinction with a focus on optimizing and hardening DRE systems by choosing the right patterns to implement also helped improve the quality attribute support of DRE system standards, such as Real-time CORBA and the Data Distribution Service. This experience demonstrated that pattern-oriented architectural abstractions could scale up to larger, networked topologies, yet still assure traditional real-time concerns, such as avoiding priority inversion and ensuring schedulability.

By the end of the 1990s, the DRE systems community recognized that patterns enabled software developers and systems engineers to understand how fundamental abstractions could be reused in a domain-independent manner, as well as combined to support integrated higher-level domain-specific abstractions. The availability of popular, pattern-oriented, domain-independent middleware toolkits (such as ACE and TAO) in open-source form increased awareness of the value of applying patterns to production DRE systems.

Starting around the year 2000, the patterns community began documenting software architectures for DRE systems more cohesively via pattern languages, which provide a vocabulary and process for the orderly resolution of software development problems. For example, the POSA4 book describes brokers, publishers/subscribers, and messaging as key architectural elements in a pattern language for distributed computing. These types of pattern languages codify, coordinate, and generate larger ensembles of software and system elements than individual patterns and pattern catalogs.

In recent years, engineers have applied various domain-specific modeling languages and tools (such as the Generic Modeling Environment and associated model-driven engineering technologies) to automate various elements of pattern languages. The combination of pattern languages and model-driven tools has enabled the analysis and synthesis of frameworks and components that are more effective than earlier computer-aided software engineering (CASE) tools.

So, over the past 20 years of research and transition efforts, software engineers have increasingly identified and applied patterns and pattern languages to document architectures and build DRE systems that are directly relevant to application developers and practitioners. The knowledge and technology base has matured to the point where the techniques and tools we have now provide substantial advantage over what was available 20 years ago, though they are no substitute for experience and insight.

Looking ahead, I think we're just beginning to comprehend and codify the pattern languages and architectures for the current generation of network-centric DRE systems-of-systems, as well as the next generation of ultra-large-scale (ULS) systems that Linda Northrop discussed in her panel presentation. As we reach this scale, complexity, and mission-criticality, we need the software architecture community to step forward and begin understanding and documenting the appropriate solutions in pattern form. Right now we know many anti-patterns for how not to build these types of systems, but we still struggle with how to build them at scale and reason about how they'll work with all the quality attributes they need to succeed.

What's Next

In my next blog posting, I'll provide a transcript of presentations 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 Douglas C. Schmidt's talk are available at
www.sei.cmu.edu/library/abstracts/presentations/schmidt-panel-saturn2012.cfm.

Many patterns and pattern languages--as well as open-source implementations of these patterns--for DRE systems are available at www.dre.vanderbilt.edu/~schmidt/patterns.html.

Douglas C. Schmidt is teaching a massively open online course (MOOC) on patterns and frameworks for concurrent and networked software for Coursera starting February, 2013. Course information and instructions for free registration are available at https://www.coursera.org/browse?source=deprecated_spark_cdp.

A Software Engineering Radio podcast describing a pattern language for distributed systems is available at www.se-radio.net/2007/07/episode-63-a-pattern-language-for-distributed-systems-with-henney-and-buschmann/.

A podcast describing the applications of patterns and pattern languages to DRE systems is available at www.se-radio.net/2006/01/episode-3-interview-doug-schmidt/.

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.