What is a software architect?

It is the renaming of a traditional role.  It attempts to embellish what we used to denominate as a "Software Design Engineer" due to a fad or trend that is ocurring.

I already believe that we have so many roles and titles that its becoming a little, well, excuse me, ridiculous.

To my dismay I observed in the fishbowl last Tuesday that some folks have personally identified themselves with the adejective in question: "ARCHITECT" and they literally looked like if their ego was attached to it.  I am sure they will outgrow it when the industry follows a new trend with some fancy name such as: "Virtual Creator" now that virtualization is a fad.  Yes, I remember when software developers would consider themselves "creators".  Writing a program was defined as a "software creation process".  If a farmer creates crops, eggs, and milk then why can't we create?

I still believe that in practice this could be a role, maybe a title, but definitely it is not yet a profession.  Anyways, we have enough titles already.  We have literally stolen titles from every industry I can think of. Well, we haven't seized the medical field titles yet but I can predict that soon we will.  Maybe I will become a network neurologist or a core cardiologist, or an infrastructure traumatologist, hmmm, what else?

The term is definitely useful to get the attention of recruiters who use it as a keyword to search for potential candidates.  It is "commercially" appealing at the least.

Albeit IBM used the term for its key engineers during the eighties after the term "scientist" didn't fit very well in the mainstream business world, it had started to fade away with the massive outburst of new information technologies in every sector, thereafter the terms "software engineer" or "computer systems engineer" became more popular in accordance with a conservative corporate world.

Bill Gates made the "architect" term popular once again when he stepped down from his executive position and was self-proclaimed as chief software architect.  He was careful of not losing his "C" title.  Many followed.  But he could have proclaimed himself anything and he would have had followers.  As it happens with every hype, this one faded away.

Until now! It has been rebirthed due to another fad:  SOA.  A few years ago folks would rather call themselves:  team leaders, project leaders, development managers, directors of development and the sorts.  Leader was the best component of a title even if you were the last one in the organizational chart with no followers to lead.  If this latter was the case you were a leader by persuassion, or influence.

Don't we adjust things easily when the round pig doesn't fit in the square peg.  Or is it the other way around?

How many universities out there offer a Software Architect pensum?  I was unable to find courses that would even cover the subject, maybe "Software Paradigms"?.  I visited both Stanford's and Berkeley's websites.

Another question is:  Can it be considered a profession if it hasn't been formally embraced by the academia world?  No.  But it can still be a job title and certainly a role.  I couldn't find the title in Salary.com where architect is mainly for landscapers and database builders.

The fact is that the activity that a software architect should perform is that of a designer and not of an implementor.  Implementing has a granularity mindset and not a big picture one.

To perform the role of software designer (or software architect for those of you with a freemason complex:. :) you have to possess certain traits, among them:

1. Vision,

2. Big picture mindset,

3. Knowledge of the technology you are using and integrating with,

4. People skills,

5. Project management skills,

6. Strong leadership,

7. Self-constrained (Getting away from the low-level details like: "Not programming!")

Should a software architect perform low-level activities?  Certainly not.  If you architect and implement I can foresee a project without an end.  The same reason technical project managers have been substituded by non-technical ones has been for almost the same reason.  When the project manager got involved in technical details the scope of the project became a "moving target".  And by the way, a "moving target" is not a positive connotation for an executive team.  Non technical project managers limit all activities within the scope and only change them when it is meant to mitigate an unforeseen risk that popped up.

In conclusion and in one sentence: "A software designer (or software architect) as a person is an individual that performs the activities of forethought calculated analysis, creative design, and mindful projection of that which will result in the materialization of a service, product, or solution that fulfills the requirements of a specific business need within the margins of a well defined scope and that can be clearly understood by all the stakeholders involved."

 Michael Planchart

 I believe the term Architect is popular because it is describing a role that is becoming more common.  If there were only a handful of people who did Enterprise Architecture or Solution Architcture, we wouldn't need a cachy label to bin all of us in.  Now that the role is expanding to the numbers that qualify as a demographic, the Marketing and Industry folks need their Labels. 

So, there are a lot of us now.  Because the IT industry has evolved where not every problem is a coding problem.  Once you have a stable set of parts you can pull out of you're tool box (be it paterns, paradigms, etc) you can do much as the designers and engineers do in every field and start working with the solution in mind, not worrying about what the parts look like. 

Software engineer always struck me as the appropriate name, rather than architect.  If Frank Loyd Wright built software it would never compile, but it woud have a very nice UI.

ProKSys:

In conclusion and in one sentence: "A software designer (or software architect) as a person is an individual that performs the activities of forethought calculated analysis, creative design, and mindful projection of that which will result in the materialization of a service, product, or solution that fulfills the requirements of a specific business need within the margins of a well defined scope and that can be clearly understood by all the stakeholders involved."

 Michael Planchart

I can't find anything to disagree with definition...except maybe add in "Faster than a speeding bullet; More powerful than a Locomotive; Smaller carbon footprint than a squirrel fart in the rain forest...."

 

Ernie 

Are there squirrels in a rain forest?

I agree that the title architect is simply that, a title.  I think it became very obvious in the fishbowl discussion that there is no clear cut definition to "architect" and what roles it includes.  I think there are some roles that people will agree upon, such as "designing" solutions and working with the business, but there are many other roles that people would not agree upon, such as coding.  As for it being a good term, or a bad term, I think it matters very little.  It is the term that has been coined and is used regularly.  I don't think that it matters much if they had decided to call it "General Contractor" or "software designer".  Based on my opinion of what the architect's roles are in an organization I would say that several of the people in the room at the meeting were indeed architects. 

As for if software architects should be doing low-level tasks, my opinion is that it doesn't matter if an architect actually writes anything that ends up in the production code (their stuff needs a code review just like everyone else!), but I do think it is important that architects do not loose site of what it takes to code something up.  For example, take Scott Guthrie from Microsoft.  Here is a person that was one of the lead designers for ASP.NET.  He is now a VP at Microsoft and what did he do during a plane ride last year?  He wrote a prototype for ASP.NET MVC.  He is still in touch with the code.  Is any of his code still in the bits that are shipping as ASP.NET MVC?  It doesn't matter.  Architects should be able to write prototypes, spikes, proof of concepts, whatever you want to call them, in order to validate their design before kicking it off to be implemented.  This ferrets out a lot of the blatant issues with a design. 

 

The other trait I would add to Michael's list is: Be a good listener.  No one should let their ego get to the point where they will not listen to those around them.  Designs from on high cannot be made in the ivory tower and thrown to the masses below.  Architects should get feedback on designs and listen to the developer who is going to spend the next sprint coding this stuff.  Good developers will speak up when they see a problem and it might very well be a disaster waiting to happen that the architect didn't think about.  To this end, being a good listener and keeping an open mind will help keep architects from getting neck deep in bad decisions. 

 

ProKSys:

Are there squirrels in a rain forest?

Yes, there are species of squirrels that live in rain forests.

It is paramount for a designer or an architect to be skilled communicators and of course as Mike indicates a good listener.

Your project stakeholders, positive and negative ones, determine the actual business needs.  If you can't listen to their actual requirements and you "architect" a solution based on your own ideas and misperceptions then you could end up with a design that will fail during the "construction" process.  You'll end up with another "Pisa tower". 

The fact is that the "blueprints" drawn by the "architect" must be readable by every team member that will eventually participate in the "building" phase. 

And all stakeholders should be able to visualize the final outcome as faithful as possible and that is where the "model" comes in handy.  Should an architect create a prototype?  Absolutely!  And it need not be in the same language as it will be implemented as a final service, solution, or product.

Recently I had to design a prototype.  The final product has to be written in unmanaged C++.  I designed the prototype using a combination of scripting, C++, C and even a little assembly with the Microsoft Research Detours library.  The prototype, far from being a releasable product, visually represented exactly what the stakeholders wanted.  The developers given the blueprints (i.e. project concept, development plan, and requirements) along with the visual model (prototype) of what it had to look like gave them a clear picture of what there final goal was.

Did I code? Yes.  But I was constrained within the boundaries of a prototype.  Will I code during the developmental phase?  No.  I will make sure that the project meets each milestone and progresses towards the vision that all stakeholders bought into.

I do have to make an exception here:  If the team encounters an unforeseen risk I will aid the mitigation of it even if that requires me to implement some code to prove the concept.  This I have had to do when we encounter performance issues and in parallel something has to be done about it without taking the original project off tracks.  Once mitigated, the knowledge is transferred to the corresponding team members so that they can implement it within the scope of their tasks.

 Michael Planchart