Introduction
It's key that any new system developed is architected not just for a successful go-live but for a successful (application) lifetime.
Often with the pressure on teams some of the 'nice to haves' can be lost and as we know to 'fix' apps after go-live is difficult and costly and damage to reputation is already done.
One example that stands out is of a really quite ground breaking app that I was responsible for supporting.
The architecture of the app was necessarily complex - everything form PDAs, wireless, 3rd party integration to real time measuring devices, interfaces to SAP via middleware etc. and the app was used across a number of industrial sites.
The problem however wasn't with the necessarily complex architecture which was sound it was with the implementation - the project to implement had had issues and I think corners were cut. Noticeably - the support strategy for this complex system was not thought through.
The result was the system would go down and it would be difficult to ascertain which of it's many elements was causing the problem.
This had a terrible knock-on effect as to how the business viewed this otherwise ground breaking application and hence how the IT department was perceived.
The issues were eventually alleviated - I ran a mini project that looked at the app and made a series of recommendations for improvement that were then taken forward.
Architectural 'ibilities
I find these a great and simple tool for helping to ensure an application's design and implementation are fit for purpose.
I use them when I create or review new designs and also use them when reviewing (problematic) existing designs.
- Scalability
- Maintainability / Extensibility
- Reliability / Availability
- Supportability / Manageability
- Performance
- Security
You consider how well the design meets each of the 'ibilities and the significance of any shortcomings.
You also consider the risk around each and where it is significant it makes sense to start a more detailed study of that area early.
For example if I had reviewed the design of the app described in the introduction I like to think I would have recognised the risk to supportability created by the complex architecture. I would then have mandated the EARLY production of a support strategy detailing exactly what happened if any component (or components) failed and how we would understand the failure and recover from it.
Scalability
This is the ability for the application to accommodate more users - using either vertical or horizontal scaling.
Maintainability / Extensibility
Maintainability is the ability to quickly correct issues with the application in a discrete way i.e. without impacting other areas of the application. So we need a modular / de-coupled design.
Reliability / Availability
Ensuring the service is available to the user base as per it's SLA.
Supportability / Manageability
The ability of the system to self diagnose issues and either fix them (e.g. failover) and/or advise the support team of the issue (in precise terms) such that it can quickly react and sort the issue out.
Performance
Need to consider early our confidence that the chosen architecture will be performant - relates to scalability in that scalability is one way to increase capacity and hence performance.
Security
To ensure that access to the application and any information it contains is controlled and that the application is as secure from attacks as possible.