5 Enterprise steps for adopting a Platform as a Service

  • Article

Most enterprises are being charged with a wholesale review of their applications and infrastructure to meet the hype, and sometimes reality, that is Cloud. It is my personal opinion that enterprise developers need to start their training, experiment and provide advice as soon as possible. However, in parallel, there needs to be consideration of an enterprise-wide structured approach to the architecture and the cloud.

As my esteemed colleague Tom Hollander states, the adoption of a PaaS may come about by both this top down approach as well as encouraging a bottom up approach of rapidly innovating and challenging the application norms. For example, the organisation may support a pilot cloud project even while the whole-of-enterprise approach to the cloud is still being defined. This can be a great way of gaining real-world experience to help inform the broader cloud strategy.

Simply moving servers though, from on-premise to off, I believe, ignores architecture and hence may lead to a solution that doesn’t provide the business with optimal efficiency and agility. The benefits of Windows Azure, a Platform as a Service solution, are realised by good architecture. Windows Azure is an exemplar of scale, agility, cost reduction, consistency as well an enabler for new business models. Theses benefits are consistent with the charter of architects within the enterprise.

A structured approach to cloud application architecture will help your organisation identity, plan for and prioritise your application portfolio. To demonstrate this I have put together 5 key steps to adopt a cloud application strategy:

Step 1: Share your enterprise architecture blueprint

Within your organisation you either have an emergent architecture or a planned architecture. Hopefully if you are in the latter category this is because you have an Enterprise Architect. An Enterprise Architect will have a responsibility, typically, to understand, quantify and model how your current applications interact with data created as part of operating your business. An artefact of Enterprise Architecture is an Architecture blueprint depicting data flows and dependencies between business units (rather than applications) and where the data itself resides.

Without a shared enterprise architecture blueprint your business may be inefficient in application adoption or ineffective in application impact.* See Enterprise Architecture as Strategy for more information and guidance on this wider topic

Step 2: Agree upon an strategic vision for your applications

Within your organisation you are likely to have objectives aligned to a business strategy. These strategies are likely to be in place to meet a business goal. For example to become the premier provider of financial advice in the superannuation business.

In order to implement these strategies effectively, the architecture team usually has a vision for how their systems could be better aligned to assist. Typically, this means you have some big bets on technologies and platforms that assist to provide the services the businesses need.

With a blueprint in hand, you will know where your data is coming from and what business functions and units depend on your application.  Each applications, naturally, will have different levels of internal efficiency and external collaboration and therefore different measures of competitive advantage.

The distinctiveness of applications within your organisation will have some common theme or thread. This could be around:

  • Connected - Applications are loosely or tightly coupled to others
  • Interoperability – Applications are able to be leveraged by other applications and users
  • Configurable – Applications can be modified and customised
  • User interface – A trend of specialisation towards one or multiple platforms
  • Channel – What partners and communications mechanisms does your organisation preference or depend on
  • Platform – What technologies do you or should you support that provides the greatest flexibility
  • Management – Where and who provides support and management for your applications

A strategic vision should be measured in line with strategic objectives. For example, standards compliance across 2 key browser types for all applications. It could be as simple as all application must register all logins with the operational management system.

Step 3: Map applications against business drivers for change

Some of your strategic vision may be complemented or overridden by pressing drivers for change. These drivers may arise from wider industry influences and simple market forces. Often there is too great an emphasis placed on technical detail and theory without due regard to these wider more significant business drivers.

I list here Mark Carroll's, 8 business drivers for change:

  • Tangible costs (How much does the product cost to purchase or maintain?)
  • Skills availability (How easy is it to get people to work on it or solve short term skills shortages?)
  • Customer requirements (Does it meet the stated business requirements? What about unstated requirements?)
  • Third party products and services (What sort of ecosystem and partner network is there for this product?)
  • Standards and Methodology fit (How will it fit with my business methods? How does it work with established standards?)
  • User Functionality requirements (How easy is the product to learn (i.e. discoverable)? Is there a consistent user experience/paradigm?)
  • Timeliness (What is the time from order to deployment? How quickly can it be modified or customized?)
  • Life expectancy (How long will the vendor be around? How long will they support the product for? Will there be a migration path to the next version?)

Add to this Policy (What legal and regulatory policies do I need to comply with?) and you have a framework to qualify which of your portfolio should be considered for change and therefore the cloud. If you are good (and often mature) at what you do and there is no reason for change (for example no cost benefit), then cloud is not for you. The business drivers emphasise importance of change,

Gianpaolo Carraro summarised at the recent Cloud Summit event, the value of change, in relation to cloud, as:

  • Operational efficiency
  • Enabling new business models
  • Competitive advantage / differentiation

At this step you should be able to justify or challenge a technology or architecture decision based off its importance and value to the organisation.

Step 4: Identify cloud application criteria

Knowing your architecture blue-print, your vision for applications, and which of those have a driver for change you should now have a subset of applications that now can be put into a list for legitimate exploration.

Presently I use three ways of establishing cloud applicability.

Evaluate

First of all I start with the full set of applications that have been identified as good candidates for the cloud. I ask a bunch of qualifying questions around risk including…..

  • Does this candidate for the cloud store Personally identifiable information or other data governed by privacy or security rules that may be difficult to meet in the cloud?
  • Would the applicable need significant changes to enable it to work in a scalable fashion?
  • Are there dependencies on applications that would require de-coupling in order to make available in the cloud?

Even though it may be possible to overcome these risks, you probably have a lot of applications that don’t have these challenges. In general it’s a good idea to aim for the low hanging fruit as you start planning adoption of the cloud, and leave the more complex scenarios for when you have more experience.

Context for change

Secondly I look at the context for change in step 3. Is the context for change compelling given the following question…

  • Is the change demand driven (typically driven by application usage) , supply driven (typically driven by cost of operation) or by a change in business model (typically a new application or component)?

Scenarios for change

Finally I use this information (non risky, high change) to map scenarios that the target platform (in our case Windows Azure) excels at. The following are three examples:

  • Application bursting

Here you can look at which applications can you keep in situ and can be extended to the cloud. Its worth noting here that there may still be compelling reasons to do this even if the usage patterns are pretty flat, for example DR or redundancy.

This is often the result of a demand based change.

  • New application delivery

Which applications could be better delivered in a way that is more agile or presents more options in line with our strategic vision (2). Examples of a new application could be a mortgage lodgement web service, a data market for , a service bus delivering payloads to multiple devices,

This scenario is often the result of a change in business model

  • Data storage

Whether its sheer volume, data archival or data migration and synchronisation there are many benefits of using data storage in the cloud. Not only is it likely to be cheaper but its likely to make your data more widely available and therefore query able. This reduces the burden of data delivery for your organisation whilst removing the intricacies of massive application scale. Windows Azure and SQL Azure present a plethora of options in this field (see this article for examples of when to use one of the other)

This scenario is often the result of a change or review of data and storage

Step 5: Assess your application

All my thoughts here may help you with context for the why. The how is provided by experts. Experts should be able to guide on how to implement, deploy and manage your application.

As assessment can provide you with ratification of your strategy or application portfolio. It can also help you implement the right design patterns and practices give you guidance on how best to implement the proposed changes to your application.Both Microsoft Consulting Services and our partners ( e.g. Readify Azure Assessment) provide assessment services, of various kinds and durations, that I would encourage you to investigate

Further Reading: Windows Azure for Enterprises

Just Beginning? Windows Azure Starter Page