At IBM, I am often requested to help evaluate an existing business model and provide innovative ways to transform the business from a technical architecture perspective.  This involves focus on several areas, but it inevitably comes down to a transition from on-premises to cloud in order to facilitate an agile, adaptive environment that can deliver results quickly, while cutting costs.

Cloud has a lot of benefits, but when transitioning from an on-premises solution, you must consider several components to weigh the pros and cons.  While ultimately, your decisions will depend entirely upon your business needs, here are the broad things to consider that are common across all solutions:

Deployment Capabilities

  • On Premises: There is typically a deployment team in-house that you must coordinate with in order to update code, install patches,  and handle any changes related to the physical servers.  Quite often, this becomes the slowest path to get changes deployed because of coordination between team and scheduling of the deployment during change windows, for example once per month in the middle of the night on a weekend. Provisioning of new resources could take anytime from a few weeks to a few months to add to the existing infrastructure
  • Cloud: In a public cloud environment, resources are hosted by the cloud service provider, but enterprise focals can access and adjust those resources at any time. The result of this approach is the ability for developers to have more control and realtime deployment strategies with zero downtime. For example, code could be delivered and deployed regularly in a 2 week sprint cycle or even multiple times in a single day to address an emergency. Provisioning a new service and making it available for development  can take anywhere from a few minutes to a few hours.

Infrastructure Cost

  • On Premises: The enterprise bears the cost of the servers and software, including all hardware, power consumption and physical space for the servers.
  • Cloud: The enterprise only pays for the resources used with no cost for maintenance and upkeep.  The price remains flexible and adjusts up or down based on how much is consumed. Based on my experience, I typically see a conservative reduction of 50%-75% from on-premises costs with a more robust performing architecture.

Data Control

  • On Premises: An enterprise retains their data and they are in full control of what happens to it. Because of this, highly regulated companies will typically remain on-prem or consider a hybrid or private cloud implementation where they can have tighter controls.
  • Cloud: The data remains under an enterprise’s control in cloud through the use of data and encryption keys.  However, if there is an outage, you may be unable to access that data temporarily.  This is one consideration when designing your cloud infrastructure and a reason to build in some redundancy mirrored through multi-regional data centers or a high availability solution.

Security and Compliance

  • On Premises: The enterprise is in full control of their own security and can segregate the systems or environment as they see fit to maintain that security.  This is attractive to several industries like government or banking or regulatory requirements like HIPAA or FERPA, but those lines are blurring with hybrid and private cloud models that offer compliance.
  • Cloud: Security in cloud is only as good as what you implement for your solution design.  Make sure you design a carefully thought out security model and perform regular penetration testing and security reviews to ensure that the design is as solid as possible. This is even more critical to remain in compliance with data privacy standards if the application is handling any personal information. You also need to be aware of any third-party provider security issues and address those immediately.

Conclusion

For each of the areas I have dealt with, we have made the decision to take the leap from on-premises to cloud.  At the same time, I have encouraged the teams to rethink their process and development needs to make sure we do a true transformation rather than a lift and shift approach.  There are merits to both, but ultimately a transformation is where you will begin to truly produce quality results that meet or exceed business objectives.  A lift and shift can help contain costs, but it will set you back on beginning the transformative efforts to establish a well-thought out design on cloud.

For my current project, the following principles are what are driving our implementation:

  • Providing creative solutions that will delight the customer and turn them into advocates for products
  • Modernizing the foundational technology platforms, which often requires a transformation from on-premises to cloud
  • Defining a process for metrics driven development and design
  • Analyzing user experience and user testing as a common task through every step
  • Simplifying the user experience – both for internal administrators as well as external customers
  • Improving development time to take requirements to implementation
  • Reducing overall infrastructure costs

I strongly encourage anyone trying to focus on similar objectives to take this and align it to a 2 week agile development model.  This will work nicely with the UX team working one cycle ahead of development to keep the projects in sync with deliverables, user testing, and regular design adjustments to the code as it is being produced. The net result is a quality end product is produced with allowance for continuous improvement with each development sprint.