We keep getting more and more field architects and architecture strategy team members blogging. Remember, I keep a list (I am becoming the Scoble of Microsoft Architecture). Anna Liu is a field architect evangelist who presented at TechEd Australia (but we didn’t get a chance to hang out). Anna’s also been thinking about software development as an engineering discipline.
In addition to Anna, two of my teammates are blogging: Chris Keyser and Dave Welsh. Chris is a solution architect who’s doing some awesome next gen SOA work. He’s been bloggingabout using WSE2 to manage Security Context Tokens. Chris, like John deVadoss (who has relapsed into silence), is very pragmatic so it’s great to run radical ideas past him.
Earlier this year, our team “inherited” a group of awesome vertical architects – I’ve blogged about John Evdemon before who’s from that group. Dave is also from that group. Like many of our vertical architects, Dave is heavily involved in standards bodies – in Dave’s case it’s UN/CEFACT. He’s got an great article on how Standards Development Organizations traditionally work and another on how MSFT (and our specification partners) is improving on that process. He’s shining a light on the dark corners of the standard process, which is a good thing since so many people act like standards are a silver bullet solution. I love Dave’s description of the traditional standards process:
[L]aunch a committee, politically pick a chair, generate lots of hype and expectation on how this spec will solve world hunger, stack the new committee with people who may be able to contribute, host conference calls and arm wrestle the original idea down to some compromise that seems to make sense, then hope someone’s got a number of free weekends over to write up a draft of the new spec.
You want an example of the results of a traditional standards process? How about XSD? I think XSD is the ugliest widely-used spec around. Don agrees, according to his comments from last years SellsCon:
Nothing illustrates [the cost of standardization] more than XML schema. XML schema is the quintessential example of what happens with a design by standards body specification. Rather than taking something that worked and something that was done and that there was experience with and effectively dotting the i’s and crossing the t’s you had two from every company off doing wanton innovation and invention without implementation experience. It was a train wreck in the making, especially when you consider the fact that you had people who vehemently disagreed about what they were building. Some people thought they were bringing object orientation to XML. Some people thought they were bringing database schema concepts to XML. Some people thought they were just, you know, reliving the SGML dream. So what do we get? We get a Frankenstein’s monster that is dumber than the dumbest person in the committee. No one person on that committee could have produced something this bad. It took an army of people to work hard day and night to build something that is not good. It’s not terrible – can we make it work? Yes. But it’s going to take a lot of work from a lot of plumbers and a lot of tool vendors to make XML schema palatable to the average developer.
A great example of the opposite approach is RELAX NG. It is widely believed at this point in time that RELAX NG is a better schema language for XML than XML schema. Why? Because two guys who were really smart said why don’t we go do this and let’s get it working and let’s build it while we do it and let’s iterate it and see what works and what doesn’t work. And then when we’re done we will take it to the rubber stamp – I’m sorry, Oasis – where they will carefully vet every decision and bless it and give it UN status.