Hybrid Delivery - The Collision of Corporate Applications with Cloud Computing
As enterprises run head-long into cloud computing one of the most widely adopted and most useful paradigms is the concept of a hybrid cloud, and with it comes hybrid delivery.
If you're interested in learning more on the ideas (HP link) behind hybrid delivery, click the link.
The bottom line is that as applications start to cross network boundaries between the traditional corporate network and cloud-based providers and service vendors, there is an imminent collision between the application development practices of yore, and the differing requirements around architecting for the cloud.
That imminent collision isn't necessarily catastrophic, as organizations have an opportunity to either get it right or really mess things up, depending on their approach. So what do I mean by the approach?
It's complex, but it essentially comes down to this - in the hybrid delivery world the enterprise is interfacing directly with assets that are not theirs and likely in a public cloud - so that connection point is vital to the success of hybrid delivery.
If you're read about hybrid delivery you're no doubt familiar with the 5 critical success components:
- Security - protect corporate and customer data
- Openness - enable choice
- Automation - enable end-to-end service quality
- Resiliency - meet defined service levels for availability, quality and performance
- Seamlessness - combine public/private cloud in a unified IT portfolio
Here's the challenge at hand - take a platform you've cultivated in-house for (potentially several) years, and interface it with a shiny new service-oriented offering someone else built out there. If you're a CIO that has to sound terrifying.
I won't tell you not to worry, or that you should consider it simple because some vendor is magically going to step in, drop a box off at your loading dock, and solve all your hybrid delivery problems - because that would be unrealistic. Instead, I'll offer some tips for assessing your readiness for the move to hybrid delivery...
Assess your application's vitals:The migration to a hybrid delivery model emphasizes data interconnectivity. This means that a foreign platform (and its users) will be inter-connecting to your data stores through some interface.
Whether you're exposing your data through a WebService, or some other type of API-based data exchange, you will need to make sure authentication and authorization is controlled very carefully and access granted deliberately.
Also, for many organizations this means that an application will be exposed outside the theoretical corporate firewall for the first time - this may mean that your application or applications aren't designed with security in mind, or aren't built to be resilient to attack.
Beyond the obvious security validations and resiliency, you will need to assess your application's ability to perform in a distributed environment where the endpoint may (and likely will) be multiple endpoints from both a fail-over perspective and performance perspective. These are just the first of a series of questions you must perform in assessing your application for a hybrid delivery model.
Review architectures: One of the more overlooked steps when thinking of incorporating cloud-based services is an internal review of architectures. Just as it is critical to carefully review the architecture of your cloud services provider, it is also critical to take this time to review your own application architecture for outdated, or unsupported architectures and components.
Remember that internal applications can often go years between updates, and departments have a tendency to "just leave it work" when nothing is broken, particularly when applications aren't facing that perceived external threat.
Validate your data: As part of any pre-flight plan, a pilot checks everything including the manifest of things that he already knows are working well. Just because you've had data in your databases for years doesn't mean that it's proper, or even 100% sane. Often times applications are written to be loose on the data they work with... especially when its your own data.
When you connect to a 3rd party application service provider the rules will likely be more stringent, data validation tighter. The cloud provider has responsibility to connect to many different consumers of their service so the validation of data is often extremely rigid.
A home-built or modified CRM tool may have many data fields that allow free-form text which are intended to be formatted as addresses, social security numbers, or product IDs - when these are migrated to a SaaS provider through a hybrid delivery service -the data will break the platform or service if its not formatted appropriately.
If you have the luxury, think about re-architecting and testing your applications' resiliency and security. If at all possible, applications should be reviewed prior to making a migration- and if found deficient in any of the 5 key success areas, consider a full-scale review of the application.
Moving to the cloud shouldn't cost your organization a fortune, but if all 5 key elements aren't addressed the costs can quickly pile up. While security and resiliency are top-of-mind in the cloud, both of those have several bulletpoint items that go into a successful audit of that component.
Resiliency isn't necessarily only from hackers, and doesn't necessarily overlap completely with security. As you consider jumping into a hybrid delivery model for your critical application services, do yourself a favor and think about all the things that means... and take a moment to assess before diving head-first into the shallow end of the pool.
Cross-posted from Following the White Rabbit