Every organization has something that makes it what it is, something that allows it to conduct its business and to deliver value to its consumers. Whether it is a private-sector company that develops pharmaceuticals or a public-sector organization that delivers transaction-based support, each organization offers products or services that are developed and/or offered in a way that provides unique value to the market.
While they may share similarities with organizations that do similar things, no two organizations are the same. What makes them unique is their intellectual property, their way of processing information or developing products.
For government organizations, this intellectual property is often represented by the business rules that guide their systems, processes and people. These business rules direct how inputs are transformed into outputs, including, for example, how eligibility is determined; how a benefit is derived; how taxes are calculated and how citizen votes are captured and tallied.
What makes each organization unique is their intellectual property, their way of processing information or developing products.
Mathematics, in general, is a good representation of the importance of business rules. Fundamentally, there is logic associated with both basic and advanced math; this logic guides addition, subtraction, factoring, and for those of us who made it that far (and I wasn’t one of them), determining the surface area of a sphere.
HOW you set the problem up, how you manipulate the data to get through the steps; that can change. You can use new math or old math; you can calculate in your head or write out each step. But the bottom line is that you have to apply the logic to the numbers to develop an accurate answer. Attempting the problem without understanding that logic is a waste of your time.
Organizations have a bit more flexibility when it comes to developing their business rules, but once developed, they represent the logic of the work to be performed. They are developed through a complex process of interpretation such that similar organizations across different geographies may integrate their own perspectives relative to the authority and flexibility offered by the Federal Government.
Breaking it down
Simply put, states make unique decisions on how to implement Federal Rules and guidelines and while these decisions must result in compliance, they often also result in considerable variability across states. Local government can often tweak this yet another step further, ultimately resulting in a set of business rules that becomes uniquely theirs. Yes, there is a core of similarity across like programs, but there is also enough variability to result in a unique business model, and this model must be taken into account when designing and implementing new technology.
Business Rules are NOT business processes. While there are similarities, business processes describe how people and systems capture and return information. Business rules define how people and systems act upon this data. Business rules aren’t subject to staff levels or workflow capability; they don’t change as the organization increases automation or reduces process inefficiency. Business Processes can be modified as part of your “To Be” vision; Business Rules are part of your “As Is” and must stay consistent even as your organization evolves.
New technology implementations often go too far with their focus on the future, and not the present.
Decisions to modernize your organization are rarely based on problems with how legacy systems process existing business rules. Your old systems are generally accurate with regards to calculations and determinations. You modernize because it becomes too challenging, expensive or inefficient to extend or maintain your old system, or because employees’ or constituents’ expectations evolve and the old processes become archaic or inefficient.
Unfortunately, the industry “leading” practices associated with new technology implementation often go too far with their focus on the “To Be,” seeking implementation simplicity and efficiency by suggesting that organizations should focus not on their current environment as much as their future environment; suggesting that new systems can be largely “vanilla” with minimal customization as long as organizations are willing to change their business processes to match those envisioned when package or transfer solutions were developed.
But again, business processes are not business rules, and this approach, taken to the extremes often employed today, can result in new systems that leave out the critical intellectual property captured in the old systems – systems that don’t correctly or completely capture all of the business rules that are critical for the organization’s ability to address regulatory compliance or transaction accuracy.
Nobody knows everything
It would be equally ideal if you could look to your employees to provide you with a set of complete business rules, if they could provide them during requirements analysis sessions. But the reality is, most of your employees are focused on a single part of your organization, and it isn’t often clear who knows what. Getting enough people in the room for as much time as would be needed to articulate the rules is impractical; folks have their day jobs and the business of government must continue.
Nobody knows everything, and there is a good chance that even in the aggregate, your employees do not know all of the business rules that are essential to running your organization. They rely upon the systems to know this information and they focus their knowledge on the business processes used to capture system inputs and act on system outputs.
The most complete set of business rules, the intellectual capital which is essential to the successful operation of your organization, lives within your legacy system itself. They ARE available in complete form. But they are rarely fully documented, they can be difficult to extract manually, and your systems contain a lot of useless information that was captured through trial and error coding. It would be wonderful if you could simply run a tool against your legacy system and produce a set of easily coded business rules, but unfortunately you cannot. It takes a disciplined approach that combines automated tools with manual validation and testing. But the results are worth it.
Validate in advance
Distilling and validating your business rules in advance of your system modernization efforts is a fundamental way to increase your probability of a successful implementation, which we define not only as an implementation that is on schedule and budget, but which actually delivers the envisioned and intended functionality and return on investment.
When you consider that most large projects only deliver 55% of the intended value, when you consider the potential for Federal Penalties, loss of constituent confidence, cost of rework, employee burnout, waste of taxpayer dollars and overall drag on the organization associated with unsuccessful implementations, it is easy to justify taking the time and spending the money to capture your business rules up front.
When you capture your business rules, resulting in a clean and complete set of critical data processing requirements for your new system, you are able to begin with a much more complete understanding of the core scope of your project. This leads to many benefits:
Understanding your scope allows you to develop a budget and schedule that is more accurate and more achievable. You can ask for the dollars and time that you truly need to develop the new system, which in turn allows you to meet the expectations of your stakeholders.
Capturing core requirements through business rules extractions reduces the burden associated with requirements analysis sessions, both for your vendor and your personnel. It allows team members to focus on high value activities that improve how the organization will function, including process redesign and organizational change management.
More complete requirements supports a more accurate design, leading to a system that not only operates as designed, but is designed to fully meet the needs of the organization. Without this critical activity, you may end up with a system that operates as designed but that is lacking key logic or functionality, therefore falling short of the expectations and/or requiring expensive and unplanned rework
Complete requirements support a more efficient and comprehensive testing process. Through business rules extraction, you will understand the base requirements that must be tested and met, and they will be clearly described so as to facilitate efficient test script development and execution.
In general, business rules extraction, done properly, will improve the organization’s ability to plan, execute and manage a project. All parties will have a clearer understanding of the work to be performed. This understanding allows State entities to hold vendors accountable with more confidence and less guess work. It allows vendors to more accurately estimate the level of customization and the general effort that will be required, and can help frame the important decisions that must be made by their clients during the design and development process.
Attempting your math homework without understanding the logic behind the calculation is a waste of time. The likelihood that you will get to the correct answer is low, and you’ll be forced to engage in exhaustive trial and error. Understanding that logic in advance will greatly increase the probability that you will complete the assignment successfully. The same goes for system modernization. Extract your business rules up front, understand the logic that drives your organization’s value, and you will minimize waste and increase the probability of a successful implementation.