devopsy.kinsta.cloud

Category: DevOps at IBM

5 Ways to Connect with me at IBM InterConnect2015
Well, I am an IBMer and going to IBM InterConnect2015 is a part of my job. And the best part about this event is that I will get the opportunity to meet all my clients and colleagues at one location instead of going to three different conference events which we use to call PULSE, IMPACT and INNOVATE. And for our clients, this is an opportunity to really get the broadest and deepest immersion into what IBM has to offer for cloud, mobile, bigdata, security etc.. and of course DevOps. That being said, I am really looking forward to it. By every measure it is going to be the largest DevOps conference ever with 300+ sessions just focused on DevOps. Although, InterConnect as a whole is not a DevOps conference – it has several areas of foci, across IBM’s massive and diverse portfolio. DevOps just happens to be one of the most significant areas of focus. At the conference, we have IBMers, sharing the IBM DevOps adoption journey with industry leaders, influencers, SME’s, and most importantly several of our customers who will talk about how they have adopted DevOps and achieved business benefits.

I myself have multiple sessions that I am delivering/participating in at InterConnect. These include:
1. Understanding DevOps (Session DTS-1778, Monday 12:15PM): This is my flagship session which I have been doing at IBM conferences for three years now. I introduce DevOps – it’s history, what it means, capabilities that make up DevOps, and where to start on your DevOps adoption journey.
2. Eliminate Dogwork with Leaner and Smarter Methods (Session DEV-6306, Monday 3:50 PM): This is a unique session. I will be delivering this with Walker Royce, IBM Chief Software Economist. It will be in the dev@InterConnect, a developer focused event happening in parallel with the main InterConnect event. You can register just for this event separate from InterConnect. Walker and I will go over how developers can self-empower themselves and reduce the waste in their application development and delivery pipelines. We will explore common sources of waste and techniques on how to identify and mitigate them.
Panels, Panels, Panels: I am on two panels with a bunch of very illustrious experts.
1. Mobile to Mainframe Experts: DevOps Best Practices for Systems of Engagement and Systems of Record (Session DEM-4399, Monday 2PM) – This panel is focused on organizations developing multi-platform applications – from Mobile to Mainframe. My co-panelists are: Rosalind Radcliffe (IBM Distinguished Engineer), Carmen DeArdo (Nationwide Insurance), Claus Bjorno (KMD A/S), Slavik Zorin (Synchrony Systems Inc), Jeff Blackadar (CMHC) and Mads Frank Zanderson (Xact Consulting).
2. Experts in Mobile, Deployment, Web IDE and Agile Answer Your DevOps Questions (Session DEV-1902, Wednesday 8 AM). This is a Q&A format panel with SMEs on all things DevOps. My co-panelists are: Yan Tina Zhuo (IBM), Eric Minick (IBM), Donald Thomas (IBM) and Wayne Monk (Skytap).
3. I will also be running a series of DevOps workshops in the ‘Inner Circle’ Event taking place at the MGM.
So, now you know where you can catch me at the conference, but that’s not all, there is a lot to look forward to with so many different stories at so many different sessions. Check out the entire agenda here. I intend to spend most of my time in and around the Cloud and DevOps tracks, DevOps Transformation workshops, and in the expo center in the DevOps zone. Come look me up. I will also be signing copies of my updated DevOps For Dummies book (2^nd Edition) on Monday and Tuesday nights in the expo center.

Register for IBM InterConnect 2015 today to know what’s happening in the world of DevOps and understand how you can be a part of it. And get your signed copy of DevOps for Dummies book today.
February 5, 2015
Google Hangout: InterConnect 2015 preview from IBM & Synchrony Systems on #DevOps for Enterprise Systems
Join us for another exciting Google Hangout* with a distinguished panel of guests as we deep dive into the multiplatform application development challenges related to: Integrating Systems of Record (Mainframe) with new Systems of Engagement (Mobile). Take this opportunity to find out how Bay Area Rapid Transit (BART) leveraged a DevOps approach to deliver an innovative mobile app integrated with their enterprise systems in 15 days. Dig deeper with the experts into what it takes to actually implement DevOps in an Enterprise dependent on traditional Systems of Record and now required to extend these core Systems to support new Cloud and Mobile initiatives.

With IBM InterConnect 2015 just a few weeks away, three featured presenters will give us an Interconnect preview.

Our Panelist:
Hayden Lindsey, IBM Vice President & Distinguished Engineer – DevOps for Enterprise Systems
Slavik Zorin, President, CEO & Founder, Synchrony Systems, an IBM Business Partner
Mike Fulton, DevOps for Enterprise Systems CTO

Date: Tuesday, February 10th, 2015

Time: 2pm eastern standard time
```
Google Event Page:(NO REGISTRATION REQUIRED*) 
Google Hangouts are FREE. To participate in a Google Hangouts LIVE, 
a Gmail or Google Profile is required
```
About Our Guests:

Hayden Lindsey, our guest from @IBM

IBM Vice President & Distinguished Engineer – DevOps for Enterprise Systems

Hayden’s session @ #IBMInterConnect

https://www-950.ibm.com/events/global/interconnect/sessions/preview.html?sessionid=DEM-1779

Mike Fulton

DevOps for Enterprise Systems CTO

makingdevelopersliveseasier.wordpress.com

Mike’s sessions @ #IBMInterConnect

https://www-950.ibm.com/events/global/interconnect/sessions/preview.html?sessionid=DEM-5873

https://www-950.ibm.com/events/global/interconnect/sessions/preview.html?sessionid=DSZ-2171

https://www-950.ibm.com/events/global/interconnect/sessions/preview.html?sessionid=DEM-4536

Slavik Zorin

President, CEO & Founder, Synchrony Systems, an IBM Business Partner

Slavik’s sessions @ #IBMInterConnect

https://www-950.ibm.com/events/global/interconnect/sessions/preview.html?sessionid=DEM-4399

https://www-950.ibm.com/events/global/interconnect/sessions/preview.html?sessionid=DEM-5416
February 4, 2015
5 best things going on at InterConnect 2015

With IBM InterConnect 2015 less than a month away, here is a quick guide to the 5 Best Things Going on at InterConnect 2015

[seoslides embed_id=”70823b380482″ script_src=”https://devopsy.kinsta.cloud/embed-script/5-best-things-going-interconnect-2015/3998/” overview_src=”https://devopsy.kinsta.cloud/slides/5-best-things-going-interconnect-2015/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”5 Best things going on at Interconnect 2015″ /]
You can stay up to date with the latest InterConnect news by following #ibminterconnect

devopsy.kinsta.cloud will be covering the event live February 23-26

January 28, 2015
Google Hangout: InterConnect 2015 preview from IBM & Nationwide on #DevOps
Join us for a Google Hangout* with a distinguished panel of guests as we discuss: Adopting DevOps for Two-Speed IT.

With IBM InterCnnect 2015 just a month away, three featured presenters will give us an Interconnect preview

*Google Hangouts are FREE. To participate in a Google Hangouts LIVE, a Gmail or Google Profile is required.

Date: Wednesday, January 28th, 2015

Time: 3pm eastern standard time
```
REGISTRATION LINK:(NO REGISTRATION REQUIRED*) 
```
About Our Guests:

Rosalind Radcliffe, our guest from @IBM

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

Carmen DeArdo, our guest from @Nationwide

Director – Tools and Technology Leader

Sanjeev Sharma, our guest from @IBM

IBM Worldwide Lead – DevOps Technical Sales (Executive IT Specialist),

Author of DevOps for Dummies
January 26, 2015
DevOps Resolutions For The New Year

As we welcome in the New Year, it’s natural for us to set both personal and professional goals. While many are adding the obligatory eat healthier, spend more time with family, and exercise more to their personal list, some of our client are adding DevOps resolutions to their professional goals.

During a recent customer roundtable discussion, we asked our clients what are their DevOps goals / resolutions for the New Year. Here are a few that stood out from the crowd.

“Focus on fewer problem areas (bottlenecks)”
-Ben S., VP, Major European Auto Manufacturer

This is my favorite. It’s counterintuitive but makes perfect sense. With a topic like DevOps, it can feel over whelming at times. It’s for easy organizations to create a litany of things to do. Many enterprises hesitate to invest in DevOps not because they don’t know where to start, but rather they have too many choices on where to start.
So this year, listen to Ben’s advice: pick the top 2- 3 areas that can make a positive impact to your organization. That may be continuous integration, or automated testing, or automated environment configuration. Whatever the area, just focus on a few areas, rally your team, and stick with it.
If you are struggling with what to pick, use time, pain, and / or cost as your prioritization criteria. Even if you get it wrong, the impact on one part of your Software Delivery Lifecycle (SDLC) will highlight the bottlenecks in other areas.

“Spend time talking to the people in trenches”
-Jay S., Senior Director, Leading HealthCare Provider

Jay hit the nail on the head. Too often we only focus on executive messaging and alignment. While that is important, talking to the people that are actually living this day in and day out is just as important. The insights you gain from them will be invaluable as you create your DevOps strategy and will go a long way when you try to get their buy in. Also, don’t just stick to the people within your silo. Talk to business, development, and operations – to get a holistic point of view
If you are going to start a DevOps cultural revolution, you might as well get both top down and grass roots support. It’s the own way it is going to work.

“Connect with others who have been there done that”
-Ann H., VP, Major Telecommunications Company

DevOps is a paradigm shift that challenges many of our long-held beliefs. It is a mind-set change and the only way to break the old way of thinking is to learn something new. So as the New Year unfolds, consider replicating Ann’s strategy: plan to connect with others who have been there and done that.
We are at a stage in the market where many organizations have jumped in with both feet into DevOps. Some have been successful and continue to invest, and others not so much. Talk to both, you can learn a lot on what to do / not to do.

“Stick To Your Guns”
– John B., Snr. Director, Leading Technology Firm

DevOps fails in an enterprise, not because of a flawed strategy, or mis matched tools, or even a bad process, but due to death by a thousand cuts. For example, breaking the continuous integration protocols and letting bad code pass through, increasing the batch size due to scope creep, not checking in code daily, and / or using non-standard pattern for deployment. Each cut, though small in nature, undermines the entire process. If done once in a while, it might be ok. But do it too often and you will literally see your DevOps investment vaporize into thin air.

So if you were to add just one resolution to the list, I would recommend you follow John and add “sticking to their guns”. Whatever process that you and your team have decided on, stick to it. The more you stick to it, the easier and more natural it will become. Do it often enough and you will be setting the right tone for yourself, your team, and towards DevOps success.

What are your resolutions for 2015?

About the Author

Mustafa Kapadia is Service Line Leader for IBM’s DevOps practice, a business advisory practice focused on helping large enterprises transform their software & application delivery. Through DevOps, organizations can get software to market faster, with better quality, less defects, reduced risk and shortened lead times.

Prior to joining IBM, Mustafa was a management consultant with Deloitte’s Strategy & Operations practice. He lives in San Francisco Bay Area, is an avid blogger (when time permitting), a speaker, and and advisor to start ups.

You can follow Mustafa on LinkedIn: https://www.linkedin.com/in/kapadiamustafa and Twitter: https://twitter.com/mkapadiatweets

January 5, 2015
Does Automating Application Release Mean the Same that it Used to?
Over the last ten years, we have seen a shift towards automation in how applications have been released. Automation has been encouraged first by agile’s embrace of continuous integration and delivery, and now the broader move to DevOps. As deployment automation left the sphere of the individual development team, another trend has emerged. The understanding of what it means to deploy an application in an automated fashion has steadily expanded. For developers in the early days of continuous delivery, production concerns were usually secondary. They would take a single build, and automate its deployment to test environments. Some teams would succeed in expanding this approach to production with a full-fledged delivery pipeline, but most would stumble. Ignoring production concerns in the lower environments resulted in their work being dismissed as unworkable in production environments. However, the success of agile development meant an increased demand for change in production. At the same time, the trend towards cloud services expanded the number of targets that a given deployment would impact. Production support teams had to automate, and in a way that would also work for the rapid rate of change in development and test. The build pipeline model was close, but didn’t meet the Ops needs of incremental change (rather than full builds), and orchestrating changes across multiple builds and tiers.

A 2012 survey of over 500 technologists by UrbanCode found that only 12% of teams scoped production releases to a single build. With the business demanding faster change, and DevOps ascending, we have seen automation mature in the production environments rapidly in the past several years. This includes the rise of Application Deployment/Release Automation as a tool category at the start of this decade. These ADA tools are defined by automation scoped at a business application – they coordinate across multiple tiers and components. So they deploy not just the new version of a web service, but also five other web services the backend databases, etc. With DevOps better linking development and operations, and an increased willingness to automate in production, we saw the first big shift in the scope of automation. From deploying a build, to deploying the build and related builds, content and database changes. The web app was still the most common scenario. Today we are seeing the next major expansion underway, and it’s hitting on several fronts at once.
1. The first front is that organizations whose releases span multiple business applications are adding release centric orchestration to speed releases of coupled applications.
2. The next front is a move beyond the web application itself. Mobile development tied to backend services is getting pulled in to the definition of the “business application” as are systems of record including the mainframe.
3. The third front is a shift down the stack. The environment and infrastructure are seen increasingly not as a place the application runs, but as part of the application itself. As that shift happens, we see a push to make a change to the CPU count in a VM go through the same types of automation and governance that updates to the behavior of a web service go through. Change is change.
4. Finally, we are seeing the normalization of Platform as a Service offering like Bluemix. That results in increased acceptance of the technology, but also the desire to coordinate change to services delivered through a PaaS platform and those delivered through other cloud or traditional data-center platforms.
Broadly, IT is delivering value to the business by delivering services. Changes to those services tend to be scoped to applications that are complex. The trend is to treat everything in that application that is software defined the same through the same channels. That lets system level testing validate the whole system, and for the whole system to be promoted forward together. The above discussion not only informs about the change taking place but also prompts at taking the step towards the change. The move to DevOps is bringing about change rapidly. On November 20, some of the industry experts and leaders got together to discuss the effects and steps to adopt the change effectively, at the IBM DevOps Symposium in the New York area (Jersey City). Understand how to adopt DevOps successfully by listening to distinguished industry leaders and experts. Join us for the replay of the webcast. Be a part of the change

About the Author:

Eric Minick is a Technical Evangelist. He joined IBM through its acquisition of UrbanCode. He has spent the last ten years helping organizations – large and small – adopt continuous integration, delivery and now –DevOps. He is a frequent speaker on the topic, and co-authored Application Release and Deployment For Dummies. Prior to consulting, Eric was a developer, test automation engineer and support engineer, and has contributed to multiple generations of UrbanCode products.
December 9, 2014
DevOps: As critical for the Systems of Record as for the Systems of Engagement

There is a lot of talk about DevOps, and how it improves the process of delivering business value. Much of the discussion of DevOps has been focused on web based companies such as Facebook, or the mobile and distributed development teams. But DevOps principles apply just as well to the traditional Systems of Record, z/OS applications.   Many of these applications have been around for a long time and have very mature development and deployment processes. These processes include the requirements for separation of duties and audit tracking. Over the years these processes have developed into lengthy procedures, to be comprehensive, the net effect of this has been to reduce the number and frequency of the deployments to reduce risk. However, there is a better way.

In the recent blog posting by Ashok Reddy he talked about the 8 critical DevOps Practices: innovate, deliver, repeat. All of these are as applicable to z/OS applications as any other, for this blog I want to focus on just a few of the practices, Loosely Coupled Architecture, Automate Testing using APIs, Transparency and Minimize hand-offs, Maximize flow.

DevOps is about bringing the entire organization together, including Development and Operations, to more efficiently deliver the business value. The practices of “Transparency” and “Minimize hand-off, Maximize flow” go to the core concepts of the people aspects of DevOps i.e., integrating the organization.   By breaking down the barriers between the organizations, people can work together to accomplish the business goals more quickly. This does not necessarily mean actually changing the organizational structure, but it does mean having the organizational structures work together as cross functional teams.

One example would be the monitoring and optimization practices. These are generally done by Operations after the applications are deployed into production. However, if instead Operations and Development worked together in the early part of development cycle to monitor and optimize the application using the same capabilities that will be used in production any issues can be addressed much earlier in the cycle. This also helps both teams learn what is required to monitor and manage the application long before it is ever deployed to production. In many z/OS environments today, the same infrastructure is already available in the test environments, but it is seldom used.

A second example is to have Operations define the deployment automation such that it can be done by Development in early stages and turned over in later stages. This ensures continued testing of the deployment capability and a validation that by the time the deployment is done in production; the deployment process itself will be well tested. Through this integration of Development and Operations you remove the hand off that currently happens only at the final stage just before production deployment.

The practice of loosely coupled architecture is key when building multi-platform applications. Having clear interface definitions between the different parts of the application is essential of a loosely coupled architecture. It is easier to allow the capability to build independently, tested at the interface level and then brought together when the parts are ready. By defining clear interfaces between application components and properly handling forward and backward compatibility, there is less of a requirement for coordinated simultaneous deployments. This allows teams to be less dependent on other parts of the application during the development process, and allows for easier automated testing.

The practice of Automate testing is critical to any DevOps transformation. It provides the capability to improve the speed of delivery while reducing risk. Moving to agile development practices while still requiring people to perform manual tests, will not allow the quick iteration on the capability. Even for existing applications you can generate interface tests to begin to build up automated regression test cases. Automated tests can be generated based on interface definitions such as a JSON schema or a COBOL copybook for new development. The increased focus on testing the interfaces early helps reduce the integration problems generally found late in the development cycle.

These are just a few of the key practices of DevOps but hopefully they have started to demonstrate how DevOps is as applicable to the Systems of Record on z/OS as it is to Systems of Engagement.   To learn more read the best practices for a DevOps approach with IBM System z whitepaper or watch the replay of the November 20, IBM DevOps Symposium webcast.

About the Author:

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

December 2, 2014
Transforming applications with Cloud and DevOps – one hybrid solution for multiple challenges
Are you on cloud yet or clouded? The answer lies in how you have adopted the transformation. Today, the world is Hybrid. For large enterprises and organizations, it always has been. Almost no enterprise is monolithic when it comes to their environments. They may already have different distributed environments and/or mainframes in their ecosystem. The advent of cloud has only added to this complexity and hybrid nature of the environments. Enterprises which have replaced their datacenter with cloud adoption, in some cases are unable to do so completely or even adopt a singular cloud solution as that remains the domain of born-on-the-web companies that started on the cloud (think Netflix) or started on physical servers and migrated very early to the cloud (think WhatsApp). You cannot think of a big bank or even a telecom giant that is a Cloud Service Provider (CSP) that fits this bill.

For the typical Enterprise (IBM included), the cloud has replaced and consolidated large sprawls of physical servers. However, physical environments remain, and may never go away and cost of migration plays a very important part in this retention. There may be large data-heavy applications that are hosted on distributed environments that may be just too expensive to re-host on the cloud. Then there are mainframe-hosted applications that cannot be migrated to the Cloud. Or the migration to cloud may be a massive multi-year transformation that you are only starting on and will have to live with workloads spread between the cloud and the physical world for an extended period of time.

What’s interesting is that, even the cloud itself will be ‘Hybrid’ in nature. There may be combination of on-premises and off-premises clouds adopted, with off-premise’s ‘cheaper’ cloud used for less critical workloads like Dev-Test environments, and on-premise’s cloud for business-critical workloads. There may also be the presence of a Platform-as-a-Service (PaaS) being used for developing innovative Systems of Engagement applications or for experimentation, which co-exists with an Infrastructure-as-a-Service (IaaS) Cloud for Systems of Record applications and other traditional workloads.

That is the complex world we live in.

DevOps and Hybrid Cloud

Cloud is the transformation enterprises are looking for whereas DevOps practices help achieve the transformation with speed and quality. When we talk about DevOps in the Hybrid Cloud environments, there are two main scenarios that can be adopted.
1. Cloud hosted application delivery pipeline: When adopting DevOps one adopts a set of tools that create what is an Application Delivery pipeline. This includes tools such as an Integrated Development Environment (IDE), a Source Code Management (SCM) System, a Build tool, an asset repository, Test tools, an Automated Application Deployment tool, Environment provisioning tools and application monitoring tools, etc. All these tools can be hosted in the cloud and made available as a service. If you are using a PaaS such as IBM Bluemix as your application delivery platform, it includes these DevOps services.
2. Cloud Hosted Environments: As applications are developed and delivered to production, they pass through multiple environments. These include development environments, multiple test environments, System Integration Test (SIT), User Acceptance Test (UAT), Performance Test, and potentially other pre-production environments (names and type vary from organization to organization), and of course Production. These environments may be spread over cloud and physical infrastructure, or even multiple cloud environments.
IBM has hosted offerings for the DevOps delivery pipeline that cover the first scenario, including its Collaborative Lifecycle Management as a Service (CLMaaS) and cloud hosted Rational Software Delivery Platform (SDP) tools available through IBMs business partner CloudOne. As mentioned before IBM Bluemix PaaS includes in it DevOps Services to deliver these capabilities in the PaaS.

For the purpose of this post, we will examine the second scenario in detail.

Application Delivery for Hybrid Cloud Environments:

Let’s examine a customer scenario I worked on recently. This customer, a large bank, was looking to host all their application delivery and production environments to the cloud. For cost management, they had decided to host their highly dynamic Development and Test (Dev-Test) environments on an off-premise’s ‘public’ or ‘virtual-private’ cloud, and host their Production environments on-premise on a private self-managed cloud. At the same time, their core business systems, in this case their core banking systems, all remained hosted on a Mainframe z/OS system. They are exposing their core Banking Applications to other applications that consume their services as REST APIs via an IBM DataPower gateway.

The goal of this organization is to be able to deploy complete business capabilities which comprises of services and middleware components deployed to the Production Cloud, and the back-end Mainframe. The primary challenge was to use a Deployment Automation tool that can deploy components and manage application configurations across all these multiple environments.

The second challenge was the need to deploy applications under development as they progressed through different environments in the delivery pipeline. These environments were hosted in a public cloud. As the production environments are hosted in a private cloud, there was a need to use ‘pattern’ technology that would allow for the provisioning of ‘production-like’ environments through the lower pre-production environments. These ‘patterns’ would allow for the production environments and the pre-production environments that match, albeit with different configurations and scale, to be managed and versioned as code. These patterns would evolve as the applications and the environments they were deployed on evolved through the development iterations.

Architecture for Application Delivery for Hybrid Cloud

Our discussion so far now leads us to designing architectures for application delivery for Hybrid Cloud which requires a deployment automation tool that supports multiple technologies comprising the hybrid cloud environment. As discussed before, multiple technologies ranging from off-premise, on-premise clouds to physical infrastructure may be included in these hybrid environments. IBM UrbanCode Deploy with Patterns provides such support.

IBM UrbanCode Deploy with Patterns supports two cloud pattern technologies:
1. IBM Virtual System Patterns
2. OpenStack HEAT/HOT templates
This allows IBM UrbanCode Deploy with Patterns to support both provisioning of cloud environments using these patterns, and the deployment of applications to these environments, whether to an on-premise or off-premise cloud. In addition, it supports application deployment to static environments on physical infrastructure – distributed and mainframe. The Cloud technologies supported by UrbanCode Deploy with Patterns include OpenStack Private Cloud, Softlayer, Amazon Web Services and VMWare vCenter. In addition, IBM UrbanCode Deploy with Patterns also supports deploying buildpacks to IBM Bluemix PaaS.

It is apparent from the example above that hybrid cloud is changing the face of enterprises and organizations today. With the speed the market is changing today, one cannot depend on waiting for transformation. IBM can help enterprises with their Cloud and DevOps journey leveraging our unique cloud and DevOps expertise. On November 20, you can know more about Hybrid cloud strategies and interact with some of the industry experts like Rosalind Radcliffe (Distinguished Engineer, Chief Architect for CLM and DevOps, Member of the Academy of Technology at IBM), Richard Irving (Certified Client Technical Professional at IBM) and Wayne Monk (Vice President, Business Development and Alliances at Skytap) at the IBM DevOps Symposium in the New York area (Jersey City). We are streaming the first hour as a series of lightning talks given by few distinguished industry leaders – so join us live or on the web.
November 18, 2014
Eight critical DevOps practices: innovate, deliver, repeat
DevOps has been garnering a lot of interest for some time. Discussions and debates on forums like devopsy.kinsta.cloud are improving our collective understanding of the right approach and now we are seeing concrete proof points of fast-movers applying DevOps practices to disrupt entire industries with rapid-fire, digital-innovation based on Cloud, Big Data and Mobile technologies. I have personally been part of this transformation at IBM for several years and would like to reflect on what we have learned, and also share with you results of a recent study from Forrester Research.

DevOps helps organizations address a critical business challenge – that of continuously capturing and responding to feedback (both internal and external) so we can rapidly and repeatedly turn innovative ideas into highly relevant, and desirable, products and services. This involves not only development and operations, but all aspects of the organization, as it entails the collaboration across the entire organization including business and supply chain. Compared to single-direction, traditional models, DevOps is bi-directional and is based on not just pushing something out to the customer but also on getting their feedback to make improvements.

In a recent webcast, I discussed eight DevOps practices that speed up software delivery with Kurt Bittner, Principal Analyst at Forrester and a leading expert on agile and iterative software development. This webcast highlighted a recent Forrester survey on DevOps practices, cycle times and where enterprises are in terms of the maturity of DevOps practices adoption.
You can watch the webcast replay here to know more – ibm.biz/Forrester-talk

Their survey of 600 IT professionals with application development responsibilities found that about a third of teams consistently deliver at cadences of one to three weeks and that the fastest teams generated higher business satisfaction than slower teams, an indication they don’t sacrifice quality to deliver fast. The study reveals how these teams did it: by adopting the following eight DevOps practices:
1. Minimum Viable Product – Deliver the smallest viable product or application and then improve it in subsequent rapid releases, based on feedback, and delivering value incrementally.
2. Dedicated Teams – Form dedicated, cross-functional teams, avoid over-specialization and ensure they are not interrupted by side projects.
3. Loosely Coupled Architecture – Use loose architectural coupling within and between applications to reduce complexity and enable delivery in small increments.
4. Minimize Hand-offs, Maximize Flow – Eliminate unnecessary steps, delays and friction between steps to increase the flow of work.
5. Deliver in Small Batches – Deliver in smaller batches helps to expose the most uncertain issues first and enables feedback on the most valuable usage models earlier.
6. Transparency – Transparency into progress helps everybody to see where you are at any point in time and also visibility into risk without decreasing productivity.
7. Eliminate Overhead –Eliminate the overhead of periodic and manual status reports and status meetings which absorbs valuable time and distracts focus from delivering value.
8. Automate Testing using APIs – Shift away from heavy manual testing to improve delivery speed, quality, and testing accuracy, and dramatically reduce cost.
The study refutes the myth that releasing fast requires you to sacrifice quality and accept higher risk. Adopting these eight DevOps practices, especially automated testing and delivering in small batches, does exactly the opposite: small incremental releases are more thoroughly tested, more stable and lower risk.

The best part about DevOps adoption is the flexibility to choose which practices to adopt first, based on each organization’s priorities, and then to incrementally adopt the rest of the practices as needed to optimize the software delivery lifecycle and accelerate innovation.

To learn more about the survey and the eight DevOps practices, download the Forrester study along with the approach that you can follow to adopt these as per your organization’s current state of delivery cycles.

About the Author

Ashok Reddy is responsible for Product Management & Strategy, product Design/user experience and Business Development for Rational Software Division of IBM Software Group and for the IBM DevOps portfolio. He is based in Raleigh, NC, USA. Ashok’s role involves all aspects of global product delivery including setting product strategy and for product line management, establishing product roadmaps and partnerships for IBM DevOps portfolio.
October 22, 2014
Enterprise DevOps: organizational change a must

There has been a lot of discussion in the blogosphere, including here at devopsy.kinsta.cloud, lately about the challenges of adopting DevOps in the Enterprise space. These challenges at the end boil down to the need for organization change. There are organizational structures that appear to hinder DevOps adoption in large enterprises, that are inherent to enterprises and smaller companies do not have. In enterprises different functional teams – Dev, Ops, Security, QA, etc. may be under totally different management chains. It is not uncommon to have to go up thru several layers of management to reach a common senior executive. In other cases, there may be an entire software supply chain in place that is made up of not just internal but also outsourced or external suppliers. These suppliers may or may not ‘play ball’ when it comes to the changes in processes required to adopt DevOps. Especially if they are bound by outsourcing contracts that do not make change possible or profitable for them.

DevOps as a philosophy has had as its centerpiece the principle that all the application delivery teams (Dev, QA, Ops, Business Analysts, Architects, Security…) need to align better and collaborate towards the common goal of delivering applications, in a efficient and constantly improving manner. This is a people and organizational principle, not just a process centric principle. To me adopting this is more important when adopting DevOps than any process or tool.

This post discusses key guiding principles on which this DevOps driven alignment of different teams in an enterprise should be based. They are designed to improve collaboration between these teams and to break down the proverbial ‘wall’; to end the water-SCRUM-fall, when it comes to the relationships between the different application delivery stakeholder teams in the enterprise. This is not an easy effort. It depends on the existing culture at the organization, the presence of outsourced suppliers, politics, contracts and above all, the desire to change.

These guiding principles are:

1. Shift Left:

Organizationally the goals of DevOps are to bring all the teams involved in application delivery together closer. Not just at deployment time, as they may do already, but all thru the delivery cycle. It requires Ops to allow Developers to take more responsibility of the operational characteristics of the applications they are building, for example. In turn, it requires Developers to keep Operational considerations in mind while building their applications. It requires analysts and architects to think holistically and work with Dev and Ops teams as they design and enhance the application. This is referred to in the DevOps world as ‘Shift Left’. As in shifting towards the left, Ops responsibilities. Shifting it to earlier in the software delivery lifecycle, towards Dev. It is shifting left the testing of your software to as early in the lifecycle as possible. It is shifting left the point at which collaboration between teams begins. It is shifting left the responsibility to deliver code to production – way left. Can someone in finance be held responsible for code not being delivered on time because they delayed approving a budget line item?

2. Collaborate across all teams:

Different functional teams typically use different tools to manage their projects and activities, for change management and (outside of email) different collaboration tools. In order to better collaborate across the organizational boundaries, all teams should start using the same Change Management and Work Item Management tools or in the worst case, use tools that are integrated. This allows seamless visibility across tools and traceability between respective Change Requests. Real-time collaboration using a common tool is obviously the best scenario.

3. Build ‘Application Aware’ Environments:

As we move towards Software Defined Environments, we have the ability to build, version and manage complex environments, all as code. All of the benefits of this are moot if the environments are not a perfect fit for the applications and more importantly the changes to the applications being delivered. The goal is hence to build Environments that are ‘Application Aware’ or are fine-tuned for the applications they are designed to run. No more cookie cutter Virtual images for all kinds of applications. More importantly, one needs to ensure that the environments are architected in a manner to allow for the evolution of the applications, both as they are developed; as they are projected to change or as they may evolve in the future. This obviously, would require close collaboration between Dev and Ops. Development Architects and Product Managers need to work with the IT Architects and Operations Managers to architect environments and their projected evolution to align with that of the application. Not only that, but also allow enough resilience in the environments to allow for unexpected change. For example, massive change caused by a super successful App. Think Instagram and how the founders had to keep changing their server environment almost daily as millions joined their service.

4. Environment Sprints:

Agile Development Principles prescribe that at the end of every Sprint, developers have a build. An executable build that runs, even if does not do much in terms of functionality. The next evolution of this concept is to extend it to environments. This would mean that at the end of each Sprint, the Dev team would have an executable AND the Ops team would have an environment, a production-like environment ready that the executable can be deployed on. This would allow the build to be tested. That too in a production-like environment. This would also provide immediate feedback to the Ops teams on the behavior of the application in their environment and use that feedback to improve the environment. This requires the Ops and Dev teams to align better. They will both have to use a single Sprint plan for releases – of their Builds and Environments respectively and will provide feedback to both at the end of every Sprint, using which Dev can enhance their Apps to improve functionality and performance and Ops can enhance the environment for the same. Leveraging full stack deployment – deploying at each instance the full stack that includes the environment, middleware and the application being deployed – could very well be called the ‘holy grail’ of DevOps. (Brief commercial break – IBM just announced the new offering UrbanCode Deploy with Patterns that provides full stack deployment leveraging OpenStack HOT patterns).

The Human factor

These principles are designed to foster Application Delivery team alignment from a teaming perspective, from a people perspective. These however do not replace the need for good old team building. Whether it is thru face to face get togethers or in todays distributed worlds, thru regular virtual meetings and online collaboration in real time. The best teams are the ones where the people know each other, trust each other, look out for each other and when there are challenges, know who to pick up the phone (or launch Skype) and talk to.

June 11, 2014