As we see things, an architect is, among other things, a better and more experienced developer. We don’t believe there’s value in having architects who just speak in UML and Visio and leave any implementation details to developers. At least, we’ve never found it easy to work with these people when we’ve crossed paths with them.
Dino Esposito & Andrea Saltarello in “Microsoft .Net Architecting Applications for the Enterprise”
I am a big believer on "an architect is a better and more expereicned developer”. but what characteristics separate an architect from his fellow experienced developers?
an experienced developer know how, and an architect know why besides know how.
in my working experience I came across an “architect”, for the convenience of writing, let’s call him G, G knows how to do lots of stuff, among all he knows, he is a big fan of “Software factory”. the other buzz words often seen in his writing are “unit test, dependency injection, architecture governance, spec catalogs …” he favors code generation over well designed code using inheritance, abstraction, encapsulation and polymorphism. let alone SOLID principles. with him as the “lead Architect” the technologies were implemented into the system. but those technologies did not deliver the timeline he promised, the project overrun original timeline more than 100%. there is nearly no unit cases in the codebase as he promised when he introduced “Dependency Injection’. the last time I checked was the project is close to be aborted by the client and his last technic he deployed was “blame the developers”
an experienced developer might know how to implement dependency injection using Unity or Ninject, but he might not know when to use it to deliver business value. an qualified architect should know.
an experienced developer might know how to implement spec catalog, but he might not know what kind of code the factory should generate. a qualified architect should know.
An experienced developer knows how to implement the techniques and an architect knows how to drive to those technical decisions based the requirement.
in my working experience I came across an lead developer, for convenience of writing, let’s call him J, I wanted to develop J's architect skills, so in a small project I position myself as “Product owner” and position J as the “architect”. In this setting, I make requirement related decisions and he makes architecture decisions. this is what happened during the project:
while there is a developer working on database schema, J decided to ask another developer to work on Entity Framework using “Code First” pattern.
when the database developer changed the database model based on UX design instead of entity relationship, asking him reviewed the new database model and his response is “it looks good” before even reading the requirement document.
on the other end, he instructed the team to implement Unity for dependency Injection, without knowing what requirement it is address to.
this reminded me what Dino and Andrea said about what an architect does in their book “Architecting Applications for the Enterprise”.
- Acknowledging the Requirements
- Breaking down the system
- Identifying and Evaluating Technologies
- Formulating Specifications
Among 4 major responsibilities of an architect, number one of them is acknowledging the requirement. all architecture decisions must be driven from requirement, functional and nonfunctional alike. All team members, especially the architect need to read the requirement document and fully understand what they mean to the system.
Approving data model changes without understanding the business domain entity model, is not a qualified Architect should do.“Code First” might be a cool technology, but it needs to fit into the team structure,
“Dependency Injection” is certainly a cool technology, but implementing it without knowing what requirement it is addressing is not a cool thing to do for a qualified architect.
