Yesterday, we had a meeting of a few architects and Memi Lavi gave a nice presentation on Architecture usability. The notions of architecture and frameworks/software infrastructure  are a little mixed in this presentation, but in essence Memi is right to say that among the quality attributes the architecture has to address you should have modifiability and architecture usage scenarios like "adding a complex form will take less than 2 weeks" or "wiring a new component into the workflow will take less than one day" etc. Reducing  friction* of frameworks is very important. I don't think it is the most important though. since if you could only have one of  the quality attributes you need to support (performance, correctness, architecture usability, framework friction, system usability, availability, budget etc.) I am not sure you would always pick architecture usability.
Driving home, I thought that essentially software architecture is just
The set of compromises, trying to maximize the effect of a limited set of  prioritized quality attributes
we can't have it all - so we need to prioritize our list of quality attributes and focus on the most important ones.


*Friction (from Ryan via Udi): "friction" is a (subjective) measure of how much the tooling gets in your way when trying to solve a specific-case problem. I've come to evaluate frameworks based on two rough metrics: how far the framework goes in solving the general case problem out of the box and how little friction the framework creates when you have to solve the specific-case problem yourself. When a framework finds a balance between these two areas, we call it "well designed."



 
Comments are closed.