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

What is a ‘Business Capability’ … And Can It Be Part of a Business Architecture Methodology?

Suppose you wanted to make ‘business capabilities’ the centerpiece of a business architecture methodology. Could you go out into the business and find existing ‘business capabilities’ in some form? Would a focus on business capabilities help you better design the business as a whole? My answer is at this point in time is … well … I dunno. I’m looking forward to the new Business Architecture Summit (http://www.buildingbusinesscapability.com/bas/) at the BBC2011 Conference (http://www.buildingbusinesscapability.com/) the first week of November to shed some light on the matter. There’s going to be some real excitement at the Conference this year on that topic! Here’s our current thinking on the term ‘business capability’ … An IT project always delivers a system and/or database and/or rulebase. But let’s say you want to take a business-oriented approach to solving some problem in business operations. The solution will probably involve significant (re-)automation – but not necessarily. The main focus is finding a winning business solution. What would you call what you deliver as an end-result from such an initiative? Unfortunately, there’s no generally accepted business name for such end-results. In our new book coming out this month – Building Business Solutions: Business Analysis with Business Rules (http://www.brsolutions.com/b_building_business_solutions.php) – we call them simply ‘business capabilities’. Any given business capability is likely to include business processes, business rules, business vocabulary, business roles and more. And it should also feature key performance indicators to measure continuing alignment with business goals.  So my bottom line is this: I know it when I’ve created a business capability, but I’m not sure I would know one beforehand. I’ll let you know if anything I hear from this post or at the Conference changes my mind. Please jump in!

Continue Reading 8 Comments

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

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

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

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

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

Business Capability … You Have to Know in Order to Do

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?

Continue Reading

Now the Shoe’s on the Other Foot … But the Foot’s Not Mine

Many years ago I was flying home after giving a talk at a conference in Boston. It was Friday and I was really tired. Fortunately, I got upgraded to first class, so I slipped off my tie and my shoes (brown), pushed the seat back, and went into a plane stupor (a zombie-like, non-sleep state).  About halfway home my feet started getting cold. Absent-mindedly, I felt around on the floor with my feet for my loafers. I quickly found one and slipped it on. But the other one eluded me. If you travel much on planes, you soon learn that shoes and other personal items get annoyed when unattended and purposely hide in the most inaccessible places possible. All you can do is tolerate the behavior.  I redoubled my efforts to find the missing shoe. I looked everywhere. No brown shoe. Oddly though, I did come up with a black shoe. I immediately did what any sensible person would do, I panicked. Had I been wearing different colored shoes all day long?! All week long!? What must the people at the conference and in my talk have thought?!   I calmed myself. Wait a minute, I was sure I had taken only one pair of shoes with me on this trip. Couldn’t be my shoe. A simple test would tell the tale, I could just try it on and see if it fit. So I did. And it fit perfectly.  Panic returns, decibels higher. My wife had helped me pack the bag. She would never have let me go off with unmatched shoes. Imagine the scene in my house if I walked in wearing shoes that didn’t match. (I’ll let you do the math on that.)  The plane began its initial descent and the man seated next to me stirred to go to the lavatory. Guess what?! Sure enough, one brown shoe and one black shoe. Now this was a situation I had never faced before. I certainly had no process laid out to follow or any experience to guide me. Exactly what are the best tactics for communicating to a perfect stranger he’s probably wearing your shoe?! Some options: 
  1. Make a joke of it. (Since he was wearing a wedding band, he probably didn’t want to go home wearing unmatched shoes either. Would he think it was funny?)
  2. Angrily demand my shoe back.
  3. Exaggerate my search until he asks what’s wrong or figures it out on his own.
  4. Tell him politely, but directly.
  5. Get up and ask a flight attendant to intervene
What kind of problem was this? It’s not about process; it’s about strategy. Don’t confuse the two; they’re very different. The key questions were (a) what were my goals (the ends I wanted to achieve), and (b) what course of action (the means) would best achieve those ends.  Clearly my basic goal was to possess my things. But there was certainly more to it; otherwise I could have just picked an option arbitrarily. So I must have had other goals (e.g., respect others), or perceived risks (e.g., escalation of a confrontation), or more likely, both. Perceiving risk(s), by the way, implies yet other goals (e.g., avoid entanglement with airline security).  Life (and business) is so complicated! Would a process model have helped? No! How likely was this scenario ever to happen again? In 35+ years of frequent travel, the scenario has happened exactly once. And I’ve never had anyone else tell me it’s happened to them. Instead, I needed to devise a strategy, one that best balanced trade-offs among conflicting goals.  Look for more from BRS on strategy in the near future. It’s one of the things we do – and we do it extremely well. A good place to start is with the standard: www.businessrulesgroup.org/bmm.shtml.  It’s an easy read and explains how business rules fit in. Business analysts need order-of-magnitude improvements in the techniques they use. Strategy is one.  How did my shoe saga turn out? Suffice it to say I got home with two brown shoes … and had a good laugh with John Zachman over dinner a couple of months later.

Continue Reading 4 Comments