Is Your Cloud Elastic or Plastic?

The discussions over multi vs. single tenant Cloud application design seems to be winding down with multi-tenancy clearly the winner. Although customers should frankly not care or be impacted by either architecture, vendors would be wise to follow a path that leads to easier maintenance and lower operational costs. As the trend in SaaS and Cloud computing puts downward pressure on license prices, application vendors need to adopt technologies and architectural models that result in the most cost effective manner to operate a Cloud application. That's assuming you have a for profit or at least against loss business model.

Now, it seems natural that the next big debate in Cloud computing architecture is going to be around elasticity vs plasticity. 

Is your Cloud computing infrastructure able to scale up or down based on demand? or Do you have to plan for peak demand and deploy enough hardware to make sure you have enough capacity to address your demand and SLAs?

If it's the latter, then it's like having a hotel keeping all the lights in every room on just in case some one checks in. How about turning the lights on only when you need them?! The amount of resources (aka moolah) wasted on running infrastructure constantly for peak demand can potentially negate any cost savings achieved through multi-tenancy.

The only arguments that seem to make any sense for plastic computing are with regards to SLAs and the latency involved in bringing on new hardware/software to support increases in demand. To that, I say...invest in some operational analytics. I'm sure if you can track your usage, you can see patterns of use and plan for them. For example, if you're running a sales or finance application, it seems natural that end of month/quarter would be the busiest times and beginning through mid-month, things are not so busy. Turn off the lights when you don't need them.

Can application integration be pre-packaged?

The concept of pre-packaged integrations is nothing new. For years, integration vendors have tried to sell pre-packaged application integrations with various degrees of failure. You might presume that because of these failures, application integration cannot be pre-packaged and but you would be wrong.

Most of the failures were due to:

1. Complexity of underlying integration platform used

The 1.0 integration products were (are) so complex and convoluted that trying to make changes costs the same as writing from scratch. So why pre-package if it's going to cost the same amount as starting from scratch.

2. Over architecture of the solution on part of the developers

You see this over and over again. Developers with little customer implementation experience are charged with developing a pre-packaged integration solution. They start by trying to conceive every possible scenario at every customer. From there, there's no coming back. You build and build till you think you have every one covered. Only problem is that now you need a 30 day training course to understand all the moving parts.

3. Combination of 1 and 2

Integrations can absolutely be pre-packaged. The question that needs to be answered is "To what extent?". The answer is going to depend on 1st the use case, 2nd the applications being integrated, and 3rd the experience of the developer.

Some use cases lend themselves to be 90-100% pre-packaged or "canned". For example, user synchronization. The objects are usually very well defined and tend not be customized per implementation.

Some use cases reach the 70-80% level. Customer master sync is good example. For the most part the customer objects on each side will be standard but you'll find various number of custom fields that need to be included. The integration platform should provide easy method for providing the additional required mappings.

You might argue that applications like SAP which provide infinite amounts of customization capability would be the exceptions to the case but that's not necessarily true. Generally, standard objects are only modified to include new custom fields.

Most use cases can be pre-packaged to at least 50%. The trick is not to over think or over build. Trying to conceive of every scenario and account for it will be impossible. As long as the underlying integration platform provides for easy modifications at implementation time, there's no need to over architect the solution. You can deal with the one-offs at implementation time.

Top 10 Indicators that you're a 1.0 Application Company!

10.	The last time you updated you're user interface, Windows 3.1 was your OS.
9.	Your UI is still Windows-based.
8.	You read "Only the Paranoid Survive" and have locked yourself in a room.
7.	Your API strategy is to expose your database tables and stored procedures.
6.	You think Cloud and SaaS are only being adopted by small companies with little to no money.
5.	You refer to your hosted instance of your application as SaaS.
4.	Your idea of rapid customization capability is to lock an engineer in the room with your SaaS hosted instance.
3.	You want to adopt a Cloud and SaaS strategy but are worried about eroding your high ASP.
2.	You don't have a Cloud strategy yet.
1.	You're Cloud strategy is to wait in your room till the fad is over.

Why is API development often an after thought?

For most application developers, SaaS and on-premise, this seems to be the case.

There probably isn't a company out there that runs their entire business on one single application from one single vendor. SAP and Oracle would probably like it to be otherwise but even they realize that it's a hard sell. SAP provides one of the better APIs in the 1.0 application space. A true sign of maturity. If your application offers any value to customers, then providing them with the ability to integrate it with other applications only serves to increase it's value not to mention it's stickiness. An integrated application is much harder to replace.

If you already have APIs or a method of integrating your applications, how would you rank it using the simple scale below?

• Level -1: Our services or engineers can write custom code when needed to export/import data when necessary.

You're in trouble. You know it or not. How can you scale this model? How do you maintain all the custom code?

• Level 0: Users can export or import a CSV file via a button or link in the application.

This is the bare minimum. Your users can manually import/export data and when ever they want to switch to your competitor, it will be easy for them. If you don't already have a way to get/post the file via HTTP(S), add it so you can at least automate the process.

• Level 1: We have XML over HTTP APIs. 100s of different operations exposed. As far as a schema, we provide DTDs or you can use the query option to see what elements are available per object so you can manually construct your requests.

Congratulations! You have APIs and can tightly integrate your application with your customers. However, you are certainly putting all the burden on your customers to figure things out. Integrating with your application will cost users more and keeping up with changing requirements or application customizations will require significant effort. Don't be surprised if integration is still an area of concern for your customers and services team.

• Level 2: We provide Web Services (WS SOAP or REST-ful). We have well defined WSDLs and/or schemas (XSDs, RELAX NG, ...). For every customization in the application, users simply re-download/import the WSDL (or schema). We release a new version of our APIs with every release which you need to immediately adopt.

You're well ahead of most of the market but don't bask in the glory too much. You still have work to do. While a static WSDL or Schema based approach seems easy enough, just ask a developer how much they enjoyed re-importing the schema 20 times because the users were making last minute changes. Consider moving your APIs to the next level.

• Level 3: We provide meta-data driven APIs via Web Services (SOAP or REST). As users make customizations to the application, they simply have to retrieve the latest set of object meta-data to include any new or changed fields. As new versions are released, users need only upgrade if they want to take advantage of the new capabilities.

You clearly understand the value of APIs and have made it a priority. Thank you!

For those of you wondering who in the 2.0 application world has achieved level 3, take a look at Force.com's APIs. Their APIs are well documented and publicly accessible. Follow the leader!

If you're planning on building or re-building APIs, I suggest reading "The Top 10 Most Common API Pitfalls" too. I have a slightly different view on a few of the points which I'll post very soon.

In conclusion, you have to make API development a core feature and part of your strategy. It's critical to your success.

Don't over architect your application integrations!

Simple and agile should be your foremost design considerations in integration. Trying to get applications with different functionality and schemas to talk to each other via different protocols or APIs is complicated  enough, you don't need to add to it. Focus on the business reason why you're integrating the applications. If in doubt, ask your business user or CIO.

Keep these guidelines in mind as you embark on your next integration project:

• If point-to-point works and its all you need, don't spend time and effort designing a hub-n-spoke model and an all encompassing uber canonical intermediary model. Unless you're the fortune 100 (50?) and have multiple identical applications across your enterprise, most of your integrations will be point-to-point. That's true even if you force a messaging bus (queue) in the middle. Don't confuse your underlying software/hardware architecture with your actual integration architecture. Everything may flow through a single hub (or server) but you can still just have a bunch of point-to-point integrations. If object A from application A only needs to be integrated with object A of application B, then stop there. If you have an integration platform worth it's salt, you can always come back and evolve your integrations.
  

• Avoid custom code like your job depends on it, which it will. Custom code is the path to the dark side and the famous Gartner Spaghetti diagram. It's not point-to-point integration that gets you in trouble, it's the lack of a unifying integration platform that leads to Spaghetti. Using an integration platform will give you consistency across design and management of your integrations. If you're being tempted by the dark side to use custom code, remember that running tail on a log file doesn't consitute management and monitoring. If you're getting tempted to build your own awesome integration platform, go back to your business user or CIO and ask them what they wanted again.
  

When selecting off-the-shelf integration software, keep the following in mind:

• Pick an integration platform that can deliver 80% of what you need out-of-the-box. Most enterprise application integration problems fall into the 80% category. The other 20% edge cases may need a different solution. Platforms and vendors that focus on those edge cases to differentiate themselves tend to provide the same model for solving all problems, with great pain and difficulty!
  
• Make sure what ever solution you choose has solid coverage for the 3 basic types of application integration:

• Data Synchronization - One time migrations or ongoing synchronizations.
  
• Process Integration - Data syncs only get you so far, being able to write integration flow logic tying different business processes together is also important.
  
• UI Integration (aka Mashups) - Perhaps the most under rated method of integrating applications. If all you need is visibility to data in another system, why synchronize the data. If you don't need to use the data in the target application for processing or reporting, then don't synchronize it. Most applications these days provide browser-based interfaces with the ability to embed iframes or other methods of incorporating external data sources. "... mashups can deliver an 80% solution at 20% the cost (or less) " (source: http://blog.programmableweb.com/2009/07/23/enterprise-mashups-continue-to-gain-momentum-as-part-of-enterprise-20/).
  

• Apply standards when they make sense and avoid them when they only serve to complicate solutions. Having adopted SOA doesn't mean that every thing needs to be exposed as a service. It certainly doesn't mean that you should force adoption of overly complicated WS* "standards". Stick with the basics that you really need (vs what would be cool). You'll find varying levels of WS* "standards" adoption in the application market place. SOAP-based or REST-ful? What ever works. You'll find that you'll have to be able to support all kinds of different "standards". Make sure your integration platform is flexible.