Navigate your project very carefully
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.
3QF
-
Scalability
-
Resilience
-
Compliance
The order is not significant. After the project context and scope are understood, a good IT Architect should always ask these 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 up to the enterprise architecture.
3 key quality factors (3QF) should be pervasive at every IT Architecture level. Why?
How 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 be in the short run, but not in the long run. Look into the whole picture. Consider the solution timeline 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 the observed system position on the organisation’s IT landscape. Confusing? Here is the mandatory diagram, from your good architect:
It has happened, that System “X” and “Z” have started on the very same day. The left vertical axis is simply the level of 3QF planning effort and the amount of effort when applying the 3QF, from the very beginning of both product’s timelines.
Focus for 5 seconds on this picture. 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 will have a 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.
Sys “X” and Sys “Z” are two competing solutions within the same market. Two competitors started building at the same time on the same platform, based on some proven pain points, for which a lot of users will need to solve a real problem. There was obvious money to be made, a 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, and users do grow. But for the vendor, the Sys “X” is very expensive (and hard) to scale up, because it is not architected to be 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 3QFs) 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 user’s 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 “X” is not Architected to expand but its users are fast to expand in numbers. Very soon, Sys X’s performance drops seriously and users are angry, and users are leaving.
Paying users will always leave first.
ROI inevitably suffers. That is the bottom ROI curve on the diagram. It is by now very difficult to keep Sys “X” in the business, knowing what is coming.
While, in parallel, the other Sys “Z” was pricier to start with. Architects insisted on 3QF focus, from day 0. But in this case, they were listened to. Inevitably System “Z” was not as quick to the market as the competitor Sys “X”.
Focus on Sys”Z” 3QF and inevitable testing focus, were the imperatives. System “Z” was inevitably released later and it was also more expensive than “X”. Naturally ROI immediately dipped in the short run. But then users started talking as System “Z” was very fast and resilient, on its own and also when compared to competing Sys X.
Several Sys Z, paying users have 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”.
All of a sudden Sys “Z” owners have arrived at the point where the ROI curve started heading forever upwards. Since then System “Z” has grown even more and is still returning handsomely what was invested in it.
The morale
So, whatever is being planned, you better listen to your good IT Architects when 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 sound principles. And that will certainly increase the initial cost of the delivery. But always remember this story.
Those 3 factors, properly introduced, will decrease the inevitable IT maintenance crisis “down the line” that many are experiencing today with legacy systems which are either not scalable or robust enough or simply not compliant. This is also called “technical debt”. (For a real-life example look no further than Windows OS. )
Compliance?
We have not mentioned the Compliance. One-third of the 3QF. Is there anything more important than Compliance in Banking, you might ask? Well … let’s not go there, right now.
We are where we are, and Compliance turns out to be a problem number one for almost all organizations. “Numero uno”.
The big hidden dark matter cloud of the Technical Debt.
The funny thing is, that Cloud migration is the golden opportunity to solve it once and for all. Migrate the organization’s data in a compliant manner, and its compliance levels will dramatically increase. Then we must tackle the GDPR.