devopsy.kinsta.cloud

Category: Variable Speed DevOps

  • Mainframes and the Myth of Bimodal in DevOps

    Mainframes and the Myth of Bimodal in DevOps

    Rewind 20 years ago when we lived in a business world where big companies with unlimited resources beat out smaller, more strapped companies. The digital era—also known as the “age of the customer”—is changing all that. Where big once beat small, fast now beats slow. The DevOps approaches of startups often make them more adept at continuously delivering the innovations and conveniences that earn customer raves. Bigger, established companies often feel disadvantaged‚ shackled by an outdated culture and inflexible processes that haven’t kept up with the pace of change.

    Gartner coined the term “bimodal IT” as a way for older IT establishments to keep pace with agile startups. In the bimodal model, IT teams are separated into two distinct styles of work—one focused on supporting predictable, well-understood workloads with legacy systems and another that is more fast-moving, experimental and adaptable in meeting users’ constantly evolving demands and flourishing digital expectations.

    But the bimodal concept is not well-aligned to the spirit of innovation underlying modern application development and delivery. This is especially true for bigger organizations using mainframes. Here’s why.

    Successful DevOps Depends on Mainframe Agility

    The goal of DevOps is to roll out high-performing software and updates, ahead of the competition and with maximum speed, ease and cost-efficiency. In a DevOps model, software delivery can only happen as quickly as the slowest team. Modern web and mobile applications tend to span multiple platforms in their end-to-end transaction—from front-end web servers (systems of engagement) all the way back to mainframes (systems of record). IT places a lot of emphasis on systems of engagement, often taking back-end systems of record for granted. The reality is, the value in systems of engagement cannot be realized without the systems of record—making it essentially all one system. Developers supporting modern applications must be able to maneuver across and between all platforms, especially within mainframe code and data.

    Let’s look at a tactical example of this. According to industry research, 80 percent of the world’s corporate data—including customer data—continues to reside on mainframes. When a mobile web application is used to make a bank deposit, or purchase a product, for example, the transactional component of those applications typically is executed on back-end mainframes.

    This means mainframe applications are crucial to development efforts. What happens when mainframe developers and testers are locked into waterfall processes or don’t have the modern tools necessary to understand application logic or access mainframe data for testing? Frustration mounts and the overall innovative effort is unnecessarily stalled.

    Stability and Agility are not Mutually Exclusive

    The longstanding myth that stability and agile cannot co-exist is simply untrue. Unfortunately, it’s at the core of negative perceptions surrounding the mainframe today—people think the mainframe environment is too slow and cumbersome to support agile development. Development teams may think if they have mainframes, the only approach it can support is waterfall.

    The reality is, though, no customer will accept poor availability and performance in exchange for new features delivered quickly.  People with hands-on experience painfully understand that slow, waterfall delivery methods produce far greater quality issues and missed expectations, resulting in competitive risk. Additionally, large enterprises taking the “slow and stable” route give startups a head start in beating them to market, with offerings that customers want now.

    Alternatively, Agile process and DevOps tool chains enable scrum teams to test quality in terms of usability, function and stability early and often in the development cycle—when the time to remediate is the fastest and the cost the lowest. Agile process and DevOps tool chains build higher quality applications and enable continuous improvement in quality over time.

    Re-Platforming is not Necessarily the Answer

    Some DevOps proponents believe moving off the mainframe—to a supposedly more modern, commodity server-based distributed architecture—is the best way to circumvent perceived challenges to nimbleness and agility. But this is almost never the best answer. The mainframe retains its distinction as being the most powerful computing platform on the planet. It remains deeply embedded in large organizations, setting the standard for reliability, security and availability for mission-critical data and transactions. The new IBM z13 mainframe, for example, can handle the load of 100 Cyber Mondays every day, 365 days a year. Currently, mainframes process 30 billion business transactions per day. The post-modern mainframe is an engineering marvel unequaled as a system-of-record, business compute platform.

    The mainframe also offers cost advantages. Studies have shown that the mainframe is more cost-effective than commodity servers in handling the massive computing volume increases instigated by mobile applications. This is because decreases in commodity server pricing have not kept pace with the increase in computing volumes. In addition, leading vendors have worked together to deliver intelligent cost management on the mainframe, enabling workloads to be distributed in a way that keeps mainframe licensing costs (MLCs) down.

    In our view, “biomodal” advocates for the exact problem that must be solved. We think the answer is not replacing the mainframe, although if mainframe development is left unaddressed, this can present obstacles to DevOps. Rather, the answer is to evolve the mainframe to keep up with the pace of DevOps. There are mounting examples from large, high-performing organizations that it is possible to apply modern practices to the fullest extent, including mainframe applications. These organizations do this by giving developers the tools they need to work on mainframe code and data just as they would with any other programming language on any other platform, while meeting the escalating quality expectations of the digital age. For example:

    • Mainstreaming the Mainframe Environment – Mainframe users need to move away from the antiquated “green screen” mainframe environment, adopting state-of-the-art interfaces and tools. This is the first step enabling developers to work more fluidly on the mainframe, in an environment that’s much more familiar and comfortable to them. Organizations that fail in this adoption will have a very difficult time enabling the next generation of development talent to leverage invaluable and irreplaceable mainframe code and data. This will place a huge hindrance on DevOps success.
    • Leveraging Tools from the Java Development World – One example is visualization capabilities, which enable developers to quickly and easily identify critical interrelationships between apps and data. This helps them to sidestep unintended, undesirable impacts as they modify applications, increasing confidence and mitigating unnecessary delays.
    • Make it Easier to Identify Mainframe Code-Level Issues – Developers need tools that enable them to identify problems with mainframe code; for example, when it is the source of a widespread user performance issue, or when it is consuming too many resources and driving up costs unnecessarily.

    Conclusion

    In our view, “bimodal” is not the solution, but a broken state of disadvantaged affairs for too many organizations. From a competitive vantage point, bimodal will only hurt DevOps teams and hold back the innovative efforts of the organizations they support.

    The bimodal IT model is a road to inevitable failure for those enterprises seeking success in the digital economy. This is especially true for organizations that rely on mainframes. A smartly leveraged mainframe is an extremely valuable competitive asset that needs to be removed from its silo, evolved and smoothly integrated into modern, heterogeneous development environments.

    It is possible for big, established companies to adopt DevOps, become agile, and move as fast as startups. But the ability to think and act like a startup requires some major fundamental changes, particularly at the level of software development. The good news is, the legacy technologies that are often perceived as impediments can actually be a tremendous competitive advantage, if they are harnessed and evolved in the right manner.

    About the Author / Christopher O’Malley

    chris-omalley2Christopher O’Malley is CEO of Compuware. He has nearly 30 years of IT experience with past positions including CEO of VelociData, CEO of Nimsoft, EVP of CA’s Cloud Products & Solutions and EVP/GM of CA’s Mainframe business unit, where he led the successful transformation of that division. Connect with him on LinkedIn and Twitter.

  • Multi-Speed IT versus Bimodal IT

    Multi-Speed IT versus Bimodal IT

    I wanted to continue our revue of the recent IBM InterConnect conference in Las Vegas last month. We kicked off the revue with the release of our first videos from the show on Monday. Since then we just updated the YouTube playlist of videos available with a new batch. We will be adding to these in the coming days. For this article I wanted to zero in on a topic that I find interesting and have explored before, namely Multi-Speed IT versus Bimodal IT.

    I know that Gartner has led the way in popularizing the term Bimodal IT. Many people have adopted the term to mean that some legacy parts of the IT organization will not be able to operate at the speed of some of the newer DevOps empowered parts of the org. can work at. So it is OK for the different parts to operate at different speeds. You have in essence more than bimodal, but almost bifurcated IT.

    My problem with this scenario starts with the Bi in Bimodal. Bi signifies two, as if there were just two parts in this equation. One moves at one speed and the other moves at another speed. In real life there are more than two parts to the organization moving at different speeds. So multi-speed is much more appropriate than Bimodal.

    My problem goes beyond just comparing two to many though. I have a problem with thinking legacy systems cannot benefit from DevOps, Agile, Lean, etc.  As we have seen, even Big Iron mainframes can be made faster with DevOps. So while different parts of the IT organization can move at different speeds and will naturally do so, it doesn’t mean that legacy systems of record for instance cannot be speeded up using DevOps.

    In my view of multi-speed IT the entire organization is more like the gears in a Swiss watch. Different gears of different sizes, moving at different speeds, but all of them orchestrated to mesh together like a fine timepiece.

    This brings me back to InterConnect. I had a chance to discuss this very issue with a few people who know a thing or two about mainframes and DevOps.  Below is my conversation with Hayden Lindsey, VP of DevOps for Enterprise Systems at IBM:

    As you can see Hayden shares many of my views on this subject, but probably even goes a bit further than me calling the premise of Bimodal IT “snake oil”.

    Hayden was not the only person I spoke to at InterConnect about this subject either. I had a great conversation with Rosalind Radcliffe, distinguished engineer, enterprise systems at IBM (and one of my favorite interview subjects).  Here is what Rosalind had to say:

    While this interview covered topics other than multi-speed IT, I have also interviewed Rosalind before on this subject. Rosalind and I actually did a podcast/DevOps chat on this subject as well.  You can listen and read along to that one here.

    The multi-speed IT versus bimodal IT isn’t just something that IBM sees though. While at InterConnect I also had a chance to sit down with Ralph Van Beek of Rabobank. A Netherlands based bank with operations throughout the world.

    Ralph tells us of Rabobank’s DevOps journey in which multi-speed IT plays a big role.

    If all of this multi-speed IT versus bimodal IT is not enough for you, we also did a good Google Hangout on this same issue prior to IBM InterConnect 2016. Finally, Sanjeev Sharma, author of DevOps for Dummies, wrote a good piece on this subject right here on devopsy.kinsta.cloud that you might find very useful if you are as interested in this subject as I am.

    So that should be enough on this subject to satisfy just about everyone. But if you have something to add to this topic please leave a comment or submit your own article to me here at editor@devops.com.

  • The Art of DevOps

    The Art of DevOps

    This is the third in a series of posts on DevOps. The first written by my colleague Lee Reid was titled The Simple Math of DevOps. The second The Calculus of DevOps was written by IBM client, and my friend Carmen DeArdo of Nationwide. Lee introduced mathematically improving delivery throughput by leveraging DevOps to improve Trust. And Carmen used Calculus to imply that the business value of IT can be improved by adopting DevOps to increase the frequency of releases. In my post I would like to visit the art of DevOps , or the art of adopting DevOps by picking up right where Carmen left off – by looking at the culture side of adopting DevOps.

    Lee and Carmen have already alluded to some basic premises behind DevOps as an approach – reducing batch sizeand improving collaboration. These result in reducing complexity, increasing throughput, and improving trust. Let’s talk about how to get there.

    As I have worked with customers adopting DevOps, across company sizes, across industries and countries, there are four common threads that make DevOps adoption successful, leveraging all three aspects of DevOps adoption – culture, process and automation. These are:

    1. Reduce batch size: The most effective way to manage risk and quality, while increasing speed is to reduce the batch size in each iteration or ‘sprint’. This is a mind shift to release smaller, more frequent new versions. Where it is not possible to release new versions that frequently to customers, release small batches to a pre-production area. The deliverable in pre-production is tested and made customer-ready, and then released to the customer at formal release dates. As Lee and Carmen have both discussed, reducing batch size is a pre-requisite to improving both trust and business value.
    2. Shift-left Operational engagement: Get operations engaged right from the beginning of a project/initiative. This has been a core principle of DevOps. Do not leave Ops in a silo that one throws code over the wall to, but have them engaged in the development process, right from requirement inception stage. This allows Ops to have visibility into what is coming from Dev; allowing them to deliver the right production-like environments, as and when needed to Dev and Test teams. It also allows Ops to shift operational concerns left, left into the minds of developers, making them more Ops conscious and engaged in what happens after they hand-off to Ops.
    3. Continuous funding: This is a significant change in an organizations funding model to enable continuous availability and engagement of SMEs and business functions, previously not engaged on a continuous basis – like security, legal, marketing, etc. Carmen in his post mentioned several examples of ‘waiting for…’ work, someone else to do something and environments. Another ‘waiting for’ in enterprises is for funding. Funding is typically provided in a waterfall manner, with specific hard dates (Months, quarters, fiscal year) and gates, not suitable for a Continuous Delivery model. Funding too should be continuous.
    4. Create a ‘Product Management’ team: This team includes a Designer, Development lead, operations lead and an Architect at the minimum (4-in-box). They own the ‘product’ through its entire lifecycle, and beyond transient projects. They are responsible for long-term thinking, design thinking, evolutionary architectural thinking, and overall ownership of the product, from concept to end-of-life.
    5. Setting up a DevOps Center of Excellence (CoE): This center of excellence is not an administrative organization or a ‘tools/enablement group’, but a place where DevOps adoptees come to learn from each other and share expertise and lessons learnt. As organizations adopt and scale DevOps adoption, this CoE also becomes a source of DevOps coaches, helping teams and programs adopt DevOps, and own the organizations DevOps framework – their own flavor of DevOps.

    Adopting DevOps is an art. It is not as simple as hiring a consultant who can show how to improve processes; it is not just buying and adopting tools to automate manual tasks; and it is not going through ‘fall-back-into-the-arms-of-the-person-behind-you’ exercises to build trust. It is a combination of all three – process improvement, organizational and cultural change, and automation with tools to replace manual processes. Adopting these in any enterprise, outside of startups, requires overcoming organizational inertia. By changing culture not by edict, but by showing the need and value of change. By building trust, not through meetings, but with improved communication and transparency. By improving business value, not by measuring mandated KPIs, but by improving organizational agility and throughput. Overcoming organizational inertia, by delivering towards a common goal for the business, irrespective of where in the organization one is, and what role one has. By developing a culture where everyone takes responsibility of delivering value to the business.

    Watch the webcast series hosted by devopsy.kinsta.cloud in partnership with IBM or download a copy of DevOps for Dummies book for more information.

    About the Author/ Sanjeev Sharma

    SanjeevSanjeev Sharma, CTO and Distinguished Engineer – DevOps Technical Sales and Adoption, IBM Cloud Unit, is a 20-year veteran of the software industry with expertise in DevOps, Mobile Development and UX, Lean and Agile Transformation, Application Lifecycle Management and Software Supply Chains. He is a DevOps Thought Leader at IBM and speaks regularly at conferences. He has written several papers and is the author of the DevOps for Dummies book.

     

    Contact Sanjeev on linkedintwitter

  • The Calculus of DevOps

    The Calculus of DevOps

    This is the second in a series of blogs, partnering with Lee Reid, who wrote the first installment “The Simple Math of DevOps” and Sanjeev Sharma both of who are outstanding DevOps Thought Leaders from IBM.

    I am picking up on Lee’s mathematical DevOps model to apply a calculus perspective, a “calculus of DevOps” if you will, (OK, not quite core Big Bang Theory Calculus but rather approaching it from the aspects of engineering queuing theory).

    One of the cultural challenges that DevOps poses is, that some aspects of it run counter to engineering principles that many of us learned with respect to capacity and response time.   When I worked at Bell Labs, we would apply queuing theory to determine how to best package information to be sent across the network. A basic premise revolved around a tradeoff between throughput and response time. On one hand, the more messages that were packed into the packet, the more the payload would improve capacity because the overhead of processing the packet of information would be spread across the messages.   However, waiting to accumulate enough call processing information meant that the packets would be transmitted less frequently, increasing the response time.

    A simple example of this would be making trips to the grocery store. If one wanted to spend the least amount of resources (time, gas, car wear, etc.) on shopping, then one would make less frequent trips and then buy a larger amount of food. So if the Smith family made one trip a month and spent 2 hours, then their average time per week spent on shopping would be 30 minutes.   If the Jones family went every week and spent an hour, then they would be spending twice the time and four times the gas on grocery shopping. However if the Smith family run out of an item (say cereal), they would have to wait, on average 2 weeks before this was replenished. The Jones family average on any item that they ran out of would be 3.5 days in comparison.

    So when the 2014 DevOps report was published[1] which states that areas that deploy more frequently get customer feedback more quickly, that is to be expected. But what’s not expected is that these organizations also have higher productivity.   So exactly what is happening here that seems to be in a basic conflict to the principles of throughput and response time?

    Keeping up with the JONESES

    If we think of a pre- DevOps state for a medium to large enterprise, it may be typical for applications to only be released (deployed into production) a few times a year to provide business functionality. (I assume there are more frequent releases for “unplanned work” like defects and other changes or operational work). For the sake of this discussion, let’s call this the Smith Application. So from a business perspective, the business wants to pack as much work into the Smith releases as possible given they only have a few cracks a year at getting new business functionality into production.

    SMITH APPLICATION CHARACTERISTICS:

    • Deliver Business Value 3 times a year (every 4 months)
    • Cost is C1
    • Business Value (BV) delivered is V1
    • Average time from concept (e.g. Story) being ready to be pulled from the backlog to the time it is delivered to the customer is 2 months plus any additional wait times (e.g. prioritization)
    • BV delivered per year is 3*V1
    • Cost per year is 3*C1

    Now let’s transport over to the Jones Planet where the application is released into production with new business capabilities at the end of every 2 week iteration.   In this case the business is more concerned with providing a constant demand flow into IT than they are with debating over whether a given feature/story is going to be included in this particular release.   Instead there is a constant prioritization (or continuous planning) process that ensures the highest value work is being fed into the IT pipeline.

    JONES APPLICATION CHARACTERISTICS:

    • Deliver Business Value 26 times a year (every 2 weeks)
    • Cost is C2
    • BV delivered is V2
    • Average time from concept (e.g. Story) being ready to be pulled from the backlog to the time it is delivered to the customer is 1 week plus any additional wait times
    • BV delivered per year is 26*V2
    • Cost per year is 26*C2

    Based on the previous engineering analysis, we would expect the following:

    1. SMITH annual cost (3C1) < JONES Annual Cost (26C2)
    2. SMITH annual BV (3V1) > JONES annual BV (26V2)

    So the tradeoff (we would believe) JONES is making by delivering more frequently is that they are spending more money and are delivering less business value on an annual basis.

    However the data from the previously referenced DevOps report is just the opposite. In fact the findings are that enterprises that deploy smaller units of work more frequently have much higher quality and much higher productivity (Capacity). So what’s going on here?

    A NEW PARADIGM

    If you go up to any IT team (even an agile one) and ask them why they don’t deploy business value more frequently, they will generally refer to the following types of wait states of waste that they encounter:

    • Waiting for work (lack of consistent flow)
    • Waiting for somebody else to do something (dependencies from other teams)
    • Waiting for environments (contention)

    One major root cause of this is the dependencies that arise from large enterprises packing a lot of work into infrequent releases. From a planning perspective, the process is elongated due to prioritization discussions because being on the wrong side of the line can mean delay amounting to months, in delivering a product to a customer.   Ask a business portfolio leader what their highest priority is for IT and I am guessing they can tell you in a matter of seconds. However, most large organizations can spend several months a year planning their annual portfolio of work for IT. Some organizations spend more than 50% of their new project build time prior to a single story entering an agile development team’s backlog!

    From a development perspective, packing a lot of work into releases means many more dependencies that have to be managed across initiatives and impacted applications. From a testing perspective, downstream environments (ST, UAT) have to manage much more information in terms of application versions and especially test data that complicate and slow down the process. The complexity of test data increase is proportional to the number of pairwise relationships that exist within the datasets required for testing.   As such, the testing complexity will increase non-linearly (perhaps proportional to the square of the dependent systems) and from a release and change perspective; there is a lot of coordination necessary given how much is being changed at one time.

    All of this work to manage all of the dependencies found in medium to large enterprises completely eliminates any potential savings one might get from batching work into a single delivery. In addition, the possibility of having to pull some work out of a release (due to quality or business readiness or some other reason) sometimes leads to complicated source code management (feature branches in some cases) that further complicate the process of merging frequently into the trunk. These types of practices also serve to drive up technical debt. So looking at the problem from this angle shows why results we are seeing make perfect sense.

    Productivity is inversely proportional to the number of dependencies in a release

    As Lee related to in the initial blog, a lot of an organization’s success depends on trust. And one factor of trust is clarity which speaks to understanding the changes that each release is bringing to the IT and customer environments. So a factor that is working against trust is the notion of delivering more things less frequently and better controlling change somehow, is a good notion.

    Trust is inversely proportional to the number of dependencies in a release

    There is another hidden component of waste associated with “big bang” initiatives. Go back to our grocery example for a moment. Chances are that the Smith monthly excursion results in buying some stuff they end up not using. Perishable items are not spread out very well when they aren’t purchased more frequently. Likewise in IT planning, we tend to put a bunch of stuff in our IT Delivery basket that we don’t know for sure that we will need and we end up with a lot of wasted effort for features that are hardly used or not needed at all. Some enterprise estimates are that 50-65% of what they put into large releases does not actually result in true value to the business. Doing more frequent releases allows a constant discovery process to better guide the usage of IT resources on what is truly of value.

    Waste is proportional to the size of a release.  

    In other words:

    Yield (Value per IT investment) is proportional to the frequency of releases.

    REVISTING THE MATH OF DELIVERY TIME

    So if we revisit Lee’s model

    Lee Reid Blog equationand apply the “Calculus of Release” as we stated above, there are increased costs associated with having larger and less frequent releases in medium/large enterprises.

    • Planning cost TPLAN
    • Development complexity TDESIGN + TDEVELOP + TBUILD
    • Testing Complexity TTEST
    • Release and Change Management Complexity TRELEASE + TDEPLOY + TEVALUATE

    TRUST % – Even if everything was proportional between the JONES and SMITH models, the component of trust that impacts clarity, consistency and collaboration, is much lower for large (SMITH) releases.  Given that TRUST has a multiplicative impact, this alone can account for the results found in the studies.

    CULTURAL CHALLENGE

    While clearly one needs to be sensitive to the changes being introduced into the business, having the ability for the business stakeholders to pull capability when they want it and having it available more frequently is not only good for customers but also has extreme benefits from an IT perspective in terms of increased productivity and reduction of technical debt. The challenge is to convince leaders in both the business and IT areas on the merits of doing more continuous planning and frequent deliveries.   Unicorns may have led the way in this type of thinking but it is actually the horses that will benefit most from this type of culture shift because it is the horses[2] that have the most to gain in mitigating the dependency factor which can undermine quality, productivity and cycle times.

    Read more about the topic in the next blog of this series The Art of DevOps by Sanjeev Sharma.

    [1] “2014 State of DevOps Reports”, Puppet Labs, IT Revolution, https://puppetlabs.com/sites/default/files/2014-state-of-devops-report.pdf

    [2] “The Phoenix Project”, Gene Kim, Kevin Behr, George Spafford, http://www.amazon.com/The-Phoenix-Project-Helping-Business/dp/0988262592

     

    About the Author

    CarmenCarmen DeArdo is the Director of Application Development Tools and Technologies at Nationwide Insurance. Carmen is responsible for driving continuous delivery utilizing DevOps, Lean and Agile techniques across Mobile, Distributed and Mainframe and other technologies. This includes recommendations and implementation of technologies used across the development life cycle (e.g. IBM Rational tool suite, open source technologies).

  • “Show Me The Money!” – Delivering DevOps Value

    “Show Me The Money!” – Delivering DevOps Value

    HM Heath Solutions delivers new business applications in the healthcare industry to 35 million customers.  In order to embark on their DevOps journey to improve software delivery, Valerie Scott, their Manager of Shared Services Division, had to show senior management an ROI on a successful project, before they would invest fully. On June 2, Val Scott along with Rick Slade of IBM joined Alan Shimel of devopsy.kinsta.cloud in a webcast to discuss this interesting client case study.  During their discussion, they illustrated in vivid detail how HM Health Solutions showed success in DevOps to their senior executives, for them to buy in and sponsor the project.

    Val and Rick’s webinar parallels many similar discussions I’ve had with senior executives.  To net it out, the bottom line is, as it was so clearly and unequivocally articulated in this amusing clip from the movie Jerry Maguire: “Show Me The Money!”

    cuba gooding jr show me the money jerry maguire tom cruise show me the money jerry maguire
    When I meet with senior LOB, Finance or IT executives — they shout a similar refrain:

    “All I want to do is buy a business outcome.  I want to invest in an IT project, and have it pay back.  Unfortunately for many application development (or other types of enterprise IT) projects, that pay back is illusory, and ROI difficult to measure.”

    — Jane or John Executive, representing nearly every IT executive or CFO I have ever met

    Unfortunately, many struggle to quantify, monetize and demonstrate the financial return on investing in IT projects.  Yet as described in this blog, it is the primary responsibility and outcome of management; leading the economic performance of their department or unit.  Show me the money!  Fortunately, many clients experience positive returns, both operationally and economically.  Ten (with links to more) client case studies with returns are highlighted in this blog, and summarized on this page.

    As you undoubtedly have experienced yourself, senior executives respond to clear business value and benefits articulated as financial returns, as ROI.  But how do you do that for DevOps, a set of technical practices and associated culture change?  As Val and Rick described during their informative webcast, comparing productivity, time-to-market, speed of delivery, and quality, both before and after a DevOps pilot, are crucial.  These operational metrics will be improved by adopting DevOps.  However, to win the hearts and minds of senior executives, you have to monetize the results, in other words – show them the money!  Technical techniques and practices such as those Val and Rick described to Alan, shifting left, test driven development, and automating application build, deployment, and test are absolutely necessary, but they are insufficient to win the argument with senior executives.  The gains they produce are necessary, and impressive.  The operational results have been stellar thus far at HM Health Solutions, per Val:

    • a 67% reduction in resource demands on the release team & process,
    • a 75% reduction in relative hours to repair defects per environment,
    • an 82% reduction in application deployment time.

    Yet as impressive as these operational results are, they are insufficient.  As Val described, arguments about business value, technical value, or improvements to developer or operations staff productivity, alone did not persuade the management.  The magic word is an economic and financial one: “investment”.  Making a strategic investment to improve delivery speed and quality of business applications was the key to winning the hearts and minds of the senior executives.

    In addition to the technical practices described above, Alan asked Val to describe the tools HM Health Solutions adopted.  A continuous delivery solution with application release automation software from IBM UrbanCode was implemented, including application build, deploy, and release.

    As a way of summarizing the webcast for the audience, Alan asked Rick and Val for their two key takeaways; the two most important messages and things to remember.  Rick’s:

    1. Knowing which metrics are critical to your organization.  There are many benefits to adopting DevOps, and many potential hard numbers that are straightforward to capture and measure.  Deciding which metrics have the most impact and are most persuasive to your stakeholders is critical to making the case to invest in DevOps.
    2. Implementing tools and automation: automated testing, and linking that to build and deployment processes and automation.

    Val’s:  Rick’s two takeaways of course!   And one more…

    1. DevOps is new in the industry, and is not yet well understood or common practice in enterprise IT or among its leaders.  Understand your audience, and become good at explaining it in straightforward and clear business and financial terms to senior executives.  Especially persuasive are other client proof points, and the results of pilots in your own enterprise IT environment.  Make sure pilot results show that the solution works and delivers timely business value, and that the related facts and metrics clearly quantify the results.

    Read this blog to know more and Check out other customer proof points/ case studies

    This was a very informative, fast paced, and information rich webcast.  I hope that you find the replay useful in continuing your DevOps adoption journey.

    If you’d like to explore more about management responsibilities and know-how for establishing an ROI for DevOps and app release & deployment automation, see this ROI web page, and read this ROI blog for additional resources on method, approach, making the case, and calculating the ROI.  And please don’t hesitate to reach out to me on twitter: @paspung.

    I look forward to hearing your success stories in making the ROI case to senior executives, and delivering DevOps value to your organization!

    peter signature, small

    Peter Spung, DevOps Deploy and UrbanCode Integration Executuve, IBM Cloud, @paspung

  • Bimodal IT and Remodeling Traditional IT for Greater Agility

    Bimodal IT and Remodeling Traditional IT for Greater Agility

    Bimodal IT is a Gartner concept created to help CIO’s understand that IT organizations need to support both traditional and agile modes of IT solution delivery and operation in order to make wise choices about infrastructure, process, people, and tools.  Much attention has been given and rightfully so to the disruptive and innovative “Mode 2” teams building on the practices established by web-scale giants like Amazon, and Google.  However, in enterprises there still exists a sprawling majority of “Mode 1”, traditional, industrialized applications run by teams that must focus on risk aversion, security and compliance.  While these will likely not match the innovative velocity of agile IT teams and applications, traditional IT teams are still under pressure to get faster, more agile, innovative, productive and cost-efficient.  Yet, the Mode 2 playbook can’t be applied wholesale to Mode 1 transformation work because it often assumes a greenfield situation—kind of like a new home construction.  By contrast, Mode 1 modernization is more like renovating an existing home that must proceed in steps that address the present realities of applications, legacy infrastructure, business mandates, organizational interactions, and technical skills.

    Understanding Bimodal IT

    The Bimodal IT concepts is meant to distinguish between applications and teams that are traditional in their focus, and those that are agile.  In her blog post on Bimodal IT, Gartner analyst Lydia Leong explains Bimodal IT thusly:

    “Traditional IT is focused on “doing IT right”, with a strong emphasis on efficiency and safety, approval-based governance and price-for-performance. Agile IT is focused on “doing IT fast”, supporting prototyping and iterative development, rapid delivery, continuous and process-based governance, and value to the business (being business-centric and close to the customer).”

    The reason that Gartner promotes the idea of Bimodal IT to CIO’s is to help them see that it can be dangerous trying to optimize processes, human resources, infrastructure, and tools to cover such different modes, and as a result, optimizing to neither.  Rather, the right move according Gartner is to allow agile teams room to develop a brand new set of capabilities that can then help transform the whole organization. Lydia continues in her blog:

    “We’ve found that organizations are most successful when they have two modes of IT — with different people, processes, and tools supporting each. You can make traditional IT more agile — but you cannot simply add a little agility to it to get full-on agile IT. Rather, that requires fundamental transformation. At some point in time, the agile IT mode becomes strategic and begins to modernize and transform the rest of IT, but it’s actually good to allow the agile-mode team to discover transformative new approaches without being burdened by the existing legacy.”

    The Contrast Between Agile and Traditional IT

    Traditional IT and Agile IT are different in a number of ways.  Perhaps an effective way to explain the difference is to picture what these applications and teams look like.

    The classic agile IT initiative in the enterprise is around a mobile, e-commerce or web-centric application that is aimed at moving into new markets, improving engagement with new customer segments, or disrupting a current market.  The application is fully virtualized, and the preferred infrastructure is a public cloud such as AWS.  The team is conceived as a unified, DevOps team of line of business product managers, developers, testers, and operations folks working collaboratively on an agile development methodology. Automation is built deeply into the process, with infrastructure as code tools used to manage public cloud virtual machines and related infrastructure components via well-documented RESTful API’s, plus other DevOps toolchain elements automating and managing most processes, including continuous integration, continuous delivery and continuous deployment of code into production.

    Traditional IT stands in pretty stark contrast.  Let’s consider an industrialized, mission-critical application that has evolved slowly for years.  The application (which is usually composed of anywhere from 5 to 10 or more components) is likely running on a mix of legacy (think RISC UNIX), dedicated (x86-based) and virtualized servers (VMWare and perhaps Hyper-V) running in a private or hosted private datacenter, using a mix of traditional and software-defined storage and connected by Ethernet and Fibrechannel switches.  The application components themselves may be legacy code, making them difficult to quickly port to more modern infrastructure.  For example, I was talking recently with a colleague who told me about his sister who still writes code in Fortran for a major bank.    With such a large, complex, long-lived and mission-critical application suite, the IT organization maintaining it and the developers creating updates and upgrades are highly concerned with quality, reliability and predictable performance.  The nature of the overall team working on an industrialized application is a far cry from the sort of “two pizza” DevOps teams on the agile IT side.  Rather, it’s more of a loose consortium of teams such as developers, testers, security and compliance, plus outsourced contractors and vendors.  The development process is waterfall-based, managed by an application lifecycle management (ALM) suite of some sort.   Automation is scant, and in particular it takes a long time to pull together infrastructure for those dev, test and other teams to perform their jobs.  Despite that, a production-like environment for testing, security, compliance, etc. is considered necessary to minimize downtime and other quality risks.  As a result, release cycles can stretch into many months.

    Modernizing Traditional IT

    When my wife and I remodeled our 1908 Craftsman-style house about 15 years ago, we discovered that an earlier renovation had actually cut out a third of a key supporting beam, leaving one part of the house literally hanging on a beam that was only attached to one side of the house.  Needless to say, we were a bit alarmed to find that out.  When dealing with mission-critical applications and infrastructure, you can’t be careless.  As mentioned earlier, simply taking the playbook for a greenfield, agile IT application and trying to apply wholesale it to a legacy, industrialized application usually won’t work.  Making traditional IT more agile requires a step-wise renovation—a risk-mitigated path that leads towards agile and DevOps practices, but without a great leap into the dark.  The steps need to establish the building blocks to agile/DevOps practice without disrupting the application, without introducing downtime, and while delivering solid returns along the way.  Successful legacy application and service ‘remodeling’ efforts observed in highly traditional organizations such as telecommunications and cable operators provides good ideas on how to take those steps:

    • Identify or Procure Automation Skills:  The initial steps to remodeling Traditional IT are about incrementally improving current practice with automation and at the same time making it ready for agile and DevOps.  This means that to be successful, you need to get some automation skills into the mix.  A team that can’t take hold of its own destiny in modernizing a Traditional IT application is not going to have a sustainable change, and that means identifying or procuring some automation expertise and protecting that person’s time to focus on the renovation rather than on firefighting.
    • Private Cloud IaaS:  One of the most serious obstacles to agility is the painful amount of time and effort it takes to allocate and provision infrastructure for developers, testers, etc. and the lack of standardized, consistent infrastructure environments, due to manual processes.  This is exactly the issue that drives some development teams to go shadow IT and start developing on AWS.  Often times, these development teams then discover that integrating that software into the production environment is plagued with translation issues.  Nonetheless, the first order of business then is for the infrastructure team to establish IaaS that can serve up full production-like infrastructure environments to devs, testers and other constituents.  This isn’t trivial when you’re dealing with a combination of legacy servers, bare metal x86, VMs, and perhaps networking, security and other devices.

    The IaaS delivers a number of key improvements.  First of all, it speeds up access because developers, security, compliance and other personnel can now get access to infrastructure in the space of minutes rather than the space of days or weeks.  More than just speed, IaaS enables asynchronous productivity by various teams to happen 24×7, so that quality progresses in an even fashion, unimpeded by office hours.  This is especially helpful if there are global teams, contractors or vendors involved.  IaaS also provides standardization and consistency across all efforts.  Finally, IaaS saves costs.  Significant amounts of operations personnel time that was devoted to painstaking manual infrastructure assembly can be repurposed to higher value activities, and infrastructure utilization rates can easily double or triple almost immediately, which reduces the need to purchase more capital equipment.

    A word here about GUI’s.  One of the key notes of dissonance that often occurs is when people hear developers say that they don’t want GUI’s, they want API’s.  That in my view is absolutely valid, but more so for Mode 2 Agile IT teams.  It turns out that IaaS GUI portals can be rather helpful in providing an easily understood reference point to multiple teams that may have highly varying understandings of the end-to-end picture of the application and its infrastructure.  For example, if an IaaS self-service portal provides a full visualization of the end-to-end infrastructure involved, a developer who might assume that latency is always near zero might become more aware that there is a WAN in the middle of the end-to-end infrastructure.

    • Test as a Service:  Many development and testing teams have taken some stab at test automation.  However, test automation tends to live and be maintained at the individual level.  The natural follow-on to IaaS is to build a standardized regression or certification of automated tests that can be offered from the IaaS portal—test as a service (TaaS).  This allows teams to access production like environments, do their development work, then easily launch a comprehensive certification test.  Tests naturally should report their results into the ALM tool so that individuals and teams can review results in near real-time to keep the process moving.  The benefits are similar to IaaS:  increased velocity, standardization, productivity and efficiency.
    • DevOps Evolution:  With a combination of IaaS and TaaS, the stage is now set to deploy a DevOps toolchain and start doing cross-functional technical collaboration, and agile methodologies.  For example, the IaaS and TaaS can be launched by a unified continuous integration server upon software development check-ins from any team.  Of course, DevOps doesn’t just mean tools and automation, but the process of coming around collaborative devtest infrastructure and common certification tests to build a common, agile development practice is one of the steps towards a more broadly responsive cycle.

    Conclusion:

    Traditional IT may not be the sexiest beast in the technology forest, but it’s often mission-critical.  Gartner’s Bimodal IT concept encourages CIO’s to let go and let Mode 2 Agile IT teams do their thing to create new culture and practices.  Translating that to Traditional IT requires a more step-wise approach.  Progressing from manual processes to IaaS to systematized, self-service test automation as the foundation for DevOps evolution is a sound way to proceed.  With these steps. Traditional IT can “do IT right” and do IT faster.

    About the Author/ Alex Henthorn-Iwane

    AlexAlex Henthorn-Iwane joined QualiSystems in February 2013 and is responsible for worldwide marketing and public relations. Prior to joining QualiSystems, Alex was vice president of marketing at Packet Design, Inc., a provider of network management software, and has 20+ years of experience in senior management, marketing, and technical roles at networking and security startups.

    Through his roles at QualiSystems, Packet Design, CoSine Communications, Corona Networks and Lucent Technologies he has acquired expertise in cloud computing and the opportunities presented through virtualization. He has written for Embedded Computing, Virtual Strategy Magazine, Datamation, SDN Central, Datacenter Knowledge and InformationWeek.

    Connect with him on LinkedIn, Twitter, or SlideShare.

  • The Simple Math of DevOps

    The Simple Math of DevOps

    We are living in an information- infused society, much dependent on various technological innovations taking place all around us. In such conditions, as consumers become more connected, they are empowered with more information and choices. They expect quick and consistent information available at all times. Likewise, our business leaders expect their IT teams to build relevant applications and stay ahead of their customers’ needs with an excellent customer experience.

    My IBM colleagues and I have been working very closely with major enterprise clients as they begin their DevOps transformational efforts. We’ve found few key points and messages that resonate very well with decision makers who need to set a new course for their teams in the wake of impact from mobile, big data, analytics, cloud, and the Internet of Things technologies.

    So what is it about DevOps that is so appealing? First and foremost is the notion that DevOps is all about attaining Speed to Value. Speed is king right now because so many of the business leaders we work with are under the gun to deliver value as quickly as possible. Yet, because of the high cost of technical debt they have come to a state where speed has to be sustainable. It’s no longer easiest to go outside their organizations for the high priority key projects as mobile applications were done recently. They need a holistic approach that builds on their existing capabilities.

    Well what does that have to do with math? Here’s the thing, everyone is trying to minimize the time it takes to deliver value and attain feedback.   We can think of the Time to delivery as the following equation.

    TDELIVERY = TPLAN + TDESIGN + TDEVELOP + TBUILD + TDEPLOY + TTEST + TFIX + TRELEASE + TEVALUATE

    In an optimal world or software factory that is fully automated the TDELIVERY is optimized by minimizing the time for each of the tasks required to complete the delivery. Most organizations follow a SDLC that is based on this simple math. They estimate the time to do each part and then the total project plan is the sum of the parts. Further, they tend to define work in relatively large chunks or big-up-front style of work definition which inherently increases the time for each task (TX). As a result, the industry has about a 50% (or worse) failure rate when it comes to completing a project within the estimated time. That causes a lot of hardship because the business can’t count on IT to deliver value to customers in the projected time frames let alone with speed.

    Because application delivery is a set of very human oriented tasks, a key factor that will determine the speed to value is TRUST. It’s pretty obvious when you draw out the value stream mapping of how work gets done at a given customer site. As members of software delivery teams lose trust in the validity of the work as it flows through the lifecycle then a large amount of rework and waste is introduced. In mathematical terms our equation becomes:

     

    Lee Reid Blog equation

    That is, the Tasks we do in a delivery cycle are impacted by the degree of trust we have in the hand-offs from one to another. If we have zero trust then our TDELIVERY will be infinite (divide by zero). 100% trust and our TDELIVERY will be only limited by how fast each task can be performed.

    Check this scenario that represents what we’re hearing from our clients in the workshops:

    “On a given project team the plan has about a 50/50 chance of being right, and the design is about 85% right, and the developers will get about 90% of the implementation right, and the testers have about 90% of the test cases right, and the release team has about 95% reliability of having the right stuff together to release, then your trust factor is something like

    .5 x .85 x .9 x .9 x .95 = 32% Trust”   (and that’s much better than what we usually hear)

    Ouch! That’s a 3x multiplier of the time it’s going to take no matter how fast we do all the delivery tasks.   In other words, we’re always limited by our trust factor. That multiplier comes into play with additional tasks we have to add into the equation to counterbalance the lack of trust. Then our equation becomes something like this:

    TDELIVERY = TPLAN + TRESCOPE + TDESIGN + TARCH REVIEW + TDEVELOP + TTECH DEBT + TBUILD + TREBUILD + TDEPLOY + TREWORK + TTEST + TRETEST + TFIX + TREFIX + TRELEASE + TROLLBACK + TRE-RELEASE + TEVALUATE

    And that’s the issue our customers are facing today. There are a lot of wasteful tasks, checks, and balances that have crept into our delivery process due to lack of trust.

    So, how does DevOps help this problem? It’s simple really; the DevOps approach is to attack the TRUST issue head on while simultaneously reduce the task time (Tx) in order to shorten the overall time to delivery. For example, if we apply a DevOps practice of breaking work up into small chunks, getting it out to users early, and getting the feedback, we can immediately impact the overall TDELIVERY. That’s because we’re positively impacting the numerator and denominator with that practice. That is, by limiting the scope we make it easier to understand, less effort to transform to working code, test, and deploy, sooner to obtain feedback, and more likely to know if we’re on the right track.

    Likewise for other practices!

    The key is finding the balance of what practices to apply to maximize this equation for a given organization and their current bottlenecks & wastes.

    DevOps practices address with three main impact points:

    Speed to Value depends upon TRUST

    TRUST is enabled by:

    1. Clarity: A clear definition of desired outcome(s)
    2. Collaboration: Team-wide communication and visibility
    3. Consistency: Systematic and repeatable steps

    When a team can master these three elements the time to perform each task will shrink and degree of TRUST will increase. DevOps practices impact these trust building elements:

    Clarity:

    • Break work up into smaller chunks and iterate
    • Seek a minimum viable product (MVP)
    • Define clear outcomes, ‘sponsor’ users, and playback (Design Thinking)
    • Reduce dependencies with loosely coupled architectures (containers, micro services, SOA)

    Collaboration:

    • Form cross functional teams (end to end)
    • Use big visual radiators
    • Have a ‘single source of truth’ for all development assets – Requirements, Code, Deployable Assets, Infrastructure as Code, etc
    • Be transparent with metrics
    • Plan and reprioritize frequently
    • Actively seek user feedback

    Consistency

    • Automate, automate, automate
    • Continually improve by replacing manual tasks with automation

     

    Speed to Value will be enabled by eliminating those bottlenecks and waste that have developed due to lack of trust. The key for organizations is to recognize that the current practices are maxed out and not sustainable when trying to move at higher speed. There’s a perfect storm amassing with big data, analytics, cloud, mobile and IOT that will either drive customers to make a DevOps transformation quickly or be a victim of the storm. Try using this simple math to help organizations understand how to move ahead and how our IBM solutions can be applied to attain speed to value.

    This year I have had the great experience to work with our DevOps CTO Sanjeev Sharma, our customer thought leaders such as Carmen DeArdo of Nationwide, and our field teams around the world addressing DevOps transformations. Sanjeev, Carmen and I decided to summarize our experiences in a three part blog. This is the first of that three part series.

    To learn more about IBM’s DevOps approach, check out www.ibm.com/devops. Also, watch the replay of a recent webcast on Variable Speed DevOps, I had a chance to present on, with Sanjeev Sharma and Carmen DeArdo.

    About the Author/ Lee Reid

    Lee ReidLee Reid, Senior IT Specialist, IBM, is a senior solution architect with focus on practical adoption of software engineering tools, software delivery solutions, application life cycle management, and DevOps. He has over 25 years of experience in software engineering, design, programming, testing, development, tools & methodology, team leadership, and strategic planning.

  • Follow the Unicorn: Transform your Enterprise Applications

    Follow the Unicorn: Transform your Enterprise Applications

    For those of us that work on Enterprise Systems such as the mainframe, the claims that the Unicorns (1) make, can be pretty astounding. Dozens and sometimes hundreds of releases a day from big companies like Netflix (2) and Etsy (3) are hard to comprehend. But look a little closer and you can see that the key difference is in the way changes are released to customers, not so much the total volume of changes. A traditional enterprise application may have thousands of changes made over the course of 3 to 6 months, but all of those changes are released at once. The Unicorns are typically able to release a very small number of changes at a time because they can develop, build, test, and deploy these changes very efficiently. Small batch releases to customers has significant value. It enables you to get feedback very quickly, and it is significantly easier to verify because the change is not mixed in with other changes.

    So how can you transform your development environment to deliver small batch of changes? I like to tackle the problem like any other computer science problem, no doubt because of my background. Break the large problem into a set of smaller problems and then solve those smaller, less daunting problems:

    Step 0: Start with a Proof of Concept

    Pick a Proof of Concept (PoC) to begin with that is important, but not mission critical. The PoC can be used as a learning ground and hopefully as a template for subsequent PoC’s. Make sure you have a team that culturally is willing to transform. Often the hardest issues to tackle have nothing to do with technology, but are cultural.

    Step 1: Understand your Application

    You need to have a good understanding of what your application consists of. Not only does the source code make up the application, but what source files are used, what the middleware configuration might be, what scripts you may have to build and deploy the application, and what data files (e.g. flat files, databases) that you use are also important. Some of these components may be shared with other applications, so you need to understand those dependencies as well. Once you have a good handle on the application, you can then automate the application build and deployment process so that all members of the team can work efficiently.

    Step 2: Understand your test cases

    If you can build and deploy the application quickly but it still takes days or weeks to test, then testing prevents you from delivering to your clients. An important shift for testing needs to be from testing the entire application to testing the change. You need to focus on running the right tests to ensure the change is correct and causes no regressions. Tests that do not exercise the code change are irrelevant and can be skipped. For many existing applications, the test suites may consist of hundreds if not thousands of test cases. Many of those test cases may be duplicates or testing areas of the code that are not being changed.

    Step 3: Understand your processes

    How fast can you get your updates to your customer? If your bug fixes and enhancements have to sit on the shelf for days, weeks or months before the customer gets them, they will not be satisfied. Streamline not only the development processes but the operations processes in your organization.

    To know more about the topic with the help of a real life case, watch the replay of a recent webcast which IBM in partnership with devopsy.kinsta.cloud hosted with Canada Mortgage Housing Corporation’s Jeff Blackadar on how breaking down IT silos helped speed up mainframe development for them.

    Also, do let me know your thoughts on the blog and on the topic.

    1 the born on the web technology teams

    2 http://www.slideshare.net/jedberg/devops-at-netflix-reinvent

    3 http://www.slideshare.net/beamrider9/continuous-deployment-at-etsy-a-tale-of-two-approaches

     

    About the Author/ Mike Fulton

    MikeFaceMedium-150x150A IBM Distinguished Engineer, CTO Enterprise DevOps at IBM,  Mike is a software development professional specializing in compilers, debuggers, profilers and virtual machines. At IBM, Mike works towards understanding and influencing trends and directions in Enterprise IT delivering new technologies into the DevOps Portfolio. He also overlooks integration of the DevOps Portfolio into IBM and Enterprise Software Solutions. Mike is an IBM Master Inventor with several patents to his credit.

    He is an avid blogger and regularly writes on his blog site – makingdevelopersliveseasier.wordpress.com

    linkedintwitter

  • Webinar: Build, test and deploy mobile apps with back-end mainframe services securely in a hybrid cloud

    Webinar: Build, test and deploy mobile apps with back-end mainframe services securely in a hybrid cloud

    You may already have a good understanding of the hybrid cloud and its benefits. But how do you get the value of the last three decades of investment in your backend infrastructure into the hands of your end users faster?

    In this webcast we will demonstrate how you can take advantage of the latest IBM technologies to quickly and easily incorporate your backend services into your mobile applications running on IBM Bluemix. We will also highlight the latest capabilities of IBM DevOps Services (IDS) and IBM Bluemix that support the end-to-end mobile development lifecycle.

    Join Kristal York, Executive Mobile Strategist, PointSource an IBM Business Partner and Rosalind Radcliffe, Distinguished Engineer, Chief Architect for CLM and DevOps as they take you on an in-depth tour of the IBM DevOps Services and Bluemix, an open-standard, cloud-based platform for building, managing and running mobile apps that connect with your back-end services securely.

     

    Recorded Thursday, June 25, 2015

    VIDEO

    SLIDES

    [seoslides embed_id=”2e765888697b” script_src=”https://devopsy.kinsta.cloud/embed-script/build-test-and-deploy-mobile-apps-with-back-end-mainframe-services-securely-in-a-hybrid-cloud/7999/” overview_src=”https://devopsy.kinsta.cloud/slides/build-test-and-deploy-mobile-apps-with-back-end-mainframe-services-securely-in-a-hybrid-cloud/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Build, test and deploy mobile apps with back-end mainframe services securely in a hybrid cloud” /]

    Your Host:

    alan_new_head_shot Alan Shimel, Editor-in-Chief devopsy.kinsta.cloud, An often-cited personality in the security and technology community and a sought-after speaker at industry and government events, Alan has helped build several successful technology companies by combining a strong business background with a deep knowledge of technology.

    About Panelists:

    kelly-ibm-devops

    Kristal York, Executive Mobile Strategist, PointSource an IBM Business Partner

    Kristal joined PointSource in 2012 and has led teams in the financial, retail and insurance verticals. She excels at fostering a collaborative environment and leading others to solve complex business problems.  Kristal’s prior experience as a business analyst has helped as a mobile strategist to define and analyze our customer’s mobile moments. She translates those mobile moments into a mobile strategy across the organization’s business processes and systems.  Mobile demands an iterative approach so Kristal helps analyze strategic planning, usability, research, as well as consistent updating.  She uses her business analytics skills to help define adoption rates and sentiment analysis once the app is launched.  Previously, Kristal was at Cartus for 12 years, most recently Senior Business Analyst, Business Analytics and Mobile Product Owner.

    RosalindRosalind Radcliffe, Distinguished Engineer, Chief Architect for CLM and DevOps, Member of the Academy of Technology

    A Distinguished Engineer within the IBM organization, Rosalind is Chief Architect for CLM and DevOps. She is responsible for driving the DevOps for multi-platform architecture; this includes System z and Power system.

     

     

     

     

  • Budgeting for DevOps Success

    Budgeting for DevOps Success

    One concept that seems to be universal across all IT departments is the admins lament of “how do I convince my boss that we should spend the money.”  Whether it is security, QA or development tools, technical professionals have a difficult time talking the language of the business to justify the expenditure of always scarce dollars. So why should it be any different with DevOps?

    The good news is that in DevOps unlike some other IT disciplines we can actually show some ROI (sometimes anyway).  Nothing will convince a financial stakeholder that spending money is OK faster than if you can show it will allow the organization to either save money or make more money. But how do you show ROI with DevOps. There is more than one way to skin that cat.

    This coming week I am hosting a webinar that will explore the various ways of showing ROI using DevOps.  We will also be looking at some case studies where ROI was demonstrated successfully. One of these organizations is HM Health Solutions. One of the interesting things in this case is that as a health care related organizations the usual compliance issues such as HIPAA often make things like automation and continuous delivery more complex.

    I will be joined by Valerie Scott, Manager of Shared Services Division, HM Health Solutions who is going to relay first hand what she and her team have done to show their executive team how DevOps delivers a real, tangible and measurable ROI.  Valerie is a seasoned exec and I am sure she will have some great insights.

    In addition to Valerie I will also be joined by Rick Slade of IBM who has lots of experience with different organizations in showing the ROI of DevOps.  I expect this webinar to be very informative.  If you are grappling with how to justify a shift to DevOps in your organization I invite you to join us next Tuesday, June 2nd.

    This webinar is sponsored by IBM. It is the third in the series we are doing on Variable Speed DevOps. Our previous webinars in this series have all been very interesting. You can listen and follow along to those here and here. The series deals with how organizations can do more faster  even though not parts of the stack run at different speeds. It is not how fast they run individually, but how well they work together is the key.

    So join me Tuesday as we discuss DevOps ROI and Variable Speed DevOps.