Business modeling

[birdy]

Hi

Ive got another question)). Its about BA and use cases.  

I will try reflect on it and you, please, tell we me where i'm wrong.

As far as i know (maybe its not right) use cases show the interaction of Actors with the System and
so they are pretty far form business. Use case diagram doesnt show directly the flow of the procces but just the
moments or situations when the user 1)comes (pre-cond) 2) do smth (scenario) and 3) go away (post-cond).

Thus we need know this situations and for that we are modeling a Business Process.

The first question is - what kind of diagrams we use? (in UML)
If we use Use Case diagram, then i don't understand anything)), because we didnt like it a moment before.
and If we use Activity diagram, then it would be interesting what is the result of BA.

there's another question - what model do i build:



1) a pure model of bisuness (that doesnt know about the System im going to develop)
 
or

2) a dream of how the business will work with the assumed System (im going to build)

??


I'll be very glad, if you comment my thougts.

birdy      

[«Midnight»]

Hi Birdy,

I'm not going to try to answer your questions in detail; the gurus on this forum will be able to point you towards some pretty good ideas. What I will try to do is get you 'unstuck' so you can get back to thinking along more productive (read "billable") lines in the meantime.

In no particular order:

• In either development or BA, you need to have some kind of boundary (real world, not UML) which delineates what you are working on. Simply put, this is your Scope. [A formal definition would be along the lines of "That which your users and clients will cause to explode after you have signed off on the final cost estimate."]
  
  • It is often difficult to clearly delineate exactly where the limits of your scope are; try to find the first point where you should be answering questions like "What does this whole thing accomplish?" or "Who actually benefits from doing this?."
    
  • At a very high level, the use cases help you understand and illustrate this boundary. At this level an Actor is (just) outside your scope. It is the role (person, group, system, process, or whatever) that interacts with your system, but is otherwise indepent from it. [Some practitioners and methodologies recognize Business Actors and Secondary Actors to explore variations on this theme. Take a look when the time is right.]
    
  • On the other side of the boundary is what your business process area (for BA) or system (for development) does in response or on behalf of the Actor. That's the oval part of the Use Case, where you will (perhaps later) elaborate the scenarios. You'll drill down into various other diagrams etc. as you proceed with your analysis.
  
  
• As you get to these lower levels you will be creating Activity diagrams and such, perhaps in related modelling paradigms like BPMN.
  • Note that in many instances, the "levels" of analysis may occur (at least partially) in parallel, and are often iterative. Some methodologies (e.g. UP) formally realize this. Do what's right for you. [How you determine this is left to the reader as an exercise...]
  
  
• As far as whether to model the "pure" business goes, you have to consider whether it is worth doing.
  
  • You will rarely have the time and resources to do this across the board, but sometimes it can be worth doing (at least for part of your scope) to gain an understanding of what you are really talking about. This is most likely something that's entirely new to your organization. Once you have got a firm grasp of what's really involved, it is usually time to get back to solving the real problem.
    
  • If you are creating a model of a business domain that you will reuse (perhaps for different clients, or several divisions of a single client) it may be worth doing a "pure" model as a basis for tailoring.
    
  • Look into the concepts of MDA (check out the OMG stuff on this and read this forum). These concepts have been used quite successfully in BA as well as development. The idea of transformation is quite relevent here.
    
  • Finally, if your problem scope is well defined and clearly understood, you will probably want to get on with solving the problem at hand. You can always create models specific to your particular business situation now. Once the problem is well on the way to solution, you can discuss the business case for developing a generic "pure" model of the system, given the incremental cost of rework (which you may now be able to estimate) versus the potential for additional return (which you may now be able to advocate). If the immediate problem gets solved before you embark on this additional exercise, then your business may be more willing to 'share' the benefits of the solution to offset the cost of refining the model.
  
  

I hope this gives you someplace to start untangling all this. Look at what the gurus say when they get on-line, and check the other threads and resources they point to; these will help you with the details.

Also remember, there is no 'right' way to work with UML. Make it work for you, rather than you working for it.

HTH,
David

[birdy]

Hi David!

Thank you for the interesting answer. Now I'm thinking it over and trying to apply it to my scope)).

While i was reading your post i had the idea how to explain my problem more concrete.

Use case diagram DOESNT show the FLOW of EVENTs (not UML, just what's happening). Is it right?

And So I'm afraid to FORGET smth, because there is almost no STRUCTURE (i mean behaviour structre). Or am i wrong again?

Hence i need to pick out the processes and to realize them with a bunch of use cases.

processes relates with BA
use case relates with System developing

so what is a line when i'm done with the Modeling Business and go to build Use Cases?

birdy

[StefanPears]

Birdy,
if you have described your business with event driven process chains, you will have no real need for use cases. However, you have to think about the mapping from BPM to UML, e.g. one BPM process (EA: activity) gives one activity diagram.
Stefan
(I apogize I did a lot of BPM with ARIS from Ids-Scheer but I havn't tried it with EA by now)

[«Midnight»]

Hi again Birdy,

Steve is on the right track here. You do have the correct pieces, but need to tweak their relationships a bit. To address your own words:

You describe the overall picture with your use cases. At the higher levels (just the pictures) you supply the reader with a catalog of what you will be addressing. At the scenario level you cover how people will go about using the system (or applying the processes) you are modelling from the users' point of view. This covers your "need to pick out the processes."

Cover the main points here, and then (or even concurrently, as long as you can clearly delineate what you are talking about in each case) begin to drill down to lower levels before you "FORGET smth." At these lower levels you will provide the "STRUCTURE (i mean behaviour structre)."

The activity diagrams (and other artefacts) are the "bunch" you use "to realize them with."

Better?

[Kevin Brennan]

Birdy,

The answers upthread are good ones. It sounds to me like you may be missing some critical info on use cases.

The UML Use Case Model is not really good for much more than delinating, at a high level, the scope of the system. It describes a) who the actors are that are going to use our system and b) very roughly what they intend to use it to do.

In order to understand how the actor achieves their goals through the use case, you need to actually write the use case description in textual form. Alistair Cockburn's, or Kurt Bitter and Ian Spence's books are good places to start on this. Without the textual documentation the use case model has little value.

Steve,

I don't think that BPM chains are sufficient to cover all the requirements in most systems. Users have goals that affect multiple processes at once and these cross-cutting concerns need to be modeled. I agree, though, that a process model and use cases may be redundant in many scenarios.

I'm currently working on a BPM application, and we tend to use a process model for the work that users do and use case descriptions to define the UI, user interaction with tasks, etc.

[jeshaw2]

Through all of the comments in this thread, I'm detecting a perspective that Use Cases define how users might want to use the system to accomplish some (business?) goal.  I'm uncomfortable with using that perspective as a BA starting point; my approach is a bit different.

The BA's role of analysis is at the CIM (Computationally Independent Model) level of abstraction; therefore there is no automated system to be used, and, depending upon what is discovered, there might not be one either.  The BA is analyzing a business, not a relationship between a worker bee and some automated system.  Therefore...

I develop Business Usage Cases (forgive my taking literary license here).  At the top level Use Case, I describe how external actors use the business.  For example, how does the car dealer use General Motors, and how about Banks, Government, automotive scrap dealers, stock holders, etc.  At a lower level, lets consider the Purchasing Department for example, how does the rest of the business use the Purchasing object(s)? What behaviors does the purchasing object exhibit? These actors are the source of events that initiate and drive the business processes thru the business objects.

I look for Business Objects (Sales Orders, Purchase Orders, Shop Orders, Finished parts, Products, employees, cash registers, surgical theaters, etc.) and study who does what to them (either manually or automated).  From this, I form Business Useage Cases--how the objects of the business, and the things that are done to them, are used to achieve business stakeholder's goals.  At the CIM level, it matters not how actors do the things they to to business object,  What's important is to capture what they do to them.  And that, my friends, is my perspective on Business use cases.

After discussion with stakeholders about their business usage cases, then one might begin developing use cases at the PIM level, which is where I perceive the current discussion is at.  But PIM level use cases are at the Software Engineering level, not at the BA level of abstraction.  

To define the project scope for the PIM level, subsets of the business usage cases and the business objects are used.  These are carried forward into the PIM.

I know IT folks sometimes execute both roles, the BA and SE, that that doesn't mean that a Business Use  case should look like a System Use Case.  If one who wears both hats tries to go directly to the PIM level, it will be like a programmer to rushes to code too soon--instead of writing good code, he write bugs that need fixing later.

[Paolo F Cantoni]

Just a short observation on this thread...

As someone who regularly practises on all three sides of the fence   (BA, SE, User)...

I echo Jim's standpoint on this.  I have found it most beneficial to ensure the domain is understood as much as is needed BEFORE plunging into systemic stuff.

(As I have said elsewhere... "Automating a business that makes sense is actually relatively easy.  Automating one that doesn't is impossible!")

Paolo

[StefanPears]

Well, I like to describe what we have and what we are going to do with event driven process chains. These diagrams are special views on the organisation. The events are those from reality, e.g. "customer is on the phone", "order has arrived". Something is done (function or process, e.g. make 3 copies at the copier) by someone (org.-unit) with the use of something (paper, book, GUI, DB-table) and this produces one or more results, which are ingoing events for the following functions or processes.

Based on this we will have a better knowledge of what is done, who (person or software) is doing that, who is responsible for that and, most important, we are hopefully sure that we have no gaps or conflicts in our work flow.

Now we can decide, where the organization has to be changed and where software has to be developed. Next project phase starts, maybe again with EPCs or maybe with Usecases/Activities/UML (not to forget functional and non functional requirements).

This description is rough and short and if it should sound easy, well, it isn't. There are some ideas and design rules about events and processes that fill books.

Stefan

[birdy]

Hi everybody!!

Thank you for yours answers. I'd like make a kind of a short summary (just a couple of thoughts).

First, i want to say, that i realize what is use case (i'm reading Co-burn's book) and i see that it is a text, that can be modeled by some behaviour diagram (e.g. activity or sequence). So you say, the process is INSIDE the use case. I do agree with that. But. I thought there is the also a big OUTSIDE process that contains use cases.
(because one use case is pretty concrete - it includes some kind of atomic actions)

From your words i can understand, that it is not completely right)), and use case diagram discribes that
"big  process" with out assistance of any other diagrams...

I'll try to do this way.

thank you.

birdy

[Kevin Brennan]

None of the things I wrote above should be interpreted as disagreeing with Jim.  

Birdy, it might help if you look at the levels of use cases Cockburn mentions. From the business level, the actor in the use case is likely to be a customer, and the goal is to get some service from the business.

Those use cases might also be modelled as a process chain. In RUP (and EA) they're called Business Use Cases.

Once you have that modelled, then you can look at people within the business. They should have sub-goals that help them accomplish portions of that overall process for which they are responsible. You have to get down to this level before you can really start thinking about which portions of the process need to be implemented in a system.

The key to understanding all of this is the actor-goal model. Who are your actors, and what goals are you trying to help them satisfy?

[jeshaw2]

I never thought we were in disagreement Kevin.  

[datasmith]

How can I represent hierarchical definitions of processes, so that if I click on a process element, I am taken to an exploded definition of that process.

The exploded definition of that process will include all sub-processes, etc.

[Kevin Brennan]

BPMN or Activity Diagrams will do that for you in EA.

[jeshaw2]

Not sure which of two questions you're asking...

Are you interested in setting a hyper-link in EA to get from one diagram element to another diagram; or,
are you asking a UML question on how to diagram Summary processes in relation to user level processes and/or from user level to sub-function level (in which case you might use the generalization relation arrow)?