The role of architect
Thanks to a pointer from Kent Beck, I’ve just read Alan Keefer’s post, Taking Responsibility. This is probably the best description I’ve ever read of the role that a software or system architect should take.
And it’s very different from the role I’ve normally seen them take. Most software architects got the title because they were very good software developers. I’ve seen far to many who assume that they should now do the “highest level” of the work they’ve been doing, that of the system level design, and leave the more mundane work to those who are still software developers. In other words, they’re considering their promotion from the point of responsibilities they’re shedding rather than those that they’re taking on.Alan, instead, speaks of the enormous responsibility that he has with the role of architect. He says, “my job is to make sure that the project doesn’t fail for technical reasons.” There’s no refuge in saying, “I did my part right.” It all has to work.
This is an important point for all of us to consider, whether architect or not. It’s never very satisfying to hide behind the statement, “I did my work well, but those people over there screwed everything up.” We can all do better than that. We can all look around and see what else is going on. We can do things to help that larger picture. We can do things to adjust to the reality of that larger picture.
Of course, we can still fail. But when we fail, it’s a pathetic refuge to blame the failure on others if we made no attempt to succeed at more than the tasks right in front of us. And if we did try hard to help the project succeed as a whole, but it still failed, then must accept some responsibility for that failure.
“In spite of my best efforts, the project failed.” There is, in that statement, both a sense of failure and a sense of pride. “I gave my best efforts.” Perhaps they were not enough for these circumstances. Perhaps they were the wrong thing in these circumstances. We do well to reflect on what we did, why things happened the way they did, what we might have done differently, and what we might do in the future. Retrospecting as a team would be wonderful. Retrospecting by ourselves is something we can always do.
This topic is a great illustration of Jerry Weinberg‘s statement, “The ultimate limit to software is courage. Imagination is a distant second.”
Now, go read Alan Keefer’s post, Taking Responsibility.
It is unfortunate that application development choose to borrow the word architect. Mr. Keefer skips around the base issue when he talks about things not being in his control, but his responsibility.
The problem is that ‘architect’ in the real world (building or naval) means that one has passed certain tests and have sufficient experience such that one IS in control. Whenever a building fails or a ship sinks, the architect is the first line of responsibility, AND he is expected to have specified EVERY element of the structure. The engineers (coders in our context) are charged with carrying out the architect’s instructions without error. The review of failure is first and foremost about whether the design (architect’s job) was sufficient or the execution (engineer’s job) failed to meet the design. The architect is required to know MORE than the engineers about materials and methods.
Most of us in systems development only have a half-hearted (and -minded) acceptance of this requirement. Many (most, all, ?) want the title and authority, but few want the responsibility or have the depth of experience and understanding to do the job. Not least because coders refuse to heel.
We really ought to stop using the word.
Robert, I won’t argue for the use of the term “software architect,” but I think that your description of building and naval architects is a bit narrow. I won’t say that it is wrong all architects (as I don’t have deep knowledge of the fields), but I’ve personally known some architects in both fields for whom it doesn’t apply. I suspect this is a case where being somewhat removed from a field makes the view of it seem simpler and more homogeneous than it is for the participants.
It seems certain to me, from experience, that some architects are not the one in control. Some architects play a supporting role. Some merely an advisory role.
It is also certain that even some chief architects do not specify every element of a structure. They instead rely on supporting architects to do most of the detailed specification. Some do not know more about materials and methods than the engineers, but instead delegate tasks to the engineers when that knowledge is required.
And, in both the building and naval architect trades, I’ve known some who want title and authority without responsibility. And I’ve known some who lack the depth and understanding to do the job, even when they have the credentials and certificates to suggest otherwise.
Perhaps the situations are not as different as they may appear from our vantage point in the software industry.