This is the third article in a series with excerpts from this year’s workshop titled, “How to Eat an Elephant – Developing a Real-World Product SaaS Product Roadmap.” Each of these articles will cover one part of core subjects in our Cloud Product Roadmap. If you are just joining us – you can return to the first article in the series and find out more about the workshop background and other articles in the series.
Cloud Product Roadmap – Technical Architecture
Excerpt: Reviewing the Roadmap Template for Technical Architecture
In this installment, we going to look briefly at what needs to be in your Technical Architecture plan rather than review a part of the presentation from the workshop. We provide MS Word templates for each element of the Cloud Product Roadmap, which can be modified and brought together to document your plan.
So just for the sake of understanding the outline – let’s review the major points of a Technical Architecture plan as for SaaS and Cloud products we see it:
- Technical Architecture Design Model
- Technical Architecture Design Process
- Architecture Design Elements
- High-Level Architecture Requirements
- Application Architecture Design
- Tenancy Approach
- Scalability Approach
- Metering Approach
- Security Authorization & Authentication Approach
- Audits & Compliance Approach
- Provisioning & Implementation Approach
- Gap Analysis & Third-Party Solutions
- Cost Estimation & Optimization
It is important to note at this point that this is not the complete technical plan. The roadmap also needs to include Development and Maintenance Processes, Operations and the Support Approach. You will also notice something it doesn’t include: Long, detailed descriptions of end-user functionality. This is because we recommend companies with SaaS and Cloud products use Agile development processes. Using an Agile approach means that the application is planned up front at a high-level using “user stories” that describe the main points of functionality needed by users. These descriptions will be broken down in more detail during the development process, but within the context of the evolving application. This allows the product manager to consider what the application needs to do, but spend less time on about how the functionality is implemented. Today developers leverage a wide range of tools and frameworks to deliver rich functionality more quickly and with better quality than in previous years. But each set of tools has its own implementation pattern. A product manager that spends too much time specifying HOW things need to be done, rather than focusing the outcomes, is likely to be wasting time on specifications that don’t leverage the frameworks properly or creating work-arounds with increased risk and development effort.
Another aspect of this plan are the elements included specifically for Cloud and SaaS applications. Tenancy, Scalability, Metering, Provisioning and Implementation are all architectural issues that concern online applications. In our experience, it is common for product management to focus on end-user functionality and leave the specifications for operational purposes until a later time. In many cases, this means the development team either ends up “back-porting” critical functionality into the application or tacking it on the side somehow. This usually means that important opportunities to do it right the first time are lost and in many cases issues like metering never have the flexibility they need. The point of our templates is to help our clients to consider these and other critical elements at the right time in the planning process – before choices are made and effort is expended that is hard to back away from.
The Design Process
If you have an existing product or assets in the form of technical assets (libraries, web services, algorithms, etc.) you can migrate, the first thought is of course leverage them to build the new Cloud or SaaS product. Using them provides a level of comfort and could lower the total cost of development. However, depending on what the assets are and what technologies are involved, they may also become a constraint that will prevent you from optimizing costs, performance, processes and the user interface. ISVs with existing products quite often consider ways to leverage their existing assets – even going so far as to just host instances of their application for clients ASP style to get something in the market quickly. Their basic thought is that the value of SaaS or Cloud all based in the delivery model. Typically startups design their applications from the ground up because they rarely have technical assets to consider.
Existing assets that are not already setup for the Cloud can also suffer from a lack of operational features to automate customer on-boarding and implementation, feature packaging and pricing, and usage metrics. Conversely, building from the ground up doesn’t mean you have to build everything. Using the Cloud model, you can leverage best of breed components to fill the operational gaps and allow you to focus on developing your core value.
You can also leverage specific SaaS and Cloud platforms that provide a many of the operational elements of Cloud products and usually enforce a level of code consistency. These can greatly lower the effort required and can offer capabilities that you can use immediately but would rarely put in your first product version. The build or buy decision in this case is usually a product of business priorities for budget, effort and the time required to bring a product to release.
So, in essence, the design process is a series of choices and compromises that finally arrive at the approach for the final product. The choices can be difficult but are usually made easier by making a series of strategic business and product decisions before you begin to consider the technical architecture. Making decisions on the technical architecture before key business and product decisions are made can lead to wasted development effort and increased risk that the development process will take longer than planned.
Special Attributes of Cloud Products
Current Cloud products, particularly those that take advantage of services like Windows Azure, can scale compute, storage, and delivery in direct response to needs in a specific dimension. That means if the application needs more storage, but doesn’t need more compute power, storage capability can be scaled up (or down) by itself. Conversely, if the application needs to process a great deal of data, it can add compute until it reaches a satisfactory performance for the job at hand. This ability to scale elements of the application separately provides opportunities to approach design problems in new ways. Where before we scaled simply by adding more servers, which included all elements whether we needed them or not, we can now scale just what we need to meet demand. This changes the design process to include considerations for issues like:
- What processes can be handled by a compute role, possibly from a queue, and processed in the background to reduce front end pressure?
- What degree of scalability will be required by each process?
- How will the application scale up and down? What will be monitored and how will it trigger change?
- What types of data will the application use and what resource can be used to store it?
- Are there content distribution needs that could take significant bandwidth?
- Does our scaling model fit within our pricing, packaging and overhead model? Are there better ways to accomplish same end with a lower overhead? What are the trade-offs?
Each cloud platform has its own capabilities and design patterns so there is a learning curve in deciding which applies to a specific product and project. But once basic decision is made for the platform, the next level is to consider how to design the application so that it can scale and leverage the platform transparently and make the best use of its strengths. It is best not to duck the decision and just go for a simple virtual machine approach because, with the exception of a few special cases, most of the value leveraging a cloud platform will be lost in the process.
If working with the interplay of decisions between your product strategy, technical architecture and business model is something you are struggling with – you should consider joining us for our workshop! It will help you parse your priorities and bring together a roadmap for product development that meets your needs.
<Read the previous article in the series – Next article>
This series will be covering more in the days leading up to the event. But reading these excerpts will not give you all the material and is no substitute for attending and joining in the discussion.
How To Eat An Elephant
Developing a Real-World SaaS Product Roadmap
28th April 2011
from 8:30 am to 1:30 pm (including breaks)
The Venue
Embassy Suites – Southeast
7525 East Hampden Avenue
Denver, Colorado
Prices
- How to Eat an Elephant Workshop – Standard price – $499
- Register by April 1st for our Denver Workshop and take advantage of our Early Bird Pricing
Agenda
- The Business Case for the Cloud - Assess if the Cloud is for you by identifying the business opportunity, investment needs, risks, etc.
- SaaS/Cloud Product Strategy – Define the competitive and positioning strategy for your product within your context and your market.
- Your Cloud Business Model - Define how your product will make money and what is needed to make it happen. Developing your SaaS/Cloud Product Roadmap – Develop a tactical roadmap to align funding, development and marketing objectives.
- Key Technical & Functional Requirements of a SaaS/Cloud Product – Understand the architecture and functional elements required to deliver your service smoothly and profitably
- Cloud Readiness Checklist – Identify key requirements of SaaS and Cloud operations, customer support, legal, financial considerations, sales and marketing that you will need to prepare for to make your product successful.
You can take the workshop by itself or in conjunction with
SaaS University
THE Industry’s Most Comprehensive Cloud Application Conference
At the Embassy Suites, Southeast – Denver, Colorado – April 26th to 28th 2011
Prices
- SaaS University Package – Regular Admission – $999
- SaaS University Early Birds – $799 (Registrations By April 1st, 2011)
Get an additional discount from Scio – Regardless of when you register
- Because we are participating in this event, you can get an additional $100 off your registration.
- Just enter the Scio’s Discount Code: SCIOsave100 when registering for SaaS University.
Go to SaaS University Denver Registration Page
Recent Comments