Tag: ibm

  • Machine Learning Put to Work in the Digital Economy

    Machine Learning Put to Work in the Digital Economy

    IBM’s Watson already has a new retail job lined up to get a head start saving for its holiday spending this season. (Hey, even artificial intelligences appreciate buying gifts.) And Macy’s is hoping its customers appreciate its “Macy’s On Call” pilot, which combines Satisfi’s communications platform and IBM Watson cognitive technology for machine learning. Macy’s On Call creates an in-store companion on mobile devices that aims to help improve the service of customers. The pilot will be in 10 stores across the United States.

    According to the retailer, the Macy’s On Call app will be accessed via a mobile web browser. Customers can ask the app questions in natural language, such as where certain brands are located, and get customized answers. Customers also can learn about specific in-store services available at each test location, including personal shoppers, pickup counters or the location of restrooms. Macy’s hopes the app will also help them learn more about the services and features that shoppers want.

    Since each Macy’s store is different, and consumers increasingly prefer mobile platforms, the system will evolve as it learns more about each store’s customers. “At Macy’s, we remain focused on identifying, testing and supporting new ideas and approaches that will help elevate service to our customers through technology. With an eye toward innovation, we are moving fast to test and scale up pilot programs that help enhance their experience with us,” said Peter Sachse, Macy’s chief growth officer, in this statement.

    “This program, in partnership with Satisfi and leveraging the power of IBM Watson, will help us explore new ways to engage one-on-one with customers in-store, providing them another level of service right at their fingertips,” Sachse added.

    “Bringing Watson into a retail store setting presents an opportunity to engage with the consumer on a variety of levels,” said David Kenny, general manager of IBM Watson. “This particular use case takes Watson beyond helping consumers evaluate purchasing decisions, and influences another, equally important aspect of the in-store experience,” Kenny said.

    The first phase of Macy’s On Call recently launched and is expected to run through late fall. Of course, Macy’s has the potential to learn an extraordinary amount about its customers’ preferences through this program—preferences that otherwise wouldn’t have been so easy to learn without the aid of the Satisfi platform or Watson’s machine learning. Macy’s also may learn how to more rapidly improve its stores, manage inventory most effectively, and more quickly learn what is and isn’t working in its retail environments. That is, of course, if it can make Macy’s On Call engaging enough for customers to want to try, as well as provide enough value for them to want to use over time.

    Macy’s wasn’t the only one recently to make a significant machine learning announcement and the innovative use of technology. Google said it is using software from its DeepMind subsidiary to significantly cut the costs to power its data centers. According to DeepMind co-founder Demis Hassabis, two years ago Google began applying machine learning  to operate its data center more efficiently. And over the past few months, DeepMind researchers began working with Google’s data center team to significantly improve the system’s utility. “Using a system of neural networks trained on different operating scenarios and parameters within our data centers, we created a more efficient and adaptive framework to understand data center dynamics and optimize efficiency,” the Google team wrote in this blog.

    According to Google, the team cut power usage in their data centers by several percentage points, which translates into a 15 percent improvement in power usage efficiency. These are exactly the types emerging technology applications CIOs and chief digital officers need to focus on if they are going to succeed, as we covered in our post, “Digital Transformation Strains Traditional IT.”

    According to the McKinsey report, “Digital America: A Tale of the Haves and Have-Mores,” the United States is digitizing so rapidly that most are scrambling to adapt. The race to keep up with technology and put it to the most effective business use is producing digital “haves” and “have-mores”—and the large, persistent gap between them is becoming a decisive factor in competition across the economy, the report said.

    According to the report, “Digitization is happening unevenly, and users with advanced digital capabilities are capturing disproportionate benefits. The companies leading the charge are winning the battle for market share and growth; some are reshaping entire industries to their own advantage. But many businesses are struggling to evolve quickly enough. Workers in the most digitized industries enjoy wage growth that is twice the national average, while the majority of U.S. workers face stagnant incomes and uncertain prospects.”

    Clearly, organizations such as Macy’s and Google making moves want to ensure that in the year ahead they want to be the digital “have mores.” Businesses that aren’t making their own similar moves to employ machine learning to cut costs, improve customer experiences, or find other ways to advance the business may not find themselves the “haves” but the “have nots.”

  • Separate but Equal: Not Equal and Not the Right Way

    Separate but Equal: Not Equal and Not the Right Way

    The DevOps Enterprise Summit in London provided another opportunity to speak to many clients about their organizations’ DevOps transformations. The key message is, “It’s all about people and culture,” but how do you make those changes? In session after session it was clear the source code manager (SCM) is central to this transformation. All clients included the SCM as a key part of the solution. SCM’s key value is as a common place to version all the artifacts from the source code to the system configuration. As such, it must provide visibility to all to allow for sharing and collaboration.

    So how can z/OS participate in this transformation if its source code is locked away in some host-based SCM? The answer is, It doesn’t. In my interview with devopsy.kinsta.cloud editor Alan Shimel, we discussed this issue and he related it to the idea of separate but equal, which we all know does not work. What’s worse is separate but equal was really never equal, and the same is true for the host-based SCM to which the z/OS source code is relegated. I have asked many companies if they would move their distributed source to those host-based SCMs, and the answer is always, “Of course not; it does not provide what the distributed teams need.” How can it provide what the host teams need? It doesn’t.

    Separate but equal does not work; it’s never equal and it isolates people. That’s not the way we should be looking at our z/OS source code. It’s critical to the business and should have the best support and capabilities, not the least. Now is the time to move to modern tools and processes and stop isolating the z/OS environment from the rest of the development environment.

    The key is to focus on collaborative management solutions that do not separate, but bring teams together by providing one environment that all teams can use together for cross-platform collaboration. Various solutions include all the capabilities companies need to provide the modern agile development environment including z/OS.  No separation—the z/OS code is in the same repository as all the rest. In these tools, the modern dependency-based build provided for z artifacts is based on Ant technology, so it can be extended just like existing build tools. With this tooling you can use your existing continuous integration pipeline and plug z into it.

    It’s time we move z/OS development into the 21 century.

    Read the thought leadership paper on DevOps for Enterprise System POV to know more on the essential tools and process that can enable disruptive technologies and an innovation at the speed the business requires.

    About the Author / Rosalind Radcliffe

    Rosalind
    Rosalind is a Distinguished Engineer within the IBM Rational organization. She 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. In addition, she is responsible for the architecture for the Collaborative Management capability for Enterprise solutions. This includes UrbanCode Deploy and Rational Team Concert’s support for standard Mainframe development activities. She is a member of the IBM Academy of Technology and a Master Inventor. Prior to Rational, she was in Tivoli responsible for the SOA Management Strategy for IBM. Connect with Rosalind on LinkedIn / Twitter.

  • DevOps Chat: GitHub Enterprise as a Hosted Service, with Jean-Louis Vignaud

    DevOps Chat: GitHub Enterprise as a Hosted Service, with Jean-Louis Vignaud

    I recently sat down with Jean-Louis Vignaud, program manager at IBM, about the new GitHub Enterprise as a hosted service that recently was rolled out on Bluemix. The GitHub Enterprise as a hosted service is a great option for enterprises that, due to compliance or other security requirements, cannot used a shared, public GitHub service.

    This GitHub Enterprise as a hosted service is the first of its type available and is hosted on the Bluemix service as both on-premises and hybrid environments. You can get more info on this at:

    1. Blog : Introducing the first-ever GitHub Enterprise as a hosted service

    2. Video : Benefits of GitHub Enterprise with IBM Bluemix Dedicated

    3. SlideShare: IBM Bluemix Dedicated – GitHub Enterprise

    Also, we will have a webinar that goes into greater detail on this. More info is at: http://webinars.devopsy.kinsta.cloud/scaling-devops-github/

    In the meantime, here is the streaming audio file of this chat, followed below by the transcript of our conversation to follow along.

    Alan Shimel: Hi, this is Alan Shimel, devopsy.kinsta.cloud, and I’m here with another DevOps Chat. Today’s guest on DevOps Chat is Jean-Louis Vignaud, Program Manager from IBM. Jean-Louis, I hope I didn’t mess up that name too bad.

    Jean-Louis Vignaud: No, that’s fine. Thank you, Alan.

    Shimel: Okay. Welcome to DevOps Chat, Jean-Louis, and as I mentioned, you are a Program Manager at IBM, and right now anyway, you’re very involved in working on the GitHub Enterprise as a hosted service offering, and we wanted to talk to you specifically about that.

    Vignaud: Okay.

    Shimel: So, Jean-Louis, I think everyone listening out here is familiar with Git and GitHub, but they may not be familiar with the concept of GitHub Enterprise as a service, so why don’t we start there, if you can explain to our audience a little bit about what that is.

    Vignaud: Okay, so maybe we can start with GitHub first.

    Shimel: Okay.

    Vignaud: GitHub is very well-known, it has probably 15,000,000 users as of today, it’s a very well-known user experience. It’s a collaboration platform, and it’s based on Git, so it’s running on top of Git, but it has many other services on top of Git. And the purpose of GitHub is to provide this collaboration platform that enables people from all around the world to collaborate on a business project, or even a private project.

    And that very well-known collaboration platform is very attractive for enterprises that want to provide the same level of collaboration within their own organization. And so what was introduced by GitHub the end of 2011, early 2012 was GitHub Enterprise. GitHub Enterprise is an on-premises version of GitHub. So, same set of capabilities, but you can install it when it’s on-premises in your—on-premises in your environment, and get it working within your firewall. So that enables teams to—you know, to enable organizations and different teams to collaborate among each other in a safe way.

    So that’s the background, and where we were standing before we introduced our offering.

    Shimel: Mm-hmm, and [Cross talk]—I’m sorry. I didn’t mean to interrupt.

    Vignaud: Yeah, so what I was going to say is that, as usual, inside an organization, as soon as you have to install your product, you have to run it, you have to manage it, you have to provision your infrastructure, you have to have the people set up and standing to manage the GitHub Enterprise offering, meaning doing the backup, doing the upgrade, monitoring its running and doing everything that needs to be done in order to comply with the enterprise security requirements.

    And that requires time, and most of an inside organization, you know, people are looking to move to the cloud, benefit of the cloud facilities, which they could find in GitHub today, but it’s a public cloud that does not meet the security requirements of an organization, and they would want the same GitHub experience, but within their organization. And this is where we come with our service offering around GitHub Enterprise—providing the user experience of GitHub within the organization while still managed by IBM.

    Shimel: Got it. And just to make clear, Jean-Louis, as far as I know, IBM is the only one actually offering this GitHub Enterprise as a hosted service, correct?

    Vignaud: Yes, this is a first-of-its-kind offering. I know if you look into what GitHub provides, GitHub provides GitHub Enterprise so you can run it on premise. You also can install it on infrastructure as a service, so you can run it inside AWS, you can run it inside Azure, but there was no one providing a service offering around GitHub Enterprise. So, with IBM, it’s hosted and managed by IBM so the “and managed” is unique.

    Shimel: Got it. And another thing I just want to emphasize, because as we were speaking about before we started today’s broadcast was, you know, this is in partnership with Git, right?

    Vignaud: Yes, that’s a partnership with GitHub, yes. We announced the partnership at InterConnect early this year in February, and so since the announcement, we have been working and creating this offering. So it took us 12 months to build it and to release it.

    Shimel: Understood. And I think that’s important, because you know, it’s one thing to just take some open-source project and offer it as a hosted service, right? Anyone could do that, it’s open source.

    Vignaud: Yes.

    Shimel: But to really have the cooperation with Git behind this really gives, I think, the best chance for enterprises to have their own Git environment really, truly as a hosted service.

    Jean-Louis, I wanted to talk about another aspect of this offering, and that is, as it’s part of an Integrated Bluemix Dedicated offering as well, right?

    Vignaud: Yes.

    Shimel: So let’s start off with, what is Bluemix Dedicated?

    Vignaud: Okay, so IBM platform-as-a-service offering is Bluemix. So, Bluemix, it consists of a huge set of services, for mobile application, for cognitive applications, so about more than 150 APIs organizations can use to build a cloud-native application, to integrate these applications with a back-end system. And so Bluemix is available in the public cloud, but as well, it’s available as a single-tenant dedicated cloud for the customer.

    So that’s Bluemix Dedicated. So, meaning, it’s a Bluemix for our customer with all this API, all these platforms that enable you to build and run your application. It’s based on Cloud Foundry, it supports containers, Dockers and so on. So it provides a very extensive set of technology that enables organizations to quickly build applications.

    As part of Bluemix, there are a set of DevOps services, so tools we provide to help organizations build those Bluemix applications. And this is where our GitHub Enterprise offering sits. It’s a DevOps offering, part of Bluemix Dedicated.

    Shimel: Got it. So, Jean-Louis, this is—I mean, unfortunately, we only have 12 to 15 minutes here, but there’s a lot of layers that we can peel back it of what one can do with this GitHub Enterprise offering, you know? And especially, in my mind—look, if you’re developing applications and you just want to have your whole platform as a service with best-of-breed stuff such as a Git, such as a Cloud Foundry, all of these elements that give you a best-of-breed application development in platform as a service forum, it seems that all the pieces are here to come together. And it’s a great time to be alive. It’s a great time to have to—you know, if you wanna develop applications, to have that at your fingertips.

    Vignaud: Yes, and in the context of Bluemix Dedicated, single-tenant, completely integrated with your enterprise network, so it enables you to safely integrate with your back-end system. So you really have a very advanced platform enabling you to develop in a safe way; you know, very innovative applications.

    Shimel: Yeah. So, Jean-Louis, two questions for you. No. 1, in terms of advantages of using the GitHub Enterprise hosted versus the public Git, that GitHub that so many of us, I think 50 million is the number of people use—the obvious advantage is, this is a more secure environment, it’s yours only. But are there any downsides? Is there any kind of features not available in the hosted service that would be available in the public service?

    Vignaud: No, not really. You know, the GitHub Enterprise has been designed to provide the same user experience as GitHub. I would say that the value of GitHub Enterprise, it’s the user experience of GitHub, but you can run it for you, so it’s a single-tenant for you as a customer, leveraging the cloud infrastructure from IBM, you can run it in a data center where you want to, geographically you can localize it in the country where you belong. So if you have compliance requirements requiring you to host your source code in-country, you can do that.

    So, I would say, no limitation and much more flexibility when it comes to the deployment of the offering.

    Shimel: Excellent. Next question, I just wanna make sure—is this publicly available today? Because I remember—

    Vignaud: It is, yes. It is available today. We announced it on the 17th of June. We officially announced it on the 17th of June, so yes, it is available today, and any Bluemix Dedicated customers can use it as part of the offering.

    Shimel: Oh, excellent. And I should also mention, Jean-Louis, that in the near future, actually—I think we’re finalizing scheduling right now—we’re actually gonna do a full webinar with GitHub and IBM, where we’re gonna explore a little deeper into this offering and for those of you listening who may be interested, I strongly, strongly encourage you to attend that webinar.

    But Jean-Louis, if people don’t want to wait for the webinar, I know IBM has put up several content pieces where people can get more information from this. One is a blog introducing the GitHub Enterprises service, there’s a video that shows the benefits, and I think there’s also something up on SlideShare about IBM Bluemix Dedicated and GitHub Enterprise. I will try to—

    Vignaud: Yes.

    Shimel: — yes, I will try to include the links to those when we publish this chat, but again, I strongly—if you have questions about his, if you’re a Git user and thinking you’d like your own GitHub Enterprise dedicated service, I’ll try to put those in there.

    You know what, Jean-Louis, unfortunately we’re just about out of time. Is there anything you want to add?

    Vignaud: I think this is fine. Thank you very much, Alan, for the interview here.

    Shimel: Thank you.

    Vignaud: I really look forward to have many customers for this offering.

    Shimel: You know, I think it’s something the market needs. It’s good to have that. As I said, it’s a great time to be a developer today, right? So many tools, so easy to use.

    Vignaud: Yes.

    Shimel: Anyway, Jean-Louis Vignaud, Program Manager at IBM, thanks so much for joining us today, and we look forward to hearing more about GitHub Enterprise as a service.

    This is Alan for devopsy.kinsta.cloud. Thank you for listening in, and we’ll see you on the next DevOps Chat.

    Vignaud: Thank you.

  • DevOps Chat: Sanjeev Sharma, DevOps Enterprise Summit London 2016

    DevOps Chat: Sanjeev Sharma, DevOps Enterprise Summit London 2016

    I had a chance to speak with CTO of technical sales of DevOps for IBM right before the recent DevOps Enterprise Summit in London. I also interviewed Sanjeev at the DOES London event and that video will be available shortly, but I wanted to give you a preview of what he was speaking about in case you didn’t get a chance to attend DOES London 2016.

    Below is the audio file of our chat and below that is a transcript of our conversation.

    Of course Sanjeev is a frequent contributor  to devopsy.kinsta.cloud and you can read more of his articles here.

    Alan Shimel:                Hi, everyone, Alan Shimel, Editor in Chief of devopsy.kinsta.cloud and we’re here with another DevOps Chat. Today’s guest is Sanjeev Sharma, CTO of Technical Sales of DevOps IBM. Sanjeev, I mangled that probably. Why don’t you correct me?

    Sanjeev Sharma:         Sure. No, Alan, you got it right. My title is CTO for DevOps Technical Sales. I’m a Distinguished Engineer here at IBM and happy to chat with you, my favorite topic, DevOps.

    Alan Shimel:                Yeah and always happy to have you on, Sanjeev. Sanjeev, today, specifically, I wanted to talk a little bit about the upcoming Gene Kim’s DevOps Enterprise Summit event taking this Thursday and Friday, June 30 and July 1, over at the Hilton Metropole in London, England. You, of course, I think are handling or moderating a panel at the event. Correct?

    Sanjeev Sharma:         Yes, sir. Yes, Alan. I’m really excited about it, and as you know, Gene has been hosting these events. This is his third year, if I remember correctly, but this is the first time he’s having it in Europe, so very excited about it. IBM, of course, is a sponsor for the event, but I also have the privilege of hosting a panel.

    On the panel, we’ll be focusing on how to assess a large enterprise’s readiness to adopt DevOps. People ask about – ask the question, “How long does it take to get from here to London? I live in Washington, D.C.” Well, I have to ask them the question, right? First of all, where in London do you want to go? Secondly, where in Washington, D.C. do you live? It can take you about an hour just to get to the airport. Knowing your Point B, where you want to go, and knowing where you are, your current state, your Point A, is very important. We will be focused on that.

    I’m pleased to have a very exciting panel. I have the leader of DevOps adoption at Lloyds Bank with me on the panel, Mark Howell. I have a VP of Application Development from Monetize on the panel with me, and then I have my peer, Rosalind Radcliffe, who is the CTO for DevOps Architecture for our Enterprise Organization aligned here at IBM. She comes from the mainframe side of the world, also as a third panelist, talking about this topic.

    Alan Shimel:                Got it. Sanjeev, before we jump exactly or primarily into the panel, as you said, this is the third year for Gene’s DevOps Enterprise Summit, first year in London. It’s happening at an auspicious time after all of this Brexit, right on the heels of it. For those who may not be familiar though, they’ve never had the chance to attend a summit, you have, obviously. Can you give our audience an idea of what the summit or what these DevOps Enterprise Summits are about? What are they trying to do? Then, we’ll dive into it specifically.

    Sanjeev Sharma:         Sure, Alan, sure, sure. I think DevOps, as folks listening to this and people who follow your phenomenal devopsy.kinsta.cloud probably realize, it came from – had its origin primarily in what we like to call the “unicorns” of the world, the cutting-edge companies, the startup companies, who are normally leaps and bounds ahead of your traditional enterprise.

    Gene Kim started this event. I think he had this as the tagline for his first one, I don’t know if he still uses it, saying, “DevOps is also for the horses, not just for the unicorns.” Right? The focus of this event is how are large enterprises, with all the complexities, the legacy, the sheer inertia of it, which comes from the size of them, how are they adopting DevOps?

    We, obviously, at IBM found that very exciting because that’s our sweet spot. Every DevOps Summit I’ve attended, the speakers Gene has been able to go find, and of course, being from IBM, I have to look at everything a little bit through my own lens, but this is not a vendor-specific event. It is totally agnostic. It is people sharing their real-life’s journeys of adopting DevOps, what stumbling blocks they encountered, what challenges they had to overcome, and these challenges, while they vary from company to company, the ones, if you’re a large enterprise with a large legacy install base, with a large distributed set of practitioners, vendors, and business partners, outsourcers, geographic time issues, these are common problems.

    You hear a lot at this summit about how large organizations are addressing these challenges, which companies face. For anybody who does not work in the proverbial startup with the proverbial “two-pizza” team, but works in such an organization, I think this is a must-attend event. This will be actually my first time speaking. I’ve attended the previous events, but I’ve not had an option to present or speak, so I’m really looking forward to it, to be a part of the action.

    Alan Shimel:                Got it. Sanjeev, thank you. That was actually dead on, and I hope that gives people a good sense of what the DOES shows are about and why they may want to attend. Let’s now jump in though. As you mentioned, you’ve got a great cast. I’ve met the gentleman from Lloyds Bank, and for those maybe on this side of the pond who aren’t familiar with Lloyds Bank, would you call them a mid-size or a large bank, as banks go, Sanjeev?

    Sanjeev Sharma:         I would qualify them as a large bank.

    Alan Shimel:                Yup. What’s interesting, and I always find this interesting when you talk to DevOps people, Sanjeev, is we think of financial and the whole financial industry as being rather conservative. But yet, when it comes to new technology, such as DevOps, or I don’t want to say new, but a little more out there technologies and things such as DevOps, we see large banks and financial institutions, whether they be insurance, banks, but finance, really kind of leading the way here. Lloyds Bank is, I think, a great example of that.

    Sanjeev Sharma:         Yes and I think, in fact, both the companies I have on, Monetize is the second panelist. In fact, Garret Evans, who was a VP of AppDev at Monetize, is the other panelist other than Mark Howell from Lloyds. They’re both in the financial services industry, and they both come at it from kind of a different angle in the sense that Monetize is a service provider, and you would call them as a company. They’re not a bank themselves. They provide services to financial organizations, and they’re on the cutting-edge of technology. They’re way ahead of their – on the innovation forefront, and Lloyds too. But Lloyds still has that whole legacy, like more large banks, still has the legacy, “keep the lights on” applications that they to run.

    But it is interesting what you mentioned about how financial services, which we, until a few years ago, one would think of them as the slow plodding conservative people in their suits and ties and risk-averse, being at the forefront of DevOps adoption, and that is very true. They are a prime example of how adopting things like Agile and DevOps actually reduced your risk, actually makes you agile in a disciplined and organized manner, as an organization, rather than some people’s view of it being the Wild West.

    I think they’re a prime example. Why are they doing this? They’re doing it because of all the industries out there, they are one who are going through probably the most transformative change in their existence they’ve ever had. Financial services, banking, peer-to-peer lending, peer-to-peer money transfer, these are all undergoing a massive transformational change. They’re getting challenged by these FinTechs, or financial startups.

    I think this has become a very interesting place for them, and I worked with financial services, it’s kind of my core industry, all over the world. Right? When you go to the developing nations, you see these financial services companies facing the challenge of, “How do I go and reach the un-banked populations who need banking services without – but cannot access a traditional bank?”

    Then, in the developed world, you have this challenge of, “HOw do I go access the Millennials, who, again, do not want to go into a traditional bank, but need banking services, but do not consume and access those banking services the way you and I, and the folks with much more grey hair than them, are used to doing so?”

    It is ripe for transformation, ripe for disruption, and DevOps provides that enablement for the IT organizations in these financial institutions to be ready for the disruption and enable it, and not be the inhibiter, but be the enabler.

    Alan Shimel:                Excellent, absolutely. Sanjeev, we’ve left an important person out of your panel though. Haven’t we? Besides yourself and the two financial institutions, we also have Rosalind Radcliffe on here.

    Sanjeev Sharma:         Absolutely. I didn’t want to – I’m not intending to ignore her [chuckles].

    Alan Shimel:                Why don’t you give our listeners a little background? Rosalind has been a frequent guest on our podcast, but for those who may not be aware, why don’t you give them a little background?

    Sanjeev Sharma:         Absolutely. Rosalind is my peer. She’s also a Distinguished Engineer here at IBM. She’s in the Development Labs in our Enterprise Modernization side of IBM. She focuses on the very – to simplify it and make it very generic – on the mainframe end of the world, although, her influence extends across to all aspects of DevOps, and she’s been a great person we’ve worked with, a great partner, in expanding IBM’s DevOps capabilities.

    She actually has her own session also, I think, a couple of sessions before my panel, where she’ll be talking about DevOps and how it’s adopted in the mainframe world, especially talking about testing, which is a major area where we’ve seen a lot of traction when it comes to DevOps adoption on the mainframe.

    She is going to be bringing to our panel the mainframe point of view, and I’m generalizing here when I say “mainframe.” Right? It could be Systems Z, or Series I, or large traditional legacy systems, but bringing that because if you look at large organizations, especially large organizations who have been around for a while, be it they’re banks, or retail, or government institutions, and those which are transaction heavy, they still rely on the mainframe to run their core businesses.

    How they are adopting DevOps has been a surprise, a refreshing surprise, so to speak, in the sense that a lot of these large organizations have come forward and their mainframe teams have the lead of saying, “We want to adopt DevOps first.” It is unique, and when we tell people that, they’re usually surprised going, “Mainframe?” One usually thinks of them as being at the laggard end of adopting new technologies and new processes.

    But we have found that to be exactly the opposite. I’m sure there are organizations out there where their mainframe teams are going, “Hey, it’s not broken. Why should I try to fix it?” but most mainframe organization’s mainframe teams are in the process of modernizing their application-delivery capabilities. I think DevOps has given them the opportunity, the platform, and the capability to move into the modern world. There’s a significant C-change going on in how customers are consuming the mainframe.

    Linux’s own mainframe is a great example. OpenStack’s own mainframe is great example. And, of course, the z/OS, which IBM’s operating system for the mainframe has also evolved and become extremely modern. She has a very – is going to be able to bring a very unique perspective, which I think will apply to a lot of the attendees, so I’m very fortunate to have her on the panel.

    Alan Shimel:                Absolutely. Sanjeev, believe it or not, we’re almost out of time already, but real quickly, specifically now to your panel, give me, if you can, three reasons why it’s a must-attend panel for those who may be in attendance in London.

    Sanjeev Sharma:         Sure. Number one, people don’t want to hear theory, and I’m sure all our attendees, or our listeners who have the opportunity to attend, don’t want to come and listen to theory. I mean you can Google DevOps, you to YouTube, watch 100 videos on the theory of DevOps, read some books. People want to hear how a company actually undertook that journey and succeeded with it. Right?

    That’s what we have on this panel. We have three examples of people, and I’m not even counting my own experiences working with the dozens of companies I’ve worked with in my role. My goal is not to talk there, but be the facilitator, but the three people we have on the panel are bringing tons of experience, real-world experience, and they will be, hopefully, sharing very openly. I know these folks. I know they’ll be sharing very openly and are willing to talk about all the pitfalls and the speed bumps they hit along the way, so real-world experience.

    Number two, it’s an interactive panel. We are going to have no slides, maybe one slide in the beginning just so people know who we are. The idea is – in fact, we are going to do it very uniquely. I’m going to have my iPad up there with me, with these organizations, both Monetize, Lloyds Bank, and Rosalind. They’re going to give me some drawings before and which I’m going to draw out during the panel, so people can, in real life, see real-life versions of what their application delivery pipelines and their architectures look like, and what changes they needed to make.

    Thirdly, we are going to focus or talk a lot about culture because the biggest bottleneck, the biggest inhibitor to adopting DevOps, is cultural inertia, especially in a large organization. Right? Things have been going on for a while. This is how we always do things, always start things. The responsibility is not mine. It’s not broken. Why should I try to fix it? These are all the specific examples of cultural inertia. We intend to spend a lot of time talking about how, in a large organization, which has set ways of doing things, which have highly distributed teams, how does one overcome that cultural inertia?

    I would say those are three very good reasons to come to our panel. We are on Thursday, I believe, at 2:45 PM, but please check the agenda, they’ve been moving things around on the agenda, for the final time and location, but come there. Our plan is to open it up for questions from the audience, so you’ll be able to ask your own questions, and, of course, all of us panelists will be around for the entire event to meet with you and answer any questions one-on-one also. I hope to see you all there.

    Alan Shimel:                Absolutely. Sanjeev, thanks for giving a quick preview of both DevOps Enterprise Summit and the great all-star panel you’re hosting there. I will be there. We’ll be filming. I think we’re actually going to video interview, so we’ll follow-up then. But for anyone who is attending DevOps Enterprise Summit in London, please be sure to take in Sanjeev’s panel. As most things Sanjeev does, I’m sure it will be a great event.

    For those who are considering going to DevOps Enterprise Summit in London, I highly encourage you to do it. If you can’t make London though, the San Francisco version of the event will be in the fall, and I encourage you to go there. Sanjeev Sharma, IBM, thanks for being today’s guest on DevOps Chats.

    Sanjeev Sharma:         Thanks, Alan. Thanks for the opportunity and I look forward to working more with you.

  • DevOps Connect: CD Summit and Jenkins Days Fall Schedule Announced

     Call for Speakers Open for Seven Events Produced in the US and Europe, By devopsy.kinsta.cloud and Sponsored by CloudBees and IBM

     Boca Raton, June 21, 2016 – devopsy.kinsta.cloud, where the world meets DevOps, along with premier sponsors, CloudBees, the enterprise Jenkins Company and IBM, today announced that their DevOps Connect: CD Summit/Jenkins Days roadshow will continue this fall with Seven Dates in the US and Europe. The call for speakers to present at these events is now open (links at bottom).

    DevOps Connect: CD Summit/Jenkins Days are two day events focused on continuous integration (CI) and continuous delivery (CD), as the fundamental best practice for enterprise software delivery. The events feature one day of hands on workshops on Jenkins, IBM, DevOps Fundamentals, and DevOps transformation. The second day is highlighted by morning keynote presentations, followed by a multi-track format of sessions in the afternoon featuring technical discussions, related business/management topics and Jenkins. Also included are networking lunch, refreshments and after event reception.

    The fall event series includes:

    • Atlanta, October 5-6
    • Denver, October 12-13
    • Austin, November 16-17
    • Seattle, December 5-6
    • Los Angeles, December 15-16
    • Berlin, TBA
    • Amsterdam, TBA

    These events are designed for enterprise IT managers and buyers along with developers, engineers, sys admins, and architects. With three main tracks focused on IT managers, technical engineers, and Jenkins practitioners, attendees will get access to the best minds in CD, CI, and DevOps. The presenters are experienced developers, build managers, quality assurance leads, DevOps practitioners, IT managers/executives, architects and IT operations professionals who are recognized within the DevOps community.

    “These CD Summits/Jenkins Days are a great way for novices and experienced DevOps teams to learn about the latest trends, best practices and open source technologies like Jenkins”, said Andre Pino, VP of Marketing CloudBees. “These events will complement the international Jenkins Word Event being held in Santa Clara in September and are a great way to learn about latest developments in the Jenkins community.”

    About DevOps Connect

    If you would like to find out more information about DevOps Connect or CD Summit and Jenkins Days, please visit http://www.devopsconnect.com

    About devopsy.kinsta.cloud

    Launched in 2014, devopsy.kinsta.cloud has quickly established itself as an indispensable resource for DevOps education and community building. We make it our mission to cover all aspects of DevOps—philosophy, tools, business impact, best practices and more.

    Our site is the largest collection of original content related to DevOps on the web and one of the top result for DevOps-related search terms. Our content includes in-depth features, bylined articles, blog posts and breaking news about the topics that resonate with IT readers interested in DevOps: teamwork through improved IT culture, continuous integration, automated deployment, agile development and infrastructure-as-code among them.

    devopsy.kinsta.cloud is comprised of thought leaders who understand both DevOps and how to create compelling, informative content. The team behind devopsy.kinsta.cloud has real-world experience in technology, cloud, online media, DevOps, IT and startups.

    About CloudBees

    CloudBees (www.cloudbees.com), the enterprise Jenkins company, is the continuous delivery (CD) leader. CloudBees provides solutions that enable DevOps teams to respond rapidly to the software delivery needs of the business. Building on the strength of Jenkins, the world’s most popular open source continuous delivery hub and ecosystem, the CloudBees Jenkins Platform provides a wide range of CD solutions that meet the unique security, scalability and manageability needs of enterprises. The CloudBees Jenkins Platform supports many of the world’s largest and most business-critical deployments.

    Backed by Matrix Partners, Lightspeed Venture Partners and Verizon Ventures, CloudBees was founded in 2010 by former JBoss CTO Sacha Labourey and an elite team of continuous integration, continuous delivery and DevOps professionals. Follow CloudBees on Twitter, Facebook, LinkedIn and Google+.

    About IBM

    https://www.ibm.com/ibm/devops/us/en/

     

    For Media inquiries contact:

    Miles Blatstein

    miles@devops.com

    For Sales inquiries contact:

    Parket Yates

    Parker@devops.com

  • Doing Nothing is Hard Work!

    Doing Nothing is Hard Work!

    If you really want to know how good your software delivery process is, try doing nothing. Yes, you read that correctly, do nothing: Go through your normal release process without any requirements, no new code, no testing and no installation at the end. Sounds easy, right?

    So let’s get started. This will be different for each organization of course, but typically a new release starts by creating an entry in some administrative system. Then there is usually a review on the scope, budget and overall fit within the company’s strategy. Since there are no new requirements, you should automatically pass any reviews. But if the approval requires a meeting or conference call, you still have to schedule it. Say “Hi” and walk out of the room or hang up the phone. Make sure you get any required e-mail approvals.

    Next, go through all of your other mandatory reviews: security, data privacy, regulatory compliance, user interface design, infrastructure readiness and so on. You may need your test team to sign off on quality as well. And don’t forget to reserve an install window and take into account any change freeze periods.

    doing nothing pic 1

    If you’re lucky, you were able to skip or get auto-approval for most of these checkpoints because you had no new requirements, software or infrastructure. If you’re unlucky, you had to deal with review committees that only meet on the second Tuesday of each month. At any rate, add the elapsed days and see how you did. Five days or fewer? Give your company a gold star! Four to six weeks? Not too bad. Did it take longer than three months? Embarrassing of course, but take solace in the fact that you’re not alone.

    When you have actual requirements to implement, a lot of this overhead is masked. You can do your approvals while there is real coding and testing going on. But this exercise will show you your limitations, and why optimizing your software delivery process is at least as important as automation.

    Doing nothing won’t hit all your bottlenecks. In this exercise, we did not look at duplicating a development environment, getting capital for already-purchased production servers or repeating previously passed tests. I’ll talk about those tasks in another post.

    How long do you think it would take your organization to do nothing? Leave a comment below.

    Doing Nothing pic 2

    About the author / Jan S (Bas) Pluim

    Bas Pluim

    Bas Pluim is a Cloud/DevOps solution architect in IBM’s innovation practice. He works with clients on infrastructure solutions, process re-engineering, automation tools and transforming the overall software delivery process. Bas is also a member of the IT Specialist certification board, a gaming enthusiast and an advocate of social media tools

    Connect with Bas on LinkedIn / Twitter

  • 3 Rules for Successful SAFe Adoption

    3 Rules for Successful SAFe Adoption

    Startups and enterprises alike are redefining—some say disrupting—markets, industries and customer experiences by delivering innovative ideas at a rapid pace and responding to feedback. Often they fail, but they fail quickly and adjust. You know the ones: Spotify, Etsy, Netflix, Airbnb. How do they do it? What can we learn from them that will work in our own organizations? What is different? In a nutshell, all of these successful organizations innovate completely, not only in terms of what they do, but also how they do it. And the common thread is the application of lean and agile practices to improve their culture and deliver innovation to customers faster than the rest of us.

    Today’s business imperative is to be the disruptor and more and more organizations are turning to enterprise scaled agile as a set of practices to help lead transformations to achieve that goal. The Scaled Agile Framework (SAFe) is the industry-leading enterprise scaled agile framework with a proven track record in thousands of organizations for several reasons, not the least of which is the incredible breadth of definition and collateral so that you just don’t have to make this stuff up yourself. Nevertheless, there is not an one-size-fits-all framework and SAFe is no exception. But there are three key concepts prescribed by SAFe that, if you do nothing else, will help you be successful in your evolution toward becoming that disruptor.

    Go SAFe or Go Home

    1. Apply Lean Principles at an Enterprise level
    You’ve likely heard the term “MVP,” or minimum viable product. This is about investing “just enough” to deliver a capability—a solution, product or application—and get feedback. It is about avoiding the pitfalls of over-engineering. This is perfect embodiment of lean thinking. By focusing on investing only as much as necessary to get feedback quickly (and doing this continuously) you not only reduce or eliminate wasted resources but also speed time to feedback. Lean is also about the notion that “capacity rules”—in other words, only invest as you have capacity to follow through. Otherwise, what’s the point?

    2. Apply Economic Thinking
    Traditional methodologies typically focus on priority to rank at all levels, from business initiatives and projects down to team-level work that delivers changes into products and applications. In the agile world, story points (or complexity) also might be used. So what’s the problem with this? First, it is only a single dimension. What about business or customer value? What about cost of delivery or reducing risks or enabling market opportunities? Is timing a factor? All of these aspects should be considered when ranking because, at the end of the day, organizations are looking for the “biggest bang for the buck.” By applying economic thinking, you are maximizing the business’s ability to deliver the most value at the lowest cost in a timely manner.

    3. Focus on Delivery of Value
    I’ve often heard that revenue generation is the primary goal when organizations look to speed delivery cycle times. In fact, the goal should be delighting the customer; revenue is a bonus, a side effect of happy customers who use your stuff and pay for it! A focus on improving feature delivery is too narrow. What you really want to do is improve time to value. That means articulating what value means, associating the notion of value with features that are delivered, assessing that value and then tracking so you have insight into your organization’s ability to deliver value and get better at it.

    SAFe embraces all of these concepts through artifacts and activities anchored in lean and agile practices. Try it, you might be surprised at how impactful this can be in improving your ability to innovate and be the disruptor instead of being disrupted.

    Read how a typical enterprise dipped its toe in SAFe water to drive delivery of a critical project, and be sure to visit the SAFe landing page to learn more.

    About the Author/ Amy Silberbauer

    Amy SilberbauerAmy is a Solution Architect charged with the definition and delivery of the Enterprise Scaled Agile and IBM DevOps Plan solutions and strategy for the IBM Watson IoT line of business. She is a recognized subject matter expert on scaled agile and software development lifecycle solutions, including enterprise modernization, SOA and collaborative DevOps. She has been with IBM for 29 years and has two decades of software development experience as an engineer, architect and manager. She is a certified SAFe® Program Consultant experienced in leading and consulting on multiple internal and external SAFe (Scaled Agile Framework®) transformations.

    Connect with Amy on LinkedIn.

  • Do You Continuously Deliver Your CD Pipeline?

    Do You Continuously Deliver Your CD Pipeline?

    If your job is to build and maintain the continuous delivery (CD) pipeline for your organization, do you feel you can’t keep up with your development counterparts in innovation? Everyone is raving about the new cool features in your company’s product. Who deserves the credit? People who wrote the code, right? It’s not that simple. Churning out new features requires a sound process and solid infrastructure. A well-designed CD pipeline is crucial to the developers’ success. It mitigates the inherent risks in a fast-paced, frequent iteration regime now prevalent in agile software shops. On the flip side, as software gets more and more complex and the appetite for a faster time to market grows, opportunities for innovation are in abundance for DevOps teams.

    Multi-speed IT

    So you’ve got two tactical teams with significantly different risk-reward equations, working at a different pace due to distinct objectives but marching toward the same strategic goal. You’re finding yourself in a multispeed IT environment. Development is focused on innovation and quick frequent iteration cycles. DevOps’ primary focus is to ensure the stability of the CD pipeline and keep a precise track record of what takes place inside the pipeline every step of the way. How do you make sure to stay ahead of the technological curve while minimizing risk?

    Based on my experience on both sides of the DevOps isle, I recommend the following four steps to successfully build and maintain a continuous delivery pipeline:

    1. Automate, Automate, Automate!

    My personal motivations for rolling up my sleeves and scripting a task are:

    • It became an annoying, mindless routine;
    • It’s no longer a one-time thing and isn’t going away;
    • My time can be spent on more important things; or
    • I make mistakes and then waste time fixing them.

    As with any type of code, organize the scripts into a sound logical structure easy to navigate and version-control it. You can always revise the code or completely rewrite it as the needs evolve.

    2. Treat Automation Code as a First-Class Citizen

    That’s right! As a practitioner, I learned the hard way that automation starts innocently small and simple. Then the requirements for more automated functionality begin to pile up rather quickly and things quickly become really messy. So write high-quality code from the get-go and reassess the design and implementation every step of the way. Remember that the visibility of your code is very high.

    Apply the same standards to your code as your peer development teams do to theirs. Write tests—unit, integration, functional, end-to-end—as appropriate. Use the same CD pipeline to automatically build, package, deploy and test your automation code. This will give your pipeline another round of validation, your code will be of a much better quality, and your team’s credibility and reputation will soar.

    3. Containerize the CD Pipeline Components

    In the past, because the CD pipeline components such as build servers were manually provisioned, they often became the single points of failure, which made it hard to plan and roll out the modifications to homegrown, open source and commercial tools. It wasn’t unusual for some components to fall behind the latest release by a full year or more. In the meantime, a year’s worth of updates and patches could address a litany of issues, but the need for a maintenance window, usually on a weekend, and the uncertainty of the outcome often would outweigh the sought-after benefits. Containerizing the CD pipeline component can be the solution. Running a build server in a container, for example, will make it a lot easier to create an exact copy of the production version in a test environment and iron out the upgrade process more thoroughly ahead of the upgrade.

    4. Test Commercial Tools

    Commercial and open source projects test their software, of course. However, it could make a whole lot of sense for your organization to create your own integration, end-to-end and performance tests for the software you don’t write—especially if the software has a plug-in architecture like Jenkins or UrbanCode Deploy and you use community or homegrown plugins. Commercial tools typically don’t provide any guarantees that those plugins will work after the upgrade. Running your own automated tests that exercise the functionality of the tool in your environment and on your specific data gives the opportunity to validate updates as they become available and identify any regressions proactively.

    The objectives of DevOps are not only to identify and eliminate the existing bottleneck in the organization’s continuous delivery process, but also to look out for any future potential bottlenecks and proactively address them before they become real issues.

    So your team is DevOps. Your product is a CD pipeline. How do you continuously improve the CD pipeline for your product?

    If want to learn more about how to effectively build and maintain your continuous delivery pipeline, please check out the newly released 2nd edition of the “Application Deployment and Release for Dummies” eBook.

    About the author / Alex Seriy

    Alex Seriy

    Alex is an accomplished technologist and DevOps evangelist with over 25 years of experience under the belt. He is an automation enthusiast and usability guru, passionate about uncovering new use cases and innovating applications for platforms, frameworks and tools. At IBM, Alex is a subject matter expert in Continuous Integration, Delivery and Testing. He currently focuses on integration testing in the API Economy through service virtualization. Prior to joining IBM, Alex served as the Senior DevOps Architect at TIAA-CREF for 4 years. Before that, he was a consultant specializing in SCM, Release Engineering, QA and DevOps for over 10 years.

    Connect with Alex on LinkedIn / Twitter

  • DevOps: Shift Left to Reduce Failure

    DevOps: Shift Left to Reduce Failure

    DevOps is all about increasing the feedback loop from idea to customer and back again. Tremendous gains have been achieved in automation and tools to drastically reduce the amount of manual labor involved in progressing down the release pipeline. But mission-critical applications in a highly competitive market cannot afford to go down. Complex applications, environments and infrastructure increase risk, which can cause failure.

    The failure rate of production deployments is still too large. Studies show that the average cost of a production outage is roughly $5,000 per minute, while the average cost of a critical application failure per hour is $500,000 to $1 million.

    Why so much failure? All too often we’re still seeing a lack of consistency across the release pipeline. Many times the provisioning and deployment processes are very different at the opposite ends of the pipeline. But by shifting left the operations concerns, you can achieve much more success in production.

    Understanding How to Shift Left

    The term “shift left” refers to a practice in software development in which teams focus on quality, work on problem prevention instead of detection, and begin testing earlier than ever before. The goal is to increase quality, shorten long test cycles and reduce the possibility of unpleasant surprises at the end of the development cycle—or, worse, in production.

    Shifting left requires two key DevOps practices: continuous testing and continuous deployment. Continuous testing involves automating tests and running those tests as early and often as possible, along with service virtualization to mimic unavailable systems. Continuous deployment automates the provisioning and deployment of new builds, enabling continuous testing to happen quickly and efficiently.

    The first and most obvious way to shift left operations is to work side by side with development in creating the deployment and testing processes. Failures observed in production often are not seen earlier in the life cycle. Many times these failures can be attributed directly to differences in deployment procedures. Development may create its own deployment procedures that are very different from those used by operations for production. Sometimes production procedures are much more manual and may even use different tooling. Operations and development need to take ownership in building standard deployment procedures. The deployment process is then practiced potentially hundreds of times in test environments before reaching production. You then have much more confidence that the production deployment will be successful.

    Another way to reduce the failure rate is to make all environments in the pipeline look as much like production as possible. This is almost impossible using traditional provisioning processes. Production environments usually are much heavier and detailed than are needed by development. But by using cloud and pattern capabilities, you can get much closer.

    The ability to use patterns to define consistent environments eliminates the failures that occur simply by configuration inconsistencies. This again requires operations and development to work together in creating the provisioning process so developers create their test environments the same way they are created in production. Using IBM UrbanCode as an example, this can be done by connecting UrbanCode Deploy to an automated self-service provisioning system such as OpenStack HEAT or IBM Cloud Orchestrator connected to OpenStack.

    Picture1

    These standard patterns can be used to create environments for all stages of the pipeline. And by using cloud capabilities you can deprovision these environments as fast as you can create them. This also allows the enterprise to have confidence in their environment patterns. They are tested on a daily basis and, therefore, operations can feel confident that testing is done on production-like environments.

    No one wants to experience production failures—and it is in everyone’s best interest to do all they can to prevent them. At the root of DevOps is the removal of those silos between development and operations. By applying these shift left operations principles you are well on your way to reducing your failure rate.

    The ingredients to make shift left are real and available: automated testing and deployment tools, service virtualization technology, agile practices and cloud environments. The main obstacle that remains is the mindset of delivery organizations. Learn more from the newly updated Application Deployment and Release for Dummies ebook to find out more.

    About the author / Dr. Darrell R. Schrag

    Darrell Schrag

    Dr. Darrell R. Schrag (@devopsdrs) is an experienced software lifecycle consultant specializing in the IBM cloud solution, helping customers establish their cloud strategy across the enterprise. He’s focused on implementing continuous delivery of software applications through the delivery pipeline incorporating cloud and provisioning solutions. He’s experienced in helping clients transition to “born on the cloud” applications utilizing microservices to take advantage of a flexible and nimble cloud platform.

  • IBM Offers Watson Services on Twilio Marketplace

    More than one million registered developers will have access to new cognitive capabilities 

    SAN FRANCISCO – 24 May 2016: IBM (NYSE: IBM) today announced it is collaborating with Twilio, the cloud communications platform for developers, to introduce two new offerings, IBM Watson Message Sentiment and IBM Watson Message Insights, which will be available as Add-Ons in Twilio’s recently announced Marketplace.

    Pre-integrated with Twilio’s APIs, the new Watson offerings are now readily accessible as “Add-ons” to the more than one million registered developers in Twilio’s community, in addition to the developers who currently access Watson technology via Bluemix, IBM’s Cloud platform.

    The new Watson Add-ons offer additional message enhancement capabilities through natural language processing to help understand sentiment, keywords, entities and high-level concepts from text messages. The insights gleaned from this unstructured data will give businesses actionable insights. The capabilities include:

    • IBM Watson Message Sentiment: using sentiment analysis, the new service allows users to retrieve sentiment from SMS in a scalable manner. For example, a customer service manager would be able to easily analyze customer SMS messages to determine whether they are positive, negative, and neutral, to help to assess a customer’s satisfaction with a brand, service or product.
    • IBM Watson Message Insights: using a combination of sentiment analysis, keyword extraction, entity extraction and concept tagging, this capability allows developers to distill key meanings from SMS. For example, a developer would be able to extract trending topics and match specific products or services to certain sentiments.

    Add-ons are pre-integrated technologies available through the Twilio Marketplace that allow developers do more with the Twilio API, and are designed to make it easier for developers to integrate with other platforms and technologies.  The new offerings complement the more than thirty Watson services

    currently available from IBM. Future plans include extending these offerings on third party platforms like the Twilio marketplace, bringing cognitive to where developers work.  Watson Speech to Text Add-on, as part of the Recording Add-on category, is up next for Twilio developers.

    “We are committed to equipping all developers, everywhere, with self-service AI and IBM’s cognitive capabilities, backed by the best science, ease-of-use and scalability. We are motivated by what developers are creating with Watson technology, and are constantly seeking new ways to help them build and innovate,” said David Kenny, general manager, IBM Watson. “By joining the Twilio Marketplace, we have opened another avenue for many more developers to harness the power of Watson.”

    “Add-ons make it possible for developers to do more with their Twilio applications using less code,” said Patrick Malatack, VP of Product at Twilio. “The IBM Watson Add-ons apply Watson’s sentiment analysis capabilities to customers’ text messages at scale, better equipping businesses with insights into how their customers feel. We’re pleased that customers can now add the functionality of IBM Watson in a single click.”

    These new services are the latest example of IBM’s commitment to empowering the developer community to build cognitive-enabled apps and businesses with Watson. They build upon IBM’s open Watson platform that offers cognitive APIs in the areas of Language, Speech, and Vision available through BlueMix, IBM’s Cloud platform.

    IBM Watson: Pioneering a New Era of Computing
    Watson represents a new era in computing called cognitive computing, where systems understand the world the way humans do: through senses, learning, and experience. Watson continuously learns from previous interactions, gaining in value and knowledge over time. With the help of Watson, organizations are harnessing the power of cognitive computing to transform industries, help professionals do their jobs better, and solve important challenges.

    To advance Watson, IBM has three dedicated business units: Watson, established for the development of cloud-delivered cognitive computing technologies that represent the commercialization of “artificial intelligence” or “AI” across a variety of industries; Watson Health, dedicated to improving the ability of doctors, researchers and insurers and other related health organizations to surface new insights from data to deliver personalized healthcare; and Watson IoT, focused on making sense of data embedded in more than 9 billion connected devices operating in the world today, which generate 2.5 quintillion bytes of new data daily.

    For more information on IBM Watson, visit: ibm.com/Watson and ibm.com/press/watson. Join the conversation at #ibmwatson.

    About Twilio

    Twilio’s mission is to fuel the future of communications. Developers and businesses use Twilio to make communications relevant and contextual by embedding messaging, voice and video capabilities directly into their software applications. Founded in 2008, Twilio is privately held and has over 500 employees, with headquarters in San Francisco and other offices in Bogotá, Dublin, Hong Kong, London, Mountain View, Munich, New York City, Singapore, and Tallinn.