The abstract to the talk is as follows:

Enterprise Applications are typically no more than a User Interface to a set of complex back-end systems. They allow Systems of Record to become Systems of Interaction by putting the records and the ability to interact with them in the palm of your hand. A good User Experience with such a Mobile App requires designing the entire end-to-end architecture with the User Interaction in mind. What is your enterprise mobile apps’ back-end? Is it a single ‘black-box’ serving up data via REST calls? Or is it a set of back-ends, communicating with your app’s UI via multiple APIs. Does your back-end include services that require you to change your app’s UI every time it gets updated? Does the nature of your back-end impact how you build your app, impact the UI design decisions you need to take? How do you test all your back-end(s) for functionality and performance? How do you integrate all these pieces together? How do you provide a good User Experience? As you build complex mobile apps, the architecture of your complete end-to-end system – Backend to UI – becomes critical to your application’s success. This presentation will help attendees identify key architectural decisions that they need to take early in their mobile app development lifecycle to help address these challenges, reduce risk and cost and enhance the User Experience. It will do so by presenting examples of successful architectures of mobile apps and explore key decisions they took and why.

The key theses of the talk is:

• If you making Enterprise Apps, you Mobile Apps are the front-end to a complex back-end system
• Architectural Decisions determine your UX

In all, there are Three UX Decisions you need to take:

1. Your UI technology should match your content
2. Your Backend Architecture and how it connects to your App
3. Your UX  and flow should match your Backend UX and flow

The Slides are Attached:

The abstract to the talk is as follows:

Enterprise Applications are typically no more than a User Interface to a set of complex back-end systems. They allow Systems of Record to become Systems of Interaction by putting the records and the ability to interact with them in the palm of your hand. A good User Experience with such a Mobile App requires designing the entire end-to-end architecture with the User Interaction in mind. What is your enterprise mobile apps’ back-end? Is it a single ‘black-box’ serving up data via REST calls? Or is it a set of back-ends, communicating with your app’s UI via multiple APIs. Does your back-end include services that require you to change your app’s UI every time it gets updated? Does the nature of your back-end impact how you build your app, impact the UI design decisions you need to take? How do you test all your back-end(s) for functionality and performance? How do you integrate all these pieces together? How do you provide a good User Experience? As you build complex mobile apps, the architecture of your complete end-to-end system – Backend to UI – becomes critical to your application’s success. This presentation will help attendees identify key architectural decisions that they need to take early in their mobile app development lifecycle to help address these challenges, reduce risk and cost and enhance the User Experience. It will do so by presenting examples of successful architectures of mobile apps and explore key decisions they took and why.

The key theses of the talk is:

• If you making Enterprise Apps, you Mobile Apps are the front-end to a complex back-end system
• Architectural Decisions determine your UX

In all, there are Three UX Decisions you need to take:

1. Your UI technology should match your content
2. Your Backend Architecture and how it connects to your App
3. Your UX  and flow should match your Backend UX and flow

I will post the slides here after the conference. Come say Hi to me if you are attending

These guiding principles are:

1. Shift Left:

Organizationally the goals of DevOps are to bring Dev and Ops closer. Not just at deployment time, as they may do already, but all thru the development cycle. It requires Ops to allow Developers to take more responsibility of the operational characteristics of the applications they are building. In turn, it requires Developers to keep Operational considerations in mind while building their applications. This is referred to in the DevOps world as ‘Shift Left’. As in shifting towards the left, some Ops responsibilities. Shifting it to earlier in the software delivery lifecycle, towards Dev. 

2. Collaborate across all teams:

The Dev and Ops teams typically use different tools to manage their projects, for change management and (outside of email) different collaboration tools. In order to better collaborate across the organizational boundaries, these teams should start using the same Change Management and Work Item Management tools or worst case, use tools that are integrated. Thus allowing 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 kids 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 that runs, even if does not do much in terms of functionality. It has been proposed (by the likes of Gene Kim) that this concept be extended 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 (potentially with very limited production like capabilities), built 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 also provides an opportunity for 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.

The Human factor 

These principles are designed to foster Dev and Ops 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.

This series on Adopting DevOps and my earlier series on Understanding DevOps will continue in future posts.

Related Posts:

Understanding DevOps:

• Understanding DevOps – Part 1: Defining DevOps
• Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery
• Understanding DevOps – Part 3: The Battle of Dev vs Ops
• Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring
• Understanding DevOps – Part 5: Infrastructure as Code

Adopting DevOps:

• Adopting DevOps – Part I: Begin with the Why
• Adopting DevOps – Part II: The need for Organizational Change

Other DevOps Posts:

• What is Water-SCRUM-Fall?
• Leveraging DevOps in a water-SCRUM-fall world
• Monetate’s 12-step program for Continuous Delivery
• The State of DevOps (by PuppetLabs)
• DevOps for Mobile Apps – Slides from IBM Pulse 2013
• Chef for DevOps – An Introduction

Dev vs Ops?

Historically, most organizations have struggled with this Dev-Ops relationship/alignment. The reason for that is very understandable. Dev is tasked with the job of producing innovative capabilities and automating business processes for speed and efficiency. Ops on the other hand is tasked with making sure the systems these applications run on are stable, available and responsive. Dev is measured on the change they create. Ops is measured on the stability they provide. Dev is ‘dinged’ for not producing change on time or not producing enough change. Ops is ‘dinged’ for instability or downtime of the systems or unexpected change. Dev wants to introduce new capabilities and features as soon as possible. Ops wants to keep stability at all times. Reasons enough to butt heads.

Then again, I am not suggesting that these differences are in-reconcilable or even that they are like opposing teams. After all, their individual goals are just two faces f the same coin. Both Dev and Ops are the to provide a system that adds value to their customers and/or users. They just have to communicate and collaborate more to make sure they align and work together to make this happen. Communicate enough to ensure Dev brings about innovation keeping Ops in the loop on the changes Ops will need to make to enable those innovations and Ops need to get more involved in the processes of Dev and get more visibility into what Dev is building so they can preemptively make the changes they need to make to deploy what Dev produces. Work as a team!

Organizational Change:

One of the reasons this is a challenge is that in most large companies Dev and Ops have been separated by a pretty large organizational ‘wall’. They are typically in separate management chains – Dev being in a CTO or VP of Dev’s organization and Ops in a COO or VP of operations’ organization. This results in hindered communications. In outsourced organizations, Dev and Ops maybe totally different sets of (multiple) vendors who never talk outside of a change management tool and contract based negotiations of responsibility! I recently met with an company where a project we were looking at had three different vendors responsible for development, QA and infrastructure respectively. This is a normal arrangement for the whole company, which has less than 20% of its IT staff made up of employees. Not much Dev-Ops collaboration going on there.

So, how does one do it? Adopting DevOps takes considerable transformational change in the organization. There are a few key principles in the DevOps space that must be used to form the basis of this transformational change. I will discuss them in the next post.

Do you see an effort to align Dev and Ops going on in your organization? What kind of Organization Change is going on? Does how Dev and Ops teams are measured and compensated need to be re-aligned too? Share your thoughts by leaving a comment below.

Related Posts:

Understanding DevOps:

• Understanding DevOps – Part 1: Defining DevOps
• Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery
• Understanding DevOps – Part 3: The Battle of Dev vs Ops
• Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring
• Understanding DevOps – Part 5: Infrastructure as Code

Adopting DevOps:

• Adopting DevOps – Part I: Begin with the Why
• Adopting DevOps – Part III: Aligning Dev and Ops Teams

Other DevOps Posts:

• What is Water-SCRUM-Fall?
• Leveraging DevOps in a water-SCRUM-fall world
• Monetate’s 12-step program for Continuous Delivery
• The State of DevOps (by PuppetLabs)
• DevOps for Mobile Apps – Slides from IBM Pulse 2013
• Chef for DevOps – An Introduction

Check out the full session list.

Related Posts:

• Speaking Engagements
• Slides on ‘DevOps for Mobile Apps’ from IBM Pulse 2013

The agenda of the deck is as follows:

• A Review of DevOps
• IBMs Continuous Delivery solution
• Introduction to Chef
• Chef and Continuous Delivery

Related Posts

Understanding DevOps:

• Understanding DevOps – Part 1: Defining DevOps
• Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery
• Understanding DevOps – Part 3: The Battle of Dev vs Ops
• Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring
• Understanding DevOps – Part 5: Infrastructure as Code

Adopting DevOps:

• Adopting DevOps – Part 1: Begin with the Why
• Adopting DevOps – Part II: The Need for Organizational Change

Other DevOps Posts:

• What is Water-SCRUM-Fall?
• Leveraging DevOps in a water-SCRUM-fall world
• Monetate’s 12-step program for Continuous Delivery
• The State of DevOps (by PuppetLabs)
• DevOps for Mobile Apps – Slides from IBM Pulse 2013
• Chef for DevOps – An Introduction

Some key findings (reproduced here without editing from PuppetLabs’ site):

Key Findings

• DevOps adoption is accelerating. Sixty-three percent of respondents have implemented DevOps practices, compared to 50 percent in 2011—a 26 percent increase in DevOps adoption rate.
• DevOps offers increased agility and reliability. Respondents from organizations that had implemented DevOps reported benefits in staggering numbers: More frequent software releases and improved software deployment quality were both reported by 63 percent. Beyond directly reporting benefits, these respondents were five times more likely to be part of a high-performing organization.
• High-performing organizations enabled by DevOps deploy code 30 times more frequently than their peers. These organizations are deploying several times a day instead of once a month, and completing those deployments 8,000 times faster.
• High-performing organizations enabled by DevOps have 50 percent fewer failures. Respondents from these organizations reported double the change success rate of their peers, and reported restoring service 12 times faster.
• Demand for DevOps skills continues to grow. Job listings for “DevOps” are up by 75 percent, and those hiring for DevOps positions are primarily looking for coding/scripting abilities and people skills.

I found this infographic they created to be an excellent overview of the report, which can be downloaded here. What are your thoughts on this report? Leave a comment to share.

2013 State of Devops Infographic | Puppet Labs2013 State of Devops Infographic

Embed 2013 State of Devops Infographic on Your Site: Copy and Paste the Code Below

2013 State of Devops Infographic – An infographic by the team at 2013 State of Devops Infographic.

Related Posts

Understanding DevOps:

• Understanding DevOps – Part 1: Defining DevOps
• Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery
• Understanding DevOps – Part 3: The Battle of Dev vs Ops
• Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring
• Understanding DevOps – Part 5: Infrastructure as Code

Adopting DevOps:

• Adopting DevOps – Part 1: Begin with the Why
• Adopting DevOps – Part II: The Need for Organizational Change

Other DevOps Posts:

• What is Water-SCRUM-Fall?
• Leveraging DevOps in a water-SCRUM-fall world
• Monetate’s 12-step program for Continuous Delivery
• The State of DevOps (by PuppetLabs)
• DevOps for Mobile Apps – Slides from IBM Pulse 2013
• Chef for DevOps – An Introduction

Our slides are available on Slideshare.

Leigh Williamson’s blog: 

• The Mobile frontier

Related Posts:

1. Understanding DevOps – the Series
2. There is no such thing as ‘DevOps for Mobile’
3. What is a Mobile Device after all?
4. 2013: The year of Mobile Fragmentation

Adopting DevOps hence, is not just about adopting a product or a process. It is about undergoing Transformational Change.

Why DevOps?

Organizations want to create innovative applications and features. They create these applications or services to solve a business problem. Either for themselves (better CRM system) or for their customers/users (better Web Portal). Whether they are a startup with an innovative Mobile App; a large financial institution with their complex transactional systems; or a Military contractor building a ‘dirt-to-space’ real-time battlefield management system, they are all looking for a way to make what they build better.

Better can mean many things. For the startup, better may be the number of new features they can get out to their users, fast. Quality may not be their highest priority. For the financial institution, better may be minimizing downtime for their systems every time they push out a new capability. The number of new features they release may be lower on their list. For the military contractor better may be ensuring close to 100% reliability of their system. Innovative features may be trumped by quality and reliability for them.

So, the reason to adopt DevOps will vary considerably from organization to organization and even from team to team within the same organization. The team building the customer website may have very different priorities than the team deploying the new HR system. All reasons are good reasons, as long as it is not ‘it’s the buzzword the VP heard at the last conference’.

Let’s list some of the reasons an organization may adopt DevOps:

• Time to value
• Speed of deployment
• Reduce cost/time to deliver
• Reduce time/cost to test
• Increase test coverage
• Increase environment utilization
• Minimize deployment related downtime
• Minimize deployment time issues (you know, the weekend long deployment marathons)
• Minimize roll-backs of deployed Apps
• Increase the ability to reproduce and fix defects
• MInimize ‘mean-time-to-resolution’ (MTTR) of production issues
• Reduce defect cycle time
• Reduce challenges related to Dev and Ops collaboration

…and I could go on. In a nutshell, the reason(s) to adopt DevOps has to be a reason that provides value to the organization.

The goals for DevOps an organization has will determine which practices and principles of DevOps the organization needs to adopt. I have worked with an organization whose biggest challenge was the limit they had on their ability to test often and thoroughly. Their QA environments took too long to be ‘refreshed’ for every test cycle, extending their test cycles to unacceptable lengths. What they needed to do was virtualize their test environments with ‘production-like’ systems (more on that in the next post), which could be provisioned and populated with ‘fresh’ test data in minutes/hours, rather than the days it took them currently. For them, adopting Continuous Delivery to Test, by building a Delivery Pipeline that would allow them to automate the cycle from a developer kicking off a build to tests being run in a ‘freshly’ provisioned environment, would add tremendous value. This is where they should begin and limit their DevOps adoption too. Once they see value from this one capability, they can examine other areas of challenges for them that can be addressed thru DevOps.

It is not easy or cheap:

Adopting DevOps is not easy or for that matter cheap. Not in terms of cost of tools, people, etc, but in terms of the effort it takes. It would be a multi-month, or depending upon your existing maturity, even a multi-year project. The good news is that if done right, starting and progressing down the path can produce value pretty early. I repeat, if done right.

The main reason it is not easy is because of the transformational change your organization will need to undergo. The People part of the equation will take more effort than the Process or Tools.

So, assess your areas of improvement in your delivery cycle. If you do not have the skills in-house, hire a consultant/consulting organization to conduct such an assessment. The assessment would help determine which areas in the DevOps spectrum of capabilities would provide you the highest ROI. Which would address the key pain-points you have. Then create a roadmap for adoption. <start commercial break> We at IBM conduct such assessments all the time. Contact us…</end commercial break>.

More on Transformational Change for DevOps in Part II.

Understanding DevOps:

• Understanding DevOps – Part 1: Defining DevOps
• Understanding DevOps – Part 2: Continuous Integration and Continuous Delivery
• Understanding DevOps – Part 3: The Battle of Dev vs Ops
• Understanding DevOps – Part 4: Continuous Testing and Continuous Monitoring
• Understanding DevOps – Part 5: Infrastructure as Code

Adopting DevOps:

• Adopting DevOps – Part 1: Begin with the Why
• Adopting DevOps – Part II: The Need for Organizational Change

Other DevOps Posts:

• What is Water-SCRUM-Fall?
• Leveraging DevOps in a water-SCRUM-fall world
• Monetate’s 12-step program for Continuous Delivery
• The State of DevOps (by PuppetLabs)
• DevOps for Mobile Apps – Slides from IBM Pulse 2013
• Chef for DevOps – An Introduction