Home > Blogs > VMware Operations Transformation Services

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 5:  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.

 

It’s All in the Context: Practical Advice for Using IT Benchmarking

Ton van TubergenBy Ton van Tubergen

IT BenchmarkingIn my role as an Operations Transformation Architect, I have been involved in many large and small IT Transformations, addressing people, process, technology, governance and organizational aspects and their dependencies.

As a responsible IT leader, managing uncertainty and risks will be an important part of steering the organization through a transformation. So, they are often asked:

  1. How are we doing compared to others? (Slow/fast)
  2. Are we doing the right things? (Did we bet on the right horse?)
  3. Which step first? (We know we have a lot to do, but where do we start?)
  4. What are lessons learnt from others? (Give us best practices so we do not make the same mistakes.)

One source to get answers and grow confidence is benchmark reports, allowing you to do a quick comparison with your own organisation. Reading benchmark reports is not always an easy job, and often disappointing.

Getting the most out of benchmarking

There are many advantages to benchmarking:

  1. It can trigger and energize the improvement (transformation) of the organization and its services
  2. It provides new insights
  3. It provides early warnings about where an organisation is performing and where it is lacking behind
  4. It can motivate all stakeholders before and after a transformation (when good new scores are available)

But before you start reading benchmark reports, ask yourself the following questions:

  1. What does our organisation want to achieve? Do we have the same (business) objectives and priorities as our peers in the benchmark?  Do we want to be the same as our peers/competitors?
  2. Are we level hunting, or are we focusing on our own business success?
  3. Are the measurements comparable and are the scores relevant for what we want to achieve? What is the quality of the data?
  4. Is there an explanation for different scores?
  5. Are best practices described in such a way that we can re-use them?

The State of IT Transformation Report

Having this framework in mind, let us now have a look into “The State of IT Transformation” recently published by VMware and EMC, a benchmark and analysis about the State of IT Transformation, and talk about how your organization can effectively use this data to further your owns goals.

Sample 1: Cloud Infrastructure – Hybrid Cloud Architecture

Hybrid Cloud ArchitectureThe report states that “most companies are not where they want to be in having a well-engineered hybrid cloud architecture,” and the infographic shows us 2 groups: Overall (N=660, so pretty relevant for you!) and Top 20% performers.

So, you are probably not alone, but how can you accelerate, and relatedly, what slowed you down? There could be a variety of answers (lack of capacity, expertise, sponsorship, acceptance, complexity too high), but even more interesting, what re-usable accelerators did the top performers use?

Sample 2 – Virtualization (%)

VirtualizationThis info graphic shows level of Virtualization in different categories. Progress is compared to 2 years ago (see info graphic in full report).

What you can learn here is that many peers follow a shared pattern: first compute (most virtualized), then storage and application, network and desktop (less virtualized). That’s interesting information, but to identify if they apply to you ask yourself:

  • What is our business-case for virtualization?
  • Based on that business-case, is it wise to virtualize everything (including legacy) to 100%?

Sample 3 – Operating Model

StrategyHere we find big gaps between what peers want and what they currently have.

In our experience, many organizations are struggling with this.  It can sometimes be difficult to answer the questions, “What should my end-state look like and how do I get there?”

What is important to remember is that you should not think about transformation as going from one static state to another, but develop your organization in an agile never ending change, responding to changes in business needs and technology opportunities during the journey.

Practical advice for leveraging benchmarks

The first step is to trace and understand the best practices in the benchmark, and why they worked well in these organizations. But that does not mean that all best practices are transportable. That’s like a heart-surgeon saying, “Every excellent beating heart can be transplanted to any patient”.

Even if best practices are available and credible (no coincidence), they still need an expert judgment to decide what and how to re-use them effectively.

What’s in it for you? A lot, keeping in mind the advantages I discussed before, but you need to invest in understanding the background of the research and how it could apply to you.  It can be extremely valuable to talk to those who participated or the experts in a similar workshop.

It’s important to get outside help with this process.  Someone impartial with expertise in this area can advise you on what is working, what could be done better, what is coming up next and how they’ve seen other organisations overcome similar challenges to yours.  To leverage our experience, contact your local VMware representative to engage with VMware Advisory and Operations Transformation services (OTS).

=======

Ton van Tubergen is a VMware Operations Transformation Architect and is based in the Netherlands. 

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.

IT Service Strategy: Catalogs and Portals

Insight from the EMC and VMware 2016 State of IT Transformation Report

self-service portalGuest Blogger:
Denise Partlow, Director, Product Marketing Cloud Professional Services, EMC Corporation

IT organizations are experiencing a cultural revolution. CIOs want to run IT like a customer-focused business. They want to empower users with self-service and enable them to make value-based consumption decisions. This means packaging IT services for easy consumption by the business, providing financial transparency through unit-based pricing and billing, and developing processes, roles, and skills to successfully manage the supply and demand side of the portfolio.

As I mentioned in my last blog, EMC and VMware have been doing workshops on IT transformation with our customers for several years now. We recently analyzed the data collected during these workshops. The top gap, identified by all organizations, is their ability to provide and efficiently manage user requests through a service catalog and self-service portal. 80% plan to have a self-service portal and service catalog in place by the 2016-2017 timeframe.

Read more >

EMC, VMware Release ‘State of IT Transformation’ Report

The ‘State of IT Transformation’ report takes a look at more than 660 EMC and VMware enterprise customers across 18 industries, and identifies gaps, progress and goals in their current IT Transformation initiatives.

By focusing on data provided by CIOs and their direct reports who participated in a transformation workshop led by EMC or VMware, this analysis provides deep insight into the biggest goals and challenges for organizations who are actually in the midst of an IT transformation.

The full State of IT Transformation Report (PDF) can be downloaded here.

Where do Organizations Want to Improve Most in 2016?

State of IT TransformationCloud Infrastructure

While more than 90% of organizations are only in the early stages of evaluating a well-engineered hybrid cloud architecture, and 91% of organizations have no organized, consistent means of evaluating workloads for hybrid cloud, 70% want to standardize on a hybrid cloud architecture across the organization within the next two years.

Operating Model

Running IT like a customer-focused business is a high priority for IT organizations, but 88% of companies have not begun, or are only in the preliminary stages of developing skills in business-facing service definition, and only 24% have a well developed service catalog in place.

Organizations recognize that collaboration is key to meeting customer expectations, with 95% of organizations expressing that having no silos and working together to deliver business-focused services at the lowest cost this is critical.  However, less than 4% of organizations reported that they currently operate like this.

Agility is also critical to success.  For over half of the participants it currently takes between a week and a month to provision infrastructure resources.  The goal this year for 77% of participants is to be able to do this in less than a day, or dynamically when needed.

Applications

Accelerating application development is a high priority for CIOs this year.  68% of the organizations surveyd take 6-12 months to complete a new development cycle.  This is likely due to the fact that 82% of the companies currently don’t have a scalable, infrastructure-independent application delivery framework on which to rapidly and consistently build mobile-friendly, cloud-native apps.

How does your organization stack up?

Are you curious about how the results changed by industry, or by geography?  Read the full State of IT Transformation Report to see how your organization compares to your peers.

If you need assistance identifying the gaps in your own organization, and developing a comprehensive strategy and roadmap for moving forward, contact your VMware Advisory Services strategist or your local VMware representative today.

Cloud Services Definition

Part 3 of the Cloud Business Management Series

By Khalid Hakim, Kai Holthaus and Bill Irvine

Services DefinitionIn our last cloud operations business transformation blog, we talked about the cloud business strategy and its importance in formulating the vision and the plan as to how you want to run your cloud as a business. In today’s blog, the focus begins to shift to executing the strategy and laying out the foundations of a service-oriented and business-driven “operating model”.

There is a saying: you can’t manage what you can’t control, and you can’t control what you can’t define.  Imagine that you are planning to open a new business. The first step is to define what services/products you want to offer your consumers and what distinguishes your market value among the others. Similarly, cloud business management starts at this point. IT should identify and define what cloud services would be offered to its consumers in order to truly drive a services-oriented and value-driven organization.

Key Areas of Services Definition

VMware recommends a unique approach for defining cloud services, through which a service owner defines a 360-degree view of how the cloud services would be established, managed and delivered effectively and efficiently to meet or exceed the expected value. To paint this panoramic view, cloud service owners should consider the following areas:

  • Service Overview – describe the service in terms of its purpose, goals, consumers, criticality, availability criteria and rhythm of business.
  • Virtual Service Team – organize your team members around the services you deliver. Team up as a virtual service team.
  • Services Definition ChartService Chart – map out the end-to-end cloud service in a graphical representation that is easy to consume. The service chart helps to visually understand the core components of a service and contributes when costing services.
  • Service Portfolio and Consumer Management – the service portfolio answers the questions, who are our customers and why should they buy the service from us. It contains all of the service categories and the business units that consume them and aids with making informed “service” and “business” based investment decisions.
  • Service Design and Development – provide high level information about how the services will be designed and developed, especially if the service isn’t yet in production. This helps with understanding the customer business need and developing the most valuable solution possible.
  • Service Catalog Management – identify service catalog structure parameters and possible blueprints. Also, define what columns or key fields should be included in service catalog entries.
  • Service Level Management – define key SLA/OLA targets to ensure provisioning time and quality meets specific business needs.
  • Service Desk Management – describe how the service will be supported. Draft a plan for service-desk requirements, skills needed and required knowledge transfer.
  • Proactive Operations Management – define the service operation requirements for support and reliability from the event and performance monitoring to availability, demand, capacity, continuity and security management.
  • Provisioning and Change Management – define the service provisioning lifecycle and associated change management policies including how the service will be pre-approved and auto-provisioned (for maximum efficiency). New leaner change management workflow needs to defined / refined (i.e. standard changes).
  • Service Financial Management – define the service cost and charge back/ show back model along with pricing and connections to the service catalog.
  • Service Performance and KPIs – define any applicable service related strategic, tactical and operational performance indicators (KPIs), and the metrics that will be collected to demonstrate that required performance was achieved. Also define how and when the KPIs and metrics will be reported, and to whom.
  • Service Reviews – define service-based review meetings to discuss and remediate any operational or consumer related topics. Follow a standard cadence for all services. Discuss potential changes in demand for services. Capture new or enhanced service requirements.
  • Service Marketing – define the key applicable service marketing elements for a successful service promotion and value realization within different company cultures.

Now, how long do you think this exercise will take? In most of our engagements, defining a service takes between 1 to 2 weeks. It is never intended to fully document all the areas above immediately, or establish all of the processes, as many organizations don’t have this all of this information available. Think of the Service Definition as a living and breathing document. The service owner should establish a working draft, develop it to the point of release and then maintain in for its life as an active service offering. All undefined services are treated as areas for improvement.

In our next blog, we will take this to the next level as we learn to establish a cloud service-based cost model and cost out cloud services end-to-end.  This will enable you to understand the cost of a unit of a cloud and provide the required level of cost transparency internally and to consumers.

=======

Khalid Hakim is an IT Business/Financial Management Lead with the VMware Operations Transformation global practice. You can follow him on Twitter @KhalidHakim47.

Kai Holthaus is a Sr. Transformation Consultant with VMware Operations Transformation Services and is based in Oregon.

Bill Irvine is a Principal Strategist with VMware Accelerate Advisory Services and is based in Colorado.

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.

Building a Holistic IT Strategy Using a Top-Down, Bottom-Up and Middle-Out Approach

Part 2 of the “Cloud Capable – Now What?” Series

Dion ShingBy Dion Shing

The modern business environment is fast, fluid, complex and ambiguous. Businesses in all markets are embattled and face challenges and threats both internally and externally.

In order to adapt, survive and thrive, business strategies should be fluid, adaptable and innovative. From an implementation perspective, strategy should be well communicated to all levels of the organization.

Challenges in IT Strategy Definition

IT StrategyFor many organizations, IT strategy definition occurs infrequently and is based on protecting current position and revenue streams, not taking into account feedback from middle and front line tiers of the business.  Furthermore that strategy is not clearly communicated to the business, or even within the IT organization.

This broken process for strategy definition results in tactics and plans that are often watered down, inadequate and not geared towards leveraging the unique strengths of the company.  For example, a company may say that their strategy is to “improve operating efficiency and provide excellent customer service.”  This strategy only brings their IT department up to par with everyone else, it does not provide any competitive advantage.

To find unique and creative competitive advantages many enterprises adapt an inclusive approach to strategy and develop frameworks such as Top-Down, Bottom-Up and Middle-Out.  This approach recognizes that IT is not only a support function that underpins business processes, but a source of competitive advantage that can provide innovative services that will help drive the strategy and success of the company as a whole.

Top-Down, Bottom-Up and Middle-Out

On their own Top-Down, Bottom-Up and Middle-Out strategies are only partially effective. What is required for effective strategy selection and for the development of rationalized strategies is coordination between all three approaches.

Top-Down

The strategy is established by senior management, and filters down the ranks. Often implementation is not well supported and results are lacking.

Bottom-Up

Strategies developed here focused on specific improvement initiatives and address specific needs, they are typically managed by a single group and manager and are effective.

The downside is that the improvement may occur only in a single area, may not be institutionalized and can lead to complexity and inconsistency. Shadow IT and unsanctioned IT Services can occur.

Middle-Out

Middle management is where the strategies that enable competitive advantages can be championed and communicated.  The effective Bottom-Up strategies developed at the frontline can be supported, nurtured, advocated for and developed by finding sponsors at the executive level, elevating bottom-up strategies to top-down strategies.  Middle management is also effective at translating Top-Down strategies from High-level language into Operational activities to be executed at the frontline

Combined, these represent a force for developing action out of strategy that ultimately drives innovation and finding the illusive competitive advantages.

=======

Dion Shing is an Operations Architect based in Dubai.

DevOps: The Operations Side

Ahmed_croppedBy Ahmed Al-Buheissi

DevOps is about getting Development and Operations to work together and avoid conflicts in how they operate is to achieve their goals. The most commonly noted objective is shifting to Agile processes where applications are released more often and with better quality. While development and operations are of equal importance to a DevOps methodology, this article focuses on the role of Operations in facilitating an efficient and successful DevOps implementation.

In a DevOps environment, the operations team participates in the following activities:

Automation Tools

DevOps AutomationAutomation is a cornerstone to DevOps, as it facilitates continuous integration and delivery of applications into various environments (dev, test, prod, etc.). An example of such automation tools is VMware’s vRealize CodeStream, which allows the creation of release pipelines (e.g., from dev, to test, to production), with various tasks to retrieve application builds, deploy environments, automation testing, and etc. These tools are typically implemented and maintained by the operations teams.

Blueprints

Infrastructure and application blueprints may consist of a number items, such as VM templates, configuration management code, or workflows. Configuration code, e.g., Puppet manifest or Chef cookbooks, are used to configure deployed VM’s and the applications running thereon. Configuration Workflows may also be developed using tools such as vRealize Orchestrator. Dev and operations teams share responsibility for developing the blueprints to ensure deployed environments are correct and ready for use in the various release stages.

Patching and Upgrading

Historically, operations teams held responsibility for maintaining the various tools used by the development and release teams, such as build tools, source-code management tools, automated testing systems, and etc. However, the lines are blurring here as developers take on more coding responsibility for such management. This means Operations teams are housing development teams capable of developing the management automation.

Monitoring

This is one of the areas that are frequently overlooked, or at least rarely mentioned, in a DevOps environment. Monitoring applications through the various promotion environments is very important to ensure a fail-fast approach: potential issues are reported and investigated in early stages (dev and test), before they become real problems.

The operation team also builds dashboards for developers and operations so the application and its environment can be monitored throughout the Continuous-Integration/Continuous-Delivery process. This provides developers with feedback on the applications impact on the environment in which it runs, allows operations to become familiar with the same from an environment (VM/vApp) perspective, and provides confidence to the operations team that the Continuous-Integration/Continuous-Delivery process is working and there will be no issues when the application is released into production

It is worth mentioning that collaboration between development and operations should start very early, as developers need to embed operations considerations in their application code (such as adequate logging information), while the operations team need to ensure infrastructure availability for developers to start their work.

=======

Ahmed Al-Buheissi is an operations technical architect with the VMware Operations Transformation global practice and is based in Melbourne, Australia.

Cloud Business Strategy

Part Two of the Cloud Business Management Series

Cloud Business Strategy

By Khalid Hakim, Charlie McVeigh and Reg Lo

At VMware we have the good fortune of working with many different customers on driving and implementing a Cloud Business Strategy.  As we have discussed in some of our prior Cloud Business Management blogs, there is a full spectrum of issues to be considered when considering Cloud Business Management.  This spectrum of issues include:

  • Cloud Strategy
  • Cloud Costing
  • Cloud Marketing
  • Service Level Management & Contracts Management
  • Budgeting & Forecasting
  • Services Definition
  • Cloud Pricing
  • Consumption & Charge-back
  • Cost Optimization

Today we are going to look specifically at the role of Cloud Business Strategy and our time tested workshop approach that we use with our customers to derive a road map to success.

CBM_workshop

Our Cloud Business Management (CBM) Workshops always start by asking our customers what their definition of “success” is when looking forward 18-24 months into the future.  While every customer is unique, the common success criteria that we hear from our customers include the following items:

  • Full transparency for IT consumers as to what they consume and what are the costs for what they are consuming, i.e. who consumes what and at what cost
  • Reclamation and recovery of unused or underutilized infrastructure.
  • Establishment of services definitions for “patterns” (repeatable services in the service catalog) and “snowflakes”  (services that are unique and require engineering to stand the service up.)
  • Reduced time of deployment of services especially “patterns”
  • Understanding from an economic and technical perspective of where is the best place to run cloud workloads. Is it private cloud, public cloud or a hybrid cloud environment? Maybe it is more cost efficient to run temporary workloads in the public cloud than the private one.
  • Incentivizing users to “do the right thing” due to understanding of economics and transparency of costs.
  • Incentivizing users to “do the right thing” due to vastly improved day 0, day 1 and day 2 operations automation.

Once we have an understanding of what “success” will look like in the future, we then drive into a deeper discussion of the following items:

  1. We start by asking for current pain points across the CBM spectrum listed after the first paragraph above. For example: Do you have service definitions? Do you know your costs for services?  Do you engage in pricing strategies?  Are you marketing cloud services to incent user behavior?  Do your users know what they are consuming?  What are you doing for cost optimization?, etc.
  2. We then engage our customers in a discussion of what they would like to see in the future across the CBM spectrum and what tangible improvements that they can anticipate as they mature across each of these disciplines.
  3. Discussions then dive into the current level of maturity across the CBM Spectrum. The key here being that more mature organizations provides higher levels of value to the IT organization and the business consumers of IT resources.
  4. Lastly, a deep dive into data sources that can be used for setting up automated cost modeling are investigated. We are looking to understand what are some of the foundational data sources for Cloud Management (such as vRA, vROPs), Foundation sources for costs (G/L, A/P, Organization, Budgets), Operational Data (Labor rates, Headcount, Compute capacity and metering, Storage capacity and metering, Network capacity and metering, Reporting requirements, Financial practices, etc.)

The workshop and the discussions that occur require a significant discovery effort and detailed listening to our customers.   From this effort we are able to derive a detailed deliverable that results in a tangible Cloud Business Strategy deliverable.   The strategy includes a road map with definitive success points at 6 months, 12 months and 18 – 24 months.

Cloud Business StrategyEmbedded within the Cloud Business Strategy document, is an illustration of what will happen to the organizations maturity across the CBM spectrum if the road map is followed.  Maturity gains will be followed and realized by direct and quantifiable improvements in value provided by the Cloud management team to the business that they are supporting.

For more information and to schedule a Cloud Business Management Workshop for your organization, please contact your local VMware representative.

=======

Khalid Hakim is an operations architect with the VMware Operations Transformation global practice. You can follow him on Twitter @KhalidHakim47.

Charlie McVeigh is an IT business management strategic advisor for VMware. You can follow him on Twitter @cbmcveigh.

Reg Lo is the Director of VMware Accelerate Advisory Services and is based in San Diego, CA.  You can connect with him on LinkedIn.