The best "enterprise architecture" plan will never be realized as long as developers assume the client of a piece of code is another piece of code. In reality, there are people creating code and by and large those people do not think of other people as clients. This is where SOA (service-oriented architectures) will fail.
The value of SOA is clear. We've been trying to produce SOA software for years. I know COBOL applications that were built on the same principles. I was a team lead for a project that built over 700 functional core services in a three-tiered architecture in COBOL 74; we produced code that was highly reusable. Of course, that was all in a silo for the large system we were building for a financial institution. We built it with the mindset that this software could be reused in other parts of the organization. I was proud of that work, but in retrospect, we weren't very good customers. We were happy to try to find commercial off-the-shelf applications that could provide major functionality, but we weren't good customers of code within our own organization. We didn't even look for software we could reuse from within the organization. The problem hasn't really changed today because we are still focused on the code, making it "reusable." The problem isn't really in the reusability of the code from the code perspective. We have to understand that the client of the code is literally other programmers and architects. We need to see ourselves as service providers who are creating code that needs to be right for our customers. It has to be easy to use. It has to be easy to find. It needs to be marketed and pitched right, and it has to fit the customer need, and we have to be better customers ourselves.
