Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Confession Time … I Fell into the Same Vocabulary Trap I Warn Everyone Else About

I have been involved in a great on-going discussion on LinkedIn about data models. I posed the question: Is there any proven way to demonstrate data models are correct, complete, and stable with respect to the operational business and its needs? You might enjoy joining in: http://goo.gl/MsnXu It was literally 25 messages into the discussion that I realized “data model” was being used in two distinct ways in the discussion. And even then it had to be pointed out by a participant who seemed to know one of the other people.
  • I always mean “data model” in the ‘old’ way, in which the data model supports real-time business operations (or close thereto). In that world, you must design for integrity, which generally means ‘highly normalized’ in the relational sense.
  • In the old-but-not-nearly-as-old world of OLAP, real-time operations and updates are not a concern, so de-normalization (and redundancy) are presumably acceptable. (I’ll leave that question to the experts.)
That’s always the problem with vocabulary – deeply buried assumptions that prevent you from hearing what you need to hear. From experience, I know the trap oh-so-well, but here I fell right into it myself. What’s the answer to the question I posed for “data models” (of the kind I meant)? Focusing on the meaning and structure of business vocabulary, not data, as a core part of business analysis.  Note to self (a rule): When you enter any discussion, be clear what you mean by the terms you use – even (and maybe especially) the ‘obvious’ ones.

Continue Reading 2 Comments

Business Rules & Events: Two Questions for Zachman re: 3.0

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

Continue Reading 2 Comments

Zachman 3.0 Announcement – Our First-Look Notes Part 2

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.

 

Continue Reading

Laws of Commerical Semantics … by Curt Monash

Ever suspect a high B.S. factor in the categories vendors use for their products? Wait, let me ask that differently: Has anyone not suspected a high B.S. factor in the categories vendors use for their products? I came across some older posts by Curt Monash that formalize the rules of software category B.S. I invite you to read them — good stuff. By the way, Curt Monash is an independent industry analyst I’ve greatly admired since his gutsy take-take of Cullinane some 30 years ago. [My comments in brackets.] Monash’s First Law of Commercial Semantics: Bad jargon drowns out good. “The idea behind the ‘Law’ is this:   If a term connotes some kind of goodness, marketers scarf it up and apply it to products that don’t really deserve it., making it fairly useless to the products that really do qualify for the more restrictive meaning. ‘Predictive analytics’ sounded cool, and now covers a fairly broad range of statistical analyses, most of which don’t involve any kind of explicit prediction.” [“Decision management” is already headed in the same direction … or worse.] http://www.strategicmessaging.com/monashs-first-law-of-commercial-semantics-explained/2009/01/09/ Monash’s Second Law of Commercial Semantics: Where there are ontologies, there is consulting. [Ooooh, the “O” word!] http://www.texttechnologies.com/2007/12/23/text-mining-myths-realities/ Monash’s Third Law of Commercial Semantics: No market categorization is ever precise. [This one is probably self-evident.] http://www.strategicmessaging.com/no-market-categorization-is-ever-precise/2011/03/01/ Most recently Curt invokes the Third Law for “Complex Event Processing” (CEP). He suggests that “Data Stream Management ” might be a better term. www.dbms2.com/2011/08/25/renaming-cep-or-not/ Although possibly on-target for current products and their technical orientation, I disagree with him here in the bigger picture. Events are simply a different primitive than what data represents (things). So the suggested name takes the focus off-target. Perhaps “Event Stream Management” would be better. Why does this interest me? Sooner or later, techniques and tools for business analysis need to come to grips with business events. This focus is essential for truly supporting business rules and know-how management. “Events” belong right up there with the other five primitives: things, processes, locations, roles, and goals. (Yes, there’s six — it’s a Zachman view.)

Continue Reading 1 Comment

Zachman Framework 3.0 Announced Tues, Aug. 23 … Quick Notes

Here’s a zipped pdf of the new 3.0 version of the Zachman Framework (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!  Our Editor for BRCommunity.com, Keri Anderson Healy, attended the announcement event – she reports an excellent turnout. The following are some quick first-look notes from Keri (my own comments appear in brackets). 
  • The Framework has a new subtitle: The Enterprise Ontology (TM). Zachman considered changing the main title word “Framework” to “Ontology” but decided to stay with the former. 

[Keri and I both think that was a good decision.]

  • Some new terms appear as replacements, aiming to better convey the ‘business’ message. Zachman explains:

“Because I came from an ‘information’ community I had initially used words like ‘data’ in column 1. Big mistake!  People thought the Framework was about IT! The first thing people saw was the word ‘data’.

[The Framework has always been about business engineering – that was clear even from the earliest talks I heard Zachman give in the late 1980s and early 1990s. In truth, I would have never guessed it would still be an issue 20+ years later.]

  • Faint grey lines now appear crossing column boundaries in a row. These new connections better convey that the Framework supports two kinds of models: engineering (the primitives) and manufacturing (the composites).

The Framework is well-known for its depiction of the engineering primitives (the columns, which are normalized – one thing in one place). The engineering models, however, don’t do anything in and of themselves. The enterprise also needs its manufacturing models – the composites. So these new faint gray lines have been added as a reminder that the composite models also exist and they are also important.

Note: These new faint gray lines are meant as ‘for example’ connections. In this sense they are like the examples shown in the Framework for the primitives in the columns.

  • Adjustments have been made to row 6 to better convey what it is about. In early versions of the Framework graphic, row 6 was depicted as just a sliver. It has always been ‘the enterprise’. Row 6 is different in nature from the five rows above it, which are engineering specifications for things in the enterprise, rather than the actual things themselves     
  • The rows are now color-coded and each cell icon reflects the color theme of its row. At the request of various Framework users, however, the background coloring has been removed from the cells of rows 1-5 so users can annotate their own specifics over the cell graphics.      
  • For rows 1-5, the color progression is red, orange, yellow, green, blue. Rather than the next-in-series indigo, row 6 is color-coded orange emphasizing that it represents the realization of what row 2 specifies.

[The row 2 / row 6 alignment is consistent with the business-engineering theme that Zachman so ably promotes.]

Continue Reading 21 Comments

Are writing skills passe? … Not!

In the new age of social media (and the mature age of email) you might be led to believe that good writing skills are no longer a matter of real concern. At the risk of sounding old-fashioned, I beg to differ … strongly. In fact, I would argue that good writing skills are one of the top 3 or 4 skills Business Analysts should have, right alongside analytical, abstraction, and people skills. Put simply, poor writing skills are one of the top reasons for ambiguity and miscommunication in written requirements, a major concern everywhere I go. A commenter on one of the forums asked “The last time you hired an analysis, did you test their ability to take a concept and specify it in a way that is unambiguous? That’s a special talent that may be overlooked at the time of hiring sometimes.” Just sometimes?!? I don’t necessarily mean English majors. I mean people who can write clearly about structured or technical subjects … and who can be consistent about the meaning of the words they use. Why aren’t universities producing more of that kind of person? What aren’t companies more careful about cultivating that kind of person? From my work on standards (SBVR), I can tell you that writing skills will become more and more important as time goes by … whereas programming skills … well, we pretty much know where those jobs are headed (if not there already). don’t we?

Continue Reading 3 Comments

Moving the Goalposts for Data Modeling … Deliberately. Hey Guys, We’re in a Knowledge Economy.

Is there any proven way to demonstrate data models are correct, complete, and stable with respect to the operational business and its needs? No. That’s distressing.  Is there an alternative that does? Yes, fact modeling, which is to say structured business vocabularies (concept systems). The core concepts (fact model) of an operational business area are very, very stable. I have outstanding proof (short case study).  See: http://www.brcommunity.com/b594.php. Definitely worth a quick read. I recently made these statements in a data modeling forum, and a practitioner came back with this: “Even if we assume that a technical methodology might exist to generate a complete and correct data model from a set of articulated business rules / facts, IMO this approach just moves the target from the data modeling area to the need to verify the articulation of business facts / rules for completeness and correctness.” Missed the point. Concept anaysis is brain work. You’ll never generate a ‘complete and correct data model’ … you must create it … ith business people and SMEs. The problem with data modeling as practiced today is that there is a large gap between the business view of things and the data model. It gives business-side people a ready excuse to drop out. And its an art rather than a science. You really have no justification building a system until you have a concept blueprint. Currrent data models evolved bottom up, from database design. (I know, I watched it happen. I was editor of the Data Base Newsletter, 1977-1999.) It’s time to approach the problem top-down. There are natural ways to build concept systems. The standard for the new approach is SBVR. (For more, see BRCommunity’s “SBVR Insider”), which in turn is based on ISO 1087 and 704.  We (all of us) need to start practicing like we’re living in a knowledge economy … which in fact we actually already are.

Continue Reading

To: Business Process Manifesto … From: Business Rules Manifesto … Re: How Business Processes and Business Rules Relate

When the Business Rules Manifesto was published in 2003 (http://www.businessrulesgroup.org/brmanifesto.htm), I co-proposed the six items below related to business processes as an additional (eleventh) Article. The Business Rules Group (BRG) decided (probably wisely) to avoid that potentially controversial area, however, and concentrate on the core message of business rules. Since a Business Process Manifesto has been in the works, it’s worth going back over the proposed items. I believe they remain valid. So I dug them out of my Editor archives, cleaned them up a bit, and presented them below. Aside: In 2003 the BRG wasn’t careful about saying “business rule” (instead of just “rule”) and business process (instead of just “process”). But that’s what we meant – real-world rule and real-world process – not technical specifications. I’m very careful about that clarification these days. A great many people have a hard time seeing the difference. Item 1. Business rules guide business processes.

Comment: If this one is not self-evident, all bets are off.

Item 2. Business rules should be substituted for any activity in a business process where the result(s) of that activity can be produced by the business rules.

Comment: This item refers to what SBVR calls definitional rules – business rules that can derive, classify or compute something. For any given ‘something’, there might be only a single business rule, or a very large number of business rules. The ‘something’ could be an operational business decision requiring many dozens or hundreds of decision rules organized into decision tables.

One thing the item doesn’t say is that not all such ‘somethings’ need to be supported by business rules from the very beginning. In fact as Item 8.5 says, they don’t need to be. Business rules are very good for incremental development. (Development of what? Smart business processes.)

Item 3. Business rules can cause business processes to be initiated under appropriate circumstances.

Comment: Circumstances can arise that require the business to respond in a pre-scripted manner – e.g., low inventory status, potential fraud or intrusion, etc. Some business rule(s) should identify the circumstances involved in such ‘spontaneous’ business events.

Item 4. The default explanation or message for any error that occurs in a business process for a business reason is a business rule.

Comment: This item is truly ground-breaking. Business rules express the do’s and ‘don’ts’ of business activity; therefore, any error that occurs under a business process for a business reason is ‘explained’ by a business rule. What else could it be?!

Keeping systems carefully aside, and noting the obvious possibility of providing additional or alternative ‘explanations’, I like to say ‘the business rules are the error messages’. By the way, I’ve been saying that since 1994 – I have the slides (transparencies actually) to prove it. If you have doubts about this item, please provide examples(!).

Item 5. Any delay in the ability to enforce a business rule must be coordinated with business processes.

Comment: In SBVR, behavioral rules are business rules that can be violated. (Definitional rules can’t be.) An example where such delay might occur is a business rule that requires an approval or sign-off on something (e.g., an extra-large order on credit) by somebody (e.g., the branch manager) who is not immediately available. The business process for that particular something must be suspended until some future time.

Note: Additional business rule(s) providing appropriate suspense criteria (e.g., 24 hours) would be wise in such cases. We don’t want an order sitting in limbo forever(!).

Item 6. Business rules cannot constrain the workings of a business process directly, but only the following: (a) the state required for the business process to be performed; (b) the state while the business process is being performed; and (c) the results – that is, the state – the business process seeks to leave behind when finished.

Comment: I think of a business process as being like a black box with respect to business rules. The business rules cannot and should not ‘look’ inside. Instead, all matters of state should be externalized so business rules – and business people – can know it and talk about it. Get ready for this: This item indicts BPMN with its token-based approach to process state. The future lies with externalizing semantics. Sorry guys!

Continue Reading 24 Comments

A Rigorous Definition of Fluff … Good Thoughts on Strategy for Business Solutions (and Other Things)

I always thought my business partner, Gladys S.W. Lam, pioneered use of the word fluff for all things superficial, especially in written material. She uses it well and often (for example, she might very well use it for these very words). However, now there is evidence of other expert users of the word.  Just to be sure of the meaning of fluff:  [MWUD 2b]: something essentially trivial and lacking importance or solid worth.  In Good Strategy Bad Strategy The Difference and Why It Matters by Richard Rumelt (Crown Publishing, a division of Random House Inc., New York, NY, 2011) fluff is described (p. 32) as “… a form of gibberish masquerading as strategic concepts or arguments. It uses ‘Sunday’ words (words that are inflated and unnecessarily abstruse) and apparently esoteric concepts to create the illusion of high-level thinking.”  Rumelt makes some excellent points. About business risks he says (p. 42): “If you fail to identify and analyze the obstacles, you don’t have a strategy. Instead, you have either a stretch goal, a budget, or a list of things you wish would happen.” Good stuff!  What do you need to be successful with strategy? Rumelt (p. 268) says: “you must cultivate three essential skills or habits. First, you must have a variety of tools for fighting your own myopia and for guiding you own attention. Second, you must develop the ability to question your own judgment. If your reasoning cannot withstand a vigorous attack, your strategy cannot be expected to stand in the face of real competition. Third, you must cultivate the habit of making and recording judgments so that you can improve.”  A Policy Charter is the deliverable in our methodology Proteus used to lay-out the elements of strategy and their motivation (know-why). By the way, did you know that know-why is actually in the dictionary? I’m not sure I actually know why.  How do you distinguish between good business strategy and bad business strategy? (Rumelt doesn’t say anything about ugly strategy, as far as I know.) He says (p. 20)“good strategy requires leaders who are willing and able to say no to a wide variety of actions and interests. [I like that!] Strategy is at least as much about what an organization does not do as it is about what it does.” He also explains (p. 243) that “good strategy is, in the end, a hypothesis about what will work. Not a wild theory, but an educated judgment. And there isn’t anyone more educated about your [business] than the group in [the] room.” Exactly right.  Rumelt says bad strategy (p. 32 ) “… is not simply the absence of good strategy. It grows out of specific misconceptions and leadership dysfunctions. To detect a bad strategy, look for … Failure to face the challenge. … When you cannot define the challenge, you cannot evaluate a strategy or improve it. Mistaking goals for strategy. Many bad strategies are just statements of desire rather than plans for overcoming obstacles.” Bad strategy “… is long on goals and short on policy or action. … It uses high-sounding words and phrases to hide [its] failings.”  He means (and says) fluff.

Continue Reading

Our Clients

[cycloneslider id="our-clients"]