Creating Apps Should Be Trivial!

At Dreamforce ’11, a presentation I particularly enjoyed was given by Ryan Smith from Heroku. Titled Designing for the Cloud: The 12 Factor App, Ryan discussed some fundamental design patterns and practices that have made Heroku successful.

An interesting analogy that was made compares applications to swiss army knives. The analogy is relevant to SRS and provides a great visual depiction of the work we are doing as part of our SaaS and SRSWP initiatives.

swiss_army_knife_giant.pngHistorically our applications were designed as large, monolithic beasts. Like this knife, every feature that could be imagined was rolled into one of our flagship products. This design meant:

  • Duplicated effort because there were no shared components between product lines.
  • Intense effort required to join the team due to the large, interconnected designs.
  • Even small changes were risky and had the potential of destabilizing anentire product.
  • Management of each product line required enormous effort to tightly coordinate development and release of new features.

swiss_army_classic.pngContrast that complexity with a design where:

  • Components are small, independent apps that work together (like Linux tools).
  • Each component delivers specific functionality.
  • Touch points between components arewell-defined contracts.

The workflow enabled by this component-based architecture is truly liberating.

  • Small teams (perhaps even a single-person team) can build on top of the shared platform to quickly create new products.
    • Most products do not need to worry about operational infrastructure, databases, etc.
    • Products can take advantage of shared services to quickly enable powerful features in innovative ways.
    • Products can tap into shared repositories of both customer-generated and catalog data.
  • Existing products are simpler to maintain and introducing change is far less risky.
    • A smaller codebase means that the project is much easier to grok.
    • Well-defined contracts that have robust automated tests written against them mean that each component can be released independently with confidence.
  • Teams can work more efficiently by choosing technologies and frameworks that are tailored to fit specific needs.
    • Using standards-compliant web services for an API means that apps written in Java, Ruby on Rails or Node.js can access shared services as easily as a legacy, .NET application.

Following a component-based approach will make the creation of new apps a trivial exercise. It will free us to focus on solving interesting problems rather than being bogged down by operational overhead. The quality of our offering will increase as we become much more responsive to customers.

Applying these principles means something different for each of our existing projects and teams. What remains to be done for your team to fully benefit from this component-based design? What new functionality would you like to see exposed by the SRSWP?