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…

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.