Farming and IT Frameworks in the Modern, Cloud World
We often get asked if IT frameworks are still applicable in the modern, cloud world. If frameworks are used as a compass and not as a road map, they absolutely still apply. The principles still apply. If one is trying to use a framework as a road map, then the desired destination may never be reached.
In addition to us getting the question so often, it is concerning to us that so many companies and groups are publishing “new frameworks” to try to capitalize from customer confusion about how to be successful in the modern and cloudy world.
We decided to show that the generic concepts from IT best practices not only still apply to the modern, [public and private] cloud world, but also to farming. If we can apply IT best practices and frameworks to farming, surely we can still gain insights to help us in IT.
Read more about CloudFit Software and how we serve our amazing customers. We would love to help you and your business simplify the complexity too.
IT Can Learn From Farming
A quick search for the “history of agriculture” on Wikipedia suggests that people have been farming for over 20,000 years. Even city folks who have never stepped foot on a farm clearly know that farming, as a process and as a profession, has evolved a ton in the past few thousand years. Farming is no longer about manual labor. Farming is about science and automation.
Scale is an interesting point. There are big farms, little farms and medium farms. There are big IT shops, little IT shops and medium IT shops. Even with the grand improvements in farming technology, there are differences in scale. I remember my childhood in rural Virginia—we farmed with horses. We did not have a tractor until I was a teenager. In my case, it wasn’t that tractors didn’t exist; rather it was that we had a tiny farm and we really could not justify the expense of a tractor. And, of course, horses were the way my family had done things all along, so it was natural that we continued with horses. However, our neighbor ran a massive-scale dairy farm, and the neighbor had more tractors and automation than we could imagine using. Even today, many readers of this text have a vegetable plant on an apartment balcony during summer months, and those plants are “farmed” manually. One does not need a tractor to raise a single plant. The scale is different. Small and medium sized farming operations have greater needs for automation than I need for my small garden. Tractors, irrigation, etc come into play for small and medium farms. As the scale increases, so does the need for technology and automation. Large farmers constantly push the bar.
The same is true for IT Service Management and scale. The smallest scale is a single user. It seems as though everyone has their own personal IT infrastructure nowadays: home network, broadband, tablet, laptop, mobile phone, wireless hotspot, etc. We act as our own, personal IT staff. We purchase, implement, upgrade, and maintain our devices. We support ourselves which is an extreme micro-scale of IT. As individual users, we usually do not have much use for scripts to upgrade our applications as such an approach would be wasteful just like having a tractor to farm a container garden in my back yard would be wasteful. But as the scale increases with computers and applications and complexity, the need for automation increases. Would we write a script if we had to upgrade 10 computers? 100? 1,000? IT is similar to farming in the scale-based application of automation.
The requirement for humans despite automation is interesting too. Even though farming has evolved, there is still a need for farmers. The technology has not put farmers out of business. However, farmers today have very different skillsets than farmers had 20, 50, 100, or 1000 years ago. Farmers who push themselves to constantly evolve thrive. Thriving farmers look to enable their businesses with the creative use of technology and automation. At scale, farmers who refuse to look for better ways to operate go out of business.
Just like with farming, automation has not and will not displace the IT Pro. In small shops, the IT Pro will continue onward much like today—mostly manual. As the scale increases, so will the business need for automation. The IT Pros must evolve their skillsets, just like the farmer, to stay relevant.
Beyond automation and the associated skillset to deliver automation, just like the farmer, IT Pros must evolve to focus on the business. Focusing on the business is the absolute key, and that involves managing numerous suppliers. Most farmers do not raise their own seeds anymore. Instead, the farmer buys her seeds and other supplies from specialized providers. In IT, the cloud is bringing a lot of change to the IT industry as capacity moves to suppliers whose core competency is providing the utility services. The IT Pro’s role is more about the business rather than on the commodity operation of underlying capacity. Devops is bringing a lot of change to the IT industry too because businesses are rightfully looking to eliminate the repetitive manual effort that introduces error, increases cost, and adds slowness to the business. Just like farmers, if IT Pros want to stay relevant, they need to evolve to focus on the business’ use of technology and automation to achieve business targets. Just as farmers get paid for the outcomes (crops) instead of the effort involved in farming, so must IT Pros begin to focus on the outcomes (sales, cost reduction, etc) rather than on the effort involved in IT Service Delivery.
Ironically, in my experience, the most rewarding days in my life are the days where I have given the greatest effort and where I finish my day physically exhausted. Whether I am physically exhausted from a hard workout or from a hard day’s work in my yard, I feel fulfilled. In the modern world with both farming and IT, that feeling of effort-driven-fulfillment is fine and well, but it does not account for much if the outcome is not there. The most productive dairy farmers never touch a cow; the process is completely automated. The same is the case with IT, the most productive IT Pros never touch a server because they have done the pre-work to automate everything.
Farming Can Learn from IT
In farming, there are countless tactical best practices. For example, common sense would tell a farmer to wait until after the risk of frost to plant the seeds. Thousands of years of iterative experience tells the farmer to break up the earth so the plants’ roots can grow. Generations of data tells us that specific nutrients are important depending on the plant, so the fertilizer chosen should be tailored to the plant; tomatoes prefer a higher soil acidity, for example. In IT, there are also countless best practices. For example, we know that we should distribute user load across multiple frontends for scale and availability. We should take backups of user-authored data. We need to remove standing human access to production systems and data. We need to monitor our services so we have a shot at delighting our users. There are countless best practices in both farming and information technology. Of course, farming has been evolving longer than IT has been evolving. Unfortunately, with IT, we do not have thousands of years to wait for things to level out. We have businesses that require us to push the bar yesterday. And in IT, we do not have the luxury of learning on the job from our wise grandfathers who spent their lives performing the tasks. With farming, I had my grandfather. With IT, each of us has the school of hard knocks to teach us tactical best practices. But is there a better way than the school of hard knocks for IT? And is there a supplement to the wise grandfather for farming? Can we take knowledge from IT and apply it to farming?
When we have countless best practices, we need a framework to deal with the complexity. We need a framework that has documented all of the key learnings throughout the history of IT into one logical sequence, and we need that framework to be documented by a single entity so we can make everything fit together. This framework must give us a place to slot in the countless best practice nuggets so that we can make sense of them all and so we can share them. The framework must stand above the ever-evolving-technology, and the framework must function in spite of, not because of, the ever-evolving-automation. Luckily, in IT, we have many such frameworks and standards.
Automation, of course, does not eliminate the need for best practices. For example, the automated method of plowing a field with a GPS-guided tractor has not eliminated the best practice necessity of actually plowing the field. The automation has made it simpler, less expensive, and less prone to human failure. And in IT for example, automatically removing an unhealthy front-end server does not eliminate the need for the best practice of having multiple front-ends. And if the best practices themselves are still required, so then is the framework that allows us to simplify and make sense of the years of best practice evolution. Just as IT can learn from farmers, farmers can learn from IT Pros and their many frameworks.
Service Strategy is where the discussion begins. The business itself needs a plan, and IT needs a corresponding strategy to facilitate the business plan. The IT Service Strategy should quantify which services will be provided, the cost and pricing of those services, how performance will be measured, etc. Basically, IT needs a high-level plan before we waste time on the specifics. The same is needed for the farm. What size farm do we intend to be in order to deliver to our customers? What crops will we raise? How much of each crop will we raise? What are our revenue, cost, and profit targets? Who are our competitors and what is our position relative to those competitors? What is our niche? What is our overall approach to managing risks? What will we do if we have excess supply? What will we do if we do not have enough supply? How will we stay relevant? Are our customers changing? Are our customers’ needs changing?
As part of Service Strategy, Financial Management and unit-based-cost-accounting are particularly interesting. For IT, unit-based-costing is more important as we move to the cloud and as we put more accountability in the hands of development and automation. People aren’t just running servers anymore and the costs are often shared across business units. DevOps automation is changing the denominators for activity-based-costing too. IT costing is moving more towards cost-per-unit (e.g. cost per mailbox, cost-per-order tax, etc). For farming, the same best practice models apply. Activity-based-costing (e.g. cost of plowing a field) changes drastically with automation and scale while the need for unit-based-costing (e.g. cost per bushel of corn to produce, cost per egg to produce, etc) is ever more prevalent. A farmer could use the IT framework models to help shorten the learning curve in this key area.
Next up is Service Design. Now that we have a Service Strategy, we need to get more specific. From the IT view, the questions are many. What services will we provide exactly? What processes must we have in place? What technology do we need to deliver the services? What specific risks will we manage? How will we measure our success? How will we make sure that our teams have the needed skills? From the farming view, similar questions should be asked. If we are raising corn, what types of corn will we raise? How much of each seed type do we plan to sow? Do we have the equipment, people, skills, real estate, seeds, etc to deliver?
As part of Service Design, we need to manage our catalog. If we do not quantify the services that we will provide and the particulars about our targets and how we will provide them, we are doomed to struggle or fail. Zig Ziglar said “if you aim at nothing, you will hit it every time.” For IT, we need to quantify what we will deliver. We must be deliberate and specific about what we plan to deliver so we can plan how we will deliver it. The same is the case with farming. How crazy would it be to plant corn alongside strawberries? The strawberries would die because they would be shaded from the sun by the much-taller corn.
Another key part of Service Design involves planning for the routine (Availability Management) and non-routine (Service Continuity) failures. For the former, in IT, we must plan to avoid, detect, and recover from routine failures like hard drive and server failures. In farming, we must plan to avoid insect damage through prevention. We must detect insect damage early through great crop monitoring. And we must respond quickly and effectively to insect damage with pesticides when needed. For the latter, in IT, we must plan for the unexpected, worst-case scenario like the extended data center power outage. And our farming friends must plan for the hail storm, the massive drought, the tornado, and so forth as well.
In IT, our frameworks tell us that Availability is made up of two equally important parts: Reliability and Maintainability. Reliability looks at frequency of failure. If the widget never fails, then we meet our availability goals. If the widget does fail, then it matters how often if fails. How often it fails (frequency of failure) is Reliability. This topic is important in IT, but it is also important in farming. What is the germination failure rate of seeds? Which specific goats did not have offspring this year? How often are tractor tires failing across our fleet of tractors?
Just as important as Reliability is Maintainability. Maintainability looks at the speed of recovery when failures do occur. If a tree falls in the woods and no one is there to hear it, does it make a sound? If the widget fails every minute but service restoration is instantaneous thanks to automation and the user never feels adverse impact, does it matter to the end user that the widget failed? If we sow two seeds in every hole and one seed fails while the other germinates, do we still have a plant? If we have invested in dual tractor tires and one tire goes flat, can we still drive the tractor to the barn? The Reliability and Maintainability concepts apply across IT and farming in the same way.
Even though there are more aspects to Service Design, the last topic we will look at here is Supplier Management; I have mentioned this topic briefly already. In IT, the need for Supplier Management is greater than ever thanks to the cloud. Luckily, our IT frameworks give us a great foundation for managing suppliers. In farming, we need to manage our suppliers from tractor fuel to seeds to fertilizer to labor.
Next in line is Service Transition. Service Transition focuses us on the implementation of everything that we have planned in Service Strategy and Service Design. In IT, we need to introduce new services in support of our business. We need to implement new versions of existing services to support new business opportunities and to reduce costs. We need to evolve the Services as we operate them to stay current, to stay secure, and to increase our efficiency. In farming, the same needs are true. We introduce new crops—perhaps we stop growing corn and start growing soybeans because of a change in consumer preferences away from carbs and towards vegan protein sources. We introduce updates to our existing crops—perhaps we start buying and growing organic corn seeds instead of the GMO seeds we used to grow because consumers are paying a premium for organic options. We introduce minor updates to our crops as part of our ongoing operation; for example, we might apply a particular pesticide a second time this year because a surprise rain shower invalidated the previous pesticide application.
Further, as part of Service Transition, we need to keep up with our ongoing, ever-evolving knowledge. Was it Einstein who said that ‘the definition of insanity is doing the same thing over and over again and expecting different results’? Wouldn’t it be a shame not to learn from our mistakes? My grandfather needed to retain knowledge about farming to pass it down to me, but surely there is a better way than just using our memories. One example for IT is that we need to make sure that the Service Desk has the knowledge they need to troubleshoot end user issues when the back-end for an application moves to the cloud. For the farm, we need to capture our learning for how best to harvest the crops because our summer employees at harvest time may have a high turnover rate.
Once the service is in place, we need to operate it. That is where Service Operation comes into play. For IT, we need to take care of the routine tasks of running the service, and we need to respond to incidents and requests. For example, through our Incident Management process, we may respond to a service outage caused by exhausted capacity by adding additional servers. And we may follow up on that outage later via our Problem Management process so we can make sure that we never hit that same scenario again. With farming, we may need to respond to temporary drought conditions by setting up daily irrigation (Incident Management). And we may prepare for the future by updating our procedure for setting up the irrigation (Problem Management).
For this text, the last topic that we will discuss may be the most important. We need to get better every single day through Continuous Improvement. We need to learn from our experiences. Oscar Wilde said “experience is simply the name we give our mistakes.” What good is a mistake if we do not improve by it? Tactically, continuous improvement is as simple as having a rule that we follow that states that we will “never make the same mistake twice”. That rule, of course, implies a lot of activities take place. In the IT frameworks, we define a seven-step process to professionalize Continuous Improvement: define the desired metrics, define the possible metrics, gather the data, process the data, analyze the data, plan based on the data, take action. The same approach to continuous improvement is feasible for IT, farming, and every other industry and walk of life.
There are thousands of pages of IT best practice content, so there is no way to be exhaustive in this text. We all need to know that there is a simple, logical flow to every IT framework with a wealth of underlying content that is not technology-specific. The content applies across different industries—even an industry as different from Information Technology as Farming. No matter the business the reader is in, IT frameworks and the concepts therein will apply. The IT framework content will help the reader make sense of the plethora of tactical best practices they already have, and it will give them a structure in which to file their future learnings. IT frameworks will also give the reader ideas (like looking at reliability and maintainability as two different, equally important things) to help round out their existing approach.
Farming and IT—the line is blending
There is one more topic to consider, and that is how an industry like farming can be impacted directly by IT now given the trans-formative nature of the Cloud and the Internet of Things. If you open your favorite search engine and query for “dairy farm cloud machine learning”, you will see articles about how dairy farmers are putting connected, geo-located pedometers on dairy cows to improve farm efficiency and dairy output volume. They are using machine-learning-detected-patterns in bovine movement to draw insights and to change their processes. It is truly amazing stuff, and of course, that takes us back to the beginning of the IT framework life-cycle for a discussion about Service Strategy—the concepts directly apply. Our world is changing fast thanks to IT, cloud, DevOps, etc and even an ancient industry like farming is being fundamentally changed. No time is better than the present for farmers to start learning and applying the IT frameworks!
Enjoy learning and applying the best practices in IT frameworks. Tell us how it is working for you via our social channels.
