A hard lesson in scalability (or why a riding mower is not a farm tractor)
I’ve talked about this before at some conferences and often folks look at me a bit askew when I start out, so let me state upfront this article is about designing for scalability, extensibility and enterprise scale IT systems. All will become clear.
Until about a year ago I owned 10 acres of land out in Wilson County in Tennessee. The land was challenging at best; very hilly and uneven with a creek running through the middle and lots of wild blackberries. I decided early on that it really needed a small tractor and a commercial brush mower to keep it tidy, and bought a DR Field and Brush and a small diesel tractor. The DR was a wonder, easily one of the most robust and well-designed machines I have ever owned. The tractor – not so much. Apart from anything else it had an exceptionally high center of gravity so it was a constant roll-over risk.
In spite of this I made it work, but it reached an untimely end when a rather cocky contractor working on my trees asked if he could use it, and when I warned him about the center of gravity he informed me he had been riding tractors for 40 years and knew what he was doing. Needless to say he flipped it within thirty minutes and broke his collar-bone, and the tractor was not easily repairable.
I was persuaded that rather than replacing it I should look the more robust models of riding mowers. I’m not talking the really little ones that make grown men look they are riding clown cars, these are larger machines, up to 30hp, with significantly-sized wheels. The one I settled on had the ability to attach non-powered attachments behind it, had decent tread, and (on paper) lots of power.
I quickly learned a riding-mower, even the largest one, is not a farm tractor. The wheels, while a decent size and with good tread, slipped on surfaces that my tractor would have happily coasted over. A farm tractor has a shaft at the back running off a PTO or Power Take-Off. This allows you to attach implements that run off the tractors engine, while the riding mower could only do the same with a deck under the belly. Surfaces you could ride over all day on the tractor became exercises in surviving bone-jarring hours of driving that would leave you sore to the bone on the riding mower.
Other things became rapidly apparent. The slightest moisture on grass or brush would immediately make the property uncuttable. Part of this was due to the mechanics of torque from a diesel versus a gas engine. My 30hp riding mower had a fraction of the power of my 17hp diesel tractor, or put another way if I ran my mower into my van it would probably have bounced off whereas the tractor could likely have turned it on its side.
The lower riding position made it impossible to cut anything long, and it was much likely that stray branches from blackberries could encroach on your cutting path and rip you up. Plus being lower to the ground meant that when you shaved the top off a yellow-jacket nest you got into trouble so much more quickly. Basic things such as being able to back a tractor into brush to cut versus having to ride over it with the lawn mower made things so much slower. The smallest tree stump that the tractor would simply drive over could stop the mower dead in its tracks.
So OK, how is this about enterprise system design? Simply put a tractor is designed from the ground up to deal with situations and do tasks that a riding mower will never handle. It was not a case of maybe if I got two or three lawn mowers and got my teenage boys to mow with me that a riding mower would ever do what was needed, the device itself would never scale.
This does not mean riding mowers are badly designed, they are designed to perform a function. It also does not mean that using lots of smaller devices to achieve scale won’t work, that is in fact fundamental to the scalability of many large scale system today. The difference is that they were designed that way from the start. That is, after all, the premise of systems such Oracle RAC which uses clustering for high availability and performance.
On the other hand I deal with systems almost weekly where the initial design and requirement gathering process did not identify the end state of the system, and as a result fatal design flaws have been implemented along the way. This can manifest in countless way:
Enterprise architecture, platform governance and architecture reviews are one way of helping to control the problem, but they are only as effective as the institutional will to enforce them. Allowing the exception to go ahead because it is expedient, or the business owner has political clout, or because you miscalculated and suddenly have to do something to catch up with a competitor, are all potential ways or rolling out a solution that will may scale to meet your needs in three years.
In the end I sold my riding mower and bought a small 17hp Kubota tractor, without the high center of gravity. It didn’t solve all my problems, I could have used more power and the ubiquitous yellow jacket nests still got me occasionally (although I was able to see them better). Having a tractor designed to bush-hog, however, taught me a hard lesson in buying based on your requirements, and what extensibility and scalability mean.
In the end wishful thinking is not a strategy.
Until about a year ago I owned 10 acres of land out in Wilson County in Tennessee. The land was challenging at best; very hilly and uneven with a creek running through the middle and lots of wild blackberries. I decided early on that it really needed a small tractor and a commercial brush mower to keep it tidy, and bought a DR Field and Brush and a small diesel tractor. The DR was a wonder, easily one of the most robust and well-designed machines I have ever owned. The tractor – not so much. Apart from anything else it had an exceptionally high center of gravity so it was a constant roll-over risk.
In spite of this I made it work, but it reached an untimely end when a rather cocky contractor working on my trees asked if he could use it, and when I warned him about the center of gravity he informed me he had been riding tractors for 40 years and knew what he was doing. Needless to say he flipped it within thirty minutes and broke his collar-bone, and the tractor was not easily repairable.
I was persuaded that rather than replacing it I should look the more robust models of riding mowers. I’m not talking the really little ones that make grown men look they are riding clown cars, these are larger machines, up to 30hp, with significantly-sized wheels. The one I settled on had the ability to attach non-powered attachments behind it, had decent tread, and (on paper) lots of power.
I quickly learned a riding-mower, even the largest one, is not a farm tractor. The wheels, while a decent size and with good tread, slipped on surfaces that my tractor would have happily coasted over. A farm tractor has a shaft at the back running off a PTO or Power Take-Off. This allows you to attach implements that run off the tractors engine, while the riding mower could only do the same with a deck under the belly. Surfaces you could ride over all day on the tractor became exercises in surviving bone-jarring hours of driving that would leave you sore to the bone on the riding mower.
Other things became rapidly apparent. The slightest moisture on grass or brush would immediately make the property uncuttable. Part of this was due to the mechanics of torque from a diesel versus a gas engine. My 30hp riding mower had a fraction of the power of my 17hp diesel tractor, or put another way if I ran my mower into my van it would probably have bounced off whereas the tractor could likely have turned it on its side.
The lower riding position made it impossible to cut anything long, and it was much likely that stray branches from blackberries could encroach on your cutting path and rip you up. Plus being lower to the ground meant that when you shaved the top off a yellow-jacket nest you got into trouble so much more quickly. Basic things such as being able to back a tractor into brush to cut versus having to ride over it with the lawn mower made things so much slower. The smallest tree stump that the tractor would simply drive over could stop the mower dead in its tracks.
So OK, how is this about enterprise system design? Simply put a tractor is designed from the ground up to deal with situations and do tasks that a riding mower will never handle. It was not a case of maybe if I got two or three lawn mowers and got my teenage boys to mow with me that a riding mower would ever do what was needed, the device itself would never scale.
This does not mean riding mowers are badly designed, they are designed to perform a function. It also does not mean that using lots of smaller devices to achieve scale won’t work, that is in fact fundamental to the scalability of many large scale system today. The difference is that they were designed that way from the start. That is, after all, the premise of systems such Oracle RAC which uses clustering for high availability and performance.
On the other hand I deal with systems almost weekly where the initial design and requirement gathering process did not identify the end state of the system, and as a result fatal design flaws have been implemented along the way. This can manifest in countless way:
- Selecting a database technology or version which is intended for individual or departmental use and is unable to handle the volume of transactions as you scale.
- Designing the system using an interface engine that will scale up to only a certain number of transactions and becomes incrementally slower as you scale beyond the threshold it was designed for.
- Doing development using a single monolith that makes it impossible to do changes without impacting 500,000 lines of codes.
- Using scripting languages to do development when you should be using a more robust language for your application.
- Using third party, sometime open-source, libraries with limited support that cannot be deployed on more than one device, causing a single point of failure or bottleneck.
- Writing overly “chatty” applications that generate a level of network that causes latency issues at scale.
Enterprise architecture, platform governance and architecture reviews are one way of helping to control the problem, but they are only as effective as the institutional will to enforce them. Allowing the exception to go ahead because it is expedient, or the business owner has political clout, or because you miscalculated and suddenly have to do something to catch up with a competitor, are all potential ways or rolling out a solution that will may scale to meet your needs in three years.
In the end I sold my riding mower and bought a small 17hp Kubota tractor, without the high center of gravity. It didn’t solve all my problems, I could have used more power and the ubiquitous yellow jacket nests still got me occasionally (although I was able to see them better). Having a tractor designed to bush-hog, however, taught me a hard lesson in buying based on your requirements, and what extensibility and scalability mean.
In the end wishful thinking is not a strategy.
Comments
Post a Comment