Book a Demo

Author Topic: Business Model  (Read 9218 times)

fluxtah

  • EA User
  • **
  • Posts: 144
  • Karma: +0/-0
    • View Profile
Business Model
« on: March 01, 2004, 09:28:15 am »
Hiya, The Case Studies in the books I am following recommend a Business Model before Requirements.. working in the Web Dev industry it is common that a company would start their business by coming to us with an idea, therefore no existing Model is in place... what's the best thing to do in this situation?

Skip the business modeling discipline and move straight on to requirements? or.. ?

Regards

Fluxtah

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Business Model
« Reply #1 on: March 01, 2004, 02:36:31 pm »
To be "traditional" about things....
The business model is a contextual model.  It is produced to ensure that the design team understand the business processes that the system is to support.
The salient issues are coming to terms with the real world constraints that apply to the requirements, often eliminating those "why do it that way" errors.
If the business constraints are understood, eg authorisation policies, need for process controls etc and the business level objects are evident - i.e. all business artifacts are disclosed, then business models may not be "necessary".
In your cited case, where the business processes are not formulated business modelling is more likely to assist than hinder.  You can treat the exercise as a simple business process re-engineering exercise, perhaps using existing client processes as the "as is" model, drafting up a "to be" process involving the web idea and walking through the models to ensure that the client is aware of the differences that the introduction of the system will bring.
By way of a complex example (the only one I can think of at the moment) I was several  years ago involved in the quality assurance of a large integrated stockbroking system.  When we investigated how the system was designed to process diary updates on the various stocks (ex-dividend dates, dividend pay dates etc) something didn't ring true.  I followed up the actual business process with the SME concerned and found that she had not been consulted regarding that functionality, which was implemented using a data feed from the exchange.  We modelled the process and she informed us that it was useless as the data feed notified the broker of the diary event on the day it occurred - not 2 weeks earlier as  needed for the (business) system.  This meant that the entire diary subsystem needed to be redesigned from scratch as the developers had assumed that the automatic feed would take care of all the data entry.  
These are the types of mistakes that can be made if "not enough attrention" is paid to the business process modelling of the system early on.
Personally I advocate the use of the Erikson-Penker UML extension (as supported by the EA profile) which lets us model the objects, events and macro data flows of the business without having to understand the nitty gritty details of the process itself.  That is the process is represented as a single element, no process pathways etc are needed.  Resources and information elements are the key objects and initiation and outcome events can be simply modelled with the analysis diagram Receive and Send pennants.

hth
Bruce
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

mchiuminatto

  • EA User
  • **
  • Posts: 113
  • Karma: +0/-0
    • View Profile
Re: Business Model
« Reply #2 on: March 02, 2004, 04:22:22 am »
Hi.

As sargasso stated a Business model is a valuable artifact for the development team.  

Besides, is a valuable artifact for the areas related with the system operation.  They can take decisions with the business goals in mind and could avoid decisions like  installing the latest service pack when the system is under highest loads, because that means that in 10 minutes the company loose 5 Million and the top client couldn't  connect to the applications and he will not operate with the company anymore, and believe me in a big company things like this happens (here in Chile at least)

The message is that if you believe the Business Model will be necessary, find the arguments, quantitative ones if it possible.

Regards
Regards.

Marcello

fluxtah

  • EA User
  • **
  • Posts: 144
  • Karma: +0/-0
    • View Profile
Re: Business Model
« Reply #3 on: March 02, 2004, 09:26:14 am »
Hiya,

Thanks Sargasso, mchiuminatto.

So, even if a client is unable to describe their own process, or they have not even thought about a process of running their business, it would be best to engineer them one from business Use Case?

The Business Model looks like a great input for requirements and analysis so it is something I would always like to do, what are the best inputs for Business Model? I can imagine some people might get offended if I try to question their existing process?

- Fluxtah
« Last Edit: March 02, 2004, 09:26:59 am by fluxtah »

mchiuminatto

  • EA User
  • **
  • Posts: 113
  • Karma: +0/-0
    • View Profile
Re: Business Model
« Reply #4 on: March 02, 2004, 10:28:19 am »
This is not a transcription from the holly bible but it works for me.

Generally the clients don't know about "business process" they know about goals and the steps needed to achieve those goals (concrete goals and from the business point of view).  So here comes the value of the analyst who has to translate those goals and steps into business use cases.

The analyst needs a little bit of psychology to face this duty. He must show, with facts and numbers if it possible, the value of the business model. For instance you have to tell your client:” The development team needs to understand the business and feel in their blood the business goals. This reduces the probability to take wrong decisions during the development cycle “. Here you should put some examples on the table.

If you find some process that has to be changed, never tell your client: "this process is wrong or inefficient", but you have to tell him:” this process is fine, but what if we add this or cut off that?

Finally. You have to let your client knows that you are the one who knows about software development and the best way to build a software product, and I mean as a software product the software components and the other 50% of the artifacts: the models.  The client is no always right.

It sounds like politician speech? Isn’t it? For more concrete advices you can go to Rational Unified Process.

Regards
Regards.

Marcello

fluxtah

  • EA User
  • **
  • Posts: 144
  • Karma: +0/-0
    • View Profile
Re: Business Model
« Reply #5 on: March 03, 2004, 12:38:15 am »
Cool! That is great advice, thanks mchiuminatto.

I just bought a new book Use Case Modelling on the Object Modelling Series, it explains how to run stakeholder workshops and how they can help enforce the problem domain :]

Regards

Fluxtah

thomaskilian

  • Guest
Re: Business Model
« Reply #6 on: March 09, 2004, 06:58:17 am »
Just another advice: Try more than one book ;D and don't take a single one as holy bible (cite from above). Business Process Modelling is something that can be done with UML in many ways. There are different tools that do the job even better (I worked with ARIS for example).  However, I like to have a single language to talk to my customer and to the development team - and that is why I prefer UML.

Thomas