Discussion: Even the words used for the building blocks of business models (e.g., the vocabulary used to develop structured business vocabularies) must be natural for business people – again, real-world. Business people talk about real-world things!
A business model enables business people and Business Analysts to engage in discussion about what needs to be created, managed, operated, changed, and discontinued in the business in business terms. Developing a business solution using a future-form business model does not necessarily imply software development, but if software development does ensue (as it usually does) the business model provides a solid grounding.
Examples of business models include strategies for business solutions (Policy Charters), business process models, structured business vocabulary (fact models), business milestone models, and Q-Charts (for decision analysis). The term business model is also used collectively to designate all the business models for a particular business capability. A business model is always subject both individually and collectively to the business rules specified for it.system model: a model that provides a design for an automatable system that is computationally competent
Discussion: For many years John Zachman, creator of the Zachman Architecture Framework, has explained that a business model is always about real-world things. These real-world things are as the business leads see or define them.
A system model in contrast comprises “… surrogates for the real-world things so that the real-world things can be managed on a scale and at a distance that is not possible in the real world.” Surrogates include data entities in place of real-world things; GUIs and use cases in place of face-to-face, real-world communication; network nodes in place of real-world locations; system events rather than operational business events; and so on.Does the separation between business model and system model blur in eCommerce? No. If business leads see or define ePersons (for example) as real-world, then real-world they are. To ensure you have a winning business solution, the ePersons should be defined and shaped within a business model. Afterwards comes design of a computationally-competent system model so you can conduct actual business with the ePersons. [John Zachman, informal communication, June 2011] ~~~~~~~~~~~~~~~~~~ Excerpted from from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, Business Rule Solutions, LLC, October, 2011, 304 pp, http://www.brsolutions.com/bbs
“Location” was previously used for the “Where” Column, which caused some people to put in instances (e.g., “Sacramento”). So, Column 3 now uses “Distribution Networks.”
The “Who” Column now uses “Responsibility Assignments” to emphasize that it covers roles rather than the individuals.
The “When” Column previously used the terms “Cycle” and “Event” for artifact models, which were often misunderstood. The Column 5 primitive models now use “Interval (for “Cycle”) and “Moment” (for “Event”). For example, Row 2 now features “Business Interval” and “Business Moment”.
The Model Names used to be shown to the left, and the Audience Perspectives on the right. These have been swapped.
As part of the ongoing work to improve communication about the Framework, the “Audience” labels now use “Perspective”.
Also, use of “Planner” was removed because it conveyed the wrong idea about the nature of the audience for the top Rows. Row 1 now uses “Executive Perspective” and Row 2 uses “Business Management Perspective”.
Zachman seriously considered moving the Classification Names (What, How, Where, Who, When, Why) to the bottom of the graphic and moving the Enterprise Names to the top. At the last minute he decided not to because a practitioner shared a compelling story with him about how W-H-W-W-W-W inspired an important discovery in his work.
To communicate that going down the rows does not indicate decomposition, crooked arrows are now shown between each of the Rows. These crooked arrows emphasize that moving from one Row to the next represents a transform. (Credit was given to Ron for this suggestion.)
Note: The transforms relationship can be one-to-many, but that’s something you need to manage very carefully.
For horizontal alignment (across a Row), make sure your tool supports the primitives and then helps you manage the compositions.
For vertical alignment (up/down a Column), you cannot just ‘push the button’ (do the transform), then forget about managing the vertical relationships. Change is inevitable, so vertical alignment must be maintained.