I’ve always been interested in how you write down software designs so that others can use them. If I’m completely honest I will admit that I find that question more interesting than how you come up with the designs themselves (although I believe the act of writing them down is inextricably intertwined with coming up with them). As Len Bass, Felix Bachmann, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judy Stafford and I work on finishing the second edition of Documenting Software Architectures: Views and Beyond, architecture documentation is on my mind more than usual these days.
I’m in Seoul, Korea, as I write this. Yesterday I rode the Seoul subway across the city to do some shopping, and I used the subway maps in the stations and on the trains to guide my journey. As I sat on the train as it made its way from station to the station, I stared at the system map inside each car:
It occurred to me, as it has in the past, that subway maps are very good everyday examples of architecture documentation. A subway system architecture isn’t a software architecture, for sure, but it’s certainly an architecture. I started wondering what parts of our Views and Beyond approach todocumentation I could recognize in a subway map and the associated pieces of information the public can find in a subway station.
Read the full article in PDF.
- Paul Clements
In the Sept/Oct 2009 Crosstalk issue, Dr. Lui Sha writes about complex cyber-physical systems with mixed criticality–such as defense systems, avionics systems, and medical devices–that need to be resilient against faults, failures, and hazards that are under software control. In his article, Sha reviews some architectural patterns for building resilient systems and points out that patterns are most often captured in architectural models. Sha also asserts that patterns must be adapted for “new application requirements.” In order to provide computer-aided verification of the adaptation of those patterns, formal verification in software modeling languages is recommended. He includes an example of a medical system modeled using the SAE International Architecture Analysis and Design Language (AADL)
The SEI and the U.S. Army Aviation and Missile Research Development and Engineering Center (AMRDEC) recently began a one-year engagement that aims to develop a comprehensive approach to overcome deficiencies with the testing now being done to validate software and system reliability. This comprehensive approach will include the development of a roadmap for the research and application of technologies such as model-based engineering, assurance cases, analytical tools, and industry standards, such as the Architecture Analysis and Design Language (AADL) in the assessment and validation of complex system reliability.
Read more here.
Philips Research and Embedded System Institute (ESI) in the Netherlands have launched this survey of system architects and managers to understand architecture decision making.
Deciding not to architect is an architectural decision. Postponing key architectural decisions while focusing on iteration-at-a-time development and customer-visible features negatively affects the success of large-scale projects. On the other hand, indulging in analysis paralysis in search of the best architecture that will sustain the system for its entire lifespan has the same effect. Continue reading
Video of Len Bass discussing quality attributes here.
Certification programs for software architects abound. How can you tell which programs best measure an architect’s capabilities? Or which ones are right for you? SATURN 2010 plans a track on architecture certification to pull together details on certification programs.