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

Addressing Business Complexity

complexity complicated-flows1[1]A large consulting company recently conducted an assessment of the IT development approach followed by one of our clients that uses our approach for business analysis with business rules. The consulting company judged the approach highly effective because the approach is ‘componentized’ (their description). 

The consulting company meant that business rules are viewed as a component; business processes are viewed as a component; business vocabulary is viewed as a component; etc. ‘Componentized’ may or may not be the right description, but the consulting company hit upon an important point.

Most IT methodologies for requirements development today make no attempt to examine the fundamental questions what, how, where, who, when, and why individually and selectively.  That omission is odd to say the least.  Those six questions are ones all of us ask and answer every day in real life.  The six question words are very basic to our language.

Instead, most methodologies today are centric.  They are process-centric or data-centric or user-story-centric or sometimes even rule-centric or decision-centric.  A centric approach requires force-fitting some or all elements of a solution into a single mold that distorts and submerges other elements.  Worse, a centric approach does little to avoid elements being neglected or omitted altogether.

Business problems are inherently complex and multi-faceted, as are their solutions. So we make every effort to ensure our approach to business analysis is well-factored and balanced – that is, non-centric – right from the start.

A non-centric approach doesn’t make developing winning business solutions harder, just the opposite. By addressing business complexity head on – as naturally factored in the real world – top-quality business solutions are far easier to attain.  Experience proves it time and time again.

~~~~~~~~~~~~

Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edition, by Ronald G. Ross & Gladys S.W. Lam, 2015

Get the book: http://www.brsolutions.com/b_building_business_solutions.php

Get the training: Instructor-led, online, interactive training: April 4-6, 2017 – Business Analysis with Business Rules: From Strategy to Requirements. http://www.attainingedge.com/online-training-business-analysis-with-business-rules.php

©Business Rule Solutions, LLC 2016. www.BRSolutions.com

Continue Reading

How Good Are You at Business Rule Analysis?

mowing-the-lawn[1]Can you understand that all three of the following business rule statements mean the same thing? Here’s what must be true: If you mow the lawn on Sunday your lawn mower is to be electric; otherwise the lawn is not to be mowed on Sunday.

1. It is permitted that the lawn be mowed on Sunday only if the lawn mower is electric.

2. It is prohibited that the lawn is mowed on Sunday if the lawn mower is not electric.

3. It is obligatory that the lawn not be mowed on Sunday if the lawn mower is not electric.

I’m fairly certain you can. And if you can determine they all mean the same thing, I contend a machine ought to be able to do so too. I mean as stated in this exact same human-friendly, structured natural language form. And tell you that the statements mean the same thing (in effect, that they are redundant). That’s the kind of language-smart (cognitive) capability that business innovators should be expecting – no, demanding – from software vendors.

P.S. In the OMG standard Semantics of Business Vocabulary and Business Rules (SBVR) the three statements are a restricted permission statement, a prohibition statement, and an obligation statement, respectively. You might prefer one or another of these forms of statements, but each is correct and reasonably understandable. Here are the RuleSpeak©[1] equivalents – even more friendly:

  1. The lawn may be mowed on Sunday only if the lawn mower is electric.

  2. The lawn must not be mowed on Sunday if the lawn mower is not electric.

  3. (same as 2)

~~~~~~~~~~~~~~~~~~~

Get trained: Instructor-led, online, interactive training: April 4-6, 2017 – Business Analysis with Business Rules: From Strategy to Requirements. http://www.brsolutions.com/services/online/strategy-to-requirements/

©Business Rule Solutions, LLC 2017. www.BRSolutions.com

[1] Free on www.RuleSpeak.com

Continue Reading

Deep Subject Matter Expertise Irrelevant – Agree/Disagree?

learningLet’s put you on the hot spot. You are forced to agree or disagree with the following statement, and defend your answer. What would you say?

Deep subject matter expertise is irrelevant for a business analyst, especially in agile business analysis.

Here’s how I answer: I disagree. How about you?

My reasoning: Actually I agree that deep subject matter expertise is generally irrelevant for a business analyst. Where I disagree (strongly) is that it’s especially true for agile business analysis.

Agile business analysis is no silver bullet. It doesn’t imbue you with magical powers to learn faster. Failing faster to learn faster is simply churn. There’s no end to it.

We’re missing the big picture. Exploring ‘deep subject matter expertise’ you’re not familiar with is a matter of having the right architectural tools to probe knowledge. It’s that deep operational business knowledge that makes subject areas hard.

So you simply need the right architectural techniques to map the knowledge of a domain explicitly. You need to be able to ask probing questions about the domain intelligently without wasting SMEs’ time.

The architectural techniques you need are true business rules and concept modeling (structured business vocabulary). By the way, business rules and concept models can be made to work equally well for both agile and waterfall – and anything in between.

~~~~~~~~~~~~~~~~~~~~~~

Mark Your Calendar: The annual Building Business Capability (BBC) conference is November 6-10, 2017 at the Loews Royal Pacific Resort, Orlando, FL. The BBC is the place to be for professional excellence!

Continue Reading

Agree/Disagree? Digital Mind Essential for Business Analysts

digital-mind[1]Let’s put you on the hot spot. You are forced to agree or disagree with the following statement, and defend your answer. What would you say?

The most valuable asset of a business analyst is a digital mind.

Here’s how I answer: I agree. How about you?

My reasoning: I almost certainly don’t agree with the statement in the way you think I might. It’s not the business analyst who needs a digital mind. It’s our machines that need the digital minds.

As we increasingly disintermediate customers and company workers, we will no longer have our workers in the loop to convey and apply operational business knowledge at the point of interaction to make things right. Machines will have to do that work. And those machines must be equipped with the knowledge to do so.

The key to launching us successfully into the digital age is setting up deep knowledge reservoirs in the company. Obviously, they will be digital.

The first and most basic step toward treating knowledge as a first-class citizen is true business rules. Business rules represent explicit operational knowledge. By the way, because of the need for compliance and traceability, business rules (think obligations) will never go away.

There are, of course, other ways in which knowledge can be applied to processes, ones where traceability and compliance aren’t so important – for example, machine learning and neural nets. Those technologies can also be used to build digital minds for your organization.

As a professional, how do you future-proof yourself? The secret is to make yourself indispensable both to the business and to machines in the business with digital minds.

Given that insight, what is the most valuable asset of the business analyst in the long term? It’s not agile, it’s not empowerment, it’s not even critical thinking. It’s the ability to communicate deeply and creatively using concise terminology about the problem space. If you’re still speaking in codes and data fields – in ITSpeak – I’m afraid you’re not on the critical path.

~~~~~~~~~~~~~~~~~~~~~~

Mark Your Calendar: The annual Building Business Capability (BBC) conference is November 6-10, 2017 at the Loews Royal Pacific Resort, Orlando, FL. The BBC is the place to be for professional excellence!

Continue Reading

Concept Model vs. Data Model

John Zachman says you can (and probably should) develop each of the following three kinds of artifacts to “excruciating level of detail”. 1. For the business management’s perspective (row 2), a conceptual model (roughly CIM in OMG terms). 2. For the architect’s perspective (row 3), a business logic design (roughly PIM in OMG terms). 3. For the engineer’s perspective (row 4), a class-of-platform design (roughly PSM in OMG terms). Because each is a different kind of model, there is a transform from one to the next. One implication is that it is possible to make a clear distinction between analysis (CIM) and design (PIM).   Another implication is that concept models and logical data models are clearly distinct. Unfortunately, many people blur the line between them. That’s wrong.
  • A concept model is about the meaning of the words you use, and the business statements you make assuming those meanings. It’s about communication.
  • A logical data model is about how you organize what you think you know about the world so it can be recorded and logically manipulated in a systematic way.
I started my career in data. It took me as much as 15 years of intense work on business rule statements (1990-2005) to fully appreciate the difference. But now I am very clear that concept models do need to be developed to excruciating level of detail in order to disambiguate the intended business communication. Most businesses don’t do that today. They jump in at data design (conceptual, logical or even physical). And they unknowingly pay a big price for it. By the way, a good concept model can be readily transformed into a first-cut logical data model – just as Zachman says. ~~~~~~~~~~~~~~~ www.BRSolutions.com

Continue Reading 1 Comment

Business Rules and the Design of Business Processes

Sample behavioral business rule: A customer that has placed an order must have an assigned agent. A practitioner wrote: In process design this means that an activity ‘Assign agent’ must happen before an activity ‘Take order’. My analysis: Here’s how behavioral business rules like this one should work according to standards[1]:
  • If the business rule is violated in performance of the process ‘Take order’, then the process (activity) ‘Assign agent’ should be (optionally) invoked automatically so the violation can be corrected immediately (by the appropriate actor).
  • In performance of the process ‘Retire agent’ (which hasn’t been mentioned!), if the business rule is violated – i.e., the retiring agent is assigned to some customer who would thereby be left agent-less – the process (activity) ‘Assign agent’ should be (optionally) invoked automatically so the violation can be corrected immediately (by the appropriate actor).
There’s one business rule, but two kinds of events (in separate processes) where the rule can be violated. I’ve literally looked at 10,000s of business rules. Probably 95% or more are multi-event like this, and therefore often multi-process. You can see from this example how easy it is for business analysts to completely miss the second event. My contention is that’s one big reason why systems today often give such inconsistent results – the other event(s) are overlooked or in another process altogether. Conclusions
  • It’s highly misleading to say ‘business rules are part of processes’. No, not really. (I run into that statement all the time.)
  • We’re not designing processes today in a very intelligent way. Designers shouldn’t have to think, ‘O.K., which process (activity) has to come first because of the business rules?’. That approach forces us into sequences where no natural sequence is meaningful. In any case there are far too many behavioral business rules for it to be practical.
P.S. If you think ‘decisions’ will fix this fundamental problem, sorry, but I’m afraid you’re in for a rude awakening! ~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com


[1]Semantics of Business Vocabulary and Business Rules (SBVR).

Continue Reading

Pleased to Announce Release of Our New Book Edition!

Building Business Solutions: Business Analysis with Business Rules (2nd Edition) … Just Out! http://www.brsolutions.com/b_building_business_solutions.php Get it on Amazon: http://goo.gl/HXxN1f What It’s About: How to develop business solutions working directly with business leads, create blueprints of the solutions, and then use those blueprints for developing system requirements. Engineering business solutions, not just requirements.We have applied the techniques described in this book successfully in hundreds of companies worldwide. Kind Words from a Practitioner: “We have based our whole business rules analysis practice on the methodology and techniques developed by the Business Rules Solution team. This book is an integral part of our practice. It’s an easy to read, useful guide with real life examples – we use it daily and couldn’t do without it!” – Michelle Murray, Inland Revenue Department NZ New in this Edition: How Business Architecture corresponds with your projects and requirements work. Developing a Concept Model and how it will help you. How business rules align with the new terminology in the recently released IIBA® BABOK® Guide version 3. ~~~~~~~~~~~~~~~~~ www.BRSolutions.com

Continue Reading

The Conversation of Three Baseball Umpires and How it Relates to Modeling

OMG released version 1.3 of SBVR (Semantics of Business Vocabulary and Business Rules)[1] last month – comprehensively reorganized for approachability, but not changed.[2] Some thoughts … ~~~~~~~~~~~~~~~~~ Ever hear the conversation that three baseball umpires once had? If you don’t live in a baseball country, it’s an archetypical story, so you’ve probably heard some variant. By the way, in American English a ‘pitch’ is a throw of the ball for the batter to try to hit, not the field of play. Meanings matter!
    • The first umpire says, “Some pitches are balls and some are strikes. I call them as they are.”
    • The second umpire says, “Some pitches are balls and some are strikes. I call them as I see them.”
    • The third umpire says, “Some pitches are balls and some are strikes. But they aren’t nothing till I call them.”
Most modeling techniques primarily focus on modeling the real world as it ‘really is’. They essentially take a first-umpire point of view or maybe second-umpire. I come from that tradition too. My 1987 book Entity Modeling was about doing that … modeling the real world as it ‘really is’. Pretty much all professionals with some IT background come from that world. Working with business people and business rules for the last 25 years, however, has taught me that business is really more of a third-umpire world. Think of laws, regulations, statutes, contracts, agreements, terms & conditions, policies, deals, bids, deeds of sale, warranties, prospectuses, citations, complaints, receipts, notices … and business policies. Even businesses that deal with tangible stuff (e.g., railroads, electrical transmission, infectious diseases, etc.) live in a third-umpire world. And many of the most automated organizations around have no tangible product at all (e.g., finance, insurance, government, etc.). They really exist only in a world of words (between people). It’s humbling to realize that the way the business world ‘really is’ is more directly the product of words exchanged by the players in a conversation game than anything IT professionals can model directly. But why would it be otherwise? Do IT professionals really know better than business owners, business managers, lawyers, engineers, subject matter experts, etc.? Really?! SBVR, in contrast to almost all other standards, doesn’t try to model the way the real world ‘really is’. Instead, its focus is on modeling what is said about the way the world really is. It’s fundamentally a third-umpire standard. You simply have to understand what the words mean – and that’s a human-communication issue. Yes, the SBVR world view is a game changer. It also happens to align closer with some of the most exciting new work in computerization today including cognitive computing and machine learning. I stand accused by peers in the standardization community of wanting to go beyond the ‘capture, exchange and production of information’. Sure, I can live with that. ~~~~~~~~~~ www.BRSolutions.com


[1]For more information on SBVR refer to the SBVR Insider section on www.BRCommunity.com.

Continue Reading

Your Approach to Business Analysis: The Big Picture

Let’s stand back and think for a moment about the future of your business and its approach to business analysis. What’s really important? My elevator pitch would comprise the following insights.

Insight 1. Order-of-magnitude improvements in business agility are possible … and proven.

Every year for the past 15 years at the Business Rules & Decisions Forum Conference[1], we’ve heard one case study after another about how companies have dramatically improved business agility. Time and time again they report having reduced the cycle time of deploying changes to business rules by an order of magnitude or more. Extensive applied experience exists in the field – such initiatives are not at the bleeding edge.

What’s actually required? Two things: Some new techniques and vision. Are we to be forever prisoners of legacy? Only if we let ourselves.

Insight 2. Doing more of the same, just faster, won’t get you there.

You’ll never get to agile business via agile programming and development. Not ever.

A requirements development and design methodology should result in high-quality systems that are inexpensive to maintain and cost-effective to enhance. How well is yours really doing that in that regard?

Insight 3. It’s not about working harder, just smarter.

Most of us are frankly already working about as hard as we can. That’s not the problem. Rather, it’s about working smarter – and producing more effective business solutions. For that you need (true) business architecture.[2] It includes business strategy, business processes and business rules, and business vocabulary (concept model).[3]

Insight 4. It’s about building business capability, not better business software (though that will happen).

Quick Quiz: Which of the following is/are directly about software?

  • Business rules.
  • Business architecture.
  • Business strategy.
  • Business processes.
  • Business vocabulary.
None of them! Of course you can use software to manage and implement any of them, but that’s a very different matter. If they’re not about software, then what? Architecting real solutions for real business challenges. Building business-oriented, business-based business capability. Any business software solution that doesn’t base itself today on these new fundamentals will be LOD – legacy on delivery. It’s time we move beyond instant legacy. ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com


[1] Refer to http://www.businessrulesforum.com/. The Business Rules & Decisions Forum Conference is part of the Building Business Capability (BBC) Conference, the official conference of the IIBA: http://www.buildingbusinesscapability.com/
[2]Refer to Building Business Solutions: Business Analysis with Business Rules by Ronald G. Ross and Gladys S.W. Lam, 2nd edition (to be published mid-2015), an IIBA Sponsored Handbook, pp 8-9. http://www.brsolutions.com/b_building_business_solutions.php
 

Continue Reading

Basics for Business Architecture: #1 – Structured Business Strategy

Professionals should always focus on business solutions first, then and only then on designing systems. Not just lip service, I mean applying the power techniques of true business architecture[1]. The first of these techniques is structured business strategy. True business solutions of any size or description hinge on strategy. Not project or IT strategy – not business case or project objectives – but real business strategy. Are you sure you really know the difference? Time and time again I find that many business analysts don’t. Here are two quick tests. Test 1. Are you aware of the standard The Business Motivation Model (BMM)[2]. Have you actually read it? If not, I’d say the issue is in doubt. Real strategy is about ends and means, not about change or how you plan, design or engineer such change. Change is inevitably involved of course – but that’s what projects and project plans are about. Test 2. Which of the following is closest to your thinking about alignment?
    • IT needs to be aligned with the business.
    • Business capabilities need to be aligned with business strategy.
If you instinctively went with the former, again I’d say the issue is in doubt. ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com


[1] Refer to the second edition of Building Business Solutions: Business Analysis with Business Rules, an IIBA Sponsored Handbook, by Ronald G. Ross with Gladys S.W. Lam (to be published mid-2015). http://www.brsolutions.com/b_building_business_solutions.php

Continue Reading 4 Comments