I attended two recent industry events where the topic, of course, was service-oriented architecture (SOA). However, the information that IT and business executives need to begin their SOA initiatives was not divulged by the panelists or the software vendors, causing palpable audience frustration. The vendors all have a SOA angle and, not surprisingly, it revolves around a license sale of their particular software platform. In my mind, there are six broad questions people are asking about SOA and services: 1) How do we get started with SOA?
2) How do we identify the appropriate services for our initial SOA projects?
3) What technologies do we need and when?
4) How do we measure results? What's the ROI?
5) What organizational, process and skills issues will we face?
6) What governance policies do we need? Who owns the SOA efforts?
Here are the answers:
Question one is the most common question we hear on the field. Most executives are not sure what steps to take to begin their SOA initiatives . In general, start with a pilot behind your firewall to gain some experience with services. Start small in an area of your business where there is low risk and a clear business "win" associated with the project. Create a focused SOA team to spearhead these efforts. Empower this team to create the first draft of your SOA vision and plan, goals, and standards to employ during the pilot, as well as for ongoing efforts. Once you've got a pilot win under your belt, begin a broader analysis of the value of services and SOA to your organization. Look for internal integration and asset reuse opportunities and external customer and partner interactions to see where the initial wave of SOA value can be harvested. Base these decisions on an analysis of your value chain and major business processes as well as planned and current IT initiatives. Can any of these already budgeted projects benefit from SOA? Should they be reevaluated from a services and SOA perspective? If any currently budgeted projects have a services and SOA angle, work with the business and IT owners to encourage a services approach. There may be some selling required here, especially if the initiative is a high-priority, mission-critical one. Be careful and pick your targets to ensure success. If you can't begin with a planned project, begin the process with future projects. Bottom line: Get going. You're probably already behind one of your competitors. For question two, once you've determined these initial SOA steps you must determine the range of services that can be exposed or developed as part of your SOA business services roadmap. This process is pretty straightforward if you pay attention to processes and business-level "services" first, as opposed to trying to identify Web services. In fact, defining the term "services" is often a challenge for many organizations. Services are the general population of message-invoked business functions or application functions that are accessible and reusable within your SOA. Web services are a subset of the total services available to be reused and leveraged in your SOA. If you focus your efforts on Web services initially, you may leave other services opportunities on the table. Think about the big picture of services first, and then the subset of these services that may ultimately be exposed as Web services. I'll finish the remaining questions in future columns. If you have questions you'd like answered, e-mail them to me and I'll tackle them for you.