zVision is the future!
This internal memo was sent to SRS Software this morning. The points are important enough that I wanted to cross-post here.
Team,
I know there has been a lot of frustration over the last year as we have been working on zVision, the web platform, and ReEn. The shift we are making takes us from creating products to the creation of a platform.
So far, most have only felt the pain of the transition and have not seen the advantages. I promise you that this transition will be worth the pain and frustration. We are on the cusp of realizing a payout and it will be huge!
A guy who worked at Amazon and is currently at Google recently posted what was intended to be an internal memo on this topic. Everyone should take time to study the attached memo (http://steverant.pen.io) and understand the points that are made.
Here are a couple of threads where people are discussing Stevey’s memo that you may find useful:
- https://plus.google.com/112678702228711889851/posts/eVeouesvaVX
- http://www.reddit.com/r/programming/comments/l9ehj/steves_google_platform_rant/
I will continue to do everything I can to clearly communicate the amazing direction we are headed.
- zVision puts us at the forefront of the technology industry!
- zVision is the platform we need to carry us for the next 10+ years!
- zVision will give SRS the flexibility and agility to dominate in our chosen market!
You are welcome to send me questions or comments privately. Alternatively, I have cross-posted this to my blog and you are also welcome to publically comment there.
- Nate
Nate Zobrist | VP of Software Architecture
Service Repair Solutions, Inc. — Revolutionizing the Delivery of Service and Repair™
770 East Technology Avenue, Building F | Orem, Utah 84097
Phone: (801) 437-5846 | Fax: (801) 437-5899 | Cell: (801) 788-4789
www.servicerepairsolutions.com
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.
Historically 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.
Contrast 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?
Contract Definition and Stability
In my first zVision presentation that was recently given at each of the SRS offices, I identified one of Engineering's current problems as an "absence of trust" between teams. This phrase caused some confusion that I would like to clarify.
Let's say I want to write an app that integrates with the del.icio.us bookmarking service. My application will be reliant on their public API. So, for this venture to be successful:
The API's Contract Definition is essential:
- Method descriptions, examples, limitations and assumptions are all necessary and are included as part of the API documentation.
The API's Contract Stability is essential:
- Breaking changes should be very rare. Even with a disclaimer stating that it may change at any time, there is an implied level of stability in any published API.
- When a breaking change to the API is necessary, backwards compatibility will be provided. That's why their APIs all have "v1" in them!
Within SRS we should think about cross-project integration similarly to integrating with external services like del.icio.us. Except in very rare situations, touch points between products are limited to APIs (i.e. massively-versioned web services).
When I referred to "absence of trust" in zVision, I call attention to the fact that we do not yet have the requisite level of Contract Definition and Contract Stability in our APIs. Without both definition and stability, I could not trust the del.icio.us API enough to base my app on it. The same is true for building on SRS-internally produced services.
Since the end of 2010 and through 2012 we are making a large investment in re-architecting our products based on principles of SOA and SaaS. Absolutely essential to success are APIs which are both well defined and stable. Once we have those things, we can trust the services provided by other SRS teams as much as we would trust del.icio.us.