In the early 2000s Jeff Bezos mandated that all applications at Amazon offer web services that other applications could use to access data and functionality. At the time, Amazon was struggling with a ponderous, unwieldy group of applications. Downtime was an issue, and Bezos had had enough.
Instead of just chucking software over the wall separating one team from the next, teams responsible for creating functionality also had to make certain it worked in production. The new mantra: “You build it, you run it.”
Amazon not only rapidly scaled its applications to support growth, it accidentally built Amazon Web Services (AWS) along the way. It’s no surprise that other companies want to duplicate its success.
But it’s hard. You will dramatically change your org chart, run the risk of delaying functionality that customers are demanding, and say goodbye to many employees who don’t get onboard. The reward is clear, however: Your team will be able to deliver improvements faster than ever.
Here's how to embrace "you build it, you run it" in your organization.
'Who moved my cheese?': Changing your org chart
The first step in building cloud applications is creating cross-functional product teams. No longer do you have dev, test, ops, system administrators, and DBAs. You have product teams that encompass those roles and skills.
One of the most frustrating aspects of application release is waiting on external teams to complete tasks that are blocking you. Cross-functional teams eliminate this bottleneck. For example, instead of waiting days or weeks for an external data services team to review an SQL script for execution, the product team can review and execute the SQL script themselves. Goodbye, waiting.
That’s a good thing. The research team behind the State of DevOps report found that companies with zero review prior to application pushes had the same IT performance as companies that had external teams reviewing change. That’s right: External reviews make no difference. The one type of review that did predict software delivery performance was peer review of changes. Thus, if you have a peer-review process, you will have better software-delivery performance.
That’s scary for the teams that perform those reviews. But if you move those reviews into the product team, your company will have better software delivery. Thus, the team members currently performing reviews must work closer with the product teams and become members of those product teams.
Don't delay customer functionality
We have all seen companies that focus on internal infrastructure at the expense of customer functionality. Zynga was a classic example of how IT decisions can wreck a company. During the explosive growth of its Farmville app on Facebook, it decided to leave AWS and create its own cloud. Not only did it fail, eventually returning to AWS, but it missed out on the explosion in mobile gaming.
Moving to a product-team-oriented organization is not the same as building your own cloud infrastructure from scratch. First, it’s proven that using web services for cloud applications works. Contrast that to Zynga, which worked on how it hosted its software instead of on the software itself. Second, product teams accelerate the rate of innovation in a company. A focus on customer demand over internal demands results in better customer functionality that's delivered faster.
You can test this yourself. Find a new bit of functionality you want to add to your monolithic application and build it separately, exposing data and functionality via a web service. Then have your monolithic application call the interface to use the functionality. Finally, improve it.
By measuring how each step takes, you'll prove to others that you can deliver customer functionality faster. In the end, focus on what you are good at: building your application. There are plenty of good cloud computing options out there to house your app. Don’t make the mistake of trying to build one yourself. If you do, functionality will surely be delayed, your customers will not be happy, and your top line will suffer greatly.
Change is scary
The only way to see long-lasting, impactful change in an organization is to make change appealing. But change you must. The question is not how to change, but how to convince your team that it wants to change. The answer is simple: Reward those who engage and drive change. Those who fight change or sit on the sidelines will ultimately see the results and choose appropriately.
To succeed, you needed a change catalyst. So identify teams that are adapting to this new way of building and delivering applications and reward them immediately and loudly. As people see the rewards, the laggards will follow.
However, tha's not sustainable over the long term. Employees need to see that they can perform their jobs better and faster. That’s self-actualization, which is a far more efficient reward system. As employees see that their own projects get released faster and with less hassle, they will whole-heartedly adopt the “You build it, you run it” mandate.
Amazon shifted to a “You build it, you run it” philosophy in the early 2,000s. Since then, it has struggled internally with changing its org chart, addressing unfounded fears of delaying customer functionality, and convincing employees to embrace the change. But as with Amazon, once you are able to manage these issues effectively, your move to cloud applications will be far easier, and much more rewarding.
Keep learning
Choose the right ESM tool for your needs. Get up to speed with the our Buyer's Guide to Enterprise Service Management Tools
What will the next generation of enterprise service management tools look like? TechBeacon's Guide to Optimizing Enterprise Service Management offers the insights.
Discover more about IT Operations Monitoring with TechBeacon's Guide.
What's the best way to get your robotic process automation project off the ground? Find out how to choose the right tools—and the right project.
Ready to advance up the IT career ladder? TechBeacon's Careers Topic Center provides expert advice you need to prepare for your next move.
