Building Business Solutions: Business Analysis with Business Rules (2nd Edition) … Just Out! http://www.brsolutions.com/b_building_business_solutions.php Get it on Amazon: http://goo.gl/HXxN1f What It’s About: How to develop business solutions working directly with business leads, create blueprints of the solutions, and then use those blueprints for developing system requirements. Engineering business solutions, not just requirements.We have applied the techniques described in this book successfully in hundreds of companies worldwide. Kind Words from a Practitioner: “We have based our whole business rules analysis practice on the methodology and techniques developed by the Business Rules Solution team. This book is an integral part of our practice. It’s an easy to read, useful guide with real life examples – we use it daily and couldn’t do without it!” – Michelle Murray, Inland Revenue Department NZ New in this Edition: How Business Architecture corresponds with your projects and requirements work. Developing a Concept Model and how it will help you. How business rules align with the new terminology in the recently released IIBA® BABOK® Guide version 3. ~~~~~~~~~~~~~~~~~ www.BRSolutions.com

Here are what I firmly believe are three basic principles for business architecture. To me they are just common sense, but they are certainly not so common in prevailing industry practices. 1. Business architecture should be of, by and for the business. (Otherwise, why add the modifier “business”?!). Our rule of thumb is that if business people don’t use a methodology term naturally, then it has no place in *business* architecture. Ever hear a business person use the term “business use case” or simply “use case” without prompting from IT?! The technique is an obvious misfit for *business* architecture. This is simply a case of IT trying to elevate its own tools to a problem it frankly often doesn’t understand. 2. The blueprinting techniques used for business architecture should apply exactly the same no matter how wide the scope – project, business process, whole business, whole supply chain, etc. These are all business problems (first), just sitting in different ecosystems. Also, it should make no difference whether automation is anticipated or not. (Actually, running business operations by hand may be harder in some respects than if automated. Anyway, systems do sometimes go down.) If a blueprinting approach fails in these regards, it’s not about *business* architecture. 3. A major shortcoming in most current approaches is the absence of attention to specifying semantics and knowledge. These need not be interpreted as anything arcane – they’re not. Basically, ‘semantics and knowledge’ simply means defining business vocabulary – words – in an organized manner, and practicable rules to run the business by. Now what business person hasn’t heard of “words”, “definitions”, and “rules”?! Yet traditional IT methods treat them as alien (or not at all). In a day and age of IBM Watson, how could such practices not be seen as archaic?! ~~~~~~~~~ P.S. Yes, such blueprinting techniques for business architecture do exist, and we practice them – in-depth – all the time with our clients. This is what our book Building Business Solutions: Business Analysis with Business Rules (http://www.brsolutions.com/b_building_business_solutions.php) is all about, as well as our on-line training based on it (http://www.attainingedge.com/online-training-business-analysis-with-business-rules.php). www.BRSolutions.com

You can find definitions and discussion of all terms in blue on Business Rule Community: http://www.brcommunity.com/BBSGlossary.pdf ~~~~~~~~~~~~~~~~~~~ business model:  a blueprint for a business capability based directly on real-world things and ideas strictly named and represented using words natural to business people

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

In yesterday’s post I talked about the difference between business models and system models: http://goo.gl/CMMPi  To make a long story short, business models talk directly about real-world things (as business people do); systems models talk about surrogates for real-world things (as system designers do). Not the same thing! Some people argue that the separation between business model and system model blurs in eCommerce. Does it?  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 those ePersons.

---

We’re teaching our online training course next week: Business Analysis with Business Rules: From Strategy to Requirements. http://goo.gl/Vnko3 Hope to see you there! Naturally, we’ll be talking a lot about business requirements. Are business requirements the same as functional requirements? No! Functional Requirement vs. Business Requirement Wikipedia describes a functional requirement as … “a requirement that defines a function of a software system … what a system is supposed to accomplish” [emphasis added] We define a business requirement as … “something called for or demanded by a business model that a system model must support” That’s a big difference! Appreciating the importance of the difference, however, requires clear understanding of the distinction between business model and system model. Business Model  We define a business model as follows[1] … a blueprint for a business capability based directly on real-world things and ideas strictly named and represented using words natural to business people We stress that business people talk about real-world things! And why should we ask them to do any differently?! 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 to-be 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 (concept models), business milestone models, and Q-Charts (for decision analysis). Any business model is always subject both individually and collectively to the business rules specified for it(!) We believe business rules are key to creating effective business requirements. System Model We define a system model as follows … a model that provides a design for an automatable system that is computationally competent 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.  That idea is actually his, not ours. Zachman describes a system model, in contrast to a business model, as comprising “… 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 or business objects 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.
• etc.

If you are developing ‘requirements’ using use cases, you are actually designing a system (creating a system model), not defining business requirements(!). We believe a focus on use cases with no prior business model puts your project at grave risk.

---

In running facilitated sessions, we like to create each kind of business model on a different wall.  We find that the physical act of walking or shifting focus from one wall to another helps participants rapidly grasp and remember what each wall represents.  It also helps business leads and Business Analysts identify disconnects and gaps in the business solution more readily. We call this walking the walls. Our definition:  managing complexity in developing a business model by figuratively, and as much as possible literally, addressing each primitive as a separate concern (i.e., on a different wall)  In physically walking the walks, we usually put business process model(s) on the left wall and the structured business vocabulary (concept model) on the right wall.  On the front wall we put reminders about the strategy for the business solution (Policy Charter) and on the back wall we capture business rules.   Aside: Business rules go on the back wall to help resist the temptation of wordsmithing, which is better done offline.  In an ideal world, there would be one surface for each of the six primitives of the Zachman Architecture Framework.  (Alas the ceiling and floor are hard to use.)  Business rules, serving as integration relationships, would occupy the 3D space between the six surfaces (even harder to use!).  Our approach approximates the notions well enough in practice.

The next time I have dinner with John, I have two questions for him. (He knows I always have new questions for him every time I see him, so he’s more or less prepared for it after all these years.) If anyone talks to him sooner, be sure to ask John these two questions … and please post the answers(!). 1. Where are business rules? (I think I know what he’ll say about this one.) 2. Why did events disappear in this rendition of the Framework? (I don’t know the answer to this one, and though subtle, it may prove to have the most important implications of any adjustment he’s made this time around.)

Our Editor for BRCommunity.com, Keri Anderson Healy, attended the announcement event last week for version 3.0 of the Framework. Now she’s back home and has had a chance to share the rest of her notes. If you missed the first post, here’s a zipped pdf of the new 3.0 version again (with permission): ZF3.0.zip [approx 1.5M]. An official version will be posted on http://www.zachman.com soon. Visit Zachman’s new website for the latest!  

• Terms in some of the Column names changed.

 “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.

•  Better artifact terms for the “When” Column.

 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”.

•  Swapped the sets of names shown on the left and right sides of the graphic.

 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”.

• Did not swap the sets of names shown at the top and bottom of the graphic.

 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.  

•  New emphasis that the Framework does not show a decomposition.

 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.

• Alignment shown for two dimensions of the graphic – at the top/bottom and on the two sides.

 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.

 

As many of you are aware, the Business Rules Forum Conference is now one of three conferences in the annual Building Business Capabilities (BBC) Conference (http://www.buildingbusinesscapability.com/), which includes the Business Analysis Forum, the official conference of the IIBA. So Gladys and I have had to do some hard thinking about the meaning of “business capability”. Here’s our take emphasizing business … A business capability is not an application system, database, set of use cases, enterprise architecture, or any other IT artifact. Its design and implementation might depend on some or all of those things, but that’s a different matter.  Instead, a business capability is created as a business solution to an operational business problem. That solution and the problem it addresses have a scope (definite boundaries) that can be identified in terms of what business items make it up. The business solution is initially developed and expressed as a business strategy (a Policy Charter in our methodology, Proteus).  The business model you create in business analysis is the business architecture for the business capability, a blueprint enabling business people and Business Analysts to engage in a business discussion about what needs to be created, managed, operated, changed, and discontinued. Developing a business solution using a business model does not necessarily imply software development, but if software development does ensue (and it usually does), the business model provides a solid grounding.  Our definition of business capability comes down to this: What the business must know and be able to do to execute business strategy. The part that many people miss is what the business needs to know. Quite simply: How can you really ‘do’ without knowing what your business rules are?