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

Posts Tagged ‘requirements’

Agile: Tail Wagging the Dog?

wag-the-dog[1]I’m deeply concerned that agile software development is taking us giant steps backwards in terms of achieving true business agility.  At some companies we visit things are simply out of control. The software development tail wags the business dog.

It’s not just me who thinks so. Here are some comments from recent conversations on social media:

“The business is now at complete mercy of IT Agile to the point where it’s cut out of critical product and service decisions. … IT agile delivery being seen as equivalent to agile/entrepreneurial business which is very far from the case.”

Donna Luehrman, MBA, CBAP

“Agile software development methodology is often antithetical to longer-term business agility and a short-sighted antagonist to the discipline required to achieve it.”

Howard Wiener, President, Codiscent Americas

Agile software development will never get you to agile business because it does not address operational business knowledge (business rules) in a direct or innovative fashion. By coding faster and faster many businesses are simply becoming more and more un-agile. Untold millions of dollars are being sunk into instant legacy. Worse, it may take untold billions of dollars to service that legacy over time. That’s not operational excellence; that’s operational negligence.

If your current approach is based on user stories and use cases and the like ask yourself these questions:

Question 1. Do you address business rules directly in your requirements approach? By ‘directly’ I mean in a systematic, traceable way. Or, do you implicitly assume IT will just somehow get them right?! I think that’s a very bad idea and a very big risk for operational business excellence.

Question 2. What are you doing to ensure governing rules are understandable by business workers and SMEs in the specific way that the business wants them to be interpreted and applied? What are you doing about rules that aren’t automatable? Aren’t those important? And what are you doing to coordinate and disseminate this knowledge to line workers in a systematic, repeatable way?

Is there a place for agile software development? Of course. Just not when it comes to basic operational business knowledge (business rules).

~~~~~~~~~~~

Read more about the Big-5 business challenges: http://www.brcommunity.com/articles.php?id=b904

Continue Reading

Getting at the Rest of the Communication Iceberg

communication[1]In many respects professionals in our field have a very a limited view of communication. Yes, of course we need to close communication gaps on every project, and among all stakeholders, and with IT. Though never easy, working to close those kinds of communication gaps should be a given.

Instead, we need to talk about a broader kind of communication – the communication of operational business knowledge over time and space. That requires some engineering. Let me put this challenge into perspective.

I recently read an interesting post in social media by Angela Wick about user stories and their role in agile and other requirements methodologies. The post depicted their role as addressing the tip of an iceberg, as in figure 1.[1]

Figure 1. The Role of User Stories in Agile and Other Requirements Methodologies

Angela WickMany agile gurus describe a user story as a placeholder for a conversation, or a promise of a future conversation. That’s a great characterization because it highlights the crucial point that user stories address only the 10% that you can ‘see’ above the requirements waterline. Over time, each user story must be fully explored and all the hidden detail, the submerged 90%, filled in.

The crucial question is what does all that hidden detail represent? A very sizable portion, certainly far more than half, is operational business knowledge – in other words, business rules.

Once you get that point, a next question naturally arises. Do you really want business analysts and system developers to re-invent and re-specify and re-design all that knowledge from scratch on each new project?! No! There’s nothing agile about that whatsoever(!). That’s simply re-inventing the wheel – over and over and over again.

We have clients telling us that they have achieved proven savings of 75% or more by having relevant business rules available before a project starts.

Pre-existing business rules allows project sponsors to launch projects on the basis of known facts rather than guesswork. It can reduce the difficulty of a project by an order of magnitude and improve the chances of success dramatically.

You should want – actually you should demand – ready-to-reuse, fingertip business rules for projects.

That’s where over-time-and-space communication comes to play. Ready-to-reuse, fingertip business rules represents communication of operational business knowledge across organizational boundaries and through the passage of time.

~~~~~~~~~~~

Read more about the Big-5 business challenges: http://www.brcommunity.com/articles.php?id=b904

[1] User Stories: You Don’t Have to Be Agile to Use Them! by Angela Wick, http://www.batimes.com/angela-wick/user-stories-you-don-t-have-to-be-agile-to-use-them.html

Continue Reading

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

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

Business Rules vs. Choices Made in Designing Systems … Not the Same Thing!

A colleague and I were recently discussing business rules. In the course of conversation he used this example: A customer may have only one address. Hold on! That’s not a business rule. Rather, it’s a design decision (probably a poor one) some IT person made in creating a system model. The business wouldn’t (and couldn’t!) make a real-world business rule about customers having only one address. But a design decision might be made to record only one (in a system). Eventually we agreed the desired business rule probably was: A customer may have only one preferred address.  ~~~~~~~~~~~~~~~~~~~~~~~~~~  This post excerpted from Building Business Solutions: Business Analysis with Business Rules (2011). See:  http://www.brsolutions.com/b_building_business_solutions.php

Continue Reading 1 Comment

Use Agile for Areas Subject to Regulations?

The Question: I asked for feedback on LinkedIn about using agile for target business problems focusing on an area subject to regulations, contract terms & conditions, agreement/deal provisions, business policies, etc. (Sound like your area?) The best reply I got back …       Guest Post by Sujatha Ramesh Sr. Manager, Business Solutions at LearningMate “In highly regulated environments, documented evidence of decisions, impact and approvals are a necessity. Agile practices discourage maintaining extensive documenting, relying on ‘sitting next to the team and explaining’ instead. You will generate precious little proof of what transpired and the decisions taken in doing so.”

Continue Reading 1 Comment

“Business Rules Are Too Unstructured to Stand Alone.” Au Contraire!!

A Business Analyst recently said, “Business Rules themselves tend to be too unstructured to stand alone “. Au contraire! Well-expressed business rules are discrete, specific, and context-independent. Think about laws, regulations, contracts, agreements, deals, policies, etc. as common sources for business rules. Business rules are interpretations that make those things practicable. Those things can certainly stand alone. So can the interpretations. The test of ‘practicable’ (the term used in relevant standards) is ‘Can a worker who is authorized and capable know what to do or not to do as a result of reading it?’ Business rules must be well-structured to pass that test. More broadly, ‘practicable’ means ready to deploy into the business for workers to follow, or to pass over to IT as part of requirements in building systems – either way with the same results. Practicable business rules are encoded know-how of the business, vital operational IP. They are explicit, not tacit, so they can be retained, managed and re-used. Business rule management is the most practical means around for meaningful knowledge retention.

Continue Reading

Business Rules and Enforcement: One of the ‘Must-Knows’ of Business Rules …

Celebrating the 10th Anniversary of the Business Rules Manifesto[1] http://www.businessrulesgroup.org/brmanifesto.htm FAQ #10 Question: How does the Manifesto view the issue of business rule enforcement? Principle 4.6 of the Manifesto states …

Rules should be defined independently of responsibility for the who, where, when, or how of their enforcement.

Why? Separation of rule specification from enforcement concerns[2] ensures that …
  • The true business intent of the rule itself can be directly validated. Enforcement concerns do not mix things up.
  • The greatest degree of business agility is achieved. Changes to enforcement specifications and changes to the rule itself can be made independently.
  • The highest degree of re-use is supported. The same rule can be subject to different enforcement specifications at different points of application.
Specifying rules independently of responsibility for enforcement is taken to mean all the following.
  • Who. If responsibility for enforcing the rule is given to some role in the organization, that role should not be mentioned in the statement of the business rule.
  • Where. If responsibility for enforcing the rule is assigned to some component of the technical architecture, that component of the technical architecture should not be mentioned in the statement of the business rule.
  • When. In general, every business rule applies to multiple events (flash points). However, those events should not be mentioned in the statement of the business rule.
  • How. If capability for enforcing the rule is laid out in some process or procedure, that process or procedure should not be mentioned in the statement of the business rule.


[1] The Manifesto is free, only 2 pages long, translated into 15 languages. Have a quick look (or re-look!). No sign up required. Well worth your time.
[2] For discussion of enforcement specifications, see Breaking the Rules: Breach Questions http://goo.gl/MFxtN

Continue Reading

Your Current Requirements Approach: A Very Big Question Mark

Each business rule usually produces multiple flash points.  Don’t know what a flash point is? I think you should! See a brief explanation: http://goo.gl/pl9sT. Why is this insight so important?  The two or more events where any given business rule needs to be evaluated are almost certain to occur within at least two, and possibly many, different processes, procedures, or use cases.  Yet for all these different processes, procedures, and use cases there is only a single business rule. Now ask yourself this (the very big question): 

What in your current IT requirements methodology ensures you will get consistent results for each business rule across all these processes, procedures, and use cases?

Unfortunately, the answer today is almost always nothing In the past, business rules have seldom been treated as a first-class citizen.  No wonder legacy systems often act in such unexpected and inconsistent ways(!).  Organizations today need business operation systems where business governance, not simply information, is the central concern. Business rules should be seen as one of the starting points for creating system models – not something designers eventually work down to in use cases.  That’s the tail wagging the dog. By unifying each business rule (single-sourcing), and faithfully supporting all its flash points wherever they occur, Business Analysts can ensure consistent results across all processes, procedures, and use cases.  Is there really any other way?! ~~~~~~~~~~~~~~~~~~~ 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

Requirements Management and the Business Motivation Model

Guest post by Cecilia Pearce ~~~~~~~~~~~ I have just completed the “Business Analysis with Business Rules: From Strategy to Requirements” on-line training session given by Ron Ross and Gladys Lam.[1] This approach has additional benefits where requirements are concerned. During the session, it became evident that some of the requirements processes defined by BABOK® – Requirements Elicitation, Prioritization and Traceability – may be simplified when following the Business Motivation Model (BMM)[2] approach. The BMM approach emphasizes starting with strategy for addressing the business problem. Being top-down and structured, it ensures that defined requirements are based on the business goals identified for the organisation. Since the source of the requirements is therefore known, their prioritization is simplified. Requirements linked directly to the goals will have a higher priority, whereas other requirements, depending how linked to the goals, may be allocated a lower priority. Traceability of requirements also benefits from the BMM approach. The requirements are already associated with the goals, possible business risks are identified, and relationships are traced to business processes, business milestones, and key performance indicators. The requirements elicitation process is just another benefit of the BMM approach. Requirements are defined with the goals in mind. The Policy Charter[3], a deliverable in the style of the BMM, illustrates the goals in more manageable segments and links the requirements directly to the identified goals. It allows the business stakeholders to ‘see’ their end result more clearly and understand what steps are required to get there.
[2] BMM is the strategy standard originally developed by the Business Rules Group, and subsequently adopted by OMG. See http://www.businessrulesgroup.org/second_paper/BRG-BMM.pdf.
[3] Business Rule Solutions’ Policy Charter was a basis for the BMM, and is consistent with the standard.
 

Continue Reading