I’ve been thinking about what it would look like to automate the process of passing laws in the U.S. government, so I decided to map out the whole process. Then it got complicated, so I decided to scale back and just start with how a law begins as a bill going through the House of Representatives.
It turns out that the process of moving a bill through the U.S. House of Representatives is pretty complicated and a great example for using Business Process Model and Notation (BPMN) to document, orchestrate, and automate a complex process.
Let me walk you through how I used Camunda Platform 8 to model this complicated process in BPMN and make it understandable. Along the way, you’ll learn how I added forms to include human interactions in the process and used a small Decision Model and Notation (DMN) decision table to minimize chances of error.
Follow along to do the same for the complicated processes you’re trying to tackle.
What we may already know
Now, if you grew up in the U.S. during a certain time this video from Schoolhouse Rock on how a bill becomes a law may be familiar to you.
There’s more to it, of course
Let’s start with the basics. The legislative branch of the U.S. government consists of the House of Representatives and the Senate. Together they make up the U.S. Congress and hold the sole authority to enact new or change existing laws.
The general idea this blog post follows is that a bill — a proposed law — is introduced in the House of Representatives and the members decide whether it will go to a committee or a subcommittee for discussion, debate, and what’s called markup. This is where the committee or subcommittee members make changes to the wording of the bill, etc.
Finally, the committee or subcommittee will vote on the bill. If it passes, it moves on to the next step. If the vote fails, the bill is dead and the whole process ends.
If the bill passes the subcommittee and the committee, it is then brought to the full House for debate. Once the full House has had a chance to read the bill and debate it, it is put to a vote by the full House.
If it passes the House, it is sent to the Senate where the whole process starts all over again.
Note: In reverse, if a bill is introduced in the Senate, and makes it all the way through there, the bill then goes to the House, where it is subjected to the entire process above.
That’s really the overly simplified version.
Mapping out the process
As with any process, it can be instructive to map the whole thing out so you can see all the various steps involved in completing it. That’s when I realized that things are actually a bit more complicated than they first appeared. There are all sorts of ways in which the process can end.
Here’s a simplified flowchart of the process:
There are a lot of these flowcharts out there, but none of them are actually executable, so I decided to make that happen. Why would you want an executable flowchart? Great question! A flowchart is nothing more than a roadmap for how a process should go. Notice in the above chart we proceed from one activity to the next. But it’s nothing more than just a chart showing how things should go. There is no actual implementation to go along with it.
With BPMN, we can not only map out the process in a flowchart but also attach actions and results to each step in the process. BPMN is an executable language, so it not only shows the steps in a process, but it also defines the actions that each of those steps needs to take.
An executable flowchart
Using other flowcharts, information, and BPMN, I mapped out the entire process of a bill getting through the U.S. House of Representatives. Here it is:
I’ve color-coded the process to make it easier to see what types of tasks I am using. In this particular process, I’m only using user tasks and business rule tasks. In fact, there are a lot of user tasks in there. A user task is a type of task where the workflow engine informs a user that there is a task that requires human intervention. It adds all of these tasks to Task List where users can go and see what pending work they might have to take care of. Typically, these user tasks require a user to fill out or respond to a presented form, which means I needed a lot of forms for users to fill out. Thankfully, there is an integrated form builder in Camunda 8, which I used to design the various forms.
I can now deploy this process, and then start an instance of it to see how it all works. This is actually an important point here. These are not just diagrams or flowcharts. Thanks to BPMN and the Camunda execution engine, they are also processes that can be directly executed.
When I deploy and start this process, I can go to Operate, which is the tool in the Camunda stack where you can see the actual execution state of your running process.
You can see the little green dot that indicates where in the process we are. The first thing we have to do is decide if this bill belongs in the House or the Senate. This is where the user task comes in. I designed a form for this user task asking one simple question: Is this bill an appropriations bill? Constitutionally, revenue-raising bills can only be introduced in the House. Traditionally, appropriations bills also start in the House.
If you look at the process above, you’ll figure out that if I were to say “no” here, the process would end because it only looks at how bills are introduced in the House. Technically this is incorrect, as any bill can be introduced in the House. I did this to show how the process could work.
Next, we will decide if the House will accept the bill. There are many reasons that the House may reject a bill; from it being poorly written, to there not being enough time to introduce it, etc. In our form, however, we just give it a straight thumbs-up or thumbs-down decision.
Notice that in Camunda Forms I can use emojis to make the form more fun. Congress could probably use more fun!
Once the bill is accepted, it is assigned to a committee for discussion, markup, and an initial vote.
There are a lot more committees in the House, but I decided to keep the list manageable for this example. Once the bill is sent to a committee, the committee decides whether or not to send the bill to a subcommittee for initial debate and markup.
Once the bill is sent to a subcommittee, that subcommittee reads through the bill, makes any changes to it, and then takes a vote on whether or not to pass it along to the full committee.
When the vote is called, all committee members have a chance to vote “aye” or “nay” as to whether the bill should pass through the subcommittee. A bill can sit in a committee (or subcommittee, or even the full House) indefinitely unless a vote is called. Typically, the committee chair or the House speaker would “call the vote” on a bill, but there is no requirement that a vote has to be held on any bill unless it is “called.”
And then a vote is held.
Once the votes are collected, we use a DMN decision table to decide whether or not the bill has carried.
The table takes the “ayes” and “nays” (yeses and noes) from the vote tally and decides whether or not the bill should be passed. In the event of a tie vote, the bill returns to the previous step for more debate and another vote. If it fails, the process ends there, but we are going to move it along.
By using a decision table, I can alleviate any accusations of vote-rigging shenanigans since no person has to make the decision, and the rules for the decision are clearly outlined in the table.
If we go back to Operate and look at the task and its progression, we can see that the bill passed through the subcommittee and now sits with the entire committee. We can also see all the history of the bill so far.
Again, by having the complete decision history and voting record, we can easily track how the bill has progressed along the way.
We are not going to go through every step in the process here, since the rest of the steps are basically repetitions or variations of steps we’ve already looked at.
Because each of the following steps is largely the same as the previous steps, I was able to reuse some of the forms and components I had already designed. I reused the “time for a vote” task, the “vote tally” task, and the vote-counting decision table. This ability to reuse previously designed elements is a huge benefit of using Camunda 8 to design and execute the process.
Finally, after the entire process is done (and the bill has passed the House) we can look back at the path that the bill followed.
You can see that the path the bill followed is colored blue, so at any time we can go back, find the exact bill we are interested in, and see all of the history associated with it — including the path it took through the House.
Wait! There’s something else there
You’ve probably seen and been wondering about this little subprocess that’s been hanging around the whole time.
Constitutionally, a bill can only be considered in the Congress in which it was introduced (Please see the earlier note). If a bill has not either passed or been rejected by that particular Congress, it “expires” when new members are sworn in. That means it can no longer be considered or voted on. It would need to be introduced as a new bill and go through the entire process again.
To ensure that all the active bills are only considered during the current Congress, we have an expiration timer for all bills. This subprocess has a timer that expires on the date the new Congress is sworn in. If the timer goes off, any bill that has not passed is expired and can no longer be considered by the House.
As you can see, the timer will go off on January 1, 2023. Once new members of Congress are elected this year (2022), they will join the upcoming Congress. When that new Congress is sworn in, all bills that have not been completed in the previous Congress will expire and be removed from consideration.
Conclusions
We have now mapped out the entire process for getting a bill through the U.S. House of Representatives. Although I started out this blog post showing you a couple of flowcharts for how the process works, those were just flowcharts. I couldn’t actually execute them as a process. By using Camunda Platform 8 to model the process in BPMN, I was able to transform it into an actual executable process. By adding forms with the integrated form builder, I was able to add human interactions to the process. In addition, using a small DMN decision table removed (hopefully) any chance of error in manually counting the votes to decide if the bill passed or failed.
So what’s missing? Well, this is just a small part of the overall process of turning a bill into law. The entire process is repeated over in the Senate (with a few differences). If the bill passed both houses, but one or the other made changes, the bill has to go to a conference committee where the changes are reconciled, so that the two versions match exactly. Once that’s done, the bill goes on to the president for their signature (or a veto).
If you’re interested in seeing the rest of the process developed, please reach out to me and let me know. Or feel free to check out the source code and make any additions or changes as a pull request.
