Hi, fellow BAs,
I've followed this dialog with interest and have a few points for you to consider:
The religious wars between methodologies and techniques don't have to be regarded as zero sum games. The techniques mentioned in the thread have strengths and weaknesses and can actually be used in concert quite effectively. For example, I typically use IDEF0 on a project to construct an enterprise-wide business process model down a couple of levels of decomposition. The business orientation of the IDEF0 model lends itself to review and revision by business professionals who can learn to love the simple IDEF0 syntax and semantics, but may be put off by the technical complexity of UML, for instance. Depending on the objectives of the project, such as automating the client's procurement process through work flow software, I may drive the process model down in a selected area to better understand the interfaces between the procurement process and other financial and logistics processes. At this point, dropping into UML or BPMN or developing detailed swim lane diagrams may be the way to go. The preferred techniques to use can be identified by considering the skills of the developers and the complexity of the business process, among other factors. A major advantage of the enterprise model is for new business generation--understanding how the process initially focused on relates to the rest of the client's business and where to go next. This is a win-win situation with a client who is serious on long-term systemic improvement. You can give good advice on how to proceed with the next project and have an understandable architecture with which to discuss options with the client.
A second point to consider is the tendency to equate IDEF0 to "old technology". To me, this is analogous to dismissing calculus as "an old way of working with numbers". Importantly, IDEF0 is a way of thinking and communicating, not a technology. I believe it has gone somewhat out of vogue because no one who really understands the profound philosophy underlying its design is active in training new business analysts. I happen to have worked at SofTech, the originator of IDEF0 in its initial form of SADT--Structured Analysis and Design Technique--for seven years and appreciate the richness and power that can be realized through its proper application.
A third point to consider is that the bigger game to play lies above the realm of specific methodologies and techniques to choose from. It lies in the larger strategies for helping a client transform--incrementally or aggressively--its business enterprise through better application of information technology and business process management. Such a strategy is Enterprise Architecture, which encompasses a broad range of architectural concepts and underlying methodologies and techniques. When you take on this bigger picture approach, it becomes evident that you need to understand how to mix and match your tools because no single tool will suffice for doing the whole job. There is tremendous potential for people who can grasp the whole picture and construct the resources that are needed to do the job properly.
Regards,
Chuck Patrick