Wednesday, 16 April 2014

Should we standardize technology or move one step ahead to standardizesoftware infrastructure

I have worked a better part of my career on standards related protocol stacks and middle-ware (SDKs, Frameworks, etc). Yet today the utility of the way the entire standardization activity is carried out can be questioned.  Standards involve the following main stages

(1) Identify a common direction or problem, encountered in the ecosystem.
(2) Multiple players get together to create a forum/working-group within a suitable SDO (that supports the ecosystem)
(3) The forum meets, brainstorms and designs a working solution on paper (i.e. charter, architecture and design). The technology is licensed under non-discriminatory to all players whether they are part f the forum or not.
(4) The ecosystem adopts the above work and everybody goes to the computer to write the supporting software infrastructure, carries out trials, inter-operability tests and the like. The problems are identified, solutions  proposed and this goes back as feedback [step (3)] for correction and enhancement.
(5) At some point the standards mature, the changes reduce and commercial deployments happen

This is how IETF, 3GPP, etc used to work. The entire cycle would take years (sometimes a decade) from start to finish. Very un-agile so as to say. Today we value frequent software releases, early feedback, welcome changes and prefer working software to bulky documentations.

 Now consider the following alternative:

(a) We have a (1) and (2), but instead of a big document (or revision) at the end of every 6 months, the SDO working group releases a simple architecture document and working software infrastructure as open-source to members every month (or even faster) highlighting how to use the new features, defects fixed rather than describe what is the wire-protocol or how it is working internally.
(b) The players immediately integrate (upgrade) the software infrastructure released by SDO in their Prototype products, carry out the tests and give feedback.
(c) Finally at some point the changes reduce and the software matures. At this point a small optimization phase is done on the software infrastructure, changes from multiple players (who are willing to share their innovation) merged into the forum OSS code-base.
(d) Subsequent testing achieves stabilization and now a final detail design document can be produced (as a subject of academic study and knowledge dissemination)  along with the working software.

How would (a)-(d) fare in terms of agility ? I think it would cut the overall development costs for every player, shorten the time to market drastically without sacrificing inter-operability (because everyone uses the  same implementation). In fact its likely that better inter-operability is achieved compared to the former process which leaves out chances of people interpreting (& implementing) some under specified parts of the standard differently (this is a very common problem). At the same time business logic innovations (that are the revenue spinners) are still protected.

Open source supporting such standardization work collaboratively done by leading players will result in a terrific force multiplier for the entire market. I already see the newer SDOs (like SDN forum with OpenFlow) working in a model similar to this by producing an implementation side by side of a document. 

No comments:

Post a Comment