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.