Tag: IT transformation

  • 3 AWS Design Patterns to Maximize DevOps Value

    3 AWS Design Patterns to Maximize DevOps Value

    Many business leaders are planning to make DevOps the cornerstone of their IT transformation strategy. But, as surprising as it might sound, skepticism abounds regarding how major vendors address the DevOps transformation challenges—they confuse DevOps with continuous delivery (CD) infrastructure.

    “We wanted DevOps and we got after a nine-month-long implementation a continuous delivery platform which speeds up IT operations without significant business value. How differently can you help?” the senior business executive of a major financial institution in New York sarcastically asked me during a conversation three months ago.

    The business executive is right: DevOps isn’t a technology as I’ve been implementing it, it’s primarily an accelerated application delivery approach implemented in the form of a technology-enabled application delivery operational model. Adam Jacob, CTO of Chef, substantiates that fact in “The Secret of DevOps: It’s Always Been About People, not Technology,” when he says, “DevOps is about bringing together all the people you need to build and run your business effectively, and empowering them to move as quickly as possible towards their goals.”

    Agile Admin’s Ernest Mueller in, “DevOps: It’s not Chef and Puppet,” confirms Adam’s point: “Chef and Puppet are individual tools that you can use to implement specific parts of an overall DevOps strategy if you want to use them—but that’s it. They are fine tools, but do not solve DevOps for you.”

    How can we implement DevOps in line with business leader expectations? Three Amazon Web Services (AWS) Design Patterns I developed can help to get the best of DevOps on AWS cloud: Software Organization Factory, Digital Organization Factory and CD Infrastructure Factory. This article discusses the Software Organization Factory.

    The Foundation of DevOps Value: Consequences to IT Service Delivery

    Before delving into these AWS design patterns, a quick reminder of what DevOps is, its value propositions and, more importantly, what changes are needed in how IT services are delivered.

    The Ignored DevOps Business Logic We All Must Consider

    The combined effect of cloud adoption and the rising digital economy is changing competitive environments; it forces business leaders to focus on innovation and market responsiveness as the competitive differentiators.

    The fact of the matter is, by facilitating access to technology, cloud accelerates entrance of several thousands of tech startups that take advantage of the recent technology innovations to substitute traditional products and services into digital. This creates a context where new entrants increasingly compete with established brands, forcing business leaders to seek value paradigms other than IT efficiency.

    The business executive argues, “In these new markets, our concern is to increase customer value by delivering the right services to the right segments at the right moment. You guys need to change the IT paradigm; IT alone does not create that kind of value.”

    Then, what should be changed in today’s IT approach?

    The Two Dimensions of Modern IT: The Operational Model and the Continuous Delivery  Infrastructure

    The new IT paradigm advocated in my recent book, “Rethink Your IT with DevOps: The Complete Guide to Aligning Your IT to DevOps,” is the idea that business value results from two dimensions: organizational agility and technology efficiency. In other words, it defines modern IT as a two-dimension asset including the operational model and the continuous delivery infrastructure.

    The timely delivery of innovation transcends IT issues; it not only cuts across your sales, marketing, post sales, application development and  IT operations, but also demands concrete answers as to how to accelerate business prioritization, decision-making and problem solving. The operational model is where business and IT people, processes, practices and tools are combined to create agile and cross-functional environments. The following exhibit shows a typical DevOps operational model:

    Typical DevOps Operational Model
    Typical DevOps Operational Model

    Organizational flexibility for the sake of flexibility doesn’t make sense unless technology is leveraged to speed processes. This is where CD infrastructures come into play; throughout the delivery process, they build on IDEs to accelerate coding and testing, on versioning tools to convert software version into releases, on continuous integration (CI) tools to build releases and on delivery pipelines to ensure continuous delivery.

    So, what is DevOps?

    DevOps is a Technology-Enabled Application Delivery Model

    DevOps is a combination of value, principles, processes and practices shared not only by developers and IT operations but also by the business. The goal is to help the organization deliver the right service to the right market segments at the right moment.

    DevOps from the Business Perspective
    DevOps from the Business Perspective

    As I’ve been implementing it, it’s a cross-functional application delivery model involving the business and IT and enabled by continuous delivery infrastructures.

    By enabling and automating agile practices, the continuous delivery infrastructure makes the operational model agile and provides the business with the flexibility and velocity needed to meet competitive challenges.

    Design Patterns as DevOps Implementation Engineering Framework

    As suggested by the business executive, today’s DevOps implementations struggle to deliver the promised business benefits. The reason is, the operational model dimension is ignored in favor of tools and infrastructure.

    Another reason is, DevOps is young and is still at the early stage of the technology maturity model; the expertise and engineering methodologies to implement it as what it is—a technology-enabled application delivery model—are lacking. That’s where DevOps transformation design patterns help.

    What are DevOps Transformation Design Patterns?

    In this article, the term DevOps transformation design patterns refers to general reusable architectures addressing specific DevOps strategy. They’re not necessarily implementable solutions, their primary goal is twofold:

    • Offer a neutral language for designing and implementing technology-enabled operational models
    • Offer an engineering approach that reduces design and implementation duration and effort

    They’re formalized architecture design and implementation best practices for DevOps and platform-as-a-service (PaaS) services.

    Design Pattern as DevOps Implementation Engineering Methodology

    To meet its goals—technology-enabled application delivery model—the design pattern is structured around four items including purpose,  principles, general solution and implementation techniques.

    Purpose: Clarifies the purpose of the design pattern along with the DevOps strategy to address.

    Principles: Are best practices formulated as rules and beliefs supposed to guarantee expected DevOps strategy benefits? They’re the determinants of the solutions to implement the DevOps strategy.

    General solution: Are blueprints resulting from the application of principles? They summarize the functional and technical architecture of the DevOps platform to implement.

    Implementation techniques: What are recommended technical approaches, solutions and tools to implement the general solutions?

    Why AWS? Why would it be the catalyst for DevOps value?

     AWS-ome Design Patterns That Will Change DevOps Implementation

    AWS offers such a rich, varied and easy-to-implement services portfolio that it would be unfortunate not to take advantage of it to modernize IT. The rationale underpinning the value businesses can derive from their DevOps transformation experience with AWS is summarized in the following figure:

    Rationale of the DevOps Design Pattern
    Rationale of the DevOps Design Pattern

    It’s the belief that:

    • Certain principles determine the AWS services needed to deliver the application delivery model (ADM) architecture that guarantees value.
    • The implementation of the ADM using these AWS services results in AWS-based DevOps platforms that tangibly deliver expected benefits.

    The Four DevOps Principles that Yield AWS Value

    Let’s explore the principles I’ve been using to make CIOs happy with their AWS cloud:

    1. Think holistic, not only IT: Reminds that transformation isn’t only about IT but the entire organization’s value stream from marketing and sales to development and IT operations.
    2. Think cross-functional, not only IT: Reminds that the bottom line is to set up a cross-functional application development environments to accelerate business prioritization, problem-solving and decision-making, and meet time-to-value objectives. They’ll be the core value propositions of the DevOps platform.
    3. Make it agile, flexible, and speedy: Reminds that agility, flexibility and speed are the catalysts for competitiveness and business value. They’ll be part of the DevOps platform.
    4. Think PaaS: Reminds that AWS provides varied services for implementing state-of-the-art CD infrastructure.

    Let’s illustrate three AWSome design patterns that’ll change DevOps experience with AWS!

    Implement a Startup Mindset with the Software Organization Factory

    The purpose is to implement DevOps strategies focused on time-to-market and time-to-value. It’s adapted for tech startups.

    To implement the startup mindset, the DevOps four principles for AWS are implemented as follows:

    • Think holistic and cross-functional, not only IT: Relevant business and IT resources are put together in a single and dedicated service development team supported by appropriate Scrum and XP agile practices.
    • Make it agile, flexible and speedy: PaaS services building on agile practices and AWS infrastructure-as-code are provided to make application delivery processes agile, flexible and speedy.
    • Think PaaS:  AWS infrastructure as code and DevOps tools are combined to implement a CD infrastructure in the form of a PaaS platform.

    The DevOps platform resulting from the principles application is illustrated below:

    Software Organization Factory
    Software Organization Factory

    The “Startup Mindset” platform is structured around three components including the cloud-enabled operational model, PaaS and the CD infrastructure.

    The operational model builds on a three-stage application delivery life cycle:

    •  Plan & measure: It mobilizes business users, development, QA and operations staff on business prioritization issues using agile practices such as Scrum product backlog planning or XP’s user stories.
    • Develop & Test: It mobilizes business users, development, QA and operations staff across the development life cycle using agile techniques such as Scrum iterations, XP’s test-driven development (TDD) and behavior-driven development (BDD).
    • Release & Deploy: It leverages continuous integration practices to build and test releases prior to deploying to production.
    • Monitor & Improve: It’s outsourced to keep the service development team on its core business: developing software.

    The CD infrastructure combines the followings services:

    • AWS CodePipeline and CodeDeploy to set up the delivery pipeline.
    • AWS infrastructure as code including CloudFormation, OpsWorks and Elastic Beanstalk to generate the CD infrastructure.

    Summing It Up

    The DevOps business benefits are real, yet, it’s young and is still at the early stage of the technology maturity model. The expertise and engineering methodologies needed to implement it as what it is—a technology-enabled application delivery environment—are lacking.

    DevOps design patterns such as the software organization factory fill the gaps of today’s transformation practices:

    • They provide the architect team and the executive team a neutral language to discuss the business, technological and technical challenges and solutions.
    • By pointing out the agile practices to leverage, they simplify and accelerate the design and deployment of the operational model.
    • By pointing out the AWS services and features to leverage they facilitate the design and implementation of the CD infrastructure.

    The DevOps implementation process described in this article is fully documented in my recent book, “Reinventing Your IT with DevOps: The Complete Guide to Aligning Your IT to DevOps.”

    In my next article I’ll tackle the Digital Organization and the CD infrastructure design patterns.

    — Philippe Abdoulaye

  • Eight steps to a sustainable DevOps transformation

    Eight steps to a sustainable DevOps transformation

    DevOps is not a standard. It is more a philosophy described by a loose set of concepts and tools, many rooted in the agile methodology and continuous delivery. That often causes confusion about the potential scope of DevOps, and makes it difficult to determine a definitive start and end point for a DevOps initiative. Moreover, DevOps requires significant cultural and organizational change, which can be hard to achieve and sustain.

    So now we know what DevOps is, here we propose eight steps to a sustainable DevOps transformation, based on the use of a modified version of the Kotter change framework (1):

    1. Develop a sense of urgency

    “Deliver it faster and less expensively”. The two most common requests from the business—whether it is to deliver digital transformation, find more agile and cost-effective alternatives to internal IT, or other requirements.

    IT organizations must become fully aware of the urgency to change in order to stay relevant for the business.

    In the context of dev/ops this urgency is measured by release velocity, turnaround time for new features and other metrics. Benchmarking helps here: comparing delivery time results with other equivalent companies using DevOps tools, for example. Any deficiencies can be brought up through a value stream analysis with a TIMWOOD waste analysis.

    1. Form a guiding coalition

    For successful DevOps transformation, identify a team which is both supportive of the change and able to communicate progress. Include senior IT management from operations and development, plus key stakeholders in DevOps processes.

    1. Create a vision

    The DevOps vision for continuous delivery should be aligned with the business vision. It should be broad enough to cover all aspects of DevOps, but sufficiently narrow to guide decisions in the subsequent change process.

    Gartner use the term “boundary objects” to denote things that can be “interpreted differently across different communities, but that posses enough common understanding to make them useful mechanisms to communicate with and improve knowledge”.[1] Boundary objects are thus considered a possible way to align on major concepts; the objects are flexible to local requirements, yet robust enough to maintain a common identity across sites. A DevOps/continuous deployment roadmap is also a necessity, encapsulating important themes and their priorities on an approximate timeline. Avoid detailed project plans, on the basis that DevOps should follow an agile approach and is all about continuous improvement.

    Should the whole organization adopt DevOps or should DevOps remain limited to those areas in which the need for agility ultimately beats strong process compliance needs, risk mitigation and availability requirements?

    There is no definite answer to this, but keep in mind:

    • DevOps is a lot about culture. In the long-term it will be difficult to maintain a single organization, built upon two different cultures.
    • IT systems are often inter-dependent; simple changes have to be implemented across an array of systems.
    1. Communicate the vision

    Communicate the vision, strategy and roadmap again and again. Moreover, start to live the cultural values of continuous delivery, such as avoiding blame, putting individuals before the process and promoting transparency.

    1. Empower others to act on the vision

    Many aspects of the vision—such as reduced process complexity and a revised understanding of collaboration—should already diffuse into the company culture even if “full” DevOps is not in place yet.

    The guiding coalition needs to remove obstacles (such as too many process steps or approvals and rigid system access rights). These potentially limit the ability to experiment with new tools or methods. Indeed, any systems or structures that seriously undermine the vision should be replaced. Likewise, risk taking and nontraditional ideas, activities, and actions should be encouraged.

    1. Create short-term wins

    For successful DevOps deployment and transformation it’s important to deliver visible performance improvements, preferably a couple of pilot projects using established DevOps teams.

    When choosing the pilot team, ensure:

    • The team can be trusted to manage continuous delivery
    • The application is a good fit in terms of architecture and technology
    • The DevOps benefits are apparent to the business
    1. Consolidate improvements and scale DevOps

    Use the credibility derived from successful pilots to change systems, structures and policies that don’t fit the continuous delivery vision.

    Have the different teams implement their own “flavors” of DevOps, best suited to their specific environment.

    These teams can leverage the experience, processes and tools developed through the pilot, but are not required to do so as long as their implementation fits into the overall continuous delivery vision.

    Avoid governance frameworks, which run contrary to the concept of agile.

    1. Institutionalize new approaches

    Articulate the connections between the new behaviors and corporate success with continuous delivery. To do this, you need the right metrics in place, linked to top-level KPIs. At this stage the entire business system has to be adopted to the new culture so that the change becomes part of “business as usual”.

    This “institutionalization” also needs to be supported by metrics, incentive schemes and the appropriate style of management.

     

    (1) John P. Kotter, The Heart of Change, 2002

    [1] Gartner, How to Scale DevOps Beyond the Pilot Stage, Cameron Haight, 11 March 2015, https://www.gartner.com/doc/3003922/scale-devops-pilot-stage