Once you articulate a vision of how software architecture could be done well, which includes the creation of models that enable analysis, the next question is, “What analyses can I do?” At this point we can either go down the path of somewhat obscure academic efforts such as rate monotonic analysis or queuing theory and pretend that they are appropriate for mainstream use. Alternately, we could admit that there really aren’t many architecture analyses yet. Let me suggest a third path.

Human brains are remarkable at processing information, but quite dependent on the form of that information. Imagine trying to navigate from NY to LA if you were given an alphabetical listing of the street segments in the country. This would thwart a human but impede a computer only slightly. That’s because people have lots of visual processing capabilities that we use to find a route on a map. Maps are drawn to work with those capabilities, for example by drawing major roads thicker than minor roads.

Analysis of software architecture can do something similar. If a human is searching for single points of failure in an architecture, he’s going to have a hard time if he only looks at the source code. However, the fact that all requests flow through a single load balancer would jump out when looking at an allocation view.

The follow-on question is: Do standard architecture views (like allocation, runtime, and module) provide the right representations for humans to leverage their built-in analysis? I do not (yet) have a way to give a refutable answer to this question, but my experience is that Yes, the standard architecture views are good, but No, they are not ideal. The standard architecture views are general-purpose, which gives them leverage on almost all domains. The flip side to this is that they provide no domain-specific leverage. For example, a calendar has the nice property that all the Mondays are in the same column — a domain-specific encoding that you wouldn’t get from the standard architecture views.

David Garlan recently asked me what I thought about data modeling and its relationship to software architecture. I’m including the answer here because it was effective at articulating some of my philosophical assumptions about software architecture that are not shared by all researchers and practitioners.

This was a question from the CMU software architecture class that I think highlights a common misunderstanding.

Question

Is there any real difference between a component and a connector? I tend to take connectors as:

• Interface and protocol between 2 components
• A component whose major purpose is conveying information

For example, in a typical drawing of the architecture of web services, you wouldn’t see the web server.
(You would see a web container, but that is something different).

This past weekend I was chatting with Ciera Christopher about her work on frameworks. We chatted about Bill Scherlis’s observation that framework interfaces are wide, while traditional library interfaces are narrow. As I mentioned briefly in a prior blog posting There is another difference you see in frameworks — some interfaces are deep, others are shallow.

Framework mini-taxonomy

Here’s my mini-taxonomy of object-oriented frameworks that I have not seen elsewhere. I define frameworks as code that uses the inversion of control pattern, where it “calls you back” (the so-called Hollywood Principle).

1. Domain frameworks. These were the original frameworks, from Smalltalk. They gave you a bunch of objects that worked together, effectively showing you how a domain works. You have specific places where you can extend the framework.

2. Quality attribute frameworks. These are newer. They grab a quality attribute and hoist it such that framework users don’t have to worry about that quality attribute. They are generally domain-neutral. Example: While Struts is just a domain framework (handles web requests), EJB is a quality attribute framework that hoists concurrency, distribution, and coupling pretty well, and security quite poorly.

I have submitted a proposal to give a 3-hour tutorial at Dr. Dobb's Architecture & Design World 2008 July 21-24, 2008. Here is the text of my proposal.

Presentation Abstract:

Software architects build and analyze models to understand systems and reduce risk, and use those models to create and evolve implementations.

Since software development has diverse risks, architects build various kinds of models. They follow a divide-and-conquer strategy, where they “divide” by producing models with a limited view of the system, allowing them better comprehension and reasoning about a particular part or quality of the system. In order to “conquer,” however, they must understand how all the models fit back together to build a system.

So we need ways to make it easier to understand individual parts of a model and relate the parts with the whole.

This session surveys some of the common architecture models and how they fit together. It gives participants the conceptual tools to help them divide models as needed, as well as fit them back together (“conquer” them). Session participants will leave with a coherent mental framework of software architecture, helping them to reconcile business needs with implementation issues, identify risks, and successfully design systems.

Book: Domain Driven Design, Tackling Complexity at the Heart of Software
By: Eric Evans
Publisher: Addison-Wesley, ISBN 0321125215

This is the only book I’ve seen that explains what good object-oriented developers do when they incrementally discover a domain by interviewing subject matter experts and building models. The book uses fictitious dialogues between a developer and a SME, which accurately capture the SME’s initial lack of confidence in the process and the transition into trust and effective collaboration. The book also documents a number of useful patterns.

I got a great email from my friend Alan B. today about my SOA definition blog posting. He too has been concerned about its definition and offers the following to work towards a definition.

• "[F]unctionality is exposed via discoverable and/or published interfaces only". "Picture a cloud with interface jacks sticking out of it, and that’s about it."
• "[C]omponent boundaries (if any) are completely hidden". "In old CBD you could tell where one component ended and another one began. Indeed to assemble an implementation you had to choose components explicitly and compose them."

I'd like to find a definition of Service Oriented Architecture (SOA) as an architectural style. The definitions I've seen so far are not clear enough in that they do not exclude enough.

The Wikipedia's entry is clear enough about lack of consensus:

As you doubtless know, gentle reader, I did my thesis research on software frameworks. Specifically, I found that client code interacted with frameworks quite consistenly, and I developed a technique, called design fragments, to specify patterns of client-framework interaction. Client code is still scattered around many classes, but the design fragments make the connections between these classes apparent.