Architects–r-US

I listened to the last few  Stackoverflow Podcasts where Joel Spolsky started, then continued, one of his patented offhanded attacks on the some corner of the software industry establishment.  And, those just happen to be my favorite thing about the podcast.   In this case it was his extreme distaste for “Architects.”  Or, to be fair, he was more referring to the TITLE of Architect and some puffed up anti-coders who justify their existence through the use of the moniker.

Of course Jeff Atwood pretty much fell in line and agreed with Joel, basically because Jeff see’s the world through programmer goggles(tm). By the way, Jeff doesn’t always agree with Joel, it was just fairly predictable that in this case he would because it favored a programmer centric view of the software world.

So, the question is “Is there a legitimate use for the title Architect, or is it just a trumped up label for programmers who can’t program, and spend most of their day making real programmers lives difficult?” 

I think the answer is another case of … it depends.  I think Jeff and Joel tend to focus on single well focused applications that have smallish teams that can accomplish the business task set before them.  By smallish, I would set the number at less than 75  total people involved with the development process, programmers, designers, CM, testers etc...  In many cases it could be less than 4 or 5. 

In those cases the jobs will have a tendency to overlap, the application and the platform involved will be well understood by the entire team.  The entire application concept across all disciplines will be shared by pretty much everyone to some degree.  In these cases the term Architect is really just the guy who herds the cats along the technology timeline.

So, before I say why I think the title can be a legitimate title in some scenarios, let me provide a high level definition of what I think a few software development titles entail;

• Architect (Vision):  The person responsible for understanding the past, present and future of an application and it’s outlying dependencies.  How the application fits into the business goals and models of the company.  And, convey that information to both the management to help them make good “forward” decisions and to the development staff to help avoid painting code into corners.  This is NOT the CTO or CIO which are both making strictly business decisions.  This is someone who should be helping those positions make good choices.
• Engineer(Details):  I always view this person as the worlds most complicated documentation writer.  This person should understand how to document an application so that if the disaster happens the new team can figure out how to get rolling.  Everything from UML diagrams, IDEF docs, specifications, installation documentation, day to day operations process documentation, CM process documentation, coding standards etc..  In other words the engineer is responsible for documenting not only how the software works, but how the team works and how the business interacts with the customer.
• Programmer(Execution): Realize the operational and functional requirements that support the business goals in code.  And a lot more … but that’s the focus.

So back to the architect.  Although all of these hats can be worn by senior programmers, the size and breadth of some applications can require specialization.  In government development for example, you can have small coding task that are tied to multi-platform, multi-organizational, multi-jurisdiction, multi-policy requirements. 

The code requirements can be very straight forward from a functional requirement standpoint, but the deployment and security implementation rules might be extremely tedious.  Maybe some government agency is looking at a new security infrastructure and want to test it in the framework you are going to deploy into.

In other words, the amount of information one person needs to keep up with about all of the things that impact the life of your application become of over-riding importance.  I know in the government world those outside factors rarely have anything to do with the functionality of the application.  It has to do with managing thousands of applications throughout their life.

In that type of scenario I think an architect is not only valid, it is essential.  You need someone who understands your app out in the world talking with the people making IT decisions at the “family size” level.  Remember that policy is going to be established more or less globally, not on an app by app basis.  Budgets for infrastructure will determine where you need to be targeting your application. 

I could go on and on about the things that an architect needs to do in this environment, but I wanted to finish by agreeing with some additional points Joel and Jeff acknowledged.  If there really is an “Architect” it should be someone with a deep experience pool.  The person should also be cross discipline capable.  There are a lot of business case and policy issues involved with big programs.  Architects need to be able to translate those into functional/technical requirements that programmers can understand.