devopsy.kinsta.cloud

Tag: ibm

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

and 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 T_PLAN
- Development complexity T_DESIGN+ T_DEVELOP + T_BUILD
- Testing Complexity T_TEST
- Release and Change Management Complexity T_RELEASE+ T_DEPLOY+ T_EVALUATE
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

Carmen 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).
July 23, 2015
Lean for DevOps: Mapping the tributaries and deltas of demand
Here at IBM’s Lean practice we use a diagram called ‘Mississippi’ to analyze demand. It is not so-called because it originates in Mississippi – in fact I’ve been given to understand that this tool was developed, and named, in our UK practice*. Instead, it’s called the Mississippi because, like that great river, demand comes from many different sources (or tributaries) and can leave a process through a number of different points (the delta). And, apparently, at times the Mississippi delta reflects tidal patterns and flows upstream. In the same way, demand can route back into, or upstream within, a process – for example, in the shape of rework.

We want to analyze the volume and frequency of demand for a number of reasons. Understanding demand helps us to:
- Identify ‘runners’ (everyday requests), ‘repeaters’ (less frequent, but not unusual requests) and ‘rarities’ (infrequent requests). This might be in terms of user groups, applications, or type of request (for example – small changes vs major project). When we design our improved future state, we will design it for runners and repeaters. Sometimes the impact of exceptions can be so painful, team’s lose sight of how infrequent they are, and design a process to prevent or manage those rarities – which will be inefficient for all those runners and repeaters.
- Identify failure demand – Where are additional requests re-entering the process, as rework? Where is there process activity which doesn’t ‘go anywhere’?
- Illustrate channels in and out of the process, so we can identify potential control points, or illuminate a lack of filter, and see where demand might be routed in via unexpected channels.
- Tell us what we don’t know: which elements of demand are we unaware of? We need to understand all demand so that we can build and resource (load level) a process which can meet that demand. Sometimes finding out what we don’t know is a lesson in itself.
These benefits are as relevant to Lean for DevOps as in any other area.

It’s hard to say what you’ll learn from conducting this analysis, until you’ve done it, as every Mississippi is different. But to demonstrate some of the valuable lessons I’ve learned from drawing up Mississippis, here are some real life examples:

Lightbulb moment: ‘Churn is a fact of life – we need a better way to handle it’

Lightbulb moment: ‘We need to start saying no to enhancement requests’

Lightbulb moment: ‘We have way too many changes taking the emergency route: a faster ‘normal’ route will reduce that demand and the associated risk.’

In their different ways, each of these helped make the case for a shortening of the SDLC, closer coupling of development to business demand, and a more nimble deployment process.

*If you’ve seen this in use outside of an IBM engagement, I’d love to hear about it! Find me on Twitter to set the record straight.
July 14, 2015
“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!”

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 Spung, DevOps Deploy and UrbanCode Integration Executuve, IBM Cloud, @paspung
July 2, 2015
$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.

T_DELIVERY = T_PLAN + T_DESIGN+ T_DEVELOP + T_BUILD + T_DEPLOY + T_TEST + T_FIX+ T_RELEASE + T_EVALUATE

In an optimal world or software factory that is fully automated the T_DELIVERY 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 (T_X). 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:

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 T_DELIVERY will be infinite (divide by zero). 100% trust and our T_DELIVERY 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:

T_DELIVERY = T_PLAN + T_RESCOPE + T_DESIGN+ T_{ARCH REVIEW} + T_DEVELOP + T_{TECH DEBT} + T_BUILD + T_REBUILD + T_DEPLOY + T_REWORK + T_TEST + T_RETEST + T_FIX+ T_REFIX + T_RELEASE + T_ROLLBACK + T_RE-RELEASE + T_EVALUATE

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 (T_x) 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 T_DELIVERY.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 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.
June 22, 2015
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⁽¹⁾ make, can be pretty astounding. Dozens and sometimes hundreds of releases a day from big companies like Netflix ⁽²⁾ and Etsy ⁽³⁾ 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.

¹ the born on the web technology teams

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

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

About the Author/ Mike Fulton

A 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

June 10, 2015
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 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:

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.

Rosalind 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.

June 2, 2015
Jenkins User Conference and CD Summit: Calling all London DevOps

I wanted to give a quick shout out to the large, vibrant and supportive London DevOps community. Later this month (June 23rd and 24th), there will be a joint conference at the Hilton Metropole, London. Combining the Jenkins User Conference and Cloudbees CD Summit, it is two days of CD/CI/DevOps learning.

Speakers include:

Kurt Bittner, Principal Analyst Forrester,

Martin Croker, Managing Director, DevOps, Accenture,

Sanjeev Sharma, CTO, DevOps Technical Sales & Adoption, IBM Distinguished Engineer, IBM,

Viktor Clerc, Product Manager, XebiaLabs

and more.

The Jenkins User Conference (JUC) features another great lineup of speakers as well. devopsy.kinsta.cloud as well as a host of others are sponsoring the event.

In speaking to my friends at Cloudbees they mentioned that there were tickets still available. I found that hard to believe as I know what the community is like here in London. So if you are going to be in town on the 23rd and 24th, don’t miss this event! I will be there hosting a great panel on the 23rd as well.

The Jenkins community is one of the most active that I have ever seen. I am looking forward to seeing many of you in London on the 23rd ad 24th.

There are still sponsorships for CD Summit as well. If interested you can contact Cloudbees for info.

Also this Thursday is DevOps Connect: Rugged DevOps @Infosecurity Europe all day. Registration is free, so come down for a great day of DevOps tracks!

June 2, 2015
Lean Value Stream Mapping for DevOps
Value Stream Mapping is a crucial step in assessing an organization’s DevOps capability. We create a value stream map of the software development lifecycle early in any DevOps engagement, because it helps us to-
- Provide context for our architects and technical experts who are, in parallel, examining tools and technology.
- Establish a performance baseline, against which the improvements delivered by adopting DevOps will be measured. (See my other blog post on Box Scores for more on this).
- Begin the process of winning hearts and minds, and engender cultural change. By working side-by-side in a workshop, Dev and Ops resources, as well as those involved in planning, test scheduling, and other activities, start to gain an understanding of how the work they do is linked to steps upstream and downstream. This lays the groundwork for closer coupling of those activities in the future.
What’s interesting is that the template we use for our DevOps Value Stream Map is almost identical to that which we use for other service processes. It’s been used by IBM Lean Coaches to assess processes as diverse as Marketing Campaign Development, Order-to-Cash, Mortgage Applications, and Production Support to name but a few. This template was evolved from more traditional Value Stream Maps used to capture manufacturing processes, and a slightly different template also exists for innovation or product development processes.

At the start of every Lean project – whether it’s in DevOps, Insurance Claims, New Product Development, or Financial Forecasting, I review the Value Stream Map template. I ask myself and my team if the questions make sense for this process and if the boxes we are seeking to fill are relevant. Some of the language might be slightly different, and the outputs will certainly differ – from a high frequency process where a step takes minutes and seconds, to a creative process where a step could take weeks. But almost without exception, the template remains the same.

We ask the same questions across all these types of processes – and now we ask those questions of the Software Development Lifecycle. Those questions are:
- What activities are being performed?
- Who delivers those activities? How much of their time is dedicated to those activities?
- What is the yield, i.e. ‘right first time’? What % of rework is generated? What causes rework?
- What tools are required to complete the step? And what other inputs are required?
- How many units (e.g. work packages) are ‘work in progress’ within this step?
- How many units are waiting in the ‘inbox’? How will they be prioritized or scheduled? How long will they, typically, wait for?
- How long does the step take? How much of that time is effort, or touch time, versus duration, or in-process lead-time?
When all’s said and done, all Value Stream Maps have something fundamentally common: they are all about flow – and DevOps is no different.

About the Author/ Katie Sotheran

Katie is an IBM Lean Master based out of Los Angeles, California. Katie has many years applying Lean principles to processes as diverse as beverage distribution in Spain, lubricant product development in the Netherlands, Insurance Sales in the UK … and IT operations, all over the world.
May 19, 2015
Surprise! Broad Agreement on the Definition of DevOps
For the past few years, the conventional wisdom has been that DevOps has no agreed upon definition. Instead, everyone has their own interpretation. However, the conventional wisdom is wrong.

While everyone supplies slightly different words, the same working understanding of DevOps is nearly universal. Our understanding of DevOps goes back to a handful of common touch-points. There is the “CAMS” (Culture, Automation, Measurement and Sharing) acronym popularized by John Willis and Damon Edwards. CAMS has been extended repeatedly – Eveline Oehrlich of Forrester is now discussing CALMSS. Gene Kim offers his “3 Ways” and Patrick Debois has codified “4 Areas”. Allspaw and Hammond had 10 deploys a day, and Etsy made technologists fascinated by a virtual crafts bazaar.

Analysts, authors, industry, and community leaders all agree. The ideas are big and mutually supportive. In short:
- DevOps exists to help the business win
- The scope is broad, but centered on IT
- The foundations are found in Agile and Lean.
- Culture is very important
- Feedback is fuel for innovation
- Automation helps
Why: To help the business win

The most popular DevOps book today is The Phoenix Project, with a subtitle “A Novel about IT, DevOps and Helping Your Business Win”. DevOps is not a navel gazing IT methodology for making IT better for IT. It is focused on how stuff involving the technologists can deliver better results for the business.

As Patrick Debois writes in his excellent post,”DevOps Areas – Codifying devops practices“:

As rightly pointed out by Damon Edwards, devops is not about a technology, devops is about a business problem. The theory of Constraints tells us to optimize the whole and not the individual ‘silos’. For me that whole is the business to customer problem, or in lean speaks, the whole value chain.

At IBM, our definition of DevOps calls out enabling the business to “seize market opportunities”.

Today, technology is critically important to how a wide variety of companies compete. Retailers who neglected e-commerce have gone out of business. Logistics companies like UPS find a competitive edge by creating software to shave miles off delivery routes. In the automotive space, Ford is at tech conferences recruiting companies to write apps for its cars and Tesla’s first fix for their flammable battery problem was an over the air software update.

DevOps is a response to what the IT is experiencing – from a back-office concern that needed to “keep the lights on” to key part in how the business competes every day.

Who: A Broad Scope, beyond development and operations.

Yes, DevOps is a portmanteau that brings development and operations together. Yes, the classic DevOps concern is the Wall of Confusion between development and operations. However, with the focus on business value, the scope must include everyone who is involved in taking an idea through IT to business value.

In recent years, there’s been something of a cottage industry of community leaders and analysts writing, “No, no it really should be Dev_____Ops” where the blank is filled in by their own specialty. Examples: DevQAOps, DevOpsSec, DevSecOps, BizDevOps and of course Bussdevtestqanetsecnetops.

When a Finance department must approve the provisioning of each new test environment, slowing the delivery of new applications by weeks or months, there is a DevOps problem that leaves narrow confines of development and operations. It leaves IT. Patrick’s quote above talks about optimizing the whole value chain. In that post he describes DevOps as being about “collaboration, optimization across the whole organization. Even beyond IT (HR, Finance…) and company borders (Suppliers)”.

Based On: Agile and Lean

In answering why he didn’t support a manifesto for DevOps, Patrick Debois points people back to the Agile manifesto and asks them to reread it more broadly. Agile’s shift towards a faster delivery of software, and focus on the end goals make it a natural spiritual ancestor for DevOps. However, from the perspective of Ops teams, Agile represented the barbarians at the gates. Agile generally took root in development side of the house, enabling it to create something the business wanted faster. But with operations still moving at a pace suited to waterfall, pressures grew and the need for something like DevOps became clear.

Where much of DevOps energy seems to come from its Agile roots, the intellectual side of the movement is more rooted in Lean. It seems no accident that many of the Phoenix Project’s lessons are taught away from the cube farm and instead from the factory floor. While we can intuit that faster feedback is better, and the “continuous” in CI and CD is convenient because it lets us map feedback to fewer changes, it is in the Lean literature where we encounter Little’s Law. It provides the queue theory mathematics supporting the idea that smaller batch sizes supports shorter cycle time. And so Reinertsen’s “The Principals of Product Development Flow: 2nd Generation Lean Production Development” has become popular in DevOps circles and is well cited by Jez Humble in his new Lean Enterprise book.

Culture: Collaboration and Experimentation

The Agile and Lean roots show through in the DevOps culture as well. Lean and Agile are both focused on people first, systems second and heavily cross-train or work in cross-functional teams. They also emphasize continual improvement (kaizen) through approaches like retrospectives.

In DevOps circles, collaboration is preached as an antidote to thinking in siloes which has resulted in antagonism between development and operations. For the systems thinking required to deliver for the business, teamwork is required. Developers make better decisions when they take advantage of operations knowledge (Patrick’s Area 3) and operations does better when application knowledge is embedded with them (Area 4).

The other cultural emphasis is a push towards experimentation, constant learning and improvement. This is Gene Kim’s third way of DevOps. The Lean Startup ideas of Eric Reis permeate the DevOps world. Intuit has made great strides in showing how these approaches work in established companies by running experiments in the midst of tax season resulting in improved business outcomes.

These cultural trends come together in things like blameless postmortems discussed by Etsy and Jake Loomis in Web Operations. When things go wrong, organizations need to understand why and take corrective action. In troubled corporate cultures, the messenger reporting the problem might be shot, and the hunt to assign blame for the problem will begin. Healthy organizations look to learn from failure and try to improve the systems that allowed (or guided) people to make a series of mistakes that lead to the failure.

Feedback: Yes. Lots please!

Experimentation, adaptation and learning tend to do better when there is ample feedback. Otherwise, there is too little to learn from. Developers tend to be more productive as well with rapid feedback. Their thirst to know whether the latest change diminished quality led to the practice of continuous integration and the tools that support CI and continuous delivery. That CD ends up facilitating faster delivery of value to the customer is something of a happy accident.

Amplifying feedback loops is Gene’s “second way“. The “CAMS” concepts of measurement and sharing point to feedback. You gather lots of information, and make sure people see it so they have an opportunity to learn from it. And when Elisabeth Hendrickson presents at DevOps Enterprise 2014, as Cloud Foundry’s Director of Quality Engineering at Pivotal, she describes her job as “to see to the care and feeding of the feedback cycles“.

As expected with a collaborative culture with ample sharing, feedback must cross the traditional silo lines. That means the awesome production monitoring that had lived in Ops land, is radiated back to development. This is “Area 2” in Patrick Debois codification.

Automation: Of course.

The “A” in CAMS is automation. Patrick’s “Area 1” points to continuous delivery techniques, well described by Dave Farley and Jez Humble in their book. A Lean initiative looking at IT will find waste in wait times, errors, and more and move towards automation as a natural result. Feedback craves automated deployment of changes, and automated tests or production monitoring that validates them. Automation is what makes a lot of DevOps possible. It doesn’t make cooperation between development and operations happen, but tensions are reduced when Ops gets out of the business of arguing about the SLA they have with Dev around server provisioning and instead provide Dev a button to press.

DevOps isn’t about automation. Automation is just the natural result of DevOps.

Additional Resources not cited above

DevOps for Dummies – by Sanjeev Sharma

8 Best Practices for DevOps – Ashok Reddy’s overview of the Forrester Report

About the Author/ Eric Minick

Eric Minick is a Technical Evangelist. He joined IBM through its acquisition of UrbanCode. He has spent the last ten years helping organizations – large and small – adopt continuous integration, delivery and now –DevOps. He is a frequent speaker on the topic, and co-authored Application Release and Deployment For Dummies.

Prior to consulting, Eric was a developer, test automation engineer and support engineer, and has contributed to multiple generations of UrbanCode products. Follow him on Twitter at @ericminick.
May 13, 2015
Webinar: Show Me Success Before I’ll Invest in DevOps – A HM Health Solutions Case Study

Whatever your conviction, the reluctance by senior management to justify new investments and sponsor major change in existing software delivery practices and technologies, while theoretically understandable, often leaves application development executives and managers lobbying for additional budget and resources putting them and their teams between a rock and a hard place. So the question is how do you monetize the benefits and measure your DevOps results? Join Valerie Scott, Manager of Shared Services Division at HM Health Solutions, Rick Slade from IBM, and Alan Shimel from devopsy.kinsta.cloud as they discuss the process for quantifying DevOps benefits using metrics your business stakeholder will care about the most. They will walk you through the methodology and share customer case studies that demonstrate the impressive ROI that DevOps is providing to IBM clients worldwide.

EVENT RECORDED: Tuesday, June 2, 2015

VIDEO

https://www.youtube.com/watch?v=J5haNExYZ2o

SLIDES

[seoslides embed_id=”f384dfd0ae4e” script_src=”https://devopsy.kinsta.cloud/embed-script/show-me-success-before-ill-invest-in-devops-a-hm-health-solutions-case-study/7686/” overview_src=”https://devopsy.kinsta.cloud/slides/show-me-success-before-ill-invest-in-devops-a-hm-health-solutions-case-study/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”Show Me Success Before I’ll Invest in DevOps – A HM Health Solutions Case Study” /]

Your Host:

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:

Valerie Scott, Manager of Shared Services Division, HM Health Solutions Strategic planner and IT leader with years of architecture and infrastructure experience in the healthcare insurance industry, Valerie is a key player in the IT Transformation efforts by driving a lean wave of change in the HM software delivery pipeline with DevOps concepts and technology.

James (Rick) Slade, Executive Solution Architect, BVA, Cost Benefit Analysis, IBM Rick is an Enterprise Solution Architect at IBM and spends his time helping clients design and automate enterprise software development and delivery practices. He is certified as an IBM and Open Group Distinguished IT Specialist.

May 12, 2015