Software Architect

If you design it, you should be able to code it.

Book: 97 Things Every Software Architect Should Know
Publisher: O’Reilly Media
Author: Richard Monson-Haefel
97 Things Every Software Architect Should Know – 63/97

'Coz sharing is caring

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.

'Coz sharing is caring

By Swatantra Kumar

Swatantra is an Open Source evangelist, a technologist and researcher. Professionally, he does software development, software architecture, server administration and project management. When he's not writing software, he enjoys building web entities and servers, reading about and working with new technologies, and trying to get his friends to make the move to open source software. He's written, co-written and published many articles in international journals, on various domains/topics including Open Source, Networks, Computer Organization, Mobile Technologies, and Business Intelligence. He made a proposal for an information management system at University level during graduation days.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.