Why your company needs a System Architect/Analyst

This post is more than 18 months old. Since technology changes to rapidly, this content may be out of date (but that's not always the case). Please remember to verify any technical or programming information with the current release.

In this post, I’m going to cover what a System Architect/Analyst (SA from now on) is and why you need one.

A System Architect/Analyst is…

A top level programmer with a lot of experience.

Experience is king here. No matter how many theoretical classes or book knowledge, experience can trump all of those. It is just impossible to run into as many situations in the class room as in the real world. This person should be continually updating their knowledge of programming concepts as well as …

Still keeps hands in the code.

A common problem with the SA’s I’ve seen is that their programming time continually declines until there is no more hands on involvement from them. It is still important for an SA to keep their hands in the code, whether it is making quick bug fixes, creating complex algorithms or, at the very least, making shells of classes and methods.

Understands advanced architecture concepts and can implement if need be.

While the current project or code base may not necessarily be in the place where advanced concepts can be applied, the SA should still understand these concepts and be able to apply them in other projects. This helps cement the fact that this individual will be the first person that is consulted on a rewrite… which means…

Knows where the code base is going.

Code bases, for the most part, are more of a living/moving entity than a stable patch based system. There is always a need to add more features while refactoring. The SA should know about where the code is going in order to give design guidance to make the new features partially on the road to the refactored code or a rewrite.

Understands where the company is going

It is important for the SA to understand some of the company’s strategic plans for future development and planning. This way they can make design suggestions about existing projects’ architecture to afford for easy upgrading to the future planned additions. This familiarity is accomplished by working somewhat with the management team or decision makers as well as the project managers.

Why You Need One

Heads off problems ahead of time.

When you have an SA in the mix, a good portion of their time is dedicated to analyzing and thinking about the current projects. Having a good knowledge of all of these projects helps them foresee any projects and take care of them ahead of time. Additionally, with all of this knowledge, they can help make educated decisions without having to bother the stakeholders. A lot of times, however, stakeholders will suggest throwing an SA into the mix for the wrong reasons - to code faster, to push out product quicker, etc. This is never a good idea. Once you pull them away from looking at the big picture, its almost as if you don’t have one - or sometimes even in a worse place than before.

Makes recommendations on how teams can accomplish work.

I’ve covered this before, but it bears repeating. While not actually accomplishing a lot of work themselves, they do get involved in many of the projects and give guidance to the team and team leaders on how to best work in the current constraints as well as plan for the future.

Authority from a technical aspect on how code is finished, peer reviewed.

When teams are having some issues solving something or a peer review doesn’t go right, the SA would be the authority on what is the solution. For example, if one peer reviewer says the code isn’t right but the other feels like it is, the SA, from their experience and other understanding, will resolve that issue immediately.

Analysis first saves work later.

Time and time again, analysis is cut short because there are not enough resources to work on the projects as well as analyze the stuff. Well, just off the bat, if you’re suffering from this problem, it sounds like you’re not putting a lot of emphasis on the analysis - or not learning from mistakes. I can’t point to ANY example where analysis first was the ‘failure’ of the project - but I can name a million where it could have helped or did help (search “software” on google for a million examples). Point being, this SA’s primary responsibility is analyzing past, existing, and future code and ideas. This is an important part of any project’s success. Just like every other skill, with practice, this becomes better. It is important to dedicate a person to this task so they can continue to become better at the analysis as well as protect from any project design misses.

Reduces work for managers.

Since the SA knows both the future plans of the business as well as has an eye for the technical solutions, they can jump in and resolve a lot of questions before they have to get queued against a manager. This is not to say that an SA should be at all responsible for personnel issues or anything - but they can help make snap decisions with the notion of what is best for the company and the architecture.

Do you agree?

I’d love to see any comments talking about if you agree with this summary/description, if you’ve recently acquired an SA and any positive or negatives you’ve seen, or if you have other things I missed. Thanks!

Return to All Posts