Service Oriented systems. Blocks or boxes?
Hanging around Jim from time to time, I get to hear many interpretations of SOA from various people.
One very common interpretation is that is a way (or the new way) to do EAI, to hook monolithic software applications together. Another interpretation is that it is a way to compose flexible automated information systems from discrete, cohesive, heterogeneous components that are joined together by, driven by, and adapt to business processes.
It’s the difference between a big black box made with a chunk of plastic and another made of Lego® blocks. 
The big black boxes can be moved. They can have windows cut into them. They can be stacked on top of and next to each other. They can be replaced with other boxes. All of these changes are typically slow, inefficient, and expensive. Reshaping them is supremely difficult.
Boxes made of little building blocks can be moved piece by piece if needed. Each block has an intrinsic means of connecting it to another block, and therefore to other boxes made of blocks. It’s easier to exchange one block with another (perhaps one with a hinge, or a slot, or a wheel). To make another box, you can reuse many of the same blocks. They are built to be put together, taken apart, and exchanged with others. They all have the same basic characteristics and mechanisms to make this fast, efficient, and cost-effective.
After writing this I started looking to see where else these distinctions have been made. Winston Damarillo of Simula Labs was talking to Joe McKendrick about commoditizing software much as what has occurred with computer hardware, and SOA (as well as Open Source) is a key.
The important thing to keep in mind though, is that quality componentry (or at least, fit for purpose) is what has driven commoditized success in physical manufacturing. Crappy software is crappy software, despite any architectural models it has purported to follow.
