devopsy.kinsta.cloud

Category: Blogs

Make ‘Mobile First’ an Innovation Strategy

The call for organizations to be “mobile first” in application development has been so heavily embraced by enterprises that today mobile first has become table stakes. Being mobile first is no longer cutting edge but merely keeping pace with the enterprise pack. And a big pack it has become: According to ABI Research, revenues generated by the enterprise mobile market are growing at twice the rate as consumer apps and will reach $340 billion by 2017.

With that size of a market in place, and nearly every employee having as many as three mobile devices, and every enterprise cranking out mobile apps as quickly as they can, how are organizations supposed to leverage that mobile infrastructure?

Here are a few ideas how:

Capture the continuous, mobile data inputs that matter

As readers of DevOps.com are quite aware, the enterprise has evolved into a continuously integrated, continuous developed and continuously deployed software and data factory. If you’re reading this site, you are aware of the tremendous benefits of DevOps, as well as the the changes containerization and microservices are bringing to IT.

But the continuous nature of the modern enterprise isn’t just about applications, especially in today’s mobile environment. It’s also about continuous data being captured by users and devices. To successfully innovate and compete today, IT leaders must take advantage of all of the real-time, continuous data inputs that are rolling in from their users’ mobile devices and, increasingly, IoT-connected enterprise devices. This data is critical when it comes to understanding customer trends, supply chain health, regional differences in demand, emergencies as they arise, and many other factors regarding business and IT health.

This means IT leaders must look for ways to capture, store and analyze these continuous mobile data inputs—and they better start now while the task is still manageable. According to IDC, there are already 200 billion computerized things connected to the Internet, and in four years there will be more than 50 billion networked sensors. The amount of data—and the importance of this data—is astounding.

Leverage citizen developers to meet mobile app demand

Enterprise mobile app backlogs continue to be the bane of enterprise mobile efforts. As covered in Clearing through the app backlog clutter, 85 percent of enterprises have an app backlog, and about half of those that do lag behind 10 to 20 apps in their pipelines. These app backlogs are costing enterprises in lost productivity and revenue.

Where should CIOs and IT leaders turn to clear these backlogs? To their citizen developers, of course. Citizen developers are not without their own risks, such as with cybersecurity and regulatory compliance. But through proper awareness training and monitoring, these risks can be mitigated.

And the benefits of working with citizen developers are too great to ignore.

For one, citizen developers can help free the mobile app backlog as well as free the core development team for more mission-critical apps. If the business needs apps that won’t be connected to sensitive systems, or managing sensitive or regulated data, let these business developers build apps on their own, if they are so inclined.

And the data indicates that more and more are, in fact, so inclined: According to an Intuit QuickBase study, “State of Citizen Development Report,” of the 148 professionals surveyed who identified either as citizen developers or as IT pros who support a citizen developer, 62 percent reported being able to develop apps in less than two weeks.

Citizen developers can also be encouraged through training to program with code-free development platforms or some of the high programming and scripting languages. This way, when business users find themselves not as effective as they want because of the lack of an app, they can build the app on their own and not have to worry about IT bottlenecks.

Deep dive into mobile micromoments

Another way to drive innovation through mobile is to ensure development teams are developing an optimized mobile experience. That means taking advantage of micromoments. Today, workers don’t sit and focus on work as much as they used to. Nope. These days, they are updating data on their phones while scurrying between meetings, standing in line or doing whatever it is that they happen to be doing in-between primary tasks.

According to an article on The VAR Guy titled, “Survey: Poor User Experience Leading Cause of Enterprise App Failure,” a survey of more than 340 respondents reported that 50 percent said their projects didn’t move forward in the enterprise because of user interface problems. Such UI problems were also cited as one of the greatest reasons for app delays.

Mobile applications have to be designed with this use in mind. Not only do apps have to be designed with the smaller form factor in mind, but they also must be designed with contexts of the moments in mind. That means taking into account features of the phone such as location, voice and ability to insert photos or video. Developers need to develop specifically for both the form factor and the context in which users engage these devices. Only then will more benefits of mobile be reaped.

Embrace an IoT platform

Most of the data generated by IoT will be managed by IoT platforms, or IoT brokers. In 2015, the industry witnessed a lot of action in both the independent IoT players as well as large cloud providers.

According to ReportLinker, IoT platforms, hardware, services and software will become a multitrillion market. “Revenue generated in 2015 [by IoT] was approximately $330 billion and is projected to reach $453 billion by 2020 with a CAGR of 6.2%,” the firm stated in this release.

The large enterprise software players didn’t stand still when it came to IoT, either. Amazon, IBM, Microsoft and Salesforce all jumped into the IoT fray with their platform offerings. And while 2015 was the year for technology platforms to come to market, 2016 will be the year IT leaders prepare their organizations to take advantage of the data, insights and control that IoT will provide their organizations in the years ahead.

Provide continuous mobile insights to users wherever

When it comes to mobile data and big data analytics, it’s easy to forget that mobile devices are more than mobile data inputs—workers need them to provide valuable, contextual insight as well. To make the most of all of the data being captured from mobile apps and IoT platforms, it’s crucial that data be accessible anywhere and be displayed in ways that make sense to your employees and users.

To succeed here, it’s important that big data insights don’t languish in big, isolated databases. Enterprise data needs to be accessible on every type of device, including mobile.

February 1, 2016
Google Hangout: Innovate Like a Startup, Scale for the Enterprise
It’s what keeps your CEO awake at night – your industry getting disrupted by a competitor you can’t see today. The winners are quick to adapt, fast to innovate. But how do you act like a startup – nimble, energetic and creative – at enterprise scale. DevOps, fused with open technologies, hybrid cloud and design thinking, can close the gap by helping build an enterprise competency for delivering continuous innovation.

Join us as industry leaders describe how they’re transforming their organizations to win. An innovation culture that addresses multi-speed IT. Blow-your-ears-back improvements in cycle time, cost and quality. Experimentation, feedback loops and A/B testing. And deploying updates to production – tens of times a day. Don’t miss it!

Date: Wednesday, February 10th, 2016

Time: 1pm eastern standard time
```
HANGOUT LINK:(NO REGISTRATION REQUIRED*) 
```
*Google Hangouts are FREE. To participate in a Google Hangouts LIVE,
a Gmail or Google Profile is required.

Your Host

Alan Shimel | Editor-in-Chief | DevOps.com,, 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.

Our Guests

Gene Kim | Author, Researcher, Speaker, Director, DevOps Enthusiast

Gene is a multiple-award-winning CTO, researcher and author. He was founder and CTO of Tripwire for 13 years. Gene is a huge fan of IT operations and how it can enable developers to maximize throughput of features from “code complete” to “in production,” without causing chaos and disruption to the IT environment. He is passionate about IT operations, security and compliance, and how IT organizations successfully transform from “good to great.”

Angel L. Diaz | Vice President, Cloud Architecture & Technology

Dr. Angel Diaz is IBM’s VP of Cloud Technology & Architecture. Angel and his team are responsible for the technology, architecture and strategy behind IBM’s Hybrid, open and secure cloud – empowering our clients with a new way to work. When he’s not working to bring greater value to clients through a flexible and interoperable cloud, he’s IBM’s leader for open technology where he is spearheading an industry IT renaissance driven by open source code, community and culture. A master of the art-of-the-possible, Dr. Diaz has been the driving force behind many of the most important Cloud, Data and Mobile open technology industry movements – all focused on enabling innovation that is built on simple, practical solutions.

David Lindquist | IBM Fellow, Vice President of Development, Cloud DevOps Services

Mr. Lindquist, an IBM Fellow and VP, is responsible for the development of IBM’s Cloud DevOps Services, including: UrbanCode, Bluemix DevOps and our Bluemix Garagre Method. Prior to this role, Dave was the CTO for the IBM Cloud & Smarter Infrastructure Division and the IBM Tivoli Division. In 2007, he was appointed an IBM Fellow, IBM’s highest technical honor for his innovation and industry leadership. He joined the IBM Software Group in the mid 90s, where he has focused on the research and delivery of emerging Internet technologies, including Cloud, SaaS, Web infrastructure, Mobile and Wireless technology. His research has led to 48 patents, recognition as an IBM Master Inventor and election into the IBM Academy of Technology.
January 29, 2016
To Be Continuous Podcast: The Clash in Open Source

Welcome to To Be Continuous, a show about Continuous Delivery and software development hosted by Paul Biggar, Founder of CircleCI, and Edith Harbaugh, CEO of LaunchDarkly. In this episode, Edith and Paul talk about the clash in OSS between developers looking to get paid and software companies looking for things for free.

This podcast is brought to you by Heavybit, a program that helps developer-focused companies take their product to market.

[soundcloud url=”https://api.soundcloud.com/tracks/244279037?secret_token=s-oeBCP” params=”auto_play=false&hide_related=true&show_comments=true&show_user=true&show_reposts=false&visual=false” width=”100%” height=’166′ iframe=”true” /]

Edith: So Paul, what do you like about open source?

Paul: So I guess that depends on whether we’re talking about writing open source or using open sources as part of a company. Writing open source, I like just having all my code out there.

And I’ll do that as often as possible. Anytime I start a little bit of code, a little library, I’m looking to open-source it and have a readme and have it out there for other people to use. I had a very long discussion, which I eventually won, about the …

Edith: I like the way you think of all discussions as win or loss.

Paul: Well, yeah, yeah. It was more on the argumentative side of discussion. But with the other co-authors of the PHP compiler I wrote, which was originally GPL. And I argued very strongly that I actually don’t care if people give back, I just want people using my software. So to me, open source is a way of having people using my software.

Edith: That’s really interesting. So, I liked what you said at the beginning about, like, you liked open source ’cause it meant getting stuff out sooner. ‘Cause I’m a big fan of that.

Like, I always say you should just publish stuff. Like, my co-founder John said something really good at our team meeting last week. He’s like, if it’s 90 percent done and you don’t publish it, it’s actually 0 percent done.

Paul: It’s 0 percent done, yeah.

Edith: Yeah, and that’s a hard lesson, ’cause you always try for perfection lately.

Paul: Right, right, right. Well, I think there’s also some really hard downsides about that. So when you publish something before it’s ready, before you really —

Edith: Well, ready.

Paul: Well, there’s ready ready, but let’s say ready is, let’s say you publish it before you clarify what the software is to do, or the values or the mission of the software.

And then you get contributors who are saying, ‘Oh, this is great, but I really want it to do this other thing,’ and you’re like, ‘Well, that’s not exactly what I was going for here.’

Edith: Well, I’d say most open source projects are so lucky as to get contributors at all.

Paul: True, true, true. So I’ll give you an example. I wrote the V8 bindings for Closure. So a binding that allows you to write JavaScript and run it in Closure. And I did that for a purely selfish thing, for another, for a nascent pipeline that I was building called Stefan.

And then people came along and they wanted to do other things with it. They’re like, ‘Okay, let’s add a binding for this other thing.’ I was like—

Edith: Well, that’s kind of like a pivot.

Paul: It is, it is, but I really was not interested in it.

I’d rather someone took it over, took over the project and actually ran with it where they wanted to go, and I can stick on the old version, or I can see if the new version solves it for me, but I wasn’t interested in becoming a maintainer in this thing, I was interested in solving my itch.

And I just happened to open-source it, because I felt it might be useful for other people.

Edith: So Paul, I hate to say this, but I agree with you.

Paul: No, not again.

Edith: Not again. No, I mean, I think what you said is exactly right, that you said, I did this for this reason, and I want somebody else to take it over now.

I think where open source runs into issues where people are like, it’s only this purpose and you can’t do anything with it besides my original thing.

Paul: So you think that’s a good thing, or you think that’s a problem? Or it causes problems in the community?

Edith: I think open source is so misused for so many different purposes that it’s hard to even say. Like, so, in Europe, people say open source is good because it means free software.

Paul: Libre or gratuit?

Edith: I’m sorry?

Paul: Free as in beer or free as in, what’s the other side of that?

Edith: There’s no such thing as a free lunch, is that what you’re talking about?

Paul: No no no, like people say open source software, it’s like free-as-in-beer software, as in software that has no cost vs. software that has no price tag vs. software that is, they use the French word libre for—

Edith: Oh yeah, that’s what I was talking about. So I remember I went to Europe in, I think it was like 2004 or 2005, and they just had this big push for open source, ’cause they thought it meant free.

Paul: Oh, this is like the German government and that sort of thing.

Edith: So literally like, so I went to this customer and they’re like, ‘So it doesn’t cost you any more to give us an extra copy.’ So why shouldn’t just everything be free?

Paul: Oh, right, yeah, well.

Edith: And so I think open source has been misused by many businesses who think of it as just like, hey, we get all these developers working for free.

Paul: So I think that the main advantage to business of open source is not that it’s free, but it’s that it’s low-risk.

Edith: Low-risk?

Paul: Lower risk. So it removes—

Edith: Ah, I would argue—

Paul: Well, so, what I mean is that it removes a certain element of risk from it. So there’s, Joss Belsky wrote a blog post about how you shouldn’t use, I think it was a database that you didn’t have the source code to.

Edith: Well, so I’ll argue the reverse, and I think open source is sometimes more risky. ‘Cause I talk to people now who are like, nobody’s maintained this open source project that I depend on.

Paul: Right, right, right. But that vs. a closed-source version.

Edith: Well, so the opposite risk is that you end up that you are responsible for this open source project, and you’re like, well, actually, I just wanted to use this thing. I didn’t want to do the maintaining.

Paul: So absolutely, you don’t wanna end up the only person that, well, it’s actually fine to end up the only person which is using this thing.

Edith: Well, no, it’s not—

Paul: It’s not ideal.

Edith: It’s that many people are using it, but nobody is paying money, and then you’re stuck.

Paul: Because no one is maintaining it.

Edith: No one is maintaining it, and you depend on it.

Paul: Right, so, but imagine that no one maintained it and all that you could get was like a binary block. That’s the real problem. The company goes out of business. You have random database version seven, the binary, that only runs on 32-bit, that you’re maintaining, like, companies are literally maintaining COBOL—

Fortran things from 30 years ago. It sits in a machine, you can’t touch it, you can’t fix it, you can’t apply security updates to it.

Edith: Yeah, that’s fair. So Tim Chou, who is, he’s an awesome guy, he was early Oracle, he said that people don’t buy, when they buy software, they’re not buying it what it is today.

Paul: Right.

Edith: ‘Cause basically, anything that you’re buying today, you could just hire 20 engineers that could build it. What they’re buying—

Paul: Yeah, you could just copy it.

Edith: Yeah, what they’re buying is the promise of stability, that it will continue to be maintained. That there is a vision. And that’s actually, I went over to a big customer who won’t let us use their name yet, but they said they love LaunchDarkly because we thought every day about feature flags.

Paul: Right, right, exactly. This is why people buy SAS, because, because people think all day about CI, about QA as a service, about queues, or whatever it is from various Heavybit companies that I just shilled for, they’re, you can probably figure out yourself which ones they are by looking at the homepage.

Edith: Well, and Paul, by the way, thank you very much for wearing your LaunchDarkly t-shirt today. It looks very handsome.

Paul: The, I definitely agree that the benefit of the thing is that you use it every day. But you can do that with open source as well. You can have open source software that, so, for example, our front end is open-sourced.

Edith: Oh, I’m absolutely a fan of open source. Like, we use open source every day. Our client libraries are open source. I’m not saying that it’s, I don’t think it’s a religious thing vs. open source vs. not, I just think that many times people assume open source is something that it’s not.

Paul: Yeah, fair enough, fair enough.

Edith: I mean that if you have open source, that just means that developers spring out of the ground willing and happy to update your software every day.

Paul: A mixed blessing, definitely. If it even happens.

Edith: Like, I remember, so I remember when Sun, so I used to work on a, I used to be at Epicentric, and we had a portal server, and we were killing Sun. Absolutely killing Sun. And this was in 2003, so what they said is, ‘Oh, we’re gonna make our portal server open source.’

Paul: Right.

Edith: And so somehow this whole thing, we’re like, everything will be open source, and like, developers will spring out of the ground, and it’s like, well, no, developers, they don’t wake up every day like, ‘I’m gonna work on your thing.’

Paul: Right, right. They will if it’s sexy or exciting. There’s lots of developers who are showing up at Mozilla just to contribute. And in fact, they’ve fought through incredibly large hurdles to contribute to Mozilla’s software.

Edith: Well, that’s fascinating, ’cause I see so often the reverse, where people, so what do you think about Mozilla made people want to contribute?

Paul: I think the fact that it was an open-source-first company, and that it was a nonprofit, and it was all about the free and the open web and that sort of thing. Also, people had had very good experiences with Firefox for, like, a decade at this point by the time I was there. Well, maybe seven years, but, you know.

Edith: It’s fascinating, ’cause I went to dinner last night with the CEO of MySQL, and I don’t know if I should say this, but he said—

Paul: This is Marten Mickos?

Edith: Yep. So he gave a talk—

Paul: He has a new startup?

Edith: Called HackerOne?

Paul: Oh, he joined HackerOne.

Edith: Yeah, he’s the new CEO. So the dinner was kind of like a debutante ball for him.

Paul: Nice, nice.

Edith: So what he said was that somebody had asked him flat out how much of MySQL was actually from contributors. He said 1 percent.

Paul: Seems about right.

Edith: He said the open source was more just a branding thing. Like it wasn’t actually like a productivity thing. It was more just a branding thing.

Paul: So you have this in Mozilla as well, that any time that there’s a really avid contributor, that Mozilla would hire them.

Edith: Yeah, that’s what he said.

Paul: Right, and if Mozilla didn’t hire them, very often they stopped being a contributor. Like, it was a real sort of a double-edged sword.

So someone who did it for six months, they were doing it for the love of the game. They weren’t doing it to be hired at, at least I think for the most part, they weren’t doing it to be hired at Mozilla. And then six months in, someone’s like, well, you know, you’re doing a really great job, wouldn’t you love to work on this full-time? They’re like, yeah, that’s so exciting. They’re flown out for an interview. And then it’s like, you know, actually, I don’t think so.

Edith: Wait, they didn’t wanna work for Mozilla, or Mozilla didn’t wanna hire them?

Paul: Mozilla didn’t wanna hire them. I mean, this isn’t a particular case. But you know, some subset of people, Mozilla didn’t wanna hire. And then what happens? Well, you kind of don’t wanna keep contributing to the company that just told you to f*ck off.

Edith: Yeah, I mean, it’s so true. I mean, I think there’s a very human thing about volunteering.

Paul: Right, right.

Edith: I volunteer, I was the moderator for a long time for the Lean Startup Circle, and somebody new came on, and they’re like, yeah, I’d love to raise some money so that we can get paid, and I’m like, they cannot afford to pay me.

Like, I don’t do this to get paid, ’cause—

Paul: Yeah, it’s like, it’s an altruism that people are trying to do.

Edith: Yeah, I was contributing like 10 to 15 hours a week, and at my going rate, it’s not, it’s like, I’m not doing this to get paid, I’m doing it ’cause I like giving back.

Paul: So there’s this thing that we were talking about earlier, about the current discussion around people getting paid in open source.

Edith: Yeah, and I think a lot of what has fueled open source is the whole 20 percent time. Like, that Google will give their engineers 20 percent for open source, and I know that other big companies, like Twitter and so on, do that too. So these people are, in essence, getting paid.

Paul: Right, right, there’s a, in most companies, in most startups at least, there’s an unspoken rule that you’re expected to contribute to the libraries that are in your application, and that sort of thing. If you’re spending time upstreaming paths that you’ve deployed, that’s work.

Edith: Yeah, so I think we’re agreeing, which, I thought we agreed that we were not gonna agree. It’s funny, ’cause I’m Twitter friends with a guy I’ve never met, who’s, he started Jango, and right now what he tweets a lot about is—

Paul: This is Jacob Kaplan-Moss?

Edith: Yeah.

Paul: Okay.

Edith: That people are working their nights and weekends, and contributing to open source, and then just, people are kind of, for lack of a better word, jerks. People are like—

Paul: People are jerks.

Edith: Yeah, like—

Paul: Even when you’re paid, people are jerks.

Edith: But it’s more aggravating.

Paul: Right, right, because you’re doing it for free, or whatever.

Edith: Yeah, and so people will, like, they’ll be like, ‘I have this pull request and it’s been open for two hours. Why haven’t you reviewed it?’

Paul: Right, right. I mean, we get the exact same thing. We get customers who email us, or more often it’s the people who get, who are using the free version, who send us a support request and then, 30 minutes later they’re on Twitter going, I can’t believe Circle hasn’t solved my problem yet. It’s been 30 minutes.

Edith: What do you think drives that?

Paul: There’s a pattern across the population in general, that people are jerks.

Thanks for listening to this episode of To Be Continuous, brought to you by Heavybit and hosted by me, Paul Biggar of Circle CI, and Edith Harvaugh of LaunchDarkly.

You can find the full episode of this podcast here. For more on Continuous Delivery and to hear other Heavybit podcasts, copy this link into your favorite podcast player. We’ll have show-specific RSS and iTunes subscription options soon. You can also follow To Be Continuous on Twitter at @continuouscast.

January 29, 2016
Information Changes Everything

Chart provided courtesy of Spurious Correlations, http://bit.ly/1L01SSt

— ROELBOB

January 29, 2016
Unifying Applications into One System
Let’s talk about a real problem that all of us have faced at one point or another: keeping track of a single thread of work across many disparate tools. Regardless of the industry a company operates in, as a company grows it accumulated back-office applications that support of the business.

Many knowledge-based companies have some sort of communication tool, project tracker and support tracker, all designed to help improve business process. Conversations suffice until they do not, and tools are implemented as the need arises. Every added tool has its purpose, solves a critical need and makes you and/or your team more productive.

At some point however, this changes. Discovery becomes a major issue, as usage patterns between different tools leaves silos of data. It becomes difficult to correlate the different company pipelines that ultimately drive your business—the pipeline to care and communicate for customers, the pipeline to deliver new features, and the human interfaces involved in each. This is only intensified by team members who work on different projects with different tools and people, team members who work in different time zones, the sheer quantity of work to be done …

How many ways can you name how not just conversations are lost, but context as well?

Commonly, teams attempt to solve this in a few ways:
- Rules! Specific guidelines (sometimes suggestions, sometimes mandatory) on how and where to have conversations and to store data.
- Integrate! Write data transforms to move data from system X to system Y as necessary.
- Go all in! Choose a suite of tools that takes care of all of these for you.
- Make it problem for “Future You” — It’s fine as is, and not really an issue.
At StackStorm, we ran into this problem. We have two ticketing systems (GitHub issues and Jira), a service desk tool (reamaze), and a chat client (Slack). The solution we use at StackStorm is one that I borrowed from my time at GitHub. One of my colleagues set up a really cool hook into Hubot that listened in our chat rooms for conversations we were having related to a GitHub Issue, a Pull Request or even a code commit. When someone mentions one of these things, Hubot would grab a chat log plank, and cross-link the permalink to the Issue or Pull Request.

But, that’s just GitHub. Context matters across all tools, and gives team members additional flexibly in learning and gaining knowledge on their own. So, we took our Support Tool, re:Amaze, and did the same thing.
- In times of speed, breadcrumbs allow you to piece together puzzles from where travelers have once voyaged. It may not be the entire puzzle, but having background greatly helps.
- In times of documentation, those breadcrumbs allow you to use the same investigative skills to assemble a better history.
This is one part of a set of behaviors that helps create a dynamic web of information. By seamlessly having a mechanism to associate conversations and issues/pr/tickets/whatever, it becomes much easier for conversations to happen whenever they need to (serendipitous interactions ftw) and still get context to team members when they’re available.

This matters because: There is only one system.

Before we get started …

Full disclosure: I am affiliated with StackStorm, the company building StackStorm the tool. That being said, the ultimate goal here is to illustrate the pattern of how to harness the recent chat culture change using an event-driven framework with the hopes of regaining just a modicum of sanity in your daily life. If you’re interested in learning more about StackStorm and how it ties into the overall automated troubleshooting and autoremeditaion space, take a look at our ChatOps Pitfalls and Tips by Dmitri Zimine. That should give you a good background on why we used StackStorm instead of, say, just a small script.

Ok, on to business!

The Sensor

This workflow begins with a sensor. Inside of the StackStorm-Slack integration is a sensor class that connects to the Slack Real-Time Messaging API. The first place to begin is with Sensors. The official Slack pack contains a sensor that uses the Slack RTM to connect to Slack and listen for messages in rooms it is associated with. Each message is then sent as an “event” to StackStorm, and I can create rules that will trap certain events and kick off.

Rules

Now that the sensor is emitting triggers into the system, I need to find a way to take an action when someone mentions an issue or ticket. The mechanism here is via a rule. Rules check triggers emitted into the system via sensors against a series of checks, and then executes an action or workflow if matched. A trigger can match to many rules.

Let’s create a rule to watch Slack for discussions related to reamaze
- Source: https://github.com/stackstorm-packs/st2-crosslink_chat_with_applications/blob/master/rules/crosslink-slack-to-reamaze.yaml
The first element in the criteria block is trigger.text. In the rule, the trigger itself is just referred to as trigger as opposed to slack.message.text. We want to see if the text properly contains a pattern related to our reamaze issue tracker. I chose contains out of the large list of comparison operators, and made sure the pattern matches what I’m looking for.

Last but not least is the action block. This block is basically the next operation. Here, I can choose a single action or a workflow to kick off, and even grab data from the trigger payload to pass to the action. In this case, I opted to create a new workflow for my purposes here, and made sure to grab a few keywords that I needed to do processing.

At this point, I have a rule matching and now I need to create the action necessary to process the trigger.

Actions and Workflows

Next, we get to creating the actions. The goal is to ensure that anytime a discussion randomly breaks out about a re:Amaze support ticket, that @estee-tew posts the Slack permalink to the support ticket. With the trigger payload extracted in the above rule, the workflow will need to:
- Take the text of a user comment and extract reamaze issue URL.
- Calculate the Slack Permalink URL of the matched message from the collected data.
- Post the Slack Permalink on the matched reamaze issue ticket.
Inside the reamaze pack, I can see that I have the ability to create_message. This action takes three parameters: slug,message, and visibility. In our rule above, the action that was kicked off when the criteria matched desired slack messages is stackstorm.crosslink_slack_to_reamaze. As of right now, this does not exist, so that is the next step. For brevity’s sake, you can take a look at the action metadata on GitHub.
```
---
chain:
  -
    name: "get_permalink"
    ref: "stackstorm.get_slack_message_permalink"
    params:
      channel: "{{channel}}"
      timestamp: "{{timestamp}}"
    publish:
      permalink: "{{get_permalink.result}}"
    on-success: "sanitize_message"
  -
    name: "sanitize_message"
    ref: "stackstorm.sanitize_slack_message"
    params:
      text: "{{text}}"
    publish:
      sanitized_text: "{{sanitize_message.result}}"
    on-success: "get_reamaze_slug"
  -
    name: "get_reamaze_slug"
    ref: "stackstorm.get_reamaze_slug"
    params:
      text: "{{sanitized_text}}"
    publish:
      slug: "{{get_reamaze_slug.result.slug}}"
    on-success: "crosslink_slack_to_reamaze"
  -
    name: "crosslink_slack_to_reamaze"
    ref: "reamaze.create_message"
    params:
      slug: "{{slug}}"
      message: "{{permalink}}"
      visibility: "internal"
```
- Source: https://github.com/stackstorm-packs/st2-crosslink_chat_with_applications/blob/master/actions/workflows/crosslink_slack_to_reamaze.yaml
This is a simple Action Chain, inasmuch as it just does one task after another. The tasks here are designed to be small and portable so they can be reused. Let’s quickly inspect each of the actions and walk through what it is that lies before us now.

Step 1: Permalink to chat history

The goal is to create a way to crosslink a Slack permalink, so let’s start there. This starts with the get_permalink action above. While the history permalink is not in the trigger payload (or even in the official API, for that matter), Slack permalinks actually are not too terribly difficult to figure out. The first action takes two parameters (channel and timestamp), and then spits us out our permalink. We know we’re going to publish the permalink variable that now can be globally used in the workflow in the future. In addition, the next step takes us to the sanitize_message task. You can take a look at the python code for this action upstream.

Step 2: Get support issue data

The next step actually happens in two tasks: sanitize_message and get_reamaze_slug. The immediate next step,sanitize_message, is necessary to clean up the output from Slack. In the message payload, URL data is sent to us as a special “escape sequence,” which doesn’t do the rest of the actions much good. This action, detailed below, is simple enough to be reused in several other workflows. Again, take a look at the action itself: The run() method in this python-runner task is the entry point from StackStorm, and this cleans up the text and returns it back as a plain URL, which we can then pass to the next action, get_reamaze_slug. This returned information gets us what we need to call our final action, reamaze.create_message. We’re able to publish the permalink slug that was shared and discussed in chat. Now we know what is being discussed.

Step 3: Post the crosslink

In this step, a the link is actually created. Here we are! The finish line! Woot! The only thing that is essential to do is to make sure we only set the note as an Internal Only note to avoid sending weird links to our friends. The next step is thecrosslink_slack_to_reamaze action. At this point, we have all the data we need, so it’s just execution.

Permalink from Slack. Crosspost to re:Amaze

and now, with GitHub…

The premise is simple enough. Included in the upstream repository also includes examples for how to setup similar context mapping with StackStorm. Take a look at https://github.com/stackstorm-packs/st2-crosslink_chat_with_applications. Same process, code reuse, and the same end effect.

Unknowns
- This workflow is not for everyone.
- We expose internal-only links that are not accessible by users, and it may be confusing to see random links in issues around GitHub. Why?! What are they?!
- Aliens!?
There are many more that will come up, but the key factor to address here is that it’s not difficult to put this together, and it’s not that difficult to change. And that’s ok. We’ll have questions to be answered, but being able to try something out super quickly was indeed satisfying. (In truth, the workflow went up faster than this blog. :P)

Wrap-up

For many reasons, it isn’t feasible to capture many fluid conversations in many different tools. The answer is not to move data around, but to leverage humans and provide them a helping hand. This is by no means a solution, but it does provide less friction in the daily work. Over time, add enough of these friction reducers, and then suddenly it’s no longer a panic issue. This also reinforces the idea that there is not a collection of systems, but rather a single system. The single company. The tools you selected are obviously necessary, as we defined at the beginning, but tools should not be dictating the communication structures of your teams, but rather informing them. Removing the ability for silos to form allows data in both bits and ideas to flow and move around. This can even be expanded to do much more.

Until next time!

About the Author/James Fryman

Now a senior DevOps engineer at StackStorm, James most recently worked at GitHub assisting in the development and curation of systems scaling within the Operations group. James is also a frequent speaker on the topic of automation at conferences throughout the world.

Twitter: @jfryman

LinkedIn: https://www.linkedin.com/in/jamesfryman

email: james@fryman.io / james@stackstorm.com
January 29, 2016
Testing: Mind the DevOps Gap
If DevOps is a continuum, it starts with planning and development, and ends with deployment into operations. Much of the focus in DevOps and within the DevOps toolchain has been on application build automation (development) and deployment of apps into operations. But, for DevOps to pay off, there must be a continuous flow and automation from development all the way through to operations, and that means providing automation for the steps in between these two.

What is in the gap between development and production delivery? Testing. Not surprisingly, when Gartner surveyed its clients in 2015, more than 50 percent of them ranked the need for test automation as one of their top priorities for DevOps success. This really illustrates the recognition that DevOps cannot succeed if only one part of the DevOps continuum is automated. Companies that have started to focus on DevOps recognize that they must “Mind the Gap.”

Closing the Testing Gap

Why is automating the various testing steps (regression, performance, stress, GUI, QA, interoperability and security testing) so difficult? There are five key components that must be automated successfully:
1. The infrastructure – It starts with one very important characteristic critical to testing that is not automated – the ability to mimic the infrastructure in which the software (or hardware) being tested is expected to run in when it gets to production. Having the ability to give each tester (or set of automated tests) their own personal replica of the target production infrastructure—a “sandbox”—is critical to ensuring the software coming out of test can be deployed into production automatically and continuously. Automating tests is not nearly as difficult as automating the underlying infrastructure in which those tests run.
2. The production environment workload – Often overlooked in automating testing is mimicking the workloads that would be common in production. This includes the network traffic, other application workloads and network security profiles. These activities need to be automated within the sandbox to create a more realistic environment for testing.
3. Test automation – Of course, the tests themselves also must be automated and there are a variety of tools to assist in this process. As software gets more complex, automation continues to be a challenge, with mobile testing replacing GUI testing as the most challenging type of testing to automate.
4. Reporting and result analysis – To provide continuous automation from development through testing to delivery, it is important to see and analyze test results automatically.
5. Tool Integration – Finally, automation into and out of testing needs to be enabled. This means that sandboxes and test automation suites need to be API-driven so they can be started by a previous tool in the DevOps tool chain and can also initiate a tool that follows testing in the tool chain.
DevOps projects tend to start in one part of the continuum from development to operations. There is nothing wrong with taking this approach. However, it is also important to “Mind the Gap” and work to expand automation across the continuum continuously. One way to ensure that automation can expand easily is to deploy sandbox technology across the continuum, beginning with development and continuing through configuration and release management. The sandbox ensures that at each step, the production configuration and workload is being replicated.

Sandboxing technology has been used in development in the past, but is relatively new to the entire DevOps process. As more companies move to continuous integration and continuous deployment, however, the need for sandboxes is growing.

The sandbox should provide the following:
- The ability to create an accurate replica of the real production environment that deployment is intended for. This can include the physical, virtual and cloud infrastructure as well as applications, network traffic and load.
- The ability to initiate a sandbox via APIs so that the sandbox can be triggered by DevOps tools as an integral part of a complete end-to-end DevOps automation.
- The ability to automate DevOps processes inside of the sandbox (e.g. automated regression testing), as well as to automate the teardown of the sandbox and trigger the next step in the DevOps cycle when those processes complete.
- Business intelligence about everything that happens inside of sandboxes so that DevOps processes can focus on continuous improvement.
- The ability for many people to have their own sandboxes running simultaneously with isolation in shared labs.
DevOps depends on continuous automation from development, through test and QA, to configuration management and production deployment. Sandboxes provide a common automation environment that can be used at each step of the DevOps cycle to close the gap between development and deployment.

About the Author/Joan Wrabetz

Joan Wrabetz is the CTO for QualiSystems. Most recently, she was theVP and CTO for the Emerging Product Division of EMC. Joan received her MBA at the University of California, Berkley, and MSEE at Stanford, and a BSEE at Yale. She has held teaching positions at the University of St. Thomas, St. Mary’s University and the University of St. Thomas, St. Mary’s University. Joan holds patents in load balancing, distributed systems, and machine learning classification and analytics. Her experience inclues: founder and CEO of Aumni Data, CEO of Tricord Systems, Vice President and General Manager for SAN operations at StorageTek, Founder and CEO of Aggregate Computing, Management and senior technical positions at Control Data Corporation and SRI International, Partner with BlueStream Ventures.
January 28, 2016
Are You Ready for Your DevOps Transformation?

You’re done with missed release deadlines, long release cycles and risky releases. If your objectives are continuous application delivery to achieve fast feedback loops and reduced waste, DevOps practices provide the means to reach them.

DevOps is all about agile transformation, which reaches beyond agile development into production to achieve continuous delivery. DevOps practices provide help for the necessary next step after agile development to leverage the full potential of agile and avoid massive post-delivery changes through the development teams, but before they are ready to go into production.

The challenge is to navigate that DevOps transformation—and make it happen faster and at less risk. The speed and direction of that transformation depends on individual circumstances—for example, the type of technology you have deployed, the shape of your organization structure and processes, and what your overriding business and IT requirements are.

Beginning the Transformation Journey

Only once you have assessed your organization’s current DevOps maturity and orientation can you begin to scale your DevOps implementation—and move faster on the transformative journey toward continuous delivery. In other words, to know where you’re going, you need to know where you are now.

By measuring your status across each of these dimensions on a scale of Level 0 and Level 4 (see diagram), you can benchmark where you are today and derive recommendations and measures for future improvements.

Culture and Strategy: DevOps requires a strong vision and strategy and its success will depend on the awareness, knowledge, skills and motivation of your employees. This pillar addresses the effectiveness and alignment of your awareness-building and enablement programs as well as your incentivation system with regard to agility in all involved units, dev and ops. It also includes a snapshot of the sentiment and motivation of people to make such a change reality.

Automation: This pillar addresses the maturity of your organization in terms of IT automation as an important prerequisite for continuous delivery. Both the application architecture and the DevOps automation tool chain are assessed. Relevant automation capabilities in application configuration, provisioning, deployment, test, infrastructure and application monitoring are included in the assessment. The maturity is assessed across the tree layers infrastructure, platform and application, and by technology stack—for example, your SAP platform, .NET or Java stacks—and then combined into a single level.

Structure and Processes: The current organizational structure and methodologies and processes in use within all involved units are assessed with regard to their effectiveness for continuous delivery. This focuses on their agile fit and maturity. Governance and how agile teams and processes are embedded into the broader organization are part of the assessment scope as well.

Collaboration and Sharing: Collaboration and sharing between development, operations, infrastructure and middleware teams are crucial to accelerate the delivery process and make it leaner. The assessment looks at particular sharing vs. redundancy of tools (e.g., tools used for deployment), information (e.g., the status of a package in the delivery pipeline), processes (e.g., an ITIL release process and a development release process) and functions (e.g., a release engineer in development and a deployment expert in production).

Now you have the facts at your fingertips. The DevOps Maturity Assessment Service presents all of this as documented findings, to include a series of recommendations on how you can scale and mature your DevOps activity.

January 28, 2016
DevOps Pillow Talk

— ROELBOB

January 28, 2016
DevOps Chat: Rosalind Radcliffe and Bimodal IT

I had the pleasure of sitting down with IBM distinguished engineer Rosalind Radcliffe the other day to talk about bimodal IT, systems of engagement, variable speed DevOps and IBM’s upcoming InterConnect 2016 event. I have interviewed Rosalind many times over the last few years and it is always informative and interesting. I hope you find it to be so as well.

Below is the SoundCloud streaming audio interview, followed by the transcript of our talk. Enjoy!

Alan Shimel:                Hi, Alan Shimel here with another DevOps Chats, and my guest is – for this session is a friend of mine, Rosalind Radcliffe of IBM. Rosalind, welcome.

Rosalind Radcliffe:      Thank you.

Alan Shimel:                Rosalind, I think you’ve appeared on DevOps Chats before, and of course we have done webinars and videos together, and so many other things. But for members of our audience who may not be familiar with who you are; do you want to give a brief background?

Rosalind Radcliffe:      Sure. So I’m Rosalind Radcliffe, I’m a Distinguished Engineer at IBM, and I’m responsible for our DevOps strategy for Enterprise Systems. So I am not only responsible for driving our product direction, but I really spend a lot of time with clients helping them with their DevOps transformations for their Enterprise Systems – mostly mainframe, and their systems of record.

Alan Shimel:                Excellent. Rosalind, of course, we’re going to talk a little bit about today about this term that’s been creeping up, Bimodal IT, and then I want to spend some time talking to you about the upcoming InterConnect Conference as well. Maybe we can combine Bimodal IT and InterConnect; I don’t what we would call that, but Trimodal. Anyway, so Rosalind in talking offline before we jumped on here I think we both agreed that we weren’t big fans of the term Bimodal IT, and all that seems to have entailed now. Do you want to share with our audience why you may not be a fan?

Rosalind Radcliffe:      Yeah. I think the term and the way it’s used isn’t implying that there is a defined slowness for the systems of record. I think it’s important instead of saying Bimodal to say more variable speed IT or something that implies that the systems may move at different speeds. I’m not going to disagree with that, but it’s not that one is inherently faster and one is inherently slower. It’s that hopefully for your system of record you’ve built that as a set of API’s or services, and so you don’t have to change the services as often as you need to change that system of engagement to entice the users to stay connected.

So it really should be about how the systems of record and the systems of engagement can work together through loose coupling, and through proper services. I do think that is going to happen; there are going to be different speeds at different times. Sometimes, honestly, the systems of record might be moving faster than the systems of engagement, because there are changes needed – regulation changes, etc. But it’s – we need to pay attention to it from that standpoint and that’s the reason why I don’t like Bimodal IT. It’s really variable speed.

Alan Shimel:                Yep. The other point that gets me with it is this whole idea of Bimodal IT, it almost takes that we have two tracks if you will, that move at different – or two trains on a track that move at very different speeds. But they never interact; it’s almost – it almost reminds me of civil rights, separate but equal. We have the water fountain for the mainframe guys, and a water fountain for the cloud dudes, and they both serve water so that’s okay. But the mainframe guys can’t drink from the cloud dude’s water fountain.

It didn’t work for civil rights, and – I don’t think it works for IT either. I think a better model when we talk about systems of record, systems of engagement, and this whole world, is more – I call it the Swiss watch model. Where you have gears that turn at different speeds, but they all mesh together in a fine tuned timepiece. To me, that’s a much better model than this idea of separate tracks, if you will. What do you think about that Rosalind?

Rosalind Radcliffe:      I actually think that’s a wonderful way of putting it. Because I think that – it would be a much better interpretation with the gears and the Swiss watch, and Swiss watch timing is always excellent with their gearing system; so that’s exactly what it is. The teams need to work together, and they need to be using the same tools, the same practices, the same processes, and each system needs to go at the speed that is required for the changes that they need to make. But they’re obviously interacting. Your systems of engagement is nothing without your systems of record. So they need to interface properly, they need to work together to provide this end-to-end solution for their end users.

So they have to be collaborating, and I – honestly I think the organizations that have brought the teams together, that do the systems of engagement and the systems of record into one team, actually do the best. They’re the most efficient; so they may have variable ability in the speed they’re delivering on different parts. But they’re all working together, they’re all collaborating, they’re all one team; not this separation idea. I think your example is very good, it’s not separate, but equal, it’s one team.

Alan Shimel:                I agree wholeheartedly. I’m not here blaming Gartner for pushing this whole Bimodal IT name and paradigm. But, Rosalind at last year’s InterConnect I remember having a bunch of conversations with you and Sanjeev Sharma and Carmen Diardo, and we were using the term variable speed IT. Right?

Rosalind Radcliffe:      Yes, absolutely.

Alan Shimel:                To talk about it – the similar thing, and, of course, I – we’ve heard other people use the term two speed IT. But I think in larger organizations, there’s actually more than two speeds; there’s a lot of different pieces that move at different speeds.

Rosalind Radcliffe:      That’s really the right answer. I really think it’s important have that ability to move at the speed required by businesses – the business demands, and that’s why it’s necessary. I think there’s a lot of thought process about Bimodal IT, because there are still or there seem to be people out there that still think the mainframe can’t move as fast, that it can’t use DevOps practices. I think that’s actually the core of the issue. We have to break down this thought process that the systems of record – the mainframe can’t move as fast, can’t be DevOps. It really can be, and it’s a reality – I guess it’s a hot button in a sense right now. I’ve just spent the last two weeks with two different clients, and this week with one of them – the first principle they put up was that there’s nothing about the mainframe that means it shouldn’t be DevOps. That the first principle is it needs to be DevOps, it needs to take advantage of the same pipeline, the same functions, the same capability to be able to move as fast as required in a reliable, consistent way with all the advantages of automated testing and automation.

Alan Shimel:                Absolutely. Rosalind, let’s turn a little bit to this year’s InterConnect where we will have – whether you want to call Bimodal IT, variable IT. There are out of the 200 or 300, I forget how many DevOps related tracks there, there will be some great ones, and I want to talk to you a little bit about that.

Rosalind Radcliffe:      Yeah, I’m looking forward to the event as well, though I’m not ready for it yet. There will be a lot of discussion and a number of sessions, both customers as well as IBMers talking about the variable speed IT or the different ways that different parts of the application development need to interact, and need to work together. One of the clients I was speaking with this week will be there talking about their DevOps development, particularly about how they’re literally building brand new applications on the in COBOL CICS applications using DevOps principles. So I look forward to all the different client discussions that are held there, bringing their teams together, and I think your Swiss gear interpretation is a good way of putting it. Because that’s what they’ll be talking about, how they’ve geared the teams together to be able to work together to provide the value the company needs.

Alan Shimel:                Absolutely. Rosalind, are you allowed – can we mention to our audience what company is that presenting? Are you allowed to say at this point or no?

Rosalind Radcliffe: So in that case, it’s Rabobank, because they’re published as a session speaker; so they’ll be speaking. There are actually quite a few. Rabobank’s one, UBS is another; there are numerous speakers scheduled – client speakers scheduled who are going to be speaking about their efforts and their transformations.

Alan Shimel:                Rosalind, what about you? I’m sure you’re speaking.

Rosalind Radcliffe:      Yeah, I have quite a few sessions that I’ll be discussing DevOps overall, working with clients and their transformations, the capabilities available, as well as having more discussions on the ops side of DevOps. I think one of the things that has been an interesting challenge is the how do we really bring ops into DevOps since we really do have ops organizations. That’s going to sound really strange, but when we think about DevOps a lot of the discussion has really focused on automation and delivery, not really focused necessarily on running the systems. So I’m trying to help some of the discussions bring more of the ops side in. How do we really get the ops collaboration coming in? How do we tie the teams together from a complete end-to-end standpoint?

Alan Shimel:                Excellent. Rosalind, it’s hard to pick among many, but what do you – besides the ones you just mentioned, give our audience – if they’re wondering should I go, should I not go, not sure; what are the two or three biggest either sessions or points of learning that you think people should know about to jump in here?

Rosalind Radcliffe:      Honestly, I think there are too many sessions to name, but the way to think about it is there are too many sessions to name. There are lots of client sessions, we’re going to be discussing their experiences. So the value out of a conference like this, one of the key values is the ability to hear from your peers, and to network with your peers to understand how they’ve done this, how they’re getting value. That’s the best way to learn from other people who are already experienced or who are experiencing. You’re going to learn from people who are headed for you, and you’re going to be helping people who are behind you. So it’s the networking, it’s the opportunity – hear those sessions, and the opportunity to meet all of the different people who are working in this space.

I think that’s the value of conferences like this; the chance to network and take advantage of that. Many people I’ve met in prior InterConnect’s have said it’s the collaboration, it’s the conversations, it’s the meeting of people that have given them the most value. Attending the sessions is also very important, but it’s the sessions that give them those contacts. So they learn in the session, and then they have this contact that allows them to continue to discuss. You always get fun – learn something new, you get some fun stories, you get something you’re really going to be able to take back and provide value to your organization.

Alan Shimel:                Absolutely. Rosalind, believe it or not we’re just about out of time; we probably have gone over. As usual it’s always — when this happens whenever we talk I apologize. But, I am looking forward to seeing several of your sessions at InterConnect, as well as I should mention – this is a quick plug, I am moderating a session myself on what DevOps will look like in the next three to five years, and I have none other than Gene Kim on the panel with me, which should be a lot of fun. So if anyone listening is attending Interconnect, please come on down for that one.

But, Rosalind, it should be quite a show, and I’m looking forward to how this whole Bimodal IT, variable speed IT, how it plays out. We’ve said it before, mainframes aren’t going anywhere, and the new way of doing things like DevOps and Agile and stuff it’s going to influence how we use our systems of engagement, but it’s not going to negate them. It’s always a pleasure to speak with you, and look forward to seeing you in Las Vegas February 21 to the 25^th correct?

Rosalind Radcliffe:      Correct. I’m looking forward to it as well, and as you mentioned the panel discussions, those are always wonderful. I’m hoping that I can make it to your session with Gene Kim if I’m not in another session myself. So I’m looking forward to it, and it’ll be a great week.

Alan Shimel:    Absolutely. Rosalind Radcliffe, Distinguished Engineer IBM, thanks for joining us today on this edition of DevOps Chats

January 28, 2016
You Say You’re Doing DevOps, But What Does That Mean?
From recent conversations I have been having, it is clear that DevOps is top of mind for many. Out of the 40 or so customers I have spoken with recently, the overwhelming majority brought up DevOps during our conversation. They believe they ought to do DevOps, but they wanted me to help them define it and point the best way to get started.

From my experience, many claim to be “doing DevOps,” but when you drill in, you’ll find wildly varying degrees of what this means. If a team is doing anything at all within the larger DevOps value chain, such as testing their software, they often believe they’re doing DevOps.

Our latest survey on the implementation of DevOps points out how easy it is for companies to say they’re doing DevOps but how difficult it is to do DevOps effectively. There’s widespread agreement among the respondents on all the different things that should get done, but very few people are making significant progress in most of them. If you ask about specific DevOps success factors, very few people are doing them.

Understanding, Then Doing DevOps

Why is DevOps so hard? In general:
1. companies don’t know how to do it
2. companies aren’t sure what it is
3. it’s too hard given the existing organization and/or culture
4. too many jobs and people identify with existing tools and technologies
5. there may be regulatory issues
6. there’s a lack of leadership on what needs to get accomplished and the direct impact on users/customers
The biggest issue usually is the organizational structure. People within IT are working in roles that have institutionalized the separation of dev and ops for 20 or 30 years, and suddenly this must change. Ops, in particular, has a process that is somewhat opaque, but now it has to be transparent, ops teams have to coordinate closely with the development teams, and they are being measured on totally different things. That’s a huge shift.

Going back to the results of the survey, if you told me 20 percent of companies are doing some element of DevOps exceptionally well, I would agree with that. If you tell me 20 percent of companies are doing DevOps end-to-end the way I think it ought to be done, I would say that number is probably closer to 5 percent.

The definition of DevOps makes all the difference. To me, DevOps focuses on the distance between the idea and the customer, whether that idea is a feature, an application or a business model. The purpose of DevOps is to optimize that distance.

I use the word “optimize” for a very particular reason, because there are several different dimensions beyond speed that we need to think about. We also need to optimize for reliability, or perhaps it is appropriate to think of that as quality. Efficiency is another dimension: How much does it cost to run that pipeline? Finally, agility: If I have to make a change based on the customer feedback or the market conditions, how rapidly can I change?

Based on your customers and what you’re trying to achieve in your business, you might optimize for those four dimensions differently than some other company. In some cases, a company might choose to emphasize speed, rolling out a new release every single day. In other cases, reliability, efficiency or agility might be given more weight.

The purpose of DevOps is to make speed, reliability, efficiency and agility a given so companies can focus on digital disruption and serving their customers better—we can see that in the survey results. If we also look at the 20 percent that are farthest along in implementing DevOps, we see their most important metrics are customer-facing metrics. In other words, it is clear that with the emergence of companies focused on business insight analytics, more organizations want to know if their application is meeting the needs of the customers as it was intended.

This is where the cultural and organizational challenges of DevOps come into play. If the ops team owns ops-related metrics, and the dev team owns dev-related metrics, then the organization is probably losing its focus on the customers. Those internal, traditional metrics are not going to get organizations to the Promised Land. You may have developed a bunch of code faster because you’re agile—and that’s great—but it’s only the first step. Instead, if we turn this around and say, “We expect this application to generate a million dollars of new revenue every four hours,” that’s a totally different mindset, and you have a much better chance of DevOps success. The app is either generating the revenue or not, and it’s the feedback you get based on the usage of the application that tells you what else you need to do.

ING is a great example of a company that has a group of people who are focused on metrics that track the distance between the idea and the customers, and they wake up every day with a focus on how to optimize that distance. The rest of the company is then organized and culturally aligned to deliver against that.

When you talk to most companies, you’ll find that there are elements of agile development, code pipelining or release automation that they do very well. These companies are taking a vertical or functional slice—such as test automation or release automation—and concentrating on optimizing there. That just gets us back to where we started our discussion, with everybody saying they are doing DevOps but no one doing it successfully. A better way would be to take an application and optimize all of the delivery metrics around that application. Take it all the way, end-to-end, and focus on solving a customer problem. Once that end-to-end distance is optimized, then you can apply what you’ve learned to other applications.
January 27, 2016