The SOA knowledge gap


By definition, SOA is about to build systems that serve across the enterprise. That results in another issue: the effect of personality differences on the group dynamic. This is only made worse by all those meetings with many representatives, since the reason they're all invited to participate is their differing needs. It is common for someone in the group (who generally is very persuasive or respected) to gain undue influence over the design decisions that come out of such sessions. To defuse this effect, I like to mix large and small group sessions, as well as one-on-one follow-ups (or pre-meetings, but be careful there). That helps sift through the plethora of information and divergent views that emerge throughout the process. This group dynamic effect is even more pronounced in a multinational enterprise.

The final issue is one that is common even in traditional software analysis: the communication gap. A question's answer can be very different depending upon how the question is asked. This can be the result of both basic communication skills and the context in which the question is asked (to me, context is part of communication, so maybe I'm restating here). Often when discussing the details of an existing process asking an abstract question generates an answer that's too specific. That is, the answer may be too implementation-specific, and does not help the enterprise architect to understand the scope of the problem as well as the specific variations of this use case.

For instance, the discussion might involve eliciting from the SME, "We need to receive orders in the formats A, B and C from partners X, Y and Z." It is important to not get too lost in the specifics of the moment. This can lead you off the important trail of an abstract understanding, disconnected from implementation details. The subtle and damaging problem is that it may be difficult to get back to abstracts after being so specific. Yet, you still need the specifics. Oddly enough, the difficulty can be either with the SME or the business analyst; or it can apply to the group as a whole. Sometimes, you can't help this. Just do your best to take notes; but be sure to be aware that the capability or service, is really receiving orders. There may be customer-specific implementation differences, but that is farther down the chain in the analysis process.

One trick I used a lot was to ask the SME the same question in three different ways, usually not in the same meeting. Often this exchange may follow a pattern like this:

"So what are the possible workflows (state changes) than an order can follow?"