Author Topic: "CRUD"ing in Use Cases  (Read 3176 times)

TrtnJohn

  • EA User
  • **
  • Posts: 176
  • Karma: +0/-0
    • View Profile
Re: "CRUD"ing in Use Cases
« Reply #30 on: May 25, 2006, 10:26:50 am »
Quote
Harrumph!  An architect is still on the development side and still needs a technical mind set to function well.  Architects are use case readers, not use case writers.  An architect's strength still lies with deep technical knowledge of an even broader range of technologies.  A business analyst has a management mind set and credentials to earn the respect of other managers.  In my experience, a business-focused architect is an oxymoron.  If I found one, I suspect it would be someone trying to live in both worlds and not doing well in either.  There are, however, some exceptions to be found in this forum   ;)

The best practice for developing a management mind-set is to "walk the walk" not just "talk the talk", nor "read the book".  To become a Business Analyst, become a manager with profit making responsibilities.  Give up that security blanket of deep technical IT knowledge and commit to learning deeply what a manager desperately needs in order to be successful.  It only takes a few weeks, of being in fear of losing one's job because you can't get the past-due shipments out the door, to make the mind-set switch. ;D

Management skills are completely different from IT developer skills.  Read management books written by leading managers, not ones written by leading technical gurus.  Read
  • Porter on Strategy
  • Mintzberg on Organizational Structure
  • Eli Rat's The Goal
  • Books and Reviews from the Haavad Business School
  • Textbooks used in your local college's MBA degree program
  • just to name a few...
Ask your management for a three month transfer to a line management position as part of your training to become an business analyst;  they'll think that a smart thing to do if they support your career goals.  In its heyday, the Pennsylvania Rail Road required its software developers to be railroaders first and developers second, not the other way around.  If you are in a large corporation, check out their managent trainee program; see if you can get into it.

Well anyhow, that's how I did it.  I now yield my soap-box to other pontificators. ;)  


Can I work where you do?????

I wish we had BAs that had a clue.  But, every company I end up at usually only have a marketing department that can support trade shows and functions.  Another reality of business is many organizations are ad-hoc and you end up wearing many hats.  Technical people are left to analyze business requirements and line managers try and make technical decisions.  (Usually creating a mess in the process).  Your post is right on the money but does not reflect reality in small to mid sized companies.  (In my experience).    In those environments much of the use case analysis is left to the technical team.  Who, typically over-engineer and miss the true business requirements.  Us poor souls stuck in this mess can learn alot from a true BA as yourself.  Thanks for the insight and references!!

John

mhdhallak

  • EA User
  • **
  • Posts: 43
  • Karma: +0/-0
    • View Profile
Re: "CRUD"ing in Use Cases
« Reply #31 on: May 25, 2006, 03:30:46 pm »
Quote

Can I work where you do?????

I wish we had BAs that had a clue.  But, every company I end up at usually only have a marketing department that can support trade shows and functions.  Another reality of business is many organizations are ad-hoc and you end up wearing many hats.  Technical people are left to analyze business requirements and line managers try and make technical decisions.  (Usually creating a mess in the process).  Your post is right on the money but does not reflect reality in small to mid sized companies.  (In my experience).    In those environments much of the use case analysis is left to the technical team.  Who, typically over-engineer and miss the true business requirements.  Us poor souls stuck in this mess can learn alot from a true BA as yourself.  Thanks for the insight and references!!

John


Good point, John. I was gonna say that but I refrained coz I was afraid I wasn't gonna speak for the public masses. Anyhow, I think ya'll will like it when I tell ya that this project i'm in, no else's on it. Yep baby, I'm doin everythin from business analysis down to development and deployment. Isn't that just a treat! I've been with this company for 3 months now, they're understaffed and they're supposedly working on this issue.

Anywho, I think they're pretty much aware (I made it clear) the enormous risks associated with this resource allocation technique, but they're willing to accept that for the sake of moving multiple projects in parallel.
Thanks

AL

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: "CRUD"ing in Use Cases
« Reply #32 on: May 25, 2006, 05:37:26 pm »
John & mhdhallak;

You both make good points.  I admit that most of my BA work has either been inside multi-billion dollar corporations or with $30 million dollar divisions of such corporations; both as an employee and as an external consultant.

However, in the situations you describe, I would suggest that such companies can ill afford to take the risks associated with doing the job incorrectly.  If you don't get it right the first time, in the long run you'll get bogged down fixing the installed applications at the expense of developing new capabilities.  At that point, you become a maintenance programmer who can't "seem to get it right" or "can't seem to make any progress" and stop being a multi-hatted guru.

Your management probably does not understand the value of CIM & PIM modeling and are pushing you for evidence of progress that they can understand--stuff running on the computer.  I would suggest the following tactics:
  • Adopt an iterative development strategy (take a look at RUP)
  • Shrink the domain of your development project to something that can be delivered in 2 - 6 Weeks.  Then follow on with more projects of the same size. That way the stakeholders will see progress they understand.
  • On each iteration, go through a the CIM ->PIM->PSM->PM process on the small domain of discourse
  • As most systems require a substantial database of information, deliver (early on) CRUD level use cases that the stakeholders may use to start priming the data pump.  That will keep them happy for a while because it is they who are in the critical path now.  
  • Encourage stakeholders to make sure the database is complete and accurate.  That will focus them on what they are putting into the database and what they might want to do with it.  Encourage those types of discussions at lunch with them.
  • Plan on developing extension use cases to enrich the capability of the use cases implemented so far.
  • Avoid the trap of using a functional break-down process to find objects;  such object are not very reusable.  Develop each object as faithful to the OO paridgm as possible to maximize its reuse in later iterations.  Ask not what they do, but what they do it to.  The better you are at this, the faster your latter iterations will be accomplished.
  • Have fun!

Hope this helps...
Verbal Use Cases aren't worth the paper they are written upon.

TrtnJohn

  • EA User
  • **
  • Posts: 176
  • Karma: +0/-0
    • View Profile
Re: "CRUD"ing in Use Cases
« Reply #33 on: May 31, 2006, 12:59:24 pm »
Jim,

Thanks for all the input.  I hear exactly what you are saying and agree 100%.  But, in my current company’s case, there is no consistency in anything.  In reality the problems are even deeper than you realize.    Fixing these problems, just as in development, must also be implemented iteratively.   If I came to some of our management with your post and insisted on such things in all cases they'd run me out of here with torches and pitchforks.  It's going to require baby steps to climb out of our current ad-hoc process.  Ironically enough, all my complaining at my current company has netted me the privilege of being promoted into marketing as what they call a Product Manager.  I will take this opportunity to try and evangelize and enact some change.  (AKA The Big Flame Out).   I've only been in my new position for a month and it has gone surprisingly well.  Upper management is disturbed by many of the symptoms you described and I have been the only one to present any kind of case on why things are the way they are.  I completely realize that any one of the principles of the company could easily torpedo this whole effort.  But, IMO it is the right fight to fight.

PS.  I must be a bit demented as I do enjoy these types of challenges...
« Last Edit: May 31, 2006, 12:59:57 pm by TrtnJohn »

jeshaw2

  • EA User
  • **
  • Posts: 701
  • Karma: +0/-0
  • I'm a Singleton, what pattern are you?
    • View Profile
Re: "CRUD"ing in Use Cases
« Reply #34 on: May 31, 2006, 09:46:55 pm »
I shall hold you in my prayers...for awhile  ;D
Verbal Use Cases aren't worth the paper they are written upon.

TrtnJohn

  • EA User
  • **
  • Posts: 176
  • Karma: +0/-0
    • View Profile
Re: "CRUD"ing in Use Cases
« Reply #35 on: June 01, 2006, 01:43:54 pm »
Quote
I shall hold you in my prayers...for awhile  ;D


Thanks!

Maybe we ought to be placing bets on how long it will take me before I start begging for my development job back?