staging-devopsy.kinsta.cloud

Tag: DevOps strategy

  • Transforming Your Digital Transformation

    Transforming Your Digital Transformation

    Change is difficult, so most companies pull the bandage slowly, hoping to avoid the hard, painful part – especially with regard to digital transformation. But in the corporate world, cautious change inevitably leads to entropy. Progress gets made in one department at a time, at the expense of others. Leaders turn over, priorities shift, plans fall apart and the desired results never happen. The bandage never really comes off.

    I see this happen a lot in companies that say they want to transform their digital customer experience – across all industries we work with. The board or the shareholders might not embrace a truly digital-first strategy or understand what the end-state transformation goal actually is. Instead, they end up digitizing the past, refreshening a longstanding brand with a new storefront in a doomed effort to maintain business-as-usual.

    These companies start with a well-meaning internal innovation team. They preach agility, then spend months researching the problem and consulting internal stakeholders, all the while trying to stay close to their comfort zone of existing practices. They write reports, they create roadmaps, run design-thinking workshops and come up with a solution … and then throw it over the wall to IT and wash their hands of it. Nine months later, the team is busy executing the new plan, but, with no internal champion, it can’t innovate. Due to the chaos and complexity of the project, the company burns through its budget and the project becomes a sad statistic. In fact, 95% of corporate digital transformations fail outright or produce diluted results, according to one recent study.

    Shrink the Transformation Timeline

    If a company really does want to digitize for the future instead of the past, it needs to turn that approach on its head. It needs to drastically shrink the timeline for digital transformation, which means starting with a digital operating model and putting the end clearly in sight.

    The result is a digital operating model that continuously delivers and measures value. It’s not a project. It’s not a product. It’s an operating model that puts teams close to the market and customer, and makes them responsible for finding and delivering innovative, high-value customer experiences.

    Get the Team Right

    This approach requires a team that knows how to embrace ambiguity and takes responsibility for creating the solution, not just designing it or building it – both of which fail when done in a silo.

    It needs to be a small, multifunctional team with the authority to implement things quickly, with the fewest possible hoops to jump through along the way. And when the inevitable organizational friction arises, the team and its goal needs to be seen as a transformation opportunity, not a barrier to be avoided.

    Companies assume they can do this work in-house, but it’s next to impossible to form the right internal teams because, typically, they don’t have enough experience with this model.

    These internal teams don’t quite have the right training for the job, but more importantly, they don’t have the right permission and agency. Some are risk-averse or can’t break through organizational silos. Some simply aren’t given the agency to do the work. Organizations with a lot of experience evolving, that give their employees this agency as a matter of course, might have success in-house. But it’s a tough ask for older, established firms.

    Don’t Design – Execute

    To their credit, many companies see this and outsource their transformation leadership to a consultancy firm. But you can’t outsource a transformation. You can’t teach a transformation. You need to implement transformation.

    Both internally and externally led transformations fail to grasp what really makes transformation work: agency and delivery.

    Instead of researching, planning and announcing, the team needs to roll up their sleeves and start executing. They have to drive the evolution of the company’s software toward the identified goals, break down any organizational silos or challenges that get in the way and deliver – quickly. They have to work together with the IT team, and anyone else who needs to understand what they’re doing, but execution needs to be top of mind at all times.

    The solution isn’t insourcing or outsourcing. It’s a joint venture, where the transformation is within the company’s core business unit, working together with a consultancy or partner to complete the digital transformation faster by focusing on a smaller slice of the business. With this foundation, an organization can be pulled through a rapid transformation in nine to 18 months, rather than three to five years.

    In fact, in under six months, a tiny transformation team of five to seven people can scale up to a transformed organization of 120 people, quickly delivering the desired digital-first customer experience. All it takes is a team that has done it successfully, multiple times. And the best thing about this is that transformation is measurable by the ability of teams to continuously deliver and evolve experiences across multiple digital channels.

    Digital moves too fast, and is too complicated, to be managed by traditional processes and approvals. If it does, whatever change your company sets out to enact is at risk of being dead on arrival. Agency plus delivery is the formula for a successful digital transformation.

  • How Managed Detection and Response (MDR) Solutions Benefit DevOps

    How Managed Detection and Response (MDR) Solutions Benefit DevOps

    Managed Detection and Response (MDR), a relative newcomer in the cybersecurity realm, is starting to have a noticeable impact on enterprises seeking to better secure their operations. Research giant Gartner notes that, “By 2025, 50% of organizations will be using MDR services for threat monitoring, detection and response functions that offer threat containment capabilities.” Despite rising adoption rates, though, much confusion remains about MDR and how it should fit into enterprise IT.

    MDR is typically defined as an outsourced security service that enables organizations to better detect malicious activity over the network. MDR is usually sold as a service, and vendors offer tools and technologies that integrate into a business’s IT to detect and mitigate network intrusions, malware attacks, attempted data theft and other malicious threats. MDR can be a powerful ally in the quest to contain cyberattacks, but only if deployed correctly and leveraged properly.

    Enterprise Benefits

    MDR offers obvious benefits for enterprises, but there’s enormous potential when MDR is integrated with DevOps. Many organizations are turning to DevSecOps methodologies to build cybersecurity into their development and deployment pipelines, and MDR can help.

    “One challenge is that DevSecOps is a term that is poorly defined in most cases, and misunderstood in many others,” said Dave Martin, senior director, product management – threat response at Open Systems. “Some people think of DevSecOps as an extension of a quality assurance department, which means that cybersecurity is mostly an afterthought, and not part of the development cycle. MDR, at least how we do it at Open Systems, brings forth a full-time security operations layer, which includes a security analyst, that can become part of the DevOps team,” Martin said. 

    Martin makes an interesting point. As more organizations attempt to implement DevSecOps, knowledge, along with action, are lacking. MDR has the potential to supplement knowledge and insight into the security posture of the code being generated. Many organizations leave cybersecurity to the network or operations teams, expecting endpoint or network security tools alone to contain threats. However, many threats in the wild may leverage older code, or target unpatched applications. MDR can enable DevOps teams to get ahead of the latest threats by keeping developers informed about evolving threats and vulnerabilities, as well as incorporating tools for continuous cybersecurity into the development and deployment pipelines. One of the core concepts of MDR is providing access to experts that can take action to mitigate an attack. This is an important consideration, according to the Enterprise Strategy Group, which reports that 51% of survey respondents face a problematic shortage of skills in the area of cybersecurity.

    What’s more, MDR becomes a tool to secure the DevOps environment, as well as a tool for developers to make code more secure. “It is critical to find advanced threats, ones that may have bypassed existing security controls, before those threats impact DevOps, yet people need to be made aware of those threats so they are not mistakenly included in the development pipeline,” said Martin.

    Choosing an MDR Provider

    With so many players in the MDR space, choosing a provider that fits into a DevOps and enterprise strategy can be daunting. According to Reports and Data, the global MDR market is expected to grow at a CAGR of 30.4% until it reaches $4.6 billion by 2026. Today, providers number in the dozens, and while many claim they have “complete” offerings, they may not consider the needs of DevSecOps along with traditional network operations concerns.

    There are some important considerations when choosing an MDR platform. For example, visibility of the attack surface is a critical concern. If an MDR provider does not have visibility into all potential attack surfaces, breaches and compromises may still occur. Also, adopters should be keenly aware of how false positives are contained, as well as the level of alert activity. Many cybersecurity solutions can introduce alert fatigue and obscure effectiveness. Automation should be a key part of any MDR solution, as it can help to categorize threats, initiate responses and identify the latest threat trends without human interaction. 

    “MDR should tear down many of the cybersecurity silos that businesses have today, and bring the various pieces of IT together into a unified cybersecurity sensitive culture,” said Martin.

    Ultimately, MDR is about people, processes and technology, and should bring these elements together to ensure success in the ongoing battle against cybercriminals. 

  • Strategy vs. Tactics

    Strategy vs. Tactics

  • Don’t Let ‘Hindsight 2020’ Be Your DevOps Strategy

    Don’t Let ‘Hindsight 2020’ Be Your DevOps Strategy

    The idea of DevOps originated a little over a decade ago with a desire to ensure efficiency in the overall software development and delivery process. Constant operational hurdles that have been hampering flawless and frequent delivery of applications have led organizations to think beyond and to come up with continuous improvements in their processes and tooling. Thus, DevOps has evolved into a solid practice to aid enterprises with an end-to-end feedback enabled framework that spans across various functions and stakeholders to design, develop and deliver quality software.

    The IT landscape over the last few years has changed significantly. Companies are building secure applications and large volumes of workloads are being transformed to the public cloud. Nowadays, firms are actively applying AI technologies to transform their businesses more than they were just a few years ago. Some companies are still investing heavily on building their own complex AI platforms involving expensive infrastructure, but most companies have realized the value in leveraging AI as a service offered by leading cloud providers.

    Digital initiatives and IoT have further increased the use of cloud-based services and the need for automated deployment and delivery of applications and services. Seamless integration of the CI/CD pipeline for on-premise or deployment to the cloud is possible only with a solid DevOps practice. For organizations that are ambitious and striving to get ahead of the game in order to accelerate the growth of their businesses, DevOps is indispensable.

    To successfully implement some of the current major trends in IT, organizations are required to have a mature DevOps practice in place.  In October 2019, Gartner published its predictions on technology trends for 2020. We’ll pick a few from those to discuss the crucial role that DevOps is expected to play in them, and the critical success factors for companies to be advanced forward.  

    Strategic Trends in IT and the Role of DevOps

    Hyperautomation

    Gartner’s analysis on strategic technology trends for 2020 has hyperautomation as the number one trend. Hyperautomation, which enables organizations to function as autonomous digital enterprises, will be leveraging latest technologies such as 5G networks, intelligent edge devices, advanced data analytics, expanding RPA with AI, etc. Firms aspiring to implement AI and ML on a grand scale will want to take advantage of the diverse range of complex machine learning algorithms implemented on scalable cloud infrastructure and offered as services.

    Instead of recreating everything from scratch, organizations will simply upload their data to the cloud and train algorithms based on their business processes and needs. For hyperautomation initiatives to be successful, organizations need to implement end-to-end fully automated DevOps processes with the relevant tooling to specifically address the varied needs from several perspectives. Speed, agility and ensuring an error-free repeatable process will be basic requirements for hyperautomation.

    On-demand deployment of transient infrastructure on the cloud, driven by infrastructure as code and configuration as code will be a primary requirement for rapid development and testing of artifacts that form components of hyperautomation. Fully automated pipelines for the creation and deployment of containers will become a core requirement not only for hyperautomation but in general for most applications. The involvement of DevOps to manage data virtualization, obfuscation and uploading data to the cloud will become more significant to increase the overall efficiency of the automated CI/CD pipelines for hyperautomation projects. 

    Democratization of IT

    Democratization of technology is about making technology more accessible to common people. Gartner has predicted this to be another major trend for 2020. Smartphones and the internet have already played a major role on this front and have enabled people with the technology, tools and data to help make better decisions. Democratization of technology in the IT world is about enabling the IT community and it gets more and more interesting day by day.

    With container technologies such as Docker Desktop that can run on a user’s laptop, a developer now has access to pre-configured container images of various operating systems and other platforms that can be pulled from container registries within seconds. Cloud services such as IaaS, SaaS and PaaS add to this by providing more independence to the development teams apart from making the entire process agile and faster. Democratization at these levels also leads to setting a different level of expectations on the overall velocity of development and delivery of applications. All these services in isolation, i.e. when not connected together through a strong DevOps process and toolset, will not produce the expected level of agility and speed.

    An end-to-end DevOps process works all the way: from triggering the build of a container image as the code is built, deploying an environment on the cloud, integrating with other components, testing artifacts with automated testing and finally to producing a production-worthy artifact. When IT teams get more democratic, they will run their domain the way they perceive beneficial and produce the best possible outcome with quality and speed to make their teams and the organization successful. DevOps will be the means to achieving that goal.

    Internet of Things

    Edge devices are getting smarter by the day. Mass manufacturing of intelligent controller boards, such as the ESP 8266 and ESP 32, is making it extremely cheap to build edge devices with data storage and processing capabilities locally within the device itself instead of communicating with a cloud based central system for command and control. However, such intelligent devices need to be kept up-to-date on security patches, bug-fixes, firmware updates, etc. A solid DevOps framework that integrates testing of patches/fixes, and deploys tested artifacts to remote edge devices is an absolutely essential component of an organization’s IoT ecosystem.

    Some controller boards run light-weight versions of Linux and have the capability to additionally run a Docker engine. This helps ensure consistency through deployment of updated containers via a DevOps pipeline to the edge devices. Convergence of cloud and digital transformation initiatives, especially in IoT over the last few years, has widened the scope of DevOps. Major cloud providers are already offering several services to integrate edge devices with a full-fledged CI/CD pipeline leveraging DevOps processes and tools. 

    Blockchain

    Application developers and IT managers spend a great deal of time either fixing bugs or recovering systems from breakdowns caused by bugs. If best practices, processes and tools are put to proper use, this wasted effort can be greatly reduced and the entire development and delivery process could be made more efficient. Blockchain demands building a strong foundation in IT and raises the need for higher quality in software development, delivery and IT operations on the whole.

    Organizations have to take a closer look at their current capabilities and process maturity before embarking on a journey involving blockchain. Firms that have faced failures with blockchain can certainly vouch for the fact that the failure wasn’t caused by the concept of blockchain or the algorithms that drive it. Rather they had resulted because the rest of the IT systems weren’t reliable enough to keep up with the strict demands of the blockchain systems. DevOps and automation will certainly help improve the security, quality, reliability and repeatable deployment of applications. When the systems that feed the blockchain application go through such increments of improvement, the net effect is that the organization is getting closer to implementing a solid blockchain solution.

    Success Factors

    Firms are moving fast toward the cloud for IaaS and PaaS services. As DevOps, CloudOps and SecOps are converging, CIOs are becoming conscious about building organizations that encapsulate these functions under one leadership in order to set shared goals and ensure synergies across these functions. Organizations with strict compliance requirements and governance would need to involve their operations teams to lay the rules regarding using cloud services.

    Application development teams and users are still dependent on several operations teams to design and implement secure cloud connectivity and to establish the rules around using cloud services. While a strong governance is absolutely essential, there is a high possibility for firms to lose their agility and get caught once again in a mess if these operational processes are not smoothen and streamlined. For the strategic initiatives on implementing the new trends to succeed, it is vital for DevOps to be able to operate without any hurdles.

    Below are a few critical success factors worth considering.

    Dev and Ops in a Box

    Organizational structure plays a key role in determining the success of DevOps. Keeping applications development, DevOps and infrastructure operations very closely aligned with overlapping goals, KPIs and roadmaps is a key to success. Companies that operate these functions independently without proper alignment fail to establish an organization-wide DevOps culture and rarely reap the full benefits of DevOps.

    Full-Stack Engineers for DevOps

    It is important to develop a DevOps culture across the company. At the same time, it is equally important to bring in experts who can evangelize DevOps and take a completely fresh look at how things are done. Experienced DevOps professionals can pin-point areas for improvement, and additionally help accelerate the adoption rate of DevOps. Settling for high-quality resources that have full-stack experience is absolutely essential if you are in for a long run with DevOps. Global companies should seriously consider placing such experienced resources close to the development and operations teams. While it may be cost-effective to recruit resources offshore, that may not be such a good idea if your active development and infrastructure teams are onshore. 

    Trained Internal Resources

    Training internal resources are extremely important in order to carry out the recommendations from experts and to make DevOps a habit. Trained resources have to be deployed immediately to work on DevOps initiatives alongside the experts. To establish synergy and increase collaboration, it is a good idea to send development and operations resources to some common training courses and sessions.

    Wrapping Things Up

    Research organizations are closely observing the direction in which most organizations are moving toward in order to improve their speed, efficiency, agility and their overall ability to provide services that are secure and reliable. Business strategy and technology feed each other and as a result, some key trends in technology emerge from time to time.

    We looked at some of the trends that are going to be prominent in 2020 and the role that DevOps would have in implementing these technologies. Regardless of any specific technology, it is important to automate the integration and delivery of applications. DevOps processes and tooling will help a great deal in accelerating the pace of implementing new technologies and leveraging them in business applications.

    The organization of IT teams and a focus on recruiting the right talents will determine the overall success of DevOps. Training internal staff would help sustain the culture of DevOps in companies and fuel further growth in this space. DevOps will not be an optional function any more. It will be an essential component of the culture, and firms that adapt themselves sooner to this culture will be the ones most successful in implementing the current and future trends in technology.

    — Sridhar Asvathanarayanan

  • Untapping the Potential of DevOps, Part 4: Tips for Launching a DevOps Team

    Untapping the Potential of DevOps, Part 4: Tips for Launching a DevOps Team

    DevOps has become a hot strategy for IT teams across just about every industry—and for good reason. DevOps is built around increasing the velocity of the development pipeline, and in businesses where time to market is a key to success, it’s easy to imagine why DevOps has gained traction. While the tools and processes put in place are certainly essential, building the right team—from top to bottom—is maybe the most important factor for getting the most out of a DevOps strategy.

    To help get the most out of DevOps initiatives—and to set teams up for long-term, sustained success—here are some basic tips for creating the team that will take development pipelines to new heights.

    Change Is Coming

    When kicking off a DevOps strategy, it’s clear that changes will be made. But, the extent of those changes may be underestimated. To get the most out of DevOps, it’s not just about changing up the tool stack or switching up meeting styles. The mindset around DevOps is at least as important as the processes. To squeeze the most juice out of a DevOps initiative, make sure the company and leadership understand what all DevOps entails and create the understanding that it requires a lot of internal changes to the existing culture. Getting leadership on board with the cultural changes that come with DevOps will go a long way toward driving success.

    Talent Talks

    This may go without saying, but it is imperative to build a team with the right skills for the task at hand. It can be easy to try to shoehorn people into roles, especially when trying to move quickly. But make sure to set individual talent up for success—both employees and the company will benefit. This means having DevOps engineers and leadership with the skills—whether they are technical, interpersonal or something else—to perform the work required.

    Get Your Budget Right

    DevOps helps create efficiencies. Leveraging automation, maximizing value delivery and getting products to market faster are all key tenets of a good DevOps strategy. But that doesn’t mean you should skimp on the important items. Like any project worth doing, it’s a lot easier (and more successful) when it is budgeted properly.

    Make sure to have an adequate budget to create a team, perform the work and support the appropriate environments and infrastructure to perform the DevOps tasks and initiatives that need to be done. Doing this in advance will save a lot of headaches down the line and help develop a clear understanding of what is really needed to get from point A to point B—and help keep spending in line while the DevOps train is moving.

    It’s Not Just About IT

    Remember there are two parts to DevOps—dev and ops. It is often easier to get the developer side to buy into the strategy—after all, many of the tenets of DevOps speak to the technical teams. But overall buy-in is necessary for cooperation and involvement of all teams needed to achieve goals. That means development and operations—plus other departments within the organization, such as sales, marketing, the executive team, etc. Getting everyone on board with the process and rowing in the same direction will fundamentally change the mindset around how to design and deliver products. When the whole team is moving in lockstep, that’s when success can really be visualized.

    By keeping the thoughts above in mind when planning a DevOps journey, organizations can help ensure teams are organized and set up for long-term success. But remember, every organization is different and has different requirements. What may work for one organization may not for the next.

    When considering the potential of DevOps for your organization, it can be tempting to dive right in and skip some important considerations for setting up the initiative. But the key points listed above are tried-and-true and carry weight, no matter the size or scope of business. Having a leader who acts as a champion for DevOps efforts is essential, so IT professionals tasked with leading the organization into the DevOps transformation should arm themselves with these tips to be better positioned for success.

    — Jonathan Fries

  • The Nirvana of Gated Progression

    The Nirvana of Gated Progression

    A highly functioning enterprise-class DevOps set of services has a fundamental goal of full automation. To be honest, having the right DevOps strategist (or visionary) leading this effort is as important to achieving this goal as the combination of all the challenges and topics that must be addressed. So for the sake of argument, will we assume you have one (if not, feel free to contact me—I am looking at the moment 🙂 ).

    With key leadership in place, the first target is always the automation of the build and deploy process. This could easily be considered the core of DevOps or its heart. But once this automation has been achieved, the trickier topic of release orchestration begins to emerge. Strategy is to release orchestration what taste is to food: Having the right one does make all the difference.

    To progress our code to production, the inherent assumption is that all testing has been completed successfully. Sounds like common sense. But then, how much of that testing occurs with human hands on it? The user acceptance testing (UAT) discipline inherently requires a human at the wheel. But the reality is, for every time a human must interact with the progression of code from the development-class environment through all the testing environments (integration, performance, user acceptance and QA) on its way to production, the momentum of innovation is slowed down—all the way down to human levels.

    The Complexity of Testing Types

    The first automated testing begins to occur in development or (DEV) class environments, where the programmer is under strict instructions to implement test-driven development. This requires new feature/functional testing as part of the build or deployment automation into DEV. Either the build or the deployment cannot be said to be successful “if” the accompanying tests are not “passed.” This also represents our first “gate.” Sophisticated release orchestration (RO) software can examine “flags” set during the build or deployment process to see if the testing has been completed successfully. If so, the code can progress to the next testing level environment within the software development life cycle (SDLC).

    Another useful type of testing completed early in the SDLC (most often in DEV) is the examination of code coverage. Development organizations can begin to examine how much of their code is put to the test, and set arbitrary percentages as a minimum standard before the target application is able to progress. The addition of alternate types of testing occurring in DEV class environments does add to the quality of the innovation effort. However, it brings with it an increased labor effort to automate both progression—and audit—of the version under test.

    For instance, feature/function testing may use a single repository to store the results for a given version of the code. I go to my testing repository and I can look up the results from version 1.4 of my application, or version 1.5 of my app, as many as I desire. Should a regulatory official or internal auditor ever ask me to prove the quality of version 1.5 of my app, I need only consult my testing repository and show them how many tests were executed, and how many passed or failed before this version of my app was ever deployed into production.

    When you add code coverage testing to the process, I now need to consult two different testing repositories, producing two separate reports to assess the quality of this same version of my app. There is nothing wrong with this, but it does create more work or effort to produce than it would if a single testing repository was used. The problem only increases as we keep increasing the types of tools we use to prove quality. Security testing, for example, (ensuring code does not have inherent security holes) tends to use different tools, or, worse, processes that require human peer observation, which again can add effort to create the automation and the traceability for audit. These are critical types of testing (and/or processes) so they must be done, but they also come with an inherent cost in automation effort.

    Small shops may not worry about these kinds of concerns, but large organizations will, particularly if they are still in the process of transitioning from legacy waterfall methods (where controls were high) to new agile methods (where it feels to auditors like the wild, wild west). Compiling a test log that matches the version of code under scrutiny such that it can be reproduced automatically will restore the faith of both internal auditors and regulatory officials who come asking. But the addition of each new type of testing tool will require more effort to maintain the ability to compile those test logs.

    The Complexity of Testing Responses

    Next, consider the impact of non-binary responses to automation efforts for gated code progression. Does my feature work (yes/no)? This is a binary evaluation, a true/false or yes/no that is easy to set my progression flag for testing response. It is another matter to evaluate the results of my code coverage and ensure this app is above 70 percent or between 70 percent and 90 percent. These kinds of questions are not binary (in other words, there is a real result to compare to, not just a pass/fail), and require further effort to set a binary flag for the gated pass/fail. When the evaluation question does not intend a binary answer at all, such as a grading of 1 to 5 where 1 equals horrible and 5 equals outstanding, I am now most often forcing a human to make an intelligent decision as to whether this code should progress.

    Multiple testing repositories require additional automation effort. Multiple kinds of responses require additional automation effort, and the standards by which the gates pass or fail also may change over time, requiring tracking of the goals at the time the tests were taken. Creating independent test automation that can be called from the build process or the deployment process is wise. Associating this test automation (whether scripts or simulations, etc.) with the version of the application code is wise. And working to reduce the number of repositories to examine is wise. Having de-coupled test automation strictly from a build allows it to be re-executed in more advanced testing environments when the need arises.

    Charting the Course to Nirvana

    RO benefits from as full a level of automation as possible. I will discuss the RO topic more fully in another article, but the foundation of automated change progression relies on a gated history of proving quality. As long as the code under review continues to pass testing, setting progression flags to green or yes or pass, the RO software can continue to progress it along its way to production. Failing code must be sent back to the DEV environments where development teams can address the issues before making its way back through the automated process once again from beginning to end.

    If the organization has made the intentional decision to keep humans substantially involved in the testing and evaluation cycle, it must realize a few impacts of that decision. Daily movement to production becomes less likely—most often it takes a week or two for changes to undergo significant human scrutiny (depending on the level of testing automation). The results of human intelligent decisions also must be chronicled in the testing repository to preserve the history for audit. This can lead to a “blame game” kind of thinking when something goes wrong, as it is immediately attached to “who” approved it, instead of to “why” they did so. And obviously the cost of labor is always the highest cost element in any innovation cycle, so buyer beware in this scenario.

    On the other hand, “Nirvana” is the state when all testing (except UAT) is fully automated and gated, and provides the foundation for RO software to move code into production as often as it can prove quality. This could mean fully automated releases instead of release weekends. This could mean multiple releases per day into production. This could mean that releases themselves are no longer considered “events,” but by default are now “non-events.” Nirvana does not endanger the lives of change and release managers—it actually gives them one. For a “change” (pardon the pun), they get to discover something they vaguely remember … a life outside of work.

    To continue the conversation, feel free to contact me.

  • Designing A DevOps Strategy: A Balanced Scorecard Framework

    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
    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-KapadiaMustafa 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

  • 4 DevOps strategies to stop your application having sand kicked in its face

    4 DevOps strategies to stop your application having sand kicked in its face

    While recently thumbing through some old comic books, I got a laugh from all the quirky advertisements. Fantastic promotions of awesome gadgets – like x-ray specs and radio wrist watches. Each designed to extract a gullible kid’s hard earned allowance. Of course they were all too good to be true and probably left many kids disappointed — and maybe like me, just a tad cynical.

    I spied one ad that actually got me thinking about DevOps. It’s the famous “kick sand in your face” strip, which to those unfamiliar offered “98 pound weaklings” a sure fire program to build muscles, beat up bullies, and make lots of new friends down at the beach.

    In IT we also have weakling apps we wish could be stronger. Services so brittle and fragile that any proposed change, update or enhancement is seen as risky – perhaps even career threatening.

    So is it possible to beef up these veritable data center weaklings? Can we also find a way to turn the tables and make our apps stronger?

    Well yes we can, but only with some new thinking. But definitely not (if like kids reading comics), we get sucked in by outrageous DevOps claims, along with a raft of gadgets and tools that never quite live up to our expectations.

    Here are four things to consider as you look to toughen up your apps:

    1. Problem fixing is on the decline – successful businesses finally get that mobile and cloud is the only way to engage customers at scale. This means IT operations won’t have nearly as much stuff to keep watch over in the future. While some mourn the loss of visibility, it actually forces us to do a much better job at what’s really more important – ensuring an awesome customer experience. IT Operations as a discipline will no longer be judged on how effective it is at fixing problems, but on its ability to detect service issues before they impact customers. Therefore app toughness means less after-the-fact causal determination and more analytics for pre-emptive strikes on emerging apps problems – especially those about to bite the business.
    1. Issues now lurk in the “shadows” – developers now have lots of control. With the ascendance of agile and new techniques like test-driven-development and infrastructure-as-code, activities like build, configuration management and provisioning can be codified into work streams. This leads many to argue that operations as a function is defunct (or at least soon will be). After all, if operations doesn’t need to be involved, why is the function needed at all? Unfortunately this “shadow Ops” logic neglects to consider an inconvenient truth – basically that performance and supportability are not top-of-mind issues for developers. So while we have faster lead times, the reality could be a steady stream of weaker apps. That’s what you call “failing fast”, but not as DevOps intended it.
    1. Agile Operations is about “Craftsmanship” – since developers can’t always be counted on to instill quality, its incumbent on IT Operations to help teams build these capabilities. This doesn’t mean trying to impart years of ops knowledge, but actually crafting this expertise into automated solutions – solutions others will use to improve the performance and supportability of applications in context of the actual task being conducted. This could include:
    • Making more accurate performance data available during development so as to code and test against realistic conditions
    • Integrating change management processes with release automation so as to activate change approvals and co-ordinate all workflows – essentially ensuring compliance while eliminating typical delays from manual handoffs
    • Providing earlier guidance to developers on code defects by incorporating standardized, consistent and scalable monitoring into every new release stage
    • Working with business analysts and development to gain usability and customer experience insights from newly released mobile apps
    • Collaborating with developers and service managers to make applications easier and less costly to maintain and support – essentially ending the 3:00am head scratching and blame games!

    Looking at these examples it’s obvious the new IT Ops craftsman won’t linger behind the production curtain. On the contrary, they’ll be the ones working across the entire software pipeline; focused squarely on acquiring new skills and building solutions to drive better business outcomes. Those who blissfully remain in denial, preferring instead to watch monitoring consoles and build out physical infrastructure have a lot to lose.

    1. Application resilience is so yesterday – With on-premise applications the traditional logic has been to associate reliability with preventing and/or recovering quickly from problems. But highly distributed, scalable, cloud-native apps are very different, so our approach also has to change. These applications are the epitome of complexity (only on steroids), introduce many more moving parts, and will service unknown demand – meaning failure is inevitable. Therefore design and operational practices must move beyond break-fix, to ensuring inevitable failures have a minimal effect on customer experience and that each application release ‘learns’ from the experience – yes, actually gets stronger.

    While the old 98 pound weakling comic book advertisement is kind of hokey, many businesses are getting sand kicked in their faces by digital disruptors. So before it’s too late, start re-engineering the operational practices needed to toughen up your applications. Just remember that while rapidly developed apps now deliver your business muscle, they’ll atrophy just as quickly if you neglect quality and performance.