How do you actually make your entire software architecture to be 100% SOA compliant? Which means that all the components of your software architecture are designed to be services?
Well, in my opinion, you need to define a clear roadmap for legacy applications governance and design standards for new components. It is not something that can happen overnight, but an incremental approach is generally necessary; it is a journey for the whole organization, not a just a new process to implement.
Someone else though, realized that a quicker and more pragmatic approach would work better.
I stumbled upon an old email sent by the Amazon CEO to his software developers, designers and architects, in order to introduce SOA. One of the employees shared the email, by mistake, on his public technology blog.
Before the email was sent, Amazon' software architecture was a silo architecture, without any internal API.
To tackle this problem, the CEO "suggested" this:
subject: Amazon shall use SOA!
body:
- “All teams will henceforth expose their data and functionality through service interfaces
- Teams must communicate with each other through these interfaces
- There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network
- It doesn't matter what [API protocol] technology you use.
- Service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
- Anyone who doesn't do this will be fired.
- Thank you; have a nice day!”
Quite a pragmatic approach for SOA governance, but looking at what the Amazon Cloud has become nowadays, it appears to me that it worked quite well.
Antonio
