Everything changes and nothing stands still. That is especially true of technology. Many of today’s products will be outdated in a single life cycle. As new features are added at each major release products can be completely transformed within a few short years.
Technology vendors pitch themselves as solution providers, offering answers to the problems we didn’t even know we had. This is a problem for IT staff and decision makers, as they are forced into a never ending game of catch up and product evaluation.
When assessing new technology and its promised problem solving functionality, some will think in terms of return on investment and costs, but not all benefits are easily measured in dollars, euros, pounds, etc. Poor initial design may well cost the business far more over the long term. Technology influencers have to explain the complex benefits/risks matrix in clear concise arguments that take the company in the right direction.
Technology solutions reference model
Availability, Manageability, Performance , Recoverability and Security are infrastructure qualities that the virtualization vendor VMware advocates in it’s design certification and training. Other vendors may use different terms but the concepts are similar.
Availability: Technology that achieves reliability, redundancy and resiliency is easy to measure, more availability increases the cost, customers pay for uptime, its tangible and easy to understand.
*For example uptime SLAs are often stated in 9s, such as 99.999 = 5 min per year downtime, 99.99 = 52 min per year downtime
Manageability: This is not so easy to measure, but we all understand the concept, there are plenty of horribly designed applications, mind numbing awful processes. Manageability, includes compatibility, usability, interoperability and scalability, but how is it to be measured?
Let take as an example of usability. Customer feedback indicated people weren’t happy about the loss of the start button in the first editions of Windows 8.0. Of course this is something completely subjective, only after go-live did a company with the status of Microsoft see that.
With management software that only a few administrators access, it would be easy to argue that lower licensing costs outweigh the benefits of intuitive well designed solutions. Though this reminds me of a series of accidents involving B-17 airplanes in the 1940s. It was realized switches controlling the ﬂaps were were side by side with identical switches controlling the landing gear. Under the pressure of a difficult landing, pilots were making mistakes.
The damage that system administrators can do through human error can cause businesses to grind to a halt. The cost of poor usability is often hidden in the cost of downtime, support calls, time spend reading manuals and blogs, beside human error, poor motivation and disdain of IT staff.
Interoperability and Scalability also need to be considered, is there a requirement to share data with other platforms, or what will be the effect on performance as usage increases?
Performance: Poor application responsiveness will eventually draw heavy criticism, and there are a multitude of tools for measuring this once a solution is in place. If the design is scalable, elastic and available resources are in place, then additional resources can quickly be added.
The reality is that it most on-premises solutions are more static than elastic, we can scale up or out, but static pricing models or change request processes prohibit near instantaneous expansion or reduction of compute power. Consequently, we have to architect for peak average performance or manufacturers recommendations. Costs may inflate to such an extent we deliberately underestimate performance or future growth to sell the project.
Recoverability: The quality of how quickly and how much effort is required to recover from an event affecting availability, measured in RTO (recovery time objective) and RPO (recovery point objective). It’s a given that recovery is guaranteed, what may vary is acceptable data loss, and speed of recovery. When disaster recovery and elements of business continuity are also required significant costs need to be added on.
This is such a complex field of permutations that we may be tempted to oversimplify the choices to get the design completed by deadline.
To give an example, imagine telling management that all critical servers were protected from disaster because they are on replicated discs shared between data-centers, however we also need to calculate compute, network and storage requirements for the recovery datacenter. Besides this downstream dependencies for each application need to be considered.
Another factor is the quality of technical support when products break, measuring the ability of a solution provider’s support is not really possible until it happens.
Security: Each option we chose, whether technical, organizational or operational will impact security in some way. For many companies this is the poisoned chalice, most would accept days of outage rather than a security breach.
Security of a single solution may fill pages of documentation, security auditors need to be presented evidence of compliance, and some solutions just haven’t thought this through.
If we were to put all the above relational diagrams together elements of one quality might easily overlap into another, that’s not a problem, as the idea is get thinking down to details, what is missed out can be the issue. Hopefully this blog will help you present product evaluation or comparison in a way that is best for your business.
This is the first in a series of post assessing vendor products in light of the AMPRS infrastructure qualities.