I was recently inspired to write on this topic after two client experiences that demonstrated serious misconceptions about the role that software architecture plays in producing quality software. After performing an assessment of a mid-sized company, it was obvious that they were in dire need of a good software architect to design and maintain the design of the application that they were in the process of planning. After making the recommendation, the CIO began to explain that they had already chosen the application architecture and were not in need of an architect. What he was really telling me was that , "We have picked the technology that we are using, isn't that all an architect does?". The other incident occurred, when after a few days at a new client, a coworker asked, "Is this a good architecture?" My response was as usual, "It depends". What he really meant was,” is this a good implementation of an architecture?”. This question I could easily answer by reviewing the code base. But to answer if it is a good architecture I would have to dig a little deeper.
Is this a good Architecture?
Architectural (construction) concepts are commonly used to relate to software architecture principles, this is because they do have many things in common. Could you hand a group of carpenters some wood, some nails and tell them to build a 3 bedroom house? Sure, but what would pass inspection? Would the house be energy efficient? Would it meet the accessibility needs of the family planning to live in the house? Similarly, you could hand a group of developers an IDE, some computers, and some requirements and they could write an application. But would it be maintainable? Would it meet the performance needs of the users? Would it meet the usability expectations? The requirements of any application are extremely important to the success or failure of a product, but each one of these features can be implemented to perfection and the application can still miss the mark. This is where architecture comes into play. Architecture focuses on the Quality Attributes (or -ilities) of the application. These are system level principles that if not accounted for early in the development and designed into the system it could lead to costly rework in the future. Imagine how costly it would be to decide that a house should be two stories after the foundation has been laid and the roof has been completed. Some examples of quality attributes are performance, scalability, maintainability, usability, testability, MTBF (mean time between failure), MTBR (mean time between recovery), and extensibility. This is not an exhaustive list, but you get the idea. Building an application with these attributes is not cheap even if you design for these attributes before a single line of code is written, but it is much cheaper if the design accounts for these attributes early on. This is why it is extremely important to understand more than just the features of an application before any work starts.
So why could I not answer if the architecture was a good one? Because I did not yet know the quality attributes that the system needed to meet. A good design for one application may be a terrible design for another. Not every application needs an elegant design, and in fact a well designed architecture may be a waste of time and money for many applications.
We don't need an architect, we have already chosen our architecture!
Let's pretend that this statement was actually true, why would I still advise that an architect be added to the project? The same reason that there are regular inspections during the construction of a building. Even the best planned design can be misinterpreted or implemented incorrectly. It is the architect's responsibility to ensure that all stakeholders understand the design and buy into the key architectural principles and the quality attributes that they represent. This “buy in” will reduce the long term risk that the implementation will stray from the original design. The architect should also regularly conduct design reviews with stakeholders to ensure the implemented architecture is really meeting the needs of the business.
There are many other misconceptions about the role of an architect. The key thing to remember is that it's easy for us techies to get caught up in the technology, which is why it is so important that we remember that our stakeholders aren't interested in the technology but the solution that it can provide. Architecture helps us keep our focus on these goals and deliver the right solution to the right client.