Home > Blogs > VMware Accelerate Advisory Services

Organizational Change: Perfecting the Process

By Richard Hawkins and Greg Link

Organizational change. Re-org. Shaking things up.

These words strike fear into the hearts of those that hear them. They should also strike fear in those that speak them. But sometimes organizational change is needed for some very good reasons. One that comes to mind is structuring IT to deliver end-to-end services and not just applications.

To reduce the pain often associated with Organizational Change, it’s important to have a clear plan in place that addresses each stage of process.  In this blog we’ll take a look at the stages Organizational Change from beginning to end as a primer on what things need to be considered and when.

Everything has a process and Organizational Change is no exception. The diagram below is a high-level overview of each of the 5 stages of Organizational Change.

Organizational Change Process

Step 1:  Gather and Validate Data

In this phase we look at every level of the organization from the top down along with the skills of each role including that of leadership. Fact is, in many organizations poor performance is more a reflection on leadership than the departmental staff.

Step 2: Perform Organizational Assessment

To assess your organization’s readiness for change, there are a number of questions you need to ask yourself. When did the last re-org take place? What changes were made? How was it received? Is a short survey in order? How formal is your organization? Are there roadblocks that can be removed to allow staff to do their job more effectively? How strict are your policies? Obtaining a cultural baseline is not easy, but well worth the effort.

Step 3: Develop Transition Plan

As you start the planning effort, it’s important to justify the change.  Having a good case for why the organization is undertaking this effort will go a long way toward acceptance.  It’s also important to identify ahead of time what cultural barriers you could face blocking a successful change.

Throughout this stage, you should remember that this effort will affect everyone, so consistent communication is key, and involving many layers of the organization, from directors and managers down to “rank and file” in the planning process will go a long way toward ensuring everyone is on the same page.

Step 4: Implement the Plan

This is another busy stage and, of course, the most important. Proper execution of a well developed plan is the key to success in any endeavor.

Leadership roles should lead by example and be fully committed to the change, and that commitment to the goal must continue throughout every level of the organization.  The success of this effort relies on all parties playing their part.

Seek out areas that may encounter resistance and work tirelessly to resolve them with empathy and understanding. Ownership of a problem in this area may not be an individual mater. It may require senior leadership intervention.

This is another phase where communication, through every means possible, is extremely important. The organization should know how things are going and how issues are being resolved in a timely manner.

Step 5: Validate Plan Success

We’ve done a good job at planning and execution so we’re done right? The new structure is in place and no one has quit or expressed any serious dissatisfaction. But are we really done? A truly good manager says “no” and will look back and make sure the plan and implementation achieved the desired outcome.

Make an initial assessment on how well the organization is working after the changes have settled in. A well timed Town Hall will go a long way in gathering the information needed to validate the efficacy and results of the re-org. If as mass gathering is not an option, departmental meeting should be in order.

In our next blog, we’ll explore 10 of the key actions you need to take along each step of this process to ensure success.

__________________________

Richard Hawkins is a Transformation Strategist based in Seattle, WA.

Greg Link is a Transformation Senior Consultant based in Las Vegas, NV.

Establish Your IT Business Management Office (ITBMO) To Run IT Like a Business

Khalid HakimBy Khalid Hakim

We hear a lot about (and maybe have interacted with) Project Management Offices (PMOs), and possibly about Service Management Offices (SMOs), but IT Business Management Office (ITBMO) sounds like a new buzz word in today’s modern IT business taxonomy. PMOs typically focus on the management and governance of IT projects, while SMOs are responsible for the governance and management of IT services and the processes to ensure effective service delivery. ITBMOs, however, go beyond this to the next IT business maturity level to address business and finance partnership with IT to help IT organizations transform into services-based, business-oriented, and value-focused organizations.

ITBMOHave you ever asked yourself of how you can make your CFO happy? How you can support your corporate financial goals and aspects of a balanced scorecard? How you respond to “IT is always expensive” perception? Have you thought of challenges related to quantifying value your consumers get of IT services? Are you challenged to view IT costs by services you deliver? Or even budgeting and forecasting by IT services? Can you tell on the spot what your unit cost of a service is? What about demand driven IT? Do you feel that you are always over capacity with low utilization of services? What about leveraging marketing power to promote your IT services? How you can commoditize and brand your IT services? And many other questions and thoughts that keep CIOs awake at night.

(I can hear you thinking)

We have been hearing about “transformation” and “running IT like a business” quite frequently nowadays. As a matter of fact, these are becoming overused terms without real meaning of what they actually imply. Imagine that you are the CEO of a new wood furniture manufacturing business. Obviously, the main functions that you could initially think about are Product Management (who turns logs into useful products), Sales and Marketing (who promotes and sells to consumers), and Finance (who manages the financial aspect of the organization). The question is: why can’t we apply the same discipline to IT organizations? Similar to Product Management, IT organizations deliver services, and therefore we have Service Management and Service Owners/Managers. We are only missing two things here to run IT like a Business: a strong service-based financial operating model and the Services Sales/Marketing sense to help promote and consume IT services in the best valuable manner to consumers.

This is what the ITBMO brings to the table: a stronger partnership between IT, Business, and Finance to accelerate transforming your organization into a business-oriented, service-based, and value-focused one. Initially, you can think of the ITBMO as a virtual group or committee that has champions from various IT/Business functions. This virtual team paints the IT business vision and defines its mission on how to run IT like a business to deliver more value to business in the most economical way.

IT Business Management Office (ITBMO)

Figure : IT Business Management Office (ITBMO)

As shown in figure 1, the ITBMO supports 6 functions/towers to ensure stronger partnership throughout the IT service and project management lifecycle. These are:

  • Service Management Office (SMO): the entity (or any similar) within an organization responsible for the delivery and management of IT services. This includes the pure ITSM process management and ownership and delivery along with the ongoing management of IT services.
  • Project Management Office (PMO): the entity responsible for project management and governance
  • IT Finance: the function that takes care of the financial aspect of IT, which could be part of IT or Finance. This typically includes IT budgeting, accounting, pricing and cost optimization.
  • Services Sales & Marketing: a new (or maybe existing) function that will be improved and strengthened as part of the ITBMO establishment.
  • Business/IT Alignment: any existing functionality (such as Customer Relationship Managers or Account Managers) that ensures ongoing alignment between IT and Business.
  • Governance, Risk, and Compliance (GRC): the function (or multiple functions) responsible for organizational change, developing IT policy and governance strategy, IT risk evaluation and mitigation and compliance.

A champion from each function (could be multiple champions based on the organization scale and size) contributes to the core operations of the ITBMO to achieve the value-focused vision. The ITBMO runs in consultative and supporting mode, but depending on the IT organization’s authority, decision making process and power, and delegation factors, the ITBMO could be an authoritative entity within the organization.

Standing Up an ITBMO

Figure 2: Standing Up an ITBMO

Figure 2 shows the six steps required to standup a successful ITBMO within your organization:

  1. Develop Vision/Mission: thinking of why you need an ITBMO in the first place is your first step. What is the challenge you are trying to overcome or opportunity you want to introduce? Thinking collectively in a short/long term vision and drafting a mission statement of what this ITBMO actually does are your foundational steps towards a value-focused organization.
  2. Build and Position the Organizational Structure: figure out what roles are needed and who needs to be onboard and whether this is a virtual team of representatives or dedicated and how it fits the organizational structure and reporting lines
  3. Develop Process Interactions: fully understand your existing processes interactions within the functions that will be supported by the ITBMO, and figure out where you want the ITBMO to help, support, and interject to accelerate value realization
  4. Develop RACI Chart: translate your discovered process interactions and help areas expected into a roles and responsibilities chart (i.e. RACI). This will expose the areas of improvement and will help build a short and long term improvement roadmap across all supported functions to achieve the desired vision.
  5. Establish Value Measures and KPIs: quantifying IT value is one of the challenging tasks IT management confronts. This step defines a very high level value measurement framework or methodology along with the success factors and measures that a CIO or CFO can judge the success of ITBMO thru. VMware vRealize Business is the technology that will be used as a platform to define those value measures and KPIs and help making informed decisions.
  6. Build ITBMO Ongoing Operations: build your ITBMO ongoing operations guide by identifying which RACI responsibilities will be performed

So, you might now be thinking about the value an ITBMO can bring into your organization and how you could best leverage such a powerful business unity:

  • Establish business horizon within your IT and implement a model to help run IT like a business
  • Ensure tighter partnership between IT, business, and finance. This partnership is key to IT success like any other business.
  • Enable your organization explore more improvement opportunities and build a maturity improvement roadmap to run IT like a business
  • Help accelerate your transformation journey not just to a trusted service provider, but to a strategic business partner
  • Create new virtual business roles within your organization and help accelerate this transformation journey
  • Help your IT organization make better and strategic use of VMware vRealize Business to drive the cost optimization and value realization strategy and goals
  • Empower your IT to deliver on the desired quality, at the right cost by creating tighter alignment and accountability between IT, Business, and Finance
  • Elevate and strategize your IT conversations with service consumers, stakeholders, and executives to support IT and business transformation journeys

And if you’re heading to VMworld, don’t miss this session (OPT 5075) on Tuesday 9/1 at 5:30pm!

6 Steps to Establish Your IT Business Management Office (ITBMO) with VMware vRealize Business

VMworld 2015While many smart IT organizations have started their transformation journey to service-oriented and consumer-centric providers, there are still some key gaps that need to be addressed to ensure the effectiveness and efficiency of this transformation and therefore to yield the expected value. These gaps are related to the IT financial operating model and how modernized it is to cope with technology & cloud evolution along with the business speed. The IT Business Management Office (ITBMO) is revolutionizing the way IT leaders demonstrate business value to the enterprise. The ITBMO could be a virtual committee to ensure stronger partnership between IT, Business and Finance together to drive an organization towards faster value realization and maturation. Khalid Hakim, global IT operations, financial and business management architect, and Jason Nienaber, IT Business Management Director at VMware will shed light on this new business practice using VMware vRealize Business to move your IT organization to the next level in maturity and position it as a strategic partner to your business consumers and line of businesses.

———————-

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

From CIO to CEO: 5 Steps to Organize an IT as a Service Provider

Jason StevensonBy Jason Stevenson

In my last CIO to CEO blog, we discussed How to Run an IT as a Service (ITaaS) Provider by providing services to meet customer needs using a commodity as an example. In this blog, we will discuss how to organize governance and personnel within an ITaaS Provider.

IT as a Service ProviderTo provide business/mission-value and remain relevant, many IT organizations are positioning themselves as a Hybrid Cloud Broker; providing both public and private cloud services to their customers and users. To be successful, these organizations must adopt ITaaS; a model in which IT is a commodity, providing services on demand to meet business needs through a scalable and measurable pool of resources using integrated and automated processes. This is accomplished through a blend of:

  • Cloud computing standards
  • Service management best practices
  • Leading cloud and virtualization technologies

The following provides five steps to reorganizing IT to become and ITaaS Provider.

Step #1: Service Owners and Managers

Misconception #1:
Service owners and managers are lower-level resources that: a) do not have financial responsibility, b) are not fully accountable for their service, and c) report into functional/project directors.

Organize an IT as a Service ProviderAs part of service portfolio and catalog management, IT assigns owners for each service.

  • Service Owners (SO) are accountable for service strategy including fiscal responsibility and understanding customer demand for their services. Service Owners solid-line report to the CIO.
  • Service Managers (SM) may also need to be identified for each organizational sub-unit such as lines of business, cost centers, geographies, etc. If used, service managers are accountable for service operation and potentially service transition. Service Managers dotted-line report to service owners.
    • In larger organizations, service owners and managers may use a one or more Business Relationship Managers (BRM) as a conduit to customers paying for the service. BRMs solid-line report to the CIO but are embedded with their customers. The CIO may also have an IT Financial Manager (ITFM) to coordinate ITaaS provider budget allocations to service owners and consolidated service chargeback to customers.

Step #2: Service Life Cycle

Misconception #2:
Service strategy, service design, service transition, service operation, and continual service improvement are just names of service management books.

Organize an IT as a Service ProviderThough many organizations claim to be service oriented, their organizational structures remain functionally and/or project oriented. The following diagram illustrates an organizational pyramid providing service orientation through a service-life-cycle-based organization.

  • Directors are assigned for each service life cycle step including service design, service transition, service operation, and continual service improvement. The CIO also acts as the service strategy director and also performs demand management. Directors solid-line report to the CIO but dotted-line report to the service owners/managers. These directors’ budgets are an aggregate allocated by the service owner.

Step #3: Process Owners and Managers

Misconception #3
Process managers can be an afterthought and “peppered” throughout the organization.

Organize an IT as a Service ProviderTo be successful, an ITaaS Provider must have mature processes under the control of process managers and owners.

  • Process Managers maintain unit procedure documentation. Monitor process reporting. Reviews process records for compliance. Provide ongoing process and system training to unit. Contribute to continual process improvement. Ensure compliance with policies, processes, and procedures. Facilitate regular process meetings and communication channels. Coordinate interface with other service management processes. Take corrective action if needed.

For organizations with intensely “siloed” or “stovepiped” cultures, process owners many need to be introduced. This is not preferred but a common reality.

  • Process Owners champion policies, process, roles and responsibilities. Provides ongoing process and system orientation. Facilitates quarterly reviews. Facilitates annual audits. Enables continuous improvement.

The Service Portfolio Manager (SPM) also fulfills the role leading a service/project management office. The office may including control, technical writing, quality assurance, etc.

Step #4. Technical-Facing Service and Configuration Item Owners and Managers

Misconception #4:
Technical resources for service design and operation do not need to work together in abstracted technical-facing services.

Organize an IT as a Service ProviderThe business-facing services discussed above are supported by functions each with its own owner.

  • Infrastructure Function Owner (IFO)
  • Application Function Owner (AFO)
  • Data Function Owners (DFO)
  • Service Desk Function Owners often fulfilled by the Incident Manager (IM)
  • Operation Center Function Owners often fulfilled by the Event Manager (EM)

These functions may be further decomposed into technical-facing services. Common technical-facing services for ITaaS include network, compute, and storage and each must have an owner.

  • Network Service Owner (NSO)
  • Compute Service Owner (CSO)
  • Storage Service Owner (SSO)

To be a successful ITaaS Provider, technical services are not “siloed” or “stovepiped” and therefore do not require managers in addition to owners as they are shared services. However, the components supporting technical-facing services often have:

  • Configuration Item Owners fiscally responsible for the component
  • Configuration Item Managers operationally responsible for the component.

Life Cycle Gravitation

Configuration Item Managers are often referred to as DevOps in an ITaaS environment; especially for configuration items supporting the application function. Depending on an organization’s culture, DevOps may dotted-line or solid-line report to the Service Design Director or the Service Operation Director. As the organization matures, resources naturally gravitate from operations to earlier phases within the life cycle.

Step #5. Users and Assignment Groups

Misconception #5:
ITaaS is just jargon. IT departments are about IT personnel delivery IT.

Organize an IT as a Service ProviderIn a mature organization, classification of events, incidents, requests, etc. are aligned to the business-facing and technical-facing services within the catalog rather than legacy Category/Type/Item classifications. In this respect, the Technical-Facing Service Owners and Configuration Item Managers discussed above may also be referred to as Assignment Group Managers. The remaining technical employees within the ITaaS provider report to these Assignment Group Managers.

Every individual employee of an ITaaS Provider must move from technology to process, to service, to customer, to mission, and then ultimately to a value focus. Because these individual employees are the first, second, and third line of support for the users receiving the service it is critical for these IT employees’ tools and training to encourage user value focus.

Though impractical from a presentation standpoint, the entire ITaaS Provider must conceptualize their role as an inverted organization chart with the users at the top of the organization, then IT employees supporting the users, and then IT management supporting IT employees.

Organize an IT as a Service Provider

Move from CIO to CEO by leveraging a Strategist from VMware to address the people, process, and technology elements necessary to transform your organization to an ITaaS Provider.

_________________________________________

Jason Stevenson is a Transformation Consultant based in Michigan.

ROI Best Practices Series — Part 1: Introduction and Goal of an ROI Analysis

Lisa SmithBy Lisa Smith

When we are considering any large investment either in our personal or work life, it is natural to question how fiscally sound that investment decision is to make.  Whether a company is considering the impact of rolling out a new product to market, acquire a company to gain market share or opening a new factory, using a Return on Investment (ROI) analysis will help define in hard numbers just how much that investment will return to us and over what period will we see our investment paid back.

What constitutes “good” ROI analysis?

Many companies have been using ROI analysis in their demand management programs to evaluative which proposed projects should funded and those which are not.  In a manner, projects are competing for both the company’s focus (labor) and limited capital dollars.

What is ROI?But a good ROI analysis does not tell the whole story a demand management program needs to determine the merit of each project proposal.  Demand management teams are also requesting project teams to include a business case to accompany an ROI analysis.  A company is not just investing their capital dollars in these projects, they are also investing their people time and focus.  We need to ensure that the project focus and execution is supportive of corporate and or business unit’s strategy – we need to have all of our oars pushing the boat in the same direction.

ROI Analysis

As Gartner espouses in their “Total Value of an Opportunity” (TVO) framework, a good business case needs to include analysis of how an investment has strategic alignment and the overall business impact of the project.  Those projects which are ultimately funded should be best aligned to the strategic goals of the company.  While a project many be financially a great decision, if the project’s goals are not in line with where the company is headed, the financial gains should be disqualified.

The goal of the ROI analysis should be to cleanly portray the financial state of “as-is” and the “to-be” future state after making the investment.  Those financial states should include all elements which are going to vary between the optional states.  When considering what metrics should be included in the analysis, it can be confusing where to draw the line – what to include and what to exclude.  What makes a “good” ROI analysis is not that we analyzing every possible cost metric but only those relevant costs which make a material impact in the savings.  The other key element to consider when building your ROI master piece is how consumable is the analysis by your project’s key stake holders.  If your ROI analysis reminds people of something out of the movie “A Beautiful Mind”, you need to step back and re-evaluate your approach.  A clean view of your assumptions, inputs, formulas and a simple side by side financial comparison of “as-is” vs “to-be” is the best to socialize your ROI study and results.

Socializing Your ROI Study

Buy in and blessing of your ROI study is the final hurdle which you need to have a truly successful ROI analysis.  Set up one on one time with various project stakeholders, walk them through your business case and ROI analysis.  A clean set of eyes is a valuable exercise to see where how your analysis holds water, what elements of your Business case needs to be fleshed out and you will immediately see how “consumable” your analysis is by another person.  If everyone asks the same question, perhaps you should that address that question in your presentation?  Let’s face it, with all the time you have been spending on building out your business case, you probably have a lot of key assumptions in your head which might not be obvious to your audience.  Lastly, during those 1:1 sessions with your stakeholders, it is a great time to feel out their support of your project and your quest for funding.

In summary, when building a business case presentation for your project consider the following factors:

  • Explain “How does this project support my corporation’s strategic direction?”
  • Outline “How will the business be impacted by my project’s success?”
  • Summarize results of ROI Analysis including side by side comparison of “as-is” and “to-be” costs.
  • Cover key assumptions, inputs and formals supporting your ROI calculation.
  • Perform key stakeholder reviews to build internal support of your work

What’s next?

This is the first blog in a series that will explore end to end ROI best practices.  Stay tuned for blogs on:

  1. Introduction and Goal of ROI Analysis
  2. Scope of ROI Analysis
  3. Structure of ROI Framework
  4. Different type of Value
  5. Infrastructure Analysis
  6. Process Analysis – Labor
  7. Process Analysis – Time to Market
  8. Process Analysis – Service Impact
  9. Risk Mitigation
  10. Tying it all to together – telling the story
  11. Benefits Realization

Lisa Smith is a Business Value Consultant in the VMware Accelerate Advisory Services team and is based in New York, NY.

From CIO to CEO: How to run an IT as a Service Provider

Jason StevensonBy Jason Stevenson

A service involves two parties: 1) a customer and 2) a service provider.

A service fulfills a customer’s need. Though there may be many components to a service, those technology, process, and people components are combined to form a single service. The customer should not need to understand all the subcomponents of the service to benefit from the service. Nor should any service-specific knowledge be required for the customer to solicit the service. In other words, the service should be expressed in cohesive layman’s terms.

Water Service Example

  • Customer Needs:  Water services fulfill multiple needs: life/thirst, personal/environmental sanitation, etc. If you put in a well, you have your own water and there’s no need for water service. However, if you do not have a well, you will need to engage the county water service provider.
  • Service Provider:  To engage water services, you expect simple contract language and simple commodity pricing. The customer should not need to be a plumber or hydro-engineer to engage the service.
  • Customer Expectations:  Once engaged, the customer doesn’t care how the water gets to them, what must be maintained, or who maintains it. After procuring the water service, they never want to talk to the water service provider again unless their needs change. If water service is interrupted, it’s the service provider’s problem. Customers don’t care what service provider people, tools, or expenses are needed to fix the problem, they just expect it to be rapidly resolved by any means.

How does this example relate to IT services?

First, let’s lay out the key players:

  • CEO, CFO, and stakeholders = Mom and Dad paying for the water service
  • IT Users = the family drinking the water and bathing in it
  • IT department = water service provider
  • IT services = water
  • Data, applications, networks, servers, storage = water treatment plants, water towers, mainlines, pipes, trucks, wrenches
  • IT staff = plumbers and hydro-engineers

Every time a customer experiences interruptions and contacts a water service center, the support call is not considered a “service” but is ancillary to the water service they are already payed for. The customer would rather not engage the service center at all. This is the same with an IT service desk.

Though a water plant monitors water flow and quality, it is not a service. The customer assumes the water is available with adequate water pressure when they purchase the service. This is the same with an IT operations center.

Though hydro-engineers and plumbers may be needed, for example in a large mall complex, they’re assistance would not be a service, rather a project to support the delivery of water services to the tenants and patrons of the mall. This is the same with IT engineers, developers, and project teams.

We assume the water is safe, maintained, and appropriate precautions are taken to ensure ongoing water quality and availability. This is the same with IT security, IT service management, and disaster recovery.

How do CIOs apply this to running as an IT as a Service Provider?

Think of what a water provider service catalog website looks like. It’s pretty simple… Water. Everything needed to supply the water is moot. You may be thinking “Sure this is true of a water commodity but IT is not a commodity.” No it is not… not yet.

So let’s take it up a notch and talk about utilities like telephone and energy services. Their service catalog websites contain utility services. Telephone companies for example list things like local and long-distance, Internet, call waiting, caller ID, conferencing, etc. on their service catalog website. They may also segregate their services by enterprise, small business, and individual customers.

Cable companies are even more similar to IT in some respects. They list things like VoIP communications, Internet, television/entertainment packages, etc. You can draw a parallel between each station offered by a cable company to each application offered by IT.

Regardless of commodities or utilities, service providers of water, power, telephone, cable, etc. have very simple service catalogs considering their extremely complex infrastructure and organizations. This is because the service provider has matured their services to focus on the customer/users and highly refined their services to meet specific customer/user needs, to remain relevant, competitive, and accessible.

To become a true service-provider, IT must take a similar approach to interaction with customers and users. To be successful, CIOs become CEOs by defining a usable service catalog with:

  • A clear business-focus addressing specific needs
  • Inclusive pricing and options
  • Seamless delivery
  • Transparent fulfillment

Jason Stevenson is a Transformation Consultant based in Michigan.

We’re going to the Cloud. Do I Still Need ITSM?

Greg LinkBy Greg Link

As of this writing, Boeing Aircraft Company is demonstrating its 787 Dreamliner at the Paris Air show. After a normal takeoff roll, the aircraft jumps off the runway into what appears to be a near vertical climb to the clouds! That is impressive. Recently a different form of cloud; cloud computing – has appeared on the horizon and appears to be here to stay. Forrester expects cloud computing will increase from approximately $41 billion this year, and rise to more than $240 billion in 2020. A 600% increase in 5-years is impressive indeed. Traditional IT shops have embraced IT Service Management (ITSM) frameworks, such as the Information Technology Infrastructure Library (ITIL®), to help them respond to dynamic business requirements. But is this framework still needed as more and more companies turn to the cloud?

What is the purpose of ITSM?

ITSM and ITIL are often used interchangeably. They are synonymous because ITIL has become the de facto or gold standard for the design, delivery and operation of quality IT services that meet the needs of customers and users. Its approach focuses on 3 major areas:

  • Using a process approach to
  • Deliver IT services rather than IT systems or applications, while
  • Stressing continual service improvement.

With the success of ITSM initiatives all across the globe there is little reason to abandon these critical practices simply due to a shift in the way storage and computing are being performed. The cloud is merely providing companies with powerful utility to meet business requirements and demand.

5 reasons why ITSM is still needed in the cloud

Your transformation to the cloud can take several paths. You can go the route of the Private Cloud where you have total control over the infrastructure and applications that will be used to do business. Another option is the Public Cloud where you contract with a provider that will host storage and computing resources. The final option is the Hybrid Cloud – combination of the two – that allows companies to meet seasonal or growing demand. Any path chosen will still require the basics covered in ITIL.

1) Service Strategy

Service strategy helps in understanding the market and customer needs to create a vision of the services needed to meet business objectives. In this phase we look at things like Financial Management. The cloud is best served when costs and fees are known and predictable. This segment also looks at Demand Management. This discipline proactively manages the dynamics of how the service will be governed from a resource perspective. Both of these are critical to success in the cloud.

5) Service Design

Service Design is the practice of taking a holistic approach to end-to-end service design while considering such things as people, process, technology and vendor relationships. Processes within this phase that are critical with the cloud are:

  • Service Level Management – setting and keeping service targets
  • Supplier Management – this is essential if you are considering going into the Public Cloud as the vendor you choose will be responsible for the delivery of your services.
  • Service Continuity Management – what is the backup plan and if needed, the recovery plan to resume business services should there be a disruption?
  • Capacity and Availability Management – will resources be available and in quantities needed to meet the business requirements in a cost effective manner?

3) Service Transition

Service Transition assists in getting a service into production with processes such as:

  • Transition Planning and Support – planning and coordination of resources in ensure your IT service is market ready.
  • Evaluation – does the service perform and do what it is supposed to do (warranty and utility)?
  • Knowledge Management – make sure that people have the information they need, in whatever capacity, to support the service.
  • Change Management – Private cloud users will follow existing process, however a well coordinated change management process will be needed for Public and Hybrid cloud users. Your vendor’s changes may affect your application in unwanted ways. Additionally, if the cloud is to be used for provisioning servers and environments, the Change Management should be optimized for agility and repeatability.

4) Service Operation

Service Operation manages how a company balances areas in consistency and responsiveness. Processes important when considering deployment to a cloud environment are:

  • Incident Management – where do cloud users turn to when things don’t go as they should and how is that managed?
  • Access Management – the method by which only authorized users are allowed access to use the application and other resources used in the delivery of services.

5) Continual Service Improvement 

  • Now that you’ve deployed to the cloud, how are customers reacting to your service? Is the service meeting their needs? Is it fast enough clear enough, secure enough…?

IT Service Management principles will help guide you into a successful cloud experience with ease and confidence.  Luckily, you’re not alone.  VMware professional services are not only experts in cloud innovation, we have ITIL Experts on staff who can help you ensure ITSM best practices are applied throughout your operating model.


Greg Link is a Transformation Consultant based in Las Vegas, NV

Understanding Software-Defined Networking for IT Leaders – Part 1

Reg Lo By Reg Lo

Software-defined networking (SDN) is revolutionizing the datacenter much like server virtualization has done. It is important for IT leaders to understand the basic concepts of SDN and the value of the technology: security, agility through automation and cost-savings. This blog post explores some of the security benefits of SDN using a simple analogy.

DomiNations

Courtesy of the game DomiNations, Nexon M, Inc.

My kids are playing DomiNations – a strategy game where you lead your nation from the Stone Age to the Space Age. I recruited their help to illustrate how SDN improves security. In this analogy, the city is the datacenter; walls are the firewall (defense against attackers/hackers), and the workloads are the people/workers.

The traditional way of defending a city is to create walls around the city. In the same manner, we create a perimeter defense around our datacenter using firewalls. However, imagine there is a farm outside the walls of the city. Workers need to leave the protection of the city walls to work in the farm. This leaves them vulnerable to attack. In the same way, as workloads or virtual machines are provisioned in public or hybrid clouds outside the datacenter firewalls, what is protecting these workloads from attack?

DomiNations

Courtesy of the game DomiNations, Nexon M, Inc.

In an ideal world, let’s say my kids have magical powers in the game and they enchant the city walls so they can expand and contract to continuously protect the workers. When a worker goes to the farm, the walls automatically extend to include the worker in the farm. When they return back to the city, the walls return to normal. SDN is like magic to your firewalls. Instead of your firewalls being defined by physical devices, a software-defined firewall can automatically expand into the public cloud (or the part of the hybrid cloud that is outside of your datacenter) to continuously protect your workloads.

This ability to easily and automatically configure your firewalls provides another benefit: micro-segmentation. As mentioned before, in a traditional city, the city walls provide a perimeter defense. Once an attacker breaches the wall, they have free range to plunder the city. Traditional datacenters have a similar vulnerability. Once a hacker gets through the firewall, they have free range to expand their malicious activity from one server to the next.

DomiNations

Courtesy of the game DomiNations, Nexon M, Inc.

Micro-segmentation of the network is like having city walls around each building. If an attacker breaches the outer perimeter, they can only destroy one building before having to re-start the expensive endeavor of attacking the next line of defense. In a similar fashion, if a hacker penetrates one application environment, micro-segmentation prevents them from gaining access to another application environment.

Software-defined networking can improve information security. Every few months there is a widely publicized security breach that damages a company’s brand. CIOs and other IT leaders have lost their jobs because of these breaches. SDN is a key technology to protect your company and your career.

In Part 2 and 3 of this series, “Understanding Software-Defined Networking for IT Leaders,” we’ll explore how SDN increases agility and drives cost savings.


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

Solving the Shadow IT Problem: 4 Questions to Ask Yourself Now

Harris_SeanBy Sean Harris

Most IT organizations I speak to today admit they are concerned about the ever-increasing growth in the consumption of shadow IT services within the business; the ones that are not concerned I suspect are in denial. A common question is, “How do I compete with these services?” The answer I prefer is: “Build your own!”

What Would It Mean for My IT Organization to Truly Replace Shadow IT?

Totally displacing Shadow IT requires building an organization, infrastructure and services portfolio that fulfills the needs of the business as well as—or better than—external organizations can, at a similar or lower cost. In short, build your own in-house private cloud and IT-as-a-Service (ITaaS) organization to run alongside your traditional IT organization and infrastructure.

Surely your own in-house IT organization should be able to provide services that are a better fit for your own business than an external vendor.

IT service providers often provide a one-size-fits-all service for a variety of businesses in different verticals: commercial, non-commercial and consumer. And in many cases, your business has to make compromises on security and governance that may not be in its best interests. By definition, in-house solutions will comply with security and governance regulations. Additionally, the business will have visibility into the solution, so the benefits are clear.

How Do I Build My Own Services to Compete With Shadow IT?

Answering the technical part of this question is easy. There are plenty of vendors out there offering their own technical solutions to help you build a private cloud. The challenge is creating the organizational structure, developing in-house skills, and implementing the processes required to run a true ITaaS organization. Most traditional IT organizations lack key skills and organizational components to do this, and IT organizations are not typically structured for this. For example:

  • To capture current and future common service requirements and convert these into service definitions, product management-type skills and organizational infrastructure are needed.
  • To promote the adoption of these services by the business, product marketing and sales-type functions are required.

These are not typically present in traditional IT organizations. Building this alongside an existing IT organization has three main benefits:

  • It is less disruptive to the traditional organization.
  • It removes the pain of trying to drive long-term incremental change.
  • It will deliver measurable results to the business quicker.

What If External IT Services Really Are Better?

It may be discovered after analyzing the true needs of the business that an external provider really can deliver a service that is a better fit for the business needs – and maybe even at a lower cost than the internal IT organization can offer. In this case, a “service broker” function within the IT organization can integrate this service into the ITaaS suite offered by IT to the business far more seamlessly than a traditional IT organization can. The decision should be based on business facts rather than assumptions or feelings.

How Do We Get Started?

As part of VMware’s Advisory Services and Operation Transformation Services team, I work with customers every day to map out the “Why, What and How” of building your own ITaaS organization to compete with Shadow IT services:

  • Why
    • Measurable business benefits of change
    • Business case for change
  • What
    • Technology change
    • Organizational change
    • People, skills and process change
  • How
    • Building a strategy and roadmap for the future
    • Implementing the organization, skills, people and process
    • Measuring success

In the end, customers will always choose the services that best meet their needs and cause them the least amount of pain, be it financial or operational. Working to become your business’ preferred service provider will likely take time and resources, but in the long run, it can mean the difference between a role as a strategic partner to the business or the eventual extinction of the IT department as an antiquated cost center.


Sean Harris is a Business Solutions Strategist in EMEA based out of the United Kingdom.

What Is DevOps, and Why Should I Care? — The IT Leadership Perspective

kai_holthausBy Kai Holthaus

One of the newest buzz words in IT organizations is “DevOps.” The principles of DevOps are contrary to how IT has traditionally managed software development and deployment. So, why are more and more organizations looking to DevOps to help them deliver IT services to customers better, cheaper and faster?

But…what exactly is DevOps anyway? It is not a job or a tool or a market segment; it’s best defined as a methodology, or an approach. It has ideological elements that are in common with techniques like Sigma Six and Lean. More on this later.

Software Development and Deployment Today

DevOps todayIn today’s world, there’s a “wall” between the teams that develop software and the teams that deploy software. Developers work in the “Dev” environment, which is like a sandbox where they can code, try, test, stand up servers and tear them down, as the coding work requires. Teams working in the “Ops” environment deploy the software into a production environment, where they also ensure the software is operational. Often, the developed software is literally ‘thrown over the wall’ to operations teams with little cooperation during the deployment.

Why Was It Set Up That Way?

This “wall” is an unintended consequence of the desire to allow developers to perform their tasks, and operational teams to do theirs. Developers are all about change; their job is to change the existing (and functional) code base to produce additional functionality. Operations teams, on the other hand, desire stability. Once the environment is stable, they would like to keep it that way, so that customers and users can do their work.

For that reason, developers usually do not even have access to the production environment. Their work—by nature—is considered too disruptive to the stability of the production environment.

The Problems with Today’s Development and Deployment

Because of the separation between developers and operations, deployment is often cumbersome and error-prone. While developers are usually asked to develop deployment techniques and scripts, these techniques first have to be adapted to the production environment. Then they have to be tested. And since the deployment teams don’t usually understand the new code (or its requirements) as well as the developers, the risk to introduce errors rises. Worst case, it will lead to incidents, which are all too common.

Additionally, in today’s datacenters that are not yet software-defined, new infrastructure—such as compute, storage or network resources—is hard to set up and integrate into the environment. This further slows down deployments and raises the possibility of disruptions to the environment.

DevOps to the Rescue

At its core, DevOps is a new way of developing and maintaining software that stresses collaboration, integration and automation. It attempts to break down the “wall” between development and operations that exists today by removing the functional separation between the teams. It uses agile development and testing methodologies, such as Scrum, and relies on virtualization and automation to migrate entire environments instead of migrating just the codebase between environments.

The main goal of implementing a DevOps approach is to improve deployment frequency—up to “continuous deployment”—of small, incremental improvements to the functionality of software. Essentially, “dot releases,” and with software updates evolving from manufactured media to online streaming, this makes complete sense.

DevOps_graphic2

Why DevOps? Why Now?

With the increased availability and utilization of software to provision, manage and decommission resources—such as compute, storage and network in datacenters and IT environments—the DevOps approach is becoming more and more common. IT organizations are now able to create new resources, integrate them quickly into environments, and even move them between environments with the click of a button. This allows developers to develop their code in a particular technology stack, and then easily migrate the entire stack to the production environment, without disrupting the existing environment.

Sounds Great, How Do I Start?

The three main aspects that need to be addressed to implement a DevOps approach for the development and operations of software come down to the familiar elements of project management:

  • People
  • Process
  • Technology

On the people side, teams have to be established that have accountability over the software across its entire lifecycle. The same teams that develop the software will also assure the quality of the software and deploy the software into the production environment.

From a process perspective, an agile development methodology, such as Scrum, must be implemented to increase the frequency at which deployable packages of software are being created. Reducing the amount of change at each deployment cycle will also increase the success rate of the deployments, and reduce the number of incidents being created.

On the technology side, DevOps relies heavily on the Software-defined Datacenter (SDDC), including high levels of automation for the provisioning, management and decommissioning of datacenter resources.

VMware Is Here to Help

VMware has been the leader in providing the software to enable the SDDC. VMware also has the knowledge and technology to enable you to use DevOps principles to improve your software-based service delivery. VMware vRealize Code Stream enables continuous deployment of your software. And if you like to be on the leading edge of technology, check out VMware Photon for a technology preview of software that allows you to deploy new apps into your environments in seconds.


Kai Holthaus is a delivery manager with VMware Operations Transformation Services and is based in Oregon.

4 Key Elements of IT Capability Transformation

worthingtonp-crop-150x150By John Worthington

As with any operational transformation, an IT organization should start with a roadmap that lays out each step required to gain the capabilities needed to achieve their desired IT and business outcomes. A common roadblock to success is that organizations can overlook one or more of the following key elements of IT capability transformation:

Technical

Technical capabilities describe what a technology does. The rate of technological change can drive frantic cycles of change in technical capabilities, but often, it is critical to examine other transformation elements to realize the value of technical capabilities.

People

A people-oriented view of a capability focuses on an organization’s workforce, including indicators of an organization’s readiness for performing critical business activities, the likely results from these activities, and the benefit from investments in process improvement, technology and training.

Transitioning people requires understanding what roles, organizational structure and knowledge will be needed at each step along the transformation path.

Process

A process sharpens the view of an organizational capability. Formally calibrating process capabilities and maturity requires processes be defined in terms of purpose/objectives, inputs/outputs and process interfaces. One advantage of a process view is that it combines other transformation elements, including people (roles) and technology (support for the process).

Transitioning processes is more about adaptation – assuming the organization has defined processes to adapt. While new working methods associated with cloud computing—such as agile development and continual deployment—are driving ‘adaptive’ process techniques, an organization’s process capability will remain a fundamental and primary driver of organizational maturity.

Service

A service consciously abstracts the internal operations of a capability; its focus is on the overall value proposition. A service view of a capability is directly tied to value, since services—by definition, according to ITIL—are a “means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.”

As you assess your organization’s readiness for transformation, and create a roadmap specific to your organization, it’s essential that these transformation elements are understood and addressed.


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