Now that we've specified the external requirements, we begin mapping our system-to-be by sketching out its internal structure, gradually involving more IT personnel. Involvement of the stakeholders depends on the nature of the system. If the system is to be highly interactive, then much of the hard work has already been done during specifying and defining the use cases. If the system-to-be is more complex than interactive, such as a knowledge base, then you might have to do much more work at this stage, for example, detailing the rules that affect each part of the solution.

We're also dependent on the skills of our IT personnel. Throughout the project, experienced people familiar with both object methodology and conceptual thinking will ask many of the important questions early in the specification stage, whereas new converts will appreciate more input from other stakeholders, including help with first-cut key diagrams.

Because structure issues are key with most enterprise systems, we provide boxes on some advanced constructs, as well as extensive footnotes on details and semi-technical issues. We point out why some peripheral, or seemingly peripheral, questions often emerge during modeling.

Some methodologies encourage a two-step process on defining classes: first, model the business classes (the first cut), and then develop a complete class model. In a lightweight approach, we can view these as two levels of detail, which then gives an indication of the involvement of relevant business expertise.

Software – Yet Another Knowledge Industry

Knowledge industries such as electronics, space, pharmaceuticals, or software are special. On the surface, they're the hotly-argued-upon backbone of the new economy, a concept that's no longer new. In our opinion, it's the approach to business that makes the difference, rather than a company's niche or age. Some old-economy veterans, such as global-automation vendor ABB, have rapidly expanded their R&D initiatives and resources, employing many more IT specialists than many so-called new high-profile IT firms. IT provides a foundation to a variety of current business ideas, including customer-driven manufacturing where a web customer configures the product or even the software guiding an industrial robot in manufacturing the chosen customized product.

Obviously, knowledge industries are more special under the shell than at this slightly superficial mass-media/thematic level. On one hand, they have business processes similar to other industries but, on the other hand, production/operations is a small part of any business dominated by R&D and by marketing the know-how of that organization.

Awareness of knowledge-industry specifics is a project-time saver, both within the software industry itself and with the rapidly increasing number of its customers in the other knowledge industries. Knowledge industries are often interleaved with traditional industry sectors – today, you find computer chips and software in all the flagships of industrialism, from heavy trucks to railways. But, in a high-tech region, the complete knowledge-business value chain can sometimes grow remarkably long without any tangible (“hard”) products whatsoever (Figure 1-1).

Think Big, Start Small, and Sustain the Effort

Most people agree that analysis occurs only when the domain expert is in the room. In our experience, in addition to being present, experts are also supposed to understand the language “spoken” in the room. The language problem has often turned out to be even bigger than that of business-travel logistics. The UML, however, provides many powerful tools to make yourself understood in the room, which come in handy for the frequent visitor. By writing this book, we simply seized the opportunity and packaged much of the substance in a lightweight manner for this purpose.

Implementing UML models (and tools) to specify requirements doesn't take much time. Employing them in a practical approach preshrunk to fit your type of systems takes more training days and practical experience. Finally, adopting a component approach throughout the enterprise can take years of sustained effort, but it's definitely worthwhile.

UML Under Time Constraints

We believe the lightweight style of this book makes it possible for experts from many other areas to approach practical, basic UML. A frequent guest to the landscape of software can view this as a phrase book for the journey, keeping grammar detail at a minimum because many good grammar books already exist for this modeling language.

At the same time, we've provided some hints on cooperation with the hosts and on what parts of the language a guest typically becomes involved with in practice.

The excellent idea of writing a lightweight book on the Unified Modeling Language (UML) wasn't ours, we admit. This idea originated from Milan's customers. Having taught more than a hundred courses and seminars on component approaches to software development and on UML over the past few years, he was repeatedly asked for “UML made easy” for people who specify, buy, or manage complex software systems, yet don't program them. This demand seems logical given the way UML is being used in projects and read of in the success stories – as well as the increasing specification workload in any knowledge industry (see Introduction). However, as we moved on into this book project, both of us became increasingly enthusiastic about the idea, as did Cambridge University Press (CUP). Luckily, a majority of our readers are quite familiar with CUP from their own (variety of) fields; so this book is likely to be seen as accessible in most senses of the word.

Any system specification can state requirements on functionality, usability, reliability, performance, and supportability, as well as legal and technical constraints where relevant. In UML projects, we start from a view of the business – its processes and activities – and move into functionality, incrementing all the remaining, nonfunctional, bullet lists as we go.

Having set the stage with class diagrams, we'll now look more closely at what is likely to happen on that stage. We examine life cycles and (with the assistance of IT staff) interactions between all the small parts within the system.

State Diagrams

Some business entities have interesting life cycles because of real-world regularities and constraints, such as business rules, legislation, laws of nature, and so forth governing their “lives.” Because these business entities are represented by a class, we model this dynamic aspect in a state diagram per class.

In most enterprises, some key business entities have an interesting life cycle, which makes a state diagram necessary. These examples show the key states (life-cycle phases) for certain key entities in different industries:

• Banking: Account (in_credit – overdrawn – blocked – overdrawn and blocked – closed)

• Travel: Reservation (registered – on waiting list – reserved – paid)

• Brokerage, shares, bonds: Order (placed – activated at desired price – deal-confirmed – closed)

• Insurance: Retirement plan (employed – payment-aged – retired – deactivated)

We find such key entities in practically any business. The latter example simply mirrors the life cycle from a retirement plan point of view.

Strengths

A state diagram is a compact, yet quite intuitive, notation. These diagrams are versatile because they can mirror the lifetime dynamics of a rather long “life” in the kernel of an enterprise system, as well as a rather short “life” in a user dialogue or in a real-time system.

Data modeling has been covered thoroughly for decades. Like class diagrams, it provides a structural view. Unlike class diagrams, data modeling omits business-level operations that the proposed system will perform. Most often, it also omits some key relationships, such as generalization, despite the fact that various data-model notations for generalization have been around for almost two decades. Because most data models are on a design level, they already take into account some restrictions posed by the underlying implementation technology (data tables).

Strengths

Data models cope well with the data to be stored in the bottom layer of a system. Therefore, data modeling is a technique suitable later on, during design. The mapping to data models enables modern object-oriented systems to use ordinary relational database engines, which are standard in enterprise systems. In practice, brief previews with Database Administrators are a good idea to coordinate legacy and other systems with our models to come. By the time data modeling becomes really interesting in our project, we already have a more technical focus.

Limitations

Data models omit most of the behavior and business logic. Also, what data modelers call constraints or rules typically turns out to mean special data-related ones (such as rules of referential integrity across data tables), whereas UML includes a more versatile and powerful standard for declaring complex business logic, the UML Object Constraint Language (OCL).

Before modeling the design of the system, a project team typically models the business processes to identify the scope of the planned system and to ensure that any chosen system aligns to the demands of both this business model and business vision.

A variety of possible diagram techniques exist for delivering this business model, as well as possible levels of ambition. With business redesign, a risk occurs of having eyes for nothing else but the modeling and ignoring some real dangers. The hard work isn't about creating a best-of-breed business model; it's about enforcing corporate change within the organization. To remind the reader of these risks, we've made separate box diagrams of the more fancy UML features. Here, lengthy modeling exercises might become a convenient excuse for avoiding challenge and confrontation with the permafrost layers found in many organizations. This challenge and lack of confrontation is a common pitfall in implementing new business practices. Therefore, process innovation methodologies spend little time analyzing the current (as is) processes – often, a quick diagnosis is enough. Instead, we focus on the new business models: the business to be.

Ownership of the business models must remain with the stakeholders and process owners. This avoids the danger of the new processes being seen as the work of the IT department, which can lead to rejection of the models by the process owners. It must be made clear that the IT specialists act only as agents in producing the business models.

This part of the book will present the validation of the Template theory and elaborate on some of its aspects. The presentation of the Templates alone may appear somewhat mystical to readers who may wonder about whether Templates prove superior in a more rigorous empirical examination, beyond the examples presented earlier. Understanding the theoretical grounds and the tests that challenge it should improve ability with and confidence in the implementation of the Templates. The empirical studies reported herein were published in Goldenberg, Mazursky and Solomon [1] and Goldenberg, Lehmann and Mazursky [2]. For readers unfamiliar with the statistical methods we are using who would like to learn more we recommend the following introductory texts:

Hair, J. F., Anderson, R. E., Tatham, R. L. and Black, W. C. (1998) Multivariate Data Analysis. New Jersey: Prentice Hall.

Lehmann, D. R., Gupta, S. and Steckel, J. H. (1997) Marketing Research. New York: Addison-Wesley. The structure of Part IV is as follows:

1. First we will present the distribution of Template-based ideas in successful new products. It turns out that 70% of successful new products in a variety of categories pertain to one or other of the Templates' structures.

2. Then we present the experiments, which indicated that individuals trained in the Template approach were able to elicit ideas that were superior to those elicited by individuals in various control groups.

3. […]

In order to understand how our Creativity Templates approach compares with other creativity-enhancing methods we look at three possible approaches.

1. Methods for “ management of the ideation session” (brainstorming, the Six Thinking Hats, electronic brainstorming (EBS), decision-making management, etc.) vs. methods which affect or manage cognitive processes (thinking). The Creativity Template proposed in this book approach belongs in the second category.

2. Methods trying to enhance randomness, on the assumption that it is instrumental to creativity vs. methods which are analytical and focused. Our approach belongs to the second category.

3. Generalized vs. specific methods. It is often argued that the more generalized an approach, the weaker it is; the more specific the method, the stronger it is. One may notice that the approaches in the Creativity Template category act in a narrower content world and not in general problem-solving, and should therefore be stronger. The suggested method for new products is different from that for advertising, and we claim that it has to be applied verbatim to general organizational problem-solving. Indeed, in marketing our method had to be specifically adapted to each focused content world. On the one hand, the method thus lacks generality; on the other hand, its effectiveness is increased. The lack of generality requires adaptation of the method to each content world. However, we claim that this is a worthwhile undertaking.

Searching for Attribute Dependency

We have seen that the Attribute Dependency Template may serve to enable the development of a new product on the basis of an existing one – a standard candle becomes a non-drip candle, lipstick is improved, a new model of car emerges. However, each time we added a dependency and obtained a new product, we did not ask how we might identify the relevant variables, but took these for granted.

In this chapter we shall focus on the methodical identification of these dependencies, and describe in detail a structured process of the “management” of a search for new dependencies, by discussing two examples. In conclusion, we give a systematic operational recipe guiding the practical implementation of the method.

Classification of variables

Our aim is to “read” the information embedded in the product as if we were reading a map of potential changes, and to manage this information in a way that will enable the addition of a dependency. First, we must classify the variables according to the following criteria.

Internal versus external variables

An internal variable is under the full control of the manufacturer, who determines its values and characteristics. We have met internal variables such as the strength of a pole, the price of pizza, the color of a car and the melting temperature of wax.