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

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