![]() Number 12 January 2005 |
![]() |
![]() |
![]() |
![]() |
Stalking the Wily Business Analyst |
![]() |
|
As we move further into a service-oriented future, the potential role of business analysts (BAs) gets bigger and bigger. Although their exact titles vary, a significant number of organizations have people in this role today. Whatever they’re called, BAs typically perform tasks on the boundary between business and technology, such as defining requirements for new applications. Responsibilities like these will still be an important part of a BA’s job in a service-oriented world, but changes in software technology are now making it possible for this group to play a more explicit role in development. Rather than just defining what software should do, BAs can now help create that software. Here are some examples:
It’s possible to imagine that BAs will occupy a position not unlike that of Visual Basic developers in the pre-.NET world. Just as VB developers performed somewhat less technical work and often had a stronger connection with the business than more technical developers, so might BAs provide a business-oriented approach to creating and maintaining key parts of applications. One could even imagine a software framework that served as a container for BA-focused tools such as orchestration designers and business rule editors. Rather than an integrated development environment, or IDE, analysts would use an “I-BA-E”. This is an attractive argument, one that makes good logical sense. And as I’ve argued elsewhere, more BAs will certainly be required if the service-oriented world we’re heading for is to succeed. But is all this really happening today? It’s hard to know. I routinely ask companies I work with whether they have people in this role. Some say yes, but based on my experience, a generous estimate is that 20% of organizations have BAs capable of taking over some aspect of creating software. Whatever BA-oriented tools are available, the population that’s supposed to use them doesn’t seem to be fully in place yet. For most companies, defining a specific role focused on building the more business-oriented parts of an application doesn’t currently appear to have an attractive return on investment. Another clue is the success of different vendor strategies in this area. Traditional BPM vendors have largely focused on the BA audience, and while some of these companies have a decent business, none has seen anything like the explosive growth of Visual Basic in its early years. As mainline software development has gotten more technical—VB has been replaced by the significantly harder VB.NET—tools aimed at BAs might be a natural replacement. Yet to date, this hasn’t happened on anything like the scale of VB’s success. It’s also interesting to look at the strategies of larger vendors in this area. In the first two releases of BizTalk Server, for example, Microsoft hosted the product’s orchestration designer in Visio, part of Microsoft Office, rather than the developer-oriented Visual Studio. Assuming a target audience of BAs, this makes sense. Why scare them away with the complexity of Visual Studio? Yet the product’s latest version, BizTalk Server 2004, now hosts its flagship orchestration designer in Visual Studio, with a relatively simple version hosted in Visio. Users of these two tools can interchange their work, which means that developers and BAs can happily work together. But a developer can also get along just fine using only the Visual Studio-based tool. This de-emphasis of the pure BA role suggests that Microsoft doesn’t have much faith today in the existence of a mass BA market. The most extreme pro-BA position, one held by some BPM advocates, says that BAs will soon be doing the bulk of application development. The other end of this continuum suggests that creating a true BA role in the software development process is a pipe dream. It’s a safe bet that the truth is somewhere in between. Another truth, though, is that we really don’t yet know where that in-between point is. I’ll admit to a bias—I’m attracted to the idea of BAs as the successor to VB developers—but I can’t marshal enough evidence to convince myself that it’s really about to happen. VB developers could once boast that they made up the largest number of software professionals on the planet, and business analysts might someday be able to make that same claim. Realistically, though, it’s too early to know whether they’ll ever wear that crown. Now Available: Newcomer and Lomow’s Understanding SOA with Web Services![]() Understanding SOA with Web Services is part of Addison-Wesley’s Independent Technology Guides series, for which I am the series editor. The books in this series provide big-picture views of important technologies, and they all have an easy-to-read layout with margin notes and plenty of diagrams. Each book also has distinct analysis sections, allowing the writer to clearly distinguish opinions, discussions of controversial issues, and other interesting topics. Watch for more books in the series later this year.
|
![]() |
||
|
|||
![]() |
David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, David helps information technology professionals around the world understand, use, market, and make better decisions about enterprise software technologies. David has given keynotes at conferences and in-house events in the U.S., Europe, Latin America, and the Middle East, and his seminars have been attended by tens of thousands of developers and decision makers in thirty-five countries. David's books have been translated into ten languages and used in courses at MIT, ETH Zurich, and other universities. His consulting clients have included HP, IBM, Microsoft, Stanford University, and other technology vendors and users.
|
©Copyright2005
David Chappell and Associates
|
|
||||
![]() |