Michel Baladi on software

I'm moving on...

mbaladi.net — Fri, 30 Mar 2007 12:43:00 GMT

After a six and a half year career at Microsoft, first as a principal consultant in Microsoft Consulting Services and later as Architect and Technical Lead in the EMEA Microsoft Innovation Centre (MIC) in Denmark, it is time fo me to move on.

Lately I have been working almost exclusively with innovation and software as a service (SaaS, and now it's time for me to stand on my own legs and practice what I hav been preaching. As of April 1st I will be doing free-lance consulting (mainly SaaS related) and also go back to my roots by starting a SaaS ISV with a couple of friends.

From April 1st, my blog will live at http://blog.baladisoftware.net and my web site will be living at http://www.baladisoftware.net

I'll talk about the remaining two sceanrios in the SHP from there...

SHP from the ISV perspective

mbaladi.net — Mon, 26 Mar 2007 21:49:00 GMT

Sitecore's solutions architect has posted a series of excellent articles on the joint project we did. Have a look at Lars's view on his blog on

what it takes for an ISV to move in to SaaS
what an ISV expects from a SaaS Hosting Platform (SHP)
how Federation can enable single sign-on across multiple SaaS applications as well as across a mix of on-premise and SaaS applications
and more...

SHP #7: Let’s go shopping…

mbaladi.net — Fri, 23 Mar 2007 14:01:00 GMT

Scenario #4: Order fulfillment and order management in the store front and provisioning for new application tenants (subscribe)

When & who?
Once there’s something in the catalog to sell, the store front companies expose public facing order fulfillment web site(s). These sites are used by potential application tenants to browse plans, options, price and eventually sign-up for plan or “try-before-you-buy” offer.

How?
The plans that were created in the catalog in the previous scenario are queried using a call to the catalog service and the result is displayed on a customer facing web site. Using a sign-up wizard, the potential application tenant can then select and deselect options and the system keeps track of dependencies as well as what parameters the user must supply for each selected software item. Example: if the potential application tenant selects the dental booking module priced by number of dentist, the order fulfillment wizard must ask for the number of dentists, know that this is a numeric and validate user input agains possible ranges (the knowledge of these parameters came from the ISV provided application manifest via the platform service). In the final stages of the sign-up wizard, the potential application tenant is asked to supply company information, billing information etc and submit the order.

The order fulfillment wizard sends customer and order data to CRM/ERP and asks platform service to initiate an application tenant provisioning sequence supplying the data from the wizard. This provisioning sequence was designed and the scripts where verified and approved during design-time (as described in scenario #2 in a previous post). Now, at run-time, the platform service does some book keeping and asks the provisioning service to execute:

Image 1: Order fulfillment and per application tenant provisioning

Looking at it in terms of call sequences, order fulfillment and per application tenant provisioning looks like this:

Image 2: Sequence diagram for order fulfillment and per application tenant provisioning

In our sample implementation we focused on getting the interaction with the SHP right and not on the details of a specific ERP/CRM system. Therefore the order fulfillment sample simply dumps customer and order data into an XML file to be picked-up, mapped/transformed and imported by some CRM/ERP directly or using products like ~~[insert your favourite ESB product here]~~ BizTalk Server ;-)

SHP #6: Software + Services for sale!

mbaladi.net — Fri, 23 Mar 2007 13:56:00 GMT

Scenario #3: Managing the re-sellers hosting plans in the store front to include software items from the new application

When & who?
There may be multiple store fronts offering the same underlying software items for sale in different packages and price models. Each store front has a business/sales manager responsible for composing plans/packages using software items and services from one or more sources, setting price per time period for eh plan etc.

How?
Each store front has its own catalog implemented of any technology the store front happens to chose. In our store front implementation, the catalog is a service implemented using Windows Communication Service (WCF), but other store fronts may choose to implement their catalog on top of an ERP system. Our catalog stores information about what software items are available, their dependencies and their license schemes. This data is read from the platform service’s inventory and the underlying platform/application manifests. In addition to software items, the catalog service also stores information about services, such as e-mail support, phone support, domain registration etc. The catalog service is then able to keep track of these software items and services in any possible combination in a plan with an associated time period and metering info (more on this in a later post about metering and billing). As an example the store front could offer a “Small business” plan that look like this:

· two software items with a fixed fee per module and month from ISV A

· three software items from ISV B with a fee per “application object” (i.e. books in a book store application, pages in a CMS application, number of hair dressers in a salon application etc)

· domain registration/renewal

· e-mail support

· 12 month at X/month or 24 month as Y/month

The 1^st stab at a simple catalog data model we implemented in our sample looks as follows:

Image 1: Catalog data model

The business/sales manager at the store front works with one plan at time, but the plan may contain software items from multiple vendors potentially running on different platforms located in different hosters data centers. Our architecture allows for these complex scenarios by

· Clearly separating the three roles (store front, ISV/platform tenant and platform provider)

· Having a service interface through which these three roles can interact and

· Having the catalog automatically refresh its software items from the platform as they are being used during plan management.

With this design, the three roles can be played by any number of business entities (two store fronts for the same applications on the same platform, one store front for two applications on two different platforms etc). However, to make life keep it simple and comprehensible in the short lab, we chose to use a simple but realistic (remember there’s a real hoster, a real re-seller and a real ISV with a concrete business problem participating in this lab) setup:

· one store front re-selling

· two applications from two different ISVs (or platform tenants) running on

· two different platforms provided by

· one platform provider (i.e. using one platform service)

as shown in the illustration below:

Image 2: Catalog & plan management

Looking at it in terms of call sequences, catalog and plan management looks like this:

Image 3: Sequence diagram for catalog & plan management

The first call is there because we discussed the possibility of having a product manager at the ISV side maintain an XML doc (using some fancy product configuration tool obviously) with the suggested packaging (i.e. “Standard” includes these 50 modules with the usage limits and “enterprise” includes these 200 modules with no usage limits etc). We thought it might be useful if the applications are complex and if the re-seller mostly follows the suggested plans, but decided to skip implementing it for now…

Next step
With the current SaaS maturity level, SaaS ISVs start-ups will pick up the phone and call the hosters sales department. However I believe that, in a not so distant future, SaaS ISVa wants to shop for hosters just as a SaaS consumer shops for applications. I also believe that many start-ups want to start small & inexpensive and the upgrade to “premium” platform services later. Therefore I believe SaaS hosters should package their platform in to “subscribe per year” type plans just like applications – i .e. offering a “bronze”, “silver” and “gold” SaaS hosting platform plan as the following example:

· Bronze: Hosting on a shared platform with data on a shared stand alone SQL server

· Silver: Two load balanced web servers in virtual machines and data on a clustered SQL server with an entry level SAN with service level of X.

· Gold: Two or more load balanced web servers in physical machines, published through two load balanced application proxies and data on a clustered SQL server with and top notch geo-dispersed SAN with service level of X*2.

In order to sell platforms as a service, the data model in the catalog would need to be extended a bit. Looking at the data model above, you’ll see that there already is a PlatformTenantPlan object for this purpose, but this node need have a tree of platform items and services hanging off it.

SHP #5: The first two scenarios – the a basic meta-data “goo” (define, map & persist)

mbaladi.net — Fri, 16 Mar 2007 13:38:00 GMT

Scenario #1: Defining the platform run-time instances and its capabilities

Why?
Describing and documenting a platform is always a good thing to do, but by storing it in a machine readable format opens up a new set of opportunities such as automation of initial application provisioning, provisioning application tenants as they subscribe and ongoing operations – all in order to save time and reduce cost.

When?
Defining the platform can be done by the hoster up-front to describe what their standard shared SaaS platform looks like. However, in some cases this is done after there’s a business agreement in place with an ISV to start hosting and/or re-selling the new application.

Who?
This work is typically done by the operations team at the hoster and the tools they most commonly use is scripting for operations/management and a diagramming tool for documentation.

How?
The Dynamic Systems Initiative (DSI) is a commitment from Microsoft and its partners to do all of the above and more. The System Definition Model (SDM) is a key technology component of the DSI product roadmap that provides a common language, or meta-model, that is used to create models that capture the organizational knowledge relevant to entire distributed systems.

The first implementation waves of the DSI vision have already surfaced in products like Visual Studio 2005 and more will come in next version of Windows server code named “Longhorn” and in Systems Center. However, for this project I needed to use released products only, appeal to the target group and solve a concrete problem within a very short time frame. Therefore the choice of “modeling tool” for the platform run-time instances fell on Visio 2003. By annotating the Visio diagram with the standard basic machine information (name, IP-address etc) plus machine/network capabilities (such as fault tolerance) and saving the diagram to an XML file (Visio uses the VDX file extension for this), a simple “Platform Manifest” was implemented.

Image 1: Platform manifest for the shared SaaS platform included in the hypothetical “Silver platform plan”

Then we implemented a Visio XML parser that was capable of recognizing the most basic shapes and extract information about these network nodes and store it in to the platform service for use in the other scenarios. Using an XSLT, this model of the application run-time instance could be converted to a logical data centre diagram for Visual Studio 2005 (LDD file) that the hoster could give the ISVs for them to verify their architecture against a hosters standard platform offering.

In the future, post “Longhorn”, this should obviously all be SDM models in the SDM persistent store. See Understanding SDM and its Practical Application in 2006 to 2008 for more details on the DSI road map.

Scenario #2: Defining the application meta-data and mapping the platform tenant to a platform run-time instance

Why?
To host a SaaS application, the hoster needs to know a walth of technical details of how to install and operate it such as machine requirements, support for platform level authentication (such as federation), performance couters, management rules etc.

To aggregate and re-sell the application, the store front needs to know how it can be packaged (i.e. dependencies between software items), how to meter usage in order to do usage based billing, what questions each new application tenant need to answer for each item in the package etc.

The ISV, hoster and re-seller could share all this knowledge by having meetings, sharing diagrams and documents etc, but by capturing all of this meta-data in a machine readable format –using a common schema across all SaaS ISVs – allows for automation and both ISV and hoster saves time and reduces cost.

When, who and how?
Most of the work involved in creating the platform and application manifests is done in design-time. On the ISV side it’s done by a developer using Visual Studio and XML Schema.

The idea of the application manifest is that the ISV describes requirements (I need a load balanced farm of web servers and no server affinity, I’m claims-aware etc.) and the hoster assigns resources by filling out tenant parameters (you get web servers web01 and web02, the app pool account will be X and I’ll use my BIG-IP box to load balance using simple round robin etc). The hoster does this assignment using a platform manifest and a platform tenant parameters. With this information, the platform run-time service can automate most of the tasks as described below.

The application manifest is structured as a hierarchical tree of software items. Each software item has information about

· Name/Id

· How to start/stop (i.e. gracefully tell the app something is about to happen)

· How to provisioning/de-provisioning throughout the life cycle (at initial install, per application tenant subscribe/unsubscribe, at application upgrades and final application de-provisioning)

o Provisioning is split up in common task Web, DNS, Database, Directory etc

o Application manifest specify run-time parameters that order fulfillment can use to ask the new application tenant for input at signup (i.e. ask user for a delegated admin user for the main software item and ask for number of mail boxes for the mail module)

o We cut corners by only implementing support for Microsoft products such as MS IIS, MS DNS, MS SQL, MS AD (ignoring other vendors but hey, we had three weeks not three years)

· Dependencies other than parent nodes (i.e. dependencies on siblings)

· Prerequisites (such as IIS, .NET, ADAM etc)

· Platform requirements (sticky sessions, federation etc)

We looked at implementing the application manifest with the application designer in Visual Studio 2005, but too many aspects of the manifest was missing so we ended up inventing a custom schema. The schema we implemented is available here. Short term, this could be generalized to include other vendors and federation claim mapping tasks. In an ideal future, post “Orcas” or post “Hawaii”, the application manifest schema should obviously evolve into an industry standard SDM/CML model living in the SDM store and be modeled using some cool new modeling tool in Visual Studio yet to be invented… Again, see Understanding SDM and its Practical Application in 2006 to 2008 for more details on the DSI road map.

With the application manifest at hand, the hoster’s IT operations staff can now map ISV applications (or platform tenants) onto specific platforms and generate install templates and management packs using a set of PowerShell scripts.

Once the IT operations staff has inspected & approved the generated files, the initial provisioning of the application onto selected physical platform(s) and import of a management pack for System Center is done run-time.

The following two diagrams show the entire process for this and the previous scenario:

Image 1: New platform tenant and initial application provisioning

Image 2: Sequence diagram new platform tenant and initial application provisioning

The platform service was implemented as a Windows Communication Foundation Service (WCF) hosted in Internet Information Services v6 (IIS6).

To import platform and application manifests and map platform tenants onto platforms we implemented a set of PowerShell CmdLets such as, Get-PlatformTenants, Get-Platform, Add-PlatformManifest etc.

And now the real magic starts. The Generate-ProvisioningTemplates CmdLet in the sequence diagram above merges platform manifest, application manifest and platform tenant parameters into a two provisioning templates – one for initial installation and one for each application tenant subscribe/unsubscribe. These templates are XML documents with a set of install tasks that an administrator can inspect and optionally edit. This stage marks the end of the design-time phase.

Finally, as the first step in the run-time phase, the Provision-PlatformTenant, executes initial provisioning of the application. For Microsoft Provisioning System (MPS) this would mean that the platform service would perform an XSLT to MPS format and pass it to the MPS engine for execution. Our Light Weight Provisioning System (LPS) is a WCF service hosted in IIS that receives an “install task document”.

Before sending the install tasks to MPS, LPS etc, the platform service have expanded all parameters (i.e. “I need a web site on all web servers in the platform instance I’m running on” is now expanded to “create a web site on web01 and do the same on web02”).

LPS converts the install tasks to a set of PowerShell CmdLets that then gets executed inside Windows Workflow (WF). WF allows us to implement long running tasks such as sending an email to a domain registrar and wait for an answer. Using PowerShell CmdLets and logging all actions allow the hosters operations staff, to inspect and optionally re-run tasks. The CmdLets that we implemented include common task for Microsoft products such as IIS6, AD/ADAM, SQL, DNS etc. In a production environment we would also nee CmdLets for the load balancer, other DNS implementations etc.

SHP #4: Just a side note before we get serious again…

mbaladi.net — Fri, 16 Mar 2007 12:26:00 GMT

Spring is here and the sun is shining. As I live close to the beautiful Roskilde Fjord, I took a walk by the water front. I figured catching some rays wouldn’t be that harmful and maybe, just maybe, my eyes would revert to an oval shape again after a couple of lengthy screen sessions. By the harbor, people were working on getting their boats ready to go into the water. However, three weeks ago when we were doing the SHP lab, it was a snow storm here :-o

This is what the Microsoft Innovation Centre lab looks like with almost ½ meter of snow in front of the main entrance:

SHP #3: SaaS Hosting Platform overview

mbaladi.net — Thu, 15 Mar 2007 01:07:00 GMT

Multiple store fronts

Since the ISV may chose to sell directly and/or through a hoster and/or an aggregator, we introduced the term “store front”. The store front is one or more places from which a potential application tenant can subscribe to the application. An ISV may choose to have a store front on its web page as well as selling some edition of the application through a re-sellers store front.

N-tierd multi tenancy

To fully leverage the economy of scale, the hardware infrastructure and many of the platform services in a given hosting infrastructure may be shared between multiple ISVs.

From an application hosting provider’s perspective, there may be many instances of these application architectures, one for each application, running simultaneously. These applications may come from the same or different ISVs, sharing services such as the security services. So from this viewpoint, the hosting infrastructure is multi-tenant with multiple ISVs (“platform tenants”) sharing hardware and services.

One level up in the SaaS ecosystem, at the ISV’s or application providers’ viewpoint, each application can have multiple tenants (“application tenants”) since the ISV will sell his application services to multiple customers/users (jointly referred to as “consumers”).

An ISV that chooses to self-host and to build the shared services capability themselves will not have to be concerned with multi-tenancy at the hosting infrastructure level. However, this series of blog post will focus on the requirements and techniques for building the multi-layered model and therefore cover multi-tenancy at the application level as well as multi-tenancy at the hosting infrastructure level.

Two platform tenants or two application tenants may never see each other’s private configuration, but there may be shared configuration at higher levels.

· As an example at the hosting infrastructure level, all platform tenants are configured to use the centralized authentication model, except the platform tenants in a specific region that use the decentralized model trusting a local Security Token Service (STS).

· As an example on the application level, all application tenants in a SaaS Point-of-Sale system have a the “refund approval limit” for the “store manager” role setting set to €1000 for all stores in the Europe, except for the stores in France where the same setting may be €1500.

Actors/roles in this play

In this series of blog post, we have used a couple of fictitious companies to illustrate the SaaS ecosystem:

· A fictitious SaaS application hosting provider named “Northwind” providing two platform run-time instances and a set of shared services. One run-time instance is an entry level platform with a single web server and a single database server. The other run-time instance has a much higher service level and uses load balanced web servers and clustered SQL servers.

· Two fictitious ISVs (or platform tenants) called “Litware” and “AdvetureWorks”. Both ISVs have chosen to use external hosting and signed up for Northwind’s SaaS platform plans. Litware’s application is only available on the entry level platform but AdventureWorks is available on both platforms through a low price “basic” plan and a high price “premium” plan.

· The architecture of the SHP allows multiple store fronts and Litware have chosen to sell both directly through their own web site as well as through Northwind.

· Two fictitious consumers (or application tenants) have subscribed to Litware’s application. These application tenants are “Contoso” and “Fabrikam music school”

Image: The SaaS ecosystem as applied to this series of blog posts

SHP Overview

In the first post in this series, I mentioned that I would go through six scenarios:

1. Defining the application platform run-time instances and its capabilities

2. Defining the application meta data and adding a new ISV (or platform tenant) and its application and modules (or just “software items”) to an new or existing platform run-time instance

3. Managing the re-sellers hosting plans in the store front to include software items from the new application

4. Order fulfillment and order management in the store front and provisioning for new application tenants (subscribe)

5. Usage metering and billing for the application tenants

6. Accessing the application with web single sign-on and federated web single sign-on

To implement these scenarios we need a SaaS Hosting Platform (SHP). I will go through the SHP In greater detail as we go, but here’s n overview to start with:

· One or more platform run-time instances. Each platform run-time instance is a set of physical or virtual machines and platform software in a given configuration such as the one described in Windows Based Hosting for Applications. A given platform run-time instance and its capabilities is described in a platform manifest that is stored in the platform service. The platform manifests together with a per platform tenant platform tenant manifest describes all aspect of the run-time platforms.

· One application manifest per application. The application manifest is an XML document that conforms to a SHP-defined schema. The manifest instance is maintained by the ISV an it describes all relevant aspects (dependencies, installation details, metering points, monitor hooks etc) of the software items that compose the ISV application.

· A set of services such platform, provisioning, catalog and metering service.

o The platform service is responsible for

§ Storing the application, platform and platform tenant manifests

§ Keeping track of the mapping between platforms, platform tenants and applications

§ Serving other applications and services with information from the manifests such as

· generating provisioning tasks from platform, platform tenant and application manifest

· providing software items from the application manifest to the catalog

· generating management rules to the management software from the application manifest

§ Keeping track of inventory of what software items are installed on which platforms

o The catalog service is responsible for maintaining a catalogue of platform items, software items and services, including licensing and pricing information, combined into application tenant and platform tenant hosting plans. This service could be implemented on top of the store front operator’s enterprise resource planning (ERP) system, but for this article we use a sample catalog service written as part of this article.

o The provisioning service is responsible for executing the install tasks for initial provisioning, per application tenant provisioning etc. Any provisioning system, such a Microsoft Provisioning System (MPS) could be used. For this article we use the sample Light Weight Provisioning System (LPS) written as part of this article.

o The metering service is responsible for collecting and aggregating metering information from the run-time platform instances as well as the applications running on top of these platforms and makes this information available to the billing system.

o Infrastructure services such as DNS, application publishing, packet inspection as well as access control services for authentication and authorization via web single sign-on (Web SSO), federated Web SSO, plan based access control etc. Even though the platform could do role based access control (RBAC) as well, this is typically managed by the application.

· A set of applications such as the plan management, order management and the order fulfillment web pages

o The catalogue is maintained by the store-fronts business manager through a plan management application that allows to combine platform and software items with services into plans that platform tenants and application tenants can subscribe to

o The platform and application tenants can subscribe to these plans from the order fulfillment web page which is well integrated to the store-front web site

o The store-fronts business manager can track orders through the customer relationship management (CRM) system directly or via the order management web page

o A set of Powershell admin scripts and semi-automated administration tasks

· A set standard applications such as platform and application monitoring, customer relationship management (CRM), accounting and ERP with five integration points

o Order fulfillment sends customer and order information to ERP and CRM

o The catalog service (master) can export software items to the ERP system (slave)

o For periodic billing, the ERP system can query the metering service for usage data

o Platform access control can query ERP/billing for outstanding payments.

o Platform service can generate management rules for the monitoring system

SHP #2: In-house vs. external hosting (the 80,0002 vs. 1160,000 quiz)

mbaladi.net — Thu, 15 Mar 2007 00:36:00 GMT

In-house vs. external hosting

An ISV that wish to start offering an application throug a SaaS delivery model could choose to move down the stack and host the application in-house (sometimes referred to as “self-host”), requiring the ISV learn how efficiently and securely operate a data centre for thousands of application tenants. A friend of mine is the CEO of an ISV that has sold 80,000 copies of an application as on-premise installation to customers with an average of 2 users. The company is used to send upgrade CDs out and do support to end-users at small businesses. Moving to a SaaS delivery model their skills would have to shift to operating a data centre 24*7 with 160,000 concurrent users and application tenants constantly subscribing an unsubscribing to services. These are obviously two very different skills sets.

Self-host could mean to actually have the data-centre in-house or to have a bunch of dedicated servers located in the data centre of a “classic” hoster who provides very basic services (sometimes referred to as “ping, power & pipe”).

Another option is outsource the hosting to a SaaS hosting provider that offers a complete SHP-for-rent and provide services at a higher level (i.e. providing an application level SLA as opposed to machine or network level SLA).

Some ISVs may even start by buying these services in the start-up phase and then bring these services in-house as they grow their business. As an example a small ISV startup may want to host its application with an application hosting provider in a shared environment (shared load balanced web servers, shared security services, shared database cluster etc). As the ISV grows in size or requirements for isolation get higher, the ISV may move to dedicated hardware within the same data centre or even choose to move the hosting in-house.

Recently we have also seen examples where ISVs that have chosen the in-house hosting model, quickly getting the required knowledge, people and data centre by acquiring a hosting provider.

Build or buy the shared services

The SHP is both an application run-time platform as well as a set of shared services. For the shared services, the ISV has a variation of the classical “build vs. buy” choice. In the SaaS world, “buy” really means “use/rent with a SLA”. This means that the ISV has a lot of options:

· build all the shared services (with self-host or outsourced hosting)

· “buy” the shared services from the same hosting provider that provides the application run-time platform

· “buy” some of the shared services from the same hosting provider that provides the application run-time platform (such as monitoring) and other services (such as catalog, order fulfillment and billing) from a re-seller or aggregator

· “buy” some of the shared services from external service providers (example; one SaaS application could send usage data to another SaaS application that implements a billing service).

· Any combination of the above

Reasons for building the shared sources in-house include:

· Better and more tailored BI on customer profiles, usage patterns, retention, targeting

· Higher level of control with features and service level iH

· Complex tenant management features – multiple levels of tenant relationship (resellers etc)

· Desire to keep customer and business information away from third parties

· More cost effective to build and operate this capability themselves

· Regulatory requirements that cannot be satisfied by third party hosters

Reasons to using shared services from of the application hoster or other SaaS ISVs:

· Allows to focus on application features to get to the market faster

· Need market presence and visibility that SaaS aggregators can provide

· More cost effective to outsource this capability

There are a couple of trade-offs involved in this decision. One tradeoff is about choosing between sharing and isolating. Should the services be shared between multiple ISVs or should it be isolated for a single ISV.

The second is about choosing between developing the shared services in-house and buying, or renting, the shared services.

These trade-offs are never black or white, but instead, it’s more of a continuum, with many variations that are possible between the two extremes.

As an example of sharing vs. isolating, an ISV may choose to share the security services, but not the data services. As an example of in-house vs. outsourced shared services, an ISV may choose to develop the operation support system in-house, use someone else’s billing system.

From an application architecture perspective it’s therefore important to abstract the underlying implementation and location of the service provider away behind a stable contract/interface in order to support changing business requirements.

SHP #1: Designed for Hosting and the SaaS Hosting Platform

mbaladi.net — Thu, 15 Mar 2007 00:21:00 GMT

During the last year I have worked with many ISVs from all over Europe & Middle East helping them to (re)architect their solutions for a Software-as-a-Service (SaaS) delivery model.

One thing stood out very clear. There’s a gap that needs to be bridged between the classic application hosting provides (hosters) and the ISVs. The ISVs where expecting the hosters to provide far more than what most hosters actually could deliver. In Gianpaolo’s blog post about the SaaS ecosystem, what the ISVs are looking for is referred to as a “SaaS hoster”, but what does it actually take for a “classic hoster” to become a “SaaS hoster” and what does it take for an ISV to move from an on-premise to a SaaS delivery model in terms of hosting, re-selling etc? I found that there’s a need to define clear interfaces between the two parties as well as providing guidance and reference architectures for both sides.

From the ISV side we invented the fictitious logo program “Designed for Hosting” (DfH) to describe a SaaS application that well architected (such as the Litware sample), well described in meta data, easy for hoster to re-package and re-sell as well as easy for a hoster to provision, manage and monitor.

ISVs need to focus on building competitive application functionality and therefore, in many cases, prefer to rent a “SaaS Hosting Platform” (SHP) that provides scalable, available, secure and interoperable application and platform services. Offering such SHP for rent provides a new business opportunity for hosters to “move up the stack” to become a “SaaS hoster”.

Many hosters also act as aggregators or re-sellers of ISV applications so the DfH must, in addition to the operational aspects, also include the sales, aggregation and billing aspects.

I have, together with my virtual team, had many whiteboard discussions with solution architects (mainly from the ISV side), infrastructure architects (mainly from the hoster side), business owners/managers (from both ISV and re-seller and aggregator side) about what exactly DfH and SHP is (or rather should be). My colleague, Fred Chong, takes a stab at defining it here (even if we used the term SDP instead of SHP back then). We realize that this is a known concept in the Telco industry and that similar hosting and re-seller platforms exist as “carrier grade”. However, our target was the ISV embarking the SaaS journey (after potentially spending decades in the on-premise world) as well as hosters moving from traditional web site hosting to SaaS application hosting. The consistent feedback from these groups is that they want to start small with a bare minimum of servers, and grow their infrastructure as their business grows. ISVs often also want to have a running instance of the SHP for internal use and testing so a light-version of provisioning, catalog etc is often asked for.

Finally we decided to invite a real ISV (www.sitecore.com) and a real hoster who operates both as aggregator as well as a platform provider under two brands (www.cohaesio.com and www.surftown.com) to do a joint three week hands-on Proof of Concept (PoC) with us. The goal of the project was to build a sample implementation of the central concepts of DfH and SHP (as we defined them). We discussed what it would take to make Microsoft’s Litware sample and Sitecore’s SaaS edition “designed for hosting” and what Cohaesio and Surftown’s SaaS Hosting platform offering should look like to be able to host and re-sell Sitecore as well as any other SaaS application.

In a series of blog posts over the next 1-2 weeks, I will go through some initial thoughts, my findings from the engagements and the six main scenarios we ended up implementing in the joint lab:

1. Defining the application platform run-time instances and its capabilities

2. Defining the application meta data and adding a new ISV (or platform tenant) and its application and modules (or just “software items”) to an new or existing platform run-time instance

3. Managing the re-sellers hosting plans in the store front to include software items from the new application

4. Order fulfillment and order management in the store front and provisioning for new application tenants (subscribe)

5. Usage metering and billing for the application tenants

6. Accessing the application with web single sign-on and federated web single sign-on

Expect to see ISV and Sitecore specific aspects of this session at Lars Fløe Nielsen’s (Solutions Architect at Sitecore) blog as well.

Thanks to all the great minds that have provided feedback and/or directly contributed to the various architectural design sessions and proof of concepts engagements over the past year:

· The folks at Microsoft (Gianpaolo, Fred, Yuriy, Kevin, Mario, Jimmy & Bo).

· The entire team from Sitecore, Cohaesio and Surftown.

· The CxOs, architects, developers etc from all the “anonymous” ISVs that have visited me in the Innovation Centre with interesting SaaS offerings or otherwise inspired me along the way.

Exec keynote on Saas at the Microsoft Europe Partner Senior Architect Forum

mbaladi.net — Tue, 13 Mar 2007 17:52:00 GMT

This week I had the pleasure to give a keynote on SaaS at the Microsoft Europe Partner Senior Architect Forum.

The session abstract was -"Software vendors are now making the transition from an on-premise installation delivery model to a software-as-a-service (SaaS) delivery model. This transition has a significant impact on the software vendor’s business model, solutions architecture as well as operational architecture/platform. In addition it also has an effect on re-sellers and solution integrators. In this session, Michel Baladi, will present how Microsoft views the SaaS ecosystem and then drill down into how each of the above areas are affected with a strong emphasis on the solution architecture and delivery architecture/platform. Michel Baladi is an architect and the technical lead of the Microsoft Innovation Centre in Copenhagen and for the past year he has been one of the driving forces behind producing architectural guidance for SaaS software vendors and hosting providers."

The slides are attached. The intro slides is only one sec per slide just to mention what type of SaaS customers I have worked with in the Innovation Centre as part of the SaaS incubation program (solutions and flags are re-ordered to protect the innocent ;-).

I am no longer an architect!

mbaladi.net — Wed, 05 Jul 2006 11:35:00 GMT

Something that really gets to me in the software business is the constant stream of meaningless buzwords, three-letter-acronyms (TLA's) and completely overloaded terms.

I have been calling my self "solutions architect" or "architect advisor", because most of the work I have done in my career is to either "architect" solutions or lately help others do so.

Unfortunately the industry seems to think that architecture is just about everything including high-level modelling, writing code, being a domain expert, being able to apply knowledge to any domain, sell solutions, manage politics, manage project process and risk, mentor others, be vendor neutral, be a subject matter expert in some detail of some vendors technology, have the big picture and the list goes on and on.

A colleague of mine makes some good points and lists some of the architect definitions here. Here's a slightly modified list
http://www.bredemeyer.com/pdf_files/role.pdf
http://www.agilearchitect.org/agile/role.htm
http://www.artima.com/intv/architect.html
http://www.certmag.com/articles/templates/CM_gen_Article_template.asp?articleid=1406&zoneid=225
http://www.microsoft.com/learning/mcp/architect/archcompetencies/default.mspx

TOGAF even defines a list of architect types and the skills and competencies each type of architect should have. The list is located at http://www.opengroup.org/architecture/togaf8-doc/arch/p4/skills/skills.htm).

So I thought that simply calling myself "solutions architect" or "architect advisor" was too unprecise and missleading. I tried to define the correct type as XML:

However, for some reason that seemed too complicated as well.

Finally I decided to simply call myself a Experinced Software Professional, or simply ESP to be industry compliant with the TLA's :-o

Btw, I noticed that Wikipedia list more than 30 meanings of ESP, but none in software...

I have also removed the word architecture from the title of my blog and from now I'll blog about software, not about about architecture or process.

Note: These are all my personal opinions based on my observations and it doesn't reflect my employer's view point.

Ahh - know it feels better. Glad I got it of my chest ;-)

Yours truly
Michel Baladi
ESP

Software as a service for architects

mbaladi.net — Fri, 30 Jun 2006 15:06:00 GMT

This week I had the pleasure to be at the Swiss Web Summit 06 and give a talk on Software as a Service for a mix of 200+ architects / developers. The session gave an introduction to what SaaS is, why threre is a renewed interest in building and using SaaS applications as well as how it affects the application architecture. The slides are based on some of the content from our ISV area on MSDN and they are available here.

Security Guidance is brought up to date through Sustained Engineering Program

mbaladi.net — Fri, 30 Jun 2006 14:57:00 GMT

The Microsoft Solutions for Security and Compliance (MSSC) team has released updates to five previously released guides, including the Microsoft Identity and Access Management Series that I co-authored.

The guides that have been brought up to date are:

Security Risk Management Guide v1.2.
The Microsoft Windows NT4.0 and Windows 98 Threat Mitigation Guide v1.1.
Windows XP Security Guide v2.2.
Windows Server 2003 Security Guide v2.1.
Microsoft Identity and Access Management Series v1.4.

The updated version of Microsoft Identity and Access Management Series is available at http://go.microsoft.com/fwlink/?LinkId=14842

SaaS guidance and seminars

mbaladi.net — Tue, 02 May 2006 07:35:00 GMT

I recently found out that two of my colleagues from the Microsoft’s Architecture Strategy Team in Redmond, Gianpaolo and Fred, are working on similar SaaS guidance that I planned for Europe, Middle East and Africa. I will pitch in with content to the main table of content (ToC) that Fred has outlined at his blog rather than creating my own. By joining forces on SaaS guidance, I think we can reduce overlap and to create consistent guidance faster. Make sure you review/comment the ToC and stay tuned…

Also make sure you attend this month’s free seminars on SaaS. See http://www.dynamicevents.com/globalsoftwareasaserviceseminar/ for more info.

So Software as a Service is the next big thing – again?

mbaladi.net — Sat, 22 Apr 2006 10:47:00 GMT

Today there’s a lot of “buz” around Software as a Service – SaaS. But what is it? Is it really going to happen this time? Simply put, the current most common definition of SaaS is “Software deployed as a hosted service and accessed over the Internet”. I have seen it come and go a couple of times over the past 15 or so years (yes, I’m getting old), but this time I think it can be big and that it can be different…

Background

In the late 1980s, I worked for an ISV doing hotel reservation software – both as packaged software and as a service. We bought and hosted a mini computer, wrote a hosted application with shared logic and data and sold the customer green terminals and leased lines. We where hosting hundreds of hotels on this one physical, but logically separated system. Through the magic of configuration, different modules and customized UIs were presented to the user.

But maintenance fees for the mini computer was high, telecommunication was expensive and PCs where getting cheaper and more stable, so the trend shifted to packaged software that was installed locally at each hotel.

In the mid 1990s the trend seemed to shift back again with the rise of the Internet. Visionary people predicted that applications would be provided as a service over the Internet. Well, that didn’t really take of for a couple of reasons; the platform was immature, bandwidth was limited, connectivity was not reliable etc. There was also a big resistance in the market against having company data hosted outside the company and against some of the business models behind SaaS (such as pay per use). But the biggest problem, I believe, was that the ISVs where not ready with real SaaS applications. At that time, they where building client/server architectures with fat clients and the picture of what SaaS was really about got “clear as mud” when hosting companies offered these non-SaaS applications over Citrix etc. and called is SaaS.

Why this time?

Today this resistance seems be gone to some extent and we see more and more ISVs adapting the SaaS concept again. The benefits (such as no high initial cost, pay only for what you need/use, no local admin etc) seem to overshadow the concerns (such as security, integration etc). Today we see customers signing up for CRM solutions, effectively outsourcing their customer database including leads/prospects they currently work, over the public Internet. We see new business and payment models emerge with a big element of targeted advertising. Through the use of computers in everywhere (desktops, mobile phones, TVs, cars etc) and by linking services from many providers together over standardized protocols (such as XML Web Services), we can take SaaS to a completely new level and provide services we didn’t even dream about in the late 1980s.

Architecture

Whether you do SaaS on a mini computer with green terminals and leased lines or if you do it on a cluster of PCs with browsers and broadband Internet connection doesn’t really change the concept – only the technology. The benefits for customers as well as the architectural characteristics and inherent problems remain:

The main architectural characteristics:

Designed to host multiple clients on separate instances on shared servers. This is sometimes referred to as multi-tenancy (analogy with multiple tenants in an apartment complex).
Designed for scalability and availability. Serving hundreds or thousand of customers from the same physical system requires a high degree of availability and changes for one customer must not affect up-time of another. And, as the number of customers grows, the system must be able to scale by adding servers which obviously requires the application to architected with this in mind.
High level of configurability order to service many different customers with the instances of the same application. White-labelling and skinning is also an important factor since the application can be consumed in many different ways.

The main architectural problems:

Hard to integrate with local packaged applications. No application is an island, and if a company decide to use an ISV solution as a service, this solution will have to integrate with the locally installed applications and hardware devices. As an example from the hotel reservation system I mentioned earlier, we had to integrate with phone centrals, video check-out systems etc. With SaaS, it’s easy to provide check-out functionality for a cashier to use in a browser application. Then try to integrate this with a video check-out system (with a 10+ year old RS-232 interface) where the guest view/approve the bill on the TV and picks up the printed bill in the reception when walking out of the hotel.
Hard to customize to the same level as sophisticated packaged applications offer. Many sophisticated ISV applications allow customization at many levels through configuration and custom code. Customizations can be made by one or more VARs as well as by the end customer. With SaaS this poses some architectural challenges and security concerns. Can we allow VARs to upload custom code? What is this code allowed to do in order not to affect the other customers system?
Security. With SaaS there are many concerns around security. Just to mention a few:
- Protecting data in transport between the service provider(s) and service consumer.
- Storage of corporate data outside the company.
- Identity and access management such as integrating the service provider’s identity system with the consumer’s identity system, very fine grained access control depending on who the consumer is etc.

Talk to me and the ISV team in EMEA (Europe, Middle East & Africa)!

In Microsoft’s Technology Centre for EMEA based ISVs where I work, we have seen more and more interest for SaaS and we expect to spend a significant amount of time the next 12 month with ISVs giving architectural guidance on SaaS during our engagements.

I want to take the learnings from these labs and provide them as architectural guidance in this forum, but I would like to hear your feedback.

Do you already do SaaS or have plans to do so next 12 month?
What are the most important architectural topics that you would like to see guidance on first?
Other issues/concerns arouns SDLC process or tools that relate to SaaS
…

The ISV architecture forum is dedicated to discuss these and other architectural issues with ISVs.