Category: Software Architect

Most architects begin their career as developers. An architect has new responsibilities and greater authority in determining how a system is built. You may find it difficult to let go of what you did as a developer in your new role as an architect. Worse, you may feel it’s important for you to exercise a lot of control over how developers do their work to implement the design. It will be very important to your success and your team’s success to give all of your teammates enough autonomy to exercise their own creativity and abilities.

As a developer you rarely get the time to sit back and really look at how the whole system fits together. As an architect, this is your main focus. While developers are furiously building classes, methods, tests, user interfaces and databases, you should be making sure that all those pieces work well together. Listen for points of pain and try to improve them. Are people are having trouble writing tests? Improve the interfaces and limit dependencies. Do you understand where you actually need abstraction and where you don’t? Work for domain clarity. Do you know what order to build things in? Build your project plan. Are developers consistently making common mistakes using an API you designed? Make the design more obvious. Do people really understand the design? Communicate and make it clear. Do you really understand where you need to scale and where you don’t? Work with your customer and learn their business model.

If you’ re doing a great job of being an architect, you really shouldn’t have enough time to interfere with developers. You do need to watch closely enough to see that the design is being implemented as intended. You do not need to be standing over people’s shoulders to accomplish that goal. It’s reasonable to make suggestions when you see people struggling, but it’s even better if you create the environment where they come and ask you for suggestions. If you are good, you will deftly walk the fine line between guaranteeing a successful architecture and limiting the creative and intellectual life of your developers and teammates.

One of the things I’ve been most entertained by as the years have gone by, is observing what things have lasted and what haven’t. So many patterns, frameworks, paradigm changes, and algorithms, all argued for with passion by smart people, thinking of the long term, balancing all the known issues, have not warranted more than a yawn over the long haul. Why? What is history trying to tell us?

Pick a worthy challenge
This one is tricky for a software architect. Challenges or problems are given to us, so we don’t have the luxury of choosing, right? It’s not that simple. First of all we often make the mistake of believing that we can’t influence what we are asked to do. Usually we can, but it gets us out of our comfort zone in the technology space. There are dragons there when we don’t choose to do the right things. Time passes, we have worked diligently and hard solving the requested challenge, and in the end it doesn’t matter: we didn’t do what was really needed and our work is wasted. Over time, a good solution to the right challenge will probably outlast all others.

Simple rules
We say it to ourselves: keep it simple stupid. We say it but we don’t do it. We don’t do it because we don’t have to. We are smart and we can handle some complexity and easily justify it because it adds agility to our design, because it is more elegant to our aesthetic sensibilities, because we believe we can anticipate the future. Then time passes, you walk away from the project for a year or more. When you come back look at it, you almost always wonder why you did what you did. If you had to do it all over again, you would probably do it differently. Time does this to us. It makes us look silly. It is good to realize this early and get over yourself, and really try to learn what simple means in the lens that only time can grind.

Be happy with that old stuff
Architects love to search for the ?one true way?, the methodology, or school of thought that provides the predictability we crave and the clear answers that always seem just out of reach. The problem is that whatever guiding light you have in one year will probably not match the guiding light you have in a couple of years, much less a decade later. As you look back, you will always be looking at designs that don’t match your current expectations. Learn to embrace that old stuff, and resist the temptation to think you should go back and “fix” it. Was the solution an appropriate one for the problem? Did it solve the needs of the problem? Keep these as your measure, you will be a lot happier.