I do NOT believe the way to achieve business agility is to “build a business knowledge-base that captures all the business rules and mental knowledge in an organization to prepare for change” (as one commenter recently wrote). I do NOT believe that, nor does the Business Agility Manifesto (https://lnkd.in/e5JCFc4) say to do that. As one of its three authors I am 100% certain.

The Manifesto’s message is that change initiatives should be conducted in more knowledge-aware and knowledge-centric fashion than today. As you develop business capabilities (conduct projects) the knowledge should be made explicit (e.g., as business rules, concept models, etc.) and retained. That approach permits not only the given business solution to be more agile, but as the knowledge is managed and extended, solutions built subsequently as well. You build on success.

We three authors spoke together November 10 on the Opinion of Gurus panel at the Building Business Capability (BBC) conference in Orlando, Florida (a spectacular event!). We specifically said NOT to go about things the way the commenter said. So who’s the guilty party that says we do?!

I get as excited as the next person about current trends in how work is best organized in digital companies. Those trends include egalitarianism (especially of ideas), transparency of decision-making, openness to experimentation, fact orientation, servant leadership, middle managers as player-coaches, self-organizing and self-directed teams – the list goes on.

You can immerse yourself in all those trends and lead yourself to believe that business is being reinvented. In some sense yes it is, but in the most important sense, no it’s not.

The death of companies is not imminent.[1] Top management is not going to disappear. Organizational hierarchies will continue to exist, even where flattened and energized.

What does that mean for discussion of agility? It means that if you want to pursue true business agility your thinking must be grounded in management imperatives. That is exactly the approach taken by The Business Agility Manifesto.[2]

Put simply, management exists because the business owns assets from which value must be created. The persisting need for strategy, security and optimization all arise from that fundamental fact of life.

The need for business agility arises because the business ecosystem has never before been so dynamic, at least on the compressed timeframes we see today. Business agility is about creating a sustainable means to continuously change and adapt, while preserving, protecting and enriching business assets.[3] Increasingly those assets include knowledge, a point the Manifesto takes as a critical point of departure.

Talking about agility only in terms of how to compact and energize organizational structures (hierarchies), while useful and exciting, fails to address the fundamental raison d’être for companies. Organizational agility is simply not comprehensive business agility. If only it were it that simple! Don’t be fooled. The problem of business agility runs far deeper than surface innovations addressing only work agility can ever resolve.

[1] Andrew McAfee and Eric Brynjolfsson confirm and explain this point brilliantly in chapter 13 “Are Companies Passé (Hint: No)” in Machine, Platform, Crowd (2017), W.W. Norton & Co, 402pp.

[2] https://busagilitymanifesto.org/ by Roger T. Burlton, Ronald G. Ross and John A. Zachman, 2017. The Management Imperatives are elaborated on https://busagilitymanifesto.org/supplements/management-imperatives.

[3] McAfee and Brynjolfsson use the more elegant term ‘residual rights of ownership’. Their argument (very briefly) runs like this. Since contracts with other parties will always be incomplete, companies with their managers and hierarchies will continue to exist to make decisions in all cases where the contracts fall short. In other words, even with distributed ledgers (blockchains), smart contracts, powerful platforms, and machine intelligence a completely flat (purely egalitarian) business playing field will remain unworkable.

Announcing: The Business Agility Manifesto released Sept 8, 2017 by John Zachman, Roger Burlton and myself. Have a look! https://busagilitymanifesto.org/  

The 3 of us will formally introduce the Manifesto for the first time at the Building Business Capability (BBC) conference Nov. 6-10 in Orlando, FL. Be there to hear all about it and to discuss! http://www.buildingbusinesscapability.com/

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

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?

Empowerment, more than rules, processes or architecture, is key to business agility.

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

My reasoning: Professionals in our field are often quite shortsighted with regard to empowerment. Many simply get it wrong. Working within business rules, processes and architectures doesn’t lessen empowerment; it lessens anarchy.

The real nemesis of business agility is things running amok. That’s true at both ends of the spectrum, from customers to IT.

• Customers: Ultimately the most important thing for customers is simple consistency and faithful compliance with the company’s obligations (business rules). That’s what I call high-fidelity customer experience. That capability can’t be achieved without rules, processes and architectures.
• IT: The ability to generate code faster – call it ‘agile software development’ or what you please – does not produce business agility. Business agility requires sustainability. In a digital world it’s not enough simply to put up systems fast and to keep them running. Business rules change, sometimes quite rapidly. You must be able to roll out changes to those business rules at the ‘speed of business’ to systems already implemented. Again, that capability can’t be achieved without rules, processes and architectures.

The industry’s view of empowerment tends to be askew. Who are we trying to empower, and why?

• Customers: Empowerment means the company always meets their expectations. The company has captured the requisite knowledge (business rules) to deal with them correctly and consistently. Customers know they can depend on you to get it right.
• Workers: Empowerment means freedom from having to be hands-on with everyday mundane cases. By having capturing the requisite knowledge (business rules) beforehand, you free up their time to deal creatively with outside-the-box cases.
• Business analysts: Empowerment means business analysts don’t have to reinvent the wheel on every new project. You’ve created deep knowledge reservoirs (of business rules) to jump start each new initiative.

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

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!

What business problems do business rules address?  My take: 1. Ad hoc rules: Most businesses have no organized approach for specifying their business rules. As a result, business workers often make up the rules as they go along. This leads to confusion, contradiction, and operational inefficiency. After-the-fact resolution of these problems wastes time and resources and causes frustration for customers and staff alike.

Business rule solution: Business rules ensure consistency in customer experience and provably on-target results for demonstrating compliance.

2. Miscommunication: Misunderstanding of key business concepts inevitably results in miscommunication. Does preferred customer discount mean the same across all departments? If not, what are the differences? What rules apply? Do these rules differ for different areas of the business? Are the rules consistent?

Business rule solution: A structured business vocabulary provides a foundation on which rules can be directly based.

3. Inaccessible rules: Finding out what rules apply to a given business situation often involves an open-ended search through multiple sources. It is not uncommon in the end to resort to the application source code. Pursuing rules in this fashion is time-consuming, inefficient, and inaccurate.

Business rule solution: An organized approach for managing business rules yields order-of-magnitude improvements in productivity and business agility.

4. Massive differentiation: Many businesses seek to support highly individualized relationships with growing numbers of customers and other partners across multiple jurisdictions for ever more complex products or services. How can businesses massively differentiate and, at the very same time, conduct each business transaction faster, more accurately, and at ever lower costs?

Business rule solution: Business rules support highly scalable customization and personalization and provide a structural solution for managing complexity.

5. The need to keep up to speed: Rapid change, at an ever faster pace, is a fact of life. In the digital age, people expect almost instantaneous implementation of changes. How can line workers consumed with day-to-day activities ever hope to keep up?

Business rule solution: Real-time delivery of business rules to knowledge workers creates a seamless, never-ending, self-training environment.

6. Knowledge walking out the door: By and large, baby boomers created much of the basic operational business capacity and operational systems we see in place in larger organizations today. Much of the related knowledge still sits in their heads – and nowhere else. Now they are retiring. On a smaller scale, people with vital operational knowledge walk out the door almost every day.

Business rule solution: A systematic way of capturing, documenting and managing business rules enables pragmatic knowledge retention.

~~~~~~~~~~

I wouldn’t go so far as to say that process and BPM are meaningless across the board in the digital economy. If you’re manufacturing or producing a physical product, you still do need to think in terms of a modeled and managed business process. Other the other hand, if your products are non-physical – for example, money, time, skills, information, meta-data, etc. – you’d better have a major re-think. The old rules of the game simply don’t apply to white-collar work. Nor do they apply if your business model is about digitally leveraging other people’s idle assets – think Uber. You must still consistently satisfy contractual obligations and regulatory constraints in this new digital world of course. But that’s a business rules problem, not a process problem. A major characteristic of the new digital world is that activity is never static in any sense of the word. You simply get no points for hardwiring repetitive behaviors. You must:

• Continuously make informed operational decisions in the blink of an eye (actually often faster than that).
• Selectively respond to changing circumstances with subtle adjustments.
• Be as dynamic as possible, yet still produce outcomes of predictable, consistent quality.

These too are business rule problems, not process problems. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

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  

Practitioners should stop thinking of business rules as simply another form of requirement. The life cycles of business rules and of software releases are distinct. Each has its own audience and its own natural pace. They need to be radically decoupled. Your company’s business rules are a business asset that needs to be managed directly. For effective rulebook managementyou need a special breed of tool, which I call a general rulebook system (GRBS).[1] Such tools are readily available.[2] What kind of support should a GRBS provide? Business rules and the vocabulary on which they are based are central to the problem of supporting continuous change. They need to be right at the fingertips of both business people and business analysts. You also want traceability from original sources through to the points of operational deployment. You want to know who created what rules, for what purpose, when. That’s called corporate memory. Without it, you’ll never achieve the rapid change and business agility you seek. ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

Charles Darwin is reported to have said, “It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.” Becoming more responsive to change is simply not optional these days. Consider the current state of affairs in IT today. The statistics are depressing. Reliable sources indicate that over 75% of all IT resources go toward system ‘maintenance’. That’s not agile! In the second of edition of Building Business Solutions: Business Analysis with Business Rules, Gladys Lam and I describe this world as like living in change deployment hell[1]. You might say that legacy systems are poorly engineered, but I believe that misses the mark. Rather, perhaps they are be over-engineered. What happens when you over-engineer something? The solution you produce is too stiff or too rigid or too cumbersome for the real-world problem. Think ‘tree that doesn’t bend with the wind’. The speed of business is accelerating, yet the architecture of traditionally-built systems is rigid and static. The fundamental problem in this regard is embedding business rules within the systems themselves. If you hard-code business rules into application logic, they will be hard to find, hard to understand, and even harder to change. Do we really want to keep building systems that way?! Make no mistake about it – many business rules will change. So if you continue hard-coding business rules into systems, you will be revisiting the code … a lot! That might be a good thing for service providers, but it’s not a good thing for the business. The obvious solution is to engineer business rules separately from functional requirements. Can you do that cleanly and effectively? Absolutely. It’s been proven many, many times. ~~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com