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


We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

I Wrestle with a LinkedIn Business Rule … Find Out Who Won

The subtitle of my Business Rules Concepts handbook (now in its 3rd edition) is ‘Getting to the Point of Knowledge’. I wasn’t trying to be cute, I meant it literally. Here’s an example. Try entering a URL in a LinkedIn invitation. I don’t know if it’s a new business rule or not, but I tried it for the very first time just the other day to point someone in the right direction on an EA question. Not allowed. I didn’t know that. I was informed and now I’m a wiser member of the social community. This is an example of what in our new book ‘Building Business Solutions: Business Analysis with Business Rules’ (Oct, 2011) we call real-time business operation systems (BOS). It takes a just-in-time (JIT) approach to the delivery of know-how. (A business rule always encodes know-how.) In my LinkedIn experience I was informed of the latest business rule in-line in a self-service, JIT manner. Violate business rules (the latest one or any of them) and if you’re authorized and capable, you’ll get back a ‘training’ message. Here’s what LinkedIn said back to me: We’re sorry, you cannot include website addresses in invitations. Please remove the website address and try again. Here’s a more direct statement of the business rule in RuleSpeak: A LinkedIn invitation must not include a URL. The RuleSpeak version conveys the same information as the LinkedIn message, just more succinctly. As I’ve been saying since at least 1994, the business rule statement is the error message. It’s the error message from a business, not system, point of view. That’s why it’s called a business rule. If you do want a friendlier version (as LinkedIn did) that’s fine. Think for a minute about your operational business processes. Many of your business rules either change frequently, unexpectedly or both. How can you keep all your operational staff up-to-speed? Constantly send them off to training classes?! Flood them with tweets or e-mails?! Not going to work. In a world of constant change, a system is not state-of-the-art unless it addresses continuous re-training. Business rules do. Ultimately there’s no alternative. I’ve been saying that for a long time too.

Continue Reading

Business Analysis & Business Rules – Announcing Our New Book and BBC 2011 Conference – **Special Discounts** for Friends and Colleagues

Let me mention two important things happening soon and special discounts for them – Both discounts good only through **Friday, September 30**   1. ANNOUNCING OUR NEW BOOK … Coming in October! BUILDING BUSINESS SOLUTIONS: BUSINESS ANALYSIS WITH BUSINESS RULES … an IIBA Sponsored Handbook (304pp) … It’s all about taking Business Analysis to the next level of capability.  http://www.brsolutions.com/bbs >> Receive 25% off the book’s list price of $39.95 if you pre-order now. Use discount code **BBS1001**.  2. BUILDING BUSINESS CAPABILITIES CONFERENCE (BBC 2011) … Oct. 31 – Nov. 3, Ft. Lauderdale, FL  http://www.buildingbusinesscapability.com/  The must-attend conference of the year covering all things ‘business’.  Four conferences in one for a total of 9 tracks on pace this year to be a sell-out!  >> Receive a 15% discount on registration. Use discount code **RRBBCFL**.  * Business Analysis Forum, the Official Conference of the IIBA. http://www.buildingbusinesscapability.com/baf/ * 14th annual Business Rules Forum Conference. http://www.businessrulesforum.com/ * The 1st annual Business Architecture Summit. http://www.buildingbusinesscapability.com/bas/ * The Business Process Forum. http://www.businessprocessforum.org/

Continue Reading

Why Your IT Project May Be Riskier Than You Think

Several comments on a must-read HBR article for an organization considering any IT project of significant size …. Why Your IT Project May Be Riskier Than You Think by Bent Flyvbjerg and Alexander Budzier  Harvard Business Review – September, 2011 http://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/ar/1 I found several points in this article particularly insightful:   1. “As global companies become even more reliant on analytics and data to drive good decision making, periodic overhauls of their technology systems are inevitable. But the risks involved can be profound, and avoiding them requires top managers’ careful attention.”   >>I’m afraid the large majority of IT professionals don’t really get this … even if they say they do. Prevalent IT requirements methodologies don’t address it well at all. It’s essential that the approach a company takes involves business people to develop business solutions based on business goals before creating system designs. There’s a business problem first, then and only then a technology problem.   2. “Insufficient procedures for financial reporting and internal controls …” >>We see this time and time again as IT designers create very ‘open’ designs that are not based on a common set of business concepts and do not embed a common business perspective. The inevitable result — “revenue leakage” … and as this article points out, much worse. Again, there’s a business problem first, then and only then a system problem. 3. “When we broke down the [IT] projects’ cost overruns, what we found surprised us. The average overrun was 27%—but that figure masks a far more alarming one. Graphing the projects’ budget overruns reveals a “fat tail”—a large number of gigantic overages. Fully one in six of the projects we studied was a black swan, with a cost overrun of 200%, on average, and a schedule overrun of almost 70%. [Only one in six? I think that figure is too low!] This highlights the true pitfall of IT change initiatives: It’s not that they’re particularly prone to high cost overruns on average … It’s that an unusually large proportion of them incur massive overages … By focusing on averages instead of the more damaging outliers, most managers and consultants have been missing the real problem. ” >>The point is simply that IT ‘change initiatives’ are risky propositions, and need to be addressed with … what else … upfront business strategy. That’s what we call a Policy Charter, and we’ve been guiding organizations through its creation for more than a decade. Doesn’t take that long … if you have the right people and the right motivation. Skip it … and pay the consequences!

Continue Reading

Requirements are Rules: True or False?

This is an excerpt from our new book: Building Business Solutions: Business Analysis with Business Rules coming out in October. Watch for it! “Requirements are rules.” Perhaps you’ve heard the argument. Maybe you’ve even made it yourself. Are they? No! Basic reasons why requirements are not rules:  Business people don’t naturally think of a ‘requirement’ as a ‘rule’. To ensure the best possible communication with business people, use of ‘rule’ should remain consistent with the real-world understanding of ‘rule’. Say ‘rule’ to business people and they will naturally think “guide for conduct or action” or “criteria for making judgments or business decisions.” If a business person says ‘rule’ he/she almost certainly means a rule for the business (e.g., no shirt, no service), not ‘requirement for a software system’. Many ‘requirements’ never become rules. The “no shirt, no service” rule doesn’t happen to be automatable (at least easily). Many other rules of the business are – e.g., no credit card, no sale. When interpreted into an implementation form, the business rules ideally should still be recognizable as a form of rule. The same cannot be said, however, for other aspects of a business model, say processes. In designing a business process for implementation, why would you ever say, “Now it represents rules.”?! Rules are rules, processes are processes, locations are locations, people are people. Each can be cast into some design-level counterpart (e.g., GUIs can substitute for face-to-face communication between people.) Nonetheless, each retains some sense or reflection of what it was originally (or should anyway). Looking at operational business design any other way inevitably leads to a break-down in communication and needless complexity.  Avoid confusing business people or IT professionals – or yourself – by calling requirements ‘rules’. Requirements are not rules! But Are Business Rules ‘Requirements’?? Clearly, requirements are not rules. What about the reverse question? Can it be helpful to think of business rules as requirements? To answer it’s essential to keep in mind what business rules are about. In plain English, business rules are about guiding and shaping day-to-day operations of the business. Business people would need business rules to operate the business even if there were no systems. The business rules just are what they are. And if well-specified, they essentially speak for themselves. All the following, though, are certainly true about business rules:
  • They should arise from, or at least be approved by, business people.  
  • They should be considered very carefully in designing a system.  
  • They should be automated whenever possible.
All said and done, whether business rules are a form of requirement is really a judgment call. The best answer is whichever is likely to prove most productive for your work.

Continue Reading 4 Comments

HarvardBiz and Use Cases?!? Yes, Seriously … And Seriously Misguided!

HarvardBiz  The Case for Starting a Design Revolution http://s.hbr.org/nXsdOk
This article is fundamentally misguided. I’m surprised to find such an article associated with HBR. Use cases are about designing systems, not developing business solutions for business problems.
All change initiatives should start with a clear, structured view of business goals and business risks, and what business policies and business tactics will best solve the business business problem. I’m talking, of course, about business strategy. That’s the conversation that business leads want to have. Get them engaged in a discussion of system interaction and GUIs and you’ll inevitably miss the big picture.
What if your business *is* about eCommerce? No matter, you still need thought first given to business strategy — the goals, risks and policies needed for a winning business solution. Good requirements will flow naturally from that base. This have always been a notoriously weak area of IT requirements methodologies. Just don’t believe IT professionals who say use cases will solve your business problems. Design attractive systems, yes (done correctly). Guarantee business success? You’re counting on nothing more than good luck.

Continue Reading 5 Comments

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

What vs. How … Could We Get This Straight?

Some professionals view the interrogatives what and how as peers, each addressing a distinct area of engineering solutions (e.g., designing systems). Other professionals characterize ‘requirements’ as the what, and the design for a system as the how. Contradiction? No, just a bit of confusion over perspective. 
  • From the perspective of designing a system, both what (data) and how (processes) must be addressed. Both interrogatives (as well as the other four – where, who, when, and why) are essential for engineering a complete, robust solution.  
  • From the perspective of IT methodologies, requirements are always incomplete, so what the requirements say must be transformed into a system model that indicates how the requirements will be supported. 
In other words, the former use of what and how is based on an engineering point of view; the latter use is based on an IT-methodology point of view. Don’t confuse business people or IT professionals – or yourself – by failing to make the distinction.

Continue Reading