Chief Architect

What does the job title ChiefArchitect mean? What does a ChiefArchitect do? Should a company even have a ChiefArchitect at all? Does it need to be one person?

PeterCoad describes the need for a ChiefArchitect. XP (ExtremeProgramming) has no ChiefArchitect. But most developments have someone like this, and it's good to account for why. Here are some of the things I've found myself called on to do that got called ChiefArchitect-ing.

Visionary: Most business folk don't really have a good idea what they want the thing being developed to be. Like blind men, they can't quite understand the elephant. This causes politics and other confusions. Someone needs to formulate and communicate a vision of the goal that the other developers can buy into and work towards. Yeah, it's mainly bullshit, but it still wants doing.

Glue Maker: developments need some kind of paradigm within which developers will work. Perhaps in the smalltalk world this is just smalltalk, but in other lands there are many choices to be made. Even if you have an underlying component standard - Corba, COM, Datablades, Beans, Agents, Voyager, JINI, or some of their many ancillaries and addendums, there's work to do to adapt them to the way the business works. MultiCaster is an example of such work.

Methodologist: XP, it appears, just happened :-) Other methodologies had someone intentionally sit down and invent them. But even if you're using a ready-made methodology, someone needs to choose which one is suitable and then communicate and adapt it to the business.

Mentor: Most developments involve people of varying skill levels and abilities. Someone needs to help the lesser experienced folk find a direction in which to grow that's relevant to the business.

Language Lawyer: To use C++, Perl, Java, and other big languages, someone needs to provide assistance and define standards and subsets relevant to the business. They should actually understand the languages and have good experience with the ins and outs of them and the tools that build and supports them.

Coach?: As per XP, I think. (I don't believe this needs to be an architect)

-- PeterMerel

Valuable roles all, and roles that C3 (and XP) embrace. But none of them look to this reviewer like roles calling for the name "ChiefArchitect". -- RonJeffries

Perhaps not - that's just what they got called. So if XP accounts for them all, perhaps it has a ChiefArchitect after all? -- Pete

The roles that CA fills - Language Lawyer, Glue Maker, etc. - are definitely important. But it's preferable to allow these roles to more naturally arise, as opposed to assigning them explicitly from the start.

Blessing an individual as "chief" is good for him ... but bad for everyone else, and bad for the project. What you call people and processes does matter.

Not universally true. Many people cringe when called names like leader or chief. Having authority necessarily means having responsibility, although the reverse isn't true

And perhaps there's the danger that having a designated position will encourage people to become complacent and rely on one person to do all of something.

But specialization is important. And there are many common cases where non-emerging specialization is useful - testers, build masters, documentors, etc. Why should ChiefArchitect be an exception?

My experience with chief architects is very different from Peter’s. I have a very negative reaction to chief architect. On the projects I have seen the chief architect has either been so far up at the top of an ivory tower that the actual designing of the system is done by the team anyway or is such an overbearing brut of a man that the team builds the system contrary to his design out of spite.

At ChryslerComprehensiveCompensation, the two chief architects were let go when Kent was brought in. At that time, I was approached by Chrysler and asked to be the chief architect. I was flabbergasted! I had been working hard during the time between stopping the old project and restarting with XP to improve team unity and spirit. The manager had noticed and decided I should be promoted! I asked him if he had been really listening to what I was saying. I made an enemy that day by turning him down flat. I told him that if we could not design and build this payroll system as a team of equals than we would be right back where we started except that we would have lost two years time. C3 didn’t have a chief architect and things worked out fine.

I had a similar experience at the VcapsProject. Even after proving the value of most of the XP practices, I still could not convince the manager that we had no need for a chief architect. She actually appointed two chief architects. I myself simply refused to serve. The other chief architect ended up leaving. After that, there was no chief architect and things worked out fine. -- DonWells

At C3, we had no ChiefArchitect position and everyone helped with the design. I have a proverb: Whoever knows enough to find a problem knows enough to design the solution. This was true at C3. Ron and I did have an occasional argument over design details, but I don't consider that abnormal and I don't remember anyone being upset about it. However, at VCAPS we did have two ChiefArchitect positions and there were often hurt feelings and frustration because of it. It might have been different if there were only one ChiefArchitect and he refused to serve. So, in my experience, I would say that the mere existence of the ChiefArchitect title could be bad.

-- DonWells

The problem that I have with the title chief architect is that it implies and usually means that one person is given sole authority over the design. The problem here is that everyone on the entire team has some responsibility for the design, admitted or not, and must therefore receive a fair share of authority over it as well. -- DonWells

Contributing to a product doesn't make the whole team responsible for the design. "Responsible" is "held responsible." If the project delivers the wrong product, it's not the junior programmers that get called on the carpet. Basic management requires that for every objective, one person be responsible and have the necessary authority and resources to meet the objective. Anything else is an invitation to chaos or paralysis. Someone has to be in charge of what strategists call "maintenance of the aim." It's not something you can vote on. -- MarcThibault

Do you have the same reaction to CEO or CFO? No law says that only one person can be the system architect. One could say that Smalltalk didn't have a single architect but instead had two (at any one time). However, it usually is a small group if not a single person and there is a good reason for that. -- RobertDiFalco

Perhaps we have agreement on the team being responsible for the architecture and not a single person. Most teams are small groups, at least where I come from. -- DonWells

I don't think we agree unless the team is very small - say three people. Even in those cases, there should be one person who has the final say. Democracy has never been known to make good art. Consider music. -- RobertDiFalco

Also, what about TheCoach in ExtremeRoles? Why is that okay? I like the idea of an Architect much better than I like the idea of TheCoach going around with a RolledUpNewspaper. -- RobertDiFalco

The coach is not supposed to be the chief architect. The coach responds to people's problems with advice on design, but has no authority to force the team to adopt a specific design. -- DonWells

No, nor should he be. I only brought up the coach because you seemed to take issue with the idea of a single person (or small group) being wholly responsible for some task. While TheCoach is not the architect, he/she is a single person mapped to a set of responsibilities. In other words, why does it work well for TheCoach to be a single person but so bad for an architect? -- RobertDiFalco

TheCoach is a role. Architecture is not. Besides - if you read all of what is written here at Wiki. you will eventually run into the VCAPS team's writings on the subject of distributing coaching responsibilities as well :-) DonWells

Artist or Manager?

The traditional idea of the 'Architect' is that of a professional, knowledgeable, construction expert who is also an artist and has, in his work, an artistic (design) intention. I am not sure how in programming this is paralled, or not. In the building world great Architecture simply would not result without pretty great individual vision and artistic intention (think Phideas's Parthenon or Michaelangelo's St Peters). Senior building Architects might often attest to the tragic nature of their art in as much as the artistic intention has to be pushed through/persevered with and kept faith with through all the very down to earth vicissitudes of finance, programming, politics, client demands etc (think British Library over 35 years!).

The Architect as merely a 'manager' of other designers or craftspeople is really a definition of 'Architect' outside this traditional artist-related concept (see my comment on BeautyIsOurBusiness). Sadly (I think) some building architects do end up distanced from the real practice as director/senior manager types, but in most cases, these guys still have an appreciation of the aim of practice and previous, usually good experience of that practice.

In the debate about 'programming architects' it seems that opinion is generally that the 'architect'-titled guys generally can't really programme and therefore aren't really 'qualified' to instruct individual or groups of programmers how to go about their work. If this really is the case perhaps you ought to drop the use of the title 'architect'. If it isn't the case, then why not quit whittling and get on with the job!!

-- MartinNoutch

Personally, I don't know many Architects I respect that aren't acceptable technologists. However, I know many that simply suck at management - they are more artist types than great managers. Both skills are equally important, but I don't often see them in the same person. -- RobertDiFalco

It may be unpopular to say it, but I believe GreatDesign is rarely the result of MajorityRules?. -- RobertDiFalco.

ISTM that these roles describe what an architect does, not what an architect is. I've come to see the ArchitectAsKeeperOfTheFlame - perhaps XP embraces the being more than the doing? -- PaulDyson

The title "ChiefArchitect" is often bestowed upon the founder of a company to ease the pain of losing control and having their equity diluted. Like most job titles, it is inversely proportional to the degree of technical contribution. -- MichaelLeach

If Architects play golf, then the ChiefArchitect must play golf in France. (or, if you're in France, in Japan.). ;)

WaldenMathews: The term ChiefArchitect implies that there is more than one architect on the project; is that what's intended here? And isn't the 'chief' redundant anyway (archi = chief)? A project needing multiple chief builders would seem a large one indeed. Maybe it's only a flattering title with no real connection to its etymological roots.

RobertDiFalco: Walden, I don't think the Chief part is as important as the Architect part. Maybe the implication of the term is more like there is a team of designers (all of which could be called the architect of their domain) and a ChiefArchitect or overall architect (or team-lead) who is responsible for the overall ConceptualIntegrity of the project (not just a domain or subsystem).

WaldenMathews: Robert, architect is indeed just a word until you attach meaning and significance to it, and that is exactly the problem as I see it. As chief builder, and architect ought to be someone who knows how to build whatever it is you are building. If you want conceptual integrity (and I do), then define a role with that in it. In the times of the pyramids, the architect was the guy with the whip.

A ChiefArchitect (chief chief builder) is a heap big honcho. Bastardizing the English language like this is like bastardizing a class in a program you are enhancing because you didn't bother to find out what the class 'means'. It's a sign of a deeper problem.

My initial point above was that the term 'ChiefArchitect' is conceptually defective. Refactoring it results in a simpler word with the same meaning: Architect. Let's be merciless here, I beg you.

RobertDiFalco: I have to say that I pretty much agree with everything you said and I too simply prefer Architect or Systems Architect to ChiefArchitect. I agree that chief doesn't really add any value and messes with the English language. However, that shouldn't immediately discount the work of organizations that have adopted this term. I think that the SoftwareEngineeringInstitute is doing some important work on extending the patterns-concept to architecture. Personally, I'm pretty intrigued by the SoftwareProductLines and the AttributeBasedArchitecturalStyles (ABAS).

ThomasWhitmore: Architecture first is pretty important for complex projects; evolving several levels of structure in code is much slower than by directed activity in a UML tool. But where XP wins, is the bringing of design activity and experience down to individual developers... Perhaps having a ChiefArchitect enables other team members to also collaborate in the architecture? This would seem good for upskilling, better team understanding, and increased depth. So the 'Chief' word preserves strong ConceptualIntegrity, but the architectural activity can be more inclusive.

On conventional (non-XP) projects, there's usually a clear need for leadership: Someone must set a direction, and ensure that the team keeps heading in that general direction. (...like herding cats. ;-) This is where it pays to have a "vision" of where the project, as a whole, ought to be - a target that helps set direction, and the technical skill to ensure that the largest/most important technical decisions are made in a way that leads in that direction.

A conventional project's TechnicalLead / ChiefArchitect probably exercises more overt control than TheCoach, and imposes a more detailed architectural vision than a SystemMetaphor. When doing BigDesignUpFront (or anything short of test-before-coding and heavy refactoring), your technical leadership must exercise more overt control over the process. Otherwise you'll be shooting in the wrong direction, and no amount of steering during project development can save you.

However, any competent TechnicalLead will recognize that they can't make all technical decisions on the project - due to their limited time, and their team member's having valuable knowledge. So, a good TechnicalLead will make the "big" decisions, and set the overall direction, and encourage "the little people" (without referring to them as such!) to contribute to the design as much as they are able - within the constraints of the TechnicalLead's overall design.

You can easily argue that ExtremeProgramming is good and BigDesignUpFront is bad. You may even be right. But most current projects being run out there in the current marketplace fall somewhere in between the two extremes, and can benefit from project management patterns that aren't quite "perfect world."

P.S. I prefer the term "TechnicalLead" over "ChiefArchitect" for some of the same reasons I prefer to call what we do a craft, instead of an art or a science. -- JeffGrigg

The relatively high pay of software jobs has attracted many people into the field who simply have no aptitude for it. The best programmers in this field are orders of magnitude more productive than the average programmer. Those who are just "really good" are orders of magnitude more valuable than those at the bottom, and worth more than a pile of the average. Yet almost anybody that hangs around long enough will be called senior. For years we craved a word to describe those senior folks who also have great aptitude.

As to the little people. Yeah, that sucks. I think it is important to realize that balance is everywhere. If your strength is abstraction and architecture, you have to realize that your team would do a better job of realizing and refactoring your high-level design than you would. I think this was true with AlanKay and DanIngalls. If I'm not mistaken, it seems as if he deferred to DanIngalls's superiority as an implementor - but maybe I'm wrong. To me, a major problem with the software world is in thinking that being an implementor is somehow less important than being an architect (or high-level designer). I mean, come one, you'd never win a game with a baseball team composed wholly of catchers. I'd like to also mention RobertAltman? here. TO be sure, he is the KeeperOfTheFlame? on his projects, but he works in an entirely collaborative way. Other directors do not, but we do not eliminate the role (or title) of director. -- RobertDiFalco

There is an underlying concern in much of what is written above about whether programming (and therefore other production/design) is best carried out by individuals or groups. In much ignorance I guess this is a lot to do with the concerns of XP at root but does it go even deeper?

On ProjectManager I note how less controversial seems to be the title 'Project Manager' as compared to 'Architect'. Having acknowledged all that has been said about poor managers/major ego types etc is part of the problem the very idea of someone 'in authority' directing others how they should work (a large part of the traditional 'function' of Architect, at least in building).

Most of us would acknowledge that idea of 'authority' is a global problem these days and does not sit easily with modern concepts of 'equality' and 'democracy'. -- MartinNoutch

Dictated authority, yes. Emergent authority, no.

My two cents worth for a ChiefArchitect is someone who can manage the customization and migration of IT Architectures (a new one every three years, seems that way) in a manner that is sensitive to the business conditions where he is employed. -- DavidLiu

In my early days, I used to ignore the business conditions when doing technical work. I still believe, that the business should not interfere with the architecture of a system but well. But a good architecture or design costs money. Not because it is necessarily more complicated to develop, but because management needs the allow for more slack, so that the discussion and workshops between the developer can happen. In my days as architects, I try to communicate the architecture to upper management in an understandable, but consistent way to management (not to many power point slides...). I see that as an important activity for every architect: Explaining the architecture to management people in business terms (we need this to meet this or that business condition). Only like that the development teams gets time and money, to work on the architecture. In the end this means: ChiefArchitect equals 20% Meetings with management to inform them about the value of the architecture and 80% development in the team. Usually the other developers are happy to give someone the title ChiefArchitect, if he spends those 20% of his time with management to allow them to do their work. -- Philipp Schneider

Negative impression of architects relate to the experience that they are sometimes resistent to feedback and that their output is not necessarily sound ( but is beyond judgement ); or that the title is something achieved with seniority that is not necessarily related to merit.

When you look to an author of a book you find that all good authors have editors. Sure, the author gets all the glory, converts inspiration, sweat and time into a novel but without a good editor the work is most likely going to be difficult.

I see the role of a ChiefArchitect to act as editor to work done by other architects. If only to coordinate and collaborate different systems, to act as the official editor of what the architect produces, to be responsible for the value the various architects provided for the company.

If the ChiefArchitect tries to control then there might be serious character issues. If your Architects are not experienced enough to make the most appropriate decisions and drive systems in the correct direction then they can only aggrivate the need for the ChiefArchitect to try and control the situation.

The lack of a Chief Architect by some title or other (I don't much like the "Chief" part, I prefer "Master Architect") is one of the principle causes of software project failures, mainly those attributed to scope creep and misinterpreted requirements. An architect's job is to eliminate both.

Projects need to have someone analogous to the building architect, who can work with the client to come up with the comprehensive external design of the product in terms that the client can understand. This means use case models, interaction designs, and prototypes, in as much quantity, quality and detail as are needed to make sure no one could possibly fail to understand what's to be built. This means that the architect has to be a pretty good business analyst, because the primary, overriding objective is effective support of some business process.

Given that understanding, the architect then has to work with the developers to come up with a design that realizes the models. The design should go to whatever level of detail is appropriate for the capability and experience of the development team. This means the architect has to be a pretty good developer because the design needs to be implementable. I've been in situations where my involvement in the design stopped at components and a preliminary object set. In other cases I've had to go all the way down to method signatures and contracts and the odd bit of heavily commented code where it was faster to code than to explain what the code should do.

As to control--the project manager is in control, mainly because she has ultimate responsibility. Once code is being written, the architect's role is design assurance, if he is even still around.

-- MarcThibault

See: TechnicalLead, JustAnArchitect, ArchitectingWord, CanAnArchitectureEmerge, ArchitectAsKeeperOfTheFlame, ArchitectureDefinitions, CommunalDevelopment, SpecializationIsForInsects, CanAnyoneDoDesign

CategoryArchitecture