Главная » Периодические издания » Business model defining

1 2 3 4 ... 27

business model defining

Ideally, the objects presented in the business models translate or map to objects in the information system. Normally, this is not a one-to-one mapping. One object or process in the business model cannot always be translated into one object in the information system, since there are objects in the information system that are not present at all in the business model, and vice versa. This makes a direct mapping between the real world as described by the business model and the software system impossible. Nevertheless, even if a one-to-one mapping between the business model and the analysis model of the information system is not possible, the way the business operates and the functionality and design of the information system used to support it are more tightly integrated. Why? Because an information system that is built to support the requirements of a process will offer the appropriate services. Using object-oriented techniques, the modeling concepts and the structures used in the business model can be the same as those used in the






analysis models for the information systems. Furthermore, the information system can be implemented using the very same concepts. This book shows you how.

Using business models as a basis for the information systems also presents the opportunity for software reuse. If there are several information systems that support the same business, they often will have an overlapping set of objects. For example, several information systems that act within the same process can use the same objects from the business model. These objects have to be implemented only once and can be reused in other information systems. Often, the objects in a business model participate in several processes, and the information systems supporting different processes then can reuse reoccurring objects. It is difficult to succeed with this kind of reuse if the system has been developed with only one software system in mind. The objects become too attached technically to a particular system; they have not been generically modeled after the requirements of the business.

The advantage of reuse also applies to models. If the same business model can act as the basis for several information systems, it can be reused as the basic input for defining the requirements of each system. Without a common business model, each system development team creates its own analysis model to understand the real world. Not only is this redundant work, but this heightens the risk that the different teams will interpret reality differently and thus develop incompatible systems. The trend for reuse within system development is leaning more toward high-level reuse through architectural frameworks or patterns, instead of simple reuse of code (which hasnt lived up to its promise). Reusing business models is another step in that direction. In addition to new information systems, most businesses already have a number of information systems known as legacy systems that are expensive and hard to replace. These systems are functional parts of the business; they actually become a part of the current business model. In many cases, the legacy systems are the parts of the business that are most likely to be the target of an improvement or innovation plan (e.g., to substitute or remove some of these old systems).

There are two ways to depict a legacy system in the business model: it may be modeled as a single entity, such as a person acting in the business, or it may be reverse-engineered. Reverse engineering means that a model is created by analyzing the current information system; that is, modeling an already completed system (which is opposite from what normally is advocated). Reverse engineering breaks down the current system in order to discover the set of information objects present in the system. These information objects then become part of the business model. These two techniques are discussed in more detail in Chapter 10, From a Business Architecture to a Software Architecture.

Improvement

A business model can be used to improve the current business. This technique, sometimes called business process improvement (BPI), is used to identify possible ways to make the business more efficient. The current business is modeled and then analyzed for opportunities for enhancement or improvement. The improvement part of BPI suggests that the business is changed incrementally (i.e., step-by-step improvements; see Figure 1.3) rather than through immediate and radical means. When an opportunity for improvement is identified, a new business model is produced to demonstrate how the business should look after those changes are implemented.

\S -1ЫГЮИ Modal-ftw

тяти w> Sup z

Figure 1.3: Business improvement means that changes are done incrementally.

A number of activities must be completed in order to change the business and implement the new business model:

Describe new routines and create administrative support for these routines.



Train the people affected by the changes; teach them the new processes and motivate them to become a part of the changes.

Change the information systems that participate in the business to better support and enhance the operation of the business.

Negotiate with subcontractors and other partners who will need to adapt to the changes.

Depending on the extent of the changes, improving the business can be simple or complex work. Changes occur in small steps, but they can be implemented continuously, acting upon changes in the business environment, such as changed customer needs (i.e., whenever a customer need is changed, an incremental step is performed to meet and handle that change in the business).

Innovation

Business innovation involves analyzing the current business and searching the model for new ways of doing things. The business model and its processes are changed significantly to create different and improved processes (see Figure 1.4). Often, routines in a business exist because of historical reasons (it always has been done that way) or because the infrastructure demands them to be done a certain way (the documents or the information systems dont allow them to be made in any other way).


Figure 1.4: Innovation implies making radical changes to the processes.

Innovation places even higher demands on correct implementation than business improvement. Motivating and instructing the people involved and ensuring that the new processes are integrated in the existing business are essential for success. To be sure, innovation is a much bigger risk than improvement, but if innovation succeeds, the resulting business can achieve much larger gains in efficiency. Innovation is therefore typically used in companies that require radical change prompted by poor performance, missed budgets, and inefficient productivity.

An extreme form of business innovation is business process reengineering (BPR). BPR advocates radical changes to the business processes; this means that everything about the current way of running the business is questioned and, subsequently, often substantially changed. BPR strives to achieve dramatic improvements in efficiency in the order of several hundred percentage points, in comparison with process improvement or traditional rationalization where changes of 5 to 10 percent are deemed satisfactory.

Succeeding with such innovation is much more difficult and bears a higher risk of failure. Consequently, there has been strong resistance to BPR. Many BPR projects have failed because those involved in the business or the environment objected to the radical changes and therefore did not actively or wholeheartedly participate in implementing the new business models. Failures are also caused by incorrect design of the business process; they simply dont work when implemented.

Information systems are the key enablers to achieving process innovation or BPR. The introduction of new information systems is not, however, a guarantee for innovation. More commonly, new information systems are designed according to a current, inefficient business model, which effectively cements the current way of doing things, and makes innovation impossible to achieve. True innovation takes place first in the minds of the modelers, before it can be described and achieved in a business model. Only then can new information systems be built, either as a central and required part of that new business model or simply as a support for it.



Debate continues in the management world over whether improvement or innovation should be used when making changes to the business processes. We will not choose sides in this debate; instead, we point out that the business modeling techniques described in this book can be used for either purpose.

Design New Processes

Business modeling can be used to create new models, not previously part of the business, in order to experiment with how new business concepts fit into the current model. Models are used to determine if the current organization, resources, and information systems can be easily used in or adapted to the new process. Business models also are used to benchmark a business, that is, to copy or study business processes used by competitors in order to measure ones own business against the competition.

Often, new processes are designed based on a vision of new opportunities. Modeling this vision or idea creates a first try that tests the feasibility of the process. Obviously, other activities have to be performed before implementing the process, including profit calculations, cost analysis, and market studies. These activities can use the new process model as a specification of the projected goals for the new process and of the necessary resources, and to determine how the new process is implemented within the current business.

New opportunities stem from finding new combinations of or additions to objects that are already present in the organization. For example, a business can identify new ways to use customer information that it already possesses, or new services to add to the products that the business sells. By visualizing the processes in models, it is easier to see the strengths and weaknesses of the business and how to use the strengths and eliminate the weaknesses in order to turn opportunities into successes.

Outsourcing

A common practice among business leaders today is to focus on the core business, fundamental processes at which the company excels and that give them the competitive edge. Processes that are not part of the core business are good candidates for outsourcing. The companies hire subcontractors to handle support functions or even entire departments, rather than managing them themselves. Information systems are not the only candidates for outsourcing; other parts of the business that arent considered vital, such as marketing or maintenance, may be sent out as well.

Business modeling can be used not only to identify and define the core processes, but also to define the processes that are candidates for outsourcing. The model then acts as a resource for the supplier and becomes a valid specification for how these processes should be performed and integrated with the core processes. The business model acts as a map that integrates the processes with each other, indicating where the processes are run by different companies and subcontractors.

Business Modeling with UML

Why use object-oriented modeling techniques to describe a business? Isnt object-oriented modeling and programming restricted to analyzing and designing computer programs? The answer is there are several advantages to using object-oriented concepts and techniques to model a business:

Similar concepts. A business can be described in terms of processes that achieve goals by collaborating with different types of resource objects. Rules define conditions and constraints as to how the processes and resources may relate to each other and how they may behave. All of this can be mapped onto objects, relationships between objects, and interaction between objects; for example, through creating static and dynamic object-oriented models.



Well-proven established techniques. Object-oriented modeling and programming has been used for several years now and has proven that it can handle large and complex systems. New techniques, such as patterns, have been introduced in the field of object-oriented modeling, and a number of patterns are available for modeling businesses. Standard notation. Business modeling methods and techniques are in need of a standard notation: every method uses its own notation and its own tool, if notation is used at all. Object-oriented modeling finally has a standard notation: UML. That means the tools are already there, and that the same tools that are used to model the information systems can be adapted and used to describe the business models. It also opens up the possibility of enabling continuous traceability of business requirements all the way to the implementation code. The absence of this capability is a major weakness in most tools today.

Short learning curve. It is a major advantage when the same basic concepts (objects, classes, etc.) used to describe the information systems that support the business can also be used to describe the business as a whole. Just as object-oriented models have decreased the semantic gap between those who analyze and design systems and those who program them; using object-oriented techniques and notation will decrease the gap between the business modelers and information systems modelers and architects (assuming both have prior knowledge of object orientation).

New and easier ways to view an organization or a business. The traditional way of describing and viewing an organization doesnt show much of how the business is performed. The functional division of a business into organizational charts cant be used to describe modern business processes that are horizontal to the organization and affect many functions within the business. Object-oriented techniques can easily show these processes, as well as the traditional organizational structure.

There are, of course, a number of other ways to create business models, including using other notations such as IDEF0; it is also possible to simply use textual descriptions of the processes. But UML is a well-defined standard, supported by many tools. It is the dominant modeling language used to model object-oriented information systems.

Summary

The purpose of business modeling is to generate descriptions (abstractions) of a complex reality that capture the core functions of the business. The models show agreed-upon fundamentals, and can serve as a point of discussion. There are many motives for business modeling: to better understand the key mechanisms of a business, to act as the basis for supporting information systems, to improve the business, to radically change the business, to identify new business opportunities, and to identify outsourcing opportunities.

UML has quickly been adopted as the standard modeling language for modeling software systems. This book illustrates how it also can be used for business modeling, based on object-oriented concepts and thus demonstrates that the same modeling language can be used for business and for software models.

This book shows a business model from a number of views. Each view is expressed in one or more diagrams. The diagrams can be of different types, dependent upon the specific structure or situation in the business that it is depicting. The diagrams capture the processes, rules, goals, and objects in the business, and their relationships and interactions with each other.

Naturally, business models alone cant guarantee the success of a business. Good leadership and management are still needed, both in terms of having a long-term strategy and in running and coaching the daily operations. Nor are business models a substitution for finding the right people to work in the business, or for motivating and rewarding these people. All of these issues are very important, but beyond the scope of this book.



Chapter offers a short introduction to the basics of UML and describes some important concepts such as powertypes and stereotypes. Beginning in Chapter 3, Modeling the Business Architecture, well use UML to do business modeling.

Chapter 2: UML Primer

Overview

The Unified Modeling Language (UML) was created by Grady Booch, James Rumbaugh, and Ivar Jacobson, and later standardized by the Object Management Group (OMG) in 1997. Since then many people and companies have contributed to making UML the language for modeling software systems that it is today.

UML has become one of the most important topics of discussion in modern software engineering circles; and it is becoming of interest to management consulting firms, business analysts, system analysts, software developers and programmers, and people working with requirement specifications. In short, UML has had and continues to have a tremendous impact. Many companies have decided that all their software should be modeled with UML, and thousands of people have taken training courses in the language. Many books have been written about UML, and many software tools support it. All this progress and UMLs importance as a generic modeling language is still only in its infancy; its use is expected to grow substantially in the years to come.

UML Basics

A modeling language has a notation-the symbols used in the models-and a set of rules that govern the language. The rules are syntactic, semantic, and pragmatic. The syntactic rules dictate how the symbols should look and how they may be combined. The syntax can be compared to words in a natural language; as in a natural language, it is important to know how to spell them and how to combine them to form sentences. The semantic rules tell us what each symbol means and how it should be interpreted by itself or in the context of other symbols. These rules can be compared to the definitions of words in natural languages (what each word represents). Pragmatic rules explain how to use the language. They may be compared to writing guidelines in natural language. They define the intentions of the symbols, through which the purpose of the model is achieved and becomes understandable to others.

In UML the symbols are geometrical, such as rectangles, circles, and lines. It has a well-defined set of syntactic and semantic rules that define what the symbols mean and how they can be combined. But UML does not have pragmatic rules, that is, specific guidelines for how to use it. Therein lies one of the purposes of this book: to show pragmatic ways of using UML in business modeling.

This chapter gives an overview of the basic UML symbols, syntax, and semantics. The pragmatics of UML in the context of modeling businesses are explored in the remainder of this book. This chapter focuses on introducing UML fundamentals; it presumes a basic knowledge in object-oriented methodology. Those readers with a good knowledge of UML and object orientation can regard this chapter as a refresher and feel free to skim it. The chapter also addresses some special areas, such as powertypes and UML extensions, which will be of interest to readers already proficient in basic UML.

Unified Modeling Language

UML has nine predefined diagrams:



Class diagram. Describes the structure of a system. The structures are built from classes and relationships. The classes can represent and structure information, products, documents, or organizations.

Object diagram. Expresses possible object combinations of a specific class diagram. It is typically used to exemplify a class diagram.

Statechart diagram. Expresses possible states of a class (or a system). Activity diagram. Describes activities and actions taking place in a system. Sequence diagram. Shows one or several sequences of messages sent among a set of objects.

Collaboration diagram. Describes a complete collaboration among a set of objects. Use-case diagram. Illustrates the relationships between use cases. Each use case, typically defined in plain text, describes a part of the total system functionality. Component diagram. A special case of class diagram used to describe components within a software system.

Deployment diagram. A special case of class diagram used to describe hardware within a software system.

These diagrams capture the three important aspects of systems: structure, behavior, and functionality. Because of UMLs unique capability to adapt and extend, it is possible to add new diagrams and elements to UML, making it is a very flexible language that can be used in many situations. Extending UML is discussed in more detail later in this chapter.

Class Diagram

Systems are built from objects, which can be physical, such as computers, people, and raw materials, or abstract, such as information or knowledge. Objects are described by their internal properties and their relationships to other objects. For example, Bills bank account (an object) has attributes common to all bank accounts, such as balance, account number, and credit on current account. In addition, Bills bank account has relationships to other objects, in this case to a specific bank (a bank object) and to Bill himself (a person object). Attributes are described with a name and a type (integer, Boolean, string, date, etc.). For example, the account number attribute is an integer (a type); and in UML it is shown as Account Number : Integer. Objects also have behavior; for example, one can ask a bank account for its balance. Behavior is described with operations attached to the objects. A bank account could, for example, have cash withdrawal and get balance operations.

A class is a set of objects with the same characteristics. Typical classes are Person, Invoice, Company, Supplier, Order, Product, and Goal. Classifying and grouping objects into classes reduces the complexity and number of elements when modeling and facilitates describing more complicated systems.

Classes are modeled and related to each other in a class diagram. The classes are described with names, attributes, and operations. The relationships between the classes are described with a name, roles, and multiplicity. For example, many companies (employers) can employ many persons (employees). This relationship can be described in terms of classes: the class Company has an employ relationship with the class Person. The company plays the role of employer and the person the role of employee. This relationship also has multiplicity, because companies employ many persons, and a person can be employed by many companies.

Class diagrams are used to describe the objects and relationships of a system. Class diagrams capture and describe information within an information system (physical items in mechanical systems, parties in organizations) or they can be used to describe objects in biological systems, such as the ecosystem. Figure 2.1 is a class diagram for a small system for insurance companies. The model specifies that:

A person can be a policyholder, and a policyholder has one or many insurance contracts.

One insurance contract has one or many policyholders, which are persons.

One insurance company plays the role of an insurer who has zero, one, or many insurance contracts with policyholders. The insurance contracts



represent one insurance, which can be a car insurance, life insurance, or homeowners all-risk insurance. The insurance is regulated by the insurance contract, which specifies policyholder, term of insurance, and policy value. The contract includes all of this information (as attributes) in an insurance policy document.

An insurance contract is expressed in one (or zero, when it has not been printed yet) insurance policy.

1 mH.

1 e l IL-*rti

Figure 2.1: A class diagram describing a small system for insurance companies.

Classes and Objects

Another way to introduce the basic concepts of object technology is to quote from The Universal Dictionary of the English Language (Wordsworth Editions Ltd, 1989). All the basic concepts are defined there:

Class. Order, group, category of organisms, etc., which have some essential character or feature in common.

Object. (1) That which is presented to, or observed by, the senses; a material thing, anything visible or tangible. (2) That which is presented to, and grasped by, the mind; that which can be apprehended or known.

Attribute. A quality ascribed to, and considered as inherent in and essential to, any person or thing.

Operation. Act performed, transaction, in the way of business: operation on the stock exchange.

Association. (1) State of being associated, companionship, intimacy. (2) Connexion, bond.

Generalization. (1) Mental process of generalizing. (2) A notion, rule, law, etc. resulting from such a process; derived, evolved, formulated by observation of specific instances. Multiplicity. Quality, state, of being very numerous or various. Role. Part played by actor.

In UML, classes are defined as a set of objects with a name, attributes, and operations. The classes can be associated to each other via associations; and the associations have names, roles, and multiplicity. The only concept quoted from The Universal Dictionary of the English Language that was not explicitly discussed in the introduction is generalization. The insurance class in the model shown in Figure 2. is a generalization of car insurance, life insurance, and homeowners all-risk insurance. The class Insurance then includes the car insurance, life insurance, and householders all-risk insurance. In a mathematical sense, a class is a set of objects, and a generalization is just a set of sets. The Insurance class is a superset containing the subsets of car insurance, life insurance, and householders all-risk insurance.

A class is drawn in UML with a rectangle that is divided horizontally into three compartments. The top compartment contains the name of the class; the middle compartment contains the attributes of the class; and the bottom compartment contains the operations of the class. A compartment can be suppressed in a diagram. Attributes with a plus sign (+) in front of them are public, meaning that other classes can access



them. Attributes preceded by the minus sign (-) are private, indicating that only the class itself and its objects can access the attribute. Protected attributes, marked with the number sign (#), can be used by the class and any descendant (specialization) of the class. Attributes can also be marked as class scope global by underlining the attribute. This designates that the attribute has only one value in common with all objects. An example of a class scope global attribute is a counter, such as number of invoices, that is common to all instances of the class. An attributes possible values can be enumerated, in which case they are shown in the form {a,b,c...}. Figure 2.2 shows class Invoice with the name and attribute compartments (the operations compartment is suppressed). Invoice has the attributes amount, date, customer, specification, administrator, number of invoices, and status. The amount attribute is of type Real (real number), date is of type Date with the initial value Current date, which means that when a new object of the class Invoice is created the attribute date of that object will be assigned the current date, invoice

+ amount: Real

+ dale : Date - Current date

* customer: Siring

* specification: Siring

adminislralBr: Siring = Unspectoad1

nurnb&r e( invoices : Integer

* slalus : &talu6 = unpaid [unpaid, paidf

Figure 2.2: A class with attributes. Classes also have operations, services that the class provides. Operations are similar to functions in programming languages; but the operations in a class have unique access to all the attributes in that class. An operation has a name, visibility, a list of parameters, and a return type. An operation performs some service that the class provides; it sometimes requires parameter values as input; and it returns a result of the return type. Figure 2.3 shows a Bank Account class with the operations cash deposit, case withdrawal, and bank statement. Bank Account

account rwmb&r: Siring

balance: CarDala

+ cash deposil (amount: real): Boolean + cash withdrawal (amount: real) : Boolean + bank slalemenl () : real

Figure 2.3: Examples of operations.

Operations can also be class scope global. Two examples of operations that always are global (for a class) are create and destroy (sometimes referred to as the constructor and the destructor of the class). A create operation is used to create new objects. It is global to the class because it is not possible to ask an object to create itself (because it needs to exist to ask it that). The destroy operation is used to model the destruction of objects. Associations are given names (usually verbs) and are represented in UML with lines. The association name appears near the association line, and multiplicity and role names appear on each end, as shown in Figure 2.4. Multiplicity is presented as a range, such as 1..5 or 0..* or as a specific number, such as 4. The asterisk (*) indicates many (an open interval). The multiplicity 0..* indicates zero or more. For example, Figure 2.4 shows that the class Insurance Company is associated to zero or more insurance contracts (specified at the end of the association line, near the Insurance contract class). Multiplicity is indicated at the ends of the association, also called the roles of the association. Specifying a name for each role is optional.



irti..iin

boa ►

1 !i issued by ni

о

mi m

A ex.-

гшпа .1

л ii:uidc

-№ldlicjh зп

: i. i .

Figure 2.4: A class diagram with classes, associations, association names, roles, multiplicity, and a constraint (xor). The reversed name of the association is indicated in parentheses.

Associations can also be given a name direction, specifying how the name of the association should be read. (For example, the Insurance Company has Insurance contracts, not vice versa.) The name direction is drawn near the association name and marked with a small, solid black triangle. If needed, the reversed name (the name in opposite direction) of an association can be indicated in parentheses. The constraint {xor}, drawn between the is insured through associations, indicates that only one of these associations can be valid at a time.

The class diagram in Figure 2.4 indicates that the Person class (a noun and a subject) is associated to the Insurance contract class (a noun and a object) with the association of has (a verb) and the multiplicity of 0..* at the end of Insurance contract. The Person is insured through one or more Insurance contracts.

More about Relationships

The aggregate relationship is a specialization of association used in situations where a whole is connected with its parts, as shown in Figure 2.5. The hollow diamond on the association in this figure denotes that a delivery aggregates many products (the parts). A delivery consists of a number of products. The constraint {ordered} indicates that a specific order exists between the different products.

DelivEry

;-:)rder d.i

Contains

Product

Figure 2.5: A delivery aggregates a number of products. Object composition, shown with a filled diamond, is a stronger form of aggregation. This relationship indicates that the parts can only be in one entity at time. Figure 2.6 shows object composition.

- ----- I--ВОЯ

Window

Mtuajc Box Window

tft [rj..l : Burton апм1 ;u V В И

inlOrmflliC*! 0..1]: l n

Sutton

Icon

(a} :i>-

Figure 2.6: Object composition. Buttons and an icon compose a message box. The right side

(b) is another way to show object composition. Where three classes are connected, a ternary association is used, as shown in Figure 2.7. Associations are normally bidirectional but there may be unidirectional associations in which the association is only valid in one direction. The association in Figure 2.7 is unidirectional. In this figure, a Plan and a Project are connected to several Resources. Ternaries can be used with both unidirectional and bidirectional associations.



1 2 3 4 ... 27
© 2003 GARUN.RU.
Копирование материалов запрещено.