- Requirements
- Business Processes
- Business Analysis
- Business Agility
- Enterprise Architecture
- Zachman Framework
- Knowledge Retention
- Events
- Enforcement
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 competentDiscussion: 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/bbsRules should be defined independently of responsibility for the who, where, when, or how of their enforcement.
Why? Separation of rule specification from enforcement concerns[2] ensures that …What in your current IT requirements methodology ensures you will get consistent results for each business rule across all these processes, procedures, and use cases?
Unfortunately, the answer today is almost always nothing. In the past, business rules have seldom been treated as a first-class citizen. No wonder legacy systems often act in such unexpected and inconsistent ways(!). Organizations today need business operation systems where business governance, not simply information, is the central concern. Business rules should be seen as one of the starting points for creating system models – not something designers eventually work down to in use cases. That’s the tail wagging the dog. By unifying each business rule (single-sourcing), and faithfully supporting all its flash points wherever they occur, Business Analysts can ensure consistent results across all processes, procedures, and use cases. Is there really any other way?! ~~~~~~~~~~~~~~~~~~~ Excerpted 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, 2011, 304 pp,http://www.brsolutions.com/bbs5.1 Business rules should be expressed in such a way that they can be validated for correctness by business people.
Validation and correctness, however, are not the only focus for business analysis with business rules. Another is whether each rule can be justified as being truly productive for the business. Businesses often accrue so many rules over time (include ‘exceptions’ in that!) that their spiraling complexity results in rapidly diminishing return. So the cost-effectiveness of every business rule should be assessed, at least informally. To do so, first you must recognize there is cost associated with each rule. The Manifesto makes that point explicit …8.2 Rules always cost the business something.
A rule’s true cost, however, might not be exactly what you think – the platform costs may be relatively insignificant. Instead, the principal cost of most rules is organizational. Rules must be documented. They must be taught to new hires. They must be explained to external parties. All these things take time – and time is money. Also note carefully: This overhead doesn’t decrease with each additional rule – it increases. The more rules, the more complexity. The Manifesto in no way suggests that more rules is better. Just the opposite; it emphasizes that a smaller number of good rules is always better. Better to start with a smaller number, then add more as you go. The Manifesto puts it this way …8.5. An effective system can be based on a small number of rules. Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.
It’s simply a myth that you have to know all the rules before designing and building productive business systems. Just the opposite is true. You can deploy a simpler solution initially, then add rules later on as time and insight permits. Fortunately, rule-based systems are extremely good at incremental design – the goal of many an agile project.1.1 Rules are a first-class citizen of the requirements world.
This first point does not suggest that business rules are more important than other requirements – for example, process models – but rather, co-equal. How can you organize or model any kind of activity without knowing the rules?! That understanding leads to the second point of the Manifesto …1.2 Rules are essential for, and a discrete part of, business models and technology models.
The “discrete part of” in this statement is crucial. It means that rules should not be embedded in other deliverables – for example, use cases – so that the rules can be written once and then applied everywhere (single-sourcing). It also means the rules can be validated directly with business people and subject matter experts. The result is better requirements – and better communication. Another result is rule independence. The rules can now evolve independently of other architectural components, often much faster. By not hard-coding rules into application programs, much more agile business solutions can be achieved. The Manifesto makes the point this way …6.1 A business rules application is intentionally built to accommodate continuous change in business rules. The platform on which the application runs should support such continuous change.