Featured Post
These days, I mostly post my tech musings on Linkedin. https://www.linkedin.com/in/seanmcgrath/
Friday, August 06, 2010
Gov 2.0 Summit
I will be attending Gov 2.0 summit in Washington D.C. in September. If you are going, or are in that kneck of the woods and want to meet up, let me know.
Show your support for law.gov
Thursday, August 05, 2010
Typography matters
Monday, August 02, 2010
The KLISS workflow model
My last post in this KLISS series marked a half way point in this whirlwind tour of the KLISS architecture. Before proceeding, I'd like to summarize the main discussion points so far and link back to earlier posts for ease of navigation.
This agnosticism about data organization is a critical component of the KLISS workflow model which is the primary topic of this post. If you have been reading along in the series, it will come as no surprise that legislatures/parliaments pose many challenges when it comes to applying "off the shelf" standard models for databases or content management systems or video publishing systems. Central to the complexity, in my opinion, is that legislatures/parliaments resist analysis and decomposition. By that I mean that the standard methods of systems analysis and design pre-suppose that the analysis phase can result in the crisp expression of the "business rules" or the "workflows" that govern any particular domain. In the standard model, one does not begin implementing business rules/workflows until one understands what they are. This sounds abundantly sensible doesn't it?
Not so in legislatures/parliaments. I'm sure most readers will find that statement surprising. How hard can the rules be? In Civics class they talk about bills being introduced and debated and modified and voted on and passed into law. Seems like a pretty straight-forward workflow to me? Why not just walk around, ask everyone what they do in support of that workflow and then write it all down. Voila! One set of "as-is" business rules!
I would like to split the reasons why workflow is not that simple in legislatures/parliaments into the following seven areas (in no particular order), each of which is discussed below:
Legislatures/Parliaments are generally grand old institutions. It goes with the territory that there is a lot of tradition and a lot of history behind how they operate. Unfortunately, the distinction between operating "rules" and operating "traditions" is easily lost in the mists of time.
Here is a pot-pourri of rules from my own experiences to give you a flavor of what I am talking about:
During analysis phases I have come across many rules such as these. It has been my experience that rules in legislatures/parliaments only have one thing truly in common. Namely, that they are cherished equally by staff and Members alike. Asking the dreaded question "why?" to any of the rules above and you are likely to get a reaction of the "because!" variety. Digging deeper, a variety of outcomes are possible:
Practical upshot: Digging deeper into any of these rationales may result in "bottoming out" the rule but it may also result in another layer of detail that itself, needs further bottoming out. That bottoming process may or may not end.
In some cases, it is possible to bottom out the "why" of a rule only to find that it is something of an accident of history. A common example is rules that exist in order to work around problems in document processing over the years. Over time, the rationale for the rule gets lost and the rule ends up having the same status as other rules in the minds of the actors concerned. i.e. the rule becomes cherished. Some examples from my own experience:
Practical upshot: Accidental workflow rules are still rules.
The rule-sets of legislatures/parliaments invariably include the rule(s) that govern changing of the rules themselves. From an IT perspective, the presence of a rule that allows the rules to be changed has profound implications. It means – in one fell swoop – that any attempt at codifying the rules directly into a programming language is doomed to fail. Anybody who approaches a legislature/parliament attempting to map business rules to business logic to computer code, in the classic model, is going to get into trouble.
Practical upshot: the rules are not written in stone so they cannot be coded in stone either. In the IT vernacular, the "rules engine" for expressing and executing the rules of a legislature/parliament needs to be Turing complete. No approach based on, say, mapping finite state machine state transitions to middle-tier function calls is going to cut the mustard.
It could be argued that the rules might not change very often. One might point, for example, the 43 standing rules of the U.S. Senate. Whilst it is true that the rules of the U.S. Senate do not change very often there is a vast (and I do mean vast) set of precedents which are, in effect, rules. Precedents result whenever something happens on the floor that requires adjudication by the Parliamentarian. The amount of precedent grows over time. Every sitting day is an opportunity for new precedent – new rules – to be formed.
Remember how, it math class, your teacher exploded your brain by telling you that between every to numbers on the number line, lies another number? Business rules in legislatures/parliaments are very similar in my opinion. There may be a rule for what happens in situation X and a rule for what happens in situation Y but when Z occurs – a combination of situations X and Y – a new rule is born. This process can be repeated ad infinitum.
Practical upshot: The rules of a legislature/parliament are like a fractal. Between each pair of rules lies the potential for a literally infinite family of sub-rules. In this sense, the rules are somewhat like the corpus of law itself. Primarly law becomes denser and denser – more fractal like – as more and more refinement is added to the rules. Similarly caselaw interprets statute and once created, the caselaw itself becomes law (in the common law tradition at any rate). Then new caselaw can come along clarifying interpretation for cases that fall between existing caselaw and existing statute. This process can be repeated ad infinitum.
Speaking of fractals...organizational boundaries are fractal-like too. Consider a new legislature/parliament formed out of an existing one. Say, the New England States or the African countries that emerged from French/English/Dutch colonies...They may start as replicas of their parent institution but soon the differences start to appear. The new institutions differentiate themselves from their parents by injecting differences in how they operate. Over time, the injection of difference percolates the new institution. The chambers inject differences so that House procedure differs from Senate procedure. Appropriations committees do things differently than redistricting committees. The Senate creates a new form of Resolution, not used in the House. The House changes the way it numbers its rules so that they are visibly different from the Senate rules...etc. etc.
Practical upshot: Rules serve to differentiate as well as control the behavior of institutions. The human organizational need for differentiation essentially guarantees that rules will change even if there is no specific technical reason for the change.
This one needs little explanation. In an earlier post I mentioned Nomic. Suffice it to say that building computer systems that are capable of interpreting and checking and executing a set of rules is made significantly more complex if the rules can be disabled at any point.
This one also needs little explanation. Politics is, in my opinion, best understood in terms of game theory. Equilibria become more complex when the rules can be modified in a way that impacts the outcome matrix.
I hope the above has convinced you that getting to the bottom of the business rules of a legislature/parliament is no easy matter. It is not a question of effort. Doubling the number of resources trying to bottom out the rules will not help you. Doubling the time available to do it will not help you.
The workflows of legislatures/parliaments are, in my opinion, complex in the formal, mathematical sense of complex. That is to say, the feedback loop created by the self-referential nature of the rules combines with the other factors listed above to create a fascinating phenomenon in which homeostasis (i.e. stable parliamentary process and procedure) emerges as a sort of emergent property of the system as a whole.
The key, in my opinion, is to not let the surface complexity overwhelm you. After all, the very definition of an emergent property is one that arises out of a multiplicity of relatively simple operations that includes a feedback loop. The complexity can be tamed! However, taming it requires looking at the right level of abstraction. A full frontal assault based on decomposing the rules is about as likely to yield actionable understanding as decomposing the ants in an ant hill.
Over the years I have seen many fall into the trap of attempting to bottom out all the rules in a legislature/parliament. I tried it myself on more than one occasion. It is seductive. It would be great it if were possible, but it is not possible in my opinion.
What to do? The critical thing is to change the focus of the hunt. The hunt is not to find individual rules. The hunt is to find the relatively simple operations from which all rules are made.
That is what KLISS is based on. The application substrate it sits on has a workflow model based on this emergent model of workflows.
That is where we will go next.
- In What is a legislature the top level "black box" model of a legislature/parliament was presented.
- In XML in legislature/parliament environments seven reasons were presented why the standard model for wielding XML is problematic in legislative/parliamentary environments. Namely:
- The centrality of line/page numbers in amendment cycles
- the complex nature of amendatory actions
- The critical nature of fidelity with historically produced renderings
- The fluid nature of work-in-progress legal assets.
- the complexity of amendment cycle business rules
- the subtle inter-play between legal content and legal content renderings
- content aggregation and its role in content modeling and information architectures
- The centrality of line/page numbers in amendment cycles
- The concept of treating legal texts as source code was the subject of Law as source code
- Allocating good names was the subject of naming things well.
- The next post rigid designation continued the discussion about names.
- The next post covered the eventing model and the consistency model used in KLISS.
- Data architecture/organization was the topic of Organizing legislative materials and the post that followed it, argued that the search for a perfect data model is always doomed which is why the KLISS data model persistence architecture is – by design – sub-optimal for all possible use cases. It does not privilege any particular view of the data.
This agnosticism about data organization is a critical component of the KLISS workflow model which is the primary topic of this post. If you have been reading along in the series, it will come as no surprise that legislatures/parliaments pose many challenges when it comes to applying "off the shelf" standard models for databases or content management systems or video publishing systems. Central to the complexity, in my opinion, is that legislatures/parliaments resist analysis and decomposition. By that I mean that the standard methods of systems analysis and design pre-suppose that the analysis phase can result in the crisp expression of the "business rules" or the "workflows" that govern any particular domain. In the standard model, one does not begin implementing business rules/workflows until one understands what they are. This sounds abundantly sensible doesn't it?
Not so in legislatures/parliaments. I'm sure most readers will find that statement surprising. How hard can the rules be? In Civics class they talk about bills being introduced and debated and modified and voted on and passed into law. Seems like a pretty straight-forward workflow to me? Why not just walk around, ask everyone what they do in support of that workflow and then write it all down. Voila! One set of "as-is" business rules!
I would like to split the reasons why workflow is not that simple in legislatures/parliaments into the following seven areas (in no particular order), each of which is discussed below:
- 1. The workflow rules are cherished
- 2. The workflow rules can have non-rule lineage
- 3. The workflow rules are malleable
- 4. Every workflow rules has an exception which is itself, included in the rules
- 5. The workflow rules are instruments of differentiation
- 6. The workflow rules include the ability to suspend all rules
- 7. The workflow rules are an instrument in the art of politics
1. The workflow rules are cherished
Legislatures/Parliaments are generally grand old institutions. It goes with the territory that there is a lot of tradition and a lot of history behind how they operate. Unfortunately, the distinction between operating "rules" and operating "traditions" is easily lost in the mists of time.
Here is a pot-pourri of rules from my own experiences to give you a flavor of what I am talking about:
- The Finance Bill is always Bill number 7.
- Chairmanship of committee X lie with the Senate on odd numbered years.
- Amendments are worded differently if the Bill is at report stage.
- Votes of finance bills only can be considered after the 90th session day.
- Only one bill may be named in a motion to introduce.
- Bills cannot be directly referred to sub-committees.
- A sub-committee can continue to exist after its parent committee has been dissolved.
During analysis phases I have come across many rules such as these. It has been my experience that rules in legislatures/parliaments only have one thing truly in common. Namely, that they are cherished equally by staff and Members alike. Asking the dreaded question "why?" to any of the rules above and you are likely to get a reaction of the "because!" variety. Digging deeper, a variety of outcomes are possible:
- It may be that nobody can remember why the rule is the way it is but all agree that it is the way it is and probably cannot be changed just to help an IT project.
- It may be that there is a statutory reason (but the statute can change at any time).
- It may be that there is an explicit chamber rule (but the rules can change at any time).
- It may be that there is a precedent the explains the rule.
Practical upshot: Digging deeper into any of these rationales may result in "bottoming out" the rule but it may also result in another layer of detail that itself, needs further bottoming out. That bottoming process may or may not end.
2. The workflow rules can have non-rule lineage
In some cases, it is possible to bottom out the "why" of a rule only to find that it is something of an accident of history. A common example is rules that exist in order to work around problems in document processing over the years. Over time, the rationale for the rule gets lost and the rule ends up having the same status as other rules in the minds of the actors concerned. i.e. the rule becomes cherished. Some examples from my own experience:
- Rule: The markup code "@XYZ" is used to trigger double-spaced printing of bill drafts. (This, upon investigation, turned out to be a bug in a computer system from the Seventies. The system had no code "@XYZ" but somebody discovered that it had the useful side-effect of double spacing the bill drafts. The rule was subsequently added into the bill drafting guide, right alongside "real" rules for statute citation and quorum rules for conference committees.)
- Rule: All internal cross-references must take the form ABC (This upon investigation, turned out to be a rule created to work around a Word Perfect macro bug which would miss certain cross-references in the reports it was generating unless they were constructed just so.)
- Rule: The House is limited to 20 committees. (This turned out to be because of a fixed size lookup table for committee names in a mainframe application which set a maximum committee count to 20 on the House side and 20 on the Senate side.)
Practical upshot: Accidental workflow rules are still rules.
3. The workflow rules are malleable
The rule-sets of legislatures/parliaments invariably include the rule(s) that govern changing of the rules themselves. From an IT perspective, the presence of a rule that allows the rules to be changed has profound implications. It means – in one fell swoop – that any attempt at codifying the rules directly into a programming language is doomed to fail. Anybody who approaches a legislature/parliament attempting to map business rules to business logic to computer code, in the classic model, is going to get into trouble.
Practical upshot: the rules are not written in stone so they cannot be coded in stone either. In the IT vernacular, the "rules engine" for expressing and executing the rules of a legislature/parliament needs to be Turing complete. No approach based on, say, mapping finite state machine state transitions to middle-tier function calls is going to cut the mustard.
It could be argued that the rules might not change very often. One might point, for example, the 43 standing rules of the U.S. Senate. Whilst it is true that the rules of the U.S. Senate do not change very often there is a vast (and I do mean vast) set of precedents which are, in effect, rules. Precedents result whenever something happens on the floor that requires adjudication by the Parliamentarian. The amount of precedent grows over time. Every sitting day is an opportunity for new precedent – new rules – to be formed.
4. Every workflow rule has an exception
Remember how, it math class, your teacher exploded your brain by telling you that between every to numbers on the number line, lies another number? Business rules in legislatures/parliaments are very similar in my opinion. There may be a rule for what happens in situation X and a rule for what happens in situation Y but when Z occurs – a combination of situations X and Y – a new rule is born. This process can be repeated ad infinitum.
Practical upshot: The rules of a legislature/parliament are like a fractal. Between each pair of rules lies the potential for a literally infinite family of sub-rules. In this sense, the rules are somewhat like the corpus of law itself. Primarly law becomes denser and denser – more fractal like – as more and more refinement is added to the rules. Similarly caselaw interprets statute and once created, the caselaw itself becomes law (in the common law tradition at any rate). Then new caselaw can come along clarifying interpretation for cases that fall between existing caselaw and existing statute. This process can be repeated ad infinitum.
5. The workflow rules are instruments of differentiation
Speaking of fractals...organizational boundaries are fractal-like too. Consider a new legislature/parliament formed out of an existing one. Say, the New England States or the African countries that emerged from French/English/Dutch colonies...They may start as replicas of their parent institution but soon the differences start to appear. The new institutions differentiate themselves from their parents by injecting differences in how they operate. Over time, the injection of difference percolates the new institution. The chambers inject differences so that House procedure differs from Senate procedure. Appropriations committees do things differently than redistricting committees. The Senate creates a new form of Resolution, not used in the House. The House changes the way it numbers its rules so that they are visibly different from the Senate rules...etc. etc.
Practical upshot: Rules serve to differentiate as well as control the behavior of institutions. The human organizational need for differentiation essentially guarantees that rules will change even if there is no specific technical reason for the change.
6. The workflow rules include the ability to suspend all rules
This one needs little explanation. In an earlier post I mentioned Nomic. Suffice it to say that building computer systems that are capable of interpreting and checking and executing a set of rules is made significantly more complex if the rules can be disabled at any point.
7. The workflow rules are an instrument in the art of politics
This one also needs little explanation. Politics is, in my opinion, best understood in terms of game theory. Equilibria become more complex when the rules can be modified in a way that impacts the outcome matrix.
Conclusion
I hope the above has convinced you that getting to the bottom of the business rules of a legislature/parliament is no easy matter. It is not a question of effort. Doubling the number of resources trying to bottom out the rules will not help you. Doubling the time available to do it will not help you.
The workflows of legislatures/parliaments are, in my opinion, complex in the formal, mathematical sense of complex. That is to say, the feedback loop created by the self-referential nature of the rules combines with the other factors listed above to create a fascinating phenomenon in which homeostasis (i.e. stable parliamentary process and procedure) emerges as a sort of emergent property of the system as a whole.
Conclusion
The key, in my opinion, is to not let the surface complexity overwhelm you. After all, the very definition of an emergent property is one that arises out of a multiplicity of relatively simple operations that includes a feedback loop. The complexity can be tamed! However, taming it requires looking at the right level of abstraction. A full frontal assault based on decomposing the rules is about as likely to yield actionable understanding as decomposing the ants in an ant hill.
Over the years I have seen many fall into the trap of attempting to bottom out all the rules in a legislature/parliament. I tried it myself on more than one occasion. It is seductive. It would be great it if were possible, but it is not possible in my opinion.
What to do? The critical thing is to change the focus of the hunt. The hunt is not to find individual rules. The hunt is to find the relatively simple operations from which all rules are made.
That is what KLISS is based on. The application substrate it sits on has a workflow model based on this emergent model of workflows.
That is where we will go next.
Subscribe to:
Posts (Atom)