Over the years, the software world has matured to the point where analysis and design are quite refined processes. Most people in the IT world are by now quite familiar with the main techniques used for gathering business requirements and developing system architectures. The role of Subject Matter Expert (SME, sometimes called a Domain Expert) is now commonplace on software development projects. This has served well for building line of business systems—software silos, if you will—that traditionally served the business unit for which they are built. Tapping directly into the knowledge of a business expert allows the development team to produce a solution that closely resembles what the business unit actually needs. This process is by no means simple, but it is at least common and well understood.

A unique SOA challenge is its need to bring together SMEs from across the enterprise. SOA builds a new collective knowledge base, representing how the business operates at a level above the individual business lines. This poses several distinct problems for the SOA analysis process. Representatives from every line of business need to be involved in analyzing the SOA's needs and capabilities. If each business unit has its own IT staff, it may need to participate as well.

It's not just an issue of getting more people to provide input, explaining what their department needs. As the number of people in this analysis process grows, so do the number of viewpoints. Business unit representatives may see the analysis skewed by their proximity to their unit of the business, neglecting the views and needs of other business units. This is really sort of to be expected, as each of these people function in an area they are familiar with and may not realize that other areas do not function in the same way. Usually, SMEs are leaders in their departments and may have an "It's all about me" attitude; where me is really my department. This is rarely intentional, but represents the fairly common form of system bias in SOA and integration initiatives I wrote about earlier. I like to have meetings with many representatives together to encourage the participants to see the larger picture.

In my line of work I often work in meetings with representatives from Finance, Accounting and Operations (post-Sales), along with IT. These team members all have unique perspectives of a single flow of data throughout the enterprise, but each only sees one piece. The representation of this data is different for each department, but the underlying entities are the same: Orders and associated financial data.

Finance usually is concerned with how revenue is booked and earnings are calculated. Accounting really doesn't care about those details, but wants to be sure that the General Ledger accurately reflects the intentions of Finance and meets GAAP and auditing requirements. Operations teams tend to be mostly concerned with moving orders through approval processes and between external systems, and often is unaware of how the financial aspects appear to either Accounting or Finance. A common conflict arises when Finance wants to recognize revenue that may be partially earned; Accounting says that will violate their GAAP; and Operations says you can't split orders without breaking their processes. Discussing the issues with all these representatives concurrently allows them to understand how the other departments interact with different aspects of this same data. When leaders from each line of business are confronted with the realities of the other lines, it often softens their resistance to compromise. Ultimately, they are all on the same team.