<<These days SOA methodologies; meaning approaches, game plans, check lists, whatever...are everywhere. Indeed, there are many out there who would like to tell you how to go about building your SOA. I guess that would include me if we're being honest.
It's tempting. I mean this stuff is relatively new, and many organizations are seeking guidance...where to start...what to do...and how to do it. However, some of the vendor delivered methods I'm seeing out there could do you much more harm than good. First of all, don't get me wrong, methodologies are good. It's helpful to have a set of procedures, instruction, or other guidance when you're looking to build something as complex as a SOA. Indeed, we've been using methods for years, including methodologies for structured analysis and design, object-oriented analysis and design, "traditional enterprise architecture," and now SOA. But, while using "a SOA methodology" is typically good, using a bad SOA methodology will kill you. That's the issue here. Many SOA vendors are selling services now, along with guidance pertaining to the implementation of SOAs, including requirements, technology selection, and more technology selection, typically without useful steps such as understanding your own domain properly and selecting best-of-breed technology. For instance: 1. Understand how You can Use Our Technology 2. Select Our Technology 3. Define the Value of Our Technology 4. Reselect Our Technology 5. Go to Steps 2 or 4 6. Pay Your Bill Promptly While I am being a bit flip here, this is not far off what I'm seeing out there. Moreover, I think many organizations are not spending the time they need to understand their own issues, and typically selecting the wrong technology for their requirements based on vendor advice. The result is a SOA that is not at all aligned with their business requirements, and an IT architecture failure that will drive the organization back to the drawing board. This not only wastes the dollars spent on the consulting and technology, but loosing the strategic advantage of having an agile architecture up-and-running sooner. So, how do you know you're using a good methodology? First of all, I would avoid using a SOA methodology from a SOA product vendor. Not that the vendor may have nothing but the best intensions, but they typically have a conflict of interest. They are interested in selling technology, not driving you to look at the technology you may need. You can use their services in the POC phases, and if you select their technology in implementation. Second, make sure the methodology has at the very least the following activities: 1. Define the ROI and align with business 2. Select a domain 3. Semantic-level understanding of the domain 4. Service-level understanding of the domain 5. Process-level understanding of the domain 6. Data abstraction 7. Service design 8. Process design 9. Technology requirements and selection 10. Implementation and testing Finally, make sure to educate the people in your organization responsible for implementing your SOA, and get the help you need. This is not just changing an application, it's a systemic change in how you do IT going forward, and you need to get it right the first time.>> You can read this advice at: <http://weblog.infoworld.com/realworldsoa/archives/2006/11/beware_of_soa_v.html?source=NLC-SOA2006-11-30> Gervas
