UML the right tool .... Really !!

So i was talking to one of my friends and we were talking about BP "Business Process", and how does the analysis for a BP differ from other type of project. and he shocked me with his response that he model Business Processes with UML!!!

I: let me ask you one question, would you use a jackhammer to open a canned tuna? Him: No sure not.

I: Probably you are using a CASE tool right?
Him: Yes

I: What sort of diagram you gonna use?
Him: Activity Diagram for sure.

I: I guessed so, okay tell me Is UML a methodology ?
Him: I guess not.

I: Does Activity Diagram have a notation for processes fault handling and compensation, and data storage?
Him: hmmm i guess not.

I: Does Activity Diagram allow you to add sub-processes and define micro transactions?
Him: haaaa !!! No i Guess.

I: one last thing, does it allow you to express the 2 commit protocol of the transaction state?
Him: Okay it doesn't, what do you suggest?

I: first as an analyst you need to think out of the box, UML is not the only modeling notation in the world, plus its just a notation it doesn't tell you how to build you diagram, it just what is this diagram.

So whenever facing a situation when you need to model, think how I'm going to benefit from my model, or its just a one time thing, and will be thrown away after finished. i learned this after long hours of modeling and not using what i did.

And for the BPM, you need to learn BMP notation and BP analysis, as Business Process is a methodology more than just a notation you will need to learn when to commit and when to add handeler and how to calculate FLOW TIME, Throughput Rate.

By this we ended our conversation , in my next article i would talk aout UML and Scott Ambler ideas of its insufficiency

I'm an Analyst .... i use a Template

After seeing so many templates in different software houses all over the middle east, I though to share some realistic facts from my reading so analysts should wake up.. and lose the template

therefore I'm sharing the following quotes for Scott Ambler , Alistair Cockburn and Martin Fowler regarding what is exactly useful in documents and templates.

I summarized it for you in three separate points:

First , Adrenaline Junkies: He Talks about the book “adrenaline junkies and template zombies “ the junkies are the agilists and the zombies … you know :)

“ModernAnalyst.com: So, you’re saying if I just use a template, it’s not necessarily disciplined, right?

Scott Ambler: Yeah, exactly. There’s actually a really great book out right now, that I do want to suggest to your readers… The book is called “Adrenaline Junkies and Template Zombies.” It’s a collection of patterns and anti-patterns for IT. So, one of the anti-patterns is template zombies; those are people who just fill in templates and making sure it’s filled out. “does this sounds familiar” Whether or not it makes sense, just fill it out. Whether or not it’s even the right template, but I have a template, I’m going to fill it out. It’s just a novel waste of time. A lot of wastage in general…. It’s a really interesting book and one of the really neat things about it … they present these patterns and anti-patterns just as a collection of one or two pages in length. … I suspect it will end up being one of those instant classics that we’ll be referring to 20 years from now.”

Second: In another interview on itc.conversationsnetwork.com

“Based on his recent review of Alistair Cockburn's new book, "Agile Software Development", Ambler said (interestingly): "in this book Alistair tackle about 28 ways of communicating between software project members, and paper/documentation is considered the worst one among them!”

Third: In one of Scott Ambler Book's "Agile modeling:effective practice for eXtreme programming and Unified process " he mentions and i totally agree:

“A common refrain within the object community is that 80% of your object modeling needs can be satisfied with 20% of the notation”

Finally , I want you to check this article if you have time : Varying SDLC methodologies among development teams it will give you an idea why things go bad by using the same process all over again in every project

And my favorite proverb "If you not gonna use it, LOSE IT"

I would like to thanks Essam Badawi from Raya Corp for his support and contribution