introduction to business modeling

Introduction To Business Modeling

1

IntroductionTo

BusinessModeling


2

Software is not only source code

plus technical architecture …


3

It is every artifact that leads to a useable system


4

Requirements Artifacts are

therefore part of the software


5

All intellectual property that gives

rise to a system should fall within the

definition of “software”


6

UX is also a core part of the software

but UX is outside the scope of this

presentation


7

However it is worth noting that to a user the interface is the

system


8

Successful software

companies value UX above all else


9

For now we focus on artifacts


10

SpecificallyBusiness Models


11

Organizations: BPMN.org. Object Management Group. IEEE.orgBooks: Agile Modeling – Ambler. UML – Podeswa. BPMN 2.0 Handbook – Shapiro et al.

Sources

And there are many, many, more …


12

UML (Unified Modeling Language) and BPMN (Business Process Modeling Notation) are just two examples of modeling languages. There are others. Many others.

UML is possibly the best known and most widely used modeling language.

UML emerged from parallel efforts by Rumbaugh, Jacobson, and Booch.http://www.cs.cofc.edu/~bowring/classes/csci%2520360/presentations/History%2520of%2520UML.ppt

Two trends are evident in current discussions about modeling language standards:

> A move towards further unification – e.g. unify UML and BPMN.

> A move towards further specialization – e.g. Domain Specific Languages (DSL’s). DSL’s may be created as extensions or subsets of existing languages such as UML or XML.

> One possible outcome is unification of general languages such as UML & BPMN on a common standard, and growth of DSL’s which are standard-compliant, so information captured in DSL’s can enrich models at the higher level.

> Requirements Interchange Format (RIF/ReqIF) is an XML extension that may be regarded as a DSL. It is still a work in progress but is supported by the Object Management Group.http://www.omg.org/spec/ReqIF/

Languages

http://www.cs.cofc.edu/~bowring/classes/csci%20360/presentations/History%20of%20UML.ppt

http://www.cs.cofc.edu/~bowring/classes/csci%20360/presentations/History%20of%20UML.ppt

http://www.omg.org/spec/ReqIF/


13

Meta Language:

> You may hear modeling languages such as UML referred to as ‘meta languages’.

> A meta language is a ‘language about a language’ – an abstracted form of ideas captured in some base language/natural language.

> In theory you could even have a meta-meta-language, i.e. a language about meta languages. The example sometimes mentioned in this regard is Object Constraint Language (OCL) http://en.wikipedia.org/wiki/Object_Constraint_Language.

You should feel free to ignore abstract philosophical discussions about meta languages. If/when these discussions produce useful results, we can have a look at those.

Next we will look at some general ideas about modeling, then drill down to the specifics of Business Modeling, and finally look at how these are being applied here at Campus Management.

Meta Languages

http://en.wikipedia.org/wiki/Object_Constraint_Language


14

Models …What we model

What Models can tell us


15

Which model of North America is correct?


16

SometimesOne modelIs simply

wrong


17


18

More typicallyWe need more than

one model to getA complete picture


19

Plan.


20

Elevation.


21

Result.


22

The same applies when modeling

business processes AND Business requirements


23

This presentation focuses on two

models


24

The Domain ModelAnd

The Requirements Model


25

Domain Model

Requirements

Model


26

à In agile software development, a domain model describes the application domain responsible for creating a shared language between business and IT. (http://searchsoftwarequality.techtarget.com/definition/domain-model.)

à The domain model is one of the central artifacts in the project development approach called Feature Driven Development (FDD). (http://www.reference.com/browse/domain+model.)

http://practicalanalyst.com/a-requirements-model-graphic/

à Requirements Model: the sum of approved artifacts for capturing requirements – e.g. Use Case + Functional Requirements.

http://searchsoftwarequality.techtarget.com/definition/domain-model

http://searchsoftwarequality.techtarget.com/definition/domain-model

http://www.reference.com/browse/domain+model

http://www.reference.com/browse/domain+model




27

Some uses of theDomain Model


28

class Artifact Meta Model

Feature Model

Functional Model

Domain Model

ERD Model

BPM Model

Activ ity

Domain

1..*

Aggregation1..*

Association

1..*

Aggregation 1..*

Association

Aggregation

1..*1..*

1..*Association1..*

1..*

Aggregation

Aggregation

The Domain Model is the totality of models such as Feature Model, Functional Model, ERD, BPM. It may also include a State Model (not shown here.) Functional Model is not a widely recognized or standardized artifact but can prove useful. (May also be referred to as a Functional Decomposition.)


29


Feature Model

Functional Model

Domain Model

ERD Model

BPM Model

Activ ity

Domain

1..*

Aggregation1..*

Association

1..*

Aggregation 1..*

Association

Aggregation

1..*1..*

1..*Association1..*

1..*

Aggregation

Aggregation

We will look at each of the models in more detail.

First, the Feature Model.


30


Feature Model

Functional Model

Domain Model

ERD Model

BPM Model

Activ ity

Domain

1..*

Aggregation1..*

Association

1..*

Aggregation 1..*

Association

Aggregation

1..*1..*

1..*Association1..*

1..*

Aggregation

Aggregation

Feature Model


31


Feature Model

Functional Model

Domain Model

ERD Model

BPM Model

Activ ity

Domain

1..*

Aggregation1..*

Association

1..*

Aggregation 1..*

Association

Aggregation

1..*1..*

1..*Association1..*

1..*

Aggregation

Aggregation

Next, the Functional Model.


32


Feature Model

Functional Model

Domain Model

ERD Model

BPM Model

Activ ity

Domain

1..*

Aggregation1..*

Association

1..*

Aggregation 1..*

Association

Aggregation

1..*1..*

1..*Association1..*

1..*

Aggregation

Aggregation

Functional Model


33


Feature Model

Functional Model

Domain Model

ERD Model

BPM Model

Activ ity

Domain

1..*

Aggregation1..*

Association

1..*

Aggregation 1..*

Association

Aggregation

1..*1..*

1..*Association1..*

1..*

Aggregation

Aggregation

Next, the ERD Model.


34


Feature Model

Functional Model

Domain Model

ERD Model

BPM Model

Activ ity

Domain

1..*

Aggregation1..*

Association

1..*

Aggregation 1..*

Association

Aggregation

1..*1..*

1..*Association1..*

1..*

Aggregation

Aggregation

ERD Model


35


Feature Model

Functional Model

Domain Model

ERD Model

BPM Model

Activ ity

Domain

1..*

Aggregation1..*

Association

1..*

Aggregation 1..*

Association

Aggregation

1..*1..*

1..*Association1..*

1..*

Aggregation

Aggregation

Next, the BPM Model.


36


Feature Model

Functional Model

Domain Model

ERD Model

BPM Model

Activ ity

Domain

1..*

Aggregation1..*

Association

1..*

Aggregation 1..*

Association

Aggregation

1..*1..*

1..*Association1..*

1..*

Aggregation

Aggregation

Business Process ModelBPM


37

BPM is multi layered class Artifact Meta Model

Feature Model

Functional Model

Domain Model

ERD Model

BPM Model

Activ ity

Domain

1..*

Aggregation1..*

Association

1..*

Aggregation 1..*

Association

Aggregation

1..*1..*

1..*Association1..*

1..*

Aggregation

Aggregation

‘Configure Campus’ decomposes to activities


38


Feature Model

Functional Model

Domain Model

ERD Model

BPM Model

Activ ity

Domain

1..*

Aggregation1..*

Association

1..*

Aggregation 1..*

Association

Aggregation

1..*1..*

1..*Association1..*

1..*

Aggregation

AggregationThe individual Activity may serve as a link from the domain mode to the Requirements Model


39

An activity from BPM will map to one or more use cases in the Requirements Model


40

This can enable navigation from the lowest level artifact all the way to the highest

For example you can start with a change to single requirement and find which business

processes and entities may be impactedFor now we focus on questions that may be

answered within the domain modelThe same principles apply within the

Requirements Model


41

We can query EA to find out:à Feature-N depends on Functional Nodes A, B, C.à Functional Node A depends on Architectural Components X, Y, and Z.

This will help us capture everything in-scope to roll out a given feature, and enables automated impact analysis. If the mapping between product, feature set and feature ever needs to change, that can be done in the Feature Model without disturbing the

other models. If we have a future need to carve out subsets of a product or ecosystem as new products in their own right, again the Feature Model makes this

straightforward.


42

The Domain Model may be extended … allowing us to answer more questions in an automated fashion … Quantified and repeatable

Feature Model

Functional ModelArchitectural Model


43

This is just a foretaste of what may be done using formalized business

modeling languages such as UML and BPMN

Many of the questions that used to rely on gut feel and historical data may be

answered more rigorously using models


44

You could eventually reach the point where the models can answer questions such as …

“How many customers would be affected?”“Would this require a change to a business rule?”“Would this require a change to a database table?”“Which Service Level Agreements would be affected?” “What is the level of effort?”


45

This concludes the main presentation

There are a couple of Appendices to note …


46

Appendix A: Three extensibility Mechanisms for UML.

à Stereotypes.à Tagged Values.à Constraints.à See for example http://umlguide2.uw.hu/ch02lev1sec2.html.

class Feature Model

«#Product»ProductSet

tags#FSD = 1

Stereotype

Tagged Value

http://umlguide2.uw.hu/ch02lev1sec2.html




47

Appendix B: Graphic illustrating Domain Model – Requirements Model linkage.


48

Appendix C: Cheat Sheet on Domain Modeling.


49

Appendix D: Cheat Sheet on Business Process Modeling using EA.


50

End

introduction to business modeling

Documents