Minimum Hardware Requirements

Such a simple topic, huh? All we need to understand is the minimum amount of resources required to use a product, surely that should be a simple thing for a vendor to answer. It is their product and nobody knows their product better than them, right? Well answer they do but beware those answers because they are not necessarily accurate and the motivations for providing the answer are often entirely different from those that are asking the questions.

An IT Administrator's Perspective

An administrator worth the title wants to provide a service that their users will not complain about using the least amount of resources possible ... budgets are always tight and are often squeezed tighter but end-users do NOT become more patient over time. When they ask about minimum hardware requirements administrators want to know how much and the type of resources to dedicate to the task of keeping their users happy. From an administrator's perspective, this should be a simple question for the vendor to answer and depending upon the application, it can be.

Take an application like email, for instance, while the size and quantity of emails can vary greatly from person to person and even, to a lesser degree, from organization to organization, the handling of email is very similar in virtually all cases. It is feasible to provide a sizing function based on quantity and size of emails that is at the same time reasonably accurate and easily understood. And of equal importance, these functions are almost always linear in the way they scale, up to the maximum resources available at least. If one doubles the input (eg: twice the number of users) then one can count on requiring about double the amount of resources.

There are actually only a very few applications that are so well understood and so single-minded in their tasks as email servers that such functions are possible, but the desire from IT is for it always to be there and they will always ask. They certainly can't be expected to determine the correct resources on their own! and you are probably spending upwards of $100k or more before it makes economic sense to pay an expert to do such resource acquisition. And, if we are being honest, and while there are a great many very intelligent and experienced IT administrators, the vast majority in that position are ordinary people very often at or near the beginning of their career. Many do not have the experience necessary to recognize that not all applications are predictable and so, understandably, simply expect the same base information from all vendors.

A Vendor's Perspective

There are many people and roles within any software vendor organization, so it is a tad unfair to suggest that a vendor has a single perspective, however it is certainly fair that a great deal of departments / divisions within a software vendor are aligned with a single goal ... to ensure that customers use the application and are satisfied with the experience. The goal is that the customers should never have to call the Customer Support department.

Few people truly understand the economic model of a business based on software licenses. While it does change depending upon the maturity of the software vendor, the goal is always the same and that is to create a recurring revenue stream. Software licenses are usually sold with two or three components:

1. The initial one-time cost of the license
2. The recurring software maintenance cost, and
3. The recurring support costs

Together the two recurring revenue streams come in at between 15% and 25% of the "one-time license" on a yearly basis, though many vendors do not split the two revenue streams. The economic goal of all software vendors is to provide a large enough license base that the recurring revenue stream becomes the major revenue stream ... because when this happens it is FAR, FAR easier to predict the financial health of the company. Microsoft, for instance, has such a large and committed support/maintenance revenue stream (also known as a customer base) that they MUST make plans that exceed 36 months in the future because the vast majority of the revenue they will receive in the next 36 months is already committed. They can only affect things very little in the short term for even the decision to not pay maintenance anymore is not one that is contracturally possible for many of their customers for 2 or even 3 years.

Contrast that reality with a software startup that has no existing customers and, therefore, no recurring revenue. They must make all of their money, or at least the vast majority of it, in the form of new customers buying new licenses. This is not only much more difficult to do it is very difficult to predict because the future brings with it so much chaos. This reality means that there is a lot of rapid development and very little spare cash ... things get created without the necessary discipline and such things like "Minimum Hardware Requirements" are little more than an afterthought. This reality is unfortunate but a public company caring about it's share price (which is the fudiciary responsibility of the Director's of a public company) has little choice; spending money on such collateral is not just a waste of money it is a waste of time that is better used in getting the product out the door which they must do because they have to sell new licenses to meet their revenue targets provided to the "the street".

So, the game for a software vendor is to build out a customer base because not only do software vendors look to maintenance and support for the recurring revenue stream, they also look to it as a HIGHLY profitable one that can provide a profit margin as high as 90%! This is the prime motivation for making bug free code, to try to ensure that the support customers are often forced (by license agreement) to purchase are never needed.

And thus we come to Minimum Hardware Requirements.

A software vendor wants to convince customers to dedicate the LARGEST POSSIBLE RESOURCES to do the job because the more resources provided the less likely that that hardware infrastructure will be the root cause of customer-perceived application problems. Now of course there is a dance here, if a vendor goes overboard on the recommendations then customers will come to distrust the vendor and that will spill over to other areas, and so there are many people within an organization who would really like to meet the expectations of IT.

That being said, it is in the best interest of nearly every staff member of a software vendor to convince their customers to deploy more hardware then the customer may need; they will get fewer performance problems and generally have an easier time with setup, configuration, and ongoing maintenance. Very few staff members will be paid to insure a customer's ROI is met thus even when the motivation isn't the corporate bottom line, their own job function often serves the same purpose.

A Computer Architect's Perspective

In the end, while the corporate goals outlined above are real, they are only really important to and pursued by management; workers of the corporation have perspectives that align with their job function. An IT expert within an organization desires to provide that sizing function, a Customer Support Representative wants to provide support and answer the question posed, and an a computer architect tasked to answer the question must keep both the technical and business perspectives in mind and create an understandable and defensible set of requirements.

The problem is that for some applications, the true answer to the question has almost no meaning or value to anybody. Let's take a concrete example of a Livelink installation ... now the truth is, as every single Open Text sales-droid, global services technician, customer support representative, and developer of that application knows by experience, it is possible to run a complete Livelink-based application using only a single computer ... a laptop even. However true that statement may be, it is not in any way valuable to those tasked to architect a solution and it certainly doesn't help the customer support department; should anybody take such a minimum seriously, they would certainly find performance problems very quickly and calling up the support department for help.

An architect's job is to provide an infrastructure that is required for the solution along with the justification for the infrastructure and the variables (or "tuning knobs") involved to allow future architects to adjust the design as the problem space changes. And the real truth about this is that it is perhaps one of the most difficult and under-appreciated jobs in the industry. That is particularly so for an application like Livelink because, in deference to email, Livelink is highly variable in the types of tasks (functions) it does and the resource requirements required to meet those functions. In a very real sense, it is not possible to provide meaningful Minimum Hardware Requirements for an application like Livelink, though it is absolutely possible to do so for the solutions that are built from it.

So, the architect must dance better than anybody; she MUST provide a justifiable answer else she doesn't get paid and if she works for the software vendor, she must also provide an answer that is reusable and meets the corporation's goals as outlined above. And so she does the only thing she can do, she uses all her knowledge and experience to: 1) provide an initial estimate or starting point; and 2) provide a model and methodology for building on the starting point.

The starting point is by far the easier of the two tasks; assuming they have the application-specific knowledge and experience, it is a task that any computer architect can and should be able to do after only a few months with an application.  But creating a model and methodology to build on that estimate in a predictable and understandable way is a far more difficult task suitable only to the most senior and competent amongst us. It takes a special brain to discover the abstract concepts within the concrete example. This is the reverse process that most of us use daily: a recipe for dinner and a computer algorithm are both examples of abstract concepts leading to concrete examples like food and an application. But imagine eating a nice dinner and then determining what the recipe is... that is often the task that must be performed when creating such Minimum Hardware Requirements.

USING the methodology is usually not hard if you understand the model. Unfortunately, not all architects take the time to truly understand what they are doing ... they really aren't architects at all but glorified IT administrators that are capable of implementing based on a clear set of instructions, they can understand the variables required and provide appropriate values such that they can create the architecture based upon the model. But, this only works if the model perfectly describes the application and that is unlikely in a dynamic application.

Broken But Still Used

As I said, there really are not a great number of people who understand computer architecture, systems design, corporate economics, and have a thorough enough understanding of an application to be able to create Minimum Hardware Requirements and so once they have been done, they are very unlikely to get redone. They are a guess at the best of times and out-of-date virtually upon publication, and yet the difficulty in creating them means that they are used for years ... well after the justification for them, and likely the person(s) who created them both being long gone. Yet the need for them hasn't changed over time, rather it has probably increased!

As new architects join an organization they need to learn about how things are done and so they, of course, use the same methodology and continue to use the same recommendations ... likely without questioning the wisdom at all, rather feeling glad that there is some methodology to follow. This approach is ideal if and when the methodology is accurate but is less than optimal otherwise. Actually, it's worse than just not being ideal, in any ordinary organization, the wisdom required to use the methodology is lost and twisted ... minimums designed as "a good starting point" become rules that are set in stone ... advice intended to allow flexibility become inflexible edicts and as just about everybody involved attempts the "Cover Your Ass" approach, these methodologies very often produce unbalanced and sub-optimal solutions.

Once that initial knowledge has completely been drained from the organizations; once the designers of the methodology have left then the methodology moves from helpful advice to "written in stone" and those once helpful documents become a dangerous set of tools that are very unlikely to create an optimal or even reasonable deployment. Worse than that, there are in fact very few people who would even know that that had happened...instead, designs are made with false assumptions, hardware is over-specified, money is wasted, and performance (and even robustness) suffers.

So, before you use that Minimum Hardware Requirements document from your software vendor, ask them how old the documents really are, how they got created and if there is anybody within the organization who actually understands the model. If the documents/methodology is over 3 years old, the recommendations are suspect on the face as all software changes radically in three years (if it didn't then Vendors couldn't justify the maintenance costs), Moore's law suggests the computer resources are 4 times greater and the vendor's knowledge about that application SHOULD have increased so why haven't the documents been updated?

ALWAYS REMEMBER

Public companies are capitalist organizations first and anything else second. It is the bottom line and only the bottom line that is important to a public company, any and all actions are directed towards that fact. That doesn't mean that a public company always makes the right decision for the bottom line, sometimes the equation isn't well understood, but the motivation is always the same. Documents like "Minimum Hardware Requirements" are very expensive and time consuming to make; there is no incentive to redo the work as it is seen as a pure expense; if there are any, updates become unjustifiable increases in RAM and CPU requirements "to keep up with the times" typically only serving to waste customer resources and when updates do not occur, eventually the minimums tend towards an under-configured solution.

You do need to start from some place, that is how a Minimum Hardwarae Reqiurements document should be viewed, as  starting place with enough resources to give the breathing room necessary to monitor, gather statisitcs and perform trend analysis so you can define a proper model for YOUR solution. The problem facing us all is that trend analysis is work that few budget for and so the the knowledge required to refine doesn't exist and the next phase / upgrade is once again based upon the (faulty) methodology and the cycle continues.

I'll follow up this topic with a specific post on the Minimum Hardware Requirements for Livelink as I have had two recent experiences with Open Text customers and staff members that indicate that Open Text's Minimum Hardware Requirements documents have lost a lot of value and are in danger of actually causing problems rather than solving them.