Home > Blogs > VMware Accelerate Advisory Services > Tag Archives: operations transformation

Tag Archives: operations transformation

Transforming IT into a Cloud Service Provider

Reg LoBy Reg Lo

Until recently, IT departments thought that all they needed to do was to provide a self-service portal to app dev to provision VMs with Linux or Windows, and they would have a private cloud that was comparable to the public cloud.

Today, in order for IT to become a cloud service provider, IT must not only embrace the public cloud in a service broker model, IT needs to provide a broader range of cloud services.  This 5 minute webinar, describes the future IT operating model as IT departments transform into cloud service providers.

Many IT organizations started their cloud journey by creating a new, separate cloud team to implement a Greenfield, private cloud.  Automation and proactive monitoring using a Cloud Management Platform was key to the success for their private cloud.  By utilizing VMWare’s vRealize Cloud Management Platform, IT could easily expand into the hybrid cloud, provisioning workloads to vCloud Air or other public clouds from a single interface.  Effectively, creating “one cloud” for the business to consume and “one cloud” for IT to manage.

However, the folks managing the brownfield weren’t staying still.  They too wanted to improve the service they were providing the business and they too wanted to become more efficient.  So they also invested in automation.  Without a coherent strategy, both Brownfield and Greenfield took their own separate forks down the automation path, confusing the business on which services they should be consuming.  We started this journey by creating a separate cloud team.  However, it may be time to re-think the boundaries of the private cloud and bring Greenfield and Brownfield together to provide consistency in the way we approach automation.

In order to be immediately productive, the app dev teams are looking for more than infrastructure-as-a-service.  They want platform-as-a-service.  These might be second generation platforms such as database-as-a-service (Oracle, MSSQL, MySQL, etc.) or middleware-as-a-service (such as Web Methods).  Or they need third generation platforms based on unstructured PaaS like containers or structured PaaS like cloud foundry.  The terms first, second and third generation map to the mainframe (1st generation), distributed computing (2nd generation), and cloud native applications (the 3rd generation).

Multiple cloud services can be bundled together to create environment-as-a-service.  For example, LAMP-stacks – Linux, Apache, MySQL and PHP (or Python).  These multi-VM application blueprints lets entire environments be provisioned at a click of a button.

A lot of emphasis has been placed on accessing these cloud services through a self-service portal.  However, DevOps best practices is moving towards infrastructure as code.  In order to support developer-defined infrastructure, IT organizations must also provide an API to their cloud.  Infrastructure-as-code lets you version the infrastructure scripts with the application source code together, ultimately enabling the same deployment process in every environment (dev, test, stage and prod) – improving deployment success rate.

Many companies are piloting DevOps with one or two application pipelines.  However, in order to scale, DevOps best practices must be shared across multiple app dev teams.  App dev teams are typically not familiar with architecting infrastructure or the tools that automate infrastructure provisioning.  Hence, a DevOps enablement team is useful for educating the app dev teams on DevOps best practices and providing the DevOps automation expertise.  This team can also provide feedback to the cloud team on where to expand cloud services.

This IT operating model addresses Gartner’s bimodal IT approach.  Mode 1 is traditional, sequential and used for systems of record.  Mode 2 is agile, non-linear, and used for systems of engagement.  Mode 1 is characterized by long cycle times measured in months whereas mode 2 has shorter cycle times measured in days and weeks.

It is important to note that the business needs both modes to exist.  It’s not one or the other.  Just like how the business needs both interfaces to the cloud: self-service portal and API.

What does this mean to you?  IT leaders must be able to articulate a clear picture of the future-state that encompasses both mode 1 and mode 2, that leverages both a self-service portal and API to the organization’s cloud services.  IT leaders need a roadmap to transform their organization into cloud service providers that traverse the hybrid cloud.  The biggest challenge to the transformation is changing people (the way they think, the culture) and processes (the way they work).  VMware can not only help you with the technology; VMware’s AccelerateTM Advisory Services can help you address the people and process transformation.

 


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

Evolving Cyber Security – Lessons from the Thalys Train Attack in France

Gene LikinsBy Gene Likins

Earlier this year, I was privileged to facilitate a round table for forty seven IT executives representing sixteen companies in the financial services industry.  As expected for a gathering of FSI IT executives, one of the primary topics on the docket was security.

The discussion started with a candid listing of threats, gaps, hackers and the challenges these pose for all in the room.  The list was quite daunting.  The conversation turned to the attempted terrorist attack on the Thalys high speed international train, traveling from Amsterdam to Paris.  A heavily armed gunman had boarded the train with an arsenal of weapons and was preparing to fire on passengers.  Luckily, several passengers managed to subdue the gunman and prevent any deaths

Immediately following the incident, the public began to question the security measures surrounding the train and the transit system in general.  Many recommended instituting airport style security measures, including presentation of identity papers, metal detectors, bag searches and controlled entry points

Given the enormous cost and the already strained police resources running at capacity, some are now calling for a different perspective on security.  As former interior minister of France Claude Gueant said,

“I do not doubt the vigilance of the security forces, but what we need now is for the whole nation to be in a state of vigilance.

As IT professionals, this should sound familiar.   So what can we glean from this incident and apply it to cyber security?

  1. Share the burden of vigilance with customers.
    72% of online customers welcome advice on how to better protect their online accounts (Source: Telesign).  One way to share the burden with customers is to recommend or require the use of security features such as Two Factor Authentication (2FA).  Sending texts of recent credit card transactions is an example of a “passive” way of putting the burden on the customer.  The customer is asked to determine if the charge is real and notify the card issuer if it’s not.  Companies should begin testing the waters of just how much customers are willing to do to protect their data.  They may be surprised.
  2. Avoid accidentally letting the bad guys in. 
    One of the common ways that online security is breached is by employees unknowingly opening emails which contain information such as “know what your peers make” or “learn about the new stock that’s about to double in price”. IT groups should continually inform their internal constituents on the nature of threats so we can all stay vigilant and look out for “suspicious characters”.
  3. Contain the inevitable breaches.
    It’s not a matter of “if”, it’s a matter of “when”. Network virtualization capabilities, such as micro‐segmentation, bring security inside the data center with automated, fine‐grained policies tied to individual workloads.  Micro‐segmentation effectively eliminates the lateral movement of threats inside the data center and greatly reduces the total attack surface.  This also buys security team’s time to detect and respond to malicious activities before they get out-of-hand.

Cyber SecurityBuilding a comprehensive security strategy should be on the agenda of all CIOs in 2016.  Cyber criminals are constantly creating new methods of threatening security, and technology is changing daily to counteract them.

VMware NSX, VMware’s network virtualization platform, enables IT to virtualize not just individual servers or applications but the entire network, including all of the associated security and other settings and rules.  This technology enables micro-segmentation and can move your security capabilities forward by leaps and bounds, but it’s only part of a holistic strategy for preventing security breaches.

To remain ahead of the threats, it requires a constant evolution of people, processes and governance, along with technology, to continuously identify and address security concerns for your organization and your customers.  For help building your security strategy, contact the experts at VMware Accelerate Advisory Services

========

Gene Likins is the Americas Director of Accelerate Transformation Services for VMware and is based in Atlanta, GA.

Introducing Kanban into IT Operations

les2By Les Viszlai

Development teams have been using Agile software methodologies since the late 80’s and 90’s, and incremental software development methods can be traced back to the late 50’s.

A question that I am asked a lot is, “Why not run Scrum in IT Operations?”  In my experience, operations teams are trying to solve a different problem.  The nature of demand is different for software development vs the operations side of the IT house.

Basically, Software Development Teams can:

  • Focus their time
  • Share work easily
  • Have work flows that are continuous in nature
  • Generally answer to themselves

While Operations Teams are:

  • Constantly interrupted (virus outbreaks, systems break)
  • Dealing with specialized issues (one off problems)
  • Handling work demands that are not constant (SOX/PCI, patching)
  • Highly interdependent with other groups

In addition; operational problems cross skills boundaries.

What is Kanban?

Kanban is less restrictive than Scrum and has two main rules.

  1. Limit work in progress (WIP)
  2. Visualize the workflow (Value Stream Mapping)

With only two rules, Kanban is an open and flexible methodology that can be easily adapted to any environment.  As a result, IT operations projects, routine operations/ production-support work and operational processes activities are ideally suited to using a Kanban approach.

Kanban (literally signboard or billboard in Japanese) is a scheduling system for lean and just-in-time (JIT) production. Kanban was originally developed for production manufacturing by Taiichi Ohno, an industrial engineer at Toyota.  One of the main benefits of Kanban for IT Operations is that it will establish an upper limit to the work in progress at any given process point in a system.   Understanding the upper limits of work loads helps avoid the overloading of certain skill sets or subsets of an IT operations team.  As a result, Kanban takes into account the deferent capabilities of IT operations teams

Key Terms:

Bottlenecks

Let’s look at our simple example below; IT operations is broken up into the various teams that each have specific skills sets and capabilities (not unlike a number of IT shops today). Each IT ops team is capable of performing a certain amount of work in a given timeframe (u/hr). Ops Team 4, in our example below, is the department bottleneck and we can use Kanban methodology to solve this work flow problem, improve overall efficiencies and complete end-user requests sooner.

Kanban Bottlenecks

As we said earlier, the advantage of adopting a Kanban methodology is that it is less structured than Scrum and is easier for operations teams to adopt. Kanban principles can be applied to any process your IT operations team is already running. The key focus is to keep tasks moving along the value stream.

Flow

Flow, a key term used in Kanban, is the progressive achievement of tasks along the value stream with no stoppages, scrap, or backflows.

  • It’s continuous… any stop or reverse is considered waste.
  • It reduces cycle time – higher quality, better delivery, lower cost

Kanban Flow

Break Out the Whiteboard

Kanban uses a board (electronic or traditional whiteboard) to organize work being done by IT operations.

A key component to this approach is breaking down Work (tasks) in our process flow into Work Item types.  These Work Items can be software related like new features, modifications or fixes to critical bugs (introduced into production).  Work Items can also be IT services related like; employee on-boarding, equipment upgrades/replacements etc.

Kanban Board

The Kanban approach is intended to optimize existing processes already in place.  The basic Kanban board moves from the left to the right. In our example, “New Work” items are tracked as “Stories” and placed in the “Ready” column.  Resources on the team (that have the responsibility or skill set) move the work item into the first stage (column) and begin work.  Once completed the work item is moved into the next column labeled “Done”.  In the example above a different resource was in place as an approver before the work item could move to the next category, repeating for each subsequent column until the Work Item is in production or handed off to an end-user.  The Kanban board also has a fast lane along the bottom. We call this the “silver bullet lane” and use it for Work Items of the highest priority.

How to Succeed with Kanban

In my previous experience as a CIO, the biggest challenge in adopting Kanban in IT operations was cultural.  A key factor in success is the 15 min daily meeting commitment by all teams involved.  In addition, pet projects and low priority items quickly surface and some operations team members are resistant to the sudden spotlight.  (The Kanban board is visible to everyone

Agreement on goals is critical for a successful rollout of Kanban for operations.   I initially established the following goals;

  • Business goals
    • Improve lead time predictability
    • Optimize existing processes
      • Improve time to market
      • Control costs
  • Management goals
    • Provide transparency
    • Enable emergence of high maturity
    • Deliver higher quality
    • Simplify prioritization
  • Organizational goals
    • Improve employee satisfaction (remember ops team 4)
    • Provide slack to enable improvement

In addition, we established SLA’s in order to set expectations on delivery times and defined different levels of work priority for the various teams.  This helped ensure that the team was working on the appropriate tasks.

In this example, we defined the priority of work efforts under 5 defined areas; Silver Bullet, Expedite, Fixed Date, Standard and Intangible.

Production issues have the highest priority and are tagged under the Silver Bullet work stream.  High priority or business benefit activities fell under Expedite.  Fixed Date described activities had an external dependency such as Telco install dates.  And, repeatable activities like VM builds or Laptop set-ups would be defined as Standard.  Any other request that had too many variables and undefined activities was tagged as Intangible (a lot of projects fell into this category).

I personally believe that you can’t fix what you can’t measure, but the key to adopting any new measurement process is to start simple.  We initially focused on 4 areas of measurement:

  1. Cycle Time: This measurement is used to track the total days/hours that a work item took to move through the board.  This was the time it took to move through the board once a Work Item moved out of the Ready column.
  1. Due Date Performance: Simply measures the number of Work Items that completed on or before the due date out of the total work items completed
  1. Blocked Time: This measurement was used to capture the amount of days/hours that work items are stalled in any column
  1. Queue Time: This measurement was used to track how long work items sat in the Ready column.

These measurements let us know how the Operations team performed in 4 areas:

  • How long items sit before they are started by Operations.
  • Which area/resource within IT is causing blockage for things being done.
  • How good is the team at hitting due dates and
  • The overall time it takes things to move through the system under each Work stream.

Can we use Kanban with DevOps?

The focus on Work In Progress (WIP) and Value Stream Mapping makes Kanban a great option to extend into DevOps. Deploying Work Items becomes just another step in the Kanban process, and with its emphasis on optimizing the whole delivery rather than just the development process, Kanban and DevOps seem like a natural match.

As we saw, workflow is different in Kanban than in Scrum. In a Scrum model, new features and changes are defined for the next sprint. The sprint is then locked down and the work is done over the sprint duration (usually 2 weeks). Locking down the requirements in next sprint ensures that the team has the necessary time to work without being interrupted with other “urgent” requirements.  And the feedback sessions at the end of the sprints ensure stakeholders approve the delivered work and continue to steer the project as the business changes.

With Kanban, there are no time constraints and the focus is on making sure the work keeps flowing, with no known defects, to the next step.  In addition, limits are placed on WIP as we demonstrated earlier.  This ensures that a maximum number of features or issues can be worked on at a given time. This should allow teams to focus and deliver with higher quality.  In addition, the added benefit of workflow visibility drives urgency, keeps things moving along and highlights areas of improvement.   Remember, Kanban has its origins in manufacturing, and its key focus is on productivity and efficiency of the existing system. With this in mind, Kanban by design, can be extended to incorporate basic aspects of software development and deployment.

In the end, organizations that are adopting DevOps models are looking to increase efficiencies, deploy code faster and respond quicker to business demands. Both the Kanban and Scrum methodologies address different areas of DevOps to greater and lesser degrees.

The advantages of the Kanban system for IT operations is in its ability to create accountability in a very visible system. The visibility of activities, via the Kanban board and its represented Work Items, aid in improving production flow and responsiveness to customer demand.  It also helps shift the teams focus to quality improvement and teamwork through empowerment and self-monitoring activities.

=========

Les Viszlai is a principal strategist with VMware Advisory Services based in Atlanta, GA.

Increase the Speed of IT with DevOps and PaaS

Reg Lo By Reg Lo

How do you increase the speed of IT?

In this 5 minute video whiteboard session I will describe two key strategies for making IT more agile and improving time to market.  For your convenience there is also a transcript of the video below.

Two key strategies for increasing the speed of IT are:

  1. Deliver more applications using DevOps. Traditional waterfall methods are too slow.  Agile methodologies are an improvement but without accelerating both the infrastructure provisioning and application development, IT is still not responsive enough for the business.  Today, many organizations are experimenting with DevOps but to really move the needle, organizations must adopt DevOps at scale.
  2. Deliver new Platform-as-a-Service faster. Infrastructure-as-a-Service is the bare minimum for IT departments to remain relevant to the business.  If IT cannot provide self-service on-demand IaaS, the business will go directly to the public cloud.  To add more value to the IaaS baseline and accelerate application delivery, IT must deliver application platforms in a cloud model, i.e. self-service, on-demand, with elastic capacity.

Let’s start with this second key strategy: delivery new PaaS services faster.  PaaS services include second generation platforms (database-as-a-service, application server-as-a-service, web server-as-a-service) as well as third generation platforms for cloud native applications such as Hadoop-as-a-service, Docker-as-a-service or Cloud Foundary-as-a-service.

In order to launch these new PaaS services faster, IT must have a well-defined service lifecycle that it can use to quickly and repeatably create these new services.  What are the activities and what artifacts must be created in order to analyze, design, implement, operate and improve a service?

Once you have defined the service lifecycle, you can launch parallel teams to create the new service: platform-as-a-service, database-as-a-service, or X-as-a-service where X can be anything.  Each service can be requested via the self-service catalog, delivered on demand, and treated like “code” so it can be versioned with the application build.

Each service needs a single point of accountability – the Service Owner.  The service owner is responsible for the full lifecycle of the service.  They are part of the Cloud Services team, or also called the Cloud Tenant Operations team.  The Cloud Services Team also manages the service catalog, provides the capability to automate provisioning, and manages the operational health of the services.

The Cloud Services Team is underpinned by the Cloud Infrastructure Team. This team combines cross-functional expertise from compute, storage and network to create the profiles or resource pools that the cloud services are built on.  The Cloud Infrastructure Team is also responsible for capacity management and security management.  The team not only manages the internal private cloud, but also the enterprise’s consumption of the public cloud, transforming IT into a service broker.

Now that we’ve described the new cloud operating model, let’s return to the first key strategy for increasing the speed of IT: deliver more applications using DevOps.  Many organizations have tasks one or two applications teams to pilot DevOps practices such as continuous integration and continuous deployment.  This is a good starting point, however, in order to expand DevOps at scale so IT can provide a measurable time-to-market impact for the business, we need to make the adoption easier and more systematic.

The DevOps enablement team is a shared services team that provides consulting services to the other app dev teams; contains the expertise in automation so that other app dev teams do not need to become the expert in Puppet, Chef, or VMware CodeStream; and, this team drives a consistent approach across all app dev teams to avoid a fragmented approach to DevOps.

Remember how we talked about expanding PaaS?  With self-service on-demand PaaS provisioning, app dev teams can build environment-as-a-service: an application blue print that contains multiple VMs (the database server, application server, web server, etc.)  Environment-as-a-service lets app dev teams treat infrastructure like code, helping them adopt continuous deployment best practices by linking software versions to infrastructure versions.

By delivering more applications using DevOps and by delivering new PaaS services faster, you can increase the speed of IT.


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

Don’t Let Stakeholder Management & Communications Be Your Transformation’s Goop Mélange

John Worthington By John Worthington

What is “Goop Mélange”?

In an episode of TV’s “The Odd Couple” Oscar took on making his own dinner.  He mixed in potato chips, sardines, pickles, and whipped cream.  It was then garnished with ketchup.  When Felix asked what he called this mélange, Oscar answered, “Goop.”

So what does this have to do with stakeholder management?

The importance of stakeholder management is referenced in almost all best practice guidance including ITIL, COBIT, PMBOK, TOGAF and many more. In addition, the number of channels available for engaging stakeholders is growing to include social media, smartphones and other enabling technologies.

Unchecked, your stakeholder management plan can quickly become a very confusing mix of uncoordinated communication. Mixing up a little bit of everything can wind up being the goop mélange of your transformation program.

One way to assure a desirable mix of communication channels is to establish a Service Management Office (SMO), which can begin to develop marketing and communication expertise within the IT organization based on a well defined stakeholder management strategy.

The stakeholder management plan can take a look at the organizational landscape based on the current and future needs of a transformation path, identify key stakeholders and provide the analysis and guidance needed for others (such as project managers, architects, etc.) to effectively do so as well within the transformation context.

From a service management perspective, the stakeholder management plan and the SMO can set in motion the improvements needed to establish cross-functional communication. An example might be Service Owners driving dialog about end-to-end IT services across technical domains.

The stakeholder management plan, supported by a well-sponsored SMO, can also ensure that top-to-bottom communication channels are matured. This is enables communication between Process Ownership, Process Management and Process Practitioners as another example.

stakeholder managment

Sticking to these basics of stakeholder management and communications as you begin your transformation can make sure your stay focused on building a solid foundation for more sophisticated communication channels when the organization is ready, and avoid making a goop mélange out of your transformation communications.

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

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

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.

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.

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.