Segmenting Architects

Continuing my examination of the architect role I think we need to point out there is not one architect role my several. There is no such thing as an “Architect”, only an “Architect of something.”

Rather than talk about an “Architect” with one word we really should use two words. The first word describes what they are an Architect of, and the second, well thats the word “Architect”.

Some examples should help:

An Enterprise Architect: One who is concerned with the systems of the enterprise as a whole and how those systems fit together. By definition this architecture in the big and it means making architects at the grand level and not being concerned about details.

So: the Architect might rule that all new systems should be in Java, and not C# but they should not concern themselves with Java coding standards or which design patterns the Java developers are using.

A Solution Architect: these architects get involved in the early discussion about what the solution will look like. They may be responsible for sketching it, they may devise a prototype, they may be involved in customer conversations around requirements because you don’t know what you want until you see the solution; and this means they have some business acumen.

You might say these are the guys who have the initial vision for the final product. Importantly though: they need to stay with the development from start to finish. They can’t walk away once they have sketched out the initial vision. They can hand over to someone else with time but they need to keep skin in the game to have legitimacy and so they learn how effective their solutions were.

Ideally, when you start working on a product/project you want one of these guys involved but you want them to change hats as the work increases and become: a software architect.

A Software Architect: This is were my interest really lies, these are the guys who are custodian of the design vision for a piece of software, or application if you prefer. They are responsible for ensuring the whole team shares the same idea of how the software is designed. As such they are more responsible than most for how the software looks (inside) now and in the future but they are not solely responsible. Software Architects should have more experience than other team members but their responsibility is to lead through teaching.

Software Architects must implement, they need code under their finger nails if they are to retain their knowledge and legitimacy.

Their work includes:

• Being a Senior Developer, hands on, they should have code under their finger nails
• Educating junior developers, sharing their knowledge, mentoring, teaching and training
• Guiding development towards a consistent and sustainable architecture
• Holding responsible for the shared technical vision and ensure it is shared
• Dealing with Conway’s Law: interfacing with non-technical manager types to ensure the technical and organisational architecture are compatible

You might like to note I’m not saying they create the design, they do not. Their responsibility is to help the team create a shared understanding which is the design, and then become custodian of that vision.

I’ve avoided mention of roles like Network Architect, these might well exist but not always. Maybe you can think of some more architects in your organization.

I’m also avoiding the term System Architect because you have to define what you mean by “system” - where does it start and where does it end? Potentially System Architect is “Architect of Everything”.

These roles will also vary by organisation size. In a large organisation you might find these roles exist as distinct roles, in small organisations they are likely to overlap. So an Enterprise Architect also needs to do some Network Architect.

This is understandable but problems come when one individual is so busy wearing many hats that they neglect some aspect of one of the roles. They try and do two or more roles and end up doing one (or all) badly. Consider an Enterprise Architect who combines his role with being a Software Architect at the same time. If the Enterprise aspect dominates they may neglect involvement with coding the application so they cannot speak with experience about the application. Or, the other way round: they are so busy being a Software Architect that they don’t keep up to date with emerging trends and neglect the Enterprise side.

Architects who aren't

Having cleared up some preliminaries, i.e. What is architecture?, we are getting closer to the big question: what do architects do? But I’ll continuing to take this piecemeal. In this blog entry I’d like to dismiss too groups of people who carry the Architect title but are not Architects.

The first group are “Architects by Seniority.” Some years ago I held a post with the title “Senior Software Engineer.” At first I though this might mean I was “the senior software engineer” but quickly realised I was one of many “senior software engineers.” The company conferred this title on anyone who had more than a few, about five, years of experience working as a software engineer. Or as I used to joke “anyone over 30.”

Some Architects get their titles the same way. My guess is this is more common on the services side of the industry were engineers are sold by the hour to clients and Architects have a higher billing rate.

A few months ago I was told it was common in the Indian outsourcing industry to confer the title Architect on engineers with 3 years experience. This is one data point, I don’t know how common that really is. Anyone out their know?

Unfortunately, some of the people who are given the title Architect simply because they have been around a while let it go to their heads. Which brings us to the second group who are Architects in title but not in practice: “Divorced Architects” or, as I think Joel Spolsky christened them “Astronaut Architects.”

These are Architects who sit around thinking big thoughts about “the system” but aren’t connected with what is actually happening. Just because you have the title “Architect” does not give you the knowledge or right to tell people what to do without doing it yourself. As Jim Coplien and Neil Harrison put it “Architect also Implements.”

If you are lucky these architects are pretty much harmless, they cost the company money, the developers tip their flat-cap to them in the morning but ignore them when they do work. If your unlucky their crazy ideas result in a messed up system and their egos get in the way.

Years ago I worked on rail privatisation, the Railtrack A-Plan timetabling system to be exact. It was on Windows NT with Sybase (yes, thats how long ago it was) in C and C++ with a little Visual Basic. 120 people worked on the system at the peak, of which four were architects and about 12 were coders, OK, maybe 16 if you include the SQL and VB guys.

But the architects came from a mainframe Cobol background so they designed a batch processing system, set down constraints and ways of working which just didn’t make sense for a client-server system. The company had a ISO-9000 system in place with lots of management so the result of this architecture was a lots of problems. Once they got into the code the developer just did what they wanted, the architects would never know because a) they wouldn’t get their hands dirty with code and b) they didn’t really know C let alone C++.

The project wound down and went into maintenance mode so I left. A couple of years later I found myself back on a much reduced project to redevelop parts of the system. Now we had about five developers, one architect part-time and a couple of dozen people tops.

We mostly ignored the architect, he saw one system and we saw another. ISO-9000 was nominally in place but widely ignored. The process worked a lot better. Occasionally we wrote a formal document to keep the formal process and architect happy but the real documentation was contained in “Rough Guides” which didn’t formally exist.

Moral of the story: Just because you are called an architect, just because you go to meetings, you aren’t an architect.

Published: 97 Things every programmer should know

Kevlin Henney’s “97 Things every programmer should know” (the website) project has now advanced from website to book. Yes, you can buy a physical copy of “97 Things every programmer should know” (the book) from all good, erh, online bookshops - I’m guessing it won’t be in your local Borders or Waterstones.



As I’ve mentioned before two of the 97 “things” are mine. Of which my favourite is “two wrongs make a right.”

What is scary is that I know many of the contributors - I mean, well enough to have drunk beer with at least of dozen of the, perhaps 30, contributors.

Many years ago I overheard a wise old programmer telling some recent graduates: “There are only 3,000 good programmers in the world... and they know each other.” OK, I can’t remember if it was 1,000, 2000, 5,000 or 8,000, I do remember it was thousands, not hundreds and not tens of thousands. I’ve no idea how accurate he was, but I’m more and more convinced of the second bit. The best guys do know each other.

And what 97 Things shows is: Kevlin knows more of them than I do which means he’s probably a better programmer than me.

Architecture or Design?

I mentioned the A word in my last post (Are there any System Analysts out there?). As regular readers might have noticed, I have over the years of this blog taken the odd pot-shot at Architects. But I’ve avoided direct comment on architect and architecture. Somehow it feels the time has come to address this debate.

I should say before we go too far that when I talk about Architecture I’m thinking software architecture. And when I talk about Architects I’m thinking about the architecture of software. I’m not thinking of network architecture, or business architecture, of course these topics are connected with software architecture but we need to narrow the topic down a little.

Nor am I talking about system architecture and system architects. System architecture is a particularly confusing concept because we first have to define the size and scope of our system: a piece of software is a system, so too is the computer it runs on and so too is the combination of both. So lets agree to leave system architecture to one side too.

Before we can tackle to subject of Architects I think we need to get a better understanding of architecture. So I’ll defer architects to another day and think about the nature of architecture today.

If we look up architecture in the dictionary then we find its all about design. Architecture is design. The word “architecture” (like the word “design”) is both a noun and a verb. Architecture is something you do (we may create a proposed architecture) and it is something you have, you software has an architecture whether it was design or not.

As an experiment, whenever you hear someone talking of “software architecture” mentally substitute the words “software design”. I don’t think you’ll find any loss of meaning.

Both design and architecture are, certainly in software systems and frequently elsewhere, part a deliberate attempt to create a particular outcome, they are also part emergent. How much is deliberate and how much emergent varies. As a result, the architecture (design) we finish with is something different to that which was planned.


(As an aside, we’ll talk about another time, that diagram is based on one from one of my favourite books, The Rise and Fall of Strategic Planning. There are close parallels to the way we relate to, and go about creating software architecture and business strategy.)

So architecture is design. Is it anything else? Anything more?

Architecture is more than design because the word architecture implies something bigger. An architecture is more than a design. You architect buildings but you design tents. Some of this “architecture as grand design” is just that, aggrandisement. It an attempt to make design into something grander. Personally I think design is a worthy and grand thing itself, you don’t need to aggrandise it any more.

In a software context there is the question of inside and outside. The term “software design” is often used to describe the external properties of the software, how it looks, feels, perhaps the features it offers. While
architecture often refers to the inside: how the thing hangs together and work. So there are “user interaction designers” but I’ve never heard of a “user interaction architect”.

I have long argued that software design exists in every line of code. Writing code is designing software. Certainly this fits with the “architecture is the inside” line of thinking but it doesn’t fit with so well with “architecture as bigger”. Somehow, while I happily argue that the choice between a FOR-loop and a WHILE-loop is an act of design, it seems wrong to argue that this is an act of architecture. But, according to own logic, that is what I am arguing.

The architect Ludwig Mies van der Rohe is reported to have said: “God is in the detail”. He wasn’t the first to use this quote but it does summarise his approach to architecture. He was an architect who was concerned about details. There was no lower bound for his architecture. So on that basis, Yes, whether you use a FOR-loop or a WHILE-loop, a bunch of IF-statements or a CASE-statement, you are making architectural decisions.

Architecture is design, it scopes up to the very big but it also includes the small details, because you just don’t know when the small details are going to become important.

Are there any System Analysts out there?

Has anyone met a System Analysts lately?

I ask because I’ve been looking for over a year and can’t find one. I should say immediately I’m not looking to hire one, rather I want to find out what they do. I’ve looked and I’ve asked and the role seems to have disappeared from organizations. Or rather, perhaps I should say the title has disappeared; the role still exists in some places, for better or worse.

My belief is that the System Analyst role has been divided up between the Business Analyst and Architect roles. Like a System Analyst, a Business Analyst will look at what is required from a computer system but they (should) look predominantly from a business perspective, not a technology perspective. Like a System Analyst, an Architect will look at the current systems and how it they work and fit together and how they should work and what new work is needed.

(Note: Of course the Architect’s role is itself a complex issue and needs subdividing, that will need to wait for another blog entry.)

I’ve run this idea past a number of people in the last year and I’ve yet to have anyone seriously disagree. In order to validate it further I went to my old (1992) copy of Roger Pressman’s Software Engineering [[link]] and found the following definition of System Analysis:

“... system analysis defines the roles of each element in a computer-based system, ultimately allocating the role that software will play”

Pressman doesn’t define the System Analyst’s role still, it seems logical that a System Analyst is someone who does system analysis. Later in the book he gives the list of the objectives of system analysis:

1. Identify customer need
2. Evaluate the system concept for feasibility
3. Perform economic and technical analysis
4. Allocate functions to hardware, software, people, database, and other system elements
5. Establish cost and schedule constraints
6. Create a system definition that forms the foundation for all subsequent engineering work

If you look at that list 1, 3 (economic) and 5 fit squarely in the BA function while 2, 3 (technical) and 6 fit in the Architect role. The BA is concerned with the people element of item 4 (and the implied process change) while the Architect is concerned with hardware, software, db, etc. Of course the two functions need to work together here because there are trade-offs.

So that’s it, System Analysts no longer exist, an open and shut case. Except...

I’ve also observed what BAs do and I think some BAs are filling a System Analyst function while holding a Business Analyst title. This is wrong. A Business Analyst should be concerned with the business need and what will deliver value to the business.

In other words: BA should be concerned with the “what”, not the “how”.

When a BA steps into the “how” they are engaging in design and enter the world of Engineers and Architects. There are, at least, three good reasons why they must not do this:

1. By specifying the “what” they restrict the options available for the development team which means they prematurely close off discussion of how needs can be best and most effectively satisfied.
2. Engineers and Architects tasked with designing solutions have the training, experience and skills necessary. One wonders if the BA who suggests “how” has equal competences, and if they do, why are they working as a BA rather than an engineer?
3. Specifying the how undermines the engineering team and encourages them to take a box-ticking approach. This in turn affects quality.

In undertaking design (synthesis) they are removing their attention from analysing the what - making more work for themselves. Synthesis and analysis are very different activities and are deliberately separated.

(Of course, on a small team the same person may find themselves engaged in analysis one week and the following week tasked with creating the solution. In such cases it is still worth considering the two as separate activities and getting some mental separation.)

I’m commenting here on what I’ve observed, its not that I have a dim view of System Analysts - if there are any out there I’d love to hear your comments. In fact, there are two reason why I’d like to see the return of the System Analyst role.

Firstly, as Tom Gilb would be quick to point out: there is an important role for System Engineering in the IT development. IT work which is too tightly focused on a piece of software, or a point solution, risks ignoring the role IT plays in the wider system. There is a need for more System Engineering in our IT development efforts and part of that is System Analysis (although maybe a different type of system analysis.)

Which raises the question: who in a typical IT development team is best positioned to take on the wider system, interdisciplinary and engineering questions which arise in large development?

That sounds like an Architect to me.

Secondly, in so much as a System Analyst is one type of Architect I think it’s a better title because it is less prone to ego-bloat. Unfortunately, some people let the title “Architect” go to their head. Once they get to be “An Architect” they see no reason to code any more or get their hands dirty with detail. They prefer to sit alone, draw UML diagrams and issue edicts. I’ve heard them called “space cadet” or “astronaut” architects. They become divorced from that is really happening.

So purely on the grounds that I suspect the “System Analyst” title less prone to pomposity than “Architect” I think it should be used.