Architecture at the Intersection

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?

Comments:

As one that works in the defense industry I must say that things look a little different here. Could it be that the "definition" of Architecture (with a big 'A') is domain dependent? I hope not. Personally I prefer Fowler's description (as opposed to definition): Architecture is the set of decisions we hope to get right at the beginning of a project. Obviously only at the end of the project can we know what the quality of our original architecture was.
Is there an intersection between business and IT? To quote Dave Welsh - "Business is from Mars, Technology is from Venus."
Hey Harry, your mailbox is sending out: Final-Recipient: rfc822;harry@devhawk.net Action: failed Status: 5.5.0 Diagnostic-Code: smtp;552 Mailbox size limit exceeded Of course, I don't know if you'll get this either, but please send me an alternate email.. Thanks!
Harry I certainly agree that an architect 'should' sit at the intersection between business and IT to ensure that the resulting architecture aligns with business requirements and priorities. It's not so much bottom-up or top-down as middle-out. That's why I get so frustrated with much of the commentary surrounding SOA which is largely driven from a software development and integration perspective rather than considering the different types of services which constitute a service-oriented approach to IT. Neil