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:

  • As service-oriented architectures make composite applications more common, the process logic that drives these applications—commonly called an orchestration—must be created and maintained. This is commonly done graphically, and at least a large part of this work can be done by business analysts
  • The rise of business rules engines (BREs) also opens the door for BAs to play a larger role in creating applications. Defining business rules externally using a BRE rather than embedding them in code makes good sense for many kinds of software. Rules become easier to change, for example, and they’re also simpler to understand, since they can be expressed in an English-like syntax. Business analysts are by definition closer to the business, and so letting them define and modify these rules sometimes makes good sense.
  • BAs can play an important role in defining the specifics of business activity monitoring (BAM). BAM technologies provide business people with understandable, up-to-date information about running business processes, which is unquestionably a good thing. Yet doing this requires some grasp of how these processes function at a technical level, along with a clear understanding of what business-oriented users want to see. This mix of business and technology understanding is exactly what BAs should provide.
  • Business intelligence (BI) applications can also be thought of as being in the domain of business analysts. Defining report formats, creating and analyzing online analytical processing (OLAP) cubes, and data mining are all tasks that require some technical knowledge coupled with strong roots in the business.

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

The 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 Schedule

February 3:
Keynote (in-house strategic planning meeting): “Keeping Your Balance: Technology Businesses in a Globalizing World”
Silicon Valley, CA

February 15:
Keynote: “SOA, BPM, and BI: A Unified View”
Memphis, TN

February 16:
Architect presentation: “Understanding Microsoft Indigo”
Chicago, IL

February 17:
Keynote: “SOA, BPM, and BI: A Unified View”
Chicago, IL

February 21:
Keynote: “SOA, BPM, and BI: A Unified View”
Birmingham, AL

February 23:
Keynote: “SOA, BPM, and BI: A Unified View”
Orlando, FL

February 24:
Keynote: “SOA, BPM, and BI: A Unified View”
Ft. Lauderdale, FL

March 8:
Architect presentation: “SOA: What’s Next?”
Salt Lake City, UT

March 9:
Keynote: “SOA, BPM, and BI: A Unified View”
Denver, CO

March 16:
Keynote: “Software in a Service-Oriented World”,
Software Development West
Santa Clara, California

March 22-24:
Presentations on SOA, Indigo, and related topics
Milan, Italy

March 29:
Presentations on SOA, Indigo, and related topics
Copenhagen, Denmark

March 30:
Presentations on SOA, Indigo, and related topics
Amsterdam, Holland

March 31:
Presentations on SOA, Indigo, and related topics
Bucharest, Romania




David Chappell is Principal of Chappell & Associates ( 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
All rights Reserved.


To subscribe or unsubscribe to this newsletter, go to