Big Ideas in Small Design: SMB vs SME

Ask 10 people what the difference is between small to medium business (SMB) and small to medium enterprise (SME), and we’re going to get nearly 10 different answers. Some will say that it’s a distinction of organizational structure. Others will say that an SMB becomes an SME after it reaches a certain number of employees. Still, others will say that it’s only a difference of terminology and that the two terms are used interchangeably depending on locale. None of these is necessarily wrong, but a hazy definition makes for a difficult marketing target and people like to simplify.

For purposes of design, it’s best to leave out the size and focus on the approach. That leaves us with the last letter of the initialism: business vs enterprise. Business can be defined as any commercial operation. Enterprise, on the other hand, has more interesting connotations. Looking at the Oxford English Dictionary, we find boldness, complexity, initiative, and resourcefulness associated with the definition.

For our purposes, let’s say the SMBs are the static organizations with needs met by basic technological solutions. The SMEs, on the other hand, are growing quickly and their requirements can change almost daily.

Still, SMB and SME are treated as one market segment by most, and the products lean heavily toward the first of these.

The Three-Year Projection

Three-year (and sometimes longer) projections are an important part of determining the suitability of a design. Nobody wants to have to do unplanned forklift upgrades before the components have reached the end of their projected usefulness. Without those projections, early upgrades are far more likely to be a reality.

Various factors are usually taken into account, most of them revolving around business growth estimates. For static SMBs and perhaps some of the larger organizations, this is going to be fairly linear and easy to project. The more adventurous organizations, like the SMEs, make this more complicated. This is a nice way of saying that they can sometimes be completely unpredictable.

Now!

The more adventurous enterprises out there have a fairly consistent timeframe for when they need network enhancements, and it’s not tomorrow. We can say that it’s not within the scope of the design, and that will work once or twice. The more often it occurs, the closer we get to that unwanted premature upgrade.

Scaling Up

When it comes to small enterprises, building for the now (or even near future) and hoping that they don’t outgrow the architecture is a risky gamble. Traditionally, there really wasn’t much of a choice. SMEs are usually constrained by cost, so building something good and fast (and, more importantly, flexible) usually ran afoul of The Twelve Networking Truths, or RFC 1925 (7a) and required compromise. Those compromises usually amounted to building an SMB-focused solution that just didn’t have the flexibility to grow as needed.

A few things have changed over the years.

Commoditization

Open source has been a catalyst for bringing advanced networking capabilities to a wider audience. Once a technology has a solid implementation in Linux, smaller and cost-conscience organizations will jump on it because it’s free! Eventually, they find that the effort and cost of maintaining these systems needs to be factored in, but this takes time. Open source is great, but from an operational standpoint, it’s “Free as in Puppy” to use.

That said, it’s only a matter of time before it gets turned into an appliance with one company or another offering a turnkey solution with full support, taking away the pain at a reasonable price.

Once the larger vendors begin losing sales to these solutions, we start seeing some of those more advanced features finding their way into their less advanced offerings.

At this point, whether we go with the open-source-based products or vendor solutions, we have many more options available to us than we used to.

Scaling Down

The products available on today’s market are much more capable at a far lower cost than they used to be. This gives us the ability to apply designs that are more flexible than before without exceeding customer budgets.

Applying a large design to a small enterprise will ultimately save money and time, but may require a bit more gazing into the crystal ball to estimate where they’re likely to be.

We shouldn’t be thinking in terms of what the customer needs now until the customer says they need something now. If we’ve thought big enough in the first place, whatever requirements the customer comes up with later shouldn’t be a big problem.

The Whisper in the Wires

The networking industry as a whole has a tendency to assume that smaller networks are simpler networks, and this is reflected in the products that are marketed to the small space. This isn’t universally true, but it’s common enough to limit the options for small offices.

Commoditization slowly brings larger enterprise technologies down to a level that fits into a smaller cost/benefit analysis. We no longer have to settle for the basics when our customers are growing faster than the basics will allow for.

We need to design for where the customer wants to be and stop thinking in terms of where they are now. That’s going to involve more than just projected growth. Resizing larger designs for a smaller implementation takes away many of the restrictions found when trying to scale smaller designs up.

Originally published on the Aruba Blogs site.