So I said yesterday that I’m talking about architecture, not architects. However, today I am going to discuss the word architect and the dramatic misuse of the word I see pretty regularly. Or at least, I see now because Paul Preiss of IASA mentioned it when we were hanging out at TechEd.

“Architect” is a noun, not a verb.

Usually, when I hear the term “architect” used as a verb, it’s being used as a synonym for design. In fact, the term “architecture” is also often used as a synonym for design. For example, Arnon wrote this:

Architecture is design (but not all design is architecture)
[Arnon Rotem-Gal-Oz, What’s “Software Architecture”?]

Like Fowler’s description I talked about on Monday, I don’t like this one much either. Architecture isn’t just “good design” which is what Arnon’s description makes it sound like. This begins to get into the title inflation that Alan Cooper wrote about a few years ago. Speaking of Alan, here’s his definition of architect.

The panoply of software construction includes three vital roles: the programmer, the engineer, and the architect. The architect is responsible for determining who the user is, what he or she is trying to accomplish, and what behavior the software must exhibit to satisfy these human goals. The engineer’s responsibilities are comparable but focused on technology. A good engineer can and should ignore human issues, confident that the architect will cover the human side.

That definition of architecture (i.e. what Alan’s idea of an architect does) dovetails pretty nicely with mine. The architect and architecture is the link between the users (i.e. the business) and the software (i.e. IT). The only thing I would change is that as we get deeper into service orientation, interop and connected systems we have lots of process that don’t have direct user involvement. So the “human goals” Alan mentions may not be end user goals so much as business / organization goals. Either way, they certainly aren’t IT goals.

As Dave Welsh said and my dad pointed out in my comments, Business is from Mars, IT is from Venus. But that doesn’t mean they can’t get together. In fact, they have to get together. You show me a system with no business drivers or impact and I’ll show you a failed architecture.

Arnon Rotem-Gal-Oz left a comment yesterday disagreeing with my characterization of engineering vs. architecture problems:

I can’t say I totally agree that it is the software architect’s role to come up with the list of functional requirements. That’s what business analysts or requirement engineers do. The role of the architect is to identify which requirements are important and to surface the significant quality attributes (non-functional requirements) of the system (again, the architect is not the source of the quality attributes but his role is to determine which the most important ones are).

I’m glad Arnon responded. His blog looks pretty interesting and he’s working with Architect MVP Udi Dahan. Subscribed.

However, I wasn’t talking about architects, I was talking about architecture. That may seem like a subtle difference, but between the wide variance in the definition of architecture and the wide variance in types of companies, trying to figure out a general description of architect across all that variance seems like chasing your tail.

So with that in mind, here’s an interesting distinction between building architects and engineers. I think Pat Helland told me this, but I forget. If you know the origin of this comment, please drop me a line.

Engineering is about walls. Architecture is about the space between the walls.

I love that distinction. That leads to my personal definition about architecture in the enterprise and/or software realm:

Architecture is the intersection between business and IT.

Most of what I see passed off as architecture lives purely in the realm of IT. For example, as much as I like Fowler’sPoEAA, I would argue that those are engineering patterns as they have little to do with business. If you’re building a system for an enterprise, there’s a business driver funding that system construction. The business folks don’t really care which domain logic or data access patterns you use. Domain Model vs. Table Module? Table Data Gateway vs. Row Data Gateway? Come on, you think business people care about that?

If a decision doesn’t effect a business person, it’s not an architecture decision. I’m not saying it’s not important – I think the role of the software engineer is critical in large-scale enterprise system design and construction. And I will readily admit that often a single person is responsible for both architecture and engineering. But that doesn’t make them the same activity. As long as we continue to confuse the two disciplines, we hold them both back.

Tomorrow, who’s doing all this architecting?

Personally, I am listening to music chosen for me by Comcast right now and a combination subscription/buy model sounds most interesting to me. Most music I listen to isn’t worth owning. But the RIAA doesn’t seem particularly concerned about music listeners.
[Robert Scoble – Om says tough times ahead for Jobs]

Scoble’s comment that most music isn’t worth owning really resonated with me. I think we can generalize – most content isn’t worth owning. Music, movies, books, etc. I find it interesting how the own vs. rent model works in each of these independent forms of media. For example, most people want to “own” their music, but have no problem renting movies. Most people buy books, even though libraries are pretty prevelent, but I wonder if that’s more related to availability. How many popular books are at the local library to borrow?

I hope we see some dovetailing around the rental model across all content types in the future.

Scott Charney is the Vice President of Trustworthy Computing for Microsoft. If you’ve never seen him present, check out this talk on Critical Infrastructure Protection that he gave at UW last year. Even if you don’t care about critical infrastructure protection (all none of you) you should check out Scott’s talk because he’s a great presenter. Great stories, great connection with the audience and no crutches slides.

So since one of my jobs is to change how we evangelize architecture, I thought it might be good to get some clarity around that term. I doubt there’s a word more varied in definition in this industry than architecture. I often joke is that we call both the person who sets strategic technology direction for the enterprise and the person who decides whether to use a linked list or an array an architect. Maybe it’s not that bad, but “architect” does appear to have a wide range of definitions.

I once moderated a discussion at the Strategic Architect Forum that featured Martin Fowler and this topic came up. Fowler’s definition of architecture was something along the lines of “The activities on a project that you do first because you think they’ll be hard to change”. He suggested that asking someone to show you their architecture was a sure way to find out the parts of the project they thought most important or were most worried about. While that’s interesting, I think it’s harmful to not have a consistent definition of the term across the industry. Everyone knows what a developer does. Nobody knows what an architect does. Well, it seems that way anyway.

Maybe it’s because my degree is in engineering, but much of what we call architecture in the computer industry feels more like engineering than architecture. One of the dictionary definitions of architecture is the “art and science of designing and erecting buildings.” Engineering is defined as “The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems.”

IMO, building a system that has a set of functional requirements (track customers, process orders, etc) and non-functional constraints (sub-second response time, support 10,000 concurrent users, use Microsoft Windows platform, etc) is an engineering problem. Coming up with the lists of functional requirements and non-functional constraints is the architecture problem.

More on this tomorrow…