Gianpaolo's blog

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

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

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

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!

I think Phil drank the Kool-Aid too but he has not realized it yet :)

Phil believes that I did drink too much Kool-Aid.

But after reading his post, it seems to me that we agree on most of the points, or maybe it is the Kool-Aid again :)

He says:

The answer, my friend, is ‘yes’. Here’s Gianpaolo’s justification for still wanting to buy an Office licence and run Microsoft’s productivity software on his PC at home:

“… as far as user interaction is concern[ed], I am a big believer in bringing it as close to the user as possible. Why would I ever want the cloud between me and my work?”

I totally agree with this point of view. But instead of going to all the trouble of buying a licence, installing the software locally and then having to maintain it, why not let the cloud bring the application to your desktop whenever you need it? That’s why Adobe developed AIR, why Google has Google Gears, and why Microsoft has developed Silverlight (in addition to investing in Softricity’s desktop virtualization software).

AIR, Gears, Silverlight etc. are not the applications you want to use; they are the containers of the applications you want to use. Once installed on the client machine, they offer a well known 'client side' execution environment that service providers can take advantage of if/when they want to offer a local, often richer UX and/or offline support. Difficulty or easiness of deployment aside, this is conceptually not different than requiring a specific version of Office, .net framework or Firefox to be installed.

Which brings me back to what I was saying in my previous post:

the problem is not running client software (there is plenty of CPU, Memory and Disk at the edge), the problem is easy deployment. I would rather focus time on fixing the root cause (deployment) than working on the symptoms.

This is why A LOT of effort are put into making deployment of these technologies on the client machines easy, fast and not requiring elevated privileges and/or technologies such as Softricity (as Phil astutely indicated as relevant) can play a big role in this model.

I reiterate my premise. Rich 'client-side-software-enabled' user experiences combined with hassle-free-infrastructure back-end hosted services is a far superior model than a cloud-only 'pure' SaaS model. The price to pay for this is deployment of the client piece, but thankfully deployment technologies and/or client side containers are increasingly facilitating all this.

Now if you don't want to call this Software + Services, it is fine by me, but it is what S+S is about.

For completeness, I need to say that rich client UX + hosted services is not the only scenario that the S+S model enables. There are plenty of others, specially in the enterprise where data ownership, regulatory compliance etc. are big decision factors, where S+S make sense but let's stick to the Office / Office Live Workspace scenario that initiated this discussion.

I was about to stop my entry here, but I decided to add another quick proof point that when we talk about AIR, Gears, Silverlight we are talking about software problems not services problems:

If you think about it, AIR, Gears, Silverlight etc.:

(a) they have to be installed on the PC before being of any use, this can be done through 'click here' type of downloads, through distribution deals with OEMs, or 'included' with other popular applications such Acrobat, toolbars etc.

(b) when a new version of these technologies is released, it needs to be redeployed on the client machines, at least for taking advantage of the new features available in the new client side container (e.g. better streaming, access to peripherals...); again either using techniques mentioned in (a) or using some sort of software updater as part of the installed software.  

(c) any breaking changes with code built against older versions have to be handled

(d) penetration of AIR, Gears, Silverlight... on client machine is a key metric for deciding whether to rely on it being present for the client piece or not

(e) ...

... in other words not that different from any other 'client software'.

And again, why would anyone want to go through all these hassles when a 'pure/cloud only' solution would remove all that: because it is MUCH better for users to interact with software locally than on the remote side of the cloud.

I too would love to live in a world where everything happens magically, but until the laws of physics will dictate how things happen on earth :) hybrid models, such as S+S are the best way to mitigate the different constraints.

At the end of the day, I think Phil and I are disagreeing more on the semantic of the term S+S than on the model itself.

S+S: Real or have I drunk too much Kool-Aid? :)

Readers of this blog must have seen that recently I have been spending quite some time discussing 'software + services'. I know that Phil thinks S+S is bunkum but I have to disagree on that one. Of course, an S+S world would disproportionately benefit Microsoft as it is the only company with massive assets on both sides of the equation, but it is not why I believe in it. I believe in S+S because when done properly it is far superior to a 'cloud-only' SaaS model.

Here is a classic example:

I love Office 2007, the interface is clean, efficient and now very familiar. Far, far, far superior to any web based productivity tools I tested. The problem of course was collaboration and anywhere access. How do I share documents with others and/or how do I access my docs from anywhere. Now I use Office Live workspaces in conjunction to Office. The combination of the two is very appealing:

I use Office (Word, Excel, Powerpoint) locally to author a document, presentation or spreadsheet and Office Live workspace in the cloud to collaborate with others and as an anywhere access store. The integration is very smooth via the Office add-in. As shown in the image below:

(note that these type of solutions have been around for quite some time within the corporate boundaries of enterprises, and/or with Office Live; the big difference here is that it is now available 'out there in the cloud' for free (well ad-funded). Of course you need to have Office on your machine, but with Home and Student edition going for <$150 I find it a price worth paying for both the features and the local/offline aspect of it. (disclosure: as an employee I pay less than that for Office (for private use), but I would easily be willing to pay $150 was I not an employee)

I agree with Phil though that having the back end as a hosted solution is very good. No hassles in term of installation, data backup etc. but as far as user interaction is concern, I am a big believer in bringing it as close to the user as possible. Why would I ever want the cloud between me and my work? As I mentioned many times in this blog, the problem is not running client software (there is plenty of CPU, Memory and Disk at the edge), the problem is easy deployment. I would rather focus time on fixing the root cause (deployment) than working on the symptoms.

I have to confess that I miss 1 feature in Office / Office Live Workspace combo that I find very powerful in several web based productivity tools: the ability to have more than 1 person work on the same document  at the same time. I mitigate that with the usage of SharedView but in the few cases of "real time" collaboration, concurrent access to the document is better. But this is a missing feature not a fundamental flaw in the model.

So tell me, is this really an appealing hybrid model? Or have I drunk too much Kool-Aid? :)

LitwareHR v2 Webcast

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"

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 :)

Introducing Narumoto-san

Many of the readers of this blog also follow Fred's blog and Eugenio's blog. It is now time to add another feed to your favorite RSS reader. It is my pleasure to introduce a new fearless architect in my team: Masashi Narumoto. Below Masashi finding better ways to architecting software services.

More seriously, Masashi multiple areas of focus will be architecting consumer oriented services, thinking about social network as platforms and ad-funded software. If these topics are of interest to you, his blog is here; check it out!

P.S.

it looks like I will have to update this picture.

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

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

FYI: my LinkedIn contact

In the last couple of weeks, I finally decided to create an account on Facebook and LinkedIn. (I know, many of you must think that I am almost a Luddite for doing so only now)

Anyway, as one would expect, I went through (and still going through actually) my old schools networks, my current and past jobs contacts etc... but I realized that a lot of the people I would like to connect with are the readers of my blog. The reason is very simple, over the past couple of years, many of the comments, questions, feedback I received through this blog led to great "offline" conversations. However, once the conversation ended, I lost touch with the brilliant mind (or minds) involved in these cyber-discussions. What a shame!

So, for those of you who want to keep in touch here is my contact on LinkedIn:

I am also on Facebook, but as many, I use Facebook for more personal associations. So I will be a bit more selective on the Facebook requests. 

Looking forward to be "connected"

Happy New Year

No Hobbits but great chat with Lukas

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

More about S+S

I just got back from a 2 weeks tour in Australia and New Zealand discussing with a lot of ISVs, Hosters and Enterprises about SaaS, SOA, Web 2.0 and how they related to Software + Services (S+S). The details and key learning of this tour will be the object of a future post, but at a high level I believe people are getting the point of an hybrid model that S+S suggests.

However, it is true that there is still a bit of confusion of what S+S really is. In an attempt to provide some additional clarity, I wrote a bit of "tongue in cheek" article published in the Architecture Journal; direct link to the article here.

As part of this tour I also gave a few press interviews, one of which (article here) was picked up by SaaS Week blog claiming that I am pooh-pooh-ing SaaS. After all the work we have done in my team to promote SaaS (suffice to look at this blog archive) I found it funny to be characterized as such. What I said in the article and I believe in it, is that SaaS would benefit greatly in introducing a local software component to it; not only for offline capabilities, but also to support a device strategy or simply because some data will never be able to leave the corporate boundaries.

If you look at what we did with LitwareHR v2, we took a "pure" SaaS application and took it to a "higher level" by allowing smart client access, offline, rich visualization, office integration, leveraging of cloud building block such as silverlight streaming, without changing the existing "pure" SaaS model. I think it is a good example of a solution that embraces the S+S model without breaking the existing SaaS model; which is coherent with my quote: "Software + Services embraces SaaS but goes beyond it,” Mr Carraro told iTWire. “You can think of those two as concentric circles where SaaS is one aspect of Software + Services."

LitwareHR v2: from SaaS to S+S

Unless you have been abducted by aliens a few months ago and just returned to earth I am pretty sure you have heard of Software + Services or S+S (if you have been abducted and just returned, hence not heard about S+S, I suppose you have bigger issues to deal with than knowing what S+S is right now...). Anyway, for people not abducted by aliens and therefore looking for S+S guidance, I am pleased to announce LitwareHR v2.

This release extends LitwareHR, the reference SaaS application we released a few months back, and provides guidance on building S+S solutions taking advantage of the full spectrum of what S+S offers (Client, Server and Services) as shown in the picture below:

In a S+S world, solutions are not either pure SaaS (a.k.a. "in the cloud") or fully "on premise", rather they are a combination of local software and Internet services interacting with one another: local software making “cloud” services better and cloud services making local software better.

From a guidance perspective, LitwareHR v2, takes all the foundation we built around multi-tenant / try before you buy / meta data driven "online services" released in v1 and augments it with:

- a rich client WPF based front end showing guidance in disconnected/offline scenarios as well as allowing "power users" to tap into rich visualization and local resources

- a "cloud service", in this case Silverlight Streaming by Windows Live handling video resumes posted by applicants

As usual, we focused much more on the HOW than completeness of features; another way of saying this is that LitwareHR v2 is meant to be deep architecture guidance not a fully features HR solution.

Based on frequent requests, also included in the release is a new Multi-Tenant Database Performance Guide, which provides tests results and guidance to compare the performance and scalability of different extensibility patterns in multi-tenant SQL 2005 databases (extension tables vs. XML data types vs. fixed columns). Some screen shots to give you an idea of what you will get below:

Next step: download the release (bits and documentation) here: http://www.codeplex.com/LitwareHR/Release/ProjectReleases.aspx . There you will find both LitwareHR v2 and the performance guide.

FYI: the code is released under the permissive license so read the license (or have it read by your lawyer) but the license (as its name indicates) is very permissive; we expect to see a lot of people being "inspired" (copy/paste?) by it.

Feedback, comments, questions as usual very welcome. And make sure to check out Eugenio's blog I am sure he will publish some additional info soon.

Enjoy!!

P.S.

For those interested in bit more info before going to codeplex and downloading the bits, below some more info about the release.

Architecture Challenges Demonstrated

· Designing a “back-end as a service”:

o Multi-tenancy 

o Application customization: metadata driven application for tenant extensions at the UI, business logic and data access layers.

o Performance and scalability of extensible, multi-tenant applications.

o Service Layer design: functional web services and meta-data web services to enable different consumption experiences (multi-head application)

o Claims based authorization

o Tenant resource provisioning

· Designing “front ends” for SaaS applications:

o Designing extensible web clients

o Smart Client with tenant customization, offline operations, claims based authorization and integration with local resources (Desktop search)

· Taking advantage of “Cloud Services”:

o Integration with Silverlight streaming from the UI (Web and Smart Client) and services layer (programmatic access).

· Performance assessment of database extensibility methods

o Using XML data types vs. fixed columns vs. extension tables with different loads, concurrent users and usage patterns (select vs. update vs. insert)

Some Release highlights

· LitwareHR enhancements highlights:

1. Platform upgrade. Updated LitwareHR v2.0 to run on Windows Sever 2008 and Microsoft Visual Studio 2008 (Beta 2). This included leveraging new technologies like Active Directory Lightweight Directory Services (ADSLDS), new management APIs and IIS7.

2. Data access performance improvement. Based on the results of the Multi-Tenant Database Performance test (see below) updated LitwareHR data access code and tables design.

3. Services Enhancements. Created new services leveraging Windows Communication Foundation 3.5 features to enable RSS & REST interfaces.

4. Silverlight Streaming mash-up.  Augmented LitwareHR services with Silverlight Streaming Services. Demonstrated in the “Submit Video Resume” feature.

5. Smart Client Application. Updated the original WPF based Smart Client showing consumption of LitwareHR functional and meta-data services even with offline support

6. Vista Gadget. Extended LitwareHR UX a Vista Gadgets consuming REST interfaces.

7. Improved guidance deployment. Moved from the old document  + readme + bunch of scripts approach to a 100% automated one, including dependencies checking and configuration.

· Multi-tenant Database Performance Guide:

1. Database extensibility patterns comparison: performance test results for common database extension methods: XML data types vs. Fixed columns vs. Extension tables.

2. Test Tools, Scripts and Documentation. In addition to the results of our own testing, we are shipping the tools, scripts and instructions for anybody to repro this tests in their own environments and conditions.

ISVs are from Mars, and Hosters are from Venus

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!