Rhino Research

In general I think the work done by the SEI is valuable and an asset to our field. My main concern is that the nature of projects they tend to be involved with is different than the ones I see. My guess is that they help out on the development of more tanks, electrical grids, and avionics systems than I do. I tend to see business systems (IT, banking) and web applications. The good news is that despite these differences I think we are describing different parts of the elephant rather than describing different animals.

When I started my book I had a boogeyman in mind: the chief architect.

I searched around and could not find information on how long a Quality Attribute Workshop (QAW) should take. My guess was between 1 and 3 days, depending on the project size, state of the design, and number of stakeholders.

The risk-centric approach I propose isn’t exactly what the Software Engineering Institute proposes. They tend to be more bureaucratic and methodical, which makes sense if you’re developing projects like the electric grid, a fighter jet, or even just software that controls the brakes in your car. The QAW, however, is one of their lighter-weight techniques, especially compared to things like the ATAM. My work assumes you know what the risks are, so the QAW is a nice compliment in that it describes how to solicit and prioritize quality attributes from a diverse group of stakeholders.

I asked Tony Lattanze, one of the authors of the QAW, for advice on its duration. Here’s his reply:

I’m having a great discussion with Larry Maccherone over on his blog. I’ve included my reply here, which will make more sense if you’ve read his original posting. Excerpts from his posting are in the block quotes below.

Hi Larry,

Thanks for chatting with me about this.

This is a letter to my friend Larry Maccherone, who is an expert on software processes and Agile in particular.

Larry,

Here’s something I’d like your opinion on, and it might become another blog post for you. I believe we should try to understand engineering activities separately from management activities.

Following architecture-centric design means that you are using the architecture to ensure a property or to achieve a quality attribute. Code can diverge from the design, often unintentionally, and disrupt your plans. We can use architecture hoisting to ensure that the code has those same properties or qualities as the design.

Architecture hoisting is the direct ownership, management, or guarantee by the architecture of a feature, property, or quality attribute. It lets developers depend on the architecture for the hoisted feature, property, or quality.

My friend Nels Beckman is writing on how to do functional programming in Java. He asked me why I thought people build systems that follow an OO decomposition. Since my boss has been relentless about getting the book done, I have not posted a blog recently, so here’s my note to Nels.

When you decompose systems, at some point you have a chunk (module, component, …) that you want to structure internally. How do you do that? One of the strategies is to mirror domain concepts.

Components and connectors are the backbone of the runtime view in software architecture, but the connector appears to play second fiddle to the component. The 1968 NATO conference that coined the term “software architecture” specifically asked for components, but did not mention connectors. Components are shown as two-dimensional boxes, while connectors must make do as one-dimensional lines.

Despite the perception of connectors as simple data movers, real work can be done in connectors. Connectors can convert, transform, or translate datatypes between components. They can adapt protocols and mediate between a collection of components. They can broadcast events, possibly cleaning up duplicate events or prioritizing important ones. Significantly, they can do the work that enables quality attributes, such as encryption, compression, synchronization / replication, and threadsafe communication. It is hard to imagine systems achieving qualities like reliability, durability, latency, and auditability if their connectors are not contributing.

You may recall writing your first essays in high school and struggling with introductions. There was probably some advice about going from the general and honing in on your specific topic, and ending up with a topic sentence. Over time this got less painful (both for you the writer and whoever had to suffer through your essays), but the introduction to a book is a whole new world of hurt. You’re trying to hook in and interest folks who come with any number of prejudices about your topic, experts and novices, academics and practitioners.

If you decided to create some abstractions to explain the architecture of existing software, it is unlikely that you would end up with the standard set of architecture abstractions (components, connectors, ports, roles, etc.) The standard set of architecture abstractions seeks to point future software development in the right direction, and so it is prescriptive in that it encourages encapsulation and clear channels of communication.

When we document existing systems, we are simply describing them as they are.

A while back I posted a list of things that are hard about software architecture, and this posting is an elaboration on that list that will make its way into the software architecture book.

Comments on this list are welcome. In fact, if you have a pet peeve about software architecture then it can probably be refactored into an entry in this list.