Should your company have a Standards Czar? An argument can be made for both Yes and No.
Presumably, you want any software your company writes to be compliant with the "rules" of the Internet. These rules, governed by the IETF and called RFCs (RFC stands for "Request for Comment" even after the standard is finalized), define everything from the definition of HTML to the proper way for e-mail servers to correspond with one another. The motivation for compliance ranges from a belief in the sanctity of standards to the desire, sanctity be damned, to make the technology work.
But even with the best of intentions, intending to be compliant and actually being compliant can be very different things. There is, frankly, a lot of information to know, and few people are expert in any one area to recite an RFC by heart (or to be invited back to parties if they do).
That assumes, too, that an individual or company really does want to follow the standards carefully and explicitly. Some, in the name of innovation (or "embrace and extend"), blithely make their own rules, and they expect others to make do.
Why, yes, I'm talking about Microsoft . Are you surprised?
But before I point to Microsoft Exchange as the villain of this piece (and I assure you that I shall do so), I want to highlight a meta-question with no right or wrong answer: where in the software development process does "standards compliance" fall? Whether it's Microsoft writing the next version of Exchange, or your own application development department creating a Web app that sends out e-mail notifications to users... whose job is it to stand at the white board, scribbling little RFC notations next to each action item?
I could argue that every company with a software development department should have a Standards Czar, whose job it is to ensure that every bit of code is as compliant as it should be. After all, Microsoft has a vice president of trustworthy computing who can order a product back to the drawing board if he finds a security problem. Is standards compliance no less important?
On the other hand, I could argue that standards, like security, have to be baked in from the start. Sure, you can and should test for standards-compliance during the QA process (though I worry that few companies actually do so). But if a Standards Czar is worrying about compliance after-the-fact, maybe it won't be top of mind at design time, when you're developing the software requirements. And some applications, such as e-mail servers, ought to be designed with a copy of the RFC as part of the application model.
I don't know what the right answer is. I'm sure that you and I could quaff several beers in pursuit of the right answer. (Make mine a good IPA, please.) But I know what it looks like when that question isn't addressed at all.
This blog post all started with a little "How 'bout that?!" that intrigued me. It blossomed into a long and detailed discussion about the, shall we say, less than admirable features of Microsoft's Exchange Server, with several kind and knowledgeable e-mail administrators. And that led to the larger philosophical issue that I think bears discussion even if you could care less about e-mail RFCs (hard as that may be for me to imagine) or if your chief concern is the annoyances of Microsoft's "embrace and extend" policy. (To which I can easily point you to concerns about Microsoft's IE 8, not that I think you needed directions.)
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.