Gauging cloud potential in an enterprise landscape

With already complex environments and new applications entering the landscape on a daily basis, enterprises are facing a lot of uncertainty in making the decisions that will allow them to best benefit from cloud technologies. Which business capabilities will benefit most from cloud applications or Hybrid Cloud Integration (HCI)? Which applications are the best candidates for cloud deployment?

This white paper introduces a decision-making framework to identify cloud-compatible business capabilities and cloud-candidate applications. It is a KPI-based, step-by step approach that considers the different service models (SaaS, PaaS and IaaS). A first assessment pass identifies the business capabilities that would best benefit from cloud-based IT support. A second pass examines and evaluates the currently existing or planned applications delivering functionality for these business capabilities to find cloud deployment candidates. The framework takes several dimensions into consideration, such as business acceptance, compliance requirements and data security aspects to assess if an application is a “good” cloud candidate or not.

Mid-sized and large enterprises suffer from enormous running IT costs. Despite best efforts to reduce operational expense, the ratio of operational costs compared to investments continues to run at a stubborn 59 percent of all IT (see Figure 1). This leaves little room for capital spend on IT support for new business initiatives. It’s no wonder renegade business units are finding their own IT solutions and undermining IT’s attempt to maintain control—or at least oversight—of the company’s IT. With this and the pressure to reduce overall IT costs, service providers’ promises of lower costs or the replacement of upfront infrastructure investment with a presumably low monthly bill is certainly tempting.

And these are not the only promises from service providers that are offering cloud solutions for enterprises. They claim that applications and infrastructure can be deployed much faster than with traditional approaches. Furthermore, they promise capacity “on demand” including taking over full responsibility for providing the necessary hardware and software. In short, a paradise for large IT organizations: fast deployment and unlimited scalability instead of longwinded procurement processes; lower operational costs instead of holding on to expensive skills and resources; and agility in providing needed IT services instead of resource gridlock.

Even more factors play an important role for cloud consideration. First, how palatable is a cloud-sourcing strategy to the business? Does the business agree with the hosting of business-critical applications by third-party service providers? Second, and even more critical, is the topic of data security. The near-, on- or off-shore activities of large companies show that legal requirements and operational practices must be considered when implementing a cloud strategy. Avoiding Software-as-a-Service (SaaS) for critical or sensitive data remains a significant form of risk control for many organizations. Third, how viable is the technological offering and how compatible is it with the current technology strategy of the enterprise? For instance, in a Platform-as-a-Service (PaaS) situation, can the established application platform be supported in such a cloud deployment or will it require a platform redesign? Will a cloud deployment involve technologies that had been banned in the enterprise for valid reasons? Can the same technology platform be used across a larger number of applications thus creating additional economies of scale?

First, let’s ensure we have a common understanding of the basic terms that are used in this decision framework.

The next three paragraphs refer to cloud infrastructure usage models as discussed in “The NIST Definition of Cloud Computing—Recommendations of the National Institute of Standards and Technology”:¹

Software-as-a-Service (SaaS):

The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email) or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Platform-as-a-Service (PaaS):

The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including network, servers, operating systems or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.

Infrastructure-as-a-Service (IaaS):

The capability provided to the consumer is to provision processing, storage, networks and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).

Furthermore, we define here an “Application” as a fully functional integrated IT product that provides business functionality to end users and/or to other applications. As such, an application supports the business to accomplish its mission.

In addition to this, we also need to define the term “Business Capability”: A business capability is an abstract description of “what” needs to be done in an enterprise to meet its business objectives, support the business model and implement a viable operating model. Business capabilities prescribe a view of the enterprise based on business activities that are independent of specific business processes and organizational silos—silos according to product, channel, customer, geographical and informational lines as is the case in most organizations today. A business activity view enables the enterprise to identify and focus on activities that are critical to business success and where they can achieve differentiation in delivery—be it cost or value–unfettered by historically given circumstances.

1. Peter Mell, Timothy Grance: The NIST Definition of Cloud Computing—Recommendations of the National Institute of Standards and Technology. NIST Special Publication 800-145.

Even mid-sized enterprises usually have at least several hundred applications in use, while large and global enterprises may easily have several thousands of applications they are working with. It’s just not feasible to simply proceed on an application-by-application basis and evaluate the cloud potential for each of the applications in detail. Such an evaluation would be prohibitively time-consuming and expensive. A step-based approach to identify promising cloud-compatible business capabilities and cloud candidate applications by using key performance indicators (KPIs) is much more practical. This methodology results in a sub-set of business capabilities and consequently existing or planned applications that should be evaluated in further detail for their cloud potential as the “low-hanging fruits.”

As shown in Figure 3, the approach has five steps with steps 4 and 5 generating final results. Step 3 provides only intermediate insight requiring further investigation to determine how much of the application landscape currently supporting a candidate business capability can be replaced with the SaaS offering at hand. In other words, SaaS offerings should not be limited to a perspective of replacing just a single application but considered as the premise for the transformation of an entire segment of the application landscape.

Step 1: Identification of relevant business capabilities

The first pass of the assessment starts with the set of all business capabilities of the enterprise at a given level of detail (usually level 2 or 3 within the hierarchy of the business capability map). It is conducted with the following three indicators:

• Change strategy is a qualitative indicator and values are provided by the business strategist. It specifies if the business strategically wants to change the business capability to, for example, invest more into new functionalities or simply reduce costs by providing existing functionalities more cost effectively. This indicator scores a capability as to the amount of change needed.
• Market differentiation is a qualitative indicator, comparing the business and operating models of the enterprise with its competitors. It specifies how unique the business capability is or should be in order to compete effectively. For example, most enterprises will evaluate support capabilities such as “logistics” with a rather low value for market differentiation. However, if the enterprise is a logistics provider, it will consider “logistics” a top-level business capability and give some of its subordinate business capabilities a high value for market differentiation as these are fundamental for the competitive positioning in the market. This indicator scores a capability as to its potential for differentiation.
• Application costs is a quantitative indicator on the business capability. It can be derived from the summarized cost of the applications (e.g., for the last year) that are associated with the business capability. If this information isn’t available an estimate is useful too.

Using an algorithm to aggregate the three KPIs for each capability results in a relevance score–an ordering where capabilities with the lowest market differentiation and the highest change strategy are at the top positions. Within these top positions, capabilities with the higher costs are positioned at a higher position than those with the lower costs. Here is the rational of the relevance score:

• The search should focus on business capabilities which have a high need for change since this is where business is willing to spend money for improvement—improvement that could be delivered in a cloud-based solution.
• Business capabilities with a high market differentiation should be positioned towards the bottom since they tend to be critical for the enterprise strategy. Putting such applications into the cloud creates potential risk and, thus, requires a detailed analysis of their cloud capability. Coming to a decision may already be a considerable investment.
• Finally, business capabilities with identical relevance scores are sorted by application costs based on the observation that more expensive applications typically result in higher savings opportunities when turned into a cloud deployment.

With these definitions, the set of relevant business capabilities can be derived. Depending on the overall strategy, it might be valuable to be quite restrictive—for example, by removing business capabilities with very low application support costs to avoid spending time and resources optimizing the application support for business capabilities with an acceptable cost/performance ratio.

Step 2: Identification of cloud-compatible capabilities

The list of relevant business capabilities can be further reduced by applying another assessment measuring the cloud compatibility of the business capabilities. The following indicators are used for this assessment:

• Cloud potential is a qualitative indicator to be provided by the architecture team for the business capability. It represents a rough estimation with regards to how much technical potential the architects see in migrating some of the existing or planned applications. For example, some business capabilities might deal with critical data resulting in a reduced cloud potential. Other business capabilities might benefit from a fresh look at standard functionalities as the applications may no longer be meeting commonly accepted standard practice. This indicator scores favorability for cloud deployment.
• Cloud affinity is a qualitative indicator to be provided by the business owner of the business capability. It represents the affinity of the business towards the idea of supporting the entire business capability or significant parts thereof with cloud technology. For example, for some business capabilities business might see great potential for improvement of the reliability and scalability of relevant business processes at an acceptable cost by moving applications into the cloud. This indicator scores cloud affinity.
• SaaS offers is a quantitative indicator representing the availability of related SaaS offers in the market. At this point, a detailed assessment of fit and suitability for such offerings is not of primary relevance. Rather, the focus should be on the number of offerings available and known to the architecture team.

This results in a view of the business capabilities in top positions that match a solid technical perspective with qualified business expectations. As a consequence, these business capabilities warrant the efforts of taking a closer look at the applications associated with these capabilities. This selection approach will also help avoid resistance from business and architecture stakeholders. Similar to the approach in the preceding step, the costs for the applications associated with a business capability are used as secondary sort criterion.

With these definitions the set of relevant business capabilities can be derived. At this time the indicator qualifying the availability of SaaS offerings has not been used. It will be included in the assessments of step 4 helping to discern business capabilities with viable SaaS offers from those where such offers do not exist.

Step 3: Identification of cloud-candidate applications

The first pass of the assessment starts with the set of all business capabilities of the enterprise at a given level of detail (usually level 2 or 3 within the hierarchy of the business capability map). It is conducted with the following three indicators:

• Cloud affinity is a qualitative indicator provided by the business owner for an application. It represents the affinity of the business towards the idea of replacing/ reimplementing the application with cloud technology.
• Affecting regulations is a qualitative indicator provided by the business owner in cooperation with the application architect for an application. It represents the impact of compliance rules and regulations on the application. Such rules are often derived from national or international laws like the “Sarbanes-Oxley Act (SOX)” in the US, the “Bundesdatenschutzgesetz (BDSG)”, the EU MiFID directive or the “Basel Accords (Basel I, II, III)”.
• Usage variations is a qualitative indicator representing the variations in usage of an application over time. It captures the difference in load levels resulting from the use of the application during peak usage periods and low usage periods. This assessment will likely require the use of a proxy measure like user count, transaction number, process execution frequency, etc. The indicator defines the difference between low and peak usage loads.
• Data classification classifies the data and content of the application and should be provided by the application architect. It is a qualitative indicator whose score represents the processing and storage of “strictly confidential or personally identifiable information,” “personal information,” confidential information,” “internal information” and “public information.”
• Interface density reflects the number of interfaces of the application as a qualitative indicator. This indicator is provided by the application architect.
• Functionality gap is evaluated by business and specifies how the business perceives the functionality of the application. Does it satisfy all needs or are there issues open which should be addressed in the future?
• Scalability gap is evaluated by the application architect and specifies perceived scalability of the application. It is a qualitative indicator.
• Incidence risk is evaluated by the application architect and qualifies the number of incidents tracked for an application. It aims at comparing the application to the rest of the application portfolio. Provided exact counts are available, a percentile-based categorization of applications is recommended.
• Operational costs is a quantitative indicator on the application representing the cumulative cost of the application (e.g., for the last 12 months). If this information is not available an estimate.

The aggregation of these indicators results in a cloud candidacy score that is high if the following is true:

• Applications with a high cloud affinity value are more favorable than those with a low cloud affinity.
• Applications heavily affected by regulations are bad cloud candidates because adherence to regulations is more difficult to control for applications deployed in the cloud. Therefore, applications with a low score for affecting regulations are rated higher.
• Applications with a high usage variation score are more favorable than those with flat usage patterns as they can benefit from the flexibility and ease of scaling cloud environments provide.
• Applications with tight data security constraints, i.e., a low data classification score, are less favorable than those which process and store only public information.
• A large number of integration touch points complicates the deployment in a cloud environment. Hence, a lower score for information density is favored.
• Migrating applications into a cloud environment might be more palatable if business users are not satisfied with the incumbent functionality. Hence, a high value for the functionality gap results in a higher rating.
• Ease of scalability is one of the more important arguments for cloud deployments. Consequently, a high value for the scalability gap results in a higher rating.
• High incidence rates result in business disruption and business user dissatisfaction. Hence, a large value for the incidence rate is considered favorable for the cloud candidacy assessment.

Step 4: Find business capabilities with SaaS potential

The assessment of business capabilities for their cloud compatibility and the evaluation of associated applications for their cloud candidacy in the previous two sections are combined to identify those business capabilities that demonstrate a high potential for a SaaS-based deployment of a standard software offering (either completely or partially). The resulting business capabilities should be funneled into a more thorough assessment as often associated applications support multiple business capabilities. Thus, the replacement of functionality required for one business capability may result in the carve-out of that functionality from an application rather than a complete retirement of the latter. To identify capabilities with SaaS potential, an additional SaaS potential score is defined for all business capabilities with SaaS offers available and known. The indicator is computed as the average of the cloud candidacy scores for all applications assigned to the business capability.

Business capabilities are ordered by the SaaS potential score. The business capabilities with the highest SaaS potential scores should be subject to a more detailed analysis. Specifically, those applications associated with the business capabilities showing the highest cloud affinity should be further inspected and assessed to determine which, if any, of the SaaS offers available in the market for this business capability would provide for a sufficient match in functionality provided. This would necessarily be the subject of a separate assessment project requiring a notional amount of funding (typically a few person-weeks).

Step 5: Find applications with PaaS or IaaS potential

For a PaaS/IaaS assessment, the technical characteristics and risk profiles of the applications are the dominating factors. Here you would consider the applications from step 3 that have proven to be not suitable for SaaS. The applications with higher operational costs should be favored due to the cost reduction potential of a PaaS or IaaS solution. Top-ranking applications in the resulting list should be analyzed in more detail to determine whether a reimplementation or re-design of the platform are required for a PaaS or IaaS deployment and if so whether the cost would be warranted by the expected savings and gains in scalability and reliability.

An enterprise architecture and portfolio management tool such as Software AG’s Alfabet can support, orchestrate and govern the execution of an assessment of business capabilities and applications for cloud potential. As a collaboration platform for planning, the tool connects the many stakeholders contributing to the assessment, relaying a common set of terms and definitions, and fostering a commonality in the approach across this widely distributed and often disconnected set of stakeholders. Many enterprises with a business IT management foundation use business capability maps as a means of communication between different business stakeholders as well as business and IT departments. Thus, the cloud potential assessment discussed in this paper can leverage the existing set of business capabilities and align to a common set of semantic terms. Furthermore, some of the indicators used in this assessment, like operational costs for applications or market differentiation and change strategy for business capabilities, are likely to already exist for other purposes like strategy or program portfolio management.

Alfabet supports the process of gathering the assessment data for the various objects. The roles of application architect for applications and business analyst for business capabilities are standard elements in the Alfabet information model, providing for an automated identification of these critical stakeholders and automated assignment of the relevant assessment tasks to them. Automated status, completion tracking as well as built-in reporting support the project manager for the cloud potential assessment throughout this process, making sure it is completed in a timely manner and generating actionable results.

Finally, Alfabet provides a powerful set of reporting capabilities to help aggregate information, contextualize it with other decision relevant information elements and present the results in a form that is readily usable for decision-making by senior managers. Alfabet also supports the communication of the decisions made, thereby resulting in higher reliability and traceability and assuring necessary actions are put into motion.

This paper has presented a step-based methodology to identify cloud-compatible business capabilities and cloud-candidate applications. A step-based approach is recommended for two reasons: First, it allows elimination of ill-suited objects early on, thereby reducing assessment efforts considerably. Second, it considers business capabilities and applications separately since SaaS solutions should be considered and evaluated from the perspective of business capabilities while PaaS and IaaS solutions are more capability-agnostic and technology-oriented, thus focusing the discussion on applications. A concluding outlook outlined how this assessment approach can be fully supported and orchestrated in an enterprise architecture and portfolio management solution like Software AG’s Alfabet.