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


We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Business Model vs. System Model: eCommerce

In yesterday’s post I talked about the difference between business models and system models: http://goo.gl/CMMPi  To make a long story short, business models talk directly about real-world things (as business people do); systems models talk about surrogates for real-world things (as system designers do). Not the same thing! Some people argue that the separation between business model and system model blurs in eCommerce. Does it?  No.  If business leads see or define ePersons (for example) as real-world, then real-world they are. To ensure you have a winning business solution, the ePersons should be defined and shaped within a business model.  Afterwards comes design of a computationally-competent system model so you can conduct actual business with those ePersons.

Continue Reading

What’s the Difference Between Business Requirements and Functional Requirements?

We’re teaching our online training course next week: Business Analysis with Business Rules: From Strategy to Requirements. http://goo.gl/Vnko3 Hope to see you there! Naturally, we’ll be talking a lot about business requirements. Are business requirements the same as functional requirements? No! Functional Requirement vs. Business Requirement Wikipedia describes a functional requirement as … “a requirement that defines a function of a software system … what a system is supposed to accomplish” [emphasis added] We define a business requirement as … “something called for or demanded by a business model that a system model must support” That’s a big difference! Appreciating the importance of the difference, however, requires clear understanding of the distinction between business model and system model. Business Model  We define a business model as follows[1]a blueprint for a business capability based directly on real-world things and ideas strictly named and represented using words natural to business people We stress that business people talk about real-world things! And why should we ask them to do any differently?! A business model enables business people and Business Analysts to engage in discussion about what needs to be created, managed, operated, changed, and discontinued in the business in business terms.  Developing a business solution using a to-be business model does not necessarily imply software development, but if software development does ensue (as it usually does) the business model provides a solid grounding. Examples of business models include strategies for business solutions (Policy Charters), business process models, structured business vocabulary (concept models), business milestone models, and Q-Charts (for decision analysis). Any business model is always subject both individually and collectively to the business rules specified for it(!) We believe business rules are key to creating effective business requirements. System Model We define a system model as follows … a model that provides a design for an automatable system that is computationally competent For many years John Zachman, creator of the Zachman Architecture Framework, has explained that a business model is always about real-world things.  These real-world things are as the business leads see or define them.  That idea is actually his, not ours. Zachman describes a system model, in contrast to a business model, as comprising “… surrogates for the real-world things so that the real-world things can be managed on a scale and at a distance that is not possible in the real world.”  Surrogates include …
  • data entities or business objects in place of real-world things.
  • GUIs and use cases in place of face-to-face, real-world communication.
  • network nodes in place of real-world locations.
  • system events rather than operational business events.
  • etc.
If you are developing ‘requirements’ using use cases, you are actually designing a system (creating a system model), not defining business requirements(!). We believe a focus on use cases with no prior business model puts your project at grave risk.
[1]Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, 2011, 304 pp.http://www.brsolutions.com/bbs

Continue Reading

Business Agility vs. Agile in Software Development: Not Related!

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  

Continue Reading 1 Comment

Batting 1000 on Amazon: Our New Book “Building Business Solutions: Business Analysis with Business Rules” Hits Eight 5-Star Reviews (of 8) on Amazon

Our new book has been extremely well received this far – very gratifying. See the Amazon reviews: http://goo.gl/8lk4u and more comments: http://www.brsolutions.com/b_building_business_solutions_reviewers.php Two reviewers, George McGeachie and Maria Amuchastegui, made same criticism, both giving the book a 5-star rating anyway. So let me clarify. George McGeachie wrote: “The point about business rules and deployment is made on page 9, where you say that requirements evolve before deployment, and business rules evolve after deployment. In reality, I would expect business rules to evolve alongside requirements, and continue evolving after deployment.” We were trying to make a simple point. This time the point was perhaps expressed too simply. A full expression of what we meant to say would be: “A great many business rules exist before requirements, some business rules evolve alongside requirements. Unlike requirements, however, business rules continue to evolve after deployment – sometimes quite rapidly.” Elsewhere in the book we express the idea that your business would need its business rules even if it had no software at all. I think that implies many (probably most) business rules do exist prior to requirements. But thanks George and Maria – point taken.

Continue Reading 1 Comment

How Important is Basic Business Vocabulary? … A Short (True!) Story

Guest Post I was teaching a BA class, trying to convey the value of having a prototype. The class was divided into ‘developers’, the BA, and the ‘executive’. The developers were given a bag of duplos, multiple shapes and colors. The executive was given a bag with a completed duplo creation. The instructions were for the BA to elicit information from the executive and provide it to the developers so they could build the creation. What I discovered is that they needed a common language (terms everyone knew the meaning of), and a frame of reference (location, name of layers or identity of corners, etc.). Without this information, communication was impossible.  After they created these ‘handles’, they were able to communicate and convey information. The value of having a prototype was demonstrated.  The value of common terms and clear understanding was priceless! ~~~~~~~~~~~~~ Acks: Thea Rasins Consultant, Educator and Professional Organizer KCIIBA Board Member and Vice President of Professional Development

Continue Reading 1 Comment

Why So Much Ambiguity and Miscommunication in Requirements? … Something We’ve Learned from Business Rules

Let me share something we’ve learned from our work on business rules. The world’s leading cause of ambiguity in expressing business rules is missing verbs. Stay with me now. Consider this sample business rule: An order must not be shipped if the outstanding balance exceeds credit authorization. As a first-cut statement, that’s perhaps not bad. The more you read it, however, the more ambiguity you’ll find. Clearly, important ideas are hidden or missing. For example: The outstanding balance of what? …order? …customer? …account? …shipment? The credit authorization of what? …order? …customer? …account? …shipment? The hidden or missing ideas are all verb-related. To eliminate the ambiguity, the relevant verb concepts (called fact types in fact modeling) – must be discerned; then the original business rule restated. Suppose the relevant verb concepts can be worded: customer places order customer has credit authorization customer holds account account has outstanding balance Using RuleSpeak (www.RuleSpeak.com – free) the business rule can now be restated: An order must not be shipped if the outstanding balance of the account held by the customer that placed the order exceeds the credit authorization of the customer. Although the resulting statement is a bit wordier, it is far less likely to be misunderstood, misapplied, or mis-implemented. It is now enterprise-robust. The key insight: Wordings for relevant verb concepts should always appear explicitly in expression of business rules. For that matter, wordings should appear explicitly in any form of business communication you want to be understood correctly – including IT requirements. Note: You probably noticed use of the preposition of in the revised business rule. Stand-in prepositions for verb concepts are considered lazyman’s verbs. (Literally, you can’t make complete sentences with only prepositions!) Yes, you can use a preposition to stand in for a full wording, but do so with caution. As a rule of thumb, prepositions are safe only for two cases: (1) properties – e.g., credit authorization and outstanding balance as above. (2) role names – e.g., owner as in the earlier example, owner of a vehicle. ~~~~~~~~~~~~~~  This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php    

Continue Reading

Requirements and Business Rules … All Just a Matter of Semantics (Really)

It almost goes without saying (but I’ll say it anyway) that you must know exactly what the words mean in all parts of your business requirements. In running a complex business (and what business isn’t complex these days?!), the meaning of the words can simply never be taken as a ‘given’. Some IT professionals believe that if they can model the behavior of a business capability (or more likely, some information system to support it), structural components of the know-how will somehow fall into place. That’s naïve and simply wrong. Business can no longer afford such thinking. A single, unified business vocabulary (fact model) is a prerequisite for creating a scalable, multi-use body of business rules – not to mention good business requirements. It’s what you need to express what you know precisely, consistently, and without ambiguity. Certainly no form of business rule expression or representation, including decision tables, is viable or complete if not based on one. And I pretty certain that’s true for most other forms of business communication about day-to-day business activity too. What am I missing something here?  ~~~~~~~~~~~~~~~~~~~~~~~~~~ This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php

Continue Reading

Is Agile Development of Business Rules Possible? … And What Would You Call It If It Is?

I’ve been exploring the meaning of ‘agile’ with respect to business rules. In our new book, we say:

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

In response, a practitioner made the following deeply insightful observation about agile development of business rules.

Practitioner: “My perception of the intent of agile software development is to try to have the underlying development process track better to the realities of the business process change. Rather than the good old days where the specification and implementation of the solution ran so long that the problem trying to be solved had changed so much that the delivered solution was irrelevant.  So, if you reach a point where ‘The only constraint is how long it takes business leads and Business Analysts to think through the change’, then, to me, you are already doing agile development.”

Just to clarify: Our underlying assumption is that business policy and business rules can be and should be specified and analyzed independently of traditional software requirements (i.e., functional and non-functional requirements). That’s rule independence as the Business Rules Manifesto calls it. Business rules can and should have an independent life cycle. Then yes, there could be two kinds of ‘agile development’. Agile development of business rules and agile development of software. (I’ll leave it to others to decide whether agile development of requirements makes sense.) But here’s the rub: If you did reach the point where ‘the only constraint is how long it takes business leads and Business Analysts to think through the change’ in business rules – and I do believe that’s possible – business managers almost certainly wouldn’t (and shouldn’t) call it ‘agile development’. That’s an IT buzzword. When you talk about development of business policy and business rules, you are really talking about governance. Here is the Merriam-Webster Unabridged definition of “govern” …

1a: to exercise arbitrarily or by established rules continuous sovereign authority over; especially : to control and direct the making and administration of policy in

Note the prominent appearance of ‘rules’ and ‘policy’ in that definition. Hey, I didn’t make it up, it’s right there in the dictionary(!). So the bottom line is this: Instead of ‘agile development’ of business rules, at that point I’d say you’d be talking about agile governance. Indeed, I believe that’s exactly what we’re getting at here. Very exciting once you see it! ~~~~~~~~~~~~~~~ Our new book (Oct, 2011): Building Business Solutions: Business Analysis with Business Rules – See:  http://www.brsolutions.com/b_building_business_solutions.php By the way, we call the “it” in “… once you see it” an elephant. Have a look at the book to find out why.

Continue Reading 1 Comment

Why Don’t Requirements Approaches and IT Methodologies ‘Get’ How to Use Strategy as a Technique? … Not Acceptable!

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 Ruleshttp://www.brsolutions.com/b_building_business_solutions.php.

Continue Reading

Just Organizational or Application Silos? … Worse, You Have Semantic Silos

Difficulties in communicating within organizations are by no means limited to communications among business workers, Business Analysts, and IT professionals. In many organizations, business workers from different areas or departments often have trouble communicating, even with each other. The business workers seem to live in what we might call semantic silos (reinforced by legacy systems).  A well-managed, well-structured business vocabulary (fact model) should be a central fixture of business operations. We believe it should be as accessible and as interactive as (say) spellcheck in Microsoft Word. Accessible business vocabulary should be a basic element in your plan for rulebook management, requirements development, and managing know-how.  ~~~~~~~~~~~~~~~~~~~~~~~~~~  This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php    

Continue Reading