Blue glowing high energy plasma field in space, computer generated abstract background
Uncategorized

Deciding How or Where To Source/Host Applications

The previous post is intended as a starting point for a discussion about where the real value, not just the cost, is in IT for organizations.  Ultimately it is the organization that has to decide, but IT can now think about a roadmap for how and where to source IT services, and how it transforms itself into a value center.

 

The diagram below shows one approach to working out the desired end point for any given application or service.  It requires that a small number of critical questions be answered by the enterprise.

 

As a prerequisite the organization must be clear about its core mission(s) and how/if it seeks to differentiate itself?

 

Then for each application or IT service that the enterprise uses, we can ask…

 

  1. Does the application enable the organization through non-functional differentiation?  Does the quality of service (scale, performance, availability, security, cost or whatever) of certain applications uniquely enable success?
  2. Does the application enable the enterprise through functional differentiation?  That is, does it do something that is non-generic or highly customized?  Does it include intellectual property or ideas that are unique in some way, or behave in a way that enables the organization to succeed or compete better?
  3. Can the service be externally hosted?  Does it include functionality, state or data that for regulatory compliance or security purposes mean that it must reside within the organization?

 

Asking these questions of each application that supports the business, in the right order, can provide insight into how the service might ultimately be sourced.


Decision Flow.png

Figure 1 – Deciding how to deliver a given service

 

So, in detail, for any given IT service…

 

Almost all services should be candidates for being sourced from, or deployed on either public or private Clouds, and indeed a Cloud solution should (in the long run) be considered the default solution.  The only exceptions should be those services where the performance, scaling, availability, security or other non-functional requirements simply cannot be met with a Cloud (private or public) solution.

 

Thus the first question is – “Is the organization differentiated by the superior performance, scaling, availability etc. of the service?”, i.e. non-functional differentiation, that cannot be achieved by running on a Cloud (public or private).  Cloud is enabled through simplification, very specifically hiding the details of the infrastructure, platforms or software that support a service. If a service is differentiated through performance etc. then whoever provides it might need to understand how it is mapped onto other services or infrastructure.   This used to be the case for many, or even most services, where manual tuning of servers, storage and networking, and the specific layout of the network and storage was critical to enabling performance and scaling.  However, with the proliferation of cheap, commodity, and yet high performing hardware, the pervasive adoption of reliable virtualization technologies that rarely negatively impact outright performance, the emergence of converged fabrics, and of newer application architectures, this is becoming less frequently the case.  Nonetheless some services still end up having to be run on more or less dedicated custom (traditional) infrastructure, although as time passes they are becoming an ever smaller proportion of the whole set.

 

Note 1 – Just because an application falls into this bucket today, doesn’t mean it will tomorrow!  Thus service owners should be investing in architectures and technologies (virtualization, automation) that will allow them to migrate these services to Clouds in due course, when their non-functional requirements are met.

 

Note 2 – And of course these services, whilst not running on Cloud infrastructure or platforms, may nonetheless be presented as Cloud PaaS or SaaS offerings.

 

Note 3 – In some cases the non-functional differentiation may be agility itself, which may be gained through the use of Cloud. Differentiation through agility based on Cloud adoption may be true in the short term, but is less likely to be true in the longer run, as Cloud services become ever more widely adopted.

 

The next question to ask is whether the service’s functionality enables the business to differentiate itself.  Things like packaged applications that are not overly customized, tend not to.  They support, rather than enable, the business, providing similar or identical services to most, if not all, organizations that deploy the service.  Examples of this kind of packaged application include Human Resources applications, Payroll applications, email and so forth.  More complicated packages, such as CRM or ERP may or may not fall into this category, depending on the level of customization.  For example if a business is genuinely differentiated by aspects of its logistical operation, then parts of the ERP solution may be considered differentiating, custom applications.  Indeed they should probably be developed by the business and treated as services that run on an ERP platform as a service, if possible.  Anyway, if the service does not truly differentiate the business then it should probably be thought of as a commodity and provided either as a Software as a Service (SaaS) offering from the public Cloud, if considered secure and compliant enough, or otherwise as a minimally customized, packaged application deployed on internal Infrastructure as a Service (IaaS)

 

Having tackled the services that are differentiated by their service level, and those whose functionality does not differentiate the organization, we are left with the custom services that provide functional differentiation.  These tend to fall into two categories – those that run as part of a shared services platform and those that run in silos or are in fact self-contained.  For most organizations, there is a strong desire, and great benefits to be accrued from moving towards a shared services implementation.  But if they do not wish to, or if an interim solution is required, then the initial option will be to deploy on public IaaS Clouds, where regulatory compliance and security constraints allow, or on private IaaS Cloud infrastructure where they do not.  For those services that do take advantage of a shared services architecture, the natural trend is toward turning this into a Platform as a Service (PaaS).  This may be internally or externally hosted, depending on compliance and security concerns.  Note that PaaS implementations may or may not be custom, i.e. they may or may not expose custom shared services that are unique to the organization.

 

Of course, every organization’s journey will be different, based on their starting point and their history. And with a potentially confusing array of opportunities presented by Cloud, it remains critical that organizations step back and take the opportunity to work out what they want to become.  Ultimately Cloud is about opportunity, and not just about technology.   In the same way that the Internet provided organizations with global access to markets to sell their goods and services, or global access for public organizations to engage with people, the Cloud provides organizations with the ability to source their IT services as commodoties, from almost anywhere.  The barriers of entry to creating enterprises, to innovating, to delivering new value quickly, to being competitive or to transforming organizations are being swept away! 

Comments

Leave a Reply

Your email address will not be published.