You Scaled Your What?

“We’re embarking on a project to provide us 4X improvement in scalability.”, said the enthusiastic architect.

“Really, in what way?”, I replied, knowing that the trap had already been laid.

“What do you mean, it’s obvious, we will have 4X the scalability of our current architecture when we’re done!”, my com-padre stated with a confused brow.

“Is that transactional headroom, storage improvements, reduction in operations staff, or time to market for new features?”, I offer, struggling to hold back a wry smile.

“Uh, well, I guess it’s transactional headroom, or at least that is what I call scalability.”, he offers, realizing this is probably not going where he wanted.

“Well, can you achieve your 4X scalability if you experience a 4X increase in data volume?”, realizing that I now feel sorry for him.

Yes, this conversation happens far too often. Scaling systems actually require managing the scaling along all of the vectors. Ignore one and that will be the one that becomes your next bottleneck. But what are the vectors? Where is our friend, full of enthusiasm, misguided? Let’s look at the minimal set of scalability vectors that should be considered in every architecture.

The article reviews distinct properties of scalability of an IT business architecture. Dan outlines the following traits:

  • Transactional scalability
  • Data scalability
  • Operational scalability
  • Deployability
  • Productivity
  • Feature time-to-market

He sums this up with a nice spider diagram with an unreadable font, providing visual mapping of those concepts.