Contribution 42

From WikiContent

Jump to: navigation, search

Take the hill!

One of the more surprising things about being an architect is that what you thought the role was going to be when you were a developer that aspired to be an architect was wrong. As a developer you think that being an architect includes more control over how your system is built and that when you become the architect you will have that control. What you don’t realize is that to be a successful architect on a team, you often need to give up some of what you did as developer so those playing the developer role can fully exercise their own abilities. Another way of saying this is that being an architect does not mean doing the sum of what you did as a developer and what you do as an architect. Of course you want to retain and exercise skills as a developer. You may even want to play the developer role on parts of some projects. The challenge is that to be good at being an architect, you have to focus on different things. Then, as you communicate to developers who are doing the details and heavy lifting of building the system, you have to guide them on architecture, but leave them to their own means as a developer. This seems to be a hard lesson to learn, but there are many precedents for this.

If you were a general, you could say, I want you to take that hill by moving tanks here, your troops there, your reinforcements over there waiting to attack at X time, essentially planning all parts of the engagement. Or you could just ask your team to take the hill, explain the reasons why and how it fits into the overall picture, and let them work out how to get it done. By choosing to focus on the details of the effort, are you sure you spent enough time picking the right hill to die on? Have you spent enough time knowing there won’t be unpleasant surprises there for the unit? Is this the right time for taking the hill? Can the hill be taken? Do you really understand the value of the hill for the overall engagement? As many have pointed out, an architect should focus on structure, unifying elements, boundaries and interfaces. These represent the contour lines of a system, as well as an understanding of the flow. It is the landscape of a system. An architect needs to look at these things and carefully pick what the highest priorities are, and then leave the rest to the means of the other developers. You have to walk a fine line between guaranteeing a successful architecture and sucking the creative and intellectual life out of your developers and team mates.

An architect designs the environment in which the other efforts of the project can succeed.


By Philip Nelson


This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Software Architect Should Know home page

Personal tools