VMware announced its intent to acquire SaltStack, a provider of tools for building intelligent, event-driven automation software.
The DevOps movement is a modern push from the software industry to instill better interaction and productivity between development (Dev) and IT operations (Ops). Instead of throwing applications “over the fence” blindly to operations, a fluid and much more effective DevOps process inserts transparency, efficiency and ownership into the art of developing, releasing and the production use of critical applications. It also binds the two traditionally siloed teams together.
A good football team is built on the symbiosis of both its offense and defense -- defense keeps the other team from scoring, and the offense stays on the field long enough for the defense to catch its breath and also strategize for the next battle. Similarly, a strong IT team can be seen in the same way, Dev and Ops working together, side by side, in one fluid motion assisting each other instead of working as two disparate moving parts.
This, of course, has a positive effect on the bottom line -- better reliability and availability, happier clients, faster time to market, and more time to focus the team's energy on core business rather than wasteful administration and firefighting.
At the heart of DevOps are the applications, as each owns a vital role in how businesses fulfill their requirements. Improving communications and integrating processes between these divided groups is something the entire IT industry should be working towards, as the speed we need to deliver software today is ever increasing and at the same time the tolerance for application errors is decreasing.
The first major barrier that I see organizations often facing when working towards a cooperative DevOps environment stems from the traditional "business versus IT" argument.
While there are still some organizations where business does not get the "business value" of IT, thankfully this is shrinking rapidly. IT is no longer seen as a mystic and arcane practice in the back office.
From an IT perspective, Development is the true driver of new business value, while Operations is the steward of running the business. It’s important for Operations to deliver high availability, while simultaneously making the changes to the production environment that the business requires for agility, revenue and also profit.
At the same time, IT have also had to learn how to express themselves in business terms and think through how requirements are managed in more detail. This trend can naturally make it easier to bridge the gap between IT and the business as they begin to speak the same language.
The second primary barrier to overcome is the hand-offs between different stages of the development and delivery of application releases.
While many businesses have invested in automating their development, few have the ability to actually connect all of the critical components of the application lifecycle and truly bridge the gap between application development and IT operations. Gaining confidence in application delivery requires organizations to marry the creation of better apps with improved processes to put this software into the hands of users.
As teams grow larger or have to deal with larger volumes of software, siloed paper-based practices for the management of each stage of development and operations are evolving to more automated and interconnected processes. The evolution to a more orchestrated approach to application development does not mean throwing out all your existing tools and solutions; instead companies should look to integrate what they already have.
Now that we’ve discussed why DevOps is important to both application performance and overall IT business performance, and we have looked at the barriers IT faces each day, lets dive into the six critical steps IT can take to improve DevOps collaboration and ultimately the business bottom line, profitability.
1. Change your change management
Change management has earned a reputation as being too slow and too difficult, and I agree. Most of the changes tracked by change management tools are caused by developers themselves via sloppy execution. Keeping projects running on-time causes staff to feel the need to circumvent uncomfortable, and time-consuming (but necessary) processes using short cuts.
Change is inevitable so change management should keep up. Changing change management means streamlining processes and automating process execution. Release Management can be inserted as a Change Management “Super Set”. Parallel paths can be created under the banners of standard, routine and emergency to deliver efficiency.
2. Better communication
Businesses need to improve the overall engagement with the developer team by sharing what both sides (dev and ops) do exactly. In a way, un-learn what each side has learned up to this point!
Hold an internal seminar explaining the processes and the best practices each require, and learn how to integrate the two. Develop team-building activities that include everyone and employ a reward system for team collaboration. Make it worth it for both teams to learn to work together. Joint education of both development and operations is key here. Then move directly to get all stakeholders onto a common workflow system to control the release management process.
3. ITIL: Not just for Ops anymore
The word “service” now has many meanings and isn’t designated only for operations-type tasks. Services are relevant to developers as well and that side of the house can benefit by understanding its role in service development and service management.
In order for an organization to embrace the service strategy of ITIL across all facets of DevOps, managers practicing ITIL should teach developers about services and overall service management and what it means to the organization as a whole.
To make the education easier for the development side of the house to understand, it might make sense to translate the “service language” to follow systems development lifecycle (SDLC) terms. SDLC in the software engineering world is a process of creating or altering information systems and the models and methodologies that are used to develop these systems. Use a language that developers understand in order to spread the service gospel so everyone understands their roles in the full application development and management lifecycle.
4. Consider app dev as “service dev”
Remember this motto, “the only thing that matters is the service, not the application.” This means that the entire process, from development to operations and beyond is what is important here.
A well-developed and managed application will perform well within this optimal environment, so it’s a given the application is still king. A well-oiled “service dev” machine will help development implement change and release management consistent with that used on the operations side. Though a key here is to make sure that operations has it right first or your organization could be in a world of hurt.
Be sure to hide the complexity with abstraction, meaning package complexity into simple easily managed services in order to make service delivery easier for DevOps.
5. Take control over the perception of IT service delivery
Another key to successful DevOps is the idea that there is no “us and them”. Just hearing those simple words in team meetings or management discussions hammers home the idea of two separate houses battling for position at the business-level conference table.
Break down the walls between Dev and Ops with the perception that IT as a whole is a “people business”, so focus on the people and the team. Leverage the right people for the right jobs by optimizing skills and employee desire for certain jobs when choosing roles. Present to the business a unified, consistent face of IT as a whole. This can be won through empowerment of all people to collaborate and make decisions without fear.
6. Integrate the ops mission with the overall business mission
Business and IT are compatible, in fact, IT doesn’t align with the business as the saying goes, IT is the business!
Instead of trying to merely align the two together, focus on process innovation, and not simply “doing your job” which will help one earn a seat at the inception table. It is all about business technology and not simply information technology. This realization comes from recognizing it is all about the bottom-line and not necessarily about the technology that helps get you there.
Something to consider is appointing ownership of services and always look for alternative delivery methods, such as strategic right sourcing, automation and cloud computing.
The hand off between Dev and Ops represents a critical gap in the release management process, and it’s a likely point in the process for things to go wrong, especially if the processes are not clearly defined or documented. Putting the right process in place is therefore an essential part of planning application deployment.
There’s no reason for Dev and Ops to not work cohesively together as part of the overall application development lifecycle approach to now only ensure timely and low risk delivery of application changes. This has a tremendous impact on the business. Suddenly the technical team starts trying to pull together as one. An 'all hands on deck' mentality emerges, with all technical people feeling empowered, and capable of helping in all areas.
Having this wider overview of the processes that should be in place can help both sides see that they are being more productive and delivering what the business demands.
About David Hurwitz
As Senior Vice President of Marketing at Serena Software, David Hurwitz leads Serena's marketing initiatives, including product marketing, communications, campaigns, sales readiness and field marketing. Hurwitz has a quarter century of experience in the enterprise software industry, the last decade of which as a marketing leader. Prior to Serena, Hurwitz served as VP of Corporate Messaging and Solutions Marketing at CA, Inc. He joined CA via its 2005 acquisition of Niku Corporation, where he was Chief Marketing Officer. Hurwitz also founded and ran Product Lifecycle Management pioneer ConsenSys Software Corporation. He began his software career by creating several MANMAN products as an engineer at legendary Silicon Valley company ASK Computer Systems. Hurwitz holds a BS in Industrial Engineering from the Rochester Institute of Technology.