The business aspects of cloud: Part 4 – Core versus context services

[#1]

In part 3, I talked about the importance for the CIO to become a strategic service broker. I mentioned the CIO will have to decide whether a service resides within the enterprise or is sourced from a public cloud. Let’s take a moment to look at the type of criteria to use in making such decision.

A couple years ago I heard Geoffrey Moore speak about “core versus context.” This is how he defines core: “My analysis in a nutshell is that core activities are those that increase the sustainable competitive advantage of a company. Core activities create value for customers in a way that is hard for competitors to replicate, and by doing so increase the market power of the company. Investors notice this, and reward the company with a higher stock price.” (I found the quote back on Roland Tanglao’s Weblog, the original document no longer seems available)

Obviously Moore recognizes that in the current world, core activities do not remain core very long as successful enterprises are often copied by others. Actually in a recent interview, he adds one important element: “Core is what allows a business to make more money and/or more margin, and make people more attracted to a business than to its competitors.  Core gives a business bargaining power: it is what customers want and cannot get from anyone else.”

And obviously, context is everything else.

Core services

So, my first rule of thumb is that core services should be kept internal. Indeed, even if we recognize competitors will try to mimic successful processes and approaches, we should make it as difficult as possible for them to do so. The “secret sauce” should remain secret.

This brings us back to the governance we discussed in part 3. Indeed, business and IT should jointly agree which services are core for the enterprise. This implies they understand what makes the company different and what attracts the customers. The processes and IT functionality supporting those activities is also core.

One more aspect to look into is that data may be core. Indeed, enterprises may gather and combine specific information elements, providing them a unique view of the way their customers behave for example. Such data should be considered core and treated in the same way as core services.

Context services

Does this then mean that all context services are delivered through public cloud service providers? That’s a little too fast as there are other aspects (technical, legal, security, etc.) that may require the service to be provided by the IT department itself.

So, rule two is that services using core data should be treated in the same way as core services, even if they are very standard in nature. This does not mean that the IT department has to develop those services. It might be able to acquire the appropriate software, but they should run within the IT environment. The only exception is if the data can be transferred to an external service provider and used by the service in a fully secure manner. Virtual private clouds may address such requirements, unfortunately, at the moment, most do not provide SaaS type services yet.

Rule three, for any other service, start from the point of view you will use a public cloud service provider, and then review if it is feasible from a technology, legal and compliance point of view. This will change your perspective and allow you to take what is probably the best decision for the service.

In a blogpost from 2008, titled “Proofpoint: Security, Compliance and the Cloud,” Eric Goodwin points out: “By outsourcing context applications such as email archiving to a SaaS provider, the burden on internal resources can be relieved, allowing them to focus on core systems and activities and ensure those systems are constantly improved and running at peak performance. At the same time, the customer benefits from the economies of scale, constant upgrades and high level of service that a SaaS provider can offer.” I tend to agree with him; however, his example of email archiving may not be the best one.

It will actually allow me to illustrate rule three. Indeed, in transferring email, there are a number of aspects that need to be taken into account. In particular, the legal elements have to be understood. Email contains privacy data, so, in which geography will the archive be stored? Who will own the email data once it’s stored there? Such aspects should not be forgotten. Actually, I always suggest companies to have a discussion with their lawyer prior to migrating email to the cloud. Lately BAE Systems refused to migrate their email to Office 365 due to legal concerns.

Conclusion

Technology is moving fast. The law takes its time to adapt. So, at the moment we have a discrepancy between a global IT landscape and local laws. This limits what should be done. In many situations, no ruling has yet taken place, so the interpretation of the law remains unclear. That’s why, in embarking on the decision of what services to keep in-house, reviewing decisions not just with the business, but also with the legal team is important. Remaining compliant is critical for successful companies. The last thing they want is a compliance scandal as it may ruin their reputation.

Core versus context is a good starting point to decide which services and data to keep internally. But other aspects have to be taken into account. The CIO, with his/her deep understanding of cloud, is critical in helping the company make the right decisions. 

[#2]

Hi Christian, indeed G.Moore uses core and context as nouns rather then adjectives - as your second reference to his concept shows. In such pure form it's actually much more powerful and we can reuse it for services, applications, processes, etc. and hence extremely appplicable in the hybrid world where the componentization is getting gradually adopted.

[#3]

You are absolutely right, the "core versus context" concept is not specific to cloud, and it was used in a more general perspective when G. Moore used it. I like it as it focuses attention back to what really matters. Now, as I pointed out it's not the only criteria, but it's in important one. In one of the next sections, I'll actually give an example how it can be used by a specif (dummy)  company. I hope that will bring the concept home. So, stay tuned.

[#4]

“Rule three, for any other service, start from the point of view you will use a public cloud service provider, and then review if it is feasible from a technology, legal and compliance point of view. This will change your perspective and allow you to take what is probably the best decision for the service.”

I respectfully disagree.  First I disagree with the premise of what you and Mr. Moore have defined as “Core Services”; Core Services could be a service that requires public participation and thus cannot be limited to being provided internally such as using a USDA database to make projections and estimates on rain and weather but still are necessary in creating your competitive advantage in combination with other data and proprietary information that is internal to the company.  Simply saying services that give an increased sustainability advantage over your competitor cannot be necessarily associated with being an internal service or not.

Next there are many different reasons in why a corporation should or should not use a public cloud service or create a private cloud service and act as an internal service provider to many different departments or separate organizations within a Global Multinational Corporation (GMN).  The reasons can be as varied as the type of organization it is such as Public Sector or Private Sector and are not just limited to compliance, legal, and feasibility.  I do not agree to the assumption using your definition of ‘Core Services’ or ‘Core Data’ should necessarily be considered as an internal service or that that a non ‘Core Service’ (again using your definition) should be considered an external Cloud service.  Many times the flexibility and control that is sustained over having a private cloud service out ways the cost benefits and TOC saved such as in a Collaboration or Knowledge Management solution.

In summary, defining if a service should be in a Public or Private cloud are not as easily categorized as defining whether it is just based as a ‘Core Service’ using your definition, and in my professional opinion corporations and government agencies should not initially assume to use a public cloud service over a private cloud service but instead should do an intelligent assessment from the very beginning without having a bias one way or the other when considering their options.  

[#5]

Robin, let me in turn respectfully disagree. I am not speaking about an "internal service" as in a service that cannot be accessed by external people/resources. I'm actually discussing where the functionality should be delivered from or where the data should be located.

Let me take your example. If you are building a competitive differentiator by better estimating rain and climate than your competitors, you have some information or algorithms they do not have. That is your competitive differentiator and that is the piece I would definitely put in a private cloud. Sure I would access external databases with the publically available ( non differentiating) data, but then run my analysis internal. I would not want that to be done in a public cloud where it is outside my control. 

If your core services require external access, for example, you consider core to your business the collaboration across your supply chain. Sure, you will give access to that service to your suppliers, but the information on how things happen in your supply chain should be kept under your close control. It's what makes your difference, your competitve advantage. 

The idea of using core versus context is exactly there to initiate a dialogue and allow companies and governments to thoroughly think through the functionality and information they have to identify what is key for them and what is "me too", in other words, what is core and what is context. You might want to take a minute going through the ACME corporation case study I discribe in a subsequent post of the same series

[#6]

Interesting conversation about core and context. If I would extend the reasoning of Moore, I would outsource the whole business model except what adds competitive strength. This is too simple to be practical.

On the other hand I like very much the three rules that "core if critical to the strategy" might be considered as non-outsourcable, and data should be kept inside and services using core data should be treated as core services . Thirdly there may be other constraints that impose internal delivery. If not, outsource. These are easy to handle criteria.

From a technology perspective Christian has given easy to use criteria for internal or public cloud.

From a business perspective the criterion is still to vague as Robin rightly argued.

To handle this more explicitly we need a rich reference of business needs. Services should be identifiable, and the context should be described so that business characteristics are well understood. This is feasible, and is even available as a service within HP. :-)

At The Open Group a standardized and formalized language has been agreed in 2011, and now this is rolled out and adopted as part of the business architecture strand in the HP Transformation Famework. It provides a concise but rich description of the business logic and business priorities, and is a perfect foundation to show the dependencies as Christian described: if a service uses data from a core service than ......

This would be a great service for clients, and of great benefit.

Harry

[#7]

It's funny to see people struggling with being able to define what is core from a business perspective. When I go and talk to customers, I often see that also. The point is not that the criteria are vague, the point is that most business people, immersed in their day to day operations, have difficulty answering a very simple question: "What makes your business being what it is?" or in other words, "What makes you different from your competitors? "

It's a fundamental question, but that we tend to forget in the middle of the day to day activities. Companies that focused defining where they want to differentiate actually are most often very successfull. They know what their core business assets are. 

Once you know that, things become easy. Which are the applications supporting these core business assets? What is the associated data? etc.

If I look at HP, what is key, its R&D and its Supply Chain. That made us what we are today. Sure we have other functions, but they are not significantly different then the ones of our competitors. 

[#8]

Hi Christian,

I can share your view, and I cannot as regards the difficulty people have to describe what is core and what is not. At the level 1 functional areas it may be simple. It ismore difficult defining it at level 3 or 4. And that is the level we need to touch I believe if cloud services may be introduced.

Usually a business is very capable to explain what is core and what is not. The challenge is to have it described and communicated in a way that other stakeholders - not involved in day to day conversations - do also understand its implications. And that goes into more detail than supply chain and R&D.

Or, would you be able to attribute cloud services based on this high level statement? I am not sure whether that would be feasible. You may comment on this.

Having done this type of analysis for a long time, I have come to appreciate that richness in communication pays off. And, that is what usually stakeholders are not capable off.

An eample: at a high tech company I was involved in developing the architecture capability with the CIO. For this I was very interested of course in how that company did its business. When waiting at the reception desk to be attended by my host, I found the annual report in which the business strategy and logic had been described in a very concise and rich way. When I asked my sponsor whether he knew that, he did not. The IT domain stakeholders did then also read this document, but could not make sense from it in their own reality. That is why a controlled way to show them implications of the business logic for business and IT services adds so much value.

My 2 cents, Harry