People, process, organization and governance for the software-defined data center

Monthly Archives: October 2014

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 DifficultIt’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.

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

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

Targeted services:
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.

Effective communication:
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

Target consumers

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.

The definition of SDLC is changing. SDLC often stands for the “software development life cycle,” a methodology to develop and implement software, currently in use by many IT organizations. IT organizations have realized, however, that this narrow focus on software is insufficient in today’s IT service delivery.

Figure 1: The SDLC Continuum

In my opinion, the next logical evolutionary step for an SDLC is to look at a “solution development life cycle,” which not only considers functionality requirements for the software, but also requirements for the underlying hardware and infrastructure systems, such as storage or networks. Solution development focuses on a more complete solution, but there is still further to go in maturing the approach. Ultimately, SDLC should really stand for “service development life cycle,” with a goal of developing, implementing, maintaining, and supporting all aspects of an IT service in order to bring real value to IT customers.

Software Development Life Cycle
Project teams often use a form of a software development life cycle to provide functionality in the form of software to users. The goal of the SDLC in this form is to use repeatable, predictable processes that improve software development productivity and software quality. Project teams will commonly incorporate aspects of project management frameworks into the SDLC, because without effective project management, it is very easy to deliver software projects late and/or over budget.

This approach to SDLC typically uses a methodology that will take the software development through multiple phases, such as planning, requirements, design, building, testing, deploying, and maintaining. The phases may be organized in a waterfall model, in a spiral model, or a combination of the two. Additionally, project teams may incorporate rapid application development or agile methods, such as SCRUM. There are a number of publicly available standards that can be applied to the SDLC, such as ISO 12207 (the international standard describing the method of selecting, implementing, and monitoring the life cycle for software), as well as process improvement guidance, such as the Capability Maturity Model Integration for Development (CMMI-DEV) or ISO 15504 (Information Technology Process Assessment).

It is important to note that the software development life cycle is really only concerned with software functionality. The framework provides guidance for developing this functionality, regardless of underlying systems, such as servers or the network that the software will need to be functional. While the SDLC in this form might (and should) be describing the requirements for such systems, the provisioning of such systems is typically not a part of this form of the SDLC. This does not necessarily mean that these requirements are not addressed at all, but typically the project team deals with them in a very separate way. This can potentially lead to miscommunication and a lack of coordination between different groups, and eventually to poorly delivered results. Another pitfall in such an approach is that the infrastructure side is done in an entirely ad hoc way, which can lead to struggles for the project team to be forced to fix things up in production, or severely under-performing services, because the infrastructure cannot support what is truly needed.

Solution Development Life Cycle
In a solution development life cycle (sometimes also known as systems development life cycle), the scope of the methodology is expanded from a narrow focus on software functionality to include the underlying systems, such as hardware and infrastructure. The SDLC in this form is seen as a process to develop an information system, aiming to produce a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, and is inexpensive to maintain and cost-effective to enhance.

The solution development life cycle approach will be similar to the software development life cycle, in that phases for requirements, design, development, building, testing, deploying, and maintaining will be defined by the project team, and in that guidance from project management methodologies or process improvement methodologies can also be incorporated. However, the focus here is still on providing software functionality to users and customers at a given point in time, and not business value in the form of delivering ongoing services.

The benefit of a solution development life cycle over a software development life cycle is that requirements for underlying systems are defined along with requirements for software functionality, and the entire solution will be developed, thus reducing the risk that these underlying systems can derail the delivery of the desired functionality late in the life cycle. The solution development life cycle therefore ensures a more complete view of how the software functionality is delivered, thereby improving the user experience.

Service Development Life Cycle
Further maturing the SDLC leads to a true service development life cycle, which, while still concerned with the software application(s) needed for success, focuses on the definition, design, build, operation, and improvement of a complete IT service, providing outcomes that customers want to achieve. This view is much bigger than the view being taken in the software or solutions development life cycle. The central idea is for the project team to figure out the end results that their customers need to accomplish and then deliver and manage IT services to achieve those outcomes. This holistic approach requires the team to consider not only the technical aspects of the service, but also the non-technical aspects such as training, documentation, support, communications, or processes.

For Example…
Here’s an example to further illustrate the difference between these three approaches. Let’s take a look at a payroll application. When using software development life cycle methods, the project team’s focus is on functionality provided by the application. For instance, an improvement to the payroll application might be to expand state tax calculation from handling a single state to also include other states, because the company will now also open offices in more states. The focus is solely on the calculations in the software.

Moving to the solutions development life cycle approach, more aspects are looked at for this change. Since adding this functionality most likely means more users and more employee records being managed by the application, the project team would also consider additional space requirements for the database storing the information about employees, additional network bandwidth that may be required for additional users, and more CPU power being needed for those users.

Taking a service development life cycle approach would require that the project team understand the outcomes customers want to achieve (e.g., “process payroll for all employees”), taking a holistic view of the current IT service landscape, and then determining how those outcomes can be best achieved within that landscape. Besides just application functionality, other aspects of service delivery come into focus, such as availability or continuity requirements, training, support, and even marketing new capabilities in the organization.

In conclusion, the evolution of the SDLC takes us from the traditional “software development life cycle” with its focus on developing and implementing functionality provided by software to defining, designing, implementing, and maintaining services that provide value to IT customers. Doing so means expanding the processes and roles described in these life cycles to ensure this value can be realized.

====Kai Holthaus is a transformation consultant with VMware Accelerate Advisory Services and is based in Oregon. Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags

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.

About this Blog

This blog is for busy people who do things. And for people who make decisions about how to do things. It offers applied insights and lessons learned for IT infrastructure and operations professions responsible for building, managing and optimizing IT Operations in the cloud era.