Some 2.0 anti patterns in Development As A Service

The main intent of the Software Development As A Service, is to outsource development to stay better focused on what is really producing value in the starting 2.0 pioneer's company.
A fresh and new idea is the real trouble of a Startup and most of the energy should be spent on that direction, while other problems are addressed trusting the services bought depending on the Service Level Agreement defined.

After a good experience in the 2.0 era in developing several online communities from the Service Provider point of view, I think it's time to share what I'm learning and the mistakes I'm doing in facing this kind of opportunities.

I'm calling those experience anti patterns because they are a good representation of what can be optimal in theory and is really ineffective in practice if the 1.0 culture is mixed with the 2.0 culture.


Embrace Software Development Company processes

Having the idea to implement all the software by delegating to a Development Provider, comprises the adoption of all IT culture of the engaged service provider.

This can be obvious a really proficient until the Startup Company is trying to figure its own development process asking the service provider to embrace and focus on its way of doing things.

This approach drives to two main drawbacks:

1. Startup company is now focusing ideas to development process that is not really creating revenue for its business;
2. Software development company is forced to change the way they do things, learning a new option in software development and focusing on the customer's process intention instead of customer business needs.

This moves the Startup's focus from the Business idea to development spending energy (and money) in thinking on gates instead of thinking on the time to market for even easier idea and Software development to produce process's artifacts (reports, well-formatted documents, etc.) instead of good software.

Focus cannot be easily restored because the current focus is to be compliant with the process. When choosing a Software Provider Company, a 2.0 startup should put in its decision table.
The way the provider works is a good point of evaluation and must be agreed with the Startup Company to avoid the process as the next collaboration's problem.


Identify a Service Level Agreement on each Service

Startup and Service providers should agree on both parties on how they're allocating or delivering services request.
A Startup Company should create milestones that bases the professional relation. Milestones are business objectives that potentially influences the ROI of the Startup Company, and Servicing company should base their SLA depending on the milestones objective.

A SLA identifies an interaction model where parties agrees to implement something that is really valuable; this creates a conversational and honest model where things go in the same direction and both.
The parties are focused on the goal. Without a SLA, a Startup Company is shifting to an investment protection system paradigm where energy are spent to avoid money loss. Without a SLA, a Service Provider focuses on service's accountability instead of service providing.
The more the Service Level is the more is the price for it. This simple rule can be extended in: the more on the service level of what is really indispensable the more a company can pay for it.


Easiness is not simpleness

A 2.0 application is a big mash up of Services around the network; in the 1.0 culture there is the idea of System Integrator that is responsible solely to do a kind of component integration.
Meanwhile in the 2.0 culture the idea of system integrator is hidden by the idea that services are available on standard protocol and then easy to integrate because it's just a javascript call or a bunch of ruby on rails lines.

The complexity of integration in 2.0 is the same of the 1.0, every integrated platform must be reliable, must work and have custom development associated. The big difference from 2.0 and 1.0 is that 2.0 integration is through services starting from the presentation tier, while in the 1.0 everything is hidden in the integration tier.

A 2.0 approach is to make the user interaction easier by leveraging on all the available technology: that's really complex and require great skill and good professionalism.


Re-DO to DO approach: talk and listen together

2.0 culture is pioneering, and fresh ideas are often not clear to be written as a strict requisite. It's easy to misunderstand what the customer is explaining and what the Service Provider is understanding.
Small iterations and a continuous conversational approach must be established to achieve the same goal. Customer and Service Provider have to thing that the counterparts are producing value day by day discovering things that are still unknown.

A 1.0 approach drives the customer to outline all the requirements predicting what will be, and in the most cases failing in some aspects. Failing means: redo the same thing. Consequences of the "redoing mindset" will be unable to launch the Startup's Services at each milestone. Redoing several times, breaks trustiness and team happiness.

A 2.0 approach is based on continuous improvement on things and from the failing paradigm moves to the Learning paradigm. Continuous improvement switch the mindset from stable services to perpetual beta services.


Conclusions

These are some of the things I've found from a first retrospective with all the involved players in my experience from the Provider Company. I'm sure this is only a starting point for the 2.0 anti pattern catalog and more will come from the experience.