What is operational business know-how? How can you model it? What results can you achieve by doing so? The answers lie with creating true-to-life business models based on behavioral rules, decision rules, operational business decisions, and operational business events — all as first-class citizens. Understanding their intertwined roles is key to creating top-notch business solutions and business operation systems unmatched in their support for business agility and knowledge retention. Find out what ideas and techniques you need to create know-how models: http://www.brcommunity.com/b623.php

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.

 

For those of you who know or have ever heard Zachman speak, I know this will come as a shock. Part of his 3.0 Release? Source: Real-time photo supplied by Keri Anderson Healy, Editor, BRcommunity.com

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?