One frequent challenge that process-design teams face is getting past a small number of intractable disagreements, often while trying to consolidate redundant legacy systems that enable similar processes, CSC’s Rhody says. “A lot of the conflicts are turf battles, people with competing agendas,” he notes, citing billing and customer information as two frequent battlegrounds. “There may be another organization in the same company that wants to do the same thing, with their own technology.”
The answer is what Rhody calls “the parking lot”: Put the 20 percent conflict on hold while you get agreement on the rest.
“When people see we’ve got 80 percent agreement and are making significant progress, they now have to start to resolve things,” Rhody explains. “Getting that forward momentum gives the sponsors the collateral they need to push forward.”
Rhody also suggests making sure to ground your planning phase in reality and specifics, including a shared taxonomy. “Most issues are about technology, interoperability, and business choice,” he explains. In a recent engagement where a client was trying to work out the process for getting a single view of a customer’s financial holdings, for example, “it was pretty clear to everybody what the process was for querying the systems. What was less clear was whose definition of holdings should be used, and how do you get the consensus on that.”
Services must be grounded in the real world, Rhody adds. “If every time your process is going to do a lookup by account number, and your services don’t have an account number, they use a social security number, you’ve got to know that. Starting from the business process downward to services doesn’t work -- you need to come bottom up and top down and meet in the middle.”
Lockheed Martin’s Vibbert, who developed a services-oriented modeling methodology for his company, includes tolerance for uncertainty as a best practice. Vibbert’s methodology centers on breaking down goals, business cases, and use cases, while simultaneously starting to define potential services, their SLAs, and a data model. The next step is defining core or common services that can be re-used across use cases.
“The tricky part is when you start defining the use cases, you can only identify X number of them,” Vibbert notes. “But there’s always that N-plus-1 that you might not think of. The nature of an SOA is ad hoc. Someone can re-orchestrate the services in an unpredicted way and get value as well.”
Because much of the execution-related learning on business process mapping and SOA is cumulative, experts recommend a continuous commitment to careful, collaborative planning efforts. “Organizations are building this in as part of an ongoing strategy to understand their business and data architecture,” says Jan Popkin, chief strategist for architecture software firm Telelogic. “As projects come along, they plug into that.”