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 ServicesThe move to service-oriented architecture is the most important trend in application development today. Although SOA was possible without web services, the universal vendor agreement on SOAP and its fellows has let this undeniably good idea go mainstream. Understanding SOA with Web Services is a guide to moving into this new world. Written by Eric Newcomer, CTO of Iona and author of the award-winning Understanding Web Services, and Greg Lomow, a consultant at BearingPoint, this book provides a clear description of the fundamentals of SOA and what it offers. Among other things, the book looks at how SOA can be applied in integration scenarios, how it allows access by diverse clients, and how SOA relates to business process management. It also provides tutorials on the major new web services specifications, including WS-Security, WS-ReliableMessaging, and more. To order a copy, visit Amazon.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's February/March Speaking ScheduleFebruary 3: February 15: February 16: February 17: February 21: February 23: February 24: March 8: March 9: March 16: March 22-24: March 29: March 30: March 31:
|
|||
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
|
|
||||