Geeks With Blogs
Out of memory, again? Kerry Huguet
| Home |

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.

Posted on Friday, December 23, 2011 9:37 PM Misc , Architecture | Back to top


Comments on this post: Software Architecture: Myth or Reality

# re: Software Architecture: Myth or Reality
Requesting Gravatar...
Some people might disagree with me, but I think that in this day and age, the term "Software Architect" is an oxymoron, especially with the low quality code you have everywhere.

There are really a handful of good developers worldwide.

The days of Dennis Ritchie are gone forever...
Left by itocotopus on Dec 27, 2011 12:01 PM

# re: Software Architecture: Myth or Reality
Requesting Gravatar...
I agree and disagree with you itoctopus, which is really the whole point of the post. The role of Software Architect is largely misunderstood and usually mistaken for a lead developer.
Left by Kerry on Dec 27, 2011 1:29 PM

# re: Software Architecture: Myth or Reality
Requesting Gravatar...
Your post is rocking and knowledgeable. I really appreciate the way you write. I would like to read more from you.
Left by Business logo designs on Dec 31, 2011 1:32 AM

# re: Software Architecture: Myth or Reality
Requesting Gravatar...
Maybe worth thinking to go to india. Very good quality and architecture.
Left by damion w on Dec 31, 2011 11:41 AM

Your comment:
 (will show your gravatar)
 


Copyright © Kerry Huguet | Powered by: GeeksWithBlogs.net | Join free