"What is Your Quest?" - Determining the Difference Between Being an Architect and Being a Developer: ASP Alliance

Print Add To Favorites Email To Friend Rate This Article
"What is Your Quest?" - Determining the Difference Between Being an Architect and Being a Developer

page 1 of 4

Published: 07 Feb 2006

Unedited - Community Contributed

Abstract
In this piece, Ambrose shares some thoughts about one way that we might further disambiguate between the developer and architect roles and why doing so might be valuable.

by J. Ambrose Little
Feedback

Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 23067/ 21

Article Contents:

Introduction

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.

View Entire Article

(Page 2) »

User Comments

Title: Mr
Name: Joe
Date: 2011-12-06 4:19:36 PM
Comment:
Thank you very much, this was a good read. I know now that I am a developer.

Title: Mr
Name: Maytham Salihi
Date: 2010-03-21 9:46:21 PM
Comment:
Thank you very much Sir, it is a great article, as a student now I now what is exactly the deference between them and what shall I focus on to be a database Architect.

Title: Continue the Discussion
Name: J. Ambrose Little
Date: 2006-02-15 5:14:20 PM
Comment:
Thanks for the comments, Tom. I'm continuing the discussion on my blog here:
http://dotnettemplar.net/FurtherRefiningTheRoleOfTheSoftwareArchitect.aspx

Title: Great article, it reminds me why I love MSF!
Name: Tom Fuller
Date: 2006-02-07 7:15:59 AM
Comment:
I love the article, this very same point seems to be reinforced by all of the recent methodology changes and guidance materials out of Microsoft. If you look at the new roles in MSF 4 an architecture role is considered important on every project. That role in my mind does exactly what you're talking about. Now, the hard part is breaking the implicit belief that your architect is just your most senior development consultant on the project. IMO that is something architects need to remain vocal about with their projects. Architects need to work on things like enterprise frameworks and pluggable architectures. Architects also work on guidance, standards, and best practices thereby helping to provide consistency and ultimately productivity.

The architecture role on any individual instance of the SDLC should be to identify those things that are architecturally significant to the enterprise. More likely anomalies from the standards that were hopefully pre-published. All of this IMO keeps the best interest of the company (aka your business) at heart. It is precisely this type of distribution of responsibility that is critical to surviving in our rapidly changing application delivery world.

My 2 cents :)

Product Spotlight