Details of What is Not SOA

Enterprise Architecture, SOA, and other phrases like it have become buzzwords within corporations today, yet sometimes I still find myself struggling to understand the terms. Earlier today, however, I came across this blog post, which discusses how to determine when something is not SOA. Below is the checklist that I found to be helpful:

1) If a vendor tells you that you need to buy a suite to get to SOA… it’s not SOA. SOA means complete freedom from suites and integrated packages.

2) If a vendor is trying to sell you hardware… it’s not SOA. Enough said.

3) If you’re sending out email inquiries or making phone calls to find out what services are out there…. it’s not SOA. Registries and repositories are essential for service discovery and validation.

4) If nobody’s sharing services… it’s not SOA. You can have all the standardized services you can handle, but if it’s services within silos and nothing more, then it’s services in silos.

5) If developers and integrators are not being incented or persuaded to reuse services and interfaces… it’s not SOA. Without incentives or disincentives, they will keep building their own stuff.

6) If your CIO is clueless about what’s going on with shared services… it’s not SOA. To truly function, SOA-based infrastructures need to cross organizational boundaries, and it takes someone at the management level to bring these efforts together. Otherwise, again, it’s services in silos.

7) If the IT department is running the whole show… it’s not SOA. Sorry IT folks, but SOA needs to have the business heavily involved in the effort as well.

8) If it only runs one operating system or platform… it’s not SOA. SOA has nothing to do with any single OS.

9) If it replicates a SOA in place elsewhere… it’s not SOA. Every company has unique business requirements and processes, and no two SOAs will be alike.

10) If you have to rewrite or redesign code to make things run right… it’s not SOA. SOA is supposed to make rewrites unnecessary.