Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  IDEF0 vs. Use Case
Previous Previous
 
Next Next
New Post 4/11/2008 7:55 AM
User is offline Adrian M.
764 posts
3rd Level Poster




Re: IDEF0 vs. Use Case 

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


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 4/11/2008 11:07 AM
User is offline Chuck Patrick
1 posts
No Ranking


Re: IDEF0 vs. Use Case 

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

 
New Post 4/11/2008 11:52 AM
User is offline Adrian M.
764 posts
3rd Level Poster




Re: IDEF0 vs. Use Case 

Hi Chuck,

I have a one word response to your post: "Amen!".

- Adrian


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 4/12/2008 4:23 AM
User is offline Kimbo
454 posts
5th Level Poster


Re: IDEF0 vs. Use Case 
Modified By Adrian M.  on 4/12/2008 10:13:05 AM)

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

 

 
New Post 4/12/2008 4:58 PM
User is offline David Wright
141 posts
www.iag.biz
7th Level Poster




Re: IDEF0 vs. Use Case 

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...


David Wright
 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  IDEF0 vs. Use Case

Community Blog - Latest Posts

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC