What should you bring to the table as a Software Architect? [closed]

Question

There have been many questions with good answers about the role of a Software Architect (SA) on StackOverflow and Programmers SE. I am trying to ask a slightly more focused question than those. The very definition of a SA is broad so for the sake of this question let's define a SA as follows:

A Software Architect guides the overall design of a project, gets involved with coding efforts, conducts code reviews, and selects the technologies to be used.

In other words, I am not talking about managerial rest and vest at the crest (further rhyming words elided) types of SAs. If I were to pursue any type of SA position I don't want to be away from coding. I might sacrifice some time to interface with clients and Business Analysts etc., but I am still technically involved and I'm not just aware of what's going on through meetings.

With these points in mind, what should a SA bring to the table? Should they come in with a mentality of "laying down the law" (so to speak) and enforcing the usage of certain tools to fit "their way," i.e., coding guidelines, source control, patterns, UML documentation, etc.? Or should they specify initial direction and strategy then be laid back and jump in as needed to correct the ship's direction?

Depending on the organization this might not work. An SA who relies on TFS to enforce everything may struggle to implement their plan at an employer that only uses StarTeam. Similarly, an SA needs to be flexible depending on the stage of the project. If it's a fresh project they have more choices, whereas they might have less for existing projects.

Here are some SA stories I have experienced as a way of sharing some background in hopes that answers to my questions might also shed some light on these issues:

• I've worked with an SA who code reviewed literally every single line of code of the team. The SA would do this for not just our project but other projects in the organization (imagine the time spent on this). At first it was useful to enforce certain standards, but later it became crippling. FxCop was how the SA would find issues. Don't get me wrong, it was a good way to teach junior developers and force them to think of the consequences of their chosen approach, but for senior developers it was seen as somewhat draconian.

• One particular SA was against the use of a certain library, claiming it was slow. This forced us to write tons of code to achieve things differently while the other library would've saved us a lot of time. Fast forward to the last month of the project and the clients were complaining about performance. The only solution was to change certain functionality to use the originally ignored approach despite early warnings from the devs. By that point a lot of code was thrown out and not reusable, leading to overtime and stress. Sadly the estimates used for the project were based on the old approach which my project was forbidden from using so it wasn't an appropriate indicator for estimation. I would hear the PM say "we've done this before," when in reality they had not since we were using a new library and the devs working on it were not the same devs used on the old project.

• The SA who would enforce the usage of DTOs, DOs, BOs, Service layers and so on for all projects. New devs had to learn this architecture and the SA adamantly enforced usage guidelines. Exceptions to usage guidelines were made when it was absolutely difficult to follow the guidelines. The SA was grounded in their approach. Classes for DTOs and all CRUD operations were generated via CodeSmith and database schemas were another similar ball of wax. However, having used this setup everywhere, the SA was not open to new technologies such as LINQ to SQL or Entity Framework.

I am not using this post as a platform for venting. There were positive and negative aspects to my experiences with the SA stories mentioned above. My questions boil down to:

1. What should an SA bring to the table?
2. How can they strike a balance in their decision making?
3. Should one approach an SA job (as defined earlier) with the mentality that they must enforce certain ground rules?
4. Anything else to consider?

Thanks! I'm sure these job tasks are easily extended to people who are senior devs or technical leads, so feel free to answer at that capacity as well.

Answer 1

A Systems Architect should:

1. Specify the high-level architecture
2. Participate in code reviews
3. Approve technologies used
4. Assist the developers in their coding effort
5. Maintain and monitor the development schedule
6. Produce SA artifacts, such as UML diagrams, Gantt charts and the like.

SA's must know how to code, and should participate in some of the coding work, get their hands wet, so to speak. This keeps them in touch with the gestalt of the development effort. As Uncle Bob Martin once said, the Architect should do some of the coding himself, so that he can see the pain he is inflicting on others with his designs.

The SA should have the last word on all design, technology and coding style decisions. But, like all managers, the job of the SA is to clear the path for his people so they can be productive. That means, for the most part, that the developers get to decide, at their level, how problems are to be solved. It means that the SA keeps the pointy-haired bosses out of the developers' cubicles. And it means that the SA pitches in to help, as needed.

Like all human beings, SA's can and do make mistakes. The good ones learn from those mistakes, and become better SA's.

Answer 2

1 What should an SA bring to the table?

• A thick skin
• Good negotiation skills
• A good understanding of the various software tiers (from whizzy AJAX goodness to low level networking I/O). You don't necessarily be a hands on expert, but you're going to have make important decisions about what software should be executed at which layer(s).
• Willingness to get their hands dirty in the code, white paper designs just don't cut it.
• Encouragement of software craftsmanship - be the cheerleader for doing things the right way whenever possible and the best way given the limitations in other cases. So things like source control, TDD, build and CI, coding DOJOs, code reviews, a good issue tracking system etc

2 How can they strike a balance in their decision making?

• Much of it depends on your team(s) and how capable they are.
• Your environment (you might be forced to use a particular vendor's product for example)
• Overall it's best not to be an ivory tower architect, be hands on, be part of the team - people will understand your decisions that way.

3 Should one approach an SA job (as defined earlier) with the mentality that they must enforce certain ground rules?

• Yes, things like version control and a build system are pretty darn important and developers need to use these. However it's aways best to make them part of the solution.

There's lots more, I think there are going to be some really good answers coming through for this one.

Answer 3

I have never run into an Architect who was useful, primarily because they weren't practical.

For me the biggest issues I've seen are:

• blind adherence to process for the sake of process
• blind bias to technology before knowing the problem
• creation and enforcement of rules without a good justification
• rewrite from scratch mentality

The best "Architects" I've worked with brought to the table:

• Questions that drove to a better understanding of the problem and the potential solutions.
• Design options/technologies and their trade-offs.
• Clear and rational explanations for both condemnations and endorsements of designs and technologies.

The problem for me is the best "Architects" I've worked with didn't have "Architect in their title. They were most often Software Engineers who are grounded in the specific problem and projects. They understood that in most businesses it isn't practical to rewrite a working codebase from scratch. They make design decision or provide options and their reasons or justifications. They map out how to iterate the codebase to a new architecture over time and still keep everything functional. They give conservative recommendations instead of recommending whatever is dejour or familiar. They would communicate a cohesive vision of how things should work and why, BUT more importantly they would map out how to get there and the cost.

Answer 4

1.What should an SA bring to the table?

"Should they come in with a mentality of 'laying down the law' ... Or should they specify initial direction and strategy then be laid back and jump in as needed to correct the ship's direction?"

A combination of both I would say. When deciding on technologies and processes, being open to opinions and suggestions can give valuable feedback/input on decisions and cause you to learn from others. Your team is (hopefully) smart; take advantage of that. But once a decision (your decision) is made, the law has been laid. Identify those who will complain about whatever wasn't their choice, and those that will just choose anything and don't care - and then ignore them.

As far as technologies: work with what you've got, if the company uses StarTeam then that's what you use. Marrying yourself to any particular product/technology/process isn't going to do anything for you.

2.How can they strike a balance in their decision making?

Listening to the team and knowing when they are right and wrong is important, and having the cojones to tell them that they're wrong and stick to your decision. Not listening will bring a lack of respect, as will flopping around on your decisions.

3.Should one approach an SA job (as defined earlier) with the mentality that they must enforce certain ground rules?

Always. If not, then the inmates will end up running the asylum, overtly or covertly. Deciding on those ground rules however, can be through talk with the team. Remember that any team may not always have the same members that it has now, so making concessions for a small group of them may hinder the team in the future once they're gone. That includes the SA.

4.Anything else to consider?

• In reference to your second example: It seems that the project team formed a tightly coupled dependence on an in-house subsystem. Loosely coupled facades aren't just for third party code. Creating an abstraction for that subsystem could have allowed an easier transition to using that library if the in-house solution failed. This is a logical solution for a software architect alone, but also being a form of Project Manager with the team expression concerns, it should have doubly so been an obvious solution.
• In reference to your third example: It's not a bad idea to have a known architecture or process for producing software (though, admittedly, you did say 'all projects'). This is sticking to what works. With that said, there needs to be opportunities where new techniques can be attempted to see if they bring additional value. In-house-only software, or smaller-scope projects where these technologies can be attempted are ideal places. Keep in mind though, that the onus is also on the developer(s) to provide researched and convincing demonstrations/arguments for adopting technologies. And SA can't be expected to know every competing ORM and its strengths and weaknesses compared to the others.