Category: Software Architect

As an architect, it’s tempting to create elaborate designs and abstractions that elegantly address the problem at hand. It is even more tempting to sprinkle new technologies into the project. At the end of the day, someone has to implement your design, and the architectural acrobatics that you have the developers perform impact the project.

When designing the architecture for your project, you need to have a feel for the amount of effort necessary to implement each element of your design – if you developed an element before it will much easer to estimate the effort required.

Don‘t use a pattern in your design that you haven‘t personally implemented before. Don‘t rely on a framework that you haven‘t coded against before. Don‘t use a server that you haven‘t configured before. If your architecture depends on design elements that you haven‘t personally used, there are a number of negative side effects:

1. You will not have experienced the learning curve that your developers will have to face. If you don’t know how long it takes to learn a new technology, you won’t be able to give a good estimate on time to implement.
2. You will not know the pitfalls to avoid when using the elements. Inevitably, things will not go as well as the demo that the trained expert in the technology provided. If you haven’t worked with the technology before, you will be blindsided when this happens.
3. You will lose the confidence of your developers. When the developers ask questions about the design and you aren’t able to give solid answers, they will quickly lose confidence in you and your design.
4. You will introduce unnecessary risk. Not knowing these things can put a big question mark on key elements of the solution. No one wants to start a project with big, unnecessary risks hanging around.

So how does one go about learning new frameworks, patterns, and server platforms? Well that‘s another axiom in and of itself: Before anything, an architect is a developer.

Software architects solve a lot of very difficult problems but we also solve some relatively easy ones. What we don‘t want to do is apply a complicated solution to an easy problem. As obvious as that advice sounds it can be hard follow. People who design software are smart, really smart. The simple problem-complex solution trap can be an easy one to fall into because we like to demonstrate our knowledge. If you find yourself designing a solution so clever that it may become self-aware, stop and think. Does the solution fit the problem? If the answer is no, reconsider your design options. Keep the simple stuff simple. You‘ll get plenty of chances to showcase your talent when the difficult problems arise, and they will.

This doesn‘t mean that we shouldn‘t implement elegant solutions. It means that if we‘re tasked with designing a system that only needs to support selling one type of SKU based widget it‘s probably a bad idea to design for hierarchies of dynamically configurable products.

The cost incurred by a complicated solution may seem small but chances are it‘s larger than you‘re giving it credit for. Over-engineering at the architectural level causes many of the same issues as it does at the development level but the negative effects tend to be multiplied. Poor decisions made at the design level are more difficult to implement, maintain and worst of all reverse. Before moving forward with an architectural decision that exceeds system requirements, ask yourself how difficult it would be to remove after it‘s in place.

The costs don‘t stop with the implementation and maintenance of the solution in question. Spending more time than necessary on an easy problem leaves less time for when the complicated issues show up. Suddenly your architecture decisions are creating scope creep and adding unnecessary risk to the project. Your time could be spent much more efficiently making sure no one else is doing that.

There‘s often a strong desire to justify solutions with a perceived benefit or implied requirements. Remember this: when you try to guess at future requirements, 50% of the time you‘re wrong and 49% of the time you‘re very, very wrong. Solve today‘s problem today. Get the application out the door on time and wait for feedback to generate real requirements. The simple design you create will make it much easier to integrate those new requirements when they arrive. If you beat the odds and your implied requirement becomes a real one on the next release you‘ll already have a solution in mind. The difference is now you‘ll be able to allocate appropriate time for it in the estimate because it‘s truly required. Before you know it you‘ve got the reputation of a team that makes good estimates and gets work done on time.