devopsy.kinsta.cloud

Tag: enterprise devops

  • REP SPOTLIGHT: Xellentro Consulting Services

    REP SPOTLIGHT: Xellentro Consulting Services

    DevOps Institute: Tell us a little about your organization.

    Xellentro: Xellentro Consulting Services LLP is an emerging global provider of project, program and portfolio management, IT service management consulting and training services. Established in 2012, with headquarters in Bangalore, India, Xellentro works closely with its clients in tackling their most difficult organizational development challenges. Xellentro is a specialist organization that works with its clients to identify improvement areas and uses experienced consultants to enhance their business and development processes.

    While the realm of management consulting is vast and a number of firms provide a range of advisory services—starting from niche areas to general management domains—what differentiates us is our practitioner’s approach where we don’t limit ourselves only to advisory and rather prefer to stay on till envisaged benefits are realized and final outcomes are delivered. We bring in huge experience across industry verticals.

    DOI: What other topics do you teach or consult on?

    Xellentro: ITIL Foundation, Intermediate, Practitioner, Expert, Scrum Master and Product Owner, PRINCE2, PRINCE2 Agile, MSP, MoP, PMP, Lean Six Sigma

    DOI: What type of interest in DevOps are you seeing in your region?

    Xellentro: There is interest mainly from corporates.

    DOI: How do you think that DevOps contributes to the business’s value stream?

    Xellentro: This will be a good extension to the ITSM and with Agile being used everywhere, DevOps will have a great value.

    DOI: What topic area in DevOps excites you the most?

    Xellentro: The concept of having both Development and Operations working together is very important to finally deliver value to business.

    DOI: Why should enterprises and individuals consider formal DevOps training?

    Xellentro: To really understand the culture change and not focus on only the tools/automation part of it.

  • Integrating ARA into traditional RM

    Integrating ARA into traditional RM

    Application Release Automation (ARA) is terminology that includes several DevOps constructs from a singular, application-centric point of view. In essence, ARA implies the automation of a single app from build through deployment (even if that deployment is to production). Of course, embedded or implied in that automation terminology is build automation or construction; deployment automation, which may include provisioning; and governance automation, which includes testing and approvals.

    If your company’s portfolio of applications is small, or if the applications are fully independent from each other, using ARA to describe your DevOps continuum is more or less a complete vernacular. However, if your application portfolio contains interdependencies; you need a coordinated/scheduled release event of multiple applications into production in a particular sequence or timing;or you are required to meet blanket compliance governance requirements that exceed the scope of a single app; you will need to learn how to integrate an ARA-based DevOps strategy with the more traditional discipline of Release Management (RM).

    Clarifying ARA

    One of the nicer implications of ARA thinking is that it places the value—or, accentuates the value—where it should be; that is, on the application. Automating infrastructure is great, but if no application rides on top of it, the infrastructure is essentially nothing more than unexplored capacity. Most CIOs are not fond of having excess computing capacity sitting idle. So the idea of ARA sets the focus of the automation where it should be: moving an “application” from construction to production release.

    ARA is also development methodology-neutral, which means the build, deployment, and releasing automation will look the same regardless of whether the code was prepared using Agile or Waterfall. Mind you, Agile tends to drive the need for speedier delivery systems, but even legacy development teams can find value in consistent delivery system automation once a build is ready to begin. It is, after all, consistency that reduces support costs by reducing errors and creating predictability, thereby improving quality. It also is consistency within the automation that permits scale, whereas variability in the automation deters scale.

    ARA also allows for depth within the stack. If code reigns at the top of the stack, then the operating system of the server reigns at the bottom (perhaps networking in the wine cellar and facilities management in the root cellar). ARA incorporates the notion of automating dependent layers of technology under the code such as database services, middleware or messaging services, perhaps the provisioning of a virtual machine, even down as far as configuring the OS, if needed.

    The practicality of moving down the stack however, is that the scope of change will continue to have a broader impact than a single app. I usually do not install a single instance of Oracle for each application I create; more often, I have several applications relying upon a single instance of my Oracle setup. So the actual changes I automate as I move down the stack tend to be more of a configuration adjustment. It is more likely my particular app needs a config change to accommodate it rather than a completely new install of a supporting technology component underneath my app. It is also worth noting that the frequency of change as you move down the stack slows down considerably compared with app code riding on it, and the cost or impact of change increases greatly, as you begin to impact a wider number of things riding on it.

    Deconstructing ARA

    ARA automation, then, includes all the traditional DevOps disciplines, but limiting them to the viewpoint of a single application as follows:

    Build Automation: This includes version-controlling each particular build. It also includes packaging all the component technologies to create a deployable package used for deployments throughout the software development life cycle (SDLC). The golden rule here is create a “build once, deploy many” philosophy in your build automation. Changes to code, included configuration files or dependent technology components down the stack must occur in the DEV class environment. Once the deployable package is completed to satisfaction in DEV, it will move unaltered through any other layers of testing environments before it gets to production for ultimate release.

    Deployment Automation: Since each deployable package is tightly version-controlled during its construction in build, there is now an ability to roll forward (normal deployment) or roll backward (revert to a prior version) in the event of failed testing in a given SDLC environment. Some of the common environment classes include integration testing, performance testing, user acceptance testing and pre-production quality assurance (QA) testing. Smart DevOps deployment tools utilize the ability to deploy (or overwrite) only the components that are out of sync with the versions listed within the deployable package. This smart deployment capability reduces time and ensures consistency with what “should” be there.

    Provisioning Automation: This is an offshoot of deployment automation. For those using virtual machine or cloud technologies, the deployment automation can include the ability to provision or set up an environment of any class on the fly. When testing is completed, the same environment can be decommissioned to not waste capacity or budgets. Provisioning bare-metal servers is precluded by human interactions, although what should go on them also can be fully automated once engineering is done with the physical work.

    Governance Automation: Even though substantial testing can and should occur in development, a significant amount of it must occur in other testing-class environments later in the SDLC progression. It is, therefore, a good idea to have the ability to isolate testing automation outside of both build and deployment templates or scripts, still making it callable or executable from an overall workflow manager (often included in the release orchestration or release automation tooling within DevOps). This gives the flexibility to run a series of tests without having to rebuild the application or redeploy the application just to kick it off. In addition to testing evaluation, there may be other process regulations driven by a governance team or compliance entity within the organization. All of these flags must be met and passed before final promotion to production.

    Integrating ARA with RM

    Dependency is the hobgoblin of simplicity. Applications that are fully independent of each other can utilize an ARA strategy and deploy into production as often as they want. No one else is impacted by this. But if a given application has dependencies upstream—I get my data from, or transact with, someone else—or downstream—my data is provided to someone else—then my path to production must include testing an application different from my own. Determining where the responsibility for failure lies now requires policy instead of just common sense. Synchronizing in-state changes where two dependent applications are now undergoing change at the same time requires policy to govern as well as more sophisticated SDLC testing environments to manage.

    When a wider view than just a single application is required, the traditional DevOps discipline of RM or its synonym release orchestration (RO) becomes the solution. RM allows for the sequencing of applications going into production to occur as needed. It allows for testing to occur when a dependency spiderweb is kicked off. RM allows for corporate governance to be applied universally to all applications attempting to enter production, instead of having to build it over and over again in each deployment script or template. RM can produce sophisticated logs designed to satisfy outside regulators for compliance history automation. These kinds of tools become invaluable when there must be a wider view of deployments to production beyond a single app at a time or in a small portfolio.

    Given this reality, the key to integrating ARA with RM is to ensure automation is constructed independently by discipline, and can be executed by discipline as needed. ARA encompasses or groups four disciplines together: build, deploy, provision and governance. RM uses the ARA package and extends it with other applications to create a needed sequence, or kicks off selective smaller units such as a testing package when needed to meet certain outside app change conditions based on dependencies. RM can selectively execute the automation ARA creates as it needs to to accommodate larger goals, while ARA continues to focus on keeping its own app as efficient as possible.

    Impacts to the Bottom Line

    There is no one right answer. There is only the perspective you hold within the DevOps continuum. Knowing that both ARA and RM are ultimately dependent on traditional DevOps disciplines offers flexibility on “how” you think about delivering innovation. In my opinion, ARA is simply the next evolution of automating build and deploy. It is a logical next step.

    There are other disciplines within DevOps, however, that might benefit from a wider view of the workflow required to move innovation to production. Take, for example, the integration of monitoring automation in the process, capacity on demand provisioning, security oversight and configuration management database (CMDB) integration—a wider view of how and where these services are integrated with DevOps might reduce the labor required to create them for each app, reinventing the wheel—or worrying the wheel has not been updated properly in a while. At its heart, DevOps attempts to create singular automations to perform tasks, increasing speed, reducing risks and improving quality.

    There is no immediate financial impact of this other than to pursue a strategy of single-app focus in an environment where a wider view would have been more ideal. Calculating the cost of that error is akin to picking six lotto numbers from the sky: It is always hard to know what might have been; at that point all one can do is wish.

    To continue the conversation, feel free to contact me.

  • Engaging Adoption of DevOps

    Engaging Adoption of DevOps

    Executive mandate does not immediately translate into a change in behavior. Organizations inherently grasp the value of embracing DevOps, but the timing of exactly when it begins and is completed is another matter. The devil truly is in the details—or rather, in the ability and willingness of the organization to adopt a change in thinking and a change in the actions that follow.

    “Adoption” is then a common term to describe the measurement of how far along an organization is in its transition between legacy and future, between the beginning and the completion of embracing DevOps services. As you might guess, adoption does not happen overnight, nor does it occur because of mandate or willingness. These factors influence the speed of adoption in some cases, but can act as deterrent in others. Adoption—like most other services provided to a given organization—occurs because its value proposition is sufficiently defined and resources are budgeted and assigned to it.

    The level of resources you dedicate to tracking and facilitating adoption of DevOps in your organization is directly proportionate to the complexity of your development efforts. If for example, you have a new development team well-versed in cloud technologies and comfortable with using software-as-a-service (SaaS) tooling with only few applications under development (small app portfolio), your proportionate adoption efforts will be small, and transition should occur very quickly. However, if you have a large number of applications spread out across a wide variety of hardware platforms and are using a wide variety of development languages or tools, your proportionate adoption efforts will be far more substantial to keep the timeline manageable. In either example, a complete lack of attention to adoption results in elongating the timeline two to eight times longer than it would have been if formally engaging adoption was considered.

    Adoption Engagement 101

    So what do these adoption/engagement resources do from day to day? The primary focus of the folks assigned to this duty breaks down into three major categories of work efforts:

    1. Communications conduit: The first responsibility of the folks on this team is to develop and implement a communications plan to keep all stakeholders up to date on what is going on with DevOps services. This includes metrics-based information such as how many applications have been fully onboarded to DevOps. It also may include how many applications have been onboarded into a particular level of automation within the stack, from code to OS. A company may want to know how many apps have gotten their database efforts automated, as an example, or perhaps how many apps are fully automated with middleware messaging systems. But the communications also must include keeping executives up to date on the ROI progress, and what areas of the company may be exhibiting resistance (for both legitimate and non-legitimate reasons). Expressing these outcomes can be sensitive and should be done with a modicum of care, so the folks assigned should have these skills to start with.
    2. Information Preparation & Follow-Up: When a given application in the portfolio is targeted for onboarding to DevOps, a significant amount of information is usually gathered about it. While a company can create an automated system for development engineers to provide the data into an electronic web page or other means, very often questions arise about “how” to respond. You do not want to have your DevOps services engineers constantly deterred from their work to answer basic questions such as this, so having an adoption team able to provide the data quickly facilitates the overall goals. In addition, often the development engineers are too “busy” to provide the DevOps team the data they need. Again, someone needs to follow-up to ensure questions are actually answered. While it is easy to assume engineers will behave professionally and respond accordingly, that assumption in the real world results in long delays and interrupted workflows across multiple teams.
    3. Training & Feature Expansions: Finally, the tools and architecture practices behind them need to be communicated effectively to the practitioners and participants of the DevOps services. When new programmers are hired, for example, they should have access to training materials on accessing to the DevOps toolsets and using base functionality, what governance procedures will impact them and more. On occasion, to facilitate adoption, an application executive sponsor and his or her immediate direct report engineering team leads will request a demonstration of a given DevOps tool or function. The adoption team should handle these requests and not divert a production DevOps engineer from his or her duties. And when a DevOps tool is updated or upgraded, the adoption team should develop the method to communicate the new ability, edit the existing documentation and ensure every practitioner is notified about the new features and how to use them.

    Adoption Engagement Financials

    Deciding how many people to dedicate to this function is a mix of your development environment complexity and what you have currently to complete your DevOps rollout efforts. If you want a 24×7 rollout, then you will need staffing levels to accommodate three shifts, seven days a week, with additional folks for vacations, holidays and sick leave. If you are only rolling out a 9-to-5, five-days-per-week effort, staffing numbers drop significantly. Resources, then, can be organized as one per line of business or one resource for every 50 applications in the portfolio (higher ratios are supportable). Whether you align the resources to the services you provide or to the customer audiences you support won’t matter nearly as much as having at least some resources dedicated to these efforts. As I stated earlier, a complete lack of resources dedicated to this function results in greatly extending the timelines for adoption of DevOps; worst case, in the failure of the transition entirely.

    This kind of function is inherently considered overhead. Most DevOps leaders (generally emerging from an engineering background) naturally don’t consider this more administrative function as necessary. It doesn’t strictly add to the engineering capability or skills of the main onboarding teams, so they simply do not include it or divert budget to more “necessary” folks during planning. Organizations that don’t actually provide a guided DevOps service—that is, they simply install the tools and tell the developers to have at it—find their adoption efforts lagging quite a bit as well. The early adopters jump right on without coaxing, but the folks too busy with their own efforts to “try something new” never seem to get around to it. Finally, the guys who think, “Since it ain’t broke, don’t fix it,” will never adopt. Even in this kind of tooling-only services deployment, dedicated adoption resources would have resolved these issues in a far more timely manner. The overhead may be painful, but the alternative is far more painful. Once a company or division experiences a failed DevOps rollout, it rarely returns to try again, and the overall costs could be doubled or worse.

    For organizations with the vision and perseverance to employ dedicated resources to facilitate adoption, the converse of the problems outlined above becomes the norm. Developer teams have the information they need to understand their own need and, more importantly, the benefits of adopting DevOps. The work relations between DevOps service provider and DevOps service consumer become highly efficient and mutually beneficial. The entire organization benefits from effective communications from the executive sponsors at the top to the engineering practitioners at the bottom. Execs know the costs, the progress, what is new and how it will help them reduce costs or speed up delivery. Practitioners know how to use the tooling, why it will help them and how to stay current on the changes that come along (and they invariably do). Practitioners appreciate being current on a given tool or skill set; this provides a way to do just that.

    Impacts to the Bottom Line

    Discreetly measuring the ROI for the application of adoption/engagement resources is a bit squishy. As a general estimation, take the timeline of the DevOps rollout you originally planned and multiply that by two to three. The cost of that delay in timeline (plus the risk of complete failure) is the cost delta to measure against hiring a few more folks (or allocating them from lesser-used areas already on staff). Usually the cost of failure far outweighs the benefits of expanding the overhead support teams as needed. In addition, the cost of a failed communication effort can grow over time. At the outset or launch of DevOps, the communications, whether in document or oral forms, will be fully up to date. But over time, as vendors add new features and new versions of the tooling emerge, practitioners won’t know how to take advantage of the new capabilities. Since many of these new features enhance speed or accuracy, the tendency to not use them—or use the inconsistently for lack of knowledge—will add up.

    I find the resistance to the idea of adoption or engagement resources often is founded in the notion that engineers are plenty smart enough to figure this stuff out on their own and they will naturally gravitate to it, as ultimately it makes their lives easier and better. Yes, the engineers are smart enough and some will. However, engineers often build their own “ecosystems” of how an application should be built (which few others could understand or improve upon). They often are reluctant to tear this down in favor of corporately implemented templates (that everyone could understand and improve). They fear the loss of unique skills the company must depend upon. They fear the loss of being “special” and needed. Even though DevOps standardization makes builds and deployments consistent, reduces trouble tickets and improves quality and speed—which ultimately translates into fewer 2 a.m. phone calls for engineers to come fix—they are still reluctant to change (just like the rest of us). Having dedicated resources to help them through the value of this, and assure them of their continuing value in a differing area (the code we want them to write), can make a world of difference and ensure a transition does occur.

    To continue the conversation, feel free to contact me.

     

  • Baselining Metrics to Measure DevOps ROI

    Baselining Metrics to Measure DevOps ROI

    Assessing the ROI of DevOps normally is done against a company’s baseline cost. The problem is, most organizations do not collect or evaluate the cost of “automating and delivering” innovation; they usually are more focused on the innovation product itself. As an example, if a company creates an application hosted on the web that offers its customers the ability to purchase inventory, the company usually is obsessed with knowing how that application performs: How many people are using it? How often does it fail due to bugs? How many sales are made? The company typically focuses on the end product—on the application as it touches customers and potential customers. The delivery process that precedes the application being loaded into production is not usually the subject of intense scrutiny. At least, most organizations are not evaluating the speed of delivery and process effectiveness of delivery prior to an embrace of DevOps methods and tools.

    This lack of scrutiny results in the lack of a baseline to compare against. Say, for example, a typical programmer (prior to DevOps) uses a mix of scripts, human intelligence and human verification to create and verify a build. Prior to DevOps, the goal is simply to create the build and get it out there to look at it, and decide what to do next. Most programmers are not obsessed with how efficient this entire process is; for them, it is a means to an end. So most programmers do not keep records of the average amount of time it takes to create the build from beginning to end. This is even more true of the deployment process. Once a build has been created (again prior to DevOps), getting it deployed to the target environment might involve a few different teams (depending on the class of test environment that is targeted). The process may involve email requests to other support teams or filling out a ticket to get it done. Once again, most organizations spend little time tracking this process from end to end; it is only ever a means to an end.

    If, in fact, an organization was watching closely how long it takes to get a build created and how long it takes to get a deployment completed, that organization would be running toward DevOps at full speed to see improvements it otherwise could not achieve. It is the things we do not measure that receive little attention—until they break. Once our deployment process has become so onerous or so complicated or so burdened with approvals required that nearly nothing gets deployed, then we begin to look at it. This creates a culture of “squeaky wheel syndrome,” which makes both our development and our operations teams focus only on reactionary issues, while proactive concerns die on the side of the road. There is no time to invent proactive improvements when you are constantly fighting the fires of something else that is seriously broken. This culture must also change if DevOps is to succeed broadly in your organization, so keep note of how far it may be infected in how you run things today.

    Preparing for Collection

    Given that most companies lack a real baseline to compare against in this area, realize that collecting one will take an investment itself. This baseline metrics collection cost is usually added to the cost of the investment in DevOps. It is a bit unfair, as you are effectively saying, the soap company will also have to bear the cost of determining how dirty we are before we invest in the soap that will clean us. The makers of soap tend to think you already have a sense of how dirty you are, or you would not be looking at buying soap in the first place. But without an accurate assessment of knowing the extent of the problems (in this case, the investment of time you spend today), you will never know the ROI of having made the improvement of DevOps (the after picture).

    Also, keep in mind that measuring anything manual is difficult. This sounds like a saying from Captain Obvious, but consider that manual work efforts require additional manual work efforts to capture them and record them in some kind of system. If, as an example, my typical programmer spends 15 minutes of every build doing human verification of the build, this amount of time is reflected nowhere. Hourly employees typically record how many hours they work per day, not what tasks they spent during the day. Even the employees who log work hours more discreetly tend to record only that they spent “x” amount of hours doing “development,” not what general task categories occurred within the heading “development.” So there are no electronic records out there that can be gathered automatically that will reflect the 15 minutes spent doing human verification of a generic build of an application. The only way to know this is a personal interview, followed by someone keying the data into a collection system of some sort.

    Knowing that the information you seek for a baseline will come in human interactions as well as some automated logs, start the collection using a tool that allows for maximum flexibility for those efforts. Spreadsheets come to mind. When the effort to collect a baseline begins, you will have some ideas about the kinds of data you wish to collect and how it might exist in your organization. But it is impossible to know exactly how the resulting efforts will be completed. In short, you don’t know what you don’t know. While you collect metrics you will invariably come across someone who reveals critical metrics-related information you were not “planning” to collect. But once the revelation is made, you will need to incorporate the “new” information to really provide an accurate baseline assessment.

    Determining the Baseline

    The next step is to begin the collection process itself. The critical data to examine usually can be gathered by looking at “human” time involved in a given core “process” of the automation and delivery of innovation, and then the “machine” time involved as well. For example, the time a programmer must spend prior to the launch of a build (not the coding time)—all the prep work doubling checking that the system is ready to launch the build scripts (or ready to manually push the buttons)—would be considered “human” time. The execution of the scripts to create the build would be considered “machine” time. Then, all the work done after the build is created to verify it and make sure things are as the programmer expected, again can be put into the “human” time category. DevOps will systemically automate both the pre- and post-time activities the “human” currently invests, so all that time will count in the ROI.

    The above example is good when one person has full control of a process from end to end. When other teams must get involved to complete a task, the “human” time begins to skyrocket. If, for example, a programmer or release manager, must get a request email (or ticket system equivalent) to deploy a particular build to a particular target environment, the entire life cycle of that ticket becomes part of the “human” time you need to track as your baseline metric. Even when shops create a two-day service level agreement (SLA) for turnaround, it still represents two days of delay (due to “process” time) in the life cycle of a deployment. The time “humans” actually spend reading requests, approving requests and routing requests is all time that DevOps will automate and eliminate. Finally, when the correct support team (usually Ops) pushes their own script buttons to do the deploy, that part of this process is once again “machine” time. As you can imagine, the end-to-end time of a given deployment can be days in the pre-DevOps methods and only minutes in the post-DevOps methods. Self-service deployments can reduce this time even farther, removing handoffs, reducing risks and delivering innovation at will.

    Further classification of this metric data can be useful as well. For example, you may wish to break down “machine” time into its relevant subcategories such as build script execution, deploy script execution, test script execution and release script execution. You also may want to break down the “human” time a bit further as well into pre-build/deploy verification, post-build/deploy verification and test script results evaluation. Finally, you may wish to break “process” time down further into request generation, request routing, request approval, request declination and request notification. DevOps will be able to give you discreet visibility into the time you saved in these subcategories, although since baselining is generally a one-and-done effort, you may not want to hunt this level of detail. It is down the road where this kind of subclassification becomes useful—for example when you are trying to determine if one set of tests runs faster than another or one cloud provider runs faster than another.

    Evaluating the Baseline

    Having gone through this exercise, a hidden or secondary benefit emerges. Your organization begins to understand much better what it has been investing in the current delivery of innovation processes. Generally, immediate areas of concern emerge and provide the DevOps services delivery with a road map for which areas to attack first to provide the company with the biggest bang for the buck. Without a baseline effort such as this in place, your DevOps services delivery plan will be based on anecdotal thinking or on executive mandate that may not be substantiated by the data on the floor. Having a baseline provides a road map for delivery based on concrete evidence on what should matter most to the business in making improvements. No one can argue with the numbers (assuming they were collected with care). The road map may reveal which applications in your organizations portfolio should be targeted first for DevOps.

    Also, your organization now understands much better “what” data in this process it sees as relevant to continue collecting even after DevOps is implemented. As DevOps is primarily an automation set of tools and methods, DevOps should be able to deliver these metrics in an ongoing basis. This allows continued metrics efforts to be automated without further human labor and can provide continuing proof of the value of DevOps to the organization, as over time the numbers continue to improve. Since the lion’s share of manual tasks disappear with DevOps in place, there should be no reason to have to manually collect metrics data as you move forward.

    Finally, having an automated metrics collection system put in place by DevOps, should lead to the next evolution in thinking: simulation. Well after the initial ROI for DevOps services has received the accolades it is due, an automated metrics collection system should provide all the raw data needed for some predictive analysis. Tweaking variables or process points or “machine” effectiveness should result in increased speed of delivery that can be measured (even before it is reality) based on the data you have been collecting systemically. Understanding the impacts of these changes is worth more than its weight in gold, because you can weed out the planned changes that simulation advises against before they even hit the road map, let alone occur in your world.

    Impacts to the Bottom Line

    There is already enough anecdotal evidence in existence to entice companies to embrace the DevOps journey. However, as your strategy begins to look to deepen down the stack from application code level to middleware, database and operating system, each layer could be assessed against a baseline to determine if your road map is sound and, more importantly, in the right order for your best ROI. This applies as well as you look to expand your DevOps journey laterally with additional services such as automated testing and evaluation, gated progression, automated provisioning, release orchestration, configuration management database (CMDB) integration, production provisioning on demand and monitoring integration. Each new service can be assessed against a baseline to determine if its ROI still meets the demands of your finance department and if your road map here is in the right order for biggest bang for the buck.

    The subtle win by performing baselining is the culture change it dispenses through your entire organization. Baseline metrics tell your development team and your operations teams (as well as the business units looking on) that you intend to measure performance and improve it systemically. Just because something was not examined before does not mean it will remain so, and a forest fire does not have to be the motivation to do so. DevOps is a proactive improvement to your delivery of automation. Collecting that baseline for your ROI, begins to seed the idea that proactive improvements are important to your executive teams. It is a demonstration of action over platitudes. It begins to eliminate the forest-fire responses in your employees, and creates a new forward thinking point of view. This cultural change is worth more to your company than any implementation of any one given tool or method, it goes back to changing how you think about delivering innovation in your individual job. That is what DevOps can do best.

    To continue the conversation, feel free to contact me …

  • Training & Certification Implications

    Training & Certification Implications

    Changing culture does not happen by osmosis, it happens through incessant education. The DevOps continuum of services your organization originally intends to create and implement is a journey more than a concrete destination. It will evolve over time no matter what your original plans were, no matter what your vendor of choice tells you, and no matter what resistance you meet along the way. If anything, resistance within your organization will push your journey left or right from its originally intended path. The lack of features in your tooling, or the introduction of those same features over time, will impact the journey of DevOps your organization will embrace. Culture is fluid. DevOps is fluid. So managing the impact they will have on each other should warrant dedicated concentration, and resources, in the form of training and education.

    Audience Educational Considerations

    It is not just your practitioner base that will need perpetual education to use your DevOps services to maximum effect. It is also the business community that relies on DevOps information and the executive community that may have sponsored the journey into DevOps in the first place. Education for the non-practitioner is more than just a matter of managing expectations, although that is a big part of it; it is a matter of helping this community learn to watch “change” or innovation as it moves from idea to production. DevOps will make an extraordinary impact on the speed of innovation delivery, as well as the quality or reliability of delivery. Engaging your business community and training them so they see this, comprehends what it means to them, and keeps them informed of the improvements will be critical to the long-term success of your efforts.

    Consider how managing expectations will impact adoption of DevOps services from a business point of view. When you first start on your DevOps journey, usually only the build and deployment services are launched as the “core” of the service. As you do this, you will need a way to keep your business community (i.e., the audience of what you do), informed as to your progress, and what key features or functions remain on the drawing board. How you communicate this information will be key to managing the expectations of your audience.

    For example, your initial efforts at build and deploy may only include the application code as its target. But over time you may begin to deepen what can be automated down the stack—say databases or middleware—as your next target. Eventually you are automating server O/S or even network definitions. If this is the services plan your organization takes on, you need to outline the timeline for expansion to the business community—not just in bullet points on a chart or timeline graphic, but specific benefits they should expect to receive at each milestone (i.e., why they should care).

    As your actual journey of DevOps begins, you may find, as an example, that you never get to network definitions in your automation efforts for one reason or another. Why you’re not reaching this goal needs to be explained, as well as the impacts of this. What drives this conclusion should also be explained; it might be for a very good or legitimate reason. But altering the DevOps journey needs to be ingrained in the business culture. Taking small steps, minimizing risk, learning from mistakes, and moving on—all are key lean concepts, agile methods, and ultimately they ensure the success of your DevOps efforts. The need to communicate changes in your plans to the business community helps manage expectations, but beyond that, it teaches the business community that information will be flowing constantly—and will be important constantly, even if it is brief in each segment.

    Whether your organization plans to expand DevOps services by moving down the stack, or perhaps by adding more capabilities laterally, you will need the ability communicate direction as well as “how” to take advantage of the expansion of DevOps you offer. So for example, if you are expanding your DevOps service by moving down the stack from app to operating system (OS), you will need to show the business community how to watch changes at each level (app, middleware, OS) or, if you are expanding your services laterally, adding automated testing, then release orchestration, then monitoring integration, and finally production provisioning automation. You need a plan for communicating each success, as well as “how” the business community can take advantage of what is accomplished.

    This communication plan should manage expectations, inform of changes in strategy or direction, inform of success/failure/alteration, and teach the business user how to use what you have done. Your communications plan may be looking at new data that was not previously available, or tracking innovation change differently. But educating your business community base will not be a “one-time” event; it will be a perpetual activity. Therefore, how you create this process should be built for perpetual delivery, not just a one-and-done delivery.

    The frequency of offering it will depend on the specifics of your organization’s needs. But the frequency should always keep pace with the changes and successes of your DevOps services delivery. If that is weekly, then weekly, if that is monthly then monthly. What you do to communicate, and how, will depend partly on that frequency and the size of your audience. Keep in mind your tooling vendor is also constantly enhancing its toolset with new features. The frequency of delivery may also need to incorporate those impacts as well.

    Practitioner Educational Considerations

    Educating your practitioner community generally is focused on tooling proficiency. But that may be a limited view. The architecture of your DevOps services is arguably more important than the specifics of how you use the build tool. Consider how your DevOps practitioners intend to accomplish the ability to scale build automation, as an example. I could just train the practitioners on how to use the build tool and then turn them loose, automating builds armed with little more than a cursory understanding of my preferred build tool. And over time using this training method, I will have as many methods to construct build automation as I have engineers who touch my tools, namely “n” methods. Having that much diversity in “how” I construct build automation creates variability that, with a large portfolio of apps, does not scale and is difficult to sustain without constantly throwing labor at it.

    Conversely, my architectural approach to build automation established by the DevOps team instead might be that each kind of technology uses a master template, or framework, as its approach. This information has little to do with a specific build tool and everything to do with the  organization’s “strategy” for build construction. That information becomes much more important than specific tool usage, because it affects “how” engineers use the tool according to company standards and practices. Training and creating a communications plan for reaching every member of your practitioner community on these items becomes critical to longer term success. This includes hiring new talent, departmental transfers and contractor augmentation.

    The additional consideration here is how you want to manage your intellectual property. “How” your company constructs build automation may be a proprietary advantage for your firm. This is particularly true if your architecture team is top-notch and able to create structures in your tooling that less experienced practitioners would not have even considered. If you train outside contractors on your methods, you are in effect giving away some of the farm. Non-disclosure agreements may keep a contractor from purposely sharing your methods with a competitor, but it will not prevent the engineer from learning how to make a better mouse trap while working with you. The contractor leaves your employ, a much more well-educated engineer than when he or she started.

    Once overall strategy education has been planned for and imparted to your practitioner community (another perpetual delivery method required), most companies focus on tooling proficiency. DevOps is still a relatively new phenomenon. And as such, certifications that are common in the networking world, for example, do not exist in the DevOps world. Gaining proficiency from vendor tools should be provided by those vendors as part of the licensing purchase agreement. If the vendor is unable to provide it in a formal delivery method, beware: The toolset is probably a new acquisition or too new in the market. If you are using open source tooling, a fully in-house model for training must be created and managed on an ongoing basis.

    Impacts to the Bottom Line

    Changing culture on a wide scale will require a focus of resources for training and education across your company. Engineers typically do not make the best communicators—that might be a DNA thing—so you may want to pair training and communication resource employees with the DevOps team to deliver what will be needed in an ongoing basis. The main consideration here is to realize that because DevOps services constantly will be evolving, communication plans need to keep pace with their evolution. And yes, I realize, this is additional overhead costs that almost no DevOps delivery person believes he or she needs when the services are first launched.

    But like all things, an initial publication or announcement is not sufficient to keep track with something that changes on a highly frequent basis. Adoption either can be facilitated by a good communications plan or thwarted by the lack of one. If it takes your company 15 months longer to get fully onboarded to DevOps because of delays in the rate of adoption (based on poor or non-existent communication), you must consider the costs of that delay in contrast. If after onboarding to DevOps, your business audience is ill-informed about how to use the services to maximum effect, what will that inefficiency cost the company? If your practitioners are only exposed to tooling proficiency once and without architectural oversight, what will the cost of the variability they produce in their automation be to the company?

    Investing in training and constant communication may not raise revenue, but it will certainly avoid costs. The measure of how much cost it avoids is difficult to track. Most companies who make the investment understand intrinsically what the alternative would be, and choose not to go down that road. The only admonition I would offer is that I have seen clients make this decision late in the cycle, and every one of them did so because the pain motivated it. Your strategies for DevOps should be comprehensive in perspective, if you need help crafting or improving yours, contact me—I am looking at the moment.

    To continue the conversation, feel free to contact me.

     

  • REP SPOTLIGHT: Soft2Solve

    REP SPOTLIGHT: Soft2Solve

    DevOps Institute: Tell us a little about your organization,

    Soft2Solve: We work with our customers in order to help them to enhance IT performance, saving cost, and training on best methods, process and practices, selecting at the same time the best solutions for Spanish Speaker Customers.

    DevOps Institute: What other topics do you teach or consult on?

    Soft2Solve: Cost savings in some specific areas as printing, energy.

    DevOps Institute: What type of interest in DevOps are you seeing in your region?

    Soft2Solve: The interest is initial. Most of customer are aware of DevOps initiatives, but they are still learning and looking how movement evolves and how they can set up the practices on their companies. Some of them already started with agile methodologies in development.

    In the other side, most of them already have ITSM practices implemented, based mainly in ITIL.

    DevOps Institute: How do you think that DevOps contributes to the business’ value stream?

    Soft2Solve: First, aligning IT with the business requirements in terms of speed, flexibility and agility. Then it contributes to analyze the bad processes in place and getting high cost savings when implementing DevOps practices. It also enhances the internal relationships between IT departments, as usually there is a big fight between them. Also, that impact on quality and speed to answer the business.

    DevOps Institute: What topic area in DevOps excites you the most?

    Soft2Solve: It is an IT answer to the business requirements to follow the business needs; meanwhile, being more productive and less expensive. In other areas, the automatization is a base for DevOps.

    DevOps Institute: Why should enterprises and individuals consider formal DevOps Training?

    Soft2Solve: Although sometimes the organizations do not know, any new change—especially culture changes—need internal sponsors as much as possible in the organizations. These people have to be trained by third-party independent people outside their organizations that are aseptic and not influenced from the internal existing culture and way of doing. These people will be the people that will support the change and the IT alignment with the business organization and will answer quickly to business requirements.

  • Iterative Indicators: Measuring DevOps ROI

    Iterative Indicators: Measuring DevOps ROI

    It’s well-established that application of ROI measurements to IT investment remains an imperfect science, and the same goes for ongoing adoption of DevOps methodologies.

    The fuzzy math of vendor-driven ROI calculators aside, even the most respected industry watchers have long struggled to create concrete parameters for assessment of technology spending. This, in large part, has been related to the fact that the requirement for continued investment has outweighed the value of short-term metrics.

    At the same time, it’s hard to put a price on the influence that paradigms including mobility, virtualization and the cloud are having on today’s business world. The scope of the so-called Applications Economy is only truly beginning to be realized.

    For in-depth discussion of DevOps ROI, register today for the upcoming webcast “Maturity Metrics – Analyzing the 2016 State of DevOps Report” with noted industry expert Gene Kim.

    With DevOps, the challenge of ROI measurement evokes similar characteristics as with these other bellwether movements. The affect that leveraging DevOps to become more agile and respond adeptly to changing customer expectations will have, long-term, ultimately will be realized as much in organizational viability as in any immediate cost-savings or other factors.

    That said, the recently published 2016 State of DevOps Report, assembled by the researchers at DevOps Research and Assessment (DORA), goes further down the path toward creating meaningful ROI metrics than any other such previous effort.

    For starters, the 2016 report builds on previous year’s conclusions that so-called “high-performing organizations”—those already deeply engaged in DevOps practices—are “decisively outperforming their lower-performing peers in terms of throughput,” and this gap continues to widen.

    Moreover, DORA contends that high performers deploy applications code 200 times more frequently than slow performers and achieve 2,555 times faster lead times. Perhaps even more importantly, in particular as it relates to the ability to improve applications performance, the report estimates that leading DevOps practitioners lay claim to 24 times faster recovery times and three times lower change failure rates.

    The State of DevOps Survey, completed by roughly 4,600 technology practitioners, also found that high-performing teams spend far less time on so-called “unplanned work and rework”—most often required to address existing problems—allowing them to spend nearly 50 percent more of their time on new work. The latter brand of effort is typically aimed at adding or improving feature functionality—or, in simple terms, innovation.

    As increased software velocity and reduction of MTTR represent the most critical differentiators in today’s environment, where an end user may wait only seconds for an app to load before abandoning your brand altogether, these conclusions obviously carry impressive weight.

    Finally, based on a framework established by research analysts at IDC which suggests that hourly application downtime costs can range from $1.25 to $2.5 billion for a Fortune 1000 firm, and that the average cost of a critical application failure is $500,000 to $1 million per hour, the State of DevOps Report allows for the conclusion that high-performing organizations save an average of more than $91 million per year.

    Much of this advantage is found, the researchers note, in the form of lower applications change failure rates, or those updates to software code that result in subsequent performance issues or outages. While high-performing DevOps practitioners experience an average change failure rate of 7.5 percent, medium-performing organizations see that figure rise dramatically, to a whopping 38 percent.

    If the undeniable adage that “time is money” applies in today’s Applications Economy as much—if not more than ever—than these ROI calculations would appear to infer substantial meaning.

    Later this month, Gene Kim, one of DORA’s founders and a key contributor to the State of DevOps Report, will host a webcast with CA Technologies expert Aruna Ravichandran to discuss DevOps ROI and many other related topics. Register for that event today.

  • REP SPOTLIGHT: getITright

    REP SPOTLIGHT: getITright

    DevOps Institute: Tell us a little about your organization.

    getITright: With offices in Australia, South Africa, The Netherlands, Nigeria and Malta and a network of partners operating in 31 countries, we offer a bouquet of services to help organizations to:

    • Manage better
    • Lower risk
    • Perform better
    • Make better business and IT decisions

    Our service offering includes:

    • Training courses – Learning best-practice through our Partner Academy courses or network of training providers
    • Accredited IT Best practice course material – License our training material
    • Consulting – We use an agile approach for projects and a lean approach for operations when consulting and coaching.

    DevOps Institute: What other topics do you teach or consult on?

    getITright:

    • Service Management: ITIL®, ISO/IEC20000, Lean IT, Service Desk Institute
    • Governance of Enterprise IT: COBIT® 5
    • Project Management: PRINCE2®, PRINCE2® Agile, DSDM AgilePM®, Scrum
    • Information & Cyber Security Management: ISO/IEC27001, NIST Cybersecurity using COBIT5
    • Quality Management & Business Improvement: ISO9001, LEAN SIX-SIGMA
    • Risk & Continuity Management: ISO31000, ISO/IEC27005, ISO22301
    • Cloud Computing

    DevOps Institute: What type of interest in DevOps are you seeing in your region?

    getITright: DevOps awareness in the region is still low, but we see a steady increase in the level of interest in the topic.

    DevOps Institute: How do you think that DevOps contributes to the business’ value stream?

    getITright: It makes projects and business as usual faster, more stable, with less risk.

    DevOps Institute: What topic area in DevOps excites you the most?

    getITright: DevOps enables organizations to improve productivity and respond to change with less risk. It’s easy to adopt by organizations with mature ITSM practices in place.

    DevOps Institute: Why should enterprises and individuals consider formal DevOps training?

    getITright: Training ensures that all resources in the organization are in sync when implementing new practices like DevOps in an organization and ensures a cohesive approach that facilitates proper organizational buy-in and adoption.

  • On Building Self-Driving IT

    On Building Self-Driving IT

    More CIOs than ever are moving their data centers to the cloud. Some have decided to maintain their on-premises data centers and move cloud-first with all new deployments, while others are moving more aggressively to all-cloud and are retiring on-premises hardware and software as quickly as possible. Both types of enterprises also are working to automate as much as they can to not only cut costs, but also improve their user satisfaction and the productivity of their organization though higher efficiencies.

    Aater Sulemen, co-founder and CEO of Flux7, a DevOps and cloud consulting firm, is an expert in hardware architecture and performance optimization, and has spent more than 10 years working with cloud. He calls that hyper-automation “self-driving IT.” This push-button IT works much the same way many expect self-driving cars to work in the not-so-distant future: Push a button, summon a car, instruct it where you want to go and it takes you there.

    In this view, when business users wants an app, a database or even more infrastructure, they reach out and request it. They fill out a form, the system determines the proper security and governance policies that should control such systems and data, they push a button, and it’s delivered.

    And rather than IT enforcing these rules manually, developers build the right tools to enable this, enabling developers to be autonomous. As the theory goes, technology gets deployed much more quickly, and when the systems are built properly, compliance and security are improved.

    devopsy.kinsta.cloud: What does “self-driving IT” mean to you?

    Suleman: It’s about achieving successful DevOps through automation. It’s not about dictating rules, or what should be done, but making the processes associated with DevOps seamless.

    Self-driving IT means that the business does not wait for developers or operations to get things done, and they don’t wait for each other. If someone needs something, from an application, to expanded infrastructure, to test and development environments, they should be able to push a button and get it done.

    Self-Driving IT is a way of automating the repetitive events and all of the process overhead and the auditing and logging systems, when someone needs a new application or service they can just get it, and it’s ready. They don’t need to wait weeks, or longer, to provision the apps, storage, servers that they need. Just like a self-driving taxi, they call it and use it.

    devopsy.kinsta.cloud: What are some of the challenges that organizations face when moving to “self-driving IT?” themselves?

    Suleman: There are known hiccups, and there are areas companies know how to smooth very well. Typically, the hiccups within enterprises are in terms of skills necessary to essentially provision infrastructure and make infrastructure provisioning very automated. Then there are the skills needed to create the tests that need to be created, and the automation that can be done around that. We don’t see such a fundamental issue there. Usually the issue that people have is a skill-set issue—They don’t have the skills or the right mindset and place for building self-driving IT themselves.

    I think, generally, most organizations run into trouble when they have to make major changes to the infrastructure and how they will support that. There are a lot of changes that need to be made, and they may not be ready.

    In most cases, if you’re making such a major change that there is going to be a brand new infrastructure designed and built, organizations are going to need some guidance and support through that.

    Another aspect here is that the infrastructure isn’t always the highest priority. So the focus isn’t always there to automate it. But when you need a database, you need a database. There’s no getting around it. So it’s a higher priority and it actually gets done, and the underlying change to the infrastructure that needs to get done to automate doesn’t get done.

    devopsy.kinsta.cloud: Where do you see this heading in a year to 18 months? Do you see more companies moving down the path to self-driving IT?

    Suleman: That is a very interesting question. We have been having a lot of discussion around this very subject lately. There are actually two kinds of customer perspectives. There’s the, what I call, IT view of automation. So IT cares about, “I can create a server with one click, backups happen automatically and I don’t care what’s run inside the server, because to me, these are just boxes. I have 80 boxes on-premises and now I have 80 boxes in the cloud. And this is self-driven IT because I can press a button and spin up a new server.” That’s a fair definition from an IT perspective.

    This is where the continuous integration/continuous delivery and (CI/CD) becomes interesting. When you wear your DevOps hat is when you see that there’s a whole new world inside those boxes. Well, what IT likes to think as boxes. And self-driving IT now has a whole new meaning: code deploy, configuration management, patch management … the stuff that is inside the virtual machines becomes very different.

    A new class of customers has started emerging. This is as recent as early this year. They used to think of virtual machines as boxes. “I don’t know and don’t care what’s in there. What I care about is I have a box in the cloud,” they’d think. And now they have evolved to just wanting to move huge segments of their enterprise to cloud.

    We’re actually working with a lot of this right now. It’s not DevOps, because it’s automated Ops. This is a new level of discussion; this isn’t an app team moving to the cloud or modernizing. It’s CIOs calling and saying that they don’t want to build another data center, that they want 5,000 virtual machines migrated.

    devopsy.kinsta.cloud: That’s fascinating. This sounds like it’s the natural evolution of cloud and DevOps?

    Suleman: Exactly. To us, self-driving IT has been synonymous like cloud, just like DevOps is. In fact, cloud has always been means to achieve DevOps, and CI/CD and configuration management follows. Now it’s a different mindset. They’re looking for a way to not deal with the servers. So, now what is happening is, when it’s time for a refresh, they are either going to call a hardware provider and ask for 5,000 boxes, or they’re going to decide to move to the cloud. And if they have a tight deadline, like under a year or six months, they don’t have enough time to “DevOpsify” 500 applications. They end up wanting a one-to-one migration, so that they don’t have to invest in a new data center or upgrade their current data center.

    It’s a very interesting conversation, and it’s front and center with a lot of enterprises now.

  • REP SPOTLIGHT: Omnikron

    REP SPOTLIGHT: Omnikron

    DevOps Institute: Tell us a little about your organization.

    Omnikron: With over 30 years of industry experience, we have honed IT and project management training techniques to ensure that course material caters to our clients’ needs. Our training is not just lectures from a book. We offer world-class courses, assessments and simulations in a variety of formats and at various paces. As the workplace has changed in the 21st century, so has the training approach here at Omnikron.

    DevOps Institute: What other topics do you teach or consult on?

    Omnikron: Omnikron’s most popular training includes ITIL, PMP, TOGAF9, Change Management, DevOps, Security & Security Awareness and Cloud.

    DevOps Institute: What type of interest in DevOps are you seeing in your region?

    Omnikron: There is a lot of talk about DevOps and our classes are slowly but surely increasing in size. Hopefully by the end of the year, we will have a packed house for our classes.

    DevOps Institute: How do you think that DevOps contributes to the business’ value stream?

    Omnikron: We have honed in on ITIL for years and DevOps is such an easy transition for most of our students. Not only are the students enjoying the class, but they are able to use their past experience to share stories in class as well as apply what they have learned outside the class.

    DevOps Institute: What topic area in DevOps excites you the most?

    Omnikron: Organization consideration and practices seems to be the favorite among our students. Plenty of dialogue has been given around this particular topic.

    DevOps Institute: Why should enterprises and individuals consider formal DevOps training?

    Omnikron: Because DevOps is designed to help our student continually improve their services to their internal and external customers. Can’t get any better than that!