Gianpaolo's blog : S+S

PDC is over, it was awesome! Now, off to Sydney

gianpaolo — Sat, 01 Nov 2008 21:17:28 GMT

What a week at the PDC!

With the CTP release Azure Services Platform I don't think that anyone is doubting anymore about Microsoft ability to understand and execute on "the cloud". But PDC was not only about the cloud, there was tons of stuff on the "this side of the cloud" i.e. the client with for example the first comprehensive public demo of Windows 7 and Office Web Applications.

(For those of you who were not in Los Angeles this week all of the sessions are available for download on channel 9)

But of course, what makes PDC special is the people. The reactions and feedback I heard from attendees were fantastic. A couple of my favorite quotes were: "I think I might buy some Microsoft shares again" and "Microsoft is back baby... Hey mr Google, bring it on" :)

But no time to rest, tomorrow I'm off to a great event in Sydney, share some love with the developer community there. Let's see if Steve Ballmer who is doing the opening keynote at the event will do his (now legendary) "developer, developer, developer..." chant

Speaking of Sydney, a couple of days ago at the PDC, I had a great chat with Michael "the delicate genius" Kordahi. After a few minutes he pulled his camera and made a 4 minutes impromptu interview.

http://delicategeniusblog.com/?p=775

Cloud Services Architecture symposium

gianpaolo — Wed, 24 Sep 2008 19:40:00 GMT

As indicated in various press articles and blog entries in the recent weeks, PDC will be Microsoft's 'coming out' party for its cloud services platform.

These additional platform assets will create a vast array of new possibilities, but at the same time introduce new architectural elements that architects and developers will have to master. Remember there is no such thing as a free lunch or as economists would say, there is an opportunity cost. (I know there aren't many credible economists left around here these days but some of their jargon is still applicable, especially in software architecture where we don't have things like credit default swaps...)

Anyway, going back to Microsoft and the cloud computing platform, my team along with many of our colleagues are putting together a cloud services architecture symposium on Day 4 of PDC. Titled Head in the Cloud, Feet on the Ground, this symposium will take an enthusiastic yet pragmatic look at the cloud opportunities. We will explore a few examples of cloud-based infrastructure usage as part of an existing application, we will discuss the architectural tradeoffs as well as best practices resulting from that usage. We will also walk through detailed examples of ‘enterprise grade’ hosted application design. And finally we will go through emerging patterns that take into account the physical aspects of a cloud-based application that are often overlooked, such as bandwidth which happens to be not infinite and certainly not free at high scale.

We believe it will be a good show packed with relevant and actionable guidance, so if you have not registered yet, here is the registration link, if you are coming, I will be looking forward to seeing on day 4 at the symposium.

As teasers, a couple of slides we are working on for the event.

P.S.

PDC is of course much much more than this symposium, with exec keynotes, demos, a few hundred sessions, if you want to see what will be presented have a look at sessions page and/or subscribe to the announcement blog

P.S.S.
corrected a few typos

A little English lesson for cloud lingo lovers...

gianpaolo — Tue, 02 Sep 2008 23:16:33 GMT

Being a non native English speaker I regularly make pronunciation or grammar mistakes and I usually don't mind. There is one thing I learned today though that I found amusing mostly because it is a small mistake that is commonly made by pretty much everybody (English native speakers included). It is the usage of 'on premise' in the context of cloud computing, as in for example: does the software run on premise or in the cloud? It should be: does the software run on premises or in the cloud?

When corrected, I initially thought it was a tomäto – tamāto (/təˈmɑːtəʊ/ - /təˈmeɪɾoʊ) thing. But after checking on dictionaries, the correction was justified, premise is not the singular of premises (when used to mean buildings).

Premises are land and buildings together considered as a property. This usage arose from property owners finding the word in their title deeds, where it originally correctly meant "the aforementioned; what this document is about", from Latin prae-missus = "placed before".

Some people suppose that since "premises" looks like a plural, a single house or other piece of property must be a "premise"; but the word "premise" is reserved for use as a term in logic meaning something assumed or taken as given in making an argument.

Of course Wikipedia had that right already: http://en.wikipedia.org/wiki/On-premise_software

On-premise software, is a common, although incorrect name for on-premises software. On-premises software is installed and run on computers on the premises (in the building) of the person or organisation using the software, rather than at a remote facility, such as at a server farm somewhere on the internet.

Who would have thought that one day I would share proper English usage with my fellow nephologists :)

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

Software + Services for Architects Webcast

gianpaolo — Tue, 22 Jul 2008 03:41:20 GMT

A couple of weeks ago, I recorded a webcast (~1hour) going through some of the architectural challenges faced by ISV architects in building S+S solutions, as well as the ones faced by architects in large enterprises consuming S+S solutions. Below a couple of slides from the webcast:

The Enterprise Perspective (Big Pharma)

The ISV Perspective (LitwareHR)

Due to the 1 way nature of a recording, if you have any questions or comments, please contact me via this blog and/or leave comments.

Once again, the link to the webcast is: Software + Services for Architects (webcast)

Enjoy!

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.

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.

Consumerization of IT: an example

gianpaolo — Thu, 27 Mar 2008 20:47:41 GMT

Over the last 2 years or so (here and here for example), I have been discussing how consumer grade IT services might/will be used as part of enterprise IT, Gartner even says that Consumerization Will Be Most Significant Trend Affecting IT During Next 10 Years.

Today, Eugenio pointed me to a blog entry from our mutual friend EdJez describing how the IT environment of his company (a non-profit small org) is mostly (entirely?) handled through cloud infrastructure, free service and desktop software. Very interesting read.

Of course, there is a HUGE difference between a small non-profit and a Global 1000 company in terms of requirements, risk tolerance etc. but IMO Ed's blog post is nevertheless interesting for any sized company.

Also interesting is Ed's "wish list" at the end:

Offline access
Unified authentication
Support for Integration

as well as his last comment:

I'd like to see more sites view themselves as 'building blocks' -- as part of a larger solution instead of trying to be the 'one stop shop'. Data, process, and UI integration APIs are always welcome.

All of this very much in line with was has been discussed in this blog and S+S strategy in general.

Thanks Ed for sharing and keep up the good work.

S+S Architecture Site on MSDN

gianpaolo — Sat, 16 Feb 2008 00:46:21 GMT

Yesterday, we released (here) on the MSDN Architecture center a section dedicated to Software + Services (S+S).

We realized that depending on whether you are a large enterprise, an ISV, a hosting company or trying to establish yourself as a trusted marketplace for software services, you will have a different perspective on S+S. This site's intent is to cater for these different perspectives, by offering 4 sub sections:

how to build S+S
how to run S+S
how to consume S+S
how to monetize S+S

Note that it is the v1 release of the site so I am very open to feedback, gaps, suggestions etc. the only request is that you be constructive (if you don’t like it, please offer a suggestion, if you think things are missing, please provide us with of as detailed as possible description of what you are missing etc.)

Feel free to send me email via the contact link on the right hand side of the blog or by leaving a comment.

Enjoy!

LitwareHR v2 Webcast

gianpaolo — Thu, 07 Feb 2008 21:41:15 GMT

Yesterday I recorded a 25min. walk through of litwareHR v2 (recording available here)

Even though the primary goal of LitwareHR is to elevate architectural best practices in a Software + Services world, this particular webcast does not dive very deep in the architecture of the application, rather it shows what the application does. If you like what it does you will like how it does it even more.

In summary:

Walkthrough here (what the app does)

Installer, code, etc. here (how it does it)

Enjoy!

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