John Matthias recently wrote this about our new book, Building Business Solutions: Business Analysis with Business Rules[1]:

“I especially liked the discussion about the mission and goals. I still see business process analysis in organizations I visit where the goals are not articulated well, and the results are not useful. (I’ve done it myself.) It’s easy to get lost among the trees, unaware of the contours of the forest or what direction you’re going.”

Indeed! That’s why we came up with the Policy Charter, which is the deliverable in our approach that lays out the elements of strategy and their motivation.  A Policy Charter is all about business goals, business risks, and business policies. It’s not about business process! [2] How do you distinguish between good business strategy and bad business strategy? Noted strategy expert Richard Rumelt distinguishes the good and bad as follows.[3] Good Business Strategy Rumelt, p. 20: “good strategy requires leaders who are willing and able to say no to a wide variety of actions and interests.  Strategy is at least as much about what an organization does not do as it is about what it does.” Rumelt, p. 243: “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.”  Bad Business Strategy Rumelt, p. 32: Bad strategy “… 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.”

Rumelt, p. 32: 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. The Three Skills of Good Business Strategy 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.”

Good stuff!

Business agility results when the IT aspect of change in business policies and business rules disappears into the plumbing.  All artificial (IT-based) production-freeze dates for deployment disappear and the software release cycle becomes irrelevant.  The only constraint is how long it takes business leads and Business Analysts to think through the change as thoroughly as they feel they need to. We define business agility as follows: being able to deploy change in business policies and business rules into day-to-day business activity as fast as business people and Business Analysts can determine the full business impact of the change and assess whether the change makes good business sense Agile in software development is an IT development method featuring rapid iteration and prototyping.  Agile methods and business agility have nothing to do with each other.  Agile in software development leaves off exactly where business agility picks up – at deployment. In working with clients we frequently come across systems that feature a very ‘open’ environment with few enterprise controls.  Typically, this ‘flexibility’ resulted from diligent efforts by IT to satisfy many stakeholders individually.  But the ‘flexibility’ is just an illusion.  The failure of business-side stakeholders to come together and develop a collective business solution before ‘agile’ software development commences can plague the company for years to come.  It reduces overall productivity, lowers customer satisfaction, and diminishes the capacity to make sound operational business decisions.  It makes apple-to-apple financial comparisons virtually impossible.  And it always costs a lot in ‘maintenance’.  There are simply no magic bullets for building business solutions! ~~~~~~~~~~~~~~~ Excerpted 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, 2011, 304 pp, http://www.brsolutions.com/bbs  

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.

An enterprise architect recently said to me, “The motivation (why) column of the Zachman Architecture Framework is the most underrated, underutilized construct in architecture.” Absolutely correct. Even worse, IT methodologies (that is, the people who create and use them) don’t realize how far afield they are on the matter. As a result they cause business people to focus on the wrong things … or to drop out entirely. Ironically, IT then becomes the impediment, rather than the solution, to much needed business innovation. A bit of background: The Business Rules Group (BRG – www.BusinessRulesGroup.org) identified the area of business strategy as a missing ingredient for business rules in the mid 1990s. In 2000, we came out with a standard for the area, now sponsored by OMG, called the Business Motivation Model. It’s a highly readable document with lots of good examples (and free): http://www.businessrulesgroup.org/bmm.shtml. It provides standard vocabulary and structure for strategy. Zachman, by the way, was a key participant. I am proud of my role as co-editor and author of the first working draft. My business partner, Gladys S.W. Lam, and I have just come out with a new book that explains how strategy (and business rules) can be an integral part of business analysis. It’s actually not that hard to do (if you have the right people, motivation, scope, and approach), and it doesn’t take all that long (ditto same caveats). Those are big myths. Gladys is generally given credit for some of the key ideas in the standard. She grew up in a highly entrepreneurial environment and has a natural sense of business risks and solution sinkholes. But I digress … See Chapter 4 of Building Business Solutions: Business Analysis with Business Rules – http://www.brsolutions.com/b_building_business_solutions.php.

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!

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/ * 14^th annual Business Rules Forum Conference. http://www.businessrulesforum.com/ * The 1^st annual Business Architecture Summit. http://www.buildingbusinesscapability.com/bas/ * The Business Process Forum. http://www.businessprocessforum.org/

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.

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?

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?