I read Steve Yegge’s rant on Amazon and Google and, like everyone else in the tech world, thought it was fascinating. But the really interesting thing is Steve’s description of how the different groups at Amazon work together through services. It’s the most succinct and argument I’ve seen for diving fully head first into a complete SOA model.  And not just technically, but fully as a business.

The key to Jeff Bezos’ mandate was that the services would be designed from the ground up to be externalized. With that key requirement, you’ve suddenly gone from a simple API to an API with full documentation, full security, full SLAs, full Dev and QA environments, full versioning, etc.

I’ve only worked in one reasonably complex organization, and that was Intuit for three years after the acquisition of Homestead. While I was there, I saw the technical group at Intuit struggle with the problem of scaling their development community, and I think it was heading down a fairly common road: standardization on technologies and libraries (at every level of the stack feasible) to increase buying power, increase code reuse, and decrease training overhead.  But the result was also fairly common and predictable: central core groups struggling to enforce mandates while client groups try to work around the system.  There was (and probably still is) a move philosophically toward SOA, but even then, use of that SOA was often done when organizationally required as opposed to technically prudent.

In my opinion, Steve Yegge’s description of Amazon’s model is how any company of any significant technical complexity should work (including Intuit), and the benefits are profound.

1. With full documentation, security, SLAs, Dev and QA environments, versioning, etc., you remove much of the bureaucracy (i.e., meetings) that surround creating technology together. If you implement an SOA in name only, like just an API (which I’ve seen a lot because it’s considered just a technical concern as opposed to a full business concern), then you’ve just replaced an architectural design meeting with an API design meeting and not made any progress toward more loosely coupled technical teams.
2. In defining your service interfaces at a business level (including SLAs, etc.), client tech groups will be able to compare the internal service with external services.  For example, the company should encourage client tech groups to compare between AWS and corporate IT, and the client tech group should pick the best service provider for their needs.
3. The ultimate result of #2 harsh but true: if the client tech groups predominantly prefer AWS, the company should figure out how to satisfy their clients better or get out of the business of corporate IT. That is, you’ll find out very soon which of your technical projects have value and which don’t.  And I bet most of them will end up going away.