Suppose that we were able to find a role for standards in a software-defined world. What would that role be? I think it’s obvious that traditional standards processes are simply not effective in the current age. They take way too long and they end up defining an architecture that has to be ignored if the end product is to be useful. So should we scrap them, or at least offer them another chance? These are my personal views with the wrong and the potential right.
I’ve been involved with standards for decades, and one thing that characterizes the efforts I’ve seen is the fact that they seem to take forever. The process is very formalized and participation in it demands you follow the processes. In many cases, these processes are time-consuming enough that it’s impossible for anyone to participate casually; you’d have to dedicate an almost full-time effort. That, of course, means that the standards groups tend to be populated by people paid to be involved. If you’ve got such a group, it tends to build a bit of insularity. Standards people are standards people. I’m not knocking them, just saying they are a very distinct group.
The insularity issue is a factor in today’s networking space, because we’re facing radical changes in the business of networking, which logically should demand radical changes in the technology. In the recent standards work I’ve been involved with at various levels, the need for radical changes worked against the mindset of many of those involved. Can you define a process that has to be agile, built using a glacial methodology? I doubt it.
The biggest problem, though, is the inspiration that necessarily underlays any great, sweeping, revolutionary concept. A large group of people can work on an idea, but it’s much harder for a large group to come up with an idea. Consensus and innovation are strange bedfellows. The standards efforts I’ve seen that were founded on something truly innovative were driven by the insights of just a few people. Rarely more than two, often only one. This set out a straw-man concept, which was then collectively refined.
Even if you get a brilliant insight, you can still trip over other factors. One of the seminal concepts in zero-touch automation is the notion of data-model-driven event steering to processes based on state/event correlation. The TMF called this “NGOSS Contract” and it was the brainchild (in my view) of a single person, about a decade ago. It was almost never implemented, and I probably talked about it more than the TMF did. A great idea, a foundation for revolutionary changes in operations automation, and the body most associated with operations (the TMF) didn’t move their own ball.
This point opens the “what could be done” topic, because what happened in this case (and in another I know of) is that bureaucracy killed even a good insight. The reason, in my view, is that you really have to do software stuff by starting a top-down transformation from goals to execution, based on an architecture (the initial insight). That’s better done with an open-source project, because a good software architect would work just like that. The trick is giving the architect the right starting point.
Which, as the TMF proved with NGOSS Contract, can be done by a standards group, but not in the usual way. What the group should do is appoint an “architect team” of a couple of people with solid background both in the topic and in software design. This team would then develop an architecture, a technical approach. The body would then either designate a current open source group (Apache, Eclipse, whatever) to pursue the high-level software architecture (with contributions from qualified people within the standards group) or spawn a new group from their members and perhaps some key invitees from the outside.
The next point to deal with is the bureaucracy, the process. Phone calls in the middle of the night are not a way to get the best minds in the industry to focus on your issues (or much of anything, truth be told). Standards groups should be built around chat/message collaboration, not real-time stuff. They should also limit the frequency of scheduled interactions, working instead to build consensus (as the IETF does, at least to a degree) based on successive contributions. In any event, the idea is to move quickly out of “standards” and into “open source” to build what’s needed.
There are a lot of very smart people with very strong qualifications to participate in standards processes, but they’re not being paid to do that and so can’t devote endless time to the activities. Building collaborative systems into the standards process, using Wikis (as software groups almost always do) to develop thinking, and using message boards for discussion rather than phone calls, lowers barriers to participation and makes it more likely that people with good stuff to contribute will be able to do that.
The goal of the process changes should be to align standards work with the practices of open-source software development. Remember, the plan is to have standards groups generate only the high-level architecture and gather requirements, then hand things off to developers to have them build the platform as a series of logical steps. Most of the work would be done during this phase, so the standards would be functional requirements and architectural guidelines only.
The obvious question is whether this kind of approach is realistic, and I have to admit that it’s probably not going to happen except under pressure. As I’ve said, I’ve been involved in a lot of standards activities, and they are populated by hard-working, honorable, and specialized people. That specialization means that they are likely to push back against major changes. That’s particularly true of industry bodies who have paid staffs and collect dues to cover their costs. Through the roughly 20 years I’ve been involved with standards, despite the radical shift toward software-defined everything, the old processes and traditional practices remain largely intact.
Pressure may come, though. Standards groups are, in my personal opinion, largely ineffective in today’s world. I can’t think of a single activity that shouldn’t have been done differently. At some point, companies are going to stop contributing resources to standards bodies, and stop paying attention to the results they achieve. To forestall this, those bodies will have to make changes in their processes.
We should expect that. We can’t run things in the Internet age with processes that would have been at home (and often were) in the heyday of the Bell System. Software’s injection into networking is proof of a profound shift in technology, and only a profound shift in practices is going to help us keep pace with the real world.
