Determining the Difference Between Being an Architect and Being a Developer

Introduction

[ Back To Top ] Given that it seems our industry is still working out just what it means to be an architect, I thought I'd toss out my thoughts with the rest of them.  The title implies the essence of what I'm suggesting; when determining if you’re an architect or a developer, simply ask yourself, what is my quest?  By this, I mean what are your primary concerns and interests when making software.  It is by answering this question that I think we can best define the distinction between software architecture and software development. Many developers have said, and rightly so, that they "do architecture," though they're still classified as developers.  True, a developer can easily be classified as an architect if all that being an architect entails is designing some software, and by that count, a developer of one month can also be called an architect.  Indeed, in all but the most detailed of specifications, a developer will be required to do a fair amount of design, a.k.a. architecture, work.  Yet I think we all recognize that there is more to being an architect than simply doing some design work.  To more meaningfully disambiguate the roles, we have to dig deeper and speak in terms not only of responsibility but of concern and interest.

The Developer

[ Back To Top ] First and foremost, a developer is concerned with, passionate about, and even in love with technology and, particularly, his creative expression through technology.  Thus, a developer's primary concerns and interests are not the business' but rather how he can best express his creativity through technology.  Taken to an extreme, you have folks who are tasked with creating software to meet a business' needs that instead take such tasking as an opportunity for them to play with the technologies that they want to use.  Instead of looking for a technology to suit the business need, they look for a way to make the business need suit their technology.  Similarly, when faced with a question to build or buy, the developer will always choose to build for the sheer joy of making software, even if, perchance, the business need would be better served by buying. The thing is that such desire, such passion, is a good thing.  It will drive the creation of truly great and inspiring software when channeled appropriately.  It is positively good to be excited and passionate about your job, as that will translate into higher quality output.  It also is a matter of specialization--a developer can and should become a guru at his technologies because he needs to be the best at them to create the best implementation of a high-level, potentially technology-agnostic design.  It is unfortunate that some people devalue such enthusiasm rather than simply encouraging its proper application within a suitable role, namely that of a developer.

The Architect

[ Back To Top ] An architect, on the other hand, is first and foremost concerned about the business.  It is the architect who is responsible for deeply understanding the business' needs and turning that into a vision for a software solution that truly meets those needs.  By business needs, I mean more than just basic functional needs but also its other needs such as IP protection, customer security and confidentiality, scalability, responsiveness, integration, interoperation, and perhaps most important, fiscal responsibility.  All of these are in addition to meeting basic functional requirements, and there are surely viewpoints that I have failed to mention and many that are peculiar to distinct domains.  But the point is that the architect thinks and speaks firstly in terms of business concerns, not in terms of technology. Implied in this is the more stereotypical responsibility of thinking of the "big picture."  It is indeed a big picture, so big that often pieces of it are neglected when the architectural role is not sufficiently recognized, articulated, and supported by the business.  I've heard it suggested by many that our biggest task is to make the business realize the benefit of design documentation, but I really think what we meant and should have been focusing on is helping the business to realize the distinct need for an architectural role and that, for a project of any size, you really need to give that role full-time attention and support.  What documentation comes of that is an artifact of the particular process being employed; what is indispensible is not the fact of documentation but the fact of ensuring that all the various viewpoints for software are given sufficient attention.  To adequately address all the viewpoints for successful (not just snazzy) software, one has to think primarily in terms of the business, and it is this kind of thinking that an architect should do.  An architect is not concerned about particular technologies except in as much as they enable her to create a software solution to her business' problems.  This obviously doesn't mean that an architect can't enjoy or be passionate about technology; it's just that passion about technology and freedom to express creativity in terms of a technology rank below passion to create a software solution that precisely meets business needs. Naturally, I would suggest that it would be best for architects to have a development background as I think it would help them to better understand the demands placed on developers to implement a proposed architecture, but this also implies that architects need distinct training (or equivalent experience) in business to understand the needs of the businesses that they are serving.  That said, I can imagine an architecture degree based on a blend of solid computer science and solid business principles that could sufficiently prepare a person for a junior architecture role without that person needing to first work as a developer.  In fact, I would see such a development as a valuable indicator that we are sufficiently realizing the distinction between the two roles.

Why Does It Matter?

[ Back To Top ] I hope that while reading this, you've asked yourself why making these distinctions should matter.  And I mean more than just so you can feel macho by saying you’re an architect.  In fact, if we take the delineation as above, it is no more macho to be an architect than it is to be a developer.  Being an architect is not a natural or implied progression from being a developer; it's no longer simply an überdeveloper (as is the common impression one gets today), but instead it is simply an alternate career path.  Those who truly get more satisfaction from expressing their intellect through code can progress along a career path that values at its core such expression, leaving broader business concerns to those who care about them.  Similarly, those who enjoy technology (and are, hopefully, good with it), but who also enjoy thinking in terms of the business and ensuring that the business' various and distinct needs that pertain to software are met, can pursue the path of architecture.  Nor are these paths mutually exclusive.  One may find at some point in his life that specializing in a particular technology or viewpoint is what he enjoys the most and then later find that focusing on meeting business needs is what really floats his boat. Developers are renowned for their disinterest in business, and the proposed definitions enable them to maintain that disinterest while still providing value where they're most able and wont to.  Architects can, thanks to the support of developers, focus more on ensuring business needs are met with due diligence (and not, as is often the case, as an afterthought or a bother).  It is an ecosystem of distinct and mutually dependent roles, as opposed to a competition between them. We, as an industry, are guilty of confusing the issue because there is an implied hierarchy, where architects are at the top and paid the best.  As long as that's the case, we'll always have this confusion because those who truly prefer to focus on technology will continue to claim to be architects.  If we change the way we view the distinction between the roles, we see that it is not a hierarchy but a complementarity.  And once that is recognized and communicated, businesses will learn to pay well for good developers without asking them to be architects.  I think, in fact, that this is the case with some companies, though by and large, I still imagine that most have the misconception that architecture is somehow implicitly more valuable than development. Further, this approach enables us to express, in terms that businesses will understand, the distinct value that the two roles add to their businesses.  Businesses would welcome the idea of a distinct role that is responsible for ensuring all business needs are met, having a person that is extensively focused on the business but who can adequately translate the business needs into a software solution.  Certainly, this isn't a panacea; we'll still have bad architecture and bad coding, but I think it is a step in the right direction in further maturing our industry and lessening the number of failed or ineffectual software applications by enabling a proper division of concerns. I'm not suggesting anything that changes the mechanics of what is involved in software development--we already have all these competing concerns built into most software methodologies today.  The only novel idea here, if it is even particularly novel, is that we make the intentional and conscious division of these two roles in software development, not just along the lines of responsibility, but also along the lines of the role's primary concern as well as the individual's interest, that we formally acknowledge the distinct value that each role brings to the table, and that we encourage individuals to excel in the role that best suits them rather than always expecting developers to be architects and architects to be developers.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14293419/viewspace-612433/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14293419/viewspace-612433/