Ann Bednarz, writing in BPM Today, provides a list of 10 best practices for SOA:
1) Start with a process that previously has been opened. In other words, the path of least resistance. Pick a "target system" in which other applications already have their hooks.
2) Don't take interoperability for granted. Just because a vendor says an application meets all the standards doesn't mean it will automatically interoperate with another vendor's application. Every vendor has its own flavor of "standardization."
3) Don't open your wallet too quickly 'Nuff said.
4) Think governance. Let me add, "do" governance. "Building a new framework for an entire corporate infrastructure is no easy task." Being able to understand and facilitate what services and standards are going into the SOA is a good first step.
5) A little incentive never hurts. People are set in their ways. Dangle a few carrots to encourage reuse, and adoption of standards and interfaces.
6) Budget realistically, or buy-in will suffer. Time, not money, is the great SOA killer. "Typically, the time and labor associated with building an SOA -- not the cost of purchasing technology -- can surprise the uninitiated." Dave Linthicum is quoted as saying that a good rule of thumb is to "allow about three or four months for each system an SOA project envelops; with normal complexity, a six-system project will take a couple of years from inception through funding, deployment and completion."
7) Don't skimp on documentation. That rarely ever happens, right?
8) Registries aren't a cure-all. Some commercial registries "don't do justice" to tracking both the technical details associated with services, such as translation requirements and service dependencies, and
functional considerations, such as what processes are involved.
9) Don't forget the network. "SOA is going to add to the load on the network -- it's that simple."
10) Mind your techie talk. Businesspeople won't get it.
Leave a comment