Gabriel Morgan : S+S

SaaS Service Offerings redefine what's in a product

Gabriel Morgan — Tue, 29 Jan 2008 11:01:00 GMT

As I continue my work on my little nook of Microsoft's S+S business strategy, the team I work with has noticed something peculiar about what exactly a Service Offering really is. Because we know the packaged software business so well, we sometimes overlook what at first seems like a subtle difference in the SaaS business but eventuates into something quite substantial. One such situations is the understanding of what a Service Offering is compared to a packaged software product.

Service Offerings via SaaS redefine what a product is

In the traditional packaged software business, product features define what a product is but Customer 2.0 expects to have direct access to operational features within the Service Offering itself.

Take for example Microsoft Word. Product Features such as Import/Export, Mail Merge, Rich Editing, HTML support, Charts and Graphs and Templates are the types of features that Customer 1.0 values most in a product. SaaS Products are much different because Customer 2.0 demands it. Not only must a product include traditional product features, it must also include operational features such as Configure Service, Manage Service SLA, Manage Add-On Features, Monitor Service Usage Statistics, Self-Service Incident Resolution as well. In traditional packaged software products, these features were either supported manually, didn't exist or were change requests to a supporting IT department.

Service Offering = (Product Features) + (Operational Features)

Operational features directly impact the most valuable aspect of the Software Service Provider business...service quality for customer retention. Dr. Nilesh Bhide, one of my esteemed colleagues wrote a great blog post on the value of the qualitative customer experience for a Service Provider business (see here). This is a fascinating reality online Service Provider businesses have.

So, what downstream impacts are there for SaaS products? There are two that I'd like to look at; operational business processes and their supporting business systems.

The operational business processes must now include Self-Service Incident Management and Self-Service Service Management to streamline and enable the direct interaction between Customer 2.0 and the Operational systems to make real-time incident resolution and service configuration changes on the fly. Inability to have these automated business systems result in a degradation of service quality and inevitably customer attrition.

Product Managers of SaaS Service Offerings must include into the Service Offering operational features to optimize customer retention. They cannot be an afterthought nor can they be lower in priority. They are a key 'feature' of the Service Offering itself.

This assumption implies that the systems providing the operational features must also have the highest system quality that product features have. System quality attributes such as system reliability, system security, system performance and system usability. Any downtime, lack of usability or any other poor experience with these features naturally reflect the rest of the Service Offering itself. This is the point I want to make with this article. Guess who builds and supports these Operational Features? Your friendly neighborhood IT department in conjunction with the Operations and Service Offering product group. This raises the quality bar for your traditional IT shop.

Oh, and by the way, these must be provided at a very low maintenance cost so as not to cut into the profit of the low profit-margin SaaS business. As noted in the Wall Street Journal the other day "Microsoft’s troubles in online services grew in the quarter as losses widened – to $245 million – due in part to increased costs of data centers..." ("Microsoft Net Surges With Help From Vista", Robert A. Guth, Wall Street Journal, Friday January 25, 2008). Of course, data center cost isn't the only factor to the $245 million dollar loss but it was a significant contributor. This is a sharp reminder that online Service Provider business must have efficient data center operations to be profitable.

The need to focus quality on the operational features to run a successful business isn't all that surprising. Geoffrey Moore once wrote "For core activities, the goal is to differentiate as much as possible on any variable that impacts customers' purchase decisions and to assign one's best resources to that challenge. By contrast, every other activity in the corporation is not core, it is context. And the winning approach to context tasks is not to differentiate but rather to execute them effectively and efficiently in as standardized a manner as possible." Business processes such as the customer-facing sales, fulfillment, assurance/support and billing are all core because they have direct interaction with the qualitative customer experience. Therefore, these processes become a top priority in order to be competitive in the online software service market. This understanding is a critical component for software service providers today.

Customer 2.0 is here and she has a major impact on business models and system architecture

Gabriel Morgan — Sun, 18 Nov 2007 23:44:00 GMT

One of the major tasks on my plate is understanding the impact of business systems to support the explosion of Software as a service business offerings, such as Exchange Hosted Services, Windows Live offerings and Microsoft Dynamics CRM Live. These business offerings all stem from the 'Subscription' business model built to support our overall Software + Services business strategy.

As I think about the S+S business strategy with my team, we, the Microsoft IT Enterprise Architecture Team, has realized that we must better understand the difference between customer expectations and how these customer expectations influence business models and IT systems. Through our work, we've learned that there is a quite interesting and simple relationship between the enterprise business applications and customer expectations. As we researched customer expectations, we discovered that a new customer profile exists, or is in the midst of existing. This new customer profile has forced the Subscription business model to exist and requires us to have a fresh look at our IT system landscape to support the business model. We have coined the term Customer 2.0 to describe these new customer expectations and this will be the topic of this blog.

My hope in this blog post is that the penny will drop and you will see that a significant change in customer needs has occurred and these changes force a deep and hard look at the supporting IT system infrastructure.

Okay, let's get started. Customer 2.0 marks a significant change in our understanding of the software market. Before describing Customer 2.0, let me first describe Customer 1.0 to help give context.

Customer 1.0 has expectations including:

Buys complete software packages
Responsible for software installation and maintenance
Pays for distinct software upgrades
Owns and controls data
Locked-in financially because of large up-front costs to purchasing software
Delayed usage due to search-buy-ship-install
Finds it difficult to move from one software package to another

Customer 1.0 is serviced by a more traditional Packaged Software business model which has characteristics including:

Low volume / large dollar transactions
Quantitative is more important than qualitative software features
Indirect customer channel via partners and suppliers
High barriers to entry and exit
Fragmented and specialized customer support
Structured product and price models

Through a change in environmental trends, Customer 2.0 has evolved. These trends have a huge impact on downstream business models and system infrastructure. Some of the environmental trends I'd like to highlight are:

Increasingly more competitive software market
Increasing digitized content
Proliferation of the Internet
Cloud computing
Social networking
Collaborative computing
Web 2.0 Mashups
Code-savvy users
Online advertising as a successful business monetization model

The above environmental trends have forced Customer 1.0 to evolve to Customer 2.0 with characteristics such as:

Has optional purchase models (flat rate-based and consumption-based subscriptions)
Pays only for what they use when they use it
Adds features to the experience seamlessly
Expects upgrades to be free and continuous
Swaps providers easily
Has flexible software budgeting
Expects a rich internet application experience
Accepts ad-based features
Expects Self-service Problem Resolution and Service Management
Accepts internet/cloud based software that is not installed on-premise
Has data locally and in the cloud
Has a direct relationship with the Service Provider
Instantaneous purchase and activation

These characteristics are incredibly different and force a change in the software business model to service them. Hence, Subscription Business Models has emerged and are a large part of the Subscription business model (near synonymous to the Software-as-a-service business model in my mind), which is key to the Software + Services business strategy.

The S+S Business strategy requires a Subscription business model with characteristics including:

Dynamic product and price models
World class IT infrastructure : Reliability and Regulatory compliance
Customer data is integrated across services
Progressive levels of feature usage
High volume / smaller dollar transactions
Self-Service Problem Resolution
Regular Service Upgrades
Customer retention is critical
Self-Service Service Portfolio Management and SLA Management
Low barrier to entry/exit
Direct customer relationship throughout the value chain
Little customer segmentation
Unified customer support experience
Single 360 degree view of customer
No boundary from features to IT supporting systems
Subscription/consumption/points/adverts monetization models
Balance transfers from dollar credits to and from points

This business model is substantial and forces a new, fresh look at the IT systems architecture needed to support it. I've bolded words in the business model which should strike you as important; reliable IT, integrated services, high volume, self-service, unified customer support, etc. These are key attributes of the resulting enterprise business system architecture which I will go into in subsequent blog posts.

The purpose of this post is to level-set on the problem domain which I will address in later posts from the business system architecture perspective.

Service Delivery Platform (SDP) for the Enterprise

Gabriel Morgan — Sat, 29 Sep 2007 03:15:00 GMT

I'm noticing a lot of great improvements in Enterprise Architecture Frameworks, namely FEAF, TOGAF, Gartner EAF and ITIL (Yes, I see ITIL as an EAF now). They are embracing similar improvement themes like Business Strategy linkage, enabling agile business via Service-Oriented Architecture approaches, iterative delivery processes, federated team models, and process, information and system complexity reduction.

The good news is that they are learning. And the bad news, unfortunately, is that they are learning and each new concept they gradually expand and adopt takes a bit of catch-up with what industry thought-leaders already know and it takes time to get new ideas incorporated into EAF documention.

For those of us who have to sign-up and deliver to our CxO executives useful architectures usually anchor, somewhat loosely, to one of the popular EAFs out there and then liberally pull from the best practices that we discover. I'd like to highlight a best practice from a somewhat lesser known EAF called New Generation Operations Support Services (NGOSS) that may radically impact the way your EAF implementation looks today. The best practice is the notion of a Service Delivery Platform (SDP) from the telecommunications industry.

We all know that SOA is a powerful tool to enable an agile business but we don't know what the nuts and bolts, bits and bobs of the resulting well-formed business process, information and system architectures are if we use your typical SOA approach. Well, it turns out that the telecom industry has largely solved this and are working on the challenges of what comes next.

Huh? Am I saying that there's more work to improve our architecture after we get a first serious rev of architecture based on SOA? Yes, there is! Through continuous improvement and change in the business, we will continually modify our architecture to advance our business and be more competitive.

For example, based on the needs of faster delivery of services, there are higher levels of sophistication in how to do Service Management with features like Service Naming, Registry and Location Services, Service Policy Management, Service Quality Management, Service Configuration Management, and Service Rating and Discounting Management.

Another example, is the sophistications in how an enterprise will handle supporting shared services. Enterprise Architectures will need to support shared services and will require sophistications in Dev and Test environments, Governance process and team models, SDLC modifications, Customer Support and Service Consultation/On-boarding.

And finally, there are levels of sophistication how the enterprise architecture will look in S+S scenarios such as process, information and system integration with cloud services. Or, resolve how the architecture will handle partner collaboration and customer-centric challenges the business strive for.

Some may argue that these are already included in a SOA approach - these people are thought leaders and are very rare. For the rest, these bits of sophistication aren't even on the radar yet.

The point is that they definitely are involved and most mainstream SOA approaches out there today don't know this yet. The NGOSS framework is focused on these aspects and through the competitive, free market forces in the telecom industry, they are improving on their framework relatively rapidly. In fact, I predict that enterprises will begin to adopt them and we will see more and more of the SDP concepts built into enterprise products moving forward.

I suggest you take a look at the NGOSS and eTOM documents produced by the TeleManagement organization. Here's their website. Register for free and then start looking at the free material. Pay particular attention to the Enhanced Telecom Operations Map (eTOM), Technology Application Map (see image below), Technology-Neutral Architecture models and Shared Information Data (SID) model that make up the NGOSS EAF.

Of course, NGOSS is more geared to delivery of monetized services than support of an enterprise shared services. But the capabilities they have created to solve for service delivery in a Service Delivery Platform are relevant for the enterprise.

That's my main point of this blog post. I see value in NGOSS/eTOM as a catalyst for improvement in an Enterprise Architecture via, at the very least, a mature Service Delivery Platform to realize SOA. Hence, SDP for the Enterprise.

As it turns out, Microsoft has a strong competency in the SDP space and have a product named Connected Systems Framework (CSF) which is born from the telco industry but generic enough to support an enterprise. Here's more info on CSF: http://msdn2.Microsoft.com/en-us/library/aa445859.

Here's a rough CSF technical architecture diagram to help convey some of the components included in the CSF solution.

Also, have a look at the article "Efficient Software Delivery Through Service-Delivery Platforms" by Gianpaolo Carraro, Fred Chong, and Eugenio Pace found here: http://msdn2.microsoft.com/en-us/architecture/bb735303.aspx

Now, for enterprises seeking to offer Services in a S+S business model, there is much more here to leverage. More on this later.

How SaaS, S+S impact an Enterprise Architect

Gabriel Morgan — Thu, 30 Aug 2007 07:39:00 GMT

Mike Walker wrote a great thought-provoking blog post on the implications SaaS has on Enterprise Architecture. Although he noted some very interesting points, I thought I’d extend this a bit and describe the impact of my life as it pertains to SaaS because coincidentally, I'm an Enterprise Architect and am personally tasked in an initiative to help solve how Microsoft IT is involved with SaaS. So, I'm in the throes of the interesting implications of how I do my job as I address this challenge.

I posted some of the thoughts on how I address business analysis as part of defining the Business Architecture. I break up the problem space into two very different areas: Business Analysis for Consuming SaaS and Business Analysis for Providing SaaS. Here are the blogs respectively.

· http://blogs.msdn.com/gabriel_morgan/archive/2007/07/18/business-analysis-for-consuming-saas-services.aspx

· http://blogs.msdn.com/gabriel_morgan/archive/2007/07/18/business-analysis-for-providing-saas-services.aspx

Because I'm short on time let me blurt out some comments in the area of "EA implications for consuming SaaS software":

The distinction between business capability and applications is very important. This will get clearer as I describe the Business Architecture implications below. Btw, I wrote a blog about these concepts to put them in an information model view to help describe how they relate. See here http://blogs.msdn.com/gabriel_morgan/archive/2007/07/31/traceability-from-biz-strategy-to-application.aspx.
Application Portfolio Management is still in the picture. Although the SaaS service means that the software and infrastructure is in the cloud, they are still a part of our application portfolio and must be rationalized to avoid redundancy and managed to ensure we make informed decisions how to position it over time.
With regard to the Business Architecture domain, things get interesting with consuming SaaS services because:

There needs to be attention paid on consuming SaaS services which are ‘Supporting’ business capabilities rather than focusing on those business capabilities which are ‘Core’ to a business. Why only the Supporting business capabilities? Well, because we don’t want to be locked into the dangers of our businesses struggling to be innovative and agile with their business process and them being constrained by a SaaS software that automate them. Remember, that the majority of SaaS provider software out there is built to be supported by several companies simultaneously using the same code base.
There needs to be attention paid to the 'connectdness' of business capabilities and look for business capabilities that are relatively independent of one another. That is, look for business capabilities that have relatively little dependency on other business capabilities especially as it pertains to business process and information.
Business process integration. We need to still model the SaaS software in relation to business processes to ensure we are optimizing the value of the SaaS software investment.

With regard to System Architecture domain, things get interesting:

When desigin system integration for both business process workflows as well as the data integration needs via system-to-system data integration. There are some interesting innovations happening in this space as system and data integration themselves can be SaaS services but I digress. Anyway, think of the challenges of supporting systems in your local IT shop that must, and I repeat, must integrate with services in the cloud. Such challenges and being responsible for the Quality of Services requirements your business has as it relates to their system, which they may not even be aware depends on clous services, such as system reliability, system maintainability, system supportability, and system testability. Yes, these issues fall on the shoulders of the local IT shop and they are not simple to solve. In our experience, which is quite young, requires an astonishing close relationship with our SaaS providers to the point that sometimes it looks like they are merely an extension of our IT shop. I'm sure that this will change as SaaS providers and the consumers (aka us) work out the kinks of working better together and streamline the basic delivery activities but for now, we are still learning.
Presentation mash-ups. As an EA, we love the concept of the business being able to build their own applications using readily available software services via presenation applications and workflows. Nick wrote more about this on this blog entry so I won't cover it here. The point I want to make is that we promote those SaaS services which enable this type of situation.

With regard to Information Architecture domain:

Like Mike noted, attention must be paid to the information that can legally be stored in the cloud. Think financial information in Europe. This is not always legal for this type of information to leave the country.
Data integration needs are very important. We are very weary of storing data in the cloud if we have Quality of Service requirements such as Data Staleness of less than 1 hour (or thereabouts). This is just an observation and probably a result of a lack of maturity of system integration abilities and think that we will overcome this in due time.
Data Masters are left on-premise at the moment. We are very weary of storing master data outside of our control. In fact, I'm not aware of any such situation. Instead, I'm seeing more interest in SaaS software that stores anciliary or extended information that is readily retrievable to a master data store.

In short, SaaS provides a lot of potential cost savings that are of high interest BUT they do bring with them some interesting challenges to an Enterprise Architect to make sure that SaaS sofware is optimized for the business investment.

Business analysis for 'Consuming' SaaS Services

Gabriel Morgan — Thu, 19 Jul 2007 07:34:00 GMT

In a previous blog, I posted some considerations to assist analyzing a business for opportunities to provide a SaaS offering with a focus on the bits that directly impact system architectures to enable the SaaS business model.

In this post I want to continue the thinking in that post but talk about considerations for consuming a SaaS service. This is a very different mindset. Providing SaaS services is about providing SaaS services to make money based on core business capabilites. This post takes a completely different tack and focuses on improving the efficiency of supporting business' capabilities.

Essentially, the approach by Geoffrey Moore is reused but instead of focusing on ‘activities’, business capabilities are used.

Once supporting Business Capabilities are found, here are some considerations to analyze whether it makes sense to consume SaaS software services to enable them instead of rely on your in-house IT department. Although I'm sure that this isn't an exhaustive list, it is what's on my mind at the moment.

· SaaS TCO. Cost/Benefit analysis includes:

· Hardware, Software, People and key ‘ility’ costs such as availability, reliability and maintainability.

· SLE + SLA costs versus local, in-house SLE + SLA costs

· IP Loss analysis. This bit is often overlooked. What I’m trying to describe is the loss of expertise of the systems and, more importantly, the people who manage them that will be lost when they are essentially outsourced to a SaaS provider.

· SaaS Integration Thresholds. Biz process, system and data integration and extension requirements.

· Vendor fit. Typical vendor evaluation but focusing on SaaS characteristics like SaaS platform strategy, SDP maturity, etc

· Local regulatory compliance (eg data). Global and local regulatory compliance compatibility.

· BP change and optimization. Analysis to identify a business’ processes which undergo drastic or moderate change and, therefore, require a highly flexible SaaS service software.

Consuming SaaS services provides a great opportunity to bring value to your business and IT organizations by exploring SaaS and raise opportunities to realize the benefits SaaS brings such as time-to-market and low-cost IT systems.

Business analysis for 'Providing' SaaS Services

Gabriel Morgan — Thu, 19 Jul 2007 05:46:00 GMT

Should a business offer a SaaS product? Hmmm, I think it might if all the right peices are there. Part of my role in the MSIT Enterprise Architecture team is to think about strategies for improving our IT systems to enable the business. One very proactive technique to do this is to bring to the business new ideas and strategies for creating new revenue models. SaaS is a great opportunity to do just this.

I've been thinking of what considerations a business should use to analyze whether there is an opportunity to offer a new SaaS service offering to customers. The concept of a Business Capability (a high-level business function encapsulating people, process, technology and data) is very useful to this process by analyzing a business’ Business Capabilities to determine what 'Core' and 'Supporting' Business Capabilities exist to filter where further analysis should be conducted.

In the context of providing SaaS services, I like the approach Geoffrey Moore described in his book 'Living on the Fault Line' of identifying a business' core activities. In the book Moore writes "For core activities, the goal is to differentiate as much as possible on any variable that impacts customers' purchase decisions and to assign one's best resources to that challenge. By contrast, every other activity in the corporation is not core, it is context. And the winning approach to context tasks is not to differentiate but rather to execute them effectively and efficiently in as standardized a manner as possible."

I think that focusing on 'activities' is good but allowing for greater, more macro efficiency the same approach could use Business Capabilities in place of 'activities'. Therefore, I’ve modified Moore's approach a tad to find Core versus Supporting Business Capabilities.

I'm not going to focus on the business market and financial analysis needed to analyze whether a business should consider providing a SaaS service. Instead, I want to focus on analysis considerations that direclty impact the IT systems architecture needed to support a SaaS business model.

Once Core Business Capabilities are found, here are some considerations to analyze whether it makes sense to provde them as a SaaS service to customers. Although I'm sure that this isn't an exhaustive list, it is what's on my mind at the moment.

Direct versus Syndication Channel. Direct, Partner or both. You can imagine the different system architectures for providing a hosted service in a provider’s data center versus a syndication model where the vendor provides the hosted services that push service proxies to a partner data center for value-add systems to complete the Partners service offering. Or, even extend pieces of a hosted service to a partner’s data center for seemless integration of the partner’s value-added systems.
Business monetization models. Combination of models such as Ad-based, Subscription, License, SLA, Per feature, Per Transaction, Bandwidth usage, etc. You can imagine the variations in metering, profiling, and authorization mechanisms needed to support the SaaS offering. Also, think about the SLA quality of service requirements. For example, what if a SaaS business model was to offer a service with a guarantee of 95% availability versus 99.99% availability on-demand. This could yield very different system architectures.
SDP maturity. Architecture maturity of the IT system supporting the SaaS business model. This assumes that not every SaaS model requires the highest SaaS system maturity. Architecting a system to level 4, as described by Gianpolo and Fred in this article, is far more difficult than level 1 and 2.
Customer Relationship maturity. It's important to understand the Customer Support needs early and architect SaaS services for them. System needs such as self-service, expert knowledge management systems, software promotion/deployment/download and the fundamental need to bring the customer support closer to the customer could require complex requirements to your system architecture.

The point of the above considerations is to focus on what considerations and their outcomes directly affect system requirements that are crucial to craft a successful system architecture to enable a SaaS business model.

SaaS is not just SOA, S+S and Web 2.0

Gabriel Morgan — Fri, 06 Jul 2007 22:39:00 GMT

Microsoft has defined SaaS as "Software deployed as a hosted service and accessed over the Internet." (see here for the article). Although I don’t disagree with this definition (quite frankly, it’s hard not to), it seems a bit generic and could cause a lack of focus on what differentiates SaaS from the basic SOA concept itself. By being so generic, I’m concerned that what makes SaaS different could cause a bit of confusion to understand what SaaS is and what it isn’t compared to other IT concepts such as SOA, S+S and Web 2.0.

Gartner’s SaaS definition is “SaaS is defined as an application owned, delivered and managed remotely by one or more providers, where the provider delivers an application based on a single set of common code and data definitions, which are consumed in a one-to-many model by all contracted customers at any time, on a pay-for-use basis or as a subscription based on usage metrics.”

There are some key differentiating elements between these two definitions with major implications. For example, Gartner’s definition assumes a single instance, multi-tenant application. It also declares that all customers are contracted and pay for their services explicitly by a pay-for-use or subscription funding model. These two differences are important not because they are different from SOA and S+S but the downstream consequences of what they cause which makes them different. The metering capabilities based on a business’ revenue models and the support capabilities of a single code base, multi-tenant system architecture cause a business to really think about, and perhaps change itself, to optimize their business model and customer support model.

These two consequences are what keep me up at night these days. No, it isn’t the the system architecture of a SaaS-enabled service but the business need of either consuming or providing SaaS-enabled services. Although the SaaS system architecture is a major challenge in and of itself, as a techie I can conceptually envision a system architecture to solve this challenge.

I prefer to think of these two differentiating characteristics as the business needs for either consuming or providing SaaS-enabled IT services and the customer support capabilities for supporting them. These two characteristics are what make SaaS different. The rest of SaaS (eg the system architecture) is merely a specialized implementation of SOA, S+S and, in some ways, Web 2.0 in my opinion. That is, SaaS-enabled IT systems merely reflects a services system architecture designed to support specific constraints such as metering, role-based access, trusted subsystem security, activity-based service granularity, etc.

Getting the a) business models, b) customer support models and c) system architecture story to all fit together is really the challenge today. Overlooking any of the three components is VERY risky for successfully understanding a SaaS strategy for any organization.