Design decisions while architecting a software solution are derived from various sources like availability of resources, customer needs and preferences, business domain etc. However, the basics remains unchallenged for every implementation scenario. One of such fundamental is explained in this great quote from “Software Architecture in Practice, Bass, Clements, Kazman”
"Architects make design decisions because of the downstream effects they will have on the system(s) they are building and these effects are known and predictable. If they were not, the process of crafting an architecture would be no better than throwing dice. "
No architecture can be perfect, in-fact you do a tradeoff between software systems attributes to come with the best possible solution for specific business requirements. Thinking of an architecture generally brings into mind the concepts of layers and tiers (layers are logical separation of components while tiers are physical). Each layer will add an additional message call which will hit the response time. Then why architects still model the system in separate layers and takes the performance hit? The answer is “to make complex things simple”. More complex the system requirement is, more are the number of layers that are generally included in the solution architecture.
Coming back to our scenario, how would an architecture can support the technology up-gradation process? I believe there can not be a complete answer to this; unless you understand the vision of the technology/ product company, it’s difficult to handle this 100% with architecture. However, there are some basic principles that remains unchallenged. XML functional calls, loosely coupled layers, different tiers for application and database etc. are few checks to handle the situation .
One important point to consider: If requirements are simple then it’s not recommended to take the performance hit by including layers. Trying to over simplify the system will make it complex 
.
2 comments:
Abhishek, I understand your view of architecture. It follows naturally from a development perspective (especially an agile one). However all of the elements you list (layering, loose-binding, etc) are not architecture but patterns and tools architects can use. IT architecture is simply technology strategy. It uses tools such as these to achieve a strategic result for the company. For example product architects spend a signficant amount of time thinking about downstream impacts, not "rolling the dice" as it were. However what Clements, et al. doesnt tell you is why downstream impacts are bad. You started to the direction when you mentioned understanding the product company 100%. That is architecture.
It is very possible and straightforward to do excellent architecture all the time, especially in a product company. But the first step to this is realizing that architecture is not a project. Great architecture is the technology strategy of the company and the skills of the architects need to be aligned with this. Those include skills in business technology strategy, design, human dynamics, quality attributes, etc. Just remember architects and developers are two completely different roles. One does not beget the other.
Love to hear back from you at iasahome.org.
Paul, I appreciate and understand your point of view. The perspective of the article and the blog is to oversimplify technical explanation so that even a developer or non technical person can understand. If I put myself in developer shoes, the first thing that I would relate with an architecture is the layers. And that’s the reason I’ve been using the geek theme in all articles. Having said this, I have keep learning about technology architecture, thanks again for your comments.
Post a Comment