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 ‘agile’

Announcing The Business Agility Manifesto

Capture-BAMAnnouncing: 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/

Continue Reading

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

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? Empowerment Key to Business Agility

empowement 2Let’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!

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

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

What Role for Business Rules in *Business Analysis*? 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 #4 Question: What role should business rules play in business analysis? Business rules are what you need to run the business. You would need them even if you had no systems. So it makes sense that business rules should be captured and expressed in a form that business people and subject matter experts can understand. That way they can ensure that the business rules are correct. If you are designing systems – and that usually is the case – there’s simply no point implementing rules that aren’t correct. So the Manifesto says …

5.1 Business rules should be expressed in such a way that they can be validated for correctness by business people.

Validation and correctness, however, are not the only focus for business analysis with business rules. Another is whether each rule can be justified as being truly productive for the business. Businesses often accrue so many rules over time (include ‘exceptions’ in that!) that their spiraling complexity results in rapidly diminishing return. So the cost-effectiveness of every business rule should be assessed, at least informally. To do so, first you must recognize there is cost associated with each rule. The Manifesto makes that point explicit …

8.2 Rules always cost the business something.

A rule’s true cost, however, might not be exactly what you think – the platform costs may be relatively insignificant. Instead, the principal cost of most rules is organizational. Rules must be documented. They must be taught to new hires. They must be explained to external parties. All these things take time – and time is money. Also note carefully: This overhead doesn’t decrease with each additional rule – it increases. The more rules, the more complexity. The Manifesto in no way suggests that more rules is better. Just the opposite; it emphasizes that a smaller number of good rules is always better. Better to start with a smaller number, then add more as you go. The Manifesto puts it this way …

8.5. An effective system can be based on a small number of rules.  Additional, more discriminating rules can be subsequently added, so that over time the system becomes smarter.

It’s simply a myth that you have to know all the rules before designing and building productive business systems. Just the opposite is true. You can deploy a simpler solution initially, then add rules later on as time and insight permits. Fortunately, rule-based systems are extremely good at incremental design – the goal of many an agile project.  


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

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

Not Much Luck So Far Bringing in Thoughts on Agile *Business* Governance …

I’m kicking off 2012 with a couple of things I just don’t get. Here’s the third one: I haven’t been able to find anyone so far talking about agile governance. Why not?! I recently posted this on an architecture and governance forum:

Is there such a thing as ‘agile’ governance’? What would it entail? Looking for ideas or experience in the matter … Here are a few thoughts. I think answers should touch on business policies and business rules. And put agile IT development into perspective. What am I missing? http://goo.gl/nCpPC

Guess what I got back? Thoughts on software platform governance, agile methods applied to business rule development, and more – everything except what I was looking for. Perhaps I’m partly to blame myself. There’s always going to be problems when you (me in this case) don’t define terms. By ‘governance’ I meant *business* governance … the running of business operations. The running of the show. On ‘agile’ I fudged a little. I really meant ‘agile’ simply in its real-world (dictionary) sense of “characterized by ready ability to move quickly and easily with suppleness and grace; characterized by quickness or liveliness of mind, resourcefulness, or adaptability in coping with new and varied situations”. But I knew ‘agile’ would probably invoke the IT sense. So let me try again: Does anybody have any thoughts on *agile governance*? To be more clear this time what I mean by ‘agile governance’ … 

Agile governance: the running of business operations in a manner “characterized by ready ability to move quickly and easily with suppleness and grace; characterized by quickness or liveliness of mind, resourcefulness, or adaptability in coping with new and varied situations” … where business rules, business policy, and rule management play a key role.

Continue Reading 5 Comments