Blog

Thanks go out to Richard Goering for his recent blog post about Hybrid-SaaS.  At the end of Richard’s post he thought a definition of the different layers of the stack would help, so this is a much simplified series of summary descriptions for each of the layers.

The Cloud Computing Stack

Starting at the beginning, below is the three layer Cloud Computing stack.  We start at the application level with the Software-as-a-Service (SaaS) layer.  I recently learned that the term was coined by David Thomas, (CEO and Founder of Intacct, now at TechAmerica) in a “gathering of the clans” at the salesforce.com offices in San Francisco involving Marc Benioff and a number of other early SaaS leaders in the early 2,000’s.  The objective of the meeting was to come up with a term to differentiate themselves from “ASP“s, but I digress. 

SaaS is the delivery of the end-application within a browser.  Next down is the Platform-as-a-Service (PaaS) layer and represents a collection of development tools, API’s, and resources used to create SaaS applications.  Finally, there is Infrastructure-as-a-Service (IaaS); a collection of (usually) virtualized compute, network, and storage resources.

Cloud Computing Stack

 SaaS Layer

This is the piece of Cloud Computing that we come into contact with everyday (every hour!?).  It is Facebook, Google Docs, LinkedIn, Virgin’s online booking app, Expedia, etc.  It is a remote application accessed and used via a common web browser.  There are no downloads, no installations, and no licenses to deal with.  Although consumer applications do not have Software License Agreements (SLA), many B2B (Business-to-Business) apps do have SLA’s, especially when deployed throughout an enterprise.

Implicit in the fact that SaaS is remote, and nothing needs to be installed - no servers and no IT required.  Two of the especially sweet reasons to go with SaaS.

Within each application there is the core functionality that delivers the value of the application.  The app engine, if you will.  This holds the secret sauce of an application, the core algorithms and differentiated functionality.  Outside of this, there is a varied collection of fairly standard components (see diagram below).

There are usually at least two interfaces or views of the app, and often there are more depending upon privileges .  An administrator view and a user view.  Below this layer is a collection of common services, such as Identity Management, Access Control, Analytics, etc.

All of these components need to be seamlessly integrated for usability and security purposes (why bolting something together around a Google Group, for example, doesn’t work).  Security needs to be integrated across the entire app to ensure functional and data integrity.

The entire app must be “infinitely” scalable.  Meaning that any number of users can start using the application at any given time.  In the bad-old days, in order to manage any spiky traffic, this meant leasing a whole mess of servers from a hosting provider.  Now we just develop the app on a scalable provider, such as Amazon’s EC2 and we’re good to go…as long as your credit card doesn’t max out

SaaS vs Client App Development

In my last blog post, I gave a collection of reasons why many enterprise software applications will have a hard time converting into a SaaS application.  The greatest technical reason is architectural - moving from a single-user client app (”single tenant”) to a mult-user server-based app (”multi-tenant”).  A Service Oriented Architecture (SOA) may help this transition, but there’s still a lot of work to do…in fact, the reality is, the endeavor will be a complete re-write.  (As a point of reference, I was talking to an Enterprise Software developer the other day, and he said his application had 11 Million lines of code…)

Also, the languages used are different - Javascript, Java, and php (or Python).  Thanks to all of the web startups out there, php and Python (”backend”) developers are hard to come by.  And so a move over to SaaS would imply a massive re-training effort.

I hope this was a useful summary.  It is in no way intended to be exhaustive.

If you know of any useful references, please add them in the comments.

Next up, Platform-as-a-Service, or PaaS.
Connect with me:

Posted under Xuropa, industry

The recent eruption of Iceland’s Eyjafjallajökull volcano has paralyzed air traffic to and from Northern Europe and is slowly expanding to cover even more of Southern and Eastern Europe. This has not only stranded travelers within Europe, but also those traveling between Europe and the rest of the world. I heard an estimate that this is costing airlines $200M per day and that does not include the impact to individuals and businesses affected by the inability to fly. It’s a pretty stark reminder of how little of our world we actually control and how small we are when it comes to global events like this.

To make it even more unsettling, scientists don’t know how long this will last. The last eruption of this particular volcano, about 200 years ago, lasted 2 years, from 1821 - 1823. Can you imagine the impact that a 2 year eruption would have on the climate and on an already fragile world economy?

EDA is one of those industries that would be greatly affected since so much of the business of EDA is done face-to-face.  There are conferences like the upcoming Embedded Systems Conference and Design Automation Conference. Product demos are typically done at customer sites. For tool evaluations, application engineers visit customer sites frequently (at a minimum) or even live on-site. And post-sales support can be even more intensive as the number of users goes from a handful to dozens.

Have you considered what your company will do if you can’t travel for the next 2 years? Maybe you’ve thought ahead and have some contingency plans already in place. Perhaps you’ve already moved a lot of your industry and customer interactions to the internet or the cloud so you are not as dependent on face-to-face meetings requiring air travel. If so, then you are in a great position to make it through (and even benefit) if this eruption continues for an extended period of time.

If not, then you’ve got some planning to do.

I live in Southern California and every time there is an earthquake people rush out to by supplies and get their Earthquake Kits together. It’s a wakeup call. Well, consider this a wakeup call to get your company’s “Volcano Kit” together. Here are some suggestions for what to stick in your Volcano Kit:

• WebEx / GoToMeeting for slide presentations and demos
• Participation in online Webinars and Virtual Tradeshows
• Videoconferencing services like Skype, Cisco
• Cloud computing for internal servers (in case they can’t ship hardware)
• Remote demos and tool access (Xuropa, of course)

I hope the volcano subsides in the next few days and is just a scare that gets us to be better prepared. If not, and it lasts a few months, then you may be able to benefit from the Do More With Less promotion we are running at Xuropa. Just tell us a way that you or your company is doing more with less, or what you have or will put in your Volcano Kit. And you might win a FREE Xuropa On-Demand Basic Application Server for a year, to put in the Volcano Kit.

Posted under Xuropa

“Huh?”, I hear from my friends,  ”SaaS (Software-as-a-Service) isn’t for all Enterprise Software?”  Let me explain.

This has been something I’ve been talking about from “the beginning“, but never got around to putting it up here for discussion.  I was finally prompted by a conversation I had over dinner with Richard Goering last week at the EDP Symposium and Workshop.  I could tell that he wasn’t expecting this perspective from me, and his question was a follow-up of what I’d said in my presentation earlier in the day.

The reality is, the world is not as as straight forward as some would have us believe - especially in some markets.  Thousands of software applications have characteristics that create barriers so high that delivery in a “salesforce.com“-like SaaS manner doesn’t make sense.  At least for a long time.

Now that we have a clearer definition of what SaaS is within the Cloud Computing stack, and we have a fuller understanding of the use models of software applications, we can more clearly see and articulate the nuances, layout the challenges and reasons why SaaS doesn’t make sense all the time, and what the alternatives are.

Software-as-a-Service Characteristics

Firstly, starting at the beginning, here is the Cloud Computing stack (I’ll go into more detail in a later post).

Cloud Computing Stack

The top layer, SaaS, today includes applications such as CRM , online docs, tax preparation, social networking, etc.   The characteristics of this layer most relevant to our conversation are:

• These applications were written from the beginning to be web-based
• They are applications that deal with what I consider the outer-circle of a company’s IP (a Rolodex, business processes, for example)
• They do not require interoperability with any other software application or data
• The user interface is consistent across all users
• In the main, these applications were created by market segment newcomers

Platform-as-a-Service Characteristics

The second layer, Platform-as-a-Service (PaaS) is a bundling of compute resources, storage facilities, datasets, an integrated development environment (IDE), and some proprietary APIs.  The characteristics for this layer are:

• Tools to develop, debug, and deploy new software applications
• You have to use the infrastructure of the PaaS vendor

Enterprise Software Requirements

When we step beyond the “safe” outer layer of IP and start dealing with the “crown jewels” of a company, what do we find?

• An installed base of millions of lines of code that has been used for years or even decades
• Applications that work with (or are used to generate) a company’s core IP
• IP protection concerns vary
• Applications that are part of sophisticated and complex flows of third-party applications and databases
• A varying degree of customization in order to meet customer-specific work flows, data formats, and other internal “standards”
• Vendors with shareholders and investors that base their investment upon expected business models and revenue streams

The Rub

All of the above enterprise software characteristics present challenges to a company in moving to a SaaS model.  However, the most crucial aspect of this list is that it’s not all one-sided.  If the list were purely issues for the vendor or the customer, then a straight forward migration can be imagined due to simple market forces.  But when both sides of the purchase equation have reasons to stick with the status quo, migration is stymied to the point when only a really large economic imperative causes the shift to occur out of necessity…or it takes a much longer time for the natural migration to occur.  It took Salesforce.com about 10 years to go from being an ASP startup to a $1B SaaS company.  Even though the rate of change is increasing, we’re still talking about a while.  Don’t believe me?  Have you taken a look over a bank tellers shoulder recently?  Or an airline booking agent?  Surprised to see the DOS app running there?  It’s running in a shell, but it’s still DOS.

Having said that, the transition will occur.  The question is, “How?”.  It will be a while before companies go out and rewrite their software to be “pure-SaaS”.  In the meantime, we need to look to scenarios where a move to the cloud makes sense, and we need a different type of SaaS to support the move.  Let’s call it “Hybrid-SaaS”.

The Move

I don’t think there’s any argument that we have an economic imperative and cloud computing is very attractive.  So the pieces will eventually fall into place, but what will that transition look like?  Here are two plausible scenarios:

The Little Guy

This would be a small company with a limited sales channel and a need to find growth somehow.  So they’d be more willing and able to explore mixed business models easily differentiating between product brand, level of service, market segment, or geography, etc.  If they have a differentiated product, great, but if they’re competing with an incumbent the agility of a Hybrid-SaaS model may provide them an edge in penetrating “the long tail” of a market.

The New Product

This is a new product within a large and established company.  The scenario is exactly as Geoffrey Moore described in a presentation I attended a few weeks ago.  Although the large company has a strong and established sales and support channel, the challenge to the new product is that it is essentially ignored.  The new product is risky for the sales organization as it could sour a relationship if something goes wrong, and that could impact existing business.  Also, the new product is not likely to be purchased “in volume”, and so the return on what would be a hard and long evangelical sale is not there.  This scenario kills new products and hinders large companies moving into new market segments.  Another opportunity for “Hybrid-SaaS”

There are more, but this will do to get us started.

Getting Started

So now we have a couple of realistic scenarios in which a company or a business unit would consider moving to the cloud.  The economic imperative is established, but so many hurdles remain.  In a later post I’ll go into more detail (this is already getting way too long) of what Hybrid-SaaS looks like, but for now, let’s break down the problem and go back to our friend Geoffrey Moore.  This is the Technology Adoption Curve, it’s inevitable, and we need to start somewhere.

Hybrid-SaaS

If we were to put software into the cloud, what would the solution need to look like?

• No re-write of the product code
• Easy installation of the software as-is
• Zero IT overhead
• Cloud and data center agnostic
• Manageable by marketing, sales and applications engineering
• Easy, secure, and manageable access for customers
• No change in licensing mechanisms
• No client-side installs
• Scalability across an entire market
• Collaboration tools
• Management tools

The solution needs to meet these requirements technically.  Because we’re not going to re-write our code, we need to start at the infrastructure layer (IaaS) and build up.

We also need to look at some early adopter use-models.  Scenarios that get value out of the cloud in a way that is in line with business objectives.

How do we leverage the Cloud?

Using the cloud and monetizing the delivery of software via the cloud may be too much of a challenge initially.  IP is still a concern to many customers.  Business models need to be tested, etc.  However, there are ways that the cloud can be used to materially impact a business, increase revenues, lower the cost of sales, and shorten the sales cycle.  Here are some of the usage models for when your software is on the cloud in an environment that meets the above requirements:

Pre-Sales

• Lead generation
• Self-qualification
• Self-education
• Training
• Evaluations

Post-Sales

• Account penetration
• Self-education
• Training
• Upgrade campaigns

Development

• Third party collaboration
• Beta testing
• Focus groups

Using the cloud in this way, value is extracted and existing business models are maintained and actually enhanced.

Fundamental to all of this activity is a deepening of the engagement between the vendor and the user.  From this point we can begin to approach the chasm with a greater understanding of what life on the other side should look like for both sides of the vendor/user equation…because it’s not straight forward.

Posted under Xuropa, industry