DevOps: Smashing through software development silos

• Industry has been discussing the need to break down the walls between development and operations
• Thus the DevOps movement was born, and a new business beckons

“EVERY business today is a software business,” says Kamal Dutta (pic), vice-president of business units for HP Software in Asia Pacific and Japan. “Or at least, they all should start seeing themselves this way.”

Applications are no longer about software development houses churning out code for others to use. “Think about the disruption LinkedIn has caused in the recruitment industry – you cannot meet an HR (human resources) guy today who doesn’t use LinkedIn.”

The biggest bookseller in the world is a software company, Amazon. Buying music on iTunes, the legitimate disruptor and successor to Napster, is a purely software experience.

“Think about this – it’s been reported that 15% of the cost of a luxury car is software; and there are six million lines of code in an airline reservation system,” he adds.

The business world runs on software. It has been identified as one of the top 10 industry hazards in all industries. Software is blamed for more business disasters than any other man-made product, says Kamal.

Yet, the way software development is structured in most organizations is dysfunctional and perhaps nothing short of disastrous.

There are two teams, each with its own set of incentives and motivations. There are the developers, who are all about speed and cool, innovative applications; and then there are the operations guys, who are all about stability and business requirements. They seemingly work at odds with each other.

There are walls between them, and these walls must be brought down if businesses are to survive and thrive in today’s fast-moving world.

“In a survey, we asked organizations how long it takes them to change one line of code,” says Kamal. “34% said about two weeks; 39% said more than a day – just to change one line of code.”

Something’s gotta give.

Required: Agility and speed

Industry has been aware of this dysfunction in software development. Over the past three years, there have been lots of discussions over the internal conflict in how the process is structured in most organizations.

These discussions began with system administrators in Europe, crossed the pond into the United States, the term DevOps (development/ operations) was coined and popularized through a series of "DevOps Days" starting in 2009 in Belgium, and quickly spreadi8ng to other geographies, including Asia.

A movement was born. A new business beckons. (See accompanying article, New HP software plugs the dev-ops gap).

As with the cloud a few years ago, each participant brings his own understanding to the table, each technology vendor has his take on it. HP defines DevOps as “a strategy and a set of principles for better collaboration between application developers, testers and the infrastructure and operations teams.”

In Kamal’s own take, DevOps is absolutely essential given the changes taking place in the business world, and how technology, specifically software, is being harnessed. Not only do businesses have to build software, how they do so has to change significantly. They need to develop ‘composite’ applications.

“Take the banking industry for example. It used to be silos of applications – retail banking, core banking, Internet banking, check-clearance applications, anti- money laundering applications, home loan applications, and so on.

“Today, the primary interface for banking is the Internet. I can order a check, see my credit profile, apply for a home loan or insurance, or check my account statements. All the teller duties have been moved to the Internet, but more than that, I can move across the bank’s portfolios of services, be it credit cards, or investment or retail banking,” he adds.

On the backend, it means all these various applications have to connect and be completely integrated with each other. And be completely transparent to the customer.

The second big reality is the much-talked and –bandied about Web 2.0.

“Web 1.0 was about static pages, Web 2.0 is about interaction. As you start interacting with the bank’s applications, the backend has undergone significant change to serve up composite applications -- which produces its own set of challenges,” says Kamal.

Among the changes, when you now test one application, you have to test all the other applications connected to it. You can’t shut down your Internet banking application just to test the latest version, because it affects and is affected by all the other applications.

Then are the multiple platforms that you have to support -- multiple operating systems and form factors as people bring in their tablets and smartphones into the equation. There is also the challenge of ‘reach.’

“Today, when you build an application, you have to build in linkages to YouTube or Twitter, for example,” says Kamal.

In HP’s estimate, today there are over four billion cellphones in use, of which 450 million offer a full Web experience. These devices can consume over 10 billion mobile apps today and it will only get harder, with 21.6 billion apps expected to be in use by 2013 accessed by over two trillion, interconnected and embedded devices by 2020.

Yet another challenge is that you don’t know what the infrastructure is going to be – whether the application will reside on the cloud or on a traditional data center.

You just have to prepare an application to be able to reside on a multitude of platforms, according to Kamal. In some ways, somewhere down the road, the infrastructure is going to be transparent.

The third big change: The merging of traditional and new web apps.

“Take your typical manufacturing company, for example. Their ERP (enterprise resource planning), inventory management and HR (human resource) systems have been integrated, but what we’re seeing now is that their website has to be integrated too,” he says. “So too their dealer management system, CRM (customer relationship management), order-entry system and even point-of-sales.”

The dealers of a tyre-manufacturing company may need to access inventory information online. Customers may want to order the new tyres via their smartphones.

Live testing, dev-on-the-go

“All these interconnected and interworking parts must be speedily developed and brought to market. You need business agility,” says Kamal.

In the old paradigm, a software developer sitting at his desk only needed to shout over his cubicle walls to get at his project manager to find out about business requirements. The software architect sat at a desk across his. The programmers were scattered all over the floor. You needed to know something, you just walked over to them.

“Today, it’s an absolutely distributed environment,” says Kamal. “The project manager may be sitting in the United States, the programmer in India, the business development guy in Malaysia.”

“We used to have self-contained applications -- you developed something for a particular function on a particular platform,” he adds. “Today, you are not going to develop a different application for a different platform. Reusability of code and reusability of services are important.”

Kamal, who before he fell into sales, was a developer himself – having launched into the industry with a computer engineering degree, says, “Previously, I would develop an application and release it in a batch – almost like batch processing. Today we’re talking about constant re-use.”

Application development used to be sequential too: “You get the business requirements frozen, develop the code, test the code, test the code again, test the environment, roll it out into production. No longer – these days I develop part of it, test it, update it, redevelop it, use it, correct it, rewrite it, and test it again.”

Previously, software development was all about stability, these days it’s all about speed.

“But the problem is that speed is not enough,” says Kamal. ”Even if you develop applications much more quickly, they still have to roll out safely.”

“The problem is that we have two different types of people, with different kinds of incentives – one for speed, the other for stability.”

Thus the DevOps movement, and HP’s new software portfolio.

“We want to take a leadership position here. Our new products not only embrace the industry’s definition of DevOps, they help businesses adopt these sets of practices,” says Kamal.

Next: HP’s new software portfolio