CIO · Cloud

The difference between Hybrid and Multi-Cloud for the Enterprise

Cloud computing still presents the single biggest opportunity for enterprise companies today. Even though cloud-based solutions have been around for more than 10 years now, the concepts related to cloud continue to confuse many.

Of late, it seems that Hybrid Cloud and Multi-Cloud are the latest concepts creating confusion. To make matters worse, a number of folks (inappropriately) use these terms interchangeably. The reality is that they are very different.

The best way to think about the differences between Hybrid Cloud and Multi-Cloud is in terms of orientation. One addresses a continuum of different services vertically while the other looks at the horizontal aspect of cloud. There are pros and cons to each and they are not interchangeable.

 

Multi-Cloud: The horizontal aspect of cloud

Multi-Cloud is essentially the use of multiple cloud services within a single delivery tier. A common example is the use of multiple Public Cloud providers. Enterprises typically use a multi-cloud approach for one of three reasons:

  • Leverage: Enterprise IT organizations are generally risk-adverse. There are many reasons for this to be discussed in a later post. Fear of taking risks tends to inform a number of decisions including choice of cloud provider. One aspect is the fear of lock-in to a single provider. I addressed my perspective on lock-in here. By using a multi-cloud approach, an enterprise can hedge their risk across multiple providers. The downside is that this approach creates complexities with integration, organizational skills and data transit.
  • Best of Breed: The second reason enterprises typically use a multi-cloud strategy is due to best of breed solutions. Not all solutions in a single delivery tier offer the same services. An enterprise may choose to use one provider’s solution for a specific function and a second provider’s solution for a different function. This approach, while advantageous in some respects, does create complexity in a number of ways including integration, data transit, organizational skills and sprawl.
  • Evaluation: The third reason enterprises leverage a multi-cloud strategy is relatively temporary and exists for evaluation purposes. This third approach is actually a very common approach among enterprises today. Essentially, it provides a means to evaluate different cloud providers in a single delivery tier when they first start out. However, they eventually focus on a single provider and build expertise around that single provider’s solution.

In the end, I find that the reasons that enterprises choose one of the three approaches above is often informed by their maturity and thinking around cloud in general. The question many ask is: Do the upsides of leverage or best of breed outweigh the downsides of complexity?

Hybrid Cloud: The vertical approach to cloud

Most, if not all, enterprises are using a form of hybrid cloud today. Hybrid cloud refers to the vertical use of cloud in multiple different delivery tiers. Most typically, enterprises are using a SaaS-based solution and Public Cloud today. Some may also use Private Cloud. Hybrid cloud does not require that a single application spans the different delivery tiers.

The CIO Perspective

The important take away from this is to understand how you leverage Multi-cloud and/or Hybrid cloud and less about defining the terms. Too often, we get hung up on defining terms more than understanding the benefits from leveraging the solution…or methodology. Even when discussing outcomes, we often still focus on technology.

These two approaches are not the same and come with their own set of pros and cons. The value from Multi-Cloud and Hybrid Cloud is that they both provide leverage for business transformation. The question is: How will you leverage them for business advantage?

Business · Cloud

One theory on Amazon interest in a second headquarters

Amazon announced that they are in search of a location for their second headquarters. The new headquarters facility is expected to create 50,000 jobs and bidders are welcome to submit their proposals to woo the Amazon opportunity. While that, in itself, sounds great, there may be more in the works than just a new headquarters. Let me share my theory on what this may indicate.

THE LOCATION SHORTLIST

First, companies like Amazon do not go into major decisions like this without already having a pretty good idea of how it will end. There is just too much risk at stake. In this specific case, the physical location of the second headquarters. Prior to making the announcement, I suspect Amazon already done their due diligence and has an internal shortlist of potential locations they would accept.

When evaluating Amazon’s two core businesses, Amazon.com and Amazon Web Services (AWS), both rely heavily on technology. Therefore, a headquarters location must have a strong technology ecosystem that can support their separate growth trajectories.

While just about any major city in the US could support a new headquarters, tech-centric locations on the shortlist may include Silicon Valley, Las Vegas, Phoenix, Austin, Atlanta, New York or Boston. One outlier may include Washington DC/ Virginia. Why? As Amazon continues their spectacular growth, innovation and acquisition of competitors, it will need stronger ties to government in-circles.

So, which location? My theory is that the process is more of a formality and the decision is between a couple of locations that will come down to local/ state tax incentives. If true, the shortlist is a few locations less than outlined above.

IS A SPLIT ON THE HORIZON?

It is not common for companies to suggest a second ‘headquarters’ location. It does happen, but not often. There may be an undercurrent driving this move. Amazon has two core businesses; Amazon.com and AWS. Almost two years ago, Amazon announced that Andy Jassy would be promoted to CEO of AWS. This may be the first market in a longer-term strategy for Amazon.

One challenge Amazon continues to face is conflict between their core Amazon.com business and Amazon Web Services (AWS). Major customers of AWS continue to flee when Amazon.com moves into a competitive role. Essentially, Amazon.com gains are negatively impacting AWS. For example, Walmart is just one of the latest customers to do so. In the enterprise space, prospective customers have expressed concern that AWS (historically) is not Amazon’s core business. The distribution business is their core. Of course, in the past few years, AWS has grown significantly. However, it still presents a challenge. Splitting Amazon into two companies with Andy Jassy taking on new AWS entity could be the solution.

SPLIT DECISIONS

But there is a potential problem with splitting AWS from Amazon. When they operate as a combined company, Amazon is not required to disclose their significant AWS customers as they are not material in revenue to their core business. However, if the two companies were to split, this disclosure could be required and would bring focus to who AWS’ material customers are…in a very public way.

Now, if none of AWS’ customers are material, or contribute a significant amount of value (individually) to their financial revenue, this issue is not relevant. However, I suspect that Amazon.com is a major consumer of AWS’ services. And there may be a couple of other major customers.

If there are significant, material customers in the mix, it could present concerns among shareholders of AWS. Today, we don’t have clarity to this issue due to the economic halo effect of the core Amazon.com business. Splitting the companies brings this potential issue to light…and may be the reason Amazon has not split the two companies yet.

IMPACT TO SEATTLE ECOSYSTEM

The last driver may be the Seattle ecosystem itself. Seattle is a vibrant, technology metropolis that supports several major technology companies like Microsoft and Amazon. In addition, major companies like Boeing and Costco consume a significant footprint too. Big companies bring great opportunities and economic growth to communities. However, they can have a downside too. Cost of living increases, risk of losing a company, limited skilled people are all risks that offset the opportunities. One can look to the SF Bay Area/ Silicon Valley to see how this is playing out, how competitive it is for talent and how hard it is to relocate someone to the Bay Area.

It is probable that with Amazon’s success and growth trajectory, they may feel that the Seattle ecosystem is starting to become limiting or incapable of handing the entirety of a company like Amazon today and moving forward. If this were the case, I suspect the shortlist of potential suitors may not include Silicon Valley, New York or Boston.

MY TAKE

All that being said, my theory is that there is an impending split on the horizon for Amazon. The move of Jassy to CEO, AWS’ continued growth and secondary factors point to this as a possible outcome. That coupled with the ability for AWS having proved it can stand on its own without the core Amazon.com business further support the perspective.

I look forward to hearing what you think. Share your thoughts in the comments below!

CIO · Cloud

Is public cloud more or less expensive than corporate data center options?

 

img_1963

First a shout out to both Steve Kaplan and Jeff Sussna for encouraging this post. This post is a continuation from the post Eight ways enterprise struggle with public cloud and delves into the reasons why public cloud can be 4x the cost of corporate data centers.

Enterprises often look toward public cloud as a cost savings measure. Cost savings is the first stage of the enterprise maturity model leverage cloud. The thinking is that public cloud is less expensive than corporate data center options, right? Yes and no. Enterprises are learning the hard way that public cloud is not less expensive than corporate data center options. Why is that the case and can anything be done to change the outcome?

AN ANALOG MODEL

First, it is important to understand the differences in usage behavior between enterprise applications leveraging corporate data centers versus public cloud. An analog is the difference between buying a car versus renting it. In this analogy, the car represents infrastructure. Which is better? Which is less expensive? To answer those questions, one first needs to understand usage behaviors.

Scenario A

Assume for a minute that you were accustomed to purchasing a large car. Whether you used it every day or not, it would sit, running, ready whenever needed. Some days you only need one seat, while other days, you need all five seats plus lots of luggage space. In this model, you pay for the large car whether used or not.

Scenario B

Now, imagine those assumptions, but rather than purchasing the large car, it is simply rented. The large car is rented full time, running and ready whether used or not.

In Scenario B, a premium is paid for the ability to rent the car. Yet, the advantages of 1) renting the car only when needed and 2) renting the size of car most appropriately needed are lost. The large car is rented whether needed or not.

Like the car model, enterprise applications are built around a model that assumes the large car is available 24×7 even though you may or may not use all its capacity or every day. Enterprise applications are accustomed to purchasing the car, not renting it. Purchasing makes sense for this behavior. Yet, when moving enterprise applications to public cloud without changing the behaviors, the advantages of shifting the model from owning to renting are lost.

BEHAVIOR AND ARCHITECTURE CHANGES OUTCOMES

Changing the behaviors of the enterprise applications when moving to public cloud is the right answer to address this issue. However, that is easier said than done. Adding orchestration and automation within an application to leverage resources when needed and returning them when done often requires a significant architectural change or a complete application re-write. Both options are significant and work against any potential cost savings for public cloud.

Adding another wrinkle to the mix is that enterprise applications are architected to assume that infrastructure is always available. That means that redundancy and resiliency is maintained in the infrastructure, not the application. Public cloud infrastructure is not built with this redundancy and resiliency. Public cloud requires the application to carry the intelligence to address infrastructure issues. Shifting intelligence to the application is yet another significant architectural challenge for enterprise applications.

Note that these architectural changes bring added value beyond efficiently leveraging public cloud. Those changes include agility and responsiveness to an ever-changing business climate.

CAN ENTERPRISES STILL LEVERAGE PUBLIC CLOUD?

With these significant hurdles and those addressed in Eight ways enterprises struggle with public cloud, it is easy to see why enterprise public cloud adoption is relatively sluggish. Yet, CIOs still need to get out of the data center business and public cloud is a fine option for those applications that make sense. Between public cloud and corporate data centers, which model is ultimately better? It depends on the needs and behaviors of the applications along with the capability of the organization.

It is important to take a minute and think about the path to public cloud. It is also important to understand that not all roads lead to public cloud. Avoid the potholes, plan accordingly and leverage the benefits.

CIO

The difference between the Traditional CIO and the Transformational CIO

Over the past several years, the role of the Chief Information Office (CIO) has changed. If you are a CIO, do you know which type you most closely align with…or aspire to be? If you are working with a CIO, do you know the characteristics and why they are so important? The details are incredibly important regardless of your stakeholder status as a partner, customer, board member or fellow c-suite member.

The CIO’s job is hard and complicated. To gain a full appreciation of why, one needs to truly understand the anthropology of IT. That alone is worthy of a book. Suffice it to say that decades were spent creating the role of the CIO and IT culture. One cannot simply unwind decades of culture over the course of a couple of years. This is where my concept of the Three-Legged Race for transformation comes in. The CIO, IT organization and rest of the organization must work together for transformation to truly take shape.

THE TRADITIONAL CIO

When most of us think of a CIO, we are thinking of the traditional CIO. There are several characteristics that identify the traditional CIO. Many of the traditional CIO characteristics are centered around building an organization that supports technology. This makes sense, and fits well for organizations that have not started their digital transformation journey.

cio-characteristics-traditional

However, the role of the traditional CIO is in decline. As more organizations recognize the strategic value that technology plays, the demand for the CIO shifts from traditional to transformational.

THE TRANSFORMATIONAL CIO

The transformational CIO is a business leader first who happens to have responsibility for IT. To be clear, this does not mean a business leader that does not have experience leading IT. It means that the leader is highly experienced in leading business and IT, but focused on the business aspects as the driver for IT.

cio-characteristics-transformational

The characteristics of the transformational CIO are quite different from that of the traditional CIO. In general, they are business centric and less focused on technology. In many ways, unlike the traditional CIO, the transformational CIO is having the same conversations as the rest of the c-suite. Put a different way, if the conversation is not one that the CEO would have, neither would the CIO. Transformational CIOs are very much looking for business opportunities like that of the CEO or many of the other c-level executives. The transformational CIO is perceived by the other c-level executives as an equal. This is a dramatic shift from the traditional CIO. The key words here are ‘perceived by others’.

MAKING THE SHIFT FROM TRADITIONAL TO TRANSFORMATIONAL

At the risk of being over-inclusive, every enterprise will need to take the digital transformation journey. Technology is playing a more central role to every enterprise. Put a different way, technology is quickly becoming the strategic weapon for every enterprise. Think of companies that have disrupted different industries. In most cases, technology was central to their ability to disrupt their industry.

As part of that journey, every enterprise will need to rely more on a transformational CIO. However, that transition does not happen overnight. Recall that it is not just the CIO that must transition (read: Transforming IT Requires a Three-Legged Race). Transformation, much like culture changes, is a journey. There is no specific end-point or finish line.

cio-characteristics-full

One could ask, how does a CIO make the transition. For each CIO, the journey is incredibly personal and transformational in their own way. Shifting paradigms of thinking from traditional characteristics to transformational characteristics is not trivial. It requires re-learning much of what we have learned over several decades. Essentially, we are learning a new role. A new job. A new way of thinking. For those that do make the transition, the change is incredibly rewarding not just for the CIO, but the team they lead, the larger company they work for and ultimately the customers they serve.

DOES THE CMO OR CDO REPLACE THE CIO?

The transformational journey takes time, yet customers and executives want immediate change. How is this gap addressed? Speculation suggests that the Chief Marketing Officer (CMO) or Chief Digital Officer (CDO) will replace the CIO and fill the proverbial gap (read: The CMO is not replacing the CIO and here’s why.). There is value in the CMO or CDO filling some or part of the gap in the interim. However, over time, the transformational CIO is well equipped and best suited to address these changes. The gap, while significant, is only a temporary phenomenon.

CIO CMO Transforming IT

The time to start the transformational journey is now. Time is not your friend. With any organizational change, it is a team effort. It may start with the CIO, but will require the support and understanding of the entire c-level leadership team and IT organization. For many traditional CIOs, that is easier said than done. The best place to start is to establish a vision that sets the tone and cadence. From there, examples and success will quickly change the perspectives of those that may have been skeptical in the past. In addition, those that lead the transformation journey will find the process rewarding on many levels.

CIO

Shifting the mindset from projects to products

IMG_3492

A recent post on changing the language of IT is getting quite a bit of attention among CIOs. Continuing the theme around changing the language and culture of IT, we shift gears to the mindset of projects and products. For decades, the IT mantra has been to complete projects on-time and under budget. While this may have worked well in the past, moving forward it inhibits the very core of how we deliver solutions on many different levels. Let us take a look at this a bit deeper to appreciate the challenges in project thinking and opportunities that come from a mindset shift to product thinking.

THINKING LIKE A PROJECT

The very core of project thinking considers a discrete ‘thing’, which is represented as the project and has a specific start, end and deliverable. Project thinking brings significant focus to the deliverable and parameters that support the deliverable. That can be a good thing. However, in practice, it often means too much focus. Yes, there is such a thing as too much focus. Have you heard of the phrase “Can’t see the forest for the trees?” Some of the same principles apply here.

Part of the problem has to do with timeframes. Projects can last from weeks to years. The longer the project, the bigger the issue. Over a period of time, dynamics change. Companies change. Their needs change. Even the very reasons for starting a given project may change…or worse, disappear. Yet, many still get stuck in the mantra of delivering the project on-time and under budget. Even if that means that the deliverables are no longer relevant or the needs have changed.

It is not just the project thinking that needs to change. Projects do not happen in a vacuum. The way budgets are constructed, management is organized, and objectives are set all center around project based thinking. Like many things in the complex world of IT, projects are only one facet of a broader ball of yarn that needs to evolve.

THINKING LIKE A PRODUCT

A good alternative to project based thinking is product based thinking. Many of the same metrics for projects apply to products. The one stark difference is that products evolve over time. Put a different way, products are constantly evolving (or should be) to remain relevant. Projects are very different in this way.

The constant change of a product forces a shift in thinking around remaining relevant through the different phases of the product development and lifecycle. Even the terms shift to an evolutionary focus.

By changing the paradigm to a product based one, the thinking changes in two ways: 1) There is a constant awareness to remain relevant throughout the development and shifting gears as needed and 2) products have an ongoing lifecycle process versus the start/ end focus on a project. The product based thinking forces a whole new set of questions like: How long will the product be in use (lifecycle)? What choices are implemented now in anticipation of future versions of the product? These two questions have a dramatic impact on choices made in the current phase of the product.

MANAGING THE LIFECYCLE

The lifecycle of a product can be applied to any application or service within an IT organization and their portfolio. For example, take something as benign and simple as Microsoft Exchange email. If Microsoft updates Exchange every 18 months and it takes the IT organization six months to plan an evaluation and/or upgrade, then every 12 months an evaluation is started to determine if the service (email) is a) upgraded to the latest version of Exchange, b) migrated to a different solution or c) retired from service.

In project based thinking, one might only be focused on the upgrade of Exchange irrespective of the implications to the lifecycle. There are also implications to the IT application/ service portfolio, but that is a whole discussion on itself.

MISSING THE LOST OPPORTUNITY

Are projects bad? No. But they are missing a vital component that is a critical component of products: Context. Whether it is the time that resources are committed to a project or the cost to engage the project, there is a value component that comes with greater insight to context. A project might miss a significant opportunity while a product could seize the opportunity. One side benefit is that IT portfolio management becomes a whole lot easier using this methodology.

Shifting the mindset from project based to product based creates a significant shift in the IT culture and thinking that aligns more fully with business value. It creates agility and engagement in ways not possible with project based thinking. As business value shifts, so does the product. As customer needs change, so does the product.

Moving IT from a project based methodology to a product based methodology is yet another significant step in changing the language and culture of IT.

Business · CIO · Cloud · Data

HPE clarifies their new role in the enterprise

IMG_3755

Last week, Hewlett Packard Enterprise (HPE) held their annual US-based Discover conference in Las Vegas. HPE has seen quite a bit of change in the past year with the split of HP into HPE & HP Inc. They shut down their Helion Public Cloud offering and announced the divestiture of their Enterprise Services (ES) business to merge with CSC into a $26B business. With all of the changes and 10,000 people in attendance, HPE sought to clarify their strategy and position in the enterprise market.

WHAT IS IN AND WHAT IS OUT?

Many of the questions attendees were asking circled around the direction HPE was taking considering all of the changes just in the past year alone. Two of the core changes (shutting down Helion Public Cloud and splitting off their ES business) have raised many eyebrows wondering if HPE might be cutting off their future potential.

While HPE telegraphs that their strategy is to support customers with their ‘digital transformation’ journey, the statement might be a bit overreaching. That is not to say that HPE is not capable of providing value to enterprises. It is to say that there are specific aspects that they do provide value and yet a few significant gaps. We are talking about a traditional hardware-focused company shifting more and more toward software. Not a trivial task.

There are four pillars that support the core HPE offering for enterprises. Those include Infrastructure, Analytics, Cloud and Software.

INFRASTRUCTURE AT THE CORE

HPE’s strength continues to rest on their ability to innovate in the infrastructure space. I wrote about their Moonshot and CloudSystem offerings three years ago here. Last year, HPE introduced their Synergy technology that supports composability. Synergy, and the composable concept, is one of the best opportunities to address the evolving enterprise’s changing demands. I delve a bit deeper into the HPE composable opportunity here.

Yet, one thing is becoming painfully clear within the industry. The level of complexity for infrastructure is growing exponentially. For any provider to survive, there needs to be a demonstrable shift toward leveraging software that manages the increasingly complex infrastructure. HPE is heading in that direction with their OneView platform.

Not to be outdone in supporting the ever-changing software platform space, HPE also announced that servers will come ready to support Docker containers. This is another example of where HPE is trying to bridge the gap between traditional infrastructure and newer application architectures including cloud.

CLOUD GOES PRIVATE

Speaking of cloud, there is quite a bit of confusion where cloud fits in the HPE portfolio of solutions. After a number of conversations with members of the HPE team, their solutions are focused on one aspect of cloud: Private Cloud. This makes sense considering HPE’s challenges to reach escape velocity with their Helion Public Cloud offering and core infrastructure background. Keep in mind that HPE’s private cloud solutions are heavily based on OpenStack. This will present a challenge for those considering a move from their legacy VMware footprint. But does open the door to new application architectures that are specifically looking for an OpenStack-based Private Cloud. However, there is already competition in this space from companies like IBM (BlueBox) and Microsoft (AzureStack). And unlike HPE, both IBM & Microsoft have established Public Cloud offerings that complement their Private Cloud solutions (BlueBox & Azure respectively).

One aspect in many of the discussions was how HPE’s Technical Services (TS) are heavily involved in HPE Cloud deployments. At first, this may present a red flag for many enterprises concerned with the level of consulting services required to deploy a solution. However, when considering that the underpinnings are OpenStack-based, it makes more sense. OpenStack, unlike traditional commercial software offerings, still requires a significant amount of support to get it up and running. This could present a challenge to broad appeal of HPE’s cloud solutions except for those few that understand, and can justify, the value proposition.

It does seem that HPE’s cloud business is still in a state of flux and finding the best path to take. With the jettison of Helion Public Cloud and HPE’s support of composability, there is a great opportunity to appeal to the masses and leverage their partnership with Microsoft to support Azure & AzureStack on a Synergy composable stack. Yet, the current focus appears to still focus on OpenStack based solutions. Note: HPE CloudSystem does support Synergy via the OneView APIs.

SOFTWARE

At the conference, HPE highlighted their security solutions with a few statistics. According to HPE, they “secure nine of the top 10 software companies, all 10 telcos and all major branches of the US Department of Defense (DoD).” While those are interesting statistics, one should delve a bit further to determine how extensive this applies.

Security sits alongside the software group’s Application Lifecycle Management (ALM), Operations and BigData software solutions. As time goes on, I would hope to see HPE mature the significance of their software business to meet the changing demands from enterprises.

THE GROWTH OF ANALYTICS

Increasingly, enterprise organizations are growing their dependence on data. A couple of years back, HP (prior to the HPE/ HP Inc split) purchased Autonomy and Vertica. HPE continues to mature their combined Haven solution beyond addressing BigData into the realm of Machine Learning. That that end, HPE now is offering Haven On-Demand (http://www.HavenOnDemand.com) for free. Interestingly, the solution leverages HPE’s partnership with Microsoft and is running on Microsoft’s Azure platform.

IN SUMMARY

HPE is bringing into focus those aspects they believe they can do well. The core business is still focused on infrastructure, but also supporting software (mostly for IT focused functions), cloud (OpenStack focused) and data analytics. After the dust settles on the splits and shifts, the largest opportunities for HPE appear to come from infrastructure (and related software), and data analytics. The other aspects of the business, while valuable, support a smaller pool of prospective customers.

Ultimately, time will tell how this strategy plays out. I still believe there is an untapped potential from HPE’s Synergy composable platform that will appeal to the masses of enterprises, but is often missed. Their data analytics strategy appears to be gaining steam and moving forward. These two offerings are significant, but only provide for specific aspects in an enterprises digital transformation.

Business · CIO

Changing the language of IT: 3 things that start with the CIO

IMG_3184The Information Technology (IT) organization is going through a significant transformation. The transformation itself is not only disruptive, but confusing for many of the stakeholders including IT leadership, IT staff and those outside of the IT organization. Three years ago, I wrote about this in Transforming IT Requires a Three-Legged Race. The path through this tumultuous time is fraught with confusion, misdirection and significant potential for failure.

But fret not. As the top IT leader, the Chief Information Officer (CIO) is uniquely positioned to lead the organization through this transition. There are three things that will help turn the corner.

  1. REMOVE ALL REFERENCES TO ‘THE BUSINESS’

It is very common to hear IT staff referring IT and “the business” as if they are two different organizations. Unfortunately, this creates a culture of ‘us’ and ‘them’. As I discuss in Transforming IT Requires a Three-Legged Race, how IT refers to non-IT organizations is just as important as how non-IT organizations view IT. Today, they are seen very differently. That needs to change…and now. The CIO should see themselves as a business leader first, that happens to have responsibility for IT. Just this one mental change starts to create a waterfall of differences in both language and culture.

  1. DISCUSS VALUE IN MONEY TERMS…NOT TECHNOLOGY

Too many times, IT focuses on the value of change in terms of technology. And many times, IT staff find frustration in why business leaders do not understand their pitches. At the end of the day, the official language of the business is money. How does a change impact the organizations ability to change their financial picture? In the past, the focus for IT was on cost constraints (save money). Today, that has changed where IT provides greater leverage to business agility and economic growth. Note that both of these significantly leverage technology, yet neither mentions technology terms.

  1. FOCUS ON THE VALUE CHAIN OF THE CUSTOMER

There are many ways in which to discuss business agility and economic growth. However, neither are particularly important unless you first understand the value chain of the customer. To be clear, the customer here is the customer of the company…not internal users. When the CIO and IT starts thinking of itself as a business organization, so changes the perspective of who the customer really is. The customer, after all, is the one that provides said economic growth for the company. Ironically, IT is one of the few organizations in a company that historically has had limited interactions with the customer. That must change. In order for IT (and company as a whole) to succeed, the CIO not only needs to understand the customer, but also be engaged with the customer.

These three things provide a unique, but foundational shift in the way the CIO can impact change in their language and culture. Are these the only changes needed to impact transformation? No. However, these three represent a significant shift in the communications for the CIO and IT with other stakeholders.