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.
I’m with Don and
Tim:
I want RelaxNG. More importantly, I want
standards that are built like WS-* and RelaxNG.