The business and IT roles inside SOA and BPM

By Rich Seeley, News Writer 20 Mar 2008 | SearchSOA.com

Digg This!     StumbleUpon     Del.icio.us

Most of the focus on service-oriented architecture (SOA) implementations focuses on what IT does, but Sandy Carter, vice president for SOA and WebSphere strategy at IBM, is looking at what business people need to do to make SOA a success.

For more information What IBM learns about SOA from its customers Selling SOA to the CEO

"We went through and said: What are the roles that we need to look at?" said Carter, who is the author of a book titled "The New Language of Business: SOA & Web 2.0."

She has identified eight roles where business people interact with IT people in the development of a typical SOA business process management (BPM) application:

Business roles

• Business Leader: Responsible for overall business performance, compliance and governance.
• Business Professional: Manages business performance and decides on strategic and tactical needs for a specific area of responsibility.
• Business Analyst: Interprets business professional and business leader requests and documents them into process models.
• Process Analyst: Specialized business analyst who concentrates on the simulation and analysis of processes in their business environments and their interactions.

IT roles

• IT Leader: A Business Leader responsible for delivering technology solutions that enable the business.
• IT Analyst: Interprets business analyst inputs/requirements in the context of IT capabilities, works with team on IT-based business process improvement
• IT Architect: Defines basic operational imperatives in the provisioning of IT services with a focus on resiliency, reuse and adaptability.
• IT Developer: Follows IT architectural principles to create "building blocks" for the construction of applications.

Carter notes that each of these people has not only a different role to play in SOA/BPM application development, but also a different point of view of the process. She uses a bank ATM scenario to illustrate how they view and interact to find a solution to a specific business process problem.

Beginning at the top, the business leader might look at the bank ATM system and ask: "Is there too much fraud?"

The business professional, who works for the leader, might then begin to focus on more specific issues by asking: "How do we add extra fraud detection capabilities to our system?"

At this business level, Carter points out: "They are not even talking about SOA yet."

In the next step, the business and process analysts might begin to work through security scenarios that could be addressed at the SOA/BPM level, such as events that might trigger a security alert: "If a person has three or more failed log-in attempts or if there is a large withdrawal from an ATM within 24-hours."

"They may get together and play that through," Carter says, "but they are each looking at different parts."

In this lifecycle of business services, she said the business professional would want to view the bank's business services policies, and track the policies that are in effect. The business leader would want to manage the enforcement of all those policies, reviewing at service level agreements (SLAs) and usage patterns.

Over on the IT side, the IT Leader would begin to look a the bank's ATM security system in terms of how to better manage and govern the lifecycle of the different services.

"So each plays a role that's equally important," Carter said.

She notes that the different views they take would even impact the kind of rich Internet application (RIA) dashboard data that they would view in an SOA system.

"Think about dashboards that have SOA on the back end," Carter said, "so you've got the information wrapped as a service, you know that the KPIs [key performance indicators] and alerts that you have on your dashboard would vary from business leader, IT leader and business professional."

We find that 80 percent of process change in an organization fails because the organization didn't understand the impact of that change. Sandy Carter Vice President for SOA and WebSphere Strategy, IBM

In the SOA/BPM scenario, different types of analysts would use different tools to begin to get a view of the business process, how it might be changed, and how that change would impact the overall system, Carter said.

Based on experience with customers, she said the business analyst might document their business processes in Microsoft Visio. The process analyst might then import the Visio diagrams into more sophisticated modeling and simulation tools.

"That allows them to capture process data," she said. "Then they would be able to simulate that process and then come back to the business analyst and say if you made this process change, here's the effect of that process change. It might not be what you expect."

Modeling and simulations on the business side can catch problems with proposed BPM changes before it is ever turned over to IT, Carter explains. This can help prevent situations where an application is developed only to have everyone involved discover unintended negative consequences.

"We find that 80 percent of process change in an organization fails because the organization didn't understand the impact of that change," she said.

Once the business side has come up with a process that works, it can be turned over to IT where the IT analyst, architect and developer can begin implementing the process as a set of services in SOA, Carter explained.

"So every role has a part to play in the deployment moving forward," she said.

Tags: Business process management (BPM),  Service-oriented architecture (SOA) development,  SOA implementations,  IBM Web services,  Ajax and RIA (Rich Internet Applications),  VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us