devopsy.kinsta.cloud

Category: Enterprise DevOps

Building a Business Case for DevOps
You can get your DevOps vehicle as fast and fine-tuned as you like, but until you provide an effective business case to the board it will remain in the garage. To get the thumbs up, you have to prove your model is efficient and makes financial sense for the company as a whole.

Do You Need to Make a Business Case for DevOps?

Coherent business cases are needed for companies at various different stages of their DevOps journey, not just those at the very beginning. Ask yourself which one of these scenarios best suits your current situation:
1. You/your CIO know(s) the company needs to become more agile, but you don’t know how to quantify the benefits.
2. Your teams have started to implement DevOps practices locally and can see the benefits, but you don’t know how to quantify the success to sell it to management.
3. Your organization sees the success of DevOps pilots, but need to justify the investment to bring DevOps to an enterprise scale.
DevOps can represent a huge shakeup of the IT department that must be justified clearly and logically. The risk must be outweighed by the projected financial gain. Crucially, this needs to be quantified in language that finance department can relate to. It is referred to as the hurdle rate: the necessary annual or total return of a project to compensate for the risk.

What Should the Business Case Contain?
1. Executive briefing
2. Recommendations
3. Required decisions
4. Business drivers
5. Scope
6. Assumptions
7. Analysis
8. NPV (Net Present Value)
9. Strategic options
Hallmarks of a Successful DevOps Business Case

Agility

This is the main benefit of DevOps: the ability to deliver applications faster and allow for frequent changes and adoptions all the way into production. But how do we measure and quantify the benefits of agility?

Time Value of Money

The time value of money expresses the fact that money today is worth more than money tomorrow. The more you have to invest early (instead of over time) and the longer it takes to receive the return, the lower the present value of your investment.

The number you receive when calculating the present value of an investment (benefits minus costs) is called NPV (Net Present Value). It tells you what your future investment is worth today.

With agile and DevOps you are able to develop an application and deliver it to your end user in small chunks rather than in big ones; thus, you will improve the NPV (Net Present Value) of your project even if the total amount of investment and output are the same.

Delivering software continuously rather than yearly creates benefits in the same way as receiving interest on your savings account every day rather than just once a year.

The precise time value of money depends on the average cost of capital a company has to bear. For example, a large, publicly traded company has a lower cost of capital than a small, privately owned one. Your finance department will know it.

Cost of Waste

A second aspect, which speaks for agility in a quantifiable manner, is the reduction of waste.

Functionality delivered using non-agile software engineering practices may be irrelevant or outdated once it reaches the end user because of the time gap and mismatches in requirements and expectations. The cost of such waste can be reduced drastically by using DevOps.

Calculate the benefit of waste reduction using available statistics on the average percentage of functionality used without changes in your applications. It may pay off to assess this number for the last two or three releases delivered.

Take into consideration:
1. Total cost of development and delivery of these releases.
2. Relative efforts of different functionalities delivered by release.
3. Cost of change requests that arrived during and after the release date.
4. End-user survey on the need and usability of these functionalities.
Combine the benefit of waste reduction and of frequent delivery and add them as positive future cash flows to your calculation.

You also need to calculate the forecasted costs of your DevOps initiative. Consider:
1. Investment in build, test, deploy and provisioning and related operating expenses.
2. Investment in IT infrastructure.
3. Investment to complement skills in development and operations teams.
4. Investment in organizational changes.
5. Operating expenses for all above.
6. Extra cost of non-automated activities in test, release and deploy due to increased release velocity.
As part of your strategic options in the business case, balance your investments in automation with investments in more resources for build, test and deploy for given agility scenarios. The higher the release velocity, the more build, test and deploy activities are required. The more automation, the less of these activities must be done manually. Visualize in diagrams how the investment in more automation starts to pay off with increasing release velocity.

Finally, sum up positive and negative cash flows and use your company’s hurdle rate to calculate your NPV.

About the Author/Michael Schmidt

Michael Schmidt heads DevOps Practice at Automic, a management and technology advisory service established to help Automic customers to prepare for and transform their organizations toward DevOps. Michael spent his carrier as consultant, entrepreneur and in several product-related leadership positions. He has a passion for building lean IT organizations. Michael holds a joint MBA from New York University, London School of Economics and HEC Paris and a Master of Computing Science.
March 11, 2016
Gartner Evaluates APM Tools for DevOps

In 2009, Gartner analyst Mark Nicolett created the Critical Capabilities report. Over time, this document became paired to individual Magic Quadrant reports, and in 2014, Gartner mandated that Critical Capabilities be paired with each Magic Quadrant. Instead of graphically plotting vendors on a x- and y-axis, this research takes a deeper look at a product and its fit for specific use cases.

So how does this pertain to DevOps?

In its latest “Critical Capabilities of Application Performance Monitoring” research, Gartner notes, “Because of its wide lifecycle purview, the DevOps release team often leverages many of the capabilities found in APM suites.” Since the foundation of DevOps is to foster collaboration among the two, typically disparate teams, modern application performance monitoring (APM) solutions are geared perfectly to help encourage this feedback loop. “When examining the capabilities valued by this buyer, APM tooling is critical when attempting to quickly assess the quality (and effectiveness) of a recent release. Detecting and diagnosing issues must be done quickly, which often requires in-depth data sourced from multiple, integrated tools,” according to Gartner.

“Much of the activity of APM technology is focused on detecting and providing insight into root causes. Identification of the impact on system and application resources is based on existing (or proposed) transaction-level trends,” the report continues. “This capability provides IT operations and DevOps release teams with the ability to tell the (line of business) and application owners the potential impact for any planned changes or continuation of resource consumption trends. Although capacity-planning tools have often filled this role, APM suites increasingly offer predictive analytics capabilities for shorter-term horizons”

Of course, we can’t ignore the key to DevOps success: culture. However, no tool—no matter how good—can foster the right type of culture. John Rakowski, my current colleague and ex-Forrester analyst, wrote a compelling ebook on the intangibles that successful DevOps teams need.

The Critical Capabilities research report provides a comprehensive and technical product analysis ranking APM suites from 15 vendors on critical APM capabilities across five different usage scenarios, including DevOps. The capabilities assessed for each use case included business analysis, service monitoring, anomaly detection, distributed profiling, application debugging and workload planning.

The vendors evaluated were AppDynamics, AppNeta, BMC Software, CA Technologies, Dell, Dynatrace, Hewlett Packard Enterprise, IBM, JenniferSoft, ManageEngine, Microsoft, Nastel Technologies, New Relic, Riverbed Technology and Tinygun.

The report is free of charge and can be downloaded here.

March 10, 2016
Embracing DevOps in the IoT Era
To those of us struggling to cope with the challenges of delivering software over the Internet of Things (IoT), DevOps can be the savior.

Delivering software over the Internet is no easy task, and delivering it over the Internet of Things is even more formidable. How do you deliver software to so many “things,” many of which are “loners” unconnected to the rest of the world?

What’s encouraging is that the software management processes and tools that we know and have learned to love still work in the IoT era. In fact, not only do they work, they are essential.

We need teams to work together more smoothly and communicate more quickly to mitigate the higher technological risks. DevOps processes and tools, therefore, are critical in the IoT era because they facilitate smooth, well-oiled collaboration between teams.

A Typical IoT Scenario

Consider a scenario in which you need to develop a “smart” parking system for a “smart” city. The system will involve multiple sensors in the parking lots, a display device in each parking area along with communication equipment, a central server for control and analysis and a smart device in each car.

Drivers can check how many slots are available in nearby parking lots on their automobile devices and navigate to the appropriate parking lot. They also can book slots in advance and start paying from the time they book the slot. When they leave a slot, the parking slot sensor automatically detects that the slot is free and updates a central server. The central server transmits slot availability to the car-based devices, where they become visible to drivers. The central server also generates various kinds of reports and performs various kinds of high-end analysis.

As with any conventional Internet system, there are multiple software components. All of them have their respective delivery (development, testing and deployment) streams. These streams need to work interdependently and collaboratively, and they need centralized configuration management and dashboards.

The Scale and Diversity of IoT

The differences and challenge, however, lie in the sheer scale of deployment, the diversity of deployment environments and the multiple deployment channels. As you can imagine, any large city will have millions of cars, thousands of parking lots and, hence, hundreds of thousands of individual slots. The number of deployment devices easily can run into the millions.

In the interest of preventing monopolies, not all the parking sensors will be from one manufacturer. The same holds for the car-based devices. While certain standards can be enforced, not all manufacturers will adhere to one universal protocol. It will be necessary to allow multiple communication and security protocols on these devices. This multiplicity of protocols can complicate software deployment on the devices.

Other Considerations

What makes the entire deployment process even more complex is the fact that most of the deployment will be done over the air (OTA). Given that OTA deployment is susceptible to radio-frequency interference and other transmission issues, the deployment process must allow for more robustness than conventional wired deployments.

There are even more factors to consider: A city-based system can be extremely dynamic. New cars get registered every day, adding to the traffic. New parking lots may be built every now and then and get integrated into the smart city system. New kinds of chips from new sensor manufacturers could be added, as mentioned earlier, to increase competition. New, more sophisticated car-based devices coming into the market might offer to host the smart parking software. Of course, as in conventional systems, new functionality and patch fixes would be released frequently. Finally, as the system becomes part of city life, its utility as an analytical tool could increase beyond analyzing parking trends to other spheres of activity.

These business and technological factors can exert tremendous evolutionary pressures on the system. A smart system in a smart evolving city must evolve, too. Yet, no change anywhere in the system must be allowed to break the system anywhere else. The chances of this happening are higher in an IoT system because interconnection protocols have not matured enough to become universal and because physical device conditions can never be predicted perfectly. For instance, a single extra field required by the central big data server could place an unsustainable additional burden on the fragile radio-frequency system in the parking lot and bring down the entire data transmission.

How DevOps Can Help

To offset the increase in technological and business risk in the IoT, we need robust processes and tools that mitigate the additional risk by improving communication and collaboration between teams. Tools that have the following features become indispensable:
- A centralized dashboard providing a cross-stream view of the software development;
- The ability to trace linkages between all related software artifacts across streams and lifecycle stages, given the stressful nature of interdependencies between streams; and
- A tool that can detect broken linkages.
The tools also need a well-oiled DevOps management culture that encourages close collaboration and rapid communication between development and operations.

IoT heightens the need for close collaboration between multiple software streams and within streams between development and operations. Adopting a DevOps culture and DevOps enabling tools is the way to offset the risks of software delivery in the Internet of Things.

About the Author / Vidhya V. Kumar

Vidhya is an advisory software engineer at IBM. An evangelist and practitioner of agile methodologies, continuous delivery and documentation, she has about 10 years of experience in the IT industry. She is a subject matter expert in DevOps, application lifecycle management and search methodologies.
March 9, 2016
Taking Stock of DevOps: Where to from Here?

Have you noticed how every technology trend goes through a series of stages on the path to mainstream adoption? First comes doubt and denial, then tacit acceptance and finally acknowledgement that it works fine after all. The DevOps movement is no different.

First came questions about what DevOps actually is and its usefulness in an enterprise context (whatever an enterprise actually means these days), then a trickle of success stories and finally the publication of tangible and quantifiable benefits.

Thankfully, we’ve moved on from the “Is it a bird or is it a plane?” stage. Of course, that doesn’t stop hype, but at least the publication of benefits—such as those recently illustrated in the global study, “Assembling the DevOps jigsaw“—allow us to cut through all the “DevOps solves global warming”-type of nonsense being written.

So with the value jury finally in, the next question we should be asking about DevOps is, Where to from here? Interestingly, the old Wikipedia entry for DevOps provides some guidance, stating that DevOps is:

… a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.

That’s pretty good, because it emphasizes the importance of collaboration across all IT functions (not just Dev and Ops). However, this still doesn’t quite cut it for me. Although lots of cultural and automation heavy lifting has been done to bridge Dev and Ops, more work is needed to understand how aligning other IT functions to DevOps actually benefits the function itself and the business. Also—and perhaps just as important—how aligning other business functions, such as HR and finance, can lead to more success.

DevOps Works Because It’s Good for Business

Business leaders talk in terms such as faster lead times, customer conversions and time-to-value, which (putting cultural discussion aside) is really the essence of DevOps. And because DevOps adoption directly correlates to making a buck, it has a fair chance of garnering attention and investment from the business.

That said then, information security and other professionals would do well to hitch their wagon to DevOps. One of the beauties of the movement is that teams collaborate and provide input much earlier in the development life cycle, with processes then automated to ensure faster release time and quality. By also involving security earlier, businesses could feasibly harden security, balancing all those “rain on your parade” audits and checklists with automated methods that ensure compliant configurations lead to faster deployments.

An interesting but important benefit is how this approach helps align IT security to business outcomes. Rather than proving its worth through a whole raft of technical sounding measures, such as penetration test scores, patched vulnerabilities or security incidents detected, security can report functional value in context of business goals, such as how automated compliance equals faster releases, leading to increased revenue.

Of course, DevOps doesn’t just involve Dev, Ops and security, it also will involve other functions providing valuable input to help increase speed and quality. Think of it like the old “Stone Soup” story but without the trickery—everyone, be they software designers, product managers and enterprise architects, providing advice and expertise earlier in the software life cycle so essential elements of resilience, supportability and scale are baked in right from the get-go.

DevOps Shouldn’t Start and End in IT

The DevOps way suggests that we shouldn’t just restrict ourselves to IT functions—start there, yes, but other facets of the business should also participate. This sounds like common sense, but in reality it’s more critical because the boundaries between business and digital have blurred significantly. Fail to recognize this and we could end up a silo of good intentions: culturally correct but lacking any teeth.

This explains why even the much-maligned HR function has a DevOps role to play. For too long, many HR departments have been fundamentally back-office, dipping their toes in the muddy waters of organizational culture with periodic staff surveys and performance appraisals. But this doesn’t go far enough. Now, HR leaders must step out onto software factory floor and work hand-in-step with other DevOps practitioners to identify all the organizational and psychological barriers that inhibit business growth and the development of talent.

Finance, too, must become aligned to DevOps. This involves moving beyond traditional IT cost-center thinking to developing new fluid funding models needed to stimulate software innovation by agile teams. This means business change agents must join forces with DevOps practitioners to look at better ways to capitalize or expense software development costs or optimally monetize new apps, APIs and information assets. Once again, the earlier this happens in the software life cycle, the better.

From an IT perspective, we’ve come a long way with DevOps in a relatively short amount of time. But this is only the start of the journey. Most businesses haven’t even considered transformation of the whole organization using DevOps principles as a change agent. Those that do most likely will gain first-mover advantage—and that’s a good place to be in an economy increasingly shaped by application software.

March 9, 2016
Measuring the Cost of Service Creation & Adoption

Adopting and implementing DevOps isn’t an overnight project. It takes time and effort to determine how it best fits into your organization—and what benefits your organization will realize as a result.

Creating an enterprise-class DevOps service is typically done in one of three ways, depending on the organization, its leadership and its employees. Each has its pros and cons, and each has a number of factors to consider.

A Fully Centralized Model

In this model, tooling decisions are done in a central service provider group for the entire organization. Tools are managed centrally and standards are created centrally. DevOps automation creation (at least the templates or frameworks) is done centrally. This model is highly advantageous for organizations with a wide variety of technology platforms (think large population of legacy apps) and use many technology components for their apps, such as multiple types of databases, middleware and operating platforms, for example.

Not many large organizations are ready to scrap what they have in the application portfolio and start over using the cloud and containers and develop in a singular methodology. Using a centralized model, companies can continue to improve upon their years of investment in legacy applications and adopt a DevOps continuum without starting over from scratch.

This also is the lowest-cost model, as tooling is standardized and administered from a central point and licensing can be negotiated to maximum effect. In addition, labor (generally the highest ongoing cost of any service creation and implementation) is minimized by centralizing it. Training costs also can be minimized by establishing a centralized training program for all impacted audiences. Companies can change their incentive programs to achieve hiring objectives and business results as priorities change—something that isn’t practical in a decentralized or federated model.

A Fully Decentralized Model

In a fully decentralized model, tooling decisions are determined and managed by each development team. This has the advantage for shops with small numbers of applications or singular methods of development—fewer applications are better candidates for starting over with cloud or container integrations and can take advantage of the newest technologies from the starting point, if needed.

Shops such as Etsy or Facebook seem massive, but from a user point of view, they really only present a single application that needs to be maintained and improved over time. Instances like this may favor a decentralized model because the actual number of application candidates may be highly limited—sometimes only one.

This model typically represents the highest costs, as repeatability and standardization can only be measured at the development team level. As such, this is practical for a very limited number of applications, or technologies; if those numbers grow, the strategy quickly becomes untenable. In addition, this strategy has an uncanny history of pulling development resources to do the DevOps automation engineering that needs to be created and maintained. Typically, the highest skilled developers are assigned these types of duties, and thinking in terms of templates and frameworks is rarely their first approach. Developers tend to be expedient, and believe they will always be there to make sure it works. This also can reduce the potential for repeatability and predictability (raising costs).

A Federated Model

In a federated model, tooling decisions and standards are done centrally, but management and operations of the tools are performed by a limited number of subservient organizations (often by line of business). Centralized templates may or may not be viable depending on the variability of the business units they serve. The chief advantage of this approach is the segregation of tooling and reporting by business unit (typically) without having to build that kind of segregation in to tools that were not designed that capability in mind.

This model also has the advantage of increasing the speed of adoption, as several parallel efforts can take place at the same time and spreading engineer resource demand across multiple organizations. It typically makes the most sense in larger organizations with multiple business units whose application portfolios that would benefit from an onboarding to DevOps.

What’s more, a federated model may be the most cost-efficient. Labor costs will be inherently higher as functions are replicated from business unit to business unit; however, that replication will result in increased adoption rates and project completions (you get what you pay for). If business units are able to leverage centralized templates for each technology type, adoption rates become an order of magnitude faster (or have that potential). Tooling costs still can be negotiated centrally, even though management will occur in the business units. Again, there is hardware replication from business unit to business unit, but the ability to segregate users, permissions and operations down to the business-unit level can save tremendous labor costs if development was the only other option to create that capability in tools not designed for it.

Adoption Costs

Measuring the cost of adoption requires focus, no matter which method you employ to create the DevOps service. Applications moving to DevOps are said to be onboarded (where the original build, deploy, test and release automation is created). To successfully onboard an application requires education of the sponsoring executives, training of the impacted developers and testers, and coordination with the change and release managers.

Collection of meta data about the behavior of application components is no small task, requiring frequent follow-ups and action items to reach completion. The effort to onboard applications to DevOps becomes the first cost for estimation and tracking as the application portfolio is attacked.

Even after onboarding of a given application is complete, costs continue. The terms “continuous delivery” and “continuous integration” should also infer that application development methods “continuously” evolve and may adopt new technology components. Significant changes may occur that require revisiting the DevOps automation to adapt to these ongoing revisions and updates.

While this work is rarely as extensive as the initial onboarding, it is measurable. Work of this nature is usually referred to as BAU (business as usual) and represents the second significant cost of DevOps services that must be measured and tracked. If no thought is given to this work effort, inevitably the team assigned to do onboarding will be distracted by the BAU requirements until they reach the point where no new applications can be completed.

Staffing cost estimations can be presented at the component level for both onboarding and BAU efforts. For example, if one DevOps engineer can onboard 20 components per week (assuming familiar technologies within a given portfolio), and if the general ratio of components per application is 4:1, then a given DevOps engineer can successfully onboard five applications per week. If the engineer is never distracted with BAU, this can continue until the entire portfolio is onboarded. However, my experience has shown that for every 20 applications completed with onboarding, the BAU work effort can absorb nearly a full DevOps engineer. So if you start with a team of 10 people, you will onboard only 200 applications total before the entire team is required to focus on BAU work effort and has no more bandwidth to continue onboarding new apps. Understanding this demand, and learning how efficient your particular engineering team is, will be key to managing costs while completing the onboarding efforts of large application portfolios.

March 8, 2016
Software Complexity Driving DevOps Automation

The drivers behind increasing software complexity also are the drivers behind expansive DevOps automation. As the saying goes, “Software is eating the world.” DevOps is gobbling up software, too, engulfing it in practices that are necessary to make it thrive under the pressure of the current environment.

That environment and those drivers are of keen interest to many. DevOps authority Andy Vitus, partner at Scale Venture Partners, has identified four drivers in particular that are creating the software complexity pushing DevOps automation.

Multiple Distributed Software Locations

According to Vitus, by moving software from one server to multiserver to multiple data center deployments, the industry has made software more elaborate. Applications now execute in a distributed manner and in parallel using multithreading inside multiple processor cores; among many servers running multicore processors; and in and between geographically dispersed data centers. This makes software more powerful and reliable, though it demands more DevOps automation to produce it.

Simply incorporating the ability for software to run in parallel using multithreading adds intricacies to the development process. To keep both the workload and the number of man hours needed during development manageable, automate as much of the additional coding duties and testing as possible.

“Running applications across servers and data centers requires that you ensure consistency in the data layer,” which will then need new databases to handle the load, says Vitus. Depending on the database, the developer must rewrite the software to be able to use it.

The entanglements don’t end there.

With mobile applications, mobile devices and back-end servers both store data. “You have to be a lot more careful about knowing what version of the data is the true one, unless you’ve got a synchronization layer built in,” says Vitus. Either way, programming annoyances can be introduced.

Getting Lost in Translation

Expanding development from a single programming language to multiple languages, even for the same project, has made software more convoluted. In legacy development shops, programmers typically used one language for everything regardless of whether it was the best language for their creations. These days teams are applying choice languages such as C++, Python and Go to the tasks to which they are best-suited. “This increases the complexity of security and patch management as you use six, seven or eight different languages all with their own vulnerabilities,” says Vitus.

While adopting several languages certainly adds to patch management and security headaches, understanding how each language can and must be compatible with the others for them to work together is an entirely new challenge. “The ways that they handle variables and time stamps changes over time, and you have to ensure that different services can still talk to each other,” says Vitus.

Stacks of Stacks

Moving from a simple three-tier stack to a distributed microservices architecture catches software development in another snag, Vitus says. The database layer has grown to include in-memory and other database types. As development breaks the application layer into microservices, each potentially with its own data store, the two layers combine to create this new stack.

Millions of Endpoints

Finally, moving from deploying servers to deploying servers, mobile and Internet of Things (IoT) takes software down new paths of mostly uncharted territory, says Vitus. “Today you deploy software changes to a back-end server that must talk to a mobile client using iOS or Android or to IoT devices such as dishwashers and light bulbs in smart homes,” he says. “You could be deploying code to millions of devices.” This certainly affects the construction of the code for use on so many different platforms.

Conclusion

These drivers help create a magnified need for DevOps automation. Considering the costs of hiring engineers and technicians to do the same development work manually, the world will be watching companies that are pushing for increased automation to displace those labor costs. “To the extent that you can offload some of that to regression tests, you end up saving, and the cost of building a new software product goes down,” says Vitus.

March 7, 2016
DevOps and the Near-Decapitation of Variability

Not all automation scales. One of the chief impediments of delivering an enterprise-class DevOps service is the decentralization of tooling choices—or worse, the methodologies within the tool for delivering CI/CD. If the methods used to deliver automation are as varied as the last engineer who created them, the spaghetti that ensues will not scale much farther than previous methods did.

The trick to scalability is not so much tooling-dependent as it is approach-dependent. Templates or frameworks (or any word you would use) to describe a relatively preformatted approach to automating a particular kind of technology component are the key to achieving scale.

Ideally, your highest-skilled engineers create the basic template or framework that other, lesser-skilled engineers will use to create the actual automation for each system as they move forward. Using a single way to automate a particular kind of technology enables you to manage large numbers of systems utilizing that technology from a single point of administration. For example, a standardized template used to create the automation to deploy a MySQL-type database could be altered over time to include new testing requirements detected from results found later in the QA process.

Once the new testing is incorporated into the standardized template, the resulting automation is fixed once for every instance of that kind of database in every system that uses it. Otherwise, you’ll need to remember to update every script for every instance of a system that uses this kind of database. Those updates likely will be implemented differently across the applications by different engineers, which may negatively impact testing results (thus defeating the purpose of testing consistency, and actually generating more unnecessary work to locate the variations).

Templates or frameworks (or pick the synonym that suits you) can reduce variability in “how” the automation continuously delivers and integrates. Once variability is killed (or nearly killed), predictability can emerge. Predictability throughout the entire SDLC lowers overall costs, as finding and fixing bugs becomes more systemic. What’s more, there are fewer bugs, thanks to battle-tested processes that produce consistent behavior. If the tooling is sophisticated enough to offer visibility, the costs of quality are reduced even further, and the speed to deliver is radically increased.

DevOps promises that combination of reduced failure rates with increased speed of delivery. However, embracing unstructured variability in creating the automation can kill it. The Ops side of the DevOps equation is all about doing things systemically and predictably, as that is the only way to maintain stability while changes whiz through their world. Getting Ops to buy into DevOps is much easier when they have complete visibility into a predictable, repeatable, process for delivering change. Avoiding that 3 a.m. phone call is something everyone has in common, and reducing variability by focusing automation through the lens of templating or frameworks is an excellent way to achieve it.

March 4, 2016
Embracing a DevOps Culture, Part 1

DevOps is popular right now. So it should come as no surprise that organizations across all industries are eager to embrace the “DevOps culture.” However, unlike ITIL, implementing DevOps into an organization does not happen overnight.

Compared to companies such as Netflix or Amazon, most organizations do not have thousands of application deployments per day. In fact, it’s usually newer companies that are able to fully embrace DevOps, since all of their business operations rely on IT already.

DevOps Philosophy > Procedure

There are many articles out there that try to define DevOps, but DevOps is more of a philosophy than a procedure. If you polled 100 organizations on their experiences implementing a DevOps strategy within their existing business processes, you’d likely get 100 different answers.

An organization’s journey toward DevOps is usually unique, since there are so many different factors that influence a DevOps integration. These include the size and age of the company, what industry it’s in (banking/finance, retail, health care, e-commerce, education, public services), how sophisticated its technology is, the nature of its IT (data center or SaaS), organizational structure (siloed or integrated), development methodology (agile or waterfall), the nature of its mission-critical applications (Web 2.0, virtualized, client-server … ) and more. For most companies that exist outside of the startup ecosystem and rely on Web 2.0 and agile application development, Dev and Ops just don’t get along.

Dev vs. Ops

Trying to collaborate with Dev and Ops can feel like trying to mix oil and vinegar if the goals of each department are not aligned. As a result, IT’s ability to deliver maximum business value is greatly reduced. To efficiently drive the business forward, Dev and Ops must get along.

Most often, the conflict between Dev and Ops is because the focus of one department is at odds with the focus of the other, which creates tension when it comes time to collaborate with one another. While Development is focused on continuously delivering new products and/or features to meet business needs, IT Operations strives to preserve the availability and the stability of IT services and the IT cost-efficiency.

DevOps Can’t Be Limited by Tools

First, for a seamless collaboration to occur between Dev and Ops, both departments must use compatible tools. Mismatched toolsets create bottlenecks, misunderstanding and miscommunications, which result in so much wasted time that the implementation process ends up hurting the business.

Next, processes must align; compatible toolsets with conflicting processes are useless. For example, it’s not unusual to find the service desk is using a ticketing system which is separate from the application development tools used to manage product defects and enhancements.

Developers tend to rely on toolsets that are optimized for rapid development to provide fast feedback on code changes, to automate build creation and for application release deployments. In addition, the Dev team may be unaware of the runtime environment, which makes it difficult to adjust the code accordingly, whereas Operations uses solutions on the target runtime environment, where stability and performance outstrip flexibility requirements.

Since the integration process is unique to each organization, it’s key to find tools that are the right fit for your new processes and employees. Just because a team uses the latest application release automation tools to consistently drive repeatable deployments of application into production, does not mean they have adopted DevOps.

In fact, version control, application release automation and application auto-discovery of business transactions are all tools that help developers meet their objectives, but may not address the other portion of the equation: Operations.

At the end of the day, one of the most important decisions is choosing the right leadership team across your business—from your C-level executive team to the heads of your Dev and Ops teams. The integration process for DevOps can be difficult; to merge two separate departments and processes together to drive collaboration, both the Dev and Ops team need leaders with clear vision of the bigger picture and what’s needed from everyone to drive the company’s forward.

About the Author/Vincent Geffray

Vincent Geffray is Senior Director of Product Marketing at Everbridge with focus on IT Service Alerting & Communications Automation and IoT.

He has more than 14 years of experience in the information technology business, designing, promoting and selling Enterprise IT Operations Management solutions, including Critical Communications, Application Performance Management, IT Process and Workload Automation. He also has international experience, as he started his career in Europe. Vincent holds a Master of Science (Mechanical Engineering and Computer Science) and executive certificates from the MIT – Sloan School of Management.

Vincent’s LinkedIn: www.linkedin.com/in/vgeffray

Vincent’s Twitter: @vgeffray

February 29, 2016
An Engineering Think Tank to Change the World

In his famous book “Mythical Man Month,” Fred Brooks says, “Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.”

While being very fond of engineering on the big scale, such as building millions of high-end and yet individually configured cars or double-deck aircraft or space ships, for example, I have always asked myself, why the most promising industry—software engineering—is so often not capable of doing engineering on that scale, too? Or, why are so many big enterprise IT projects painful in so many ways?

With these questions that nobody seemed to be really interested in on my mind, one day I met some higher corporate management, who wondered why the IT department would be so reluctant to follow their lean transformation advice and instead talked about some agile and continuous integration thingy.

From that moment, I understood that everything necessary to radically upgrade software engineering was already there! The biggest problem was that we do not communicate enough—and furthermore, there is no holistic view on the complete IT value chain.

By that I mean we need to create awareness for the value chain, starting with digitized formal models of business processes and written business requirements.

That was how the following chart came to existence, and I still love it. Apparently, most awesome things happen on the borders of separated knowledge domains; you need just to talk to colleagues from departments you’d never talk to! What if we would mix knowledge from big industry, best available process improvement and quality assurance methodology, and apply all this to how we design, build and deliver software?

At first I thought I had found a new perspective on DevOps, but now I believe there could be more to it. Well, now the door to the radical innovation is open! Just imagine: What if we would apply the Internet of Things approach to our industry? Maybe we could close the loop of process improvement in software development and test, moving it to real time and running optimization not by ambiguous frameworks but by hard facts coming from virtual sensors, with unprecedented levels of transparency?

This was how a couple of friends and I came to the idea of our foundation we call SIGSPL (Special Interest Group for Software Production Lines). This public organization is a non-profit think tank, built around three generic domains—Labor Automation, Analysis and Advanced Visualization—which we consider to be the three pillars of the upcoming convergent software engineering in the post DevOps era.

We are sure this sort of thing inevitably will happen, but our mission is to catalyze these processes to make radical innovation happen intentionally and faster, so we all can build information technology that rocks!

We are a small team of six with some infrastructure, publications at our blog and a well-established yet growing knowledge base. We would like to reach out to more like-minded people to let this idea grow and change the world. Our plan is to foster further exchange and discussions between DevOps experts and other specialists “unexpected” in this context, such as production lines and supply chain management experts, Six Sigma Black Belts, 3D artists, hackers, venture capitalists and many, many others.

Our proof that we are not ponding to nowhere is our magic triangle diagram, showing some well-known tools we map to the three generic domains, which are also of high interest for venture capital. Our question to the world is, What would appear in the middle of this triangle in, say, five years?

About the Author/Peter Muryshkin

Peter studied M.Sc. in Applied Computer Science and works in management consulting roles focusing on complex analysis and customer satisfaction, including IT Business Analyst and Change Manager. His current scientific research focus is digital transformation applied to the field of software engineering in large distributed organizations.

LinkedIn: https://de.linkedin.com/in/muryshkin
Team blog: http://sigspl.org/blog/

February 25, 2016
Designing A DevOps Strategy: A Balanced Scorecard Framework
Despite all the hype about DevOps, little has been written on a formal DevOps strategy. Too often DevOps initiatives starts with tooling discussion and gets stalled in technology. The larger vision is rarely discussed. The goal of this article is to provide enterprises, large and small, with a framework for creating that vision and unlocking the promise of DevOps.

Elements of a DevOps Strategy

A holistic DevOps strategy, at the most basic level, must answer the following questions:
- Where should we focus our efforts? Where do we begin?
- What are we trying to solve?
- What is our goal? How are we going to solve it? How long will it take?
- How is this going to impact the larger enterprise? Who are our stakeholders and what do they value?
- Is this worth doing it? What are the benefits and costs?
If implemented correctly a good strategy provides an organization with focus, creates a common (unbiased) view of the current problems, develops the future state, unveils opportunities for growth and results in better business outputs.

DevOps Strategy Map: A Balanced Scorecard Framework

A Balanced Scorecard typically consists of four high-level perspectives that highlight key practices and objectives that are needed to build a strategy. We choose this framework primarily because it does three things really well. First, it provides a disciplined approach towards creating a strategy. Second, it links the key activities together and describes the cause and effect between them. And third (and most important), its easy to use and follow.

A scorecard is usually read from the bottom up. Enclosed below is a Balanced Scorecard modified for DevOps.

DevOps Strategy Map

1. People, Process & Technology

In DevOps we have the luxury of plenty: an abundance of applications, technologies, competing initiatives, bottlenecks, nebulous problems, tools, etc. The objective of this dimension is to narrow down the application options (system of record vs. system of engagement) and target the problems that really matter (value stream mapping exercise). By doing so, we bring clarity and focus to the organization and greatly improve the chances of success.

2. Critical Capabilities

The next step consists of three activities – create a vision (which includes a future state value stream), determine where to invest, and build an implementation plan. Three things to keep in mind as you go about doing this exercise. First, pick hard targets for your vision. Instead of “improve speed” try to get to “improve speed by 25 percent”. Second, pay particular attention to capabilities gaps. Gaps can then be used to determine areas of investment, approximate budget, and a key input into your ROI model. Third, make sure to prioritize the bottlenecks. Putting the priority list on a timeline can be quickly translated into an implementation plan.

3. Perception by Key Stakeholders

Identifying your key stakeholders, determining their priorities, and aligning your strategy accordingly is the next crucial step. Some of the key stakeholders to consider are business/end customer, CIO and the IT leadership, development, operations and security. Once identified, match the value drivers from the vision to each stakeholder. This along with the output from the previous section will highlight pitfalls of your future state solution, its feasibility, and political objections.

4. Value to the Organization

The financial benefits section serves as the keystone for the balanced scorecard. By using output from the previous sections the business case brings the entire strategy together. As for the benefits themselves, they come in both hard and soft forms. The most common benefits we see are listed in the chart above. To get to ROI, combine the hard benefits with the investments from the previous section.

One Last Thing

The strategy map is meant to be iterative—the great thing about a DevOps solution is that it is not a “one size fits all” approach. Play around with all of the above steps. Move things around, change scope, update solutions and redefine vision until you come up with an objective that is both transformative and achievable for your organization.

DevOps is a journey that’s two steps forward and one step back. Good luck!!

Special thanks to Sunil Joshi and Emily Pence for helping create the Strategy Map. To find out more on how to use this map, joins us at IBM Interconnect.

About The Author/Mustafa Kapadia

Mustafa Kapadia is the Service Line Leader for IBM’s DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery. He has over 17+ years of experience in the tech. space, both as a service provider and a management consultant.

Prior to joining IBM, Mustafa was a management consultant with Deloitte’s Strategy & Operations practice. He lives in San Francisco Bay Area, is an avid blogger (when time permitting), a speaker, and adviser to start ups.

Connect with Mustafa LinkedIn | Twitter
February 18, 2016