Hi Kimbo,
You are absolutely correct, using IDEF0 is like programming in COBOL (I made a similar analogy to FORTRAN). And you are correct also that UML is the most popular modeling language/notation. But we should also remember that IDEF0 "used to" be popular at one point - so what happened? UML came along it became popular - arguably because it was better.
So, unless we think that UML is perfect, we should be open to the idea that there could be newer modeling standards which, in some cases, work better than UML. I am a frequent user of UML diagrams especially Use Case Models, Class Diagrams, Sequence Diagrams, and even Activity Diagrams. However, for business process modeling I like to use BPMN (a newer notation) which, I believe, is much better suited for this task. Even the OMG, standards body for UML, chose to add BPMN to it's list of standards even though, many argue, Activity Diagram could do as good of a job. Take a look at the BPMN specification - you might be surprised by what you find.
Best regards,
- Adrian
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
Hi Chuck,
I have a one word response to your post: "Amen!".
Yeah, well said Chuck.
I actually don't use either activity or IDEFO to model process. I'm currently using a tool that uses an approach based on, I think, Martin of EA fame. The tool is called holocentric (www.holocentric.com). I'm just a customer, not associated with them. It has the whole of business approach that I like and that you were alluding too, I think.
Perhaps we should call a halt to the religious wars as you say Chuck. I do love a good argument though.
Kimbo
Reading through the latest posts in this set, I started to get the feeling that someone was going to say "can't we all just get along?", but it hasn't happened and may be a bit unfair to imply.
But, I will reiterate a few things:
1) BA's should learn/use UML (and I mean other than use cases) because its popular? because the other kids are doing it? I still prefer to use what works best.
2) Use Cases may be an integral part of UML, but I guess that's because UML needs them, but you can use Use Cases very effectively for Requirements without the rest of UML. So when someone says they are using UML for Requirements, I would ask, "you mean you are using Use Cases?"
And that''s pretty much all I have to say on this...
brought to you by enabling practitioners & organizations to achieve their goals using: