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?

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…

So my time off ended a month ago, but I haven’t blogged significantly in over two months. New kid + new job + new house will do that to you. However, I spent the time this morning upgrading DevHawk to the new 1.8 version of dasBlog and I’m ready to jump back in.

Back when I was still on leave, my new boss John deVadoss this to say about my new job:

Our current thinking is that Harry will focus on two top-level areas

1. Being the storyteller (Metropolis, Connected Systems etc)
2. Changing the way we evangelize Architecture – its not all about n-dimensional frameworks, with m layers of abstraction, about perspectives and viewpoints, with n-layers of capability mappings, and enterprise frameworks up and down the wazooo, blah blah blah.

I loved #2. Architecture is such different things to different people (more on that later) but I thought John’s description about what it’s not all about was priceless.

After a six month silence, Dad posted about what he called Business Oriented Architecture (BOA?):

If I had to guess what a service oriented architecture will eventually look like, I would guess that it would reflect the business architecture – Business Oriented Architecture (BOA). Business organizations have evolved over many centuries into a number of common “departments” – sales, accounting, personnel, etc. Perhaps that is a good starting place for services.

John forwarded me a post from Richard Veryard where he comments on Dad’s post:

The issues addressed in my book are now becoming mainstream as the technological agenda of service-oriented architecture (SOA) starts to converge with the strategic agenda of the service-based business (SBB). This implies an approach to business strategy that involves dynamically managing the geometry of the business. (To achieve a fully adaptive enterprise we typically need to implement a variable geometry.) We can find elements of this thinking in some of the methodologies coming out of IBM and Microsoft, although from what I’ve seen so far I don’t think any of these methodologies go far enough.

Hal calls this Business Oriented Architecture. If anything, I’d prefer to call it Architecture-Oriented Business. As Hal indicates, this calls for architectural thinking at the business level, which need to be aligned with architectural thinking at the information/software level.

This comes back around to the whole SOA top-down vs. bottom-up argument. Something I’ll comment further on when I’m not up to my armits in moving boxes.

Jim Newkirk has released an alpha version of a utility to convert NUnit tests to VSTS tests. What he doesn’t mention in the post is that he’s using GAT to integrate this conversion functionality into VS05. Basically this conversion is an “unbounded recipe” which means that any time you right click on an item in the solution explorer, the NUnit Converter uses Visual Studio’s CodeModel functionality to analyze the contents of the file. If the file is a C# file and has any NUnit test fixtures in it, NUnit Converter adds a “Convert NUnit Test Code” item to the context menu.

From a cursory glance at the code (which Jim was kind enough to send me) it doesn’t look like it took very much GAT code to integrate into VS. Of all the files in the solution, there are only three that relate to GAT – the Conversion Action (i.e. the code that initiates the NUnit -> VSTS conversion when you select the context menu item), the Conversion Recipe Reference (i.e. the code that determines if the conversion menu item should be added to the context menu) and the Selected Project Item Provider (i.e. the code that retrieves the selected file from the Solution Explorer). There’s also the XML file that defines the recipes. Everything else as far as I can tell handles the conversion itself and has nothing to do with GAT.

It’s cool to see a real-world usage of GAT and that using GAT is a pretty low-impact effort given the VS integration benefits it provides.