I found my self in an interesting conversation just the other day about the commonly and oft wrongly used term for a position in Big Co. called the 'Architect' or 'Software Architect' or 'System Architect', you pick your poison. These days the term 'architect' is over assigned, over used, and overloaded to mean someone that has been in the programming or software development industries for an extended period of time. 'Architect' is being used to indicate that the individuals time 'IN' should equate to them knowing what they are doing and as such that they should be able to 'architect' a good system, or at best design a bit of software now and again from scratch. In the end, this over use and overloading of the word leads to misunderstandings and misinterpretations, and I ran into one in the form of an interesting debate question:
Should an architect also be a coder?
At first I was quick to answer this question in a simple and unequivocal manner: YES!
Then I stopped and thought about the reason for asking the question in the first place and the premise for thinking that an 'architect' should not be involved in any code base, or involved in producing any code for a given system. I then provided what I thought to be a more complete argument then simply answering yes. It went something like:
How can an organization, or any given programmer, expect to have a person or persons be responsible for helping set an over all direction for a system(s) without knowing what it is made of? As a programmer I find out what a given bit of software is made of by digging in and checking out how it is coded. I look to see what the codebase would be capable of doing, what it is resilient against, what code smells might it have - what the over all feel of the code is. I can think of no better way to help set direction and I find it difficult to see the other side which states the 'architects' like managers should not be interested nor involved in how the code is written. That they should only be interested in the high level direction - and that should be their only responsibility. I turned the counter argument in my head into something that I don't like architecture groups to do - and that is to become Ivory towers, or worse yet 'Picture-tecture" groups.
I firmly believe that architects should be involved in code... they should have coding tasks in each and every scrum/sprint/dev cycle (Insert term of choice for your company here). Only in this way can they truly understand the issues and problems and come up with creative and innovative ways to solve them. You might be able to find a unique individual out there who can just "KNOW" a system by hearing it be described - but to me that sounds more like a miracle person then someone I would care to get to know OR take any direction from.
In alot of ways I would hope that an architect would be 'OK' eating their own dog food now and again and being involved in implementing some of the things that they may have at one time put down on paper for someone in a meeting or design session. In essence I think all architects should be ok chasing items down the rabbit hole now and again. Its good for the soul, its good for development and its a spectacular sign that you have someone that is REALLY interested in understanding what they are talking about. An architect interested in a full understanding is what I want - not someone who just thinks they are the shiznit, or like Joel recently posted is an 'Architect Astronaut' or even better someone who is 100% enamored with the title of a blog post. I want to be someone who does really work and ACTUALLY helps programmers solve real problems that let them be faster, and get more done with less effort. I want to chase items down the rabbit hole once and a while - stay sharp and keep current.
skip to main |
skip to sidebar
This is my place to talk about my experiences and travels in the world of software development. These thoughts are my own and any resemblance to situations you may have been in or are in currently is strictly coincidence.
18 comments:
If you draw a parallel with the construction industry, you wouldn't expect the architect of a building to actually lay bricks or cable (although he would be expected to be on site and able to recognise a good job). You would expect the architect to worry about the overall design, making sure the building met regulatory and user specifications.
I agree that the architect should have sound and especially current technical knowledge, but architectural concerns should be at a different level to coding concerns (more "which systems do we need to interface to" rather than "how do we interface with them")
What you describe sounds more like a tech lead, who bridges the ivory tower design of the architect with the daily reality of the developers. Ideally the tech lead has authority to change the design of components within the overall system as long as the interface is maintained, the architect deals with the system as a series of 'black boxes'.
To return to the construction analogy, the 'team lead' would be the site foreman.
Tuneable:
I don't really object to your terminology: if you want to use the word "Architect" for the person who does the "ivory tower design" and "tech lead" for the person who brings that to the daily reality of the developers, then that's fine by me.
But if those are the definitions we're using, then I agree with what I think Joe was trying to say: I would rather be an "tech lead" than an "architect"... and I actually don't want anything to do with architects.
Don't get me wrong... I have nothing against bringing an academic viewpoint. I'm the kind of guy who writes out Big-O performance analyses of his database designs. But "ivory tower" (your words) implies more than academic sensibilities, it also implies an obliviousness to real-world considerations. In programming it is very easy to be oblivious to real-world concerns... I've seen it happen time and time again. The best defense I know of is for the people responsible for high level design decisions (whether you call them "tech lead" or "architect") to ALSO be responsible for writing some of the code.
Tuneable:
Analogies to the construction of physical buildings do not work for software.
If you absolutely must go in this false direction, remember that the entity responsible for laying bricks is not a programmer, it is a compiler.
What ALL programmers do is write out blueprints for a machine to use to construct the finished program.
So if you must go in this direction, the BigCo Architect is like a Senior Architect, and the programmer is like an Architectural Draftsperson, or a Junior Architect.
Either way, we expect the Senior Architect to spend a lot of time with the detailed blueprints as well as with the renderings, presentations, and high-level sketches.
Perhaps the Senior Architect does not lay out every single electrical conduit in the finished plan.
but I would be amazed if a Senior Architect on a real job had never even seen the finished plan and checked it for accuracy because they were too busy laying out a vision for architecture services...
I was just about to comment something similar:
Software is not made of bricks so in my mind the analogy between a software "architect" and a building "architect" is a bad one. In my mind I would always expect the person that is helping to define the 'direction' that the software should go in from a 'high' level (high being relative to the thing being designed) should also be able to help steer some of the lower level stuff.
In my opinion an architect should be responsible for some design, some implementation and some 'ship steering' - all under the simple job description of "Helping the programmers go faster". This simple statement in my mind translates into:
1) Helping the systems be more resiliant to the types of changes the BigCo business folk are asking for.
2) Allowing the programmers to have some overall input to what the systems should and should not be capable of doing.
3) Driving in designs that allows the programmers to FOCUS tightly on "business value" or specifically things that the business at BigCo is interested in - rather then having to worry about boiler plate, or incidental code.
In the end - even on the job site I would expect that the Architect KNOW this a beam in the wrong place is bad and be able to both adjust the drawings and make sure that the changes make it into the building itself. I would STILL expect them to get their hands dirty so to speak... I don't want someone who WANTS to be disconnected from all of that - I would want someone who 'CAN' be disconnected when the case warrents and CAN be 100% involved when needed.
The analogy to bricks is not a good one unless you introduce the notion of the bricks fundamentally changing on a regular basis. They don't, of course, but the underlying software components, styles and practices do change and unless you are actually involved in those changes day to day you will quickly become unfamiliar with the "bricks" with which you are trying to build your building.
Another peril I have seen many times is that by accepting that architects do not need to write code you quickly establish the corollary that architects do not need to know how to write code. This is very dangerous because it establishes a path for the least talented programmers to become managers and thought leaders of software projects without understanding how to actually do the work.
I used to agree that architects need to code, but I no longer do, at least not for *all* architects. There are different kinds of architects, and they work at different levels of abstraction. The "enterprise" architect does not really need to code, IMO, because they are dealing with a set of abstractions that is far removed from source code.
Of course, a coding *background* is still advisable, for many reasons.
I may agree with you there - but I would likely set that up to be a rotation of people up and down at a certain level. I really always want the "Architect" (enterprise or other) to understand the "bricks" being used and how those bricks are shaped to use mitch's analygy - they should always KNOW how to code... which may be the coding background you are indicating.
Regarding the question of whether an architect should also be a coder; I would say a better way to distribute the work and to enforce accountability would be to put the architect in charge (oversight not drugework) of the TESTING.
Both architecture & testing seem to benefit more from experience, whereas implementation is often best turned over to talented novices (more energy & bleeding edge knowledge). And of course, if you want your architect to be accountable - make them responsible for final validation of their creation...
If an architect is concerned with "architecture" then in theory it's possible to see how an architect will only code pieces that demonstrate or enforce architecture or architectural tenets and may not code any domain logic per se.
Having said the above, many architects come up from the ranks of developer to design lead to architect so I don't think they raise up their noses not wanting to know "how" the system is being built.
I don't think its about architects turning their nose up - I think it is more a problem of hubris, architects eventually coming to think that they are the end all be all of design - stating that everyone should do it my way or choose the high way. The Ivory Tower in other words. Usually this dismisses the value that other team members, developers, and lead have to offer a project.
I actually consider "design" different from "architecture" which is also different "implementation", but that's a discussion for another day. I know developers who are better coders than the "architect" and I don't think there is anything wrong with that.
Architects, generally speaking, tend to have more experience than other technical resources but I don't think that should lead to an inflated ego. I know we don't like the "construction" analogy because software is "soft" but allow me to borrow it and say that the architect and the builder are equally as important.
On your last point:
YOU BETCHA!
I would be interested in hearing from you on the first point "Another day" and a longer post. Lemme know if you post something on it.
Architects must be able to write code otherwise they are unable to make intelligent decisions regarding tradeoffs in features, performance, and deliverables.
Further, I've long believed and have yet to find evidence to refute this belief that the lower the ratio of people calling themselves architects to the number of people that are programmers is a direct indication of the likelihood of that group will succesfully complete the development of a product.
My title is Information Architect and I also code. I say "This software sucks" and I know it does because I can look at the code and study behavior of the functionality and ascertain whether or not it is actually useful.
I do not consider myself a programmer but I can write scripts to convert data, mine data, display data etc. using Java and/or PHP. I have a BA in Graphic Design and an AA in CIS. Most of what I really know I learned by trial and error on the job, not in school.
At least in my experience, a system architect better know code and not be just a business analyst. An info architect better know some code and also design, but again cannot be just a business analyst. I too think the term Architect is overused. Information Analyst might be more appropriate.
I consider myself to be a developer first, and although I wouldn't admit it to many who would misuse and misunderstand the term, I probably function as an architect. I find myself talking directly with end users and building models -- whether with Django or EMF, its domain modeling.
If you have good experienced developers with good communication skills that understand some sort of model-driven architecture, what do you really need an architect for? I say they'll fill these roles naturally -- if they don't, you have a bunch of junior devs.
I wouldn't mind getting paid like an "architect" though...
Architecture depends on both the underlying technical and business problem domains. How can someone draft a working solution, if they don't understand the strengths and weaknesses of their technologies? How can someone solve a user's problem, if they've never been around the users before?
On a given project, an experienced architect need not be one of the programmers, but I really think that someone who's never personally 'built' a system for a given business domain, or with a specific set of technologies is not likely to choose a practical or working architecture. They just don't have the experience to do the job.
Paul.
The worst kind of "architect" is the one that stuffs bad product choices down your throat on the basis of a couple of demos, without considering the programmability of the thing.
I briefly took on an enterprise architect role. I started with a theory I called testable architecture, where we wouldn't just cherry pick standards (SOAP, WS-*, EJB) or products anymore without trying them out in some kind of test lab. I had some fun, but once I had built the templating engine to turn PowerPoint presentations into code and have the build manager deploy them as enterprise applications, I hung up my copy of Visio and picked up Ruby on Rails. Apparently, some Danish bloke had better ideas than me, even though we were both cribbing off of Fowler's notes. (He picked the easy stuff though...and made it awesome.)
Even construction architects build scale models from their plans to prove their designs. How can an architect (construction or software) prove their design unless they have the ability, at the very least, to create a scaled downed version of the design they would want other people to implement.
I am complete agreement with Joe and Mitch on this one. The only thing you have when you have an architect that can’t code is a theorist with no way to prove there hypothesis.
Post a Comment