 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > SOA News > The business and IT roles inside SOA and BPM |
| |
|
|
|
|
| SOA News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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.
"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
IT roles
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."
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.
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
