Preconceptions of Architects

"Science progresses best when observations force us to alter our preconceptions." --Vera Rubin

Been doing a lot of reading, been doing a lot of thinking. Having moved to a new company, I'm seeing my role in a different light, which is expected. Being the company's first architect, helping better define the role, and starting to work with development teams who are not used to working with an architect has really gotten me thinking. And reading some more.

I've read a lot of concerns about architects. Concerns that surprised me because they haven't been my experience, so I'm a little curious if these concerns are holdovers from days gone by (or at least going by) or if they are still relevant concerns. Either way, since the concerns are still talked about, I see a lot of value in looking at them and learning from them.

Architects are Ivory Tower Theorists

I've run into this before, and for good reasons. This is one have seen as a problem- designs getting passed on and the architect disappearing. Now, the disappearing act was often due to the fact that another effort had been dropped on an architect in a sorely understaffed group, but that doesn't mean the perception doesn't need changing.

Architects value theory over practicality

I'm kind of split on this one. There's a fine line here. Architects have to take the long view. I've sometimes said that I'm not working on this project, I'm working on the next one for this product. On the other hand, strict adherence to OO theory and complete Protected Variation (If indeed there is such a thing) are worthless if you can't get the project out the door. One of the biggest challenges of my career has been justifying a design that takes into account change that only might happen. I've found that YAGNI is a moving target.

Architects over complicate everything

Kind of an extension of number 2, but it goes a bit farther. A former manager of mine once said that an elegant design is one that makes the solution seem simple to the point of obviousness. I've often told developers that if I have to answer more than two clarifying questions about my design, then I made it too complicated.

So, what's the answer? I'm a pretty big believer in the idea that there isn't a "The" answer to much of anything, but I've been mulling over one answer. 

Architecture is an Agile project with the development team.

The parallels hit me recently. We provide a product for developers and should interact with them under the same principles under which developers interact with the business on a project.

Constant interaction

A sure sign that something has gone off the rails is an architect not knowing who is implementing a design. Just as an Agile development project requires constant communication with the client, so should we have constant communication and feedback from developers. A good development team doesn't need low-level guidance, be it from an architect, manager, or anyone else. But if the development team can't give feedback to the architect, then one of two things happen. Either they implement a flawed design or they ignore the design. Toss a coin as to which will cause more problems.

This doesn't mean an architect always has to incorporate developer feedback into the design. Sometimes you just have to say "No, this is the way we have to do it". I've done that once. Ever.

Factum non dictum

Deeds, not words. While thinking things through is important, even mandatory, at some point you have to act. And that point should be sooner, rather than later. Action is a funny thing. I've found that acting refines my thinking faster than thinking does. I've also found that action breeds more action. When I'm providing designs, rather than thinking about them, I get feedback faster (See the last heading) and thus work more efficiently.

But this isn't just about translating thoughts to deeds. How does one "act" as an architect? Over the years, I've come to three methods of communication:

1. For simple things, talk to the developers. More than that isn't necessary if things are simple. "We have a web service that manages this functionality. Let's use that rather than developing a new library." "Let's use SSIS for this task"
2. For moderately complex projects, I'll go ahead and use UML, but only if the resulting diagram doesn't look like a spider threw up a Visio diagram. If I have to actually follow a line with my finger to see what elements it connects, UML isn't helpful.
3. Code is best communicated using code. There's a reason we call them "Languages" and there's a reason we have the phrase "Lost in the translation". With some things, I'll create a library with stubbed classes and a few examples based on project use cases and acceptance criteria. I don't mean this as a final design to be carved in stone, but rather a communication of a thought using a language natural to the discussion.

They don't work for you, you don't work for them

Developers and Architects are two sides of a coin. And while Architects may be used to giving guidance and oversight to developers, we sometimes forget that developers can, and should, give guidance and oversight to Architects.

In his book Software Architecture for Developers, Simon Brown compares Architects to Master Masons, responsible for design and oversight of the work and the workers. I think there's a lot of truth to that, but that's just one part of the relationship. Architects, I've found, love to talk theory. I've spent hours comparing design patterns, arguing the possible effects of a given DI Framework, or just whether or not a particular class should be considered an Interface or an Abstract class. Which is all a heck of a lot of fun. But if discussion hinders progress then the development team has the oversight, and even the responsibility, to say "Knock it off and deliver something already!"

Check your ego at the door

Fortunately, there's one thing that makes this all far easier to manage. In a good development department, everyone's a professional working towards the successful delivery of a quality product. That goes a long way. If the development team accepts the realities of an architect and the architect accepts the realities of practical software development, then it's highly unlikely there will be significant problems. Which begs the question, when conflict arises am I the one holding too tightly to my ideas or not communicating them well? Part of why I'm writing this is to remind myself to ask these questions of myself.