What is a Software Architect anyway?

Over at StackOverflow.com I posted this response to the question of What is a "software architect"?.

In retrospect, I still believe this is a good summary of the role, need, and title... which I see as different things people call "software architect". I'll expand on my own story a bit and add some more useful links from the original.

My Path

I was given the title and role before I had the tools to do the job. As often happens in software cultures, the "sink or swim" model would best fit description of how I got here. Well, that was about eight years ago. I bet on architectural choices like Web Services, the Microsoft .NET framework, and some back-end Java processing, and it's worked pretty well.

My software architecture has gone into several products and several versions with customer adoption and use. Whew! I made it! Stuart Smalley would be happy for my self-affirmation.

The next step has been learning, evolving, and re-evaluating where current designs stand. Where do new products fit? How do I integrate the products that came with that acquisition?

...and a host of cool, fun, and challenging problems. I actually liked software architecture.

Certification

Certification may make you an architect

• Microsoft
• Sun Java EE Arch
• The Open Group ITAC
• The Open Group TOGAF
• Zachman Framework Cert
• IASA

... but certification won't make you a good architect. Some architects are home-grown, and are just placed in that role.

I'd like to get into a full explanation of each Architecture Framework, but that would drag down the post. Maybe I'll give a treatment of my assessment of each in new posts later.

What's the Technical Architect's role?

(I have also seen successful Enterprise Architects and Functional Architects)

• Primarily technical leadership, like a Martin Fowler. Keeping abreast of industry trends and the effect on the software products under the architect's care.
• They design the application architecture, specifically responsible for process-level, component-level, deployment-level items.
• They solve the *ity problems of the system (Reliability, Scalability, etc).
• They often handle the cross-cutting concerns of the app (Security, framework adoption, tool choice, etc).
• Most often called on for POC or Prototyping (third party integration, platform upgrades, etc).
• Handle SDLC issues like choosing the process for dealing with the version control system, process for the build, process for performance testing, and process for development testing.
• Sometimes the archs that get stuck in process definition can get myopic about the software they're trying to create (IMO).
• They can be called on to do PM, develop features, BA, Dev Mgmt, but that should be to pick up slack or ease project tightness.

The lines blur

Most shops used to get away with putting this role on a good Sr. Developer/Team Lead. When that team lead is only doing the Arch Role, then it's probably time to be fair to him/her and change labels.