Gianpaolo's blog : SaaS

Multi Tenant Data Access (MTDA) Blueprint

gianpaolo — Tue, 26 Aug 2008 02:05:49 GMT

Although cloud storage fabrics are very cool, a lot of multi-tenant applications will be build against a database. Based on some work we did on our super famous sample application LitwareHR :) , we just released a blueprint providing guidance on writing a SQL Server based, single instance, multi-tenant data access layer. (thanks Michael for the blueprint framework)

Here is a short video introducing the MTDA blueprint. Interviewer: Michael, interviewee: Eugenio

MultiTenant Data Access (MTDA) S+S Blueprint Released

Enjoy and let us know what you think!

P.S.

Note that if you already have the S+S Blueprints Manager installed you can get this Blueprint by updating from the RSS feed.
If you want more information, you can visit the MTDA codeplex site: http://www.codeplex.com/mtda

Make a movie on S+S and win a trip to Macau!

gianpaolo — Mon, 23 Jun 2008 19:05:44 GMT

A couple of months ago I wrote an article providing a high level explanation of the basic concepts of S+S, now my friends in Asia Pacific need your help visualizing this article through a great video.

Anyone can participate – whether you’re a student, IT pro, architect or someone with movie-making talent.

The winner will jet off to Macau, where you can celebrate your win in style with a weekend at The Venetian Resort Hotel.

Submission deadline: 31 July 2008

All the info here: http://www.bringitalltogether.asia/

Looking forward to watching your submissions!

Cloudy Future for the Enterprise and most likely for ISVs too

gianpaolo — Fri, 20 Jun 2008 04:18:55 GMT

As I mentioned previously, the study of clouds (cloud computing of course) is becoming a very popular topic in the software industry. In the last couple of weeks alone, I read tens of articles on the subject. I found many of them proposing various type of taxonomies for cloud computing, utility computing, PaaS etc. even more offering futuristic predictions, including but not limited to, the doom of "on premise" software, but I found extremely few attempting to explain the architectural impact of "the cloud".

With this gaping void in mind (btw similar to the void that existed about 2.5 years ago around architectural impact of SaaS) I decided to spend some cycles on trying to understand the implications of cloud computing for large enterprises and ISVs. To get started on the enterprise angle, I used a simple, yet powerful technique: I asked. I asked various 'office of the CIO' type folks who I happen to meet quite often in my job and tried to extract the commonalities of what they were telling me. I then bounced some ideas around with trusted colleagues and once refined, I validated these ideas with another group of 'office of the CIO 'type, making sure I was not completely off the mark. Below my finding.

'do it yourself' vs. 'as a service'

The first finding (which happens to be quite obvious after the facts) is that the most important element that an IT architect has to understand with regards to the cloud, is the impact of the fundamental question that the business or IT will ask itself: “what will I do myself” versus “what will I get 'as a service'”.

'do it yourself' will give you control. But if you do it yourself you will not be able to tap into economy of scale; quite understandably, if you do it yourself, the scale is 1 (you) no much economy there. You bear the full cost.

On the other hand, if you get something “as a service” you can tap into higher economy of scale. By leveraging the fact that the “as a service” provider is providing the service to hopefully thousands, if not hundreds of thousands of customers, you benefit from the economy of scale that the provider is capable of achieving. But you have little control on what you get.

So key takeaway #1: as illustrated in the picture below, at the highest level, you are trading control for economy of scale (and vice versa)

who builds it and where does it run

The second element that is important to understand is that in cloud-aware world, there are 2 dimensions of “do it yourself” vs. “as a service”

First dimension: Who builds it? (the good old build vs. buy); this directly impacts the control of FEATURES. If you build the software, you control the features that will be in the software, if you get the software from a service provider you get the features that are offered by the provider (very logical isn't it).

Second dimension: Where does it run? This choice impacts the control of SLA. If you run your stuff yourself, 'on premise', you have full control of the SLA. Note that controlling the SLA is different from having a high SLA or doing a better job than the guys in the cloud. It means that you are able to control what the SLA is. If you use the cloud, you get the SLA that is given to you.

Once again, as I mentioned earlier, for both of them (SLA and features), control comes at the expense of economy of scale.

map of possibilities

Why is this important? Because these 2 dimensions create a “map” of possibilities that enterprises can use for their IT assets.

Enterprises are now capable of deciding, along these 2 dimensions, where they want control of features and/or control of SLA at the expense of economy of scale. No area on the map is a “better choice” than another, it is about making sure that the various IT assets are placed where they should be, based on relevance to the business, compliance to regulation etc.

The table below gives some examples of IT assets type, based on the level of control along both features and SLA. In the top left corner, you find the classic 'packaged software deployed on premise'. By running it yourself, you have full control of SLA, but being a packaged software you have low control of features. The low control of features is compensated by high economy of scale of features. The software vendor, amortizing the R&D cost across hundred/thousands of customers, can build features cheaply than you can do yourself. The bottom left area is where we find the good old "build and run on premise" software, for example an homegrown banking system. There, you have full control of SLA and features since you are doing everything yourself but you have no economy of scale. Both the cost of developing the features and running the software can only be divided by 1 (you). The top right area is the canonical 'SaaS' offering. The economy of scale is high on both the features and the SLA, but you have little control on features and SLA. The intermediate columns (@hoster and @cloud) are deployment options with decreasing SLA control compared to doing it yourself but increasing economy of scale.

(note: one could justifiably argue about whether the economy of scale is higher @cloud or @vendor; the rationale to place them in this order is that @cloud gives you more control than @vendor; the assumption here is that you would be deploying your own software or packaged software in a cloud compute environment and therefore have some level of control on how much computing power you want to allocate to your applications, as opposed to @vendor where you have 0 control)

semi-hypothetical scenario

Now that we have discussed some of the theory behind this, let’s go through a semi-hypothetical and largely simplified scenario. (I say semi-hypothetical because this scenario without being a 100% real one, is highly inspired from an actual conversation I had with a large pharmaceutical company.)

In this scenario, there are a couple of IT assets they built themselves, as they wanted very unique features and some other assets they sourced from the market as they “just” wanted what everybody else had. In other words, they made significant investments in assets they wanted competitive differentiation (e.g. clinical trial management software and new molecule research) and purchased from the market 'common in the industry', non-differentiating assets (CRM, Email,...). In addition to these choices, they ran all of their IT themselves, owning and therefore having control on the SLA of their entire IT environment.

Although this picture is quite common, my discussion with this company CIO surfaced that this map did not represent how they wanted to run their IT. They knew they were spending too much of their budget on non-differentiating assets, limiting the amount of investment they could make on differentiating assets.

wished state

In other words, they way they would like to run their IT is better reflected by the picture below.

Email and CRM not being seen as competitive differentiators, it is ok to trade control on SLA and features for much higher economy of scale (shift to the right); legacy HR system built in house for historical reason should be pushed up for gaining economy of scale in terms of features, but would be kept in house for keeping the control of SLA. Clinical trial software, being an asset providing competitive advantage, gets a double down in terms of investments (thanks to the saving of pushing some assets to the right). The new molecule research software is pushed to the cloud to get access to elastic computing resources (variable peak computation) as well as cheaper storage (at the expense of control of SLA) but although it is running 'off premise', the development is kept in house to keep full control on features.

As you can see, even in this highly simplified environment, the goal is to clearly understand where keeping control makes sense and where it is better to tap into economy of scale and place the assets accordingly.

crossing the chasm

Unfortunately, this is easier said than done.

Reusing a sentence made popular by Geoffrey A. Moore in his book (albeit in a completely different context), pushing software out to the cloud (e.g. CRM in the example above) as well as projecting cloud software back into the corporate boundary (e.g. the new molecule research software) is very much like crossing a chasm. And it is precisely that chasm crossing that architects must master.

The architectural challenges are multiple; the major ones can be categorized in 3 buckets: identity, management and data. Examples of identity challenges are around cross boundaries authentication and authorization, single sign on and identity lifecycle. Examples of management challenges are around cross firewall SLA monitoring and cloud software management action triggering (halting, pausing, throttling). Example of data challenges are data ownership, portability, reporting and privacy. As you can see, a lot of good stuff for architects to become even more indispensable :)

To be honest, I do not have all the answers yet, but now that hopefully the a clear scenario has been described, and the cloud impact of this scenario is better understood, I hope you will be joining us in our new journey in discovering and describing the underlying black magic required to master the cloud.

In future posts we will be going through these 3 buckets in more details, we will be discussing high level architecture(s) that this semi-fictitious "Big Pharma" company could put in place to smoothly cross the chasm, as well as describing the set of 'on premise' and 'cloud technologies' that can be leveraged to do all that. And of course, similarly to what we did with LitwareHR it would not be surprised if we threw a few bits and reference model in the mix as well :) Finally in addition to the enterprise angle, we will exploring the complementary view, the ISV perspective.

stay tuned!

P.S.

Although it was not the initial intent, now that I wrote all this, I find that this post has an eery similarity to Fred's invitation back in February 2006, when we started our SaaS architecture work and invited everybody to walk the journey with us. Hopefully this ride will be as fun as the previous one.

Nephologist: The Hottest Job in the Software Industry!

gianpaolo — Tue, 27 May 2008 09:40:47 GMT

Nephology (from the Greek word nephos for 'cloud') is the study of clouds and cloud formation. It seems to me that everybody in the IT industry wants to be an expert in cloud these days; cloud computing that is.

Jokes apart, one thing I learned from the real clouds is that : Atmosphere is a dynamic system, and the local conditions of turbulence, uplift and other parameters give rise to many types of clouds. Replace "Atmosphere" with "Software Industry" and you have an idea of why so many "cloud platforms" are currently out there.

Knowing how difficult it is to reliably forecast the weather, I will not try to give you an accurate picture. But, I suppose I can safely say: stormy weather continues with 90% chances of cloud tomorrow.

You liked LitwareHR v1, You loved LitwareHR v2, You are going to die for LitwareHR 'cloud storage' edition :)

gianpaolo — Tue, 06 May 2008 20:50:28 GMT

More seriously... Eugenio just announced and released on Codeplex the latest drop of LitwareHR.

Although the application UI was treated with a welcomed 'facelift' (we were told that LitwareHR UI was "too 1990s"), the main effort for this release was to move from local storage infrastructure (SQL Server) to 'cloud storage' in the form of SQL Server Data Services (SSDS).

Our intent was to extract the architectural challenges and best practices related to cloud storage in the context of line of business (LoB) applications. After having learned a lot through this exercise, I can safely say that, from an architecture perspective, the decision between local storage (SQL) or cloud storage (SSDS) will not be a no-brainer. As with pretty much all architectural decisions, it is all about trade off. The choice that will make most sense for your application will mostly depend on (a) the type of application you are building and (b) which are the challenges you want to own and which are the challenges you want to push to the underlying platform.

For example, in the specific context of LitwareHR, SSDS greatly simplified the multi-tenancy and customization aspects of the data layer; i.e. a lot of 'plumbing' code related to entity customization went away thanks to the flexible entity model natively offered by SSDS. On the other hands, the data model as well as the querying code had to be modified since SQL (used in our previous implementation) and SSDS do not share the same programming model (at least not at this stage). Also, SSDS not supporting JOIN required some new type of plumbing code e.g. cross-container search. The management of transactions had also to be rethought. Another example is the need of a better caching strategy on the business logic side of LitwareHR as the data layer (being in the cloud) is across a wide area network from the business logic, on the other hands we did not have to worry about the growth, scalability and availability of the storage subsystem anymore. From a hypothetical business model perspective, there would be changes as well, since on premise SQL server or licensed under SPLA would have a different cost curve from how SSDS would charged us. Specific comparison and analysis was not possible as SSDS has not disclosed its pricing model yet; but again, I do not expect being a no-brainer either and will depend on your storage access patterns, variability of access etc.

For those of you interested in deeper architectural challenges, trade offs and solutions chosen, I can only highly recommend you to read Eugenio's mini-series:

LitwareHR on SSDS - Part I - Multi-tenancy & Flexibility

LitwareHR on SSDS - Part II - The data access layer

LitwareHR on SSDS - Part III - Data access enhancements 1: caching

LitwareHR on SSDS - Part IV - Data access enhancements 2: developing offline

LitwareHR on SSDS - Part V - Searching across Containers

More on parallel queries across containers in SSDS

LitwareHR on SSDS - Part VI - Unit of Work support

Paging in SSDS & Parallel Queries

as well as a session at MIX08 on SSDS presented by Nigel Ellis uber SSDS architect (session here).

Also, for those of you wanting the see the goods, before investigating further, a screencast showing this release of LitwareHR is available (with sexy Argentinean accent) here.

For those of you wanting to experiment with SSDS, you can register for a beta account with this service here.

Probable next steps will be to do a similar effort around 'cloud Identity' and implement some of the concepts described here by my good friend Vittorio (a.k.a Dr. Identity Maximus) using the BizTalk Services Identity Provider; but let's not get too much ahead of ourselves and let's start digesting (and enjoying?) this new release of LitwareHR embracing cloud storage for part of its architecture.

This overall exercise was extremely valuable to us and allowed us to better understand aspects of cloud infrastructure in the context of a LoB application (as opposed to a more consumer oriented / social application), hopefully what we are sharing with you today (code, guidance etc.) will be as valuable to you in your investigation or implementation of cloud infrastructure based solutions.

An "S+S World"

gianpaolo — Tue, 29 Jan 2008 05:44:54 GMT

Below is an diagram I have been using for a while in my presentations on software + services (more about s+s here); so due to popular demand :) here is an explanation of it in my blog.

The image is meant to represent the new (or evolving) relationships among the different actors in a S+S world. Of course, reality is more complex and has more nuances, but hopefully it is a good approximation of what is going on.

On the right hand side, you see the S+S ISVs (previously known as SaaS ISVs, but now they have seen the light and have moved to an S+S model :). These ISVs are interested in building S+S solutions (such as this one), sometime to reach a wider market, for example the SMB space, sometime to revamp their product lines with product offering that better match their customers expectations.

These ISVs are increasingly collaborating with hosting companies, since part (if not all) of their solution is now a hosted service. This increased interest from ISVs is leading to an evolution of what hosters must offer to support the need of an S+S ISV. Co-location and dedicated servers are still the norm for now, but you must admit, it is a crude way of serving the ISVs need. An opportunity to offer a higher level platform, some call it a service delivery platform, as we described here and here is very real in many hosters mind. Leverage such platforms is even more real in ISVs mind. High touch managed services companies are also frequent but IMO a lot of what today falls into the "high touch" category could be architected out and automated, allowing even higher level of touch.

In addition to hosting services, there is an increased opportunity to offer “monetization services” such as a marketplace, a product catalogue, a reputation system, as well as more operational elements such as billing on behalf etc. In other words, the goal of the fictitious A Datum Marketplace in this diagram (and many real companies out there) is to connect software services supply with demand. Although today, many emerging software services marketplaces also provide the hosting of these services, it can (and should) be thought as a separate function. Fred has some related writings on this here and here.

Another interesting element in the S+S world is the emergence of “cloud infrastructure”, some call it platform as a service, I would rather call it infrastructure as a service but this will the object of a future post. Some of that cloud infrastructure is very "data center" oriented, as represented by the global foundation services image above. This is what people often refer to as "cloud computing"... very low level, usually commodity priced; it is becoming accepted that only a few players will be successful there. Massive economy of scale is the harsh law governing success in that part of the ecosystem and only a few have the aspiration and more importantly the financial capacity to achieve. There is also another set of "cloud infrastructure" which is a bit more "application level", pictured as building block services above, these services expose things like identity in the cloud, storage in the cloud, but also things like maps and alerts.

Finally, on the left hand side, there are 3 types of customers with quite different expectations: from individual consumers cherishing simplicity, not ready to pay anything for anything, happy about an advertisement model; to very large IT shops that have lots of legacy, regulatory compliance to worry about, often paranoid about their data, pressured by the competition to streamline all non core business, while augmenting agility and competitiveness. And of course the small and medium business market with little IT budget, wanting to tap into the benefit of large IT software 10 or 20 seats at a time.

The goal of architects in this world, is to understand how this interlinked system works or more accurately make it work. But making it work will depend on which actor you are in the system.

Typical concerns for ISVs are around solution architecture e.g. what are the tradeoffs in leveraging building block services, how do I design my solution to be hosting friendly, how do I design my solution to take advantage of multiple monetization schemes.

These concerns are very different from the hoster concerns; the hoster concerns are not only about the *-bilities (scalability, availability...), but also how to offer a service delivery plaform, how to architect the environment to transition from web site hosting to line of business application hosting, how to streamline operational processes to offer services to the long tail of service providers... dilemmas around buying servers vs. retailing "cloud computing" purchased wholesale... and of course the holy grail of hosting, maximize density.

The enterprises are often not interested in how to build or how to run, many are mostly interested in how to consume all this goodness available in the cloud. But consumption is not as simple as that, the concerns are around how to consume this goodness while keeping the high standards in terms of security, making sure that control of the most important data is kept, as well as compliance to Sarbanes Oxley, integrating cloud services with internal systems… A few of these concerns are explained here. And some enterprise are looking at bringing a lot of the cloud compute thinking in house i.e intranet-s+s.

Platform vendors will have to understand how to reach tremendous scale without blowing costs, abstract complex infrastructure into friendly programming models and of course fine tune what platform services are better offered as cloud services and which one are better offered as 'on premise' servers.

We have just scratched the surface here, but as one can easily see, with all "new worlds" come tremendous opportunities both in terms of slashing cost and in terms of top line revenue growth; these opportunities comes at a high price in terms of new scenarios to solve and new architectures to master. It looks like we (architects) have secure our jobs for another 10 years :)

Monetization: the next frontier of SaaS / S+S architecture

gianpaolo — Sat, 19 Jan 2008 04:28:31 GMT

Over the week end, I was looking at AMZN DevPay announcement and I started thinking in more general terms about the architectural impact of different monetization schemes. At a high level, software / service monetization can be put into 4 main categories:

perpetual license (e.g. one time charge of $85 and you get unlimited access to the software)
subscription (e.g. $20 per user per month)
usage based also known as transaction based (e.g. $0.05 per text/SMS sent)
and ad-funded (the service is free for the user and is paid for by someone interested in getting your attention while you are using the service/software)

Each scheme has an implication on the overall architecture of the service, and even further, some scheme cannot be used unless some architectural elements are part of the solution. Let me explain this in taking these 4 schemes one by one.

Perpetual license

Selling software through a perpetual license is a very attractive in many ways (for the seller); the money is received up front, reducing the impact of churn (even the user stops using the service, it was paid for already) and it is good for the treasury. From the buyer perspective it is often less attractive as by paying up front, most of the risk is on the buyer side.

From an architecture perspective, perpetual license can mostly be performed "out of band"; meaning that the software itself does not need to know, who is using it, how much it's been used... in other words, there is no real need to meter the usage. A perpetual license gives "all you can eat" access, forever. In other words, in a perpetual license scheme, the architecture does not need to be 'monetization-aware' (a part from any anti-piracy aspects)

But, as we all know, forever is quite a long time :) which means that if you are hosting the service on behalf of your customers (saas model) you are incurring an hypothetical infinite hosting cost with this model. This is not the case in the more traditional "on premise" model where the software is deployed on customer data centers and/or desktops. Architecturally then, you are better off not having to host what you sell on a perpetual basis. Unless of course, (a) you believe the up front charge can cover all the hosting cost (unlikely) (b) you know that the service will be time bound and therefore your perpetual license is not that perpetual after all (c) you can attach some additional monetization schemes after the perpetual license is sold (e.g. maintenance fee).

Summary: Good for the treasury, no need to do much from an architecture perspective to support this model, but watch out for hosting cost if you are in a saas model.

Subscription

The "per user, per month" scheme is, at least currently, the most popular option in the saas space. Akin to the perpetual license, it can be supported from an architecture perspective mostly "out of band". Meaning that here again, the billing/invoicing can be mostly separated from the application itself. A business contract can be established for say 50 users "out of band" of the application itself, and a monthly bill of 50 x cost per month is sent to the buyer.

The most important aspect that your architecture needs to do to support this monetization scheme is to verify that the user is 'current' on his monthly payment (as the license is to perpetual). In a hosted model, this can be done without having the application itself being aware of whether the caller is 'current' or not. The hosting infrastructure could check that 'out of band' by looking up into the payment database and restrict access to the application endpoint(s) (e.g. taking down the web site, modifying DNS entries, place site in read only...) for all customers not paying their bills.

From an architecture perspective, one could think of subscriptions as renewable time-bound perpetual licenses. This said, there are multiple areas where a provider could benefit from a tighter linkage between the order system and the application. Automatic/self provisioning comes to mind. But as mentioned, not strictly required by the monetization model.

This model also removes the problem of having to host 'forever' the customer; as it is a renewable monthly contract that is in place. Every month a new injection of cash is received from the buyer.

The issue for the seller here are more around customer acquisition costs and churn. Since there is no up front payment in this scheme, it usually takes multiple billing cycles (i.e. multiple months) for recovering the customer acquisition costs. So. if churn is high, customers might not stick around long enough to recover the acquisition costs. Although customer acquisition costs are mainly marketing related (awareness campaigns, introductory prices, free trials, referral fees...) good architecture as always can help :).

A typical example is to architect for self service and automation. An architecture that reduces any type of human intervention, reduces the operating cost. So, if you are giving away free trials, you'd better off if these free trials do not require (expensive) humans having to touch the system, run scripts, provision resources etc.

Another example is to architect for high density, i.e. trying to 'pack' as many free trial customers as possible in a single unit of infrastructure. Multi-tenancy here can come handy as well as virtualization technologies.

Summary: subscription base monetization is architecturally similar to the perpetual license in the sense that it can mostly be done "out of band", customer acquisition costs and churn are the elements to watch out for, architecting for self service, automation and high density can greatly help.

Usage based a.k.a. transaction based

In a usage based model, you cannot rely on a "out of band" model for monetization anymore; the architecture has to be able to meter the actual consumption of the service. This consumption can be captured either by the application business logic itself or by the hosting environment. It is often the case that if the monetization at the resource level (bandwidth, CPU, storage...) the hosting environment meters it; if the monetization is at the business transaction level ('check credit score', 'apply for open position') the business logic meters it.

In addition to metering that is now mandatory, another architectural aspects related to usage-based is the potential need of 'non repudiation of usage' systems. Trust between the service provider and service consumer is often enough to cover this, but in case of litigation or limited trust, there should be a way of getting to 'the truth'. There are multiple ways to handle this, one being using a 3rd party 'mutually trusted' auditor, another one is to emit billing events to the service consumers as they happen so they can capture them in their systems and correlate at each billing cycles whether the numbers match. It is a little bit like taking your own meter in a taxi and at the end of the trip comparing the taxi meter with yours (not sure what happens when there is a discrepancy).

There are other elements, but one can quickly see that implementing a usage/transaction based system is heavier on the architectural side than the "out of band" monetization schemes possible with the previous models.

On the plus side, usage based pricing is very low risk from the buyer perspective as the buyer only pays for what is actually used. The lower risk of usage means that service provider might be able to attract more companies to use their service(s). Zero cost of usage when the service is not used is a quite appealing proposition (compare that to your gym membership that you keep paying monthly although you never go there:). Free trials in the subscription model are of course low risk, but in the free trial model, the service provider incur an actual cost (part of the customer acquisition cost).

A good analogy here is the “pay as you go phones" vs. "phones with monthly plans”. My understanding is that pay as you go phones are marginally profitable and the strategy (hope?!) is to convert "pay as you go" customers into more long term profitable "with a plan" customers. Alternatively, once a consumers start using the service (and hopefully like it) the usage could go up and a “all you can eat” user/month model or hybrid model (N transaction included in your plan + $x per transaction after that) can be offered.

In other words, enabling an usage based monetization could be a good way to de-risk the trial of service without incurring potentially large customer acquisition costs while retaining an up sell opportunities once consumers increase their usage of the service.

Summary: this model has explicit architectural requirements: metering for sure, non repudiation... it can be a good way to offer a low risk access to buyers without exposing itself to the customer acquisition cost / churn problem.

ad-funded

The premise of this model is simple, consumers access software or a service for free and someone interested in their attention sponsors it. This model has been recently talked about as the 'ultimate disruption'; I am not 100% about that, so for now I'll stick to the architectural impact.

Most of the ad funded software I see, is monetized "around" the application. That is to say, the application or service has the central area of the screen and banners, links, sponsorships are placed around the application (think of search as a perfect example of that). In more complex application, there is a clear opportunity to modify the architecture of ad-funded software to allow 'in application' ad placement (as opposed to around); one can think of this as similar to 'in game' ad placement we are seeing in the latest console games.

Another aspect is that these 'around' ads are selected based on various level of assumptions about the user. The better the assumptions, the better the selection; the better the selection (a.k.a targeting), the more likely it is that the ad placement is effective (of course, other elements such as size and richness of inventory plays a role but let's leave these aside for the moment). A second opportunity for ad-funded software architecture is therefore to better capture the 'user context' that could lead to better capturing 'intent' that could lead to (more) accurate targeting.

At this stage I do not know, what sort of APIs should be exposed by ad-funded software to allow 'in application' ad placement and even less about how 'intent' can be better captured, but be reassured that these are topics that are being investigated.

Summary: ad-funded software has proved to worked in certain areas of the software industry, we are still in the infancy of how to architect for ad-funded optimization.

As we have seen (albeit only superficially), monetization has many impacts on software architecture, some are known (e.g. metering) others are new (e.g. 'in application' ad placement). There is a clear need in better understanding these models and extract best practices in all of these. So, expect more in depth entries from myself and members of my team on this topic soon.

As always, comment/feedback welcome.

2008 the year of INTRAnet-SaaS / INTRAnet-S+S

gianpaolo — Mon, 31 Dec 2007 20:50:00 GMT

In the next couple of days I might have fun again and offer my 10 or so 2008 predictions as I did in 2007. (many of which I think are still very valid) but in case I don't, I wanted to make sure that at least this one gets out.

- 2008 will be the year of the INTRAnet-SaaS (or INTRAnet-S+S)

Similarly to what happened about 10-12 years ago where the growth of the Intra-net was faster than the Inter-net (certainly in terms of $ if not in global terms), in 2008 SaaS (and its evolutionary successor S+S) will grow faster inside the corporate boundaries than outside.

Of course I have no data whatsoever to back this up J, but as an observer of the SaaS phenomenon and mainly through my very frequent interactions with enterprises and ISVs, it is what my senses are telling me. (Just to cover my back I will use the good old Gartner trick and add a 0.7 probability to it; so, if it does not happen, I was not wrong, it was just the 0.3 probability of this not happening that occurredJ)

More seriously, let me give you a few reasons why I am increasingly convinced of this:

- SaaS/S+S architectures are beneficial regardless of whether the service provider is “in the open cloud” or “in the corporate cloud”:
Metadata driven customization and other SaaS best practices as described in LitwareHR resulting in economies of scale are great solutions for multi-departments/multi-geographies deployments, frequent in large enterprises. An example I heard a few times is a bank investigating the deployment of a multi-tenant version of an e-banking system for the multiple geographies they do business in, rather than deploying multiple times a hard coded configuration of the same e-banking system. Another area where Intranet-SaaS best practices can be applied is around the ‘shared services’ initiatives that I have heard about many times, especially in the public sector space.
The benefit are not only technical or cost driven, Intra-net SaaS can enable a more mature monetization schemes for central IT delivered services. Under this model, “subscription” and/or “usage-based” monetizations can be introduced more easily and replace the somewhat unfair traditional “flat fee” taken as a % of revenue by IT.

- Data:
#1 concern of adopting SaaS is data control (protection, ownership, privacy, compliance…) all of this goes away if data remain within corporate boundaries. Enterprises get the benefits (albeit reduced) of SaaS without giving away control of their data.

- Kicking the tires:
Going to the cloud for IT capabilities is a big jump for many enterprises. Doing it internally first allows them to learn, at reduced risk, the ‘ropes’ of externalization of IT services. Of course, in this case the externalization stays within the enterprise so the benefit are reduced as the potential economy of scale is lower, but at the current level of maturity and trust, the reduced risks will win the trade off battle vs. reduce costs. Over time, intra-net delivered services could move to the Internet.

- Alignment to existing SOA initiatives:
SaaS / S+S initiatives within the corporation will be aligned (assimilated) with the current SOA initiatives (as multiple people have told me: S+S is “just” SOA done right). The fact that there is already mindshare and willingness to invest in SOA within the enterprise will facilitate investment in SaaS/S+S if kept within the enterprise.

To preempt comments from readers, 2 caveats:

1) Of course, the larger the company the bigger the benefit. I would argue that any company with more than 50’000 employees managing multiple thousands of servers with more than say 20 subsidiaries would benefit from it. This is a very very crude estimate. It is very likely than smaller companies could benefit from it. Larger ones (Global 1000 etc.) would absolutely benefit from it.

2) Over time, internet-saas will move to the cloud to a “purer” internet-saas. Economy of scale and optimization opportunities are even bigger when performed at Internet scale, but this will happen only when (among many things) service providers will have attained the level of trust required to take ownership of sensitive corporate data, and enterprises will have attained a level of internal maturity where “letting go” of IT capabilities will be seen as a form of strength and not weakness. Today for the general case, neither of these is true.

In conclusion, I argue that not only enterprises would benefit from building their own software following SaaS best practices, but maybe more interestingly ISVs would benefit from making their SaaS solutions re-hostable by large enterprises, regardless of what Credit Suisse analysts say about the higher multipliers they are willing to give to the pure play SaaS ISVs.

Firstly, because the enterprise (for the foreseeable future) is still where the money is, hence IMO a lower multiplier of a larger revenue base is better than a high multiplier of a non profitable company. Secondly, ISVs selling a intranet-saas deployment solution might be able to command “traditional licensing” models as opposed to “per user / per month” models which based on empirical evidence are, at least currently, not as attractive for the seller.

As usual, feedback very welcome.

Looking forward to seeing 1 year from now where this prediction held water or if was just another random thought of a dotcom refugee J

Happy New Year!

No Hobbits but great chat with Lukas

gianpaolo — Sat, 15 Dec 2007 13:51:00 GMT

When I went to New Zealand I did not manage to see any hobbits but I had the pleasure to record an ARCcast i.e. architecture podcast (direct link to podcast here) with Lukas Svoboda; not too surprisingly, we discussed Software + Services and SaaS from an Architect's point of view. The talk covers various aspects such as:

What is the difference between “Software plus Services” and “Software as a Service”
Explore the different audiences of S+S/SaaS: Builders, Hosters and Enterprise Consumers
Explore the focus of many SaaS providers around purely being web based applications
How Microsoft technologies aid S+S initiatives
The significance of SOA to S+S/SaaS

Link to the podcast here
Link to ARCast New Zealand post here
Link to Mark Carroll commenting on this podcast here

ISVs are from Mars, and Hosters are from Venus

gianpaolo — Thu, 08 Nov 2007 22:06:43 GMT

It took us a bit longer than expected, but our latest white paper is finally here! This white paper goes through the sometime quirky relationships that exist between ISVs wanting to deliver their software as a service and Hosters.

Here is an excerpt from the paper:

The Impetus for Specialized SaaS Hosting

The case for specialized Software as a Service (SaaS) hosting can be easily rationalized by examining an incompatible pair of anecdotal fact and reality:

Fact: When we explore the expertise of software vendors today, we find that most of them will not claim operating a hosting environment as a core competency. Actually, many would also cite operational excellence as a key barrier of entry into the SaaS market. This observation should not come as a surprise to the reader.
Reality: However, when we take a look at the prevailing market situation, delivering SaaS applications often depends on hosting solutions that are “home-brewed” by the software vendors themselves. This is to say that in addition to implementing the application logic, many SaaS software vendors themselves will need to design, develop, and integrate the operational modules for their service offerings. As illustrated in Figure 1, the service delivery components, such as billing, metering, and logging, are built by the application vendor and integrated into the application stack.

The key observation from the datum above is that many ISVs are re-implementing operational components by necessity, not because those infrastructure additions provide significant value to differentiating the core features of the applications. Moreover, building these components add to the time and cost of delivering the application. Therefore, for the software vendors, most of such redundant work and expenditure can be eliminated if the software vendors can obtain the same operational functions from third parties that specialize in SaaS hosting.

Link to the white paper here. As usual, feedback very welcome.

Thanks to our Venusian co-author Matt who helped us better understand the Hoster point of view.

Enjoy!

Complexity does not go away, it just changes hands...

gianpaolo — Tue, 28 Aug 2007 21:26:12 GMT

A law that I always found interesting in Physics is the the Lavoisier Law which states that the mass of a closed system of substances will remain constant. In other words, matter cannot be created nor destroyed, it can only change form. (just for the purists: of course this law does not hold in special relativity or quantum mechanics where photon (which are mass less) are emitted, but I don't think we are ready to discuss software as a service in quantum terms quite yet :) Anyway... the point is that a similar "law" could be expressed in the context of software as a service: In a closed system, software complexity does not go away, it just changes hands.

The fact that (metaphorically) a SaaS customer can just "plug" into the service fabric and get immediate access to LoB application is because the delivery of the application (e.g. hosting, monitoring...) shifted to the provider, not because the delivery complexity disappeared. It seems obvious when stated like this, but based on a few conversations I had recently it often seems to be forgotten.

In this case, a first approximation of a "closed system" where complexity stays equal (but changes hands) is the Enterprise-ISV-Hoster trio. (The reason I said first approximations, is because there are additional entities that could participate in the closed system, such as system integrators, resellers, aggregators, multiple layers of hosters...). In other words, all the functions of software consumption and service delivery must be present somewhere in Enterprise-ISV-Hoster trio, otherwise the "law' of conservation of complexity would break, which, a part from maybe a few relativist or quantum cases, is impossible :)

Since complexity does not go away, the value proposition of an ISV is to shift complexity from Enterprise to ISV by offering SaaS and the value proposition of an Hoster is to shift complexity from ISV to Hoster by offering a Service Delivery Platform.

In this situation, Enterprises concentrate on using software they need, ISVs focus on building domain specific software and Hoster focus on the delivery plumbing and SLAs. This is IMO a much better model than stretching core competency by performing someone else expertise (i.e. ISV self hosting)

Note that the Enterprise/ISV/Hoster separation of concern is at the conceptual level, nothing prevents a large enterprise (Global 1000 type) to perform the 3 roles of 'using', 'building' and 'delivering' software (intranet-saas?!) but keeping these functions separate would benefit them.

Make sense?

P.S.

I'm pretty sure that I could also have plugged the second law of thermodynamics stating that in an isolated system (i,e, without any external 'work') entropy can only increase. But I will leave that for a future post. :)

Efficient Software Delivery through Service Delivery Platforms

gianpaolo — Thu, 05 Jul 2007 21:20:10 GMT

Several weeks ago, we wrote a introductory article on service delivery platforms published in the Architect Journal. If we don't count blog entries, this is our first published article looking into "running" software delivered as a service. Over the next few months our goal is to complement our LitwareHR reference implementation (which show how to "build" software as a service) with another reference implementation Northwind Hosting (?!) which will encapsulate the service delivery platform best practices.

Below an excerpt of the article. Full article here.

"[...] There is, however, another means of improving efficiency which ISVs have not adopted with the same enthusiasm: the use of an underlying Service Delivery Platform (SDP). Adoption has been slow mainly because service delivery platforms optimized for line-of-business applications delivery are still in their infancy. But both existing and new actors in the hosting space are quickly building compelling capabilities. This paper explores the goals, capabilities, and motivations for adoption of SDP, and describes the technology and processes related to efficient software delivery through SDP. [...] The downward flow of horizontal capabilities from ISV “plumbing” into frameworks, and then into core platforms can be generalized further to cover the scenarios of software delivered as a service. In this sense, an SDP becomes an “operating system” for service delivery.”[...]

As usual feedback/comments/questions welcome.

Intra-enterprise SaaS

gianpaolo — Thu, 05 Jul 2007 05:08:03 GMT

Today, on his blog, Sinclair asks: Can the Fortune 500 Achieve Efficiency through Intra-enterprise SaaS?

The answer is obviously YES!

A lot of the concepts built in software as service such as multi-tenancy, meta driven customization, self service (try before you buy) are great practices whether you are delivering software over the Internet or Intranet. Granted the economy of scale you can get within an enterprise is not as large than in consumer or LOB over Internet scenarios but they are very real.

The same can me said about Service Deliver Platforms (SDP). Some capabilities of an SDP, e.g. Billing, might not be as important in a intra-enterprise scenario (even though cross charging access to services is an increasing practice in enterprises), but many other aspects of an SDP, for example facilitated on-boarding through a declarative manifest (as described for example in Eugenio's blog here) are very relevant.

I would argue that SaaS is taking the same path than Wiki, blogs etc. These technologies or concepts gained success in the consumer / Internet space first and are now gradually migrating into the enterprise space.

As we mentioned in our paper a few months back, enterprises are spending a lot of cycles understanding how to "consume" software as a service, i.e. the integration and composition challenges of embracing an "extended view" of SOA, including services in their own data center and services in the cloud. But as hinted by Sinclair in his post and based on the numerous discussion I had with Global 1000 companies at various Microsoft executive briefings, there is also a lot of interest in introducing these service delivery best practices in their own software development.

P.S.

As a reminder a lot of these best practices are implemented in LitwareHR our reference implementation available on Codeplex.

Either I don't get it or I'm calling (at least partial) BS on SaS 70

gianpaolo — Sat, 30 Jun 2007 10:05:12 GMT

Please educate me on SaS 70 as either I don't get it or its importance is in my opinion overly inflated.

I keep hearing from various analysts the importance of SaS 70 (preferably type 2) certification for SaaS vendors; and I of course hear a lot of SaaS vendors who went through the process, gloating about their SaS 70 (preferably type 2) certification. But, unless I am missing the point, SaS 70 is NOT a quality label. According to the web site http://www.sas70.com/about.htm (my emphasis)
SAS No. 70 provides guidance to enable an independent auditor ("service auditor") to issue an opinion on a service organization's description of controls through a Service Auditor's Report (see below). SAS 70 does not specify a pre-determined set of control objectives or control activities that service organizations must achieve. [...] A SAS 70 Audit is not a "checklist" audit.

My understanding is that the auditor will ask about the controls you have in place, and will verify that what you do is what you say you do. Which is IMO very different than verify that what you do is what you should be doing. In other words, the main value of SaS 70 is to have an independent auditor certify that you are not lying about what you are doing, not that you are doing the right thing.

Continuing to read the description of the service:

A Type II report not only includes the service organization's description of controls, but also includes detailed testing of the service organization's controls over a minimum six month period.

Cool, now the auditor is not only making sure you are not lying about what you say you are doing, she will also test for 6months that what you are going to do is what you told her you were doing. This has again the same limitation, the control themselves are not judged, their existence and application is tested for 6 months not their quality.

The description of the SaS 70 engagement mentions that the service auditor will express an opinion, including whether the controls were suitably designed to achieve specified control objectives. Same story here, the opinion is about whether what you are doing is coherent with your objectives, not an opinion about the objectives themselves. Let's take this ridiculous and extreme example: if you have as an objective to trash the data every week and your controls are a perfect match for trashing data every week, would the opinion be positive? I personally don't know, but based on the way SaS 70 is described it would seem so.

Also, and bear in mind that I have never met a SaS 70 auditor but based on the description they are professionals who have experience in accounting, auditing, and information security. I hope the one who audited the vendor you are considering buying from, was more of the latter type (information security) and not too much of the former (accounting type). Don't get me wrong, I value CPAs very much, but not necessarily for making sure that the multi tenant database design will be preventing cross tenant data leakage.

Frankly, based on my current understanding (and PLEASE, as mentioned at the beginning of this post, educate me if I am completely missing the point) SaS 70 seems to be more a "checkbox" that SaaS vendors seem to be forced to have due to all the recommendations out there about being certified than something that is really important to actually have.

Yes, making sure that a SaaS vendor is not lying is critical, but (a) hopefully I have other ways of assessing that (e.g. referrals comes to mind) (b) the fact that the vendor is not lying is a necessary condition for me to buy from him, but it is not sufficient. Not lying is not equal knowing what you are doing.

Don't take this post as a mockery of SaS 70, but an attempt to (1) better understand myself what the big deal around SaS 70 is (plus get educated if I am wrong) and (2) hopefully raise some awareness around the possible misconceptions of what SaS 70 really is, so SaaS buyers and vendors understand what they are really getting out of it.

Are you a SaaS vendor SaS 70 certified? What did you gain (a part from the checkbox)? What was your experience? Please leave a comment, I'd love to know.

P.S.

Maybe I should ask a SaS 70 auditor his own SaS 70 type 2 certificate and see what type of opinions come out :)

Phil on SaaS Appliance

gianpaolo — Tue, 19 Jun 2007 19:38:15 GMT

I read with interest Phil's post on SaaS appliance and how a few companies are using this model for "putting SaaS on-premise" as Phil says. Phil's commentary is very similar to what we had published in the past in our enterprise perspective white paper here, or Fred's post here where software as a service can be seen as a continuum of possibilities along multiple axis: location being one of them. Other continuum can be around licensing, life cycle management, UX etc.

Coming back to the appliance model, one thing that is important to note is that the appliance model is very likely to use an isolated model (1 appliance - 1 customer) therefore highly limiting the opportunity of economy of scale for the provider, chopping off a bit chunk of the long tail. On the other hand, as described in Phil's post, an appliance can help overcome the data security concerns that many customers have as data will likely be stored within the appliance (inside the corporate firewall).

Another aspect I discussed a while back with a company interested in delivery their solution as an appliance was the reluctance from many Enterprise IT operators to punch a 'hole' into their firewall (allowing "Internet initiated" connections) required by that company to remote manage the appliance. Of course there are other ways of solving that problem typically by leveraging already existing VPN infrastructure etc. but this was going against the "just plug this appliance into your rack and everything works" (a.k.a. jptaiyraew) model.

Anyway, all these continuums and trends confirm something that we have believed in for some time now: the browser-only; cloud-only (a.k.a. BOCO) delivery of services is far from being the only way to deliver software a service and I would go as far as saying that it is actually a bit limitative view of SaaS.