This is a continuation of a discussion I began with a short article on ASPAlliance. Tom Fuller had some good comments, and I've since been discussing the subject with some other experienced developer-architects. Both Tom and they have very valid and interesting concerns about what I'm proposing. The biggest pushback has been on my definition of the architect role as being 1) not an überdeveloper and 2) not necessarily more valued or well-paid than developers. Of course, there is also some vagueness around just what an architect would do, and that much, at least, was intentional.
First, let me say these propositions are not thoroughly baked in my mind, and rather than trying to tell everyone exactly how it should be, I’m just tossing out some ideas that may or may not pan out in the end. This is the nature of thoughtful dialogue, and I appreciate anyone who has constructively critical feedback. As such, I’m not promising any sort of unbreakable consistency on my part as the ultimate solution is the goal and not the presupposition of this dialogue.
Now, the core issues with both of the objections mentioned above are, I think, inherent in the way the architect role is perceived today. Because architects are expected to design systems down to even the class/interface level, they are expected to be developers, and because they’re expected to know everything developers know and more, they should naturally be more valued and paid better by the business. It may be true that this is the way things should be and continue to be, but what I’m suggesting is that this view of the architect role is in fact not optimal to achieve successful projects or even enterprises.
I think that if we did have a complete career track (such that architecture is in fact a distinct but related discipline), an architect's duties would be distinct enough from a developer's to not require “real-life” dev experience in order to be good. This would be achieved not just through training or book knowledge but also from experience as an architect, starting as a junior and being mentored by senior architects. This way you are still learning from experience but instead of learning developer lessons, you're learning architect lessons.
Similarly, because architects are responsible for a different set of problems, they don’t need to be an expert developer in the first place. While their role may ultimately be perceived as more valuable to a business, it would not be due to simply being a developer++ but rather due to the distinct value they bring to the business. And even within the architecture discipline, I imagine there’d be different levels of experience as well as different kinds of architecture responsibilities (solution architect, enterprise architect, and infrastructure architect, for example). You’d have some junior architects who are less valued (paid less) than some mid-level or senior developers.
This does not preclude some cross-over between the disciplines—a senior developer would likely have a faster track to a senior architect role than a junior architect right out of college because there is most definitely a shared body of knowledge between the two. It may be that said developer simply has not had the opportunity to pursue an architecture path, or it may be that due to fiscal constraints, he’s had to play both roles and hasn’t been able to fully pursue architectural interests, which is often the case for smaller shops and consulting firms.
Of course, all of this implies a redefinition to some extent of the role of an architect--he'd take on some of what some people think of as business analyst functions, some of what might today be seen as project manager functions, some of what may be seen as QA functions, and even perhaps some of what might be seen as developer functions.
The architect would take on the responsibility of understanding and assisting BAs in analysis of the business in terms of how and where technology would best apply to solve business problems. She’d be responsible not for scheduling and facilitating the keeping of the project on track but rather in ensuring that the business needs are sufficiently being addressed by what the developers are building. In ensuring the output of the project is aligning with standards and business needs, she serves in a kind of QA role. And she might do some development of cross-functional solutions like authentication, authorization, and auditing, but at least she’d take on the specification of how these kinds of things should take place to ensure consistency in areas of cross-functional functionality and within the greater enterprise architecture.
I don’t think it is fruitful to further delineate responsibilities at this level because the specific responsibilities will vary based on the size of the development team(s) and, more importantly, the methodology being used. The key realization is that the architect is the hub between these various disciplines, not some other person (such as the BA or PM). The reason I think the architect should be this person is that the product being built is software, and you need an individual who is very well-versed in software design, the trade-offs, the technologies, and the patterns but who can also get and jive with the other disciplines to ensure that everything is working together in a complete picture of a well-oiled machine. It is a very strongly technical position, but it is also a very strongly people- and business-oriented position.
To facilitate this change or (I’d suggest) better definition of an architect’s role, he'd be divesting himself of what some people see as being the “ivory tower” architecture role--the idea of a specification of the system to its lowest level of abstraction and the handing down of such a specification from on high to developers. This is key in getting developer buy in to any kind of idea of architect, and it is key in the architect being able to take on a more holistic role in terms of the project.
Most devs want to do some design work—within their technologies and within specified business requirements, and I think in this world I'm proposing, they would. The role of the architect in terms of system design would definitely be the big picture concerns--cross-functional and non-functional, cross-application, technical requirements, etc.--and the architects and devs would have to work together. Design could not be done in a vacuum in either role.
At this point, the term "architect" comes into question as the metaphorical value becomes less. Indeed, I think architect is probably not the best metaphor because we're dealing with designing computer systems that make business processes more efficient, not with designing a free-standing physical building. So perhaps we've approached the problem wrong in the first place--the laws of physics don't change every week, but business processes can and do.
It may be that the role I’m envisioning is not in fact a refining of the architect role but rather the specification of a new distinct role. But if that is the case, I question the value of thinking of architects and developers as distinct roles, which speaks volumes to the current confusion around the roles today. Most developers do design work, and if the only distinction between the roles is whether or not design work is done, where’s the value in the distinction? Why not just call all developers architects or all architects developers?
Truly, though, I think there is a distinction—the one I am trying to draw out via further refinement of what we might think of as the architecture discipline. It’s partial refinement, partial redefinition, but I tend to think that this refinement and redefinition is necessary to not only enable the discipline to grow but also to be able to communicate a distinct value that a person in the “architect” role brings to the table. He’s not just a developer (though he certainly can have development skills), he’s the key role—the hub between the disciplines we’ve come to realize should be involved in software creation—that ultimately makes or breaks a project.
That’s not to imply that the other disciplines do not add value by any means or that their failure will not break a project as well. But the state of things today seems to be that these disciplines have a hard time of coordinating and actually coming up with a coherent solution that truly meets the business needs. Up to this point, we’ve been refining those disciplines in themselves and trying to define processes, methodologies, and documentation to solve the problem of failing projects or projects that just aren’t solving business issues. And last I read, as an industry, we’re still doing terribly poorly when it comes to project success from a business perspective.
So I think rather than solving the issue by further refinement of the currently-known disciplines, processes, and methodologies, we need to pull architecture out of the development discipline, pull out of development what needs to be pulled out with it (which does not mean all design), and give architecture new responsibilities (or at least better defined ones) that essentially relate to being the technical hub of the project or enterprise.
If at the end of the day we still call it the architect role is irrelevant to me. I don’t think it fully speaks to the role I’m imagining, but it does to some extent, and since the term is fully entrenched, it may not be worthwhile completely changing it but rather just redefining it to something more pertinent to our industry that deals with business processes, not gravity, mortar, wood, plumbing, and electricity.
On the other hand, software is a new thing in human experience, and I tend to think the repeated attempts to redefine terms from other industries in our own may not be the best approach. Whether it’s likening it to authoring, architecting, developing, constructing, etc., none of these will fully speak to the roles necessary for successful software. So we need to keep that in mind as we think about how we further refine our industry and be willing to coin new roles as they are necessary. But that, I suppose, could be a discussion all its own.