 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > SOA News > SOA remaking business analyst job |
| |
|
|
|
|
| SOA News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
Service-oriented architecture (SOA) changes the traditional roles played by many IT professionals and business people, but no job is being more radically changed than that of business analyst, says John Michelsen, chief scientist at iTKO Inc.
SOA tool vendors most frequently focus on the role of the developer, but Michelsen argues developers are the least impacted while business analysts find themselves in a whole new ballgame. "I think it might be fair to say that the individual developer writing code is the least affected because he or she is taking requirements and building a component, testing components, and plugging it into a larger system," he said. "That in itself is not that different than it was five years ago. So, ironically, the developer may be the least impacted by SOA." Creating the requirements the developer works from is a role that has traditionally been done by business analysts, Michelsen said. But there is a world of difference between developing traditional requirements for mainframe or client/server applications and what now must be done for SOA, he added. Where once it was enough to produce a Microsoft Word document filled with 10 Commandments-style "the-system-shall" statements and screenshots illustrating the functionality end users required, SOA now requires detailed business modeling, he said. However, before anyone laments this new burden placed on business analysts, Michelsen points out that it is a good thing because they are more of a player in the process than ever before. "They have a new challenge," he explained. "It's good because it gives the business analyst more ability to define how these services function." After all, how interesting can it be to create a 300-page document filled with screen shots and statements that "the system shall provide the end users with … ?" Michelson said he is increasingly asked by his company's customers for help with the transition business analysts need to make to come up to speed with the requirements for SOA. To begin with they need to see how SOA is different and why. "As you start to decompose applications you've got a totally different situation that the business analyst has to deal with," he explains. "Things like system-shall and screenshots don't really apply. They have to learn a lot more about the business process and the business rules that are associated with a particular component." After a decade or more of mocking up Microsoft Windows-style screenshots to show application functionality, that whole concept has to be dropped, Michelson said. "As you go services-based, you don't have screens and you don't talk about screen elements," he explained. "You have to talk much more about business rules and business functions." In the past, business analysts could make decisions on requirements from the UI down, now they have to think about how their service functions and interacts with other services, he said. This new mindset requires a new toolset. Business analysts need to learn to work with business process modeling tools instead of Microsoft Word or whatever they were using to document requirements.
This is leading to a boom in business process modeling tools, Michelson said. Business analysts now have to describe the overall business application that is being built from the services. Michelson said it is no surprise that business process modeling tools from companies such as Tibco and IBM are such hot product categories. The modeling tools will actually make it easier for the business analysts to make the transition to SOA since the tools will allow them to describe processes in business language rather than IT jargon. Business analysts are already starting to describe end user requirements in terms of services and along with IT professionals they are taking responsibility for the application, he said. "Business analysts are starting to drive the application requirements as business process models, which is a great thing," Michelson said. "It's the end game for SOA because that's when you really know you've aligned the IT development with the business."
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||
|
|
About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
||
|
|||||||
