I am a small part of a project of a project empirically investigating how documented software architecture can positively affect a project. In this case the project is the open source Hadoop distributed files system (HDFS). <a href=”http://blog.sei.cmu.edu/post.cfm/measuring-the-impact-of-explicit-architecture-documentation” title=” Rick Kazman’s SEI Blog Post” > describes some of the background and goals.
I’ve been asked recently “what does a design or architecture document look like?” Well, part of this project was document the architecture for Hadoop, and that document can be found here
<a href=”http://kazman.shidler.hawaii.edu/archdoc.html” title=”Hadoop Architecture Doc” > .
Although we often think of Architecture as a high level design, that isn’t really quite right. In design we often have to jumb between high levels of abstraction to more detail, then back again. In short, Architecture tries to capture design aspects most important to satisfying the non functional goals. Some of the description will capture the physical layout of the code modules, e.g. modularity or class structure. Other views may include run time views of data or process flow. Some of the tactics developers might employ could affect architectural properties of the system. They need to have some understanding of those design considerations. That’s the goal of Architecture and architecture documentation.