<= Home
Architecture ilities
I am sure others posted/published this before and I do not claim these thoughts as my own in any way. But recently we have had some touchy political situations as architectures between two parties had to be compared. This of course leads to debates and ultimately hard feelings. So it was recommended by some smart ThoughtWorkers to make a list of ilitites specified by priority that the business (direct users and their managers) would create. After looking at list it helped us sort some issues out but even more so, I think this exercise can be beneficial upfront when conceiving the infant stage of an evoloving architecture.
Here is a list (in no particular order) of the ilitites I look as most important to a system that can be prioritized. There are many more and feedback is appreciated on ones I may have missed. (I’d like to revise this list continually going forward)
To demonstrate this exercise, take the list and apply them to your most current system in the order of issues the architecture addresses by priority from 1 -10 (1 being the highest priority). Then take it to the business, ask them to do the same, and see if their expectations and needs match your results.
- Adaptability – An application that can easily be extended to provide new business functionality with can be considered to be adaptable. (aka Extendibility / Flexibility)
- Configurability – Similar to adaptability, but the need to provide additional functionality or rules without recompiling.
- Maintainability – The ability to easily mitigate risks (issues/bugs) that occur during a system’s lifetime. This sometimes may have a direct correlation with Stability.
- Stability – If stability is important then the system should not fail during normal execution, and in the case of failure, it should do so fast and in a predictable way that alerts the proper parties of the anomaly.
- Deployability – The system should be able to deploy new changes effortlessly because frequent updates are expected and/or because corporate polices may restrict deployment processes, etc.
- Scalability – If our system can effortlessly support extra users/workload by throwing more hardware at it and not touching any code, then our system would be highly scalable.
- Usability – The more robust and responsive the user interface is the more usable it is. Many factors can lead to higher usability as long as all make the system easier to naviage/use for the user.
- Testibility – The ability to develop automated tests around the system. This seems like a given for any agile project, but it is a fact that some developers don’t use proper encapsulation and OOP techniques which make their code highly untestable. This is not always the priority of the business so therefore let them decide it’s value if the overall development staff does not create testable code by nature.
- Performability (I will not even pretend this is a real word) – Obviously the faster and more efficient your system runs the higher the performance. Most people will say performance is important but many business applications will see this rank low on the list when the other aspects are prioritized.
- Interoptibility – The need for a system to communicate with external systems requires extra effort and therefore if your system needs to do so often, Interoptibility will become high on the list. This ultimately can have an effect on a systems Stability if it is not properly prioritized.