September 27, 2003

On architecture

Someone recently asked me what architectural approach I liked... a few names were thrown out: Rechtin, Fowler/Cockburn, and Malvaeu/Mowbray (Software Architect Bootcamp).

I respect most of these authors. But there are a lot of problems with "architectural schools of thought". Many assume that "THEY" have the answer. Building big software systems is a lot more complex than that, and it's hard to have a cookbook approach. I find it's hard to come up with a step-by-step model, or "design by checklist".

Therefore I tend to like the "framework" approach to architecture -- one that doesn't dictate steps and realizes that situations differ.

I don't believe in "big architecture up front".

I think there's a fair amount of things that can be discussed up front, but I also believe architects must be involved with the team doing the building, at least for a significant part of the project.

I also don't believe in "UML is the key".

UML is useful in the right business context: you have a team that wants to use it and a culture that values "ceremony" for various reasons (geographically distributed teams, separate maintenance teams, etc). By "ceremony" I mean deliverables that aren't actually executing software, but bubbles and lines on a piece of paper -- it's Alistair Cockburn's term.

Financial companies tend not to value ceremony, I find. They're obsessed with time to market. Telecom companies, on the other hand, love ceremony.

Finally, I'm a believer that "architecture must have context".

Your software system is just a part of a larger organizational system (Alistair Cockburn would say it's a co-operative game within a larger political game). People, culture, management, and skills are first-order success factors - much more so than technology platform and software process.

Perhaps I have a broader view of systems architecture than most. But if you take systems thinking to its logical end, you have to be able to look totality of the system in its context. Its context is yet more systems! An architect can't just focus on technology, because then they're ignoring 2/3 of the system surrounding the technology!

To me, an architect is the bridge between business, people, and technology. Architecture cannot merely be about technology, because then it's just engineering analysis without context (building something right, but not building the right thing). But architecture can't just be about business, people and politics, because then you're not actually building anything.

Here are the most useful categories (with authors and thinkers) on architecture, in my opinion, from high level to low level.

a) Conceptual. I think Zachman framework captures this.
b) Context. I would look at Gerald Weinberg's work on systems thinking and congruent action. Systems architecture is inside a larger context of people, change management, and politics.
c) Process. The most balanced approach is Alistair Cockburn's work on productivity to determine the right process "fit" for your project. How much "ceremony" do you really need -- do you need to write a bunch of thick documents or can you just throw 10 people in a room with a whiteboard and code?.

What does process have to do with architecture? Lots. How you choose to build your software has a tremendous impact on how you specify it. Do you hand down UML models from upon high (not recommended!). Or is it an oversight role?

d) Requirements analysis This is about understanding how to break a problem apart and understand what should be solved in software systems, and what should be solved with changes to human systems. This is a form of "business architecture" (along eith (e)). Here, I like Michael Jackson's work on "problem frames", Gerry Weinberg's work on "ambiguity", Cockburn's work on "use cases", and Kent Beck's work on "user stories")
e) Information modeling. Many authors here: William Kent, David Hay, Terry Halpin, Chris Date, Bill Inmon, Ralph Kimball....
f) Evolutionary / agile development (Martin Fowler's Refactoring, Tom Gilb's work in the 1980s, and Kent Beck's XP writings) help keep the architecture in sync with the development.
g) A software performance engineering (SPE) process should be run concurrently with the main development process. I really liked the treatment in this book.
h) Finally, Computer Science.

At the highest levels, software systems architecture is all about people. At the lowest levels, software systems architecture is all about computer science. Since these are simultaneously the hardest areas in software development, most people tend ignore both (and focus on "design patterns", or a specialized platform).

I like to revisit the classics often: Gray & Reuter's book on Transaction Processing, for example. Another implication , to me, is that systems should take a scientific approach to their development in the small (XP'ers would call this a "spike solution"): don't make blind assumptions, test your hypotheses!

All of these means a very STRONG sense of healthy skepticism and pragmatism. Don't try to "fill every box" of the Zachman framework with a separate document , or to deliver a UML model for every piece of the system, but make sure you're addressing all of the various concerns in some (however informal) way.

A) what you're building (end-state),
B) in what business context (funding, priorities & culture),
C) in what domain (people, concepts, information)
D) with what functional requirements,
E) with what environmental requirements (performance, scalability, availability, platforms)

Some might say this is too much, and way too complicated. Actually, I'm not advocating much other than to pay attention to the reality around you -- it's just that I'm breaking down reality into classifications. That tends to highlight problems that we traditionally put into a black box labelled "here there be monsters".

Posted by stu at September 27, 2003 12:43 AM