Home > Blogs > VMware Operations Transformation Services > Monthly Archives: January 2016

Monthly Archives: January 2016

3 Capabilities Needed for DevOps that You Should Already Have in Your Cloud Organization

Pierre Moncassin-cropBy Pierre Moncassin

A number of enterprise customers have established dedicated organizations to leverage VMware’s cloud technology. As these organizations reach increasing levels of cloud maturity, we are more and more often asked by our customers: “how is our organization going to be impacted by DevOps?“

Whilst there are many facets – and interpretations – to DevOps, I will highlight in this blog that many of the skills needed for DevOps are already inherent to a fully- functioning cloud organization. Broadly speaking, my view is that we are looking at evolution, not revolution.

First, let’s outline briefly what we understand by DevOps from a people/process/technology point of view:

  • DevOps EvolutionPeople: DevOps originated as an approach, even a philosophy that aims to break down organization silos, specifically the traditional gap between application developers and operations teams. This is why it is often said that DevOps is first of all, about people and culture. Application Developers are sometimes depicted as “agents of change” whilst the Operations team are seen as “guardians of stability” – teams with opposite objectives that can lead to well-documented inefficiencies.
  • Process: From a methodology point of view, DevOps integrates principles such as “agile development”. Agile this provides the methodological underpinning for Continuous Delivery, an approach that relies on the frequent release of production-ready code. Whilst Agile development was originally about applications, DevOps extends the principle to infrastructure (leading to the idea of “agile infrastructure”).
  • Technology: DevOps processes necessarily incorporate the use of development and automation technologies such as: source code control and management (e.g, Git); code review systems (e.g., Gerrit); configuration management (e.g., Puppet, Chef, Ansible, SaltStack); task execution and management (e.g., Jenkins); artifact and application release tooling (e.g., VMware vRealize Codestream); and others. In order to manage those tools as well as applications generated by them, DevOps also incorporates operations tooling such as provisioning and monitoring of the underlying infrastructure (e.g., vRealize Automation and vRealize Operations).

Features of a cloud organization adapted for VMware’s cloud technology, are described in detail in the white paper “Organizing for the Cloud” (link below):

https://www.vmware.com/files/pdf/services/VMware-Organizing-for-the-Cloud-Whitepaper.pdf

DevOps Organizational Model

Here are, in my view, some key capabilities in the cloud organization as recommended by VMware:

1) The rise of developers’ reach.

As development departments mature beyond  writing strictly  application code, their reach spans broader knowledge bases. This includes writing code that performs end-to-end automation of application development, deployment and management: applications and infrastructure as code. Developers utilize the same skills traditionally relied on in application teams and apply them towards  cloud services:

  • Provisioning for example with VMware vRealize Automation.
  • Automating network configuration with VMware NSX
  • Automating monitoring and performance management (VMware vRealize Operations).

This shift in reach from Ops to Dev forms the the basis of ‘infrastructure-as-code’ – a now relatively standard cornerstone of DevOps.

2) Ability to work across silos

One of the defining capabilities of a cloud team  – and a key skill required of all team members, is to be able to break the boundaries between silos:

  • Technical silos: for example the customer-facing team (Tenant Operations, also known as IT Service Center) will define end-to-end cloud services across technical silos such as compute (servers), networks and storage. Service Owners and Service Architects will define the scope and remit of such services; Service Developers will put together the workflows and scripts to allow end users to provision those services automatically.
  • Functional silos – merging “Design” and “Run”. Whilst traditional IT organizations tend to separate teams of architects/designers from operations team, the cloud development teams bring those skills together. Service Developers for example will build workflows that include not only the deployment of infrastructure, but automate its monitoring and configuration management at runtime. Service Owners are involved both in the definition of services but also act as point of contact in resolving incidents impacting those services.  DevOps takes this trend to the next level by merging the “dev” and “ops” teams.

3) Increased alignment with the business

Whilst all IT organizations aim to align with the business,  A model organization (as described in “Organizing for the Cloud”) aligns business lines with practical structures and roles.  For example this model defines dedicated roles such as:

  • Service Architects who translate business requirements into functional and technical architectures.

DevOps continues this trend towards business alignment: in a context where business is increasingly driven by revenue-generating applications, application development becomes integral to the lines of business.

DevOps Organization

In sum, a well-functioning cloud team will have established many of the positive traits needed for DevOps – a preference for rapid development over fire-fighting, for bridging silos across technologies and processes, and for close cooperation across business lines.

Going one step further DevOps pushes these traits to the extreme – preferring continually improving development and automation of application and infrastructure. For example a Devops team might leverage VMware’s Cloud Native Apps capabilities to build applications optimized to run on cloud from “day one” (for more details see https://www.vmware.com/cloudnative/technologies).

Take-away – practical ways to prepare your cloud team for DevOps;

  • Encourage job rotation of key team members across technical skills and functions.
  • Continuously expand your team’s knowledge and practice of cloud automation tools. This can include advanced training on tool such as vRealize Automation, vRealize Operations; as well as generic skills in analysis and design.
  • Ensure that key tenant operations roles (i.e. customer facing roles) are in place and give them increasing exposure to application development and business lines.
  • Develop an awareness of Agile approach for example by formal training and/or nominating ‘Champions’ in your team.
  • Build up a skill base in Continuous delivery, for example leveraging training or a pilot with vRealize Codestream.

—-
Pierre Moncassin is an operations architect with the VMware Operations Transformation global practice and is based in the UK.

How to Overcome the Resistance to Change

Gordon HodgsonBy Gordon Hodgson

As the New Year begins IT Organizations are beginning to implement their strategies for 2016 which will bring change to their operations that will have impact their staff.  Mark Fields, the CEO at Ford addresses strategy when he is quoted as saying, “You can have the best plan in the world, and if the culture is not going to let it happen, it’s going to die on the vine.”, in other words the culture of the organization needs to change as much if not more than the technology or the methodologies and this is going to be a much bigger challenge.

In 500 BC Heraclitus the Greek Philosopher said that “The Only Thing That Is Constant Is Change -” He seems to have been right and change continues at much faster pace today especially in technology.  Some people embrace change, some fear it, while others try to avoid it all together but no matter your view change is constant and it is disruptive. Change arrives at your doorstep in many ways and with it comes the opportunity to respond either in a positive or negative style and to influence those around you.

My Experience as a CIO

Change

A few years ago I had the great opportunity to lead IT at the world’s largest faith based humanitarian organization as their International CIO. This large Non-Governmental Organization (NGO) had IT staff in 102 countries mostly in the developing world. As you might imagine organizational change in this type of environment was a challenge almost on a daily basis as the majority of employees were focused on solving world hunger and oppression and not on the concerns of IT.  NGO’s by nature are non-profit and meeting the bottom line was not always top priority.

As the CIO I was charged with bringing systems into the 21st century and reducing the overall cost of IT on a global basis.  Organizational Change for IT is difficult in the western world but move that into the developing world with a 102 different cultures and the challenges multiply significantly.  In order to accomplish this initiative many things needed to happen but most of all I needed to be an influencer so that the vison of what needed to be done would resonate in this multicultural environment.  While many IT professional may not have all of the challenges of a large NGO they still face an uphill battle when attempting to implement major IT changes in their organizations.

With Innovation Comes Organizational Change

No one needs to tell IT Professionals that change is inevitable as they have experienced significant changes in this just the past few years.  The Cloud, Software as a Service (SaaS) Infrastructure as a Service (IaaS) Desktop as a Service (DaaS) and the most recent and perhaps the most challenging DevOps.  Customer who embrace cloud technology such as VMware’s to transform their IT services (whether Iaas, PaaS, DaaS or SaaS) will have managed a significant level of organization change. Those who continue this transformation journey towards DevOps will implement even further changes.  This article is not about these new technologies or methodologies it is about the change that they bring and some ideas on how to deal with that change from an organizational perspective.

Considerable materials have been written on the topic of Organizational Change Management and the methods to change corporate culture to adapt to the impact of a large project or of new methodologies.  In spite of all these materials the problem still exists and IT executives need to have a strategy to address these issues so that as they implement new tools they will be assimilated successfully into the organization.  There is no magic formula or silver bullet but by following some proven principles of Organizational Change Management there is an enhanced opportunity for success.

Adapted from P. Atkinson, How to Implement Change Effectively, (2014). P.34

Adapted from P. Atkinson, How to Implement Change Effectively, (2014). P.34

Taking look at some of the organizational change management challenges that are required, for example when making the move to a Dev/Ops or a Bi-modal approach to application development, which is a Gartner defined concept of optimizing both the traditional SDLC method of development with the concept of agile application development,.  In the chart below is the estimated adoption of a major change by the typical organization.  As you can see by these estimated numbers and Organizational Change requires some heavy lifting to gain acceptance across the enterprise.

To be effective with major changes such as DevOps the IT Organization needs to lead the change not just manage it. Since over 74% of the impacted staff are estimated to be either resistors or fence sitters certain steps need to be taken to influence these stakeholders to see the value of the proposed change.

Overcoming Cynicism around Change

As stated earlier, change is the one constant in almost every environment and this can cause many to become cynics to the next new corporate plan to implement a change.  From the chart presented earlier there are resistors and fence sitters and many of them could possibly be considered cynics. So to move a change forward there is a need to change the cynic’s mind about the change that is being implemented. 

It has been suggested by several studies, (Stanley, Meyer & Topolnytsky) that employee cynicism can be manifested in resistance to change at the organizational level.  Due to this finding it is important for management to take this into consideration when attempting to implement changes such as Dev/Ops. Cynicism is not always easy to overcome it can be addressed by improved communications, adding a trusted advisor within the company to the project team, someone that others look up to and respect.  Management should be a transparent about the change as possible to be continue to show the value to the overall organization of this change.

Becoming a Champion for Change

Cynicism is not the only roadblock to organizational change that management needs to consider and to deal with to be successful.  The overall organizational culture is a very powerful element that can thwart the efforts of a major organizational change such as DevOps.  To help overcome cynicism and other challenges to organizational change to the ability to become an influencer can be a great asset to your success.

Too many times management issues a mandate to implement new systems or methodologies and sends the email down the chain expecting results and success. Gartner states in a 2014 survey that only 37% of IT projects are considered successful.  If that statistic is true, and there is no reason to believe that it is not, those of us in IT need to review our approach to organizational changes that are created by IT projects and develop the ability to lead and not just manage. “We call this ability to create changes in human behavior influence and the people who do in influencers. At the end of the day, what qualifies people to be called leaders is there capacity to influence others to change” (Grenny, Patterson, Maxfield, McMillian & Switzer, p.6 2013).

As the International CIO of a large NGO I had complete responsibility for all of the IT functions outside the US but did not have the authority to mandate change, I would need to move strategy forward with influence and relationship building.  This approach is more difficult and can take a longer time to reach the goal however it is attainable and you can be successful even without a mandate.  (Grenny et al., 2013) stated that there are six major sources of influence and each one has a specific focus area and expected outcome.  By focusing on these six major sources of influence one has an increased chance to implement major IT initiatives and create organizational change.

Adapted from (Grenny et al, (2013). Influencer. p. 70). McGraw Hill Education, New York

Adapted from (Grenny et al, (2013). Influencer. p. 70). McGraw Hill Education, New York

Transparency and Communication

By following some of these suggestions and being as transparent about the changes that need to be made will contribute to your success.  Communicate as much as possible and be involved with changes as much as possible, be the change champion and allow people to see that IT leadership is behind the change with more than lip service but with support and resources to make the change happen.  Consider these points for communication (P. Moncassin, 2013) for any major organizational change as they will help to remove barriers to change and get buy in from the resistors and fence sitters.

  • Enlist visible leaders to paint the vision and be responsible or be the conduit for regular communication.
  • Communicate often and in small chunks.  Plan to communicate over an extended period of time throughout the transformation and beyond.
  • Include enough detail to make the communication personal and practical whenever possible.
  • Vary the communication approaches. Some people prefer visual communications. But others respond better to verbal communication.
  • Avoid too specialized vocabulary (a.k.a. “jargon”) or too technical content, especially at the early stages when concepts are being introduced.
  • Explain the continuity, or at least relationship with “traditional” approaches, concepts and practices that individual are familiar with.
  • Welcome resistance to change (to a point).

It is my experience there is no magic bullet that will make everyone accept the changes that need to be made and not everyone will see your vision for the future.  According to Gartner statistics only 37% of IT projects are successful and that it is estimated that 74% of employees are either resistors or fence sitters with regard to organizational changes.  IT Leadership and especially the CIO need to fully appreciate that no matter how important or necessary a change such as Dev/Ops might be there will resistance. It is futile to not recognize resistance will be present with any major change. Failure to include a plan to mitigate this resistance could negativity impact your initiatives and cause the project to fail or not be as effective as possible.

References

  • Atkinson, P. (2014) How to Implement Change Effectively. Management Services Autumn Edition. Ps. 33-38
  • Gartner. Run IT Like a Business and What does it Mean and How do you do it. Published by VMware 2014.
  • Grenny, J., Patterson, K., Maxfield, D., McMillan, R. & Switzler, A. (2013). Influencer. McGraw-Hill Publishers, New York.
  • Moncassin, P., (2013). 7 Communication Tips to Facilitate Culture Change When Adopting a Cloud Model.  VMWare Blogs
  • Stanley, D., Meyer, J. & Topolnytsky, L. (2005).  Employee Cynicism and Resistance to Organizational Change. Journal of Business and Psychology, Vol. 19, No. 4, summer 2005. Ps.429-459

=======

Gordon Hodgson is a Transformation Senior Consultant with VMware Operations Transformation Services and is based in the Portland, OR metro area.