Once an IT professional gets his or her interest piqued in service-oriented architecture, the natural question is to ask, "All right, where do I start?"
The answer is at best uncomfortable – "It depends." It depends on what you've already got in place. It depends on how well your organization can absorb a paradigm shift. It depends on where your business opportunities lie.
You can spend a lot of time sorting through SOA maturity models, but you can run into square peg-round hole syndrome with those. The constant temptation is to seek out magic bullets, but remember the dictum that "SOA is something you do, not something you buy." Probably the soundest advice is to incorporate the principles of service orientation into your next project. Literally, do it.
Chances are your project can be service-oriented. You don't have to wait for an integration project to come along to build something integratable. You can decouple your business logic from your implementation code without having to leverage a pack of Web services standards. That's why we at SearchWebServices.com cover such a broad range of SOA-related topics. There is no standard pattern for adoption. The list of concerns, not surprisingly, extends across your technical and business architecture.
Last week we covered a mainframe project, the reach of composite application assembly and the importance of the SOA repository.
This week we'll be focused on virtualization and SOA inside small and medium businesses. We'll have tips on Web Application Description Language for REST, ADO.NET data interoperability and data architecture.
Where you start with service orientation isn't nearly as big a concern as how far you take it. We're talking about something pervasive here. If it seems like a lot to swallow, well, it's no larger or smaller than the size of your enterprise IT installation.
