Database sizing remains an enigma to many. The norm for years has been to “guesstimate” and pad. And pad and pad. Every level and every signer wants to be sure they have padded so the system does not need additions for a specified time. Historically, I have used three years, but these days, in non-cloud systems, I set expectations for one year. It’s just hard to guess and it can be costly with 3X padding. In cloud systems, you are not forced to tighten down your estimate.
However even those on the cloud, with its dynamic provisioning, need to have a handle on database sizing in order to prepare a directional budget. The idea behind dynamic provisioning is hands-off scaling. Data growth should mean business growth which should cover the additional expenses of the data, but it is sometimes not so clean. If only for the intangible benefits associated with the understanding, sizing should be done even for cloud environments.
Back to the on-premises approach, while it would seem at first blush that it would wildly overestimate the space required, this is not always the case. Many times, companies will coincidentally hit the mark because the padding will cover up for another, ignored area. This is the area I want to bring to light.
The neglected area of database sizing is a business vision of the possibilities for the expansiveness of and use of data within the charter of the database. While we pad the core sizing estimate, we underpad vertical expansion of data – into other fields and tables – and user derived fields. Business vision means asking the question “With this core of data, what other data could be added in the near future to meet business needs and goals?”.
This vision can be limited with internal resources initially, but often an external consultant with visibility into where more progressive companies, from the same industry and other industries, have taken their similar databases. This is especially true in the midmarket, where the competitor list is voluminous and often ambiguous. In the midmarket, due to similar scale, relevant case studies and ancedotes for database use can be found in a wide variety of industries. Much of the success of a database effort in the midmarket will be based on choosing reference points wisely.
Futhermore, the vendor community (i.e., in the cloud) has been largely focused on streamlining processes no matter the company size. This actually provides many more advantages to the midmarket, where wasted dollars and straying from core knitting can have much more deleterious effects on the business.
For example, a database thought to only store going-forward transactions for 13 months could be expanded to load all history available, never release data, and store the data at a line item, not transaction, level. Other fields could also be brought into the record.
With vision of the possibilities for business gain through using the additional data, storing it is a no-brainer. This is just initial sizing. Maybe initially it’s covered in the padding and the idea will be to reevaluate it in a year. However, knowing the possible eventuality may also influence platform selection!
Applying 3X padding to the estimates that include vision could have extra costly consequences. That is NOT the idea. If on-premises, consider the cloud for its value proposition or, at the least, get on point with database sizing by including vision in your estimates.
This post was written as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions.