Documenting Business Models

In other cases, there is no strong need to construct a business model before you get on with a component spec, particularly if the software focuses on only one aspect of a very general business. Sometimes it is useful to create the static part of the business model, without any collaborations. For example, before designing a word processor, you first define what a document is. This is the business world in this case—the subject matter with which the software will deal but modeled separately from any concerns of what the software will do with it. This approach is particularly useful when there are standards of interchange between components Web pages, RTF files, floppy disks, and TV pictures all have standard models of the objects without designing the equipment that handles them. 

You write business models and requirements documents by talking with people who know the business and will use the product that you are designing. They may be end users, or... 

As with business models, the main message is to keep the users well involved. The worst method is to take an informal requirements document, go off into a back room for three years, and then proudly present users with something that isn t what they wanted in the first place and is inappropriate now. You need to make it clear to users that their ideas are invited, take steps to stimulate ideas, and keep them in touch with the process. 

Business model A (section of a) document that describes the business or problem domain, precisely capturing object types, attributes, invariants, and actions. This document may itself be structured based on... 

Choose Classes Based on the Business Model To maintain traceability, deviations forced by performance, current or planned reuse, and other constraints should be local and clearly documented as refinements. 

For example, one of our clients in the telecommunications industry recently built a business model. In that world, all the manufacturers and operators adhere to several standards. So some of the client s model was determined by what the standards say and will have to be updated whenever the standards change in other words, it imports the industry-standard virtual packages. So our client s business model contains definitions of the standardized concepts (or at least its interpretations of them) along with all its own definitions. Because there were not yet arty UML versions of these standards, we simply consider the standards documents to be part of an implicit virtual package and proceed to virtually import it. 

For every Customer we know about businesswise, there is a Person in the System Design. We ve shown the relationship as the association abs. There are similar direct correspondences for several other types. In fact, the whole business model is implemented by the whole system design, so we ve shown that association, too. (The outer type boxes are shown in gray to reduce clutter in Figure 10.26. In real documentation, you d show them separately.) So we can say that... 

Documentation is structured around specifications and implementation and their refinement and import relationships. A user manual—a description of how a user accomplishes tasks by using the system(s)—is a particular form of documentation associated with a refinement how the abstract business model and actions are realized by more-detailed actions performed by the users and systems. Test specifications are also associated with refinement relationships. The rules for system architecture are documented in a package that specifies the patterns and frameworks that will be used in other packages that import it. 

Moreover, as discussed in Section 13.1.2, Specify, Document, Implement, and Test Business to Code, activities to build, install, and deploy a system are consistently thought of as implementation steps at different levels implementation of internal design, system spec, and the to-be business model. 

Are you going to reuse the old code or only the old design ideas or only the old business model In general, each of these elements can be reused using appropriate techniques. In each case, it is essential to capture the existing concepts first (using the modeling notation in earlier chapters) and, separately, to document where you d like to be. 

Many of us have experience of development where the designers don t get to meet the end-users that is the analysts prerogative. (They know how to wear smart suits, I guess.) The effect is that although they may implement the stated requirements, they may do so in a way that isn t very user-friendly — simply because they don t have a clear vision of the context in which the system works. The context model and its documentation gets around this, and provides a clearly scoped connection to the business model. 

This book also covers the connection between the new EU Chemicals Policy (REACH) and Chemical Leasing. Within REACH, cooperation, networking and communication based on documentation, evaluation and minimisation of hazards is indispensable. The new business model can serve as a basis for this intensified dialogue and cooperation. 

The Registration phase of REACH and the Principles of Chemical Leasing business models have additional central aspects in common. They both involve different stages of the supply chain - as producers and applicants are challenged - and both approaches are life-cycle oriented either through their documentation requirements addressing phases of production, use or dis-... 

Each person in an enterprise has an individual view of the business, tmd this view is often limited in scope and parochial in nature. Variations among viewpoints can cause considerable misunderstanding among individuals and groups about the purposes and direction of the enterprise. A well-documented, comprehensive business model can facilitate a common understemding of the business, both internally and externally. 

For purposes of understanding the business and documenting the business model, it is useful to organize the business processes into categories ... 

The ARIS concept in Figure 18 is enhanced by the phases of the buUdtime ARIS phase model. After a general conceptual design, the business processes are divided into ARIS views and documented and modeled from the requirements definition to the implementation description. These three description levels are created for controlling purposes as well. This makes it possible to create the links to the other components at each of the description levels. 

But a model should surely tell us something about the business or design if we re allowed to do things any old way, what s the difference between a system that conforms to the model and one that doesn t The practical answer is that the information represented by each attribute should be in there somewhere. It should be possible to write a read-only function or procedure that retrieves the information from whatever weird format the designer has represented it. These abstraction or retrieval functions are a valuable aid to both documentation and debugging. (You ll find more about this in Chapter 6, Abstraction, Refinement, and Testing.)... 

Experience with formal notations shows that the precision of the notation tends to flush out these issues at the appropriate stage. Anyone who has spent a day or two in a specification workshop, creating a model for a business or a new system, is aware of how quickly important questions are raised. Many of these issues would never have been thought of had the requirements document been in plain natural language (English or your local favorite). 

The usual excuse is, We ll do it soon—when we get some time. Developers are too busy sorting out problems and late updates to do the write-ups. It s funny how these projects are always the ones that require a lot of heroic overtime. See Ed Yourdon s excellent book The Decline of the American Programmer. In such a case, a possible damage limiter is to hire a suitably skilled person to spend a few weeks writing the models. This person may be able to clarify some inconsistencies and at the same time transfer some skills to the existing team. But a lack of documentation is a cultural problem and is not easily fixed. 

We describe designs for objects using collaborations—collections of actions. A joint action defines a goal achieved collaboratively between the participant objects, using postconditions whose vocabulary is the model of each of the participants. Collaborations range from business interactions ( banks trade stocks ) to hardware ( fax sender sends document to receiver ) to software ( scrollbar displays file position ). 

For example, the GUI of a typical development might be documented only with storyboards and GUI mock-ups that are annotated with explanatory notes, with an optional mapping to the type model. Other design discussions, and specification of business behavior, use proper action specifications. Exceptions may be done more or less formally, depending on project needs. 

Deployment It is in this phase that the business or domain makes its transition to the to-be model, adopting new processes, hardware, and software. It involves things such as software and hardware installation, tools to upgrade or migrate to new releases, documentation, acceptance testing, and user and administrator training. Note that user docu-... 

---