Subscribe to the FREE Business Rules Journal Newletter





RLCA Observations from the Crow's Nest

by Dagmar Cole

The crow's nest sits high above the deck and provides the best view for a lookout to spot approaching hazards.  RLCA positions the IT strategist in the crow's nest with the ability to see the existing landscape as well as the distant horizon.

Companies are focused on "next quarter earnings" and a one-year (or less) return-on-investment.  It's difficult to sell upper management on a technique that takes staff years to complete and more than one fiscal year to payoff.  How does RLCA compare to other SISP methodologies — Business Systems Planning (BSP), Strategic Data Planning (SDP), and Strategic Management Planning (SMP)?

Timeliness.  RLCA can be done relatively quickly.  Performing analysis on the Human Resources resource consisted of a total of 5,280 hours or approximately 2.5 man years.  This is an order-of-magnitude less than performing other SISP techniques.

Quality.  Both business and IT users were able to comprehend the RLCA concepts and assess the value chain.  Using desktop tools, not only basic reports but graphics were created.

Maintainability.  Existing RLCA does not require any specialized tools and can be performed using a spreadsheet or a desktop database.  Existing tools can be modified to support RLCA and thus does not require additional cost or training.

Reproducibility.  As each reviewer examined the resource value chain, results were concurred by both IT and business users.  Given that other SISP methodologies have such a long time to complete, with the business landscape constantly changing, it is highly unlikely that any other SISP methodology can be realistically reproduced.

Usability.  BSP, SDP, and SMP each have a tremendous chasm between the resulting strategic plan and the implementation.  RLCA has a tight coupling to the enterprise strategic plan.  The resulting precedence architecture provides the map needed for prioritizing applications development and as well as highlighting those applications to be retired.  RLCA additionally identifies gaps that most likely are undocumented 'stovepipe' applications.

As an application architect for a Fortune 50 organization, I have implemented RLCA in my organization and the results have been phenomenal.  Using a tool no more sophisticated than a desktop database, I had my business analysts identify the resources, value chains, and precedence.  Using this as a basis, applications were mapped to the value chains, then entities.  This was done as part of the normal requirements-gathering process and not as separate projects so there was "no cost" to the business.

Immediately there were major benefits;

    • Clusters of applications supporting the same resource functions were identified.

    • Some functions had no identifiable IT application support.

    • The ability to compare the resource value chain with the process flows identified tasks that may not be providing value to the organization.

    • It provided a basis for project prioritization.

    • It provided the ability to accurately bound and scope the project's level of effort, resulting in business case estimates going from +/- 200% to /- 25%.

Strategically, RCLA identified the 'low-hanging fruit'.  Functions with missing supporting applications were reviewed first.  In all cases there was a spreadsheet or manual process that was automated, and we were able to identify 'quick hit' improvements that were low cost and high value to the organization.  These quick hitters were used to gain the business' trust.

The RLCA precedence architecture provides an enterprise-wide view of the business and associated IT applications.  RLCA identifies candidate redundant applications by viewing clusters of applications supporting the functions.  Are the applications supporting critical or low-priority functions?  If low priority, why so many?  For example, in Organization 'A', where the pilot was performed, why were there over forty applications supporting Recruitment?  After discussions with the manager, it was discovered that new employees wanted tools they were familiar with so tools were bought; then subscriptions were purchased for ongoing maintenance and support, with little to no use.  A decision was made to reduce the number to three, resulting in immediate savings to the organization without any associated costs.

Conversely, viewing clusters of applications around high-priority projects identified potential projects to integrate.  Often we found that there was a single function that was not integrated, which required the entire application to remain operational.  One small functional sliver like this resulted in ongoing inflated maintenance costs.  Knowledge is power — armed with this information, developing integration roadmaps became extremely easy and aligning IT with the business strategy was a breeze.

The precedence architecture also proved to be an invaluable tool for estimating a development project.  Rather than the 30,000-foot view of architectural diagrams from an IT perspective, the precedence architecture provided a realistic map to bound the actual scope of the project.  For example, we knew that changing an application for this resource function would impact ten other areas.

The result?  Over a three-year period of the business tracking variations between the 'raw' order of magnitude (OOM) estimates and the actual final project costs, the variations were in the range of  +/- 25%.

There is a saying, "There is nothing new under the sun."  In this case, RLCA has been around, largely languishing, for nearly twenty-five years.  I say it's time to dust it off and for it to take its rightful place in the sun.


DISCLOSURE:  Dagmar Cole has no relevant relationship with Ron Ross or Business Rule Solutions.

standard citation for this article:
Dagmar Cole, "RLCA Observations from the Crow's Nest," Business Rules Journal, Vol. 17, No. 9 (Sep. 2016), URL:  

September 2016
Observations from the Crow's Nest
By Dagmar Cole

August 2016
Resource Life Cycle Analysis to the Rescue
By Dagmar Cole

July 2016
The Stormy Seas of Information Strategic Planning
By Dagmar Cole

March 2016
Business Rules Hierarchy
The World of Business Rules Is Not Flat

By David Lyalin, PhD and Warren Williams, MPH

January 2016
SBVR for UTP Using an OMG Specification to develop another OMG Specification
By Markus Schacher

September 2014
Supporting a Business Rules Approach with Standards and Patterns
By Chris Maple

April 2014
Bringing Enterprise Business Rules Management to Inland Revenue
By Michelle Murray

March 2014
Focus on What Makes Your Business Smart: From Interpretation to Implementation - Steps 5 7: The Technical Steps
By Gladys S.W. Lam

February 2014
Focus on What Makes Your Business Smart: From Interpretation to Implementation - Step 4: Develop Scenarios
By Gladys S.W. Lam

December 2013
Focus on What Makes Your Business Smart: From Interpretation to Implementation - Step 3: Analyze and Refine
By Gladys S.W. Lam

November 2013
Decision Tables Saved Our Project from Failure!
By Gwen Bradshaw

November 2013
Focus on What Makes Your Business Smart: From Interpretation to Implementation - Part 3: Structure Business Logic
By Gladys S.W. Lam

October 2013
Focus on What Makes Your Business Smart: From Interpretation to Implementation - Part 2: Interpret from Sources
By Gladys S.W. Lam

September 2013
How Business Rules and Decision Tables Support Evaluation of Patient Eligibility for Publicly-funded Vaccines
By David Lyalin, PhD and Warren Williams, MPH

September 2013
Focus on What Makes Your Business Smart: From Interpretation to Implementation - Part 1: Introduction
By Gladys S.W. Lam

July 2013
Insights from the Adoption of Fact Modeling
By Chris Maple

June 2012
Using the Business Motivation Model to Encourage Big Picture Thinking in Fast-moving Agile Development Environments: Some Personal Reflections on Motivation And Representation
By Peter Wells

November 2011
RegelSpraak for Business Rules: Experiences in building a Business Rules Compiler for the Dutch Tax Administration
By Frans Fokkenrood

July 2011
Are Use Cases Any Good In Capturing Business Rules?
By Terry Moriarty

April 2011
Experiences in Re-Inventing a Business Process with Business Rules (Part 5): Monitor & Adjust
By Dencie Mascarenas

March 2011
Experiences in Re-Inventing a Business Process with Business Rules (Part 4): Test & Retest
By Dencie Mascarenas

February 2011
Experiences in Re-Inventing a Business Process with Business Rules (Part 3): Document & Code
By Dencie Mascarenas

January 2011
Experiences in Re-Inventing a Business Process with Business Rules (Part 2): Get Support & Help
By Dencie Mascarenas

December 2010
Experiences in Re-Inventing a Business Process with Business Rules (Part 1): Identify the Core Problem
By Dencie Mascarenas

October 2010
Success Story
By Beth Myers

September 2010
Breaking The Rules A Business Rules Analysis Case Study
By Craig McLean

December 2009
Standing Out in a Crowd
By Miranda Shumaker

October 2009
Commercial Insurance Carrier's Road to Business Agility
By Mo Masud and John Lucker

June 2009
Cost and re-use of terms: can we measure it? ~ Yes we can!
By Tom Bazzarre and Beth Myers

October 2008
Creative Artifacts to Accompany our Business Rules
By Miranda Shumaker

August 2008
It's All About the Data: How the Use of a Business Rules Approach is a Critical Success Factor for a Data Project (Part 2)
By Pat G. Wilson

July 2008
It's All About the Data ~ How the Use of a Business Rules Approach is a Critical Success Factor for a Data Project (Part 1)
By Pat G. Wilson

January 2008
Traceability Aspects for Business Rules Management
By Mukundan Agaram

May 2007
The Phased Approach to Mining Business Rules
By Mukundan Agaram

April 2006
Business Rules in Practice
By Bonnie Moonchild

November 2003
Enterprise Rules Services at Liberty Regional Agency Markets
By David Christiansen

April 2003
Case Study: Business Rules at Work in The Pump Manufacturing Industry
By Steve Taylor

June 2001
Case Study: Business Requirements Analysis Using UML (Part 2)
By Dan Tasker

February 2001
Case Study: Business Requirements Analysis Using UML (Part 1)
By Dan Tasker



 about . . .


Dagmar Cole has over twenty years of experience working in all facets of the Software Development Life Cycle (SDLC). Her interest in applying quantitative management techniques to software began at George Mason University. While majoring in Decision Science, she published a paper on Software Quality Assurance. Later, she published her master's thesis in strategic information systems planning at Marymount University.

As a business analyst and project manager, Dagmar continues her quest to apply quantitative techniques to the SDLC. She is an active member of the Fort Worth Chapter of IIBA and was a speaker at the IIBA BBC 2015 conference. She also has extensive training in conflict resolution and is returning to the IIBA BBC conference in 2016 to discuss conflict resolution.



[ Home ] [ Staff ] [ About BRC Publications ] [ Editorial Feedback ] [ About BRCommunity ]
[ Contributor's Guidelines ] [ Privacy Policy ]