There are many organizations – large and small – undertaking SOA initiatives. As much as the technical infrastructure, message processing, service governance, and web service monitoring are important for your SOA you cannot afford to ignore the organizational aspects. In this post, I want to not focus on your entire enterprise but your department or a group of development teams undertaking SOA initiatives. When aspiring for SOA success you have to have more than developers and technical leads on your side.
So who else needs to be involved? You need your requirements analysts, your data modelers, and production support staff all singing the SOA tune albeit in their unique voices. This post will talk about requirements analysts.
Many developers underestimate the impact of requirements analysts (also referred to as system analysts or business analysts). Some analysts mix requirements with design offering specific solutions to business needs. Requirement specifications end up becoming design documents. Why is this a limiting factor for SOA? Because, you want to identity candidate services, reuse existing service capabilities, refactor legacy and modern assets and govern these service capabilities as part of your SOA strategy. Imagine, sifting through a requirements document that specifies implementing functionality as stored procedures or batch jobs. Without care, this can influence your thinking – knowingly or unknowingly binding you into solutions that are not in line with your SOA goals.
You want your requirements analysts to specify the business processes the application needs to automate, enhance and the business capabilities required. You can then deduce the business services, the enterprise data services, and the BPM workflows that need to be developed. If your analysts are receptive you should persuade them to use a modeling tool that can specify an analysis model using a vendor neutral notation that can be imported into a BPM engine and converted into an execution flow. All said and done, the deeper point isn’t BPM or analysis model but about the what of the system. Using the what you can design the how. That is where SOA comes in addressing questions around what services you will build, which ones you can integrate with, which ones to decommision, and which ones to change. Requirements should clarify and not prematurely solve technical problems.
Ask your analysts to provide world class requirements including functional and non-functional ones. Persude them to stay away from providing technical solutions so you can figure out how to automate your firm’s processes within the context of your SOA efforts. This isn’t easy and won’t be possible with every project but that shouldn’t prevent you from trying!