LinkedIn
Software Architects and Enterprise Architects Group
How would you describe a well-architected system?
In my experience, I have found a useful rule that I don't remember reading anywhere, so I consider it "my own": the 90-9-1 rule.
Software Architects and Enterprise Architects Group
How would you describe a well-architected system?
In my experience, I have found a useful rule that I don't remember reading anywhere, so I consider it "my own": the 90-9-1 rule.
I always try to design and implement systems that spend
- 90% of their lifetime in a state that requires the 1% of effort. To use the system the user does not have to "learn" too much (recommended reading is the Human Interface Guide from Apple). The system maintenance (like log rotation, memory management, automated notification on anomalies etc.) is designed properly, so the administrators don't have to "ping" the system: "if I know nothing about it, then it runs fine";
- 9% of their lifetime in "administrative state" that requires 9% effort. This is the administrative part of the application that the user has to learn to use (but this part is validated and even the admin should not crash the system - or at least not easily :-) ). These are the planned upgrades, handling change requests, etc. This is normal for any live system, and should be considered during design and development, supported by the architecture and the running framework;
- 1% of their lifetime in "exceptional case" that requires 90% effort. This is a major structural change request from the customer, where both parties has to put serious effort in design and implementation. The system should support finding the boundaries: how far the side effects may reach. This is also a major problem in the framework codes or running hardware: the system should support standing up from this state by proper state and transaction management, logging, etc.
@ Lorand - good system design objectives but not a primary architecture consideration. Again, a system with a good architecture will show an ROI, which translates into it has/had value.
@Edward - true, I chose to list goals and not technology to achieve them, because I think the goals are abstract and usable for any system size, while the technology is not: using oversized equipment for a small task is not "well-architected". I know this very well because I always think too much, and had to realize that my approach simply does not fit well to a smaller task. Currently, I am testing the patience of a multinational company with my architecture...
To be more precise, I work on a fully configurable application structure including the GUI; only message-based communication between components which really have one and only one function. The core is so simple that GWT can take it to the browser, so I can use the same Java codebase on the server and the client (but have a transparent proxy logic for objects that can't work in the browser - OK, I have performance problems with IE, but that is my fault and I'll take care about it when I have time).
For example serialization requires 5 components in a row, but changing the stream format from JSON to XML requires only replacing the formatter/parser at the end :-)
I broke all deadlines while making it, and of course it is still in a "proof of concept" state, but already mighty beast. I love it :-)
@All - I hammer on the ROI for one reason, the question was - what makes a GOOD system architecture?
We all have opinions about what is good, and that is good because one can learn from the opinions of others. However, our opinions can not be used to measure good, but ROI can. Therefore; I keep on going back to the only thing I know that can be used to prove of value was created - ROI. We should all work towards achieving that goal, and there are many ways to do it.
@Edward Perhaps it is not so obvious, but I totally agree: a good architecture must return the investment.
It means the whole design and development process is NOT focused on the delivery deadline and the mere list of required features, but the "long tail": how much it will take to keep that system alive in the upcoming years (and therefore: "refactor" even the original requirements in favor of the foreseen upgrades in the next decade), and in the end, make it a valuable source of information for its successor, and not a heap of smelly spaghetti (even though most system I knew already smelled before the delivery because of the last minute changes and patches...)
My 90-9-1 rule (from my point of view) is an abstract (but for me very pragmatic and useful) recipe to achieve ROI.
