Lessons Learned about Software Architecture

NEWS AT SEI

This library item is related to the following area(s) of work:

Software Architecture

This article was originally published in News at SEI on: July 1, 2007

“Architecture used to be a fairly ill-defined discipline. No one had the title of ‘architect.’ It was just a role that someone played—usually by the most experienced technical guys around and usually they were the oldest guys there—the ones who had experienced the most pain and been through the wars the longest. We all looked to them for guidance and that was architecture. Back then, it was truly an emerging discipline.” That’s how Jeromy Carriere, currently chief architect at VistaPrint, describes the art of software architecture in the 1990s.

Much has changed since then. Over the years, Carriere has worked in several industries as a software architect and learned many lessons about architecture and its importance to system success. During his keynote address1 at this year’s SEI Software Architecture User Network (SATURN) Workshop, he recounted these lessons and supported them with his own real-world experience:

  • Big systems are hard to get right. Thinking about “architecture stuff” up front is necessary for success.
  • Architecture is the bearer of quality, but reasoning about architecture is actually reasoning about the potential of a system.
  • Performance and flexibility really do trade off against each other.
  • Reprioritizing architectural qualities is extremely risky.
  • Don’t forget “saleability” and “marketecture.” They can help you sell a system to upper management before it is built, even if they offend a “pure” architecture sensibility.
  • Autonomy of organizations and systems is paramount, and this autonomy happens to be the foundational principle of service-oriented architecture. 
  • If you don’t know where you’re going, you’re not going to get there—regardless of how good your map is.
  • Technology doesn’t matter. What does matter are people, the process, and the consistency of practice.
  • Architecture validation is critical but hard to institutionalize—even in a process-oriented organization.
  • The deepest problems in IT are still communication and understanding.
  • Don’t let “pragmatism” become a disguise for shortsightedness.

Carriere sees continuing potential in architecture reconstruction, seeing it as analogous to an archeological dig. “Archeology is when guys go out and dig stuff up, find artifacts, and then try to posit hypotheses about what human process created them. How did each artifact get there? And in fact not just the human process but also what environmental process contributed to producing that artifact the way it is, where it sits, and how it works. Software architecture reconstruction is exactly the same. We go into the code and we dig around and try to figure out how what design decisions produced that shadow of a process.”

Through his work with architecture reconstruction and working on multiple and varying types of systems, Carriere has found that reasoning about architecture is really reasoning about the potential of a system based on that architecture. “I can take a great architecture, analyze it, prove that it has all these great qualities, but then somebody goes off and builds it, and it’s in that building process that we often lose our grip on what it was we we’re trying to achieve. That’s why architecture reconstruction and architectural conformance are so important. They can give us the connectivity—or traceability—from design decision to execution that we need to make architecture truly valuable.” Carriere’s experience has also taught him that, because software architects eventually move on and find other roles, companies must find some thread of consistency through the systems they build. If they don’t, organizational scalability is fundamentally threatened.

According to Carriere, the four areas of the SEI’s current architecture research—systems of systems, architecture-based evolution, architecture competence, and economics-based architecture—respond to all of these lessons and to the issues faced by software architects in the field today.

Benefits of that research are working for people all over the world—at organizations like Ericsson, Samsung, and Sandia National Laboratories. At SATURN 2007, employees from those companies explained how SEI technologies and methods are working for them: at Ericsson, the SEI Quality Attribute Workshop (QAW) and work in tactics, patterns, and software architecture documentation; at Samsung, SEI Attribute-Driven Design; and at Sandia, the QAW. While some organizations—such as the U.S. Army—reported using the SEI Architecture Tradeoff Analysis Method® (ATAM®) as-is to evaluate their architectures, others like Raytheon, Wells Fargo, and Microsoft have customized the QAW and the ATAM to create unique evaluation methods. During a panel discussion on using the ATAM, Raytheon personnel presented ATO Lite—a method consisting of a subset of ATAM activities—that helps architects develop robust architectures in a timely and cost-effective way. And a Wells Fargo architect described how the company has leveraged both the QAW and the ATAM to create a hybrid evaluation method for exploring quality attribute concerns when a full ATAM is not possible. Carriere described an ATAM-related method that he developed while at Microsoft—the Lightweight Architecture Alternative Assessment Method (LAAAM). The LAAAM incorporates the scenario-driven perspective of ATAM into a lightweight approach to assessing high-level architectural decisions.

Workshop attendance doubled from 2006 to 2007—a trend that exemplifies the growing importance of architecture around the world. Many participants came from outside the United States—from Ireland, South Korea, Mexico, Australia, Japan, and Britain.

SATURN 2008 is scheduled for April 28 through May 1 in Pittsburgh, Pennsylvania. Planned topics include case studies and lessons learned in applying SEI software architecture methods, improving the state of architectural practices across an organization, evolving an architecture along with business and mission goals, and future directions in software architecture technology.

This year’s organizers are looking for up-to-date information on how companies are using both SEI and non-SEI methods and technologies to improve their software architecture practices and competence. If you would like to tell your story at this year’s workshop, submit your presentation or tutorial proposal at http://www.sei.cmu.edu/architecture/saturn/. The deadline for submissions is December 7.

1    To see the slides from his keynote presentation, go to the library.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to del.ico.us  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us

info@sei.cmu.edu

412-268-5800

Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.