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.

Is RIA the new Client Server?

I was just working on an old JDK 1.1 based web application that was running on Oracles implementation of Apache’s old JServ. Yes, I get all the cool new bleeding edge assignments. At the same time I was doing a bit of analysis on an upcoming task that looks to be a bit more modern with dashboard functionality, drilldown reporting, pretty pictures and possibly some streaming audio.

What struck me about the old code is how absolutely stripped down the client side of the servlet based web application was. It was completely static content with the most basic request/response paradigm possible. Almost no session data to track, other than a few settings in a cookie. No back button history issues, no controls, no local eventing, no java script, no nothing. Just some good ol’ html input tags inside an html form.

Remember I’ve got eye number 2 mulling over some possible directions we can take for this 12+ year old client server application written with Oracle Forms.

This is what popped into my head. Silverlight, Adobe Air/Flash and JavaFX programming paradigms seem to have more in common with Oracle Forms than the old servlet based web application that I was working on.

So here I am trying to figure out how to “un-clientserver” an application and bring it to the “modern ages” but the client code and environment is going to end up looking very similar to what’s already there. It will have more in common with the Oracle Forms app than the servlet app. SAY IT ISN’T SO!!

OK, here’s the disclaimer. I know the benefits of getting off of a thick client architecture. It just seems funny to me that it’s possible that we’ve replaced something that did what it was supposed to (the old html app) with something that works like the model it was supposed to replace (the client server app).

Here’s some general hot points:

html centric: static data, all you need is the browser, sandboxed, low/burst bandwidth utilization, very deployable, centralized administration, business code is in a single location(ok, maybe that is too idealistic), upgrades happen at the web server not every client etc..

client server centric: have to install and manage the client platform software and drivers and keep them version synched on every machine, heavy traffic, need system level access, business rules are embedded in every client, proprietary client platforms are very difficult to maintain and cause dependency to the technologies that single vendor supports ...

RIA centric: Let’s see, you have to have client side platform software installed and maintained, tons of business logic on the client side for control manipulation, security management and UI building based on user information, we spend tons of time trying to figure out how to get around the browser sandbox for content manipulation and so on. PLUS we are starting to stream BOAT LOADS of data, goodbye thin client….

So, have we really advanced? Or, are we just running around in circles thinking we are covering new ground because the hole is getting deeper on each pass? There are some seriously difficult code maintenance issues that come with a complex client server application. As the client side of RIA applications get more and more sophisticated and event and data management code becomes more complex, are we doomed to paint ourselves in the same corner?

What say you?