Here are three quotes on software development I ran across yesterday.
From Douglas Crockford, author of JavaScript, The Good Parts:
Just because something is a standard it doesn’t mean it’s the right choice for every application (e.g. XML).
From Yukihiro Matsumoto, creator of Ruby:
An open source project is like a shark. It must keep moving, or it will die.
From Roger Sessions, CTO of ObjectWatch:
A good IT architecture is made up largely of agreements to disagree. … Bad architectures and good both contain disagreements, but the bad architectures lack agreements on how to do so.
I once worked on a project that had a proprietary file format that became more sophisticated over time until it resembled a primitive relational database. After that I resolved to use standard technologies as much as possible. I think others have had the same experience and overreacted, using standard technologies even when they are overkill. Crockford’s comment is a reminder to moderate one’s zeal for standards. Moderation in all things.
I would add to Matsumoto’s comment that it’s not only open source projects that need to keep moving or die, though they may have an extra need for movement to maintain credibility. (Update: See this post on how software, networks, and storage all have to keep moving to survive.)
The way I understand Sessions’ comment is that good architecture focuses on high level agreement rather than low-level conformity. “Let’s rewrite all our code in Java” is not a good software architecture. Or one that I hear more often “Let’s move everything to Oracle.” Such low-level standardization does not guarantee a coherently organized system. Whether subsystems use the same implementation technologies is not as important as whether there is a good strategy for making the pieces fit together.
Thanks for the mention. My point is that architectural agility comes from allowing people to make decisions locally. But architectural chaos comes when those decisions are not tied together in a coherent way. So to give but one example, a good SOA describes how services are tied together through messages, but nothing about how those services are implemented. If the various service implementation groups can’t agree on a database, it doesn’t matter. Through agreeing that the services work together through messages (and only through messages), we have agreed to disagree on the implementation details, such as how data is stored, what language is used, etc.