Dan,

I enjoyed your comments and you are right on. I've been working on exactly this issue for about two years in my organization. It's like pushing a string across a table but when it works the results are well worth the effort.

We use a business modeling approach which I encourage anyone attempting this kind of work to investigate as it really helps to organize and rationalize the competing points of view of various stakeholders. Check it out at http://www.businessgenetics.com/portal/

Of course no methodology or tool helps much unless there is adequate business sponsorship for the initiative. We also find that the business SMEs we need to talk with are also being requested by every other change initiative in the organization so getting their time and attention is a challenge as well (and something that the sponsor can help with).

Dave McGinness

Thanks for reminding us of a critical issue that goes far beyond SOA. We've had this problem in systems design in all its forms.

I try to start with kickoff sessions where we try to show the whole pictire of what success looks like for the project. Then we can refer back as we progress, keeping our eye on the prize.

One major issue is nomenclature. On one project for implementing a project management system, the key was to get Finance, Accounting and IT to agree on what all the terms and rules of FASB standards (such as SOP 98-1 or EITF 00-2) really meant. The CPA's and the IT folks used the same words with different meanings (e.g. "pilot"). Once we dialogued to obtain agreement on what the terms meant, we could build an information flow that met everyone's requirements.

Again, thanks for reminding us of the critical need for early communication and interaction.

Christopher Technology Consulting

Re: The SOA Knowledge Gap by Dan Rosanova

I believe that a very senior level Product Champion is essential to any meaningful functional requirement definition effort. The role of the Product Champion is to enable organizational allignment, appoint a representative team of "domain experts" across organizational lines and to define the critical sucess factors for the effort being undertaken.

I further believe that this effort needs to be very structured and governed by rules. In my opinion gathering requirements through meetings simply does not work because organizational alligmnment is difficult to achieve. Also it takes too much time.

The whole effort should take two to three days in an off-site meeting with all parties present. This seems to bring about the best result with cross organizational alligments.

The result must clearly define the functional requirement, quantify the benefit to the business, define any constraints, business rules, and issues. When put in writing a competent progammer analyst should be able to develop detailed specifications from these requirements. Anything short of this is a waste of time and money.

Unfortunately not too many folks do it well.

Robert M. Menar
R.M. Menar & Associates
Pasadena, California

Dan,

Thank you for a well written article. The one point I'd like to add may seem tangential, but it greases the skids for the kind of cross functional discussions you mention: prior to starting any work like this on SOA, begin with the customer perspective, and map out the end-to-end value stream with your subject matter experts.

Not only will this help define the core elements of what generates value for the customer and revenue for the company (providing more than a few ah-ha moments and generating a heat map for prioritization), it turns company thinking away from internal organizational structures and aligns people on delivering things that the customer is willing to pay for.

Thanks,

Michael

So where are the unruly users - or is the title just journalistic hype to get people to click through...?

Nice article but I think managing business rules (policies, expertise, regulations) as requirements is as limited in SOA as it is in any project. Check out my response.

JT

James Taylor
Decision Management Solutions
Author, with Neil Raden, of Smart (Enough) Systems

You're absolutely right, but what's your point? Anyone taking on an SOA-like project has to understand its potential impact across the organization and have the authority to make happen. If you don't, you're wasting your time and will do more harm than good.

You think you have it rough?

General Motors has, or had, well over 100 manufacturing plants spread out across the world, managed by a dozen corporate entities, each with their own IT departments, and a considerable dislike for big-brother. While there was some consistency, for the most part even though they did the same basic SERVICES, (welding, assembly, paint, casting, purchasing, quality control, etc.), the systems in every one of those plants were unique. The cost of maintaining those environments was literally measured in the multi-BILLIONS of dollars every year. More importantly, while they felt they had instances of best practices, the diversity of environments prohibited their use across the enterprise. Consider the impact of this on GM's ability to leverage their resources, to be responsive to changing business needs, and to have anything that even looked like a corporate strategy.

You think you got problems? Count your blessings.

In this kind of environment if you don't have a vision, if you don't understand the extent of the problem, if you don't have the authority - and I'm talking Board of Directors - then you better just get off your horse. SOA, when you consider all the issues is NOT an IT issue - it is a business issue.