Friday, June 27, 2008

SQL Server Data Services Needs an Open Development Process Similar to that for ADO.NET Data Services and Entity Framework

Soumitra Sengupta’s Philosophy behind the design of SSDS and some personal thoughts post of June 27, 2008 explains SSDS’s total lack of relational features (or some might say “baggage”) in its present incarnation. Soumitra says:

Since we made an early decision to limit the number of hard problems we needed to solve, we decided that we would focus less on the features of the service but more on the quality of the service and the cost of standing up and running the service.  The less the service does we argued, the easier it would be for us to achieve our objectives. [Emphasis added.]

The last sentence applies to any software product or service. Taken to the extreme, this approach favors a service that does nothing. The SSDS Team’s objectives might not coincide with potential user’s objectives at this point in SSDS’s development.

Presently SSDS doesn’t have a role-based security model, support joins, order the sequence of returned entities, deliver aggregate values, or offer the other accouterments that DBAs and developers have come to expect from commercial and open-source RDBMSs. Obviously, SSDS’s target audience isn’t expecting drag-and-drop table and form generation offered by QuickBase and DabbleDB. But even after sprint #2 SSDS remains too “bare-bones” for me and most developers I’ve talked to.

At the end of his post, Soumitra throws the following bone to potential early adopters:

Over time, … as we learn what it takes to run a 24x7x365 service (nobody we know of is running a data service using a commercial database system at this scale and cost point) like SSDS, I can assure you we will start to expose capabilities of the underlying engine.  How quickly and how much will depend on our ability to provide you, our customers with the quality of service you need to trust your business to SSDS.

Sounds like a chicken and egg problem to me. Most organizations won’t devote resources to testing an offline database with the few features that SSDS offers today, let alone trust its business to SSDS without an inkling of if and when needed features will be implemented. I’m surprised by the few vague and guarded descriptions of SSDS features in the works, such as schemas, and the rationale behind their implementation.

The SSDS team should emulate Tim Mallelieu’s approach of describing new Entity Framework v2 features in advance and adoption of an open development process, which was initiated by Pablo Castro for Astoria. Tim made it clear what the priorities for EF v2 are in his Transparency in the design process post of June 23, 2008.

Note: Since we don’t know what SSDS’s current scale and cost point are, we can’t make a comparison with QuickBase, which is undoubtedly today’s most successful online RDBMS with 250,000 users and a newly established Developer Program.

1 comments:

Anonymous said...

Thanks Roger. Appreciate your suggestions.

An open design process where the community is deeply involved in the choices that are made is better than a closed process. I think we all agree on this. The question I have is how to adjust the process Pablo and Tim are using quite well to a service that revs every 8 weeks. Bear in mind that once we enable a feature for the service end point, it is hard to take it back. If I recall correctly, the Astoria design has changed quite a bit through the CTP process.

The 8 week sprint has an interesting side effect - till we start the sprint planning process, we do not know the prioritization of the work items. Makes it hard for us to predict what will get done and when.

Having said that, we should be more transparent in prioritizing the feature set for the sprints. It is on our plate to make this happen.