Enhancing Your SharePoint Experience

This is the second in a series of articles on building elastic cloud applications. Read the first article here.

Adapting the Lean Startup principles to application architecture produces a few significant requirements. A Lean Architecture has the following properties:

• requires next to none upfront cash investment
• is flexible to changing application requirements
• requires little time investment to scale
• incurs moderate scaling costs

Taking these principles into account, it becomes obvious why some early design decisions may affect your business’ ability to cope with the challenges during the early stage and later growth. Cash is king and any required upfront investment directly affects the risk versus reward perspective. In Lean Startups where the product concept changes to reach a product/market fit, an upfront infrastructure investment may become obsolete quickly.

Utilizing well-known and widely deployed application stacks helps to quickly adapt to changing application requirements. There is nothing worse than starting with an exotic platform that fits well with the first requirements but calls for platform customizations to cope with changing requirements. Building on open standards not only provides cost-effective platform choices, but also introduces the flexibility to grow and incrementally adapt the application. After all, you are building an application and not a new application platform.

The desired product/market fit may not only bring joy and happiness. Quite the contrary, a sudden load spike may expose unknown bottlenecks in the application architecture. The result is all but happy customers and a lot of stressful hours for your team. The root of the problems are often small and not easy to grasp upfront. For example, increasing load with a growing average response time may put exponential burden on some application performance metrics.

Understanding the pains involved in scaling an application makes the case for using an elastic platform where the provider takes care of all issues involved with scaling. Cost and the ability to execute on this premise are key factors to consider when selecting a provider. The Cloud Architecture Overview illustration shows examples of several well-known cloud infrastructure providers. Due to their inherent scale, they are able to offer cost-effective solutions and their experience in running massive data centers underlines their ability to deal with nearly any load scenario.

Cloud Architecture Overview

Lessons Learned

• Lean Architecture for Lean Startups
• use open, well-known platforms
• scaling might be painful
• elastic platforms solve scaling issue

The next article explores building elastic front-ends.

This is the first in a series of articles on building elastic cloud applications.

This might be the year where enterprises finally adopt cloud computing. Despite all the hype about software as a service (SaaS), few resources focus on how infrastructure as a service (IaaS) helps Lean Startups avoid significant investments.

While IaaS saves monetary investments in hardware and long-term hosting contracts, it also frees up valuable human resources used to set up and manage data center infrastructure. And when your user base finally grows, the elastic cloud absorbs the extra load without creating sleepless nights and requiring urgent visits to the data center.

Design First, Less Worries Later

One important aspect to a successful application deployment is to pick proper IaaS services. With a diverse set of offerings, it’s easy to get lost in the cloud. Investing time upfront to properly design the application saves money but also prevents growth problems later. While enabling you to cope with rapidly rising demand, a well designed application keeps your most precious assets – your time – focused on adding value instead of dealing with infrastructure services.

To help guide the design of applications, we divide IaaS offerings into four categories: elastic front-end, batch processing, relational storage and data storage. The Cloud Architecture Overview illustration shows several example services for each of them.

Cloud Architecture Overview

Lessons Learned

• IaaS saves the most important resource – your time
• plan first, worry less later

The next article adapts the Lean Startup principles to application architecture.

Steve Jobs and Apple are known for astonishing product launches. Pictures and an emotionally charged experience effectively communicate the message to the audience.

Behind the scenes, significant efforts and a drive for excellence produce these impressive presentations. The slides below shed some light on how Steve Jobs creates these presentations with the help of his team.

Lessons Learned

• brainstorm, plan and practice over and over again
• create an experience for the audience
• a picture speaks a thousand words
• keep it short and simple
• bullet points are bad, hah

The Lean Startup vision introduces a methodology for building a technology product. In short, a Lean Startup is a low-burn technology venture which combines the Customer Development methodology and an Agile Software Development methodology.

Startups don’t fail because the technology doesn’t work. They fail because nobody wants what they are trying to build.

Eric Ries

Eric Ries and his blog ‘Lessons Learned’ offer insights on how to build a Lean Startup. A recent presentation from Eric Ries’ on Lean Startups in the Stanford University’s Entrepreneurship Corner explains his approach to building a technology product. In his pragmatic view on how to integrate Customer Development with Agile Software Development, he advocates an approach with two teams. The cross-functional problem team continuously validates the problem hypothesis and updates the product concept, while the solution team uses an Agile Software Development methodology to build the product from the product concept.

The Pivot

A key aspect to any startup is defining the problem that it tries to solve. Customer Development advocates a cross-functional problem team that intensively works with customers and continuously defines and adapts the problem hypothesis.

The systematic approach of Customer Development produces a series of invalidated problem hypotheses. At each iteration, the team adapts one piece of the hypothesis which includes, among others, customer segments, feature set and positioning. Each change builds on the lessons learned in validating the earlier problem hypotheses.

The pivot is the incremental change to the problem hypothesis. Building on the continuous feedback of the early adopters, the pivot represents the minimal change needed to address the barriers of the hypothesis.

The startup’s vision assures a coherent direction despite many incremental changes to the product concept. In the absence of a strong vision, incremental changes may steer the product concept into a random direction.

The Minimum Viable Product

Deciding what and when to ship to customers is a key part of any venture. During bootstrapping, limited resources force startups to find the smallest feature set required to engage with their early evangelists. Eric argues that startup teams often overestimate the smallest feature set by a big margin and that the best approach is to divide that first set down several times. Shipping the minimum set of features may produce surprising results from the customer base.

Despite a limited feature set, customer might actually be happy with the shipped features. Visionary customers are very forgiving as they not only buy into the current product but also in the startup’s vision. Furthermore, the view of the team on required features may not be aligned with the customer’s needs. In the worst case, customers will give their opinion on what features are missing to create a value proposition for them.

By focusing on the minimum viable product, startups avoid the mistake of building a product that nobody wants. By engaging with the target segment early on, the Customer Development methodology offers more advice on building a product for a few engaged customers instead of trying to build a product from the outset for everyone.