kran77 - Fotolia

Problem solve Get help with specific problems with your technologies, process and projects.

It's time to embrace 'you build it, you run it'

If you want to release better software faster, change your org chart, flatten your teams and think about the customer first. Robert Reeves outlines a new way to think of DevOps.

In the early 2000s, Jeff Bezos mandated that all applications at Amazon offer web services for other apps to access data and functionality. Prior to this, Amazon struggled with a ponderous, unwieldy suite of applications. Downtime was an issue, and Bezos had had enough.

Instead of tossing software over the wall, teams had to create the functionality and make sure it worked in production. We've shortened that to "you build it, you run it."

Amazon's results -- the company was able to rapidly scale applications to support growth and "accidentally" built Amazon Web Services -- explains why it's no surprise other companies want to duplicate its success.

But it's hard. You may have to dramatically change your org chart and delay customer-requested functionality. A lot of your employees who don't get on board may need to leave. That's scary, but it's worth it if your employees can deliver improvements faster than ever.

Change your org chart

The first step to achieve "you build it, you run it" cloud applications is to create cross-functional product teams. Dev, test, operations, system administrators and database admins no longer run their own show. You will have product teams that encompass those roles and skill sets.

One of the bigger frustrations with application release is the wait for external teams to complete tasks. Cross-functional teams eliminate this bottleneck. For example, instead of a long wait for an external data services team to review a SQL script for execution, the product team now has the skills and green light to review and execute the SQL script themselves.

And that's a good thing. The research team behind the State of DevOps report found companies with zero review prior to application pushes and companies that had external teams to review change had the same IT performance. That's right -- there is no difference between how your company's IT organization performs if you have external reviews. The one type of review that predicted software delivery performance was peer review of changes. So, if you have a peer-review process, then you will have better software delivery performance.

That's very scary for the teams that perform those reviews. However, if those reviews are moved into the product team, the company will have better software delivery. Thus, the team members currently performing reviews must work more closely with the product teams and become members of those product teams.

Do not delay customer functionality

We have all seen companies focus on internal infrastructure at the expense of customer functionality. A classic example of how IT decisions can wreck a company is Zynga. During the explosive growth of Farmville on Facebook, Zynga left AWS and created its own cloud. During this period, the company not only failed -- and returned to AWS -- but it also missed out on the explosion of mobile gaming.

The move to a product-team-oriented organization is not the same as building your own cloud infrastructure from scratch. First, it's proven that product teams that use web services for cloud applications are successful. Contrast that to Zynga, which worked on how it hosted its software instead of the software itself. Second, product teams accelerate the rate of innovation in your company. A "you build it, you run it" focus on customer demands instead of internal demands will mean your team delivers better customer functionality faster.

In the end, focus on what you are good at: building your application.

Of course, you can test this "you build it, you run it" concept yourself. Find a new bit of functionality you want to add to your monolithic application and build it separately, so a web service exposes the data and functionality. Then, have the monolithic application call the interface to use the functionality. Finally, improve it. Measure how long it takes at each step, and you will prove you can deliver customer functionality faster.

In the end, focus on what you are good at: building your application. There are plenty of really good cloud computing options out there to house your app. Don't make the mistake of trying to build one yourself. If you do, quality 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. And change we must. The question is not how to change, but how to convince your team they want to change. And 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.

Organizations need a change catalyst. Leaders should identify teams that adapt to this new way to build and deliver applications and reward them immediately and loudly. As people see the rewards, the laggards will begin to change.

That is not sustainable for the long term, though. Employees need to see they are able to perform their jobs better and faster. That's self-actualization, which is a far more efficient reward system. As employees see their projects released faster and the hassle factor of release lessens, they will wholeheartedly adopt a "you build it, you run it" mandate.

Dig Deeper on Building a DevOps culture

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

How does your organization incentivize change?