Chances are shadow IT is happening right now at your company. No longer content waiting for their companies’ IT help, today’s employees are taking action into their own hands by finding and using their own technology to solve work challenges as they arise—a trend that likely isn’t fading into the shadows anytime soon.
In this post, I want to share with you some “rule of thumb” estimates on how many full-time equivalent (FTE) positions an IT organization may need to operate a cloud platform. Note: this is not an exact science, so I wanted to give you the practitioner’s approach. What are the general guidelines? What do I need to take into account?
Readers can learn more specific details around the different roles in the cloud management team in the VMware white paper “Organizing for the Cloud” as a starter. Here I use a generic term of “administrator” or “operator” to broadly describe the technicians/analysts/operators who manage and configure the tools on a daily basis. Here’s my list of factors to consider when estimating IT staff ratios:
Number of lines of business. It stands to reason that the higher the number of distinct business units (lines of business) that are using the cloud, the higher the number and complexities of workflows to support, the more user profiles to manages, reports to produce, and so forth.
Number of data centers. If the toolsets must manage multiple data centers, there will be added complexity in order to manage multiple environments, which often are in different locations.
Level staff skill/experience. The higher the experience of the operators, the larger and more complex the infrastructure they can manage. In other words, IT should require fewer FTEs to manage the same level of complexity in a cloud infrastructure. (This is a topic that deserves a separate article: “How the IT Organization Learns to Use Cloud Management Tools — and Over Time.”)
Number of services. By this I mean cloud-type services, as in IT-as-a-service or applications. As a starter, determine how many services will be offered in the cloud service catalog.
Workflow complexity. Factor in the internal complexity of the automated workflows. For example, on a scale of 1-5 (5 being most complex), a workflow with multiple approval points might score as 5, whereas a basic workflow as 1.
Internal process complexity. Within IT, the organization with a higher number of mandatory internal process steps (which might all be in place for good reason) will likely need more staff (or it will take their staff longer) to carry out the same tasks as the organization with fewer internal process steps. A higher degree of complexity often develops in highly regulated environments, be it defense or civil administrations, or where an outsourcing provider requires rigid contractual relationships with inflexible approvals. Process and workflow complexity are related but separate considerations (all processes are not automated into workflows).
Number of third-party integrations. The more integrations that need to be built into the automation workflows, the higher the workload for the operators.
Rate of change. Change may be due to business change (mergers, acquisitions, new products, new applications), but also technological change (such as internal transformation programs). These may impact FTE requirements.
Number of virtual machines under management. It may help to group into broad ranges: less than 100, 100 to 1,000, 1,000 to 10,000, and above 10,000. That range will impact FTE requirements.
Number of user dashboards/reports to maintain. This can range from a couple basic reports to dozens of dashboards and complex reports. If the reporting is not sufficiently automated, the “unfortunate” administrators may need to spend a substantial part of their time producing custom reports for various user groups.
For those readers keen on modeling, each factor I’ve provided can be quite easily prorated on a 1-to-5 scale and turned into a formula. Others can be satisfied with applying as a simple rule of thumb.
My approach can be extended to VMware vRealize Automation or vRealize Operations management products, as well as other management tools. Stay tuned for a future article, as I am also at work to break down the roles far more accurately than “administrators.”
Meanwhile, consider the above factors I’ve outlined as basic guidelines. And a call to action for practitioners: Compare my guidelines to your metrics, and send me your feedback!
—- Pierre Moncassin is an operations architect with the VMware Operations Transformation global practice and is based in the UK.
DevOps. It’s the latest buzzword in IT and, as usual, the industry is either skeptical or confused as to its meaning. In simple terms, DevOps is a concept that allows IT organizations to develop and release software rapidly. By acknowledging the pressure the Development and Operations teams within IT place on each other, the DevOps approach enables the Development and Operations teams to work closely together. IT organizations put policies for shared and delegated responsibilities in place, with an emphasis on communication, collaboration, and integration.
Developers have no problem writing code and pushing it out, however their demand for infrastructure causes conflict with the Operations team. Traditionally it is the Operations team that release code to the various environments including Development, Test, UAT, and Production. As developers want to continuously push functionality through the various environments, it is only natural that Operations gets inundated with requests for more infrastructure. When you add Quality Assurance teams in the mix, efficiency is negatively impacted.
Why the rush to release code? Rapid application development is requisite. The face of IT is changing very quickly and will continue to change even faster. Businesses need to innovate fast, and introduce products and services into the market to beat the competition and meet the demands of their customers.
Here are four reasons rapid application development and release is fundamental:
This is the social media age. Bad code and bugs can no longer be ignored and scheduled for future major releases; when defects are found, word will spread fast through Twitter and blogs.
Mobile applications are changing the way we work and require a different kind of design—one that fits on a smaller screen and is intuitive. If a user doesn’t like one application, they’ll download the next.
Much of the software developed today is modular and highly dependent on readily-available modules and packages. When an issue is discovered with a particular module, word spreads fast among user communities, and solutions need to be developed immediately.
Last and most important, this is the cloud era. The very existence of the Operations team is at stake, because if it cannot provide infrastructure when Development needs it, developers will opt to use a publicly available cloud service. It is that easy.
So what is DevOps again? DevOps is not a “something” that can be purchased — it’s an approach that requires new ways of working as an IT organization. As an IT leader, you will need to “operationalize” your Development team and bring them closer to your Operations team. As an example, your developers will need the capability to provision infrastructure based on new operations policies. DevOps also means you will need to move some of your development functionalities to the Operations team. For example, the Operations team will need to start writing workflows and associated scripts/code that will be used to automate the deployment process for the development team.
While there are adequate tools that will facilitate the journey to DevOps, DevOps is more about processes and people.
How to implement DevOps The IT organization needs to undergo both people and process changes to implement DevOps — and it cannot happen all at once — the change needs to be gradual. It is also very difficult to measure “DevOps maturity.” As an IT leader, you will know it when your organization becomes DevOps capable — it happens when your developers have the necessary tools to release software at the speed of business, and your Operations team is focused on innovation rather than being reactive to infrastructure deployment requirements.
Also, your test environment will evolve to a “continuous integration” environment, where developers can deploy their code and have it tested in an automated and continuous process.
I make the following recommendations to my clients for process, people, and tools required for a DevOps approach:
Process The diagram below illustrates a process for DevOps, in which the Operations team develops automated deployment workflows, and the Development team uses the workflows to deploy to the Test and UAT environments. The final deployment to production is carried out by the Operations team; in fact Operations should continue to be the only team with direct access to production infrastructure.
Service Release Process – Service Access Validation
However, it is critical that Development have access to monitoring tools in production to allow them to monitor applications. These monitoring tools may allow tracking of application performance and its impact on underlying infrastructure resources, network response, and server/application log files. This will allow your developers to monitor the performance of their applications, as well as diagnose issues, without having to consume Operations resources.
Finally, it is assumed that the DevOps tools and workflows will be used for all deployments, including production. This means that the Development and Operations teams must use the same tools to deploy to all environments to ensure consistency and continuity as well as “rehearse” the production release.
The following roles are the main players in facilitating a DevOps approach:
Operations: The DevOps process starts with the Operations team. Their first responsibility is to develop workflows that will automate the deployment of a complete application environment. In order to develop these workflows, Operations is obliged to be part of the development cycle earlier and will therefore have to become closer to Development in order to understand their infrastructure requirements.
Development: The Development team will use their development environment to determine the infrastructure required for the application; for example database version, web server type, and application monitoring requirements. This information will assist the Operations team in determining the capacity required and in developing the deployment workflows. It will help with implementing the custom dashboards and metrics reporting capabilities Development needs to monitor their applications. The Development team will be able to develop and deploy to the “continuous integration” and UAT environments without having to utilize Operations resources. They can “rip and replace” applications to these environments as many times as needed by QA and end-users in order to be production-ready.
Quality Assurance (QA): Due to the high quality of automated test scripts used for testing in such an environment, the QA team can play a lesser role in a DevOps environment by randomly testing applications. QA will also need to test and verify the deployment workflows to ensure the infrastructure configuration used is as per the design.
End Users: End-user testing can be reduced in a DevOps environment, by only randomly testing applications. However once DevOps is in place, end users should notice a vast improvement in the quality and speed of the applications produced.
Tools VMware vRealizeTM Code StreamTM targets IT organizations that are transforming to DevOps to accelerate application released for business agility. Some of the features it offers include:
Automation and governance of the entire application release process
A dashboard for end-to-end visibility of the release process across Development and Operations organizations
Artifact management and tracking
For IT leaders, vRealize Code Stream can help transform the IT organization through a DevOps approach. The “continuous integration” cycle is a completely automated package that will deploy, validate, and test applications being developed.
DevOps can also benefit greatly from using platform-as-a-service (PaaS) providers. By developing and releasing software on PaaS, the consistency is guaranteed as the platform layer (as well as lower layers) are always consistent. Pivotal CF, for example, allows users and DevOps to publish and manage applications running on the Cloud Foundry platform across distributed infrastructure.
Conclusion Although DevOps is a relatively new concept, it’s really just the next step after agile software development methods. As the workforce becomes more mobile, and social media brings customers and users closer, it’s necessary for IT organizations to be able to quickly release applications and adapt to changing market dynamics. (Learn how the VMware IT DevOps teams are using the cloud to automate dev test provisioning and streamline application development in the short video below.)
Many organizations have tackled the issues associated with running internal development teams by outsourcing software development. I now see the reverse happening, as organizations want to reach the market more quickly and have started to build internal development teams again.
For the majority of my clients, it’s not a matter of “if” but “how quickly” will they introduce DevOps. By adopting DevOps principles, their development teams will be able to efficiently release features as demanded by the business, at the speed of business.
==== Ahmed Al-Buheissi is an operations technical architect with the VMware Operations Transformation global practice and is based in Melbourne, Australia.
Communication is the single-most important pillar of being a service-driven IT organization. While technical aptitude and service are both vital, being able to communicate effectively about value internally and to consumers is the key to IT becoming a true business partner.
IT has always struggled because its culture is one of fragmented thought leadership; not to mention the fact that those in the IT profession are often reactive, detail-oriented, and risk averse. Overcoming these obstacles requires careful management of IT’s internal brand.
Traditional IT is control-driven and customized. Go to a third-party cloud service provider and knock on the door, and they aren’t going to hand you a customized solution. The majority of them have a solution that they have predicted you will need. They have created a small number of services that will satisfy most of their consumers.
Now is the time to take a cue from those vendors and shift to a service-oriented model of IT by truly understanding user needs and perceptions first, then designing services around them. Manage IT like it’s your own business. Be competitive, proactive, and innovative. Manage customer perceptions. Remember that risks are opportunities.
Change is Difficult It’s difficult to change negative perceptions, but marketing campaigns do that every day; they are designed to put a new, positive perception in your head. It’s time to start your own IT marketing campaign to manage how your company views IT and help foster change.
Here are the five components you’ll need to think about as you start your IT brand campaign.
Admit where you are now and where you want your brand to go. Your name, symbol, and color palate, are all part of the perception. So are all of the ways you communicate, including emails and templates.
Catalyst of change:
What are the reasons why your stakeholders would want change? The biggest place where this is a problem is within IT.
In order to create a good catalyst, you need a vision that you can communicate. “We have to change because…” Many people are nervous about cloud, for example, but there is an opportunity for it to be that positive catalyst for change, that differentiator that tackles business issues, not just IT issues. Your vision needs to be something that is trackable. It can’t be something too absolute, like being the best cloud provider in the world. You will also need to determine who will communicate the vision and to whom.
Know your niche. There are all sorts of cloud services available. So find out what the needs of your consumers are and your value proposition to them. A lot of times in IT, we buy the architecture first, and then tell people their needs. Now that consumers have options, that strategy is not competitive.
A cohesive message to communicate with different audiences to help position service values.
Let’s look a little more closely at the three types of individuals that you will be communicating with in your entire organization. Of course, the first step is to get your own people on board with the dog food you are going to sell.
The complacent are happy with the status quo, they are the most resistant to change, and unwilling to look at the benefits of change. If you tell them they are going to do something new, they say “no way.” They pose the biggest threat to consumer adoption at your organization.
The blind followers, on the other hand, can get behind any vision but aren’t able to articulate it. They are tactical so the high-level vision is likely too broad for them.
Lastly, you may have a small group of competent followers who may be emerging leaders or IT loyalists (or both). They understand the business units, and are highly interested in the team and organizational results. They can help you manage the other two groups.
Go out and create evangelists. Executives and directors cannot carry the whole load. The individual contributors–those who will be using the services—can be your most influential advocates.
Pave the Way Forward
Now that we’ve looked at the individual types of stakeholders and the five components of your brand campaign, let’s take a look at how to get your message across.
Acknowledge IT’s current state
Tell stakeholders your transformation plans from start to finish.
Admit challenges to make IT more credible.
The plan should communicate:
Product or service
Your competition and how IT compares
IT services value over competition
Three main stages:
Identify critical success factors: What must be right in order to meet forecast and grow?
Value proposition: which aspects of your products make the IT consumer focus on the services rather than the prices?
Prepare a service uptake forecast: Lay the best path that IT can reach.
These IT marketing concepts may seem simple or common sense, but they are also reasonable and achievable. When you prove value through effective communications and marketing, the business starts looking at you like a true partner.
===== Alex Salicrup is a transformation strategist with VMware Accelerate Advisory Services and is based in California.
One aspect of the software-defined data center (SDDC) that is not solved through software and automation is how to support what is being built. The abstraction of the data center into software managed by policy, integrated through automation, and delivered as a service directly to customers requires a realignment of the existing support structure.
The traditional IT organizational model does not support bundling compute, network, storage, and security into easily consumable packages. Each of these components is owned by a separate team with its own charter and with management chains that don’t merge until they reach the CTO. The storage team is required to support the storage needs of the virtualized environment as well as physical servers, the backup storage, and replication of data between sites. The network team has core, distribution, top of rack, and edge switches to support in addition to any routers or firewalls. And someone has to support the storage network whether it is IP, InfiniBand, or Fibre Channel. None of these teams has only the software-defined data center to support. The next logical question asked is: What does an organization look like that can support SDDC?
While there is no simple answer that allows you to fill a specific set of roles with staff possessing skill sets from a checklist, there are many organizational models that can be modified to support your SDDC. In order to modify an organizational model or to build your own model to meet your IT organization’s requirements, certain questions need to be answered. The answers to the following five steps will help shape your new organization model:
Define what your new IT organization will offer. Although this sounds elementary, it is necessary to understand what is planned on being offered in order to know what is necessary to provide support. Will infrastructure as a service (IaaS) be the only offering or will database as a service (DBaaS) and platform as a service (PaaS) also be offered? Does support stop at the infrastructure layer, or will operating system, platform, or database support be required? Who will the customer work with to utilize the services or to request and design additional services?
Identify the existing organizational model. A thorough understanding of the existing support structure will help identify what support customers will expect based on their current experience and any challenges associated with the model. Are there silos within that negatively impact customers? What skills currently exist in the organization? Identifying the existing organization and defining what will be offered by the new organization will help to identify what gaps exist.
Leverage what is already working. If there are components of the existing organization that can either be replicated or consumed by the new organization, take advantage of the option. For example, if there is already a functioning group that works with the customers and supports the operating system, then evaluate how to best incorporate them into the new organization. Or if certain support is outsourced, then incorporate that into the new organizational model.
Evaluate beyond the technical. The inclusion of service architects, process designers, business analysts, and project managers can be critical to the success of your new organization. These resources could be consumed from existing internal groups such as a central PMO. But overlooking the non-technical organizational requirements can inhibit the ability of the IT organization to deliver on its service roadmap.
Create a new IT organization. Don’t accept the status quo with your current organization. If the storage, compute, and virtualization teams all report through separate management chains in the current organization, the new organization should leverage a single management chain for all three teams. Removing silos within the IT organization fosters a collaborative spirit that results in better support and better service offerings for customers.
Although there is no one size fits all organizational model for the software-defined data center, understanding where your IT organization is currently and where it is headed will enable you to create an organizational model capable of supporting the service roadmap.
==== Tim Jones is business transformation architect with VMware Accelerate Advisory Services and is based in California.
By definition a service is a means of delivering outcomes that a customer wants to achieve, so it’s important not to forget where these outcomes originate in order for IT to be customer-focused.
Transforming IT from a technology-oriented to a services-oriented organization is at the heart of IT service management. The “specialized organizational capabilities for delivering value to customers in the form of services” must be developed, refined, and continually improved with business outcomes in mind.
If IT is working well, with a true service orientation, your customer will see that:
IT actions align with the business, particularly in ways that help the business serve external business customers
IT costs are controlled and reduced wherever possible
Quality of end-to-end IT services is improved
IT agility in responding to business needs is improved
IT is focused on customer results
Prioritization of IT expenditures and actions is based on business priorities
For the IT organization, this service orientation starts with defining what constitutes a “service” in the context of the particular business and cataloging all the services available. Then the resulting service catalog, and the full service portfolio of which it is a part, become the means of ensuring that IT and the business are always completely in synch around IT services and their value.
What your customers want from IT
When I work with IT organizations that are building their initial catalog of services, I’m interested to see who views whom as the “customer.” This is fundamental, however, since it is IT’s customer who defines value.
Frequently, service definition work is driven between particular IT groups, which can essentially put the entire effort within the boundaries of the IT organization, as illustrated in Figure 1. This can result in an internally focused view of the customer/supplier relationship. The focus is on supporting services, and parts of the IT organization itself end up being treated as “customers” of other parts of IT.
Figure 1 – Supporting Service Focus
Undoubtedly supporting services are important, since these are the building blocks that provide the capabilities that enable the customer-facing, outcome-oriented services. But they are not what the business is ultimately concerned with. Enumerating supporting services does not provide for the benefits the business expects – surely we don’t intend the service catalog to be limited to the IT organization!
Another approach I see my clients commonly take is to begin defining services that face the internal customers — the business — which establishes service catalog boundaries within the enterprise as illustrated in Figure 2. Services are defined as what IT does for the business itself, without reference to the external customers of the business.
Figure 2 – Internal Customer Focus
This approach reflects a critical step in the evolution of an IT organization’s maturity as a service provider. IT has begun to look at customer outcomes, with the customer being the business the IT organization serves. I believe such an approach can lead to a more coordinated, collaborative way of working within IT; the various IT groups focus their attention on end-to-end service provisioning, not merely on their own IT silos.
So while initial service catalogs often start with the existing applications and infrastructure and package that for customers, a best practice approach that I recommend is to begin with the outcomes that customers desire and define services based on them as illustrated in Figure 3.
Figure 3 – External Customer Focus
The truth is, there will need to be multiple cycles of service definition and re-definition that need to continue indefinitely, since customers’ desired outcomes and perceptions are under constant change.
Defining services from the top down, starting with external services, is also a recommended approach. But this is easier said than done, since it quickly exposes a need to define both internal customer-facing services and supporting services.
Accelerating the journey to IT as a Service This is the exciting part of being part of VMware. By establishing re-usable supporting IT services enabled by a software-defined data center and transformation road maps that make sure people and process changes are in place to realize the IT-as-a-service vision, I can help the IT organizations I work with to accelerate their ability to be truly customer-focused.
Many IT stakeholders have limited trust in the IT organization as a result of the way it has operated in the past. In this short video, Kevin Lees shares tips on how IT can deal with this real-world problem that is almost always overlooked.
This infographic distills data behind what’s driving the demand for IT professionals with cloud-related skills and why the hunt is on for top talent. Scroll through the entire image for a final section of lucrative careers and top companies hiring.
Many organizations on their journey to delivering IT as a service have chosen to adopt and implement VMware vCloud® Automation Center™ to automate the delivery and management of IT infrastructure and services through a unified service catalog and self-service portal. As this transformation requires a new IT operating model and change in mindset, a common challenge that IT organizations encounter is:
How do I define and package IT services to offer and publish on the service catalog?
This is analogous to a mobile operator putting together a new mobile voice and data plan that the market wants and pricing it attractively.
Here’s a possible approach to designing a service catalog for vCloud Automation Center implementation.
Service Model Service catalog is the new face of IT. It is a communication platform and central source of information about the services offered by IT to the business. It is also empowering users through an intuitive self-service portal that allows them to choose, request, track, and manage their consumption and subscription to IT services.
The first step to developing the service catalog and identifying the services within it is to understand the business requirements as to how these demands are going to be fulfilled — that is to develop a service model. For example, you could start with a business function — Sales — and then pick a business process — client relationship management (CRM). CRM can be further broken down into three domains: operational CRM, collaborative CRM, and analytical CRM. Each of the CRM systems can be instantiated in different environments (product, test, and development). Each instance is technically implemented and delivered via a three-tier system architecture. What you would get is shown below in Figure 1, which is a service model for CRM.
Figure 1. Service Model for CRM
Repeat the above steps for the other business functions. At the end of the exercise, you have defined service categories, catalog items, and service blueprints for implementation of a service catalog and self-service portal in vCloud Automation Center.
Service Catalog Using the above business centric approach allows you to define a customer-friendly service catalog of business services. The service categories and catalog items are in business-familiar terms, and only relevant information is presented to the business user so as not overwhelm him/her with the complexities of the underlying technologies and technicalities.
The business services are provisioned using service blueprints, which are templates containing the complete service specifications, technical service levels (e.g., RTO, RPO, and IOPS), and infrastructure (e.g., ESXi cluster, block or file storage, and network). The service blueprints allow IT to automate provisioning through vCloud Automation Center. To maximize business benefits and optimization of infrastructure resources, it is also important to establish a technical service catalog of technical capabilities and to pool infrastructure resources with similar capabilities. Then, vCloud Automation Center can provision a service via the service blueprint to the most cost-effective resource pool and providing optimal performance.
In summary, using a business-centric approach to designing your service catalog elevates IT to speaking in business terms and provides a whole new IT experience to your users.
——- Choong Keng Leong is an operations architect with VMware Professional Services and is based in Singapore. You can connect with him on LinkedIn.