Make it your rule, not a conjecture.
Every IT system solution should have a clear focus on 3 key attributes of quality. 3QF: The 3 key factors of quality delivery. Elevated to prominence , in your organization, as much as possible.
The 3 quality factors are
The order is not significant. After project context and scope are understood, good IT Architect, should always ask this questions:
Is the Solution:
- Scalable enough?
- Resilient enough?
- Compliant enough?
These 3 key questions should be asked regardless of the level of the project. From micro to macro solutions. From applications all the way up to the enterprise architecture.
3 key quality factors (3QF) should be pervasive on every IT Architecture level. Why?
3QF focus increases ROI
Business Management will use its right to be diligent)and will surely ask: is the insistence on these 3 attributes feasible? Is this not increasing “Time to Market” and thus decreasing the ROI ?
My answer: It will in the short run, but not in the long run. Look into the whole picture. Consider the solution time line in the widest possible sense.
And this is directly related to the projected longevity of the IT system, the dark force leading to the pain many enterprises are experiencing today with legacy systems.
Projected longevity is directly related to observed system position on the organisations IT landscape. Confusing? Here is the mandatory diagram, from your good architect:
Y axis is simply the level of 3QF focus while planning and the amount of effort when applying the 3QF, at the very beginning.
The message is clear: he who pays attention to 3 Key Q Factors (3QF) will benefit in the medium and long run. And he who does not, he will have quick and inferior solution, delivering some small benefit in the short run but will experience diminishing ROI in the long run. Forever nearing the painful zero. How?
Please consider the use case hidden in the above deceptively simple diagram.
Imagine Sys “X” and Sys “Z” are two competing solutions of the same market requirements. Two competitors started building at the same time this (for example ) new kind of platform, based on some new but proven concept a lot of users will need to solve a real problem. There was an obvious money to be made, market to be conquered and investors to be pleased.
Sys “X” management has decided they will not listen to the resident Architect and will not focus (at all) on this “3QF thing”. Thus, Syst “X” was built rather quickly by neglecting the 3QF. And then released quickly to the cheer and joy.
What happens next? Time passes, number of users grow but the Sys “X” is very expensive (and hard) to scale up, because it is not scale-able. And one of the F’s in 3QF is scalability. Sys X vendor (as an immediate consequence of not planning for resilience, yet another F of the 3QF’s ) experiences very high costs of maintaining the service this system provides. This is because they (by now) have to increase the necessary infrastructure size, to meet the users peaks in demand, for example. And this is one very short lived stop-gap measure. At that stage the Sys X vendor realizes, it can not keep up with the demand.
Simply system is not Architected to not-expand and users are fast to expand in numbers. Very soon, Sys X performance drops seriously and users are angry, and users are leaving. Paying visitors will always leave the party first. ROI inevitably suffers. That is the min ROI curve on the diagram. It is by now very difficult to keep Sys “X” in the business.
While, in parallel, the other Sys “Z” was pricier to start with. Architects insisted on 3QF focus, from the day 0. But in this case they were listened to. Inevitably System “Z” was not that quick to the market as the competitors Sys “X”.
Focus on 3QF and inevitable testing focus, were the imperatives. System “Z” was released later and it was also more expensive than “X”. ROI immediately dipped in a short run. But then people started talking as this System was obviously very fast and resilient, on its own and also when compared to competing Sys X.
Number of Sys Z, paying users has rapidly grown. But this time resilience and scalability were architected, designed and implemented from the beginning. Increasing the capacity of system “Z”, was easy and painless and cheap and easy to administer and monitor. Users were happy and even more of them came, especially disappointed ones flocking over from Sys “X”.
And all of a sudden Sys “Z” owners have arrived at the point where ROI curve started heading forever upwards. Since then System “Z” has grown even more and is still in the business, and still returning handsomely what was invested in it.
So, whatever is being planned, you better listen to your good IT Architects if they advise (in the planning stage) seemingly expensive measures to (sometimes radically) elevate the 3 Q factors, aka 3QF.
That will lead to concepts and solutions built on the foundations of the sound principles. And that will certainly increase the initial cost of the delivery. But always remember this story.
Those 3 factors, properly introduced, will definitely decrease the inevitable IT crisis “down the line” that many are experiencing today with legacy systems which are either not scalable, nor robust enough or simply not compliant. This is sometimes called “technical debt”. (For an real life example look no further than Windows OS. )
Banking, Software and 3QF
Banking is an good example when observing the problems amassed through time just because some banks, System X was hastily delivered without 3QF principles applied.
Do keep in mind we are talking whole IT systems here. IT architectures. Not micro-level implementation details. Do not view them in isolation. As an example software code quality is an important factor of software component robustness. But software development is a dynamic ever changing process. Compared to IT infrastructure, the software component is easier to change or upgrade; thus being important, software 3Q Factors are not as important as, 3QF driven solutions of the underlying IT infrastructure and platform.
Compared to big-iron hardware, software is small and dynamic and extremely changeable. The software can and will increase its 3QF through time. But, not so the “big iron”. The underlying IT infrastructure. Often hastily piled up. while happily ignoring the 3QF, leading its owners to ruins.
If a resulting infrastructure is not scalable, robust or compliant, that will hit the software layers, built on top of it hard. Sooner or later. And the sooner the BIG mistake is recognised the better. As very few veteran CTO’s have survived to tell.