SOA planning: Sizing up business processes

Successful service-oriented architectures begin with process modeling and careful collaboration between IT architects and business stakeholders

As SOA goes mainstream in the enterprise, its success may hinge on a crucial meeting of the minds -- a mashup of talent that can uncap a font of creative potential.

On one side of the mashup are architects and developers, who up to now have perhaps been designing point Web-services deployments or legacy systems wrappers. On the other side are business process modelers, who’ve been mapping out how your business really works and what it needs, often in isolation and with limited ability to act on their process insights.

Before enterprises deploy SOA on a large scale, experts say, getting these teams together in a disciplined planning exercise can unlock the business value that process modelers knew was there all along.

“I think the business process modelers were waiting for SOA to show up,” says Sean Rhody, a chief architect at the CSC Consulting Group. “Without being able to define services, they were always talking at a level that didn’t connect to the actual implementation at all.”

Before SOA, says Sandy Carter, IBM’s vice president of SOA and WebSphere strategy, “you could do all this wonderful mapping of processes, but the underlying technology didn’t Click for larger view. exist to support any major changes in the process. Now IT has the technology to offer services on a business activity basis, whereas before it was on a technical subtask. Process is becoming that common vocabulary that exists between the business and IT.”

Before SOA, says Sandy Carter, IBM’s vice president of SOA and WebSphere strategy, “you could do all this wonderful mapping of processes, but the underlying technology didn’t Click for larger view. exist to support any major changes in the process. Now IT has the technology to offer services on a business activity basis, whereas before it was on a technical subtask. Process is becoming that common vocabulary that exists between the business and IT.”

And the payoff, says Forrester Research Vice President Randy Heffner, comes when the two groups work together to find business processes that share common services and prioritize the development of those services.

“It’s capturing business capability as reusable digital services, in a way that can be connected to any business process,” Heffner explains.

Across a range of enterprises, IT is laying the groundwork for SOA deployments that will have a transformative effect on IT, rolling out services that various applications can share and establishing governance rule for service design and interconnect. Yet woe to those who ignore business process planning and proceed directly to architectural design.

“If you don’t factor in your business process, you really don’t have an SOA,” says Tim Vibbert, senior systems engineer at Lockheed Martin.

Lessons from the front

What does it take to model processes successfully in an SOA context? InfoWorld interviewed consultants, analysts, and enterprise architects and got an earful from those on the front lines, among them Wachovia vice president Rohn Griggs.

“We’re just now scratching the surface around SOA,” says Griggs, who oversees workflow, imaging, and integration technology in the company’s business process modeling “center of excellence,” a group that provides enterprise-wide ground rules and guidance.

Griggs explains that although the company started from the bottom up, exposing legacy apps as Web services, it’s now trying to orchestrate those services around business processes such as loan origination.

“My team is trying to stand up some shared infrastructure with SOA capability,” Griggs says. “We’re good at business process modeling, and we’re good at exposing legacy applications as Web services. Now its time to say, ‘Let’s bring the two together.’”

To do so, Griggs is leveraging his center of excellence, which sits within corporate IT and now also oversees integration. The group includes product specialists (developers familiar with modeling), process engineers (who interview business users for process-centric modeling), and a consulting organization that markets the technology to the bank’s lines of business. The bank also has a roundtable steering committee for SOA and process modeling, made up of architects from each line-of-business organization.

“The way we typically start a project is with a daylong kickoff meeting, including breakout sessions where we interview subject-matter experts on their perspective,” Griggs says. Then his team gets down to work, developing process maps that can be played back to the business in a two-day validation session -- including re-engineering proposals, for example, to eliminate costs or reduce cycle time.

Be prepared for resistance from the line of business when you try to map business processes as they actually are, Griggs warns. “You wouldn’t believe the amount of pushback we get. They’ll say, ‘We don’t need you to model, just do it like we tell you. I know how I do things today; I know my process is broken.’” Griggs advises IT to refuse this type of engagement.

“That’s a big lesson learned for us. Validation of the as-is is imperative,” Griggs says. “It’s an eye-opening experience when the business sees a process-centric view of their work. They’ll say, ‘Geez, I never thought of our process that way. Why do we staple that in the upper left hand corner? That’s the way we’ve always done it.’”

Another key is to completely ignore organizational constraints when mapping a business process, says Griggs. “We look at how do we make it end-to- end the most efficient, streamlined possible even if it crosses business boundaries.”

Griggs recommends working with outside consultants who can help benchmark you against other organizations, but not giving them too much control. “Don’t try to do it alone,” he says. “You still need to run it as an internal project. Just use the consultant’s expertise as staff augmentation.”

Click for larger view.

The great methodology debate

Although process modeling has been around for years, the mashup of process modeling and SOA is still new enough that analysts and consultants have strong and often differing opinions about best practices.

IBM, which worked with Wachovia on its pre-SOA deployment process mapping, emphasizes a rigorous methodology called component business modeling for synching up processes with services, starting with proactively selecting the processes that will help differentiate businesses.

“Today, people are selecting the project they dive into based on their history,” IBM’s Carter says. “If I’m an ERP shop, I’ll start from an ERP perspective and move out. If I’m a datacentric shop, I’ll start from my data view and move out. Only 20 percent are re-architecting from SOA; the other 80 percent are starting with their heritage.” What enterprises should be doing, Carter argues, is looking at their processes across the board, and identifying the highest impact opportunities -- such as improving customer satisfaction, enabling better collaboration, or more quickly getting new products to market. “If you try to start with ESB [enterprise service bus], we’ll push you to look at your process,” Carter says.

“The process you select to start with SOA on is crucial.”

As an example of how small process shortcomings can have huge business impacts, she cites a Columbian coffee company that had 17 different ways to label a single coffee bean. “Because they had different ways to qualify it around the world, they couldn’t tell if they were in or out of stock -- it was there, but just designated a different way. It seemed like a simple little thing, but it was costing the company a lot of money.”

In IBM’s component business modeling framework, consultants typically pull together diverse business stakeholders for a rigorous, full-blown mapping exercise. A session with a retail industry client, for example, might include representatives from IT, business administration (HR, corporate strategy, financial planning, and compliance), distribution and warehousing (for logistics expertise), product merchandising, and marketing.

“This is all about governance,” Carter says. “At the very highest level of business, most companies are doing it as a business transformation. You need alignment of business and IT, and a set decision-making process. And you need rules for compliance -- everyone will use this particular service.”

Just don’t expect any magic formulas that can be applied across the board, Forrester’s Heffner says. “It’s less important to figure out which process modeling method you’re using, and more important to ensure that you’re getting a rich dialogue between the business and IT,” he says.

“Success now is characterized by personality,” Heffner argues -- the involvement of self-starters who combine business and IT savvy, create opportunities by making connections, build relationships around a process area, and just make things happen.

“Forget about best practices,” Heffner says. “Take bits from here and there ... just enough process modeling, just enough technology. This is not the kind of thing we’ve had in the industry long enough for it to be programmatized in a way that leads to good outcomes.”

Focus too rigidly on either pure process modeling or services architecture, Heffner warns, and you could end up in a methodology boneyard. “Three years ago, somebody drew some maps, and they’re not really part of any solution delivery process [today]. At this point, you should be establishing opportunities, designing your business as you’re designing your services, understanding how your business will function in the digital world,” he says. “You don’t want to freeze either of these design points … success is characterized by the dynamics of the process.”

Meeting in the middle

The key to a successful process/services mashup is how you execute it, according to analysts -- from methods for resolving conflicts, to grounding your assumptions in specifics, to leaving room for the business-use cases and SOA to evolve over time.

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.”