Home > Blogs > VMware Operations Transformation Services > Tag Archives: organizational change

Tag Archives: organizational change

Updated White Paper: Organizing for the Cloud

Kevin LeesOrganizing for the CloudBy Kevin Lees

An updated version of my “Organizing for the Cloud” white paper is now available.

The update to the white paper was based around a major update to our service-oriented operating model, which we use to help our customers optimize the way they deliver services in a VMware supported environment with VMware-supported tools. The model update is based on customer feedback along with our direct experience working with customers over the last couple of years and falls into the following areas:

  • Replacing Cloud Infrastructure Ops and Cloud Tenant Ops by Cloud Service Teams
  • Expanding Roles to include specialization
  • Emphasis on creating a collaborative and agile service oriented culture

Changes to the Cloud Service Teams

When the primary focus for IT was delivering Infrastructure as a Service (IaaS), concentrating the organizational model on Cloud Infrastructure Ops and Cloud Tenant Ops was appropriate. IaaS is now seen as table stakes. Our customers are moving beyond IaaS to define and deliver higher value services to their business customers, like Digital Workspace as a Service and Data Analytics as a Service as well as even expanding Platform as a Service to a more comprehensive DevOps as a Service.

To build and support these next generation services, customers should build a Cloud Service Team that is wholly accountable and responsible for the lifecycle of their service. Cloud Tenant Ops is, therefore, replaced by a collection of Cloud Service Teams focused on the lifecycle of their respective services. Cloud Infrastructure Ops is Cloud Service Team responsible for Cloud Infrastructure Services.

Expanding Roles to Include Specializations

While using ecosystem “champions” as a mechanism for breaking down functional silos remains a key concept in “Organizing for the Cloud,” we did expand core team roles to include specialization. For example, as VMware NSXTM continues to gain incredible traction as a core Software Defined Datacenter and multi-cloud enabling technology, we expanded roles on the Cloud Infrastructure Services team to explicitly include network and security specializations of existing roles. This need is equally true across all Cloud Service Teams. By the very nature of defining, delivering, and operating more complex services, such as Data Analytics as a Service, roles specific to supporting those services are required.

Collaborative and Agile Service Oriented Culture

The biggest challenge our customers face when transforming IT to be more service oriented  is overcoming the entrenched IT culture. Becoming service oriented requires an IT mind-set shift not only in how it interacts with its customers but also how it functions internally.

Much can be learned from the DevOps concept which is, at its core, a mind-set shift in how IT and application development teams work together. These same cultural concepts apply to IT and how it approaches the way it defines, develops, delivers, and manages the services it offers. The Organizing for the Cloud whitepaper includes a treatment of the key cultural changes related to becoming service oriented, collaborative, and leveraging an Agile-based approach to service delivery.

It’s very likely that this will not be the last time the Organizing for the Cloud whitepaper is updated.  The ubiquity and flexibility of service delivery in the cloud environment continues to evolve, dramatically impacting the very nature of IT, how it interacts with its customers, and the impact it can have on the digital business. The “only constant is change” and Organizing for the Cloud will continue to be updated based on our experience working with customers as they undergo their transformations.

=======

Kevin Lees is the field Chief Technologist for IT Operations Transformation at VMware, focused on how customers optimize the way they operate VMware-supported environments and solutions. Kevin serves as an advisor to global customer senior executives for their IT operations transformation initiatives and leads the IT Transformation activities in VMware’s Global Field Office of the CTO.

Implementing an Operating Model for Agility

Paul WiggettVMworld 2016By Paul Wiggett

At VMworld Europe 2016 next week in Barcelona one of the topics you will be hearing a lot about is digital transformation. How must IT organisations adapt to support the changing business models required to remain competitive in a “liquid” business environment?

There is constant pressure on businesses to introduce innovative products and services rapidly into new and existing marketplaces. IT departments need to enable this by improving their strategy and becoming more tightly aligned with the business than ever before. The core focus needs to shift from keeping the lights on to delivering agility, efficiency, and core business value. One of the primary ways this can be achieved is by embracing a cloud-based services delivery model enabled by a flexible SDDC infrastructure platform.

Cloud-based service delivery introduces significant challenges for traditional IT operating models. For example, traditional IT Service Management (ITSM) operating models have generally focused on delivering services through a centralised set of responsibilities driven by heavy governance to decrease the rate of change and therefore risk. In addition, traditional ITSM services are often highly customized for IT’s line of business customers.

In contrast a cloud-based Service-Driven Operating Model focuses on cross-functional integration, extensive automation, proactive IT operations, and standardized services while applying the appropriate level of governance to control risk but not at the cost of agility and responsiveness.

Now as you can imagine this is not something that can be done overnight and requires a well-defined and achievable transformation roadmap. This transformation can take a time to implement successfully depending on many organisational factors such as maturity, size and the appetite for change.

VMware’s operations transformation services teams are partnering with organisations just like yours on a day to day basis to put the building blocks in place to help them in their transformation journey and make their strategic vision a reality.

If you are interested in our approach to this as well as some of the challenges and lessons we’ve learned in one of our major transformation projects, plan to attend the session SDDC7886 – Implementing an Operating Model for Agility: A Customer Success Story next Thursday the 20th October 2016 at 9AM presented by Kevin Lees (Principal Architect for VMware’s global Operations Transformation practice) and myself, Paul Wiggett.

=======

Paul Wiggett is a Technical Operations Architect for Operations Transformation Services EMEA and is based in the U.K.

A Day in the Life of a Cloud Service Owner

Pierre Moncassin-cropCloud Service OwnerBy Pierre Moncassin

Customers often tell me, “I totally get the principles behind the role of Cloud Service Owner – but can you describe what do they actually do throughout their work day?”

Let me start with a caveat: we are all aware that in a knowledge economy few roles have the luxury (or burden, depending on the point of view) of a completely predictable, set routine.  We are in an era where many traditional, factory assembly line jobs have been re-designed to become more agile and less repetitive, at least in some leading-edge companies.  The rationale being that job rotation and innovation if not creativity, leads to higher productivity. Less routine, more output.

What is a Cloud Service Owner?

When I say Cloud Service Owner (CSO), I am referring specifically to the Service Owner role described in the VMware white paper: Organizing for the Cloud.

A CSO is a relatively senior role that includes responsibility for the end-to-end life-cycle of cloud services, with numerous levels of interaction with the business and cloud team members. So I will endeavor to highlight some typical aspects of a ‘day in the life’ of that role – bearing in mind all the caveat above.

Cloud Service Owner

The Cloud Service Owner ensures a consistent, end-to-end Service Lifecycle

Cloud Service Owner Stakeholders and Interactions

The CSO interacts with a number of key stakeholders, first of all within the business lines. When a new service is requested, the CSO reviews the requirements with the Business stakeholders; which may include not only the definition and costing of the service but also a discussion of how quickly it can be placed into production.

In a DevOps environment, that interaction with the business lines will still take place, with the difference that business and application development may be a single team (the business stakeholder may be an application product owner). When the (DevOps) business proposes to launch a new product (i.e. cloud based application or application features), they may need to discuss with the Service Owner how to develop the continuous delivery automation to support that new product.

The CSO will also interact with the members of the cloud operations team, for example with the Cloud Service Architect who will assist in all aspects of the design of the automation workflows and blueprints underlying the services.

Interactions will also include working with other support groups such as the Service Desk – for example, to review incidents relating to the services and work out patterns or root causes; possibly involve the Service Analyst to improve the monitoring and risk management underpinning these services.

Of course the list does not end there. The CSO may also interact with third party providers (especially in a hybrid cloud or multi-cloud model), as well as contractors. If the cloud platform is part of an outsourcing arrangement, the CSO will likely have a counterpart within the outsourcer.

Key Processes for a Cloud Service Owner

From a process perspective, our CSO will be involved in all aspects of the service life-cycle – this is by definition of the broad remit of the role. But I can highlight some key ‘moments’ in that life-cycle.

  • Initial definition of the service in cooperation with the business stakeholders.
    This is a critical stage whether both the scope of the service is defined, but also the expected costs and service levels.
  • Monitoring the performance of the service.
    In traditional IT, the review of SLA performance with business takes a key role once a service is up and running. In a cloud environment, much of SLA monitoring may be automated, however SLA review is still an important role for the CSO.
  • Continuous Improvement and ultimately, de-commissioning of the service.
    It is expected that the service will evolve and that ultimately it will be de-commissioned (possibly freeing some capability). This is also an activity that needs close cooperation with business lines.

Toolsets for a Cloud Service Owner

I mentioned at the outset that the CSO is not necessarily expected to a toolset expert.  However, in order to fully leverage the capabilities of a cloud platform, the CSO will be able to leverage the key cloud management tools, specifically:

  • vRealize Automation – the CSO will have a solid understanding of how blueprints are designed and where/when existing blueprints can be re-used to create new (or amend existing) services.
  • vRealize Business – understand the costing models and how they can be built into the tool to automate charging/billing.
  • vRealize Operations – leverage the tool to track service performance, and generally managing service ‘health’ and capacity.
  • NSX – the CSO is less likely to interact with this tool on a daily basis, but will benefit from a solid understanding the capability of this tool to help design the automation workflows and to plan the security controls that may be required when deploying the services (e.g. leveraging micro-segmentation).

The list is not exhaustive. Many organizations are considering, or already working towards DevOps adoption, and in those cases the CSO will benefit from a broad grasp of industry tools whether related to continuous delivery (think Jenkins, Codestream, Puppet, Ansible), or specifically to Cloud-Native Applications (think Docker,  VMware’s Photon OS).

Take Aways:

  • For roles such as Cloud Service Owner, design activities should take precedence over fire-fighting. These roles will prefer an engineering approach to problems (fix a problem once).
  • Do not expect a rigid work-day pattern – the Cloud Service Owner is a senior role and will need to liaise with a range of stakeholders, and interact directly and indirectly with several tools and processes.
  • The Cloud Service Owner will maintain a healthy understanding of toolsets; and leverage that knowledge daily to design, manage and occasionally de-commission services. This is an aspect of the role that may be significantly different from more traditional Service Manager roles.
  • However, the Cloud Service Owner is not meant to be a toolset specialist. If they spend their entire day immersed in toolsets, it is a sign that the role is not fully developed!
  • The Cloud Service Owner will work in increasingly close cooperation with the business lines– not from silo to silo but through an increasingly permeable boundary.

=======

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

Mind the Gap: Breaking Down Silos

Part 1:  Getting Started.

Kevin LeessilosBy Kevin Lees

For IT to truly transform into an effective, business-focused service provider it has to do more than implement an enabling technology like software defined data center, though that’s certainly a great start. In fact, according to the recently published State of IT Transformation analysis done by EMC and VMware, 95% of participants believe having an IT organization that has no silos and works together to deliver business-focused services at the lowest cost is critical.  Yet, not astonishingly based on experience, less than 4% reported they currently operate like this. That’s quite a gap!

According to the same analysis, operating without silos was one of the top 10 goals in all but one of the industries represented in the study (17 of 18 industries) and was in the top 11 for all industries. Thankfully, while there is a significant gap between desire and current state, IT operating without silos is top of mind and viewed as critical to success regardless of industry. So how do you navigate this gap? Where do you start? How do you proceed without causing an anxiety attack or worse, intransigence, within IT? In this two part blog, we’ll walk through some critical steps we use for closing this gap.

Step 1:  Secure an Executive Sponsor

First and foremost you have to realize and acknowledge that the biggest challenges you will face in breaking down silos are cultural and in all likelihood political challenges. That has been my experience and that of my colleagues when working with companies to break down their IT silos. And of the two, the political challenge can be the harder to overcome.  Which brings us to the first step in closing the gap: getting executive sponsorship and not just any executive sponsorship, you need proactive executive sponsorship.

You need an enthusiastic, proactive executive sponsor for this kind of change.  Indeed, that’s your number one goal – to have an executive involved who completely embraces this idea and the change it requires, and who’s committed to proactively supporting you.  He or she is critical to success in many ways, not the least of which in overcoming the cultural and political challenges. To overcome these challenges the executive sponsor has to have the enthusiastic support of those in the management chain of the organization in which the silos exist.

But how to you generate the enthusiasm when we know how resistant some people are to change, especially change that might affect their span of control?

Step 2:  Sell the Change

Work with the executive sponsor to craft a communication plan aimed at both the management chain and the organization as a whole. When building the communication plan, you would ideally derive the intent for the change from a strategy and roadmap focused on transforming IT into a service provider to the business that has both executive and business support. If not, developing that IT transformation strategy and roadmap becomes step one!

The communication plan should focus on why you’re making the change, why it is critical for the business, and what value embracing it has for the affected IT managers and employees– what they stand to gain as individuals.  And individuals do stand to gain, for example through recognition, increased visibility, opportunity to participate in something truly innovative, obtaining new skills that are highly valued in both the company and the industry, and new career opportunities. The goal is to make participating in the change aspirational. But enthusiasm only goes so far. You also have to provide them a safe way to modify their behaviour – as well as provide a little extra nudge to those in management who are still a bit reluctant to change.

Step 3:  Modify Behavior

Modifying behaviour is a key step but one that is overlooked more often than not. This involves modifying annual performance review criteria, and bonus critera if applicable, to reflect the desired outcome.  If this is not done individuals will default to their incentivized behaviour when prioritization decisions need to be made – or, for a few, as an excuse for not fully embracing the change.  Modifying this criteria is absolutely critical for the management chain in order to help address the political challenge. It’s also important for members of the silos whose walls are to be torn down, as we’ll see in the final step.

Step 4:  Break the Silos

I say the “final step” but that’s a bit of a misnomer, as the final step can take some time and consists of many activities as it is the actual breaking down of the silos. In part two of this blog I will focus on the approach we have found to be successful when undertaking this type of organizational change.

=====
Kevin Lees is Principal Architect for VMware’s global Operations Transformation Practice and is based in Colorado.

 

Surviving Change: 12 Organisation Transformation Principles to Help You Cope

Craig SavageBy Craig Savage:

Change Organisation TransformationIn my role as an Operations Transformation Architect, I get the privilege of working with many different organisations in many different markets and geographies, and as our team are closely knit, we share a lot of knowledge and experience amongst ourselves and globally after each engagement we undertake. What follows are some of the key principles that we believe can and should be applied across all the large IT organisation transformation projects we see.

  1. Understand that transformation is EXPENSIVE – in terms of time, money and emotional energy.
    1. Time – any cultural change will take time, traditions need to be re-made, new balance created (many times) and new roles will take time to settle.
    2. Money – your people will need to gain new skills and competencies; you will also need to reflect on your compensation model.
    3. Emotional energy – Some people thrive on change, others find it very hard work so being aware of how the process is affecting your people and making sure you keep everyone is engaged is crucial.
  2. Realize that every transformation journey is different – there is no “one size fits all” as every company has a different culture and a different diversity in their people, as well as a uniquely evolved process framework to take into account. That said, there are a lot of common elements, that if treated similarly to architectural building blocks, can be re-used
  3. Culture change must be a primary priority and must be led top down. Realistically assess your current culture before beginning – decide what to keep, what needs to be transformed and what will have to be scrapped. Get outside help!
  4. There is a great deal of value in structuring the programme effectively – it really needs to be about constant, small and iterative changes that drive towards a larger goal. One huge project with fixed milestones generally runs into issues, whereas a programme with a clearly defined end state, with multiple smaller, short projects or a more Agile-esk sprint structure will deliver earlier realised outcomes at lower cost.
  5. You will need to change the way you recognise and reward your people – people management and the skills of acquiring and retaining the right people will become increasingly valuable. Keep the management structure focused on performance, development and reward management, managers should be mentors and coaches. Doing this allows for people to hold different roles in different teams without the artificial tribal boundaries that tend to arise in the older models.
  6. Be transparent about the changes taking place – people will be uncertain anyway, and we have seen countless times how destructive rumours can be, whereas every time we have seen openness and clear communication we have seen a far easier transformation journey. Be mindful that local laws, unions, etc. can often inhibit this, so sometimes you will need to be creative in order to keep your people informed and engaged without exposing your company to additional risk.
  7. You will likely need to increase headcount while you transform, unless your current team are grossly under utilised or your current process model is very inefficient. Get help understanding when and how to flex your teams.
  8. Encourage innovation, value it highly and find ways to make it valuable to yourself and your teams. Encourage people to hold multiple roles, increasing the skills and capability diversity and capacity across your team.
  9. Identify and work with your resistance fighters – they may have a valid concern and they definitely have passion, find a way to make them part of the change.
  10. This may sound terribly obvious – keep your current environment running! Alienating your business by delivering bad (or worse) service now will not help.
  11. Understand you are no longer the sole provider of IT for your organisation, no matter how much may seem to be true, your business will already be taking some IT services from other providers. Work towards becoming the broker of these services and being your organisation’s preferred IT provider.
  12. Technology can only effectively transform an operation when the people that operate it and the processes that they carry out are able to take full advantage of that technology. In our experience, implementing technology and expecting the people and process change to take place organically fails almost every time.

With your people heading in the direction of the new and clearly defined way of working, and your processes being re-written and optimised to deliver on that new vision, your organisation will have started off well.

It’s important to get outside help with this process.  This major change requires someone impartial with the skills and experience to advise you on what is working, what could be done better, what is coming up next and to give you ways they’ve seen other organisations overcome those new challenges.  To leverage our experience, contact your local VMware representative to engage with VMware Advisory and Operations Transformation services.

=======

Craig Savage is a VMware Operations Transformation Architect and is based in the UK. You can follow @craig_savage on Twitter.

3 Common Mistakes when Breaking Organizational Silos for Cloud and DevOps

Pierre Moncassin-cropOrganizational SilosBy Pierre Moncassin

Every customer’s journey to Cloud, DevOps or other transformative initiatives is unique to an extent.  Yet all those journeys will come across a similar set of challenges.  With the exception of truly green-field projects, each transformation to Cloud/DevOps involves dealing with the weight of legacy – organizational and technical silos that hamper their momentum towards change.

This is why I often hear from customer teams: “We know that we need to break down those silos – but exactly how do you break them?”

Whilst I do not advocate a one-size-fit-all answer, I want to share some recommendations I promote on how to go about breaking those silos – and some mistakes to avoid along the way.

From where do silos come?

As discussed in earlier blogs, silos usually come into existence for valid reasons – at the origin. For example, when infrastructure administration relies on manual and highly specialized skills, it appears to make sense to group the skills together into clusters of deep expertise. Unix gurus, for example, might cluster together, as might Microsoft Windows experts, SQL database specialists and so on.  These are examples of silos teams build around infrastructure skills – experts of all those areas need to align their mode of operation to support cloud infrastructure services.

Other examples of commonly found silos include:

  • Application Development to Operations: DevOps emerged precisely as a way to break down one of the ‘last great silos’ of IT – the persistent gap between the Development teams and Operations teams.
  • Business to IT: When IT becomes so reliant on a specialist set of skills (think mainframe programming) significant inefficiencies arise in cross-training IT staff to business or vice-versa. In transitioning to Cloud/DevOps, this is another of the ‘great silo risks’ that the transformation will mitigate and ultimately break down completely as Business, Application Development and Operations function as an integrated team.

Common mistakes when attempting to break down silos.

a) Toolset-only approach.

A frequent temptation for project teams is to install software-based tools and assume (or rather, hope) that the silos will just vanish by themselves. In Cloud transitions, teams might install automated provisioning, but forget to work across the business/IT silos. Result – adoption by the business generally ends up minimal. In DevOps transition attempts, the technology approach might consist of deploying, for example, Jenkins, Code Stream etc. – tools meant for continuous delivery efforts, but failing to bridge the gap fully with day two operations management, for example without governance around incident-handling or idempotent configuration management. Without a clear path to resolution that cuts across the silos, it is easy to see when issues are not resolved satisfactorily. The impact on customer satisfaction is predictably less than optimal.

b) Overlook the value of ‘traditional’ skills

During the transition to Cloud/DevOps, especially when considering a toolset-only approach, it can appear at first sight that many of the legacy skills have become irrelevant.   But this is often a mistaken perception. Legacy skills are likely still relevant, they simply need to be applied differently.

For example, traditional operating systems skills are almost always relevant for Cloud, however they will be applied differently. Instead of manually configuring servers, the administrators will develop blueprints to provision servers automatically. They will use their knowledge to define standardized operating system builds.

Traditional skills become all the more critical when we look into soft skills. The ability to manage stakeholder relationships, communicate across teams, organizational and business specific knowledge – are all essential to running an effective Cloud/DevOps organization.

c) Focus on problem not solution

This is a well-known principle of change management – focusing on the problem will not solve it. Rather than present the teams with a problem, for example existence of a silo, it is often far more effective to work on the solution – cross-silo organization and processes.

Does it work? I can certainly relate the experience of ‘seeing light bulb’ moments with highly specialized teams.  Once they see the value of a cross-silo solution, the response is far more often “we can do this” as opposed to defending the status quo of individual silos.

In sum, focus on the vision, the end-state and the value of the end-to-end solutions.

Five recommendations to help break down silos.

  1. Shift from silo mindset to Systems Thinking. Conceptually, all the ‘common mistakes’ that I mentioned above can be traced back to the persistence of a silo mindset – whether focusing on traditional (versus leading-edge skills), new toolsets (versus legacy ones), or isolated ‘problem’ areas. The better approach is Systems Thinking. Systems thinking implies an understanding that the overall organization is more than the sum of the parts. It means looking for ways not just to improve the efficiency of individual elements (skillsets, tools, process steps) but optimize the way these elements interact.
  2. Create vision. As mentioned earlier, creating the vision is a vital step to get the team’s buy-in and to overcome silos. This can entail an initial catalog of services and outline workflows to fulfill these services. Potentially, it may be worth setting up a pilot platform to showcase some examples.
  3. Build momentum. Building the vision is important but not enough. One the initial acceptance is reached, the transformation team will need to build the momentum. For example by recruiting ‘champions’ in each of the former silos.
  4. Proceed in incremental steps, building up a track record of ‘small wins’ and gradually increasing the pace of change.
  5. Establish the permanent structure. One the change in motion, it will be necessary to define the long-term roles that operate the Cloud/ DevOps operations. These roles are detailed in ‘Organizing for the Cloud’: https://www.vmware.com/files/pdf/services/VMware-Organizing-for-the-Cloud-Whitepaper.pdf.

Take-aways

  • Breaking silos is a result rather than the end. Start by building the vision to engage teams and motivate them to break the silos themselves.
  • Do not rely on technology alone. Toolsets augment processes, but do by themselves overcome silos (e.g. vRealize Code Stream, vRealize Cloud Automation and other VMware Cloud automation tooling) as long at they are leveraged to sustain the vision and constantly build momentum.
  • Leverage existing skills. Many of the legacy, previously silo’ed skills can be adapted to the future cloud/DevOps organization.

=======

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

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.

IT Transformation and Organizational Process Maturity

John WorthingtonBy John Worthington

Regardless of what process framework you use, and especially if you’ve done some ‘adaptation’ of processes, building process capability over the long haul goes hand-in-hand with building the organization’s process maturity.

Having thought about my comment, ‘so go ahead, adopt and adapt’, in one of my previous posts I thought further discussion might be in order.

Measuring Organizational Process Maturity

Based on the ISO standard[i], an organization’s process maturity is measured by establishing base and extended process sets at each stage of maturity. These base and extended process sets are tailored based on the domain and scope of the assessment and/or client-specific requirements.

For example, if a company decided that process A, B and C are critical to achieving organizational objectives they may determine that these represent the base process set. They could not achieve a process maturity of Level 1 (Basic) unless process A, B and C all met a Level 1 process maturity.

At Level 2, the organization may determine that there are additional processes that must be established. These would represent the ‘extended process set’ at a Level 2. To reach an organizational maturity of Level 2 (Managed), both the base and extended process sets would need to achieve Level 2 process maturity. Additional extended process sets might be added at higher levels of maturity as shown in the figure below.

Process Maturity

Process Capability versus Maturity

Capability

Process capability is focused on the ability of the process to achieve its desired outcomes based on business objectives. The process ‘base’ practices are directly related to the process objectives; which means the base practice attributes of a process are different for each process. So rating the degree to which each process expected outcome is met (or not) is a quick way to provide insight to its capability, which may (or may not) be adequate for a given organization’s business objectives. An example for Incident Management is given below. (Note: A formal process assessment will also review the process inputs/outputs, supporting people/technology and other evidence

Process Maturity

Process Capability Attribute  – Incident Management
(i.e., objectives/process desired outcomes)
Rating
An incident and service request management strategy is defined and implemented
Incidents are reported, prioritized, analyzed for business impact, classified, resolved and closed
Customers are kept informed of the status and progress of their incidents or service requests
Management of potential service level breaches are communicated to and agreed with the customer
Incidents which are not progressed according to agreed service levels are escalated by customers

If all the objectives of the process are either Largely or Fully achieved, the process will meet Level 1 (performed) requirements.

Maturity

Process maturity attributes apply to all processes, and are considered ‘generic’ attributes. These ratings are usually taken across a group of processes (such as the base and extended process set). Each level of process maturity builds on the next:

  • Level 1 – Performed (Process Performance)
  • Level 2 – Managed (Process Performance Management, Work Product management)
  • Level 3 – Established (Process Definition, Process Deployment)
  • Level 4 – Predictable (Process Measurement, Process Control)
  • Level 5 – Optimizing (Process Innovation, Process Optimization)

How mature are your processes?

Download this simple exercise using the ISO standard generic process attributes. Identify what you feel would be your ‘base process set’, and if you want a ‘extended process set’ as well. Then answer these questions for each process.

Organizational Process Maturity and ITaaS Transformation

Each organization has different starting points, different goals and objectives, and different levels of capability/maturity. So while we can effectively leverage our extensive experience with ITaaS transformations, each transformation path will be unique.

As processes are adapted along an ITaaS transformation path, changes in process boundaries, roles, controls and supporting technology can dilute organizational process maturity. This is another reason why ‘slow and steady’ may win the IT transformation race; frantic attempts to speed up the hill (again and again) increase the costs associated with the transformation effort an ultimately exhaust IT staff.

So go ahead, ‘adopt and adapt’, but be careful to maintain your hard-earned gains in organizational process maturity.

[i] ISO15504 – http://www.iso.org/iso/catalogue_detail.htm?csnumber=54175

=====================

John Worthington is a VMware transformation consultant and is based in New Jersey. Follow @jMarcusWorthy and@VMwareCloudOps on Twitter.

Staffing Your Cloud Organization – A Heuristic Model

Approximating staffing ratios in a cloud organization as a logarithmic function of infrastructure metrics.

Pierre Moncassin-cropBy Pierre Moncassin

Customers who want to establish true cloud services based on VMware’s SDDC solution (or any other provider for that matter), realize that in order to fully leverage the technology, they need to adapt their IT organization.

More specifically, they need to setup a dedicated team – a cloud Center of Excellence (COE) to manage and operate their cloud services.

The structure and roles of that team are described in detail in ‘Organizing for the Cloud’.

During practically all Operations Transformation projects, a question frequently asked is: what is the optimum staffing level to setup this cloud organization (FTE a.k.a. Full Time Equivalent)?

The standard consultant answer is of course  ‘it depends’. But in this blog, I will explain in more detail what “it depends” means in this context.

In an earlier blog, I described “10 key factors to estimate staffing ratios to operate platforms with vRealize Automation and vRealize Operations Manager”.

  • Number of lines of business
  • Number of data centers
  • Level staff skill/experience
  • Number of cloud services
  • Workflow complexity
  • Internal process complexity (includes support requirements eg 5 days/5 or 24 hour/7)
  • Number of third party integrations
  • Rate of change
  • Number of VM’s
  • Number of user dashboards/reports

Now these 10 factors, and probably hundreds of other factors will determine the complexity of the tasks that the cloud organization needs to perform and therefore, the staffing level. Clearly there are thousands of possible combinations of these factors. But if I want to see how the FTE count evolves with a single , easy-to-quantify parameter (such as number of virtual machines or any other ‘simple’ infrastructure metric’), we need to make strict assumptions to ‘tie down’ the other factors.

So let’s assume that we are looking at a single organization evolving over time; as time passes the number of virtual machines gradually increases, but so does the number and complexity of the services, as well as the demand for support coverage:

  1. Between 1 and 100 VM’s, the COE is running as a pilot, there are no support requirements, only a small number of services to run.
  2. Between 100 and 1000 VM’s., the COE is running cloud services regionally with some basic service levels.
  3. Over say, 30,000 VM’s, the COE is now running a global operation with 24/7 support requirement and a broad range of services.

Practical observation of a number of real-life examples suggests an evolution broadly similar to the logarithmic curve in figure 1. Now this is still a model that deliberately simplifies and ‘smooths out’ the FTE curve, but there are two practical implications:

  • The staffing levels may rise most steeply at the beginning of the curve. When the organization transitions from a pilot to a fully operating COE, the staffing need levels rise significantly.
  • The FTE curve flattens out then the organization matures and can handle high volumes. Once the COE is operating with a high level of automation with experienced staff, adding workload only requires a marginal increase to the FTE’s count.

In reality of course the complexity – i.e. the demand on FTE – never grows quite linearly.

We would see threshold effects. For example when we reach 300 worksloads, a new 24×7 service may be added to the portfolio, which requires a rapid increase in FTE.

Take-aways:

  • The faster rise in FTE will occur in the early stages of build-up of cloud services; this is ‘normal’ given that we see an increase altogether of the number of services and the service levels and therefore significantly increasing the demands on the cloud organization;
  • Once well established and automated, the FTE level should only increase marginally with rising infrastructure volumes – your organization will have learned to cope with increasing quantities.
  • We need to caveat that although the FTE curve may look broadly logarithmic, threshold effects are inevitable: new demands on service level (eg new compliance requirements, 24×7 etc) can create an ‘uptick’ in FTE without necessarily a prior ‘uptick’ in volumes.

What we have presented here in an intuitive model to understand how increasing volumes impact FTE. You are welcome to share your experience and perhaps refine this heuristic model.

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