Architect as Consultant?

 

Given the thoughtful comments on Architects Must Write Code and Testing Design, I’m wondering if some of the difference in our beliefs stem from our perceptions of the architect’s role.

I see the architect as the technical lead who shepherds a product through the overall design, someone who explains enough about the system and how it hangs together so that the other developers can take their parts write/design them (in whatever way works for them). I now believe in as-little-as-possible design-up-front and as-much-as-possible emergent design. Because I see the architect role as a shepherding role, I see the architect as immersed in the project, and integral part of the project team who needs to continue to participate to see when things go south.

But I wonder if some of you are thinking about the architect as more of a consultant. The more up-front design and architecture you do, the more you can try to create the architect-as-consultant role. Certainly, architects for buildings do become “merely” consultants once the general contractor starts the actual construction. (Yes, this is one more reason the building construction metaphor doesn’t work for me.) If the role of the architect on your project is more of a consultant, then I can understand why you disagree.

I’m going to have to think about ways to make the architect-as-consultant model successful, even if I don’t believe in it. (For me, this all points to feedback for the architect.) Certainly, many of my clients believe in and use that model. Just because I can point out ways that it doesn’t work doesn’t mean these folks can or are willing to change. So, I’ll be thinking about ways to make it work–and the risks involved. (This will make the organize-your-project-team chapter easier to write too. Duh.) I may well ask you for your comments.

12 Replies to “Architect as Consultant?”

  1. There are two major issues that need to be addressed with the “architect-as-consultant” model.
    The first is the feedback loop that you have identified – the architect absolutely must get feedback on the design through implementation and production use, and must participate in the ongoing evolution of the design. Without this feedback, the architect will not learn what areas of the design needed change. Without the ongoing involvement in the evolution of the design, the architect’s original vision may well become distorted, and the design will lose cohesiveness.
    The other issue is the risk of “finger-pointing”. With no involvement with the implementation, the architect can simply say that the development team didn’t follow the design _exactly_ (which they wouldn’t have), and thus blame them for failures. The developers, in turn, can point back at the unrealistic design which needed change to overcome unexpected obstacles and deal with unanticipated changes. A blame-fest immediately ensues.

  2. Johanna,
    I’ve found myself in both sides: architect inmersed in the project and architect as consultant, and I will say that the second one just does not work unless the rest of the team is very strong and can hold on it’s own, and the architect is very, very good at getting his point and vision for the system across. Naturally, this won’t happen as often as one would like in the real world.
    I can also honestly say that architect-inmersed-in-project is far more rewarding as an architect (at least imho), and I’ve enjoyed that inmensly. That’s why I kinda like the “Devarchitect” role Ali Pasha talks about here http://blogs.msdn.com/a_pasha/archive/2005/10/30/486951.aspx.
    I totally agree that the architect as consultant thing just lends itself too much to misunderstandings and in consulting/outsourcing companies, this is often mandated by managers that want their architects to be multi-task several projects (because they are more expensive sometimes, or just because the company tries to bill for them a higher hourly rate and so the customer is not willing to pay that rate for fulltime engagement).

  3. I could see more variations in the proposed model:
    1- architect-inmersed-in-the-code. This is the obvious one. The architect might be a senior developer who graduated to the architect level. This person knows how the system work from A to Z and can assist all the development team.
    2- architect-inmersed-in-the-business. I was once in this situation in a startup with outsourced development. To my surprize, my job as a chief architect was a lot less technical (I did not write code). I facilitated the emergence of a solution between our different groups (Product Management, Sales, Marketing, Science, Development, Testing, Business Development). I did not write code, but I spent a lot of time specifying APIs, specifying/reviewing deliverables,… and talking to everybody.
    3- architect-process-oriented. Several years ago, I talked to the chief architect of Boeing. He told me that his role was not so much technical but more process oriented. He wanted to make sure that the teams could talk to each others. He had installed a process where teams had the freedom to pick the technology they wanted as long as it was approved by the other teams/groups/divisions (some sort of peer decision review I guess).
    4- architect-as-consultant as technical lead. I have seen that few times but it rarely worked for all the reasons already mentioned.
    5- architect-as-consultant as enterprise referee. I have seen that in a large organization (15.000 employees). Many teams were locked down in their technical (and sometimes legacy) choices that resulted in silos and politics. An external architect, sponsored by the CIO, was then called to make the calls. The good thing is that we got a more unifed approach in the enterprise. The bad side is that the consultant played the politics aligning himself with the most powerful departments.
    Thierry

  4. I think there is room for both immersion in the project and consulting mode
    While I don’t know about architects in general- I can give you a few examples from my experience.
    One project I am involved with is a very large (several hundreds of man-years) project. I acted as its lead architect for the better part of about 3 years where I was deeply involved in many aspects of the projects. now (more than a year later) I still support this project but it is well towards the end of its second phase (with some groups already working on stuff related to phase III) – and I mostly visit it from time to time (design reviews and a little more involvement in new elements) This project has enough senior developers and team leaders to solve the day-to-day issues and they don’t need my daily attention. On the other hand on another (much smaller) project (that needs to serve as a platform for several other projects) I am deeply involved with all the details of the project (to the point of helping debug performance and threading issues).
    Nevertheless, I still don’t think that deep involvement in a project == the architect developing the production code
    just my .2 cents
    Arnon

  5. Does the purpose for “making an architecture” have something to do with the kind of involvement that the architect (e.g., chief architect) should have in making it? Does an Enterprise Architecture have the same purpose as a System Architecture, for example?
    If the purpose various architectures is different, then is it not possible that there is not one right answer to the question of whether the architect should code?
    IMO the architect should be as involved as needed to ensure that the purpose of the architecture is achieved — if that means coding, then so be it; if not, then so be it.

  6. My experience is that an architect is pulled between three poles – the product, the team and the client. The product pole pulls you towards managing the “conceptual integrity” of the design. The team pole pulls you towards mentoring people, helping them build skills, etc (which may mean consciously letting someone write code that you could do much better yourself). The client pole pulls you towards translating between the technical and the client domains (which is often where you get pulled into powerpoint).
    You need to trade these poles off differently on every project.
    Several factors modulate this dynamic, including:
    a) The project manager. The architect-PM relationship is very important and good pairings often find ways to complement each other. e.g. if the PM is very focused on the client, then the architect may spend more time with the team, doing some stuff that would traditionally be seen as project management.
    b) the skills of the team. e.g. How much mentoring do they need?
    c) the type of project. e.g. How demanding is the client? A very tech-savvy client needs different support from the architect compared to a client that has never particpated in a software project before. Likewise, a project involving bleeding-edge technology is very different to an organisational change project based on configuring fairly stable technology.
    d) the type of architect. The word “architect” is a bit of a problem these days, as it’s so overloaded with different role expectations. Enterprise, system and software architecture are different concerns. Information architecture is a totally different area of specialism. Throw in data, application, network and other architects (all of which tend to much more focused on technical design rather than team or client concerns) and it’s easy to get very tangled.
    e) who is the architect working for? e.g. If the architect is employed by the client (perhaps to ensure this project delivers stuff that will interface to that delivered by other projects), then they have a very different role to when they’re employed by the development organisation.
    For me, architect as bridge between technology and the business’ use of that technology is the most interesting role, which increasingly pulls me to the client pole. But that’s purely a personal preference, and all variants on the role are equally important (& difficult to get right) in their right context.

  7. After so many valuable comments I’m really scared to voice my “minority” oppinion, but let it be. I do play a role of an architect-consultant within my organization and it sometimes does work. The “architect” and “architecture” terms have so many different meanings for different people that I’m not sure it would be easy to get to a commonly acceptable conclusion. In my organization (digital television) we have at least three types of architects: system architects, Set-Top-Box (STB)architects, software architects. System architects NEVER write code, only specs, and nobody expects them to do so. They are primerily concentrated on the system end-to-end aspects, many times they play a role of technologists, but not always. An STB architect also NEVER writes code, only specs, and is concentrated on synchronising various aspects of a consumer electronics device internal components. A software architect role actually almost does not exist, but I do play it many times. Local cirmusntances do not make it possible to be engaged in mass code writing within all teams I’m working with. Still it does not mean I cannot make or advise certain software architecture decision and I should not follow up these decisions. To summarize I can re-iterate what I wrote previously – it depends.

  8. I was so late coming to the party on this topic, I thought I should post here. First of all, I think the architect has a role in making sure we “built the right thing”. This is different than we “built it the right way.” Building the right thing means that the architect has to live the first delivery and installation of the product — and I do not mean in a laboratory. It must be a customer.
    Second, the architect has to know how to communicate specifications and design parameters. Usually, in my experience, the architect is not a craftsman, so perhaps the architect as consultant is the role I have seen most often. This means the architect must allocate requirements to the design structure. The architect must work with the project manager to determine how to devise sufficiently many integration-and-test points in the project. The architect must resolve design conflicts (who does what work, and where it goes in the system). The architect articulates the quality goals and quality tradeoffs so that few design conflicts reach him.
    So the architect does not get out of building it the right way after all. This of course means the architect has to understand the skills of the coders. If it is expensive to build a particular design because of staff skills, alternatives have to be considered. If the architect is not watching the developers work, he (she) will not understand what the developers found difficult about the design. Hence, coding is not bad for the architect either.

  9. In among the declarations of what an architect “is” or “should be” comes the observation that the role isn’t consistently understood.
    So, I think the most important thing for being one, having one, or using one is having this conversation. “So, what’s your part here?” You’ll get in big trouble if there are several ideas of that.
    I suppose one of the first jobs of an “architect” is defining how they think they can add value in the situation at hand. That sounds like a good test for the architects you might use. Can they define their value add? Do they do that? Is that something that fits for you?

  10. While in most projects, Architect-immersed-in-project model works very successfully and is probabaly the best way to go. But in the real world, there are projects which are very long term and in which the architecture gets evolved and stabilized in the initial iterations. After first few iterations, the framework is stable and has been in use and understood by most of the team members. That is the time when Architect-as-consultant model is needed as a full time architect may not add much value.
    So IMO Architect-as-Consultant model works in most projects after it has evolved and become stable. The initial evolution phase definitely requires architect-immersed-in-project.

  11. Just for perspective on “building architects” – they do not always become “merely” consultants when the contractor starts. They can and do at times act similiar to the technical lead who shepherds the project through to completion, ensuring that their vision is implemented consistently.
    (IMO, the building construction metaphor doesn’t work because those who often use it try to pigeon hole a building architect into some simple one-size-fits-all mold that is as far from reality in building construction as it is in software construction.)
    In software I belive that architect-as-consultant can work (as it does in construction) if the goals and skills of the “architect” and “builder” (coder) are adjusted accordingly. Basically after the architect has moved on, someone on the dev team needs to take on the torch of ensuring consistency, quality, etc. Are they then in reality just acting as an “architect who codes”? Probably, but working within guidelines and framework provided by the “architect-as-consultant” may require less architectural skills. I.e. it takes a different level of skill to ensure that code lives within the appropriate layer, than it does to decided which layering and physical-tier strategy is appropriate for a given system. Of course this is similiar to trying to define what is “architecture” and what is “design”.

  12. I think a key consideration in answering what an architect does – when the job is done most effectively – is to look at the needs and characteristics of the organization. On a small development team, it is fully appropriate and very efficient to have an emersed architecture as developer. In situations with large organizations where skill centers are segmented and people generally do not wear more than 1-2 hats, the architect as consultant role can work.
    __________
    John Reiling

    webmaster@pmtrainingonline.com

    http://www.pmtrainingonline.com

    Project Management Training Online

Leave a Reply