Over a million developers have joined DZone.

Legislative Software on NetBeans

DZone 's Guide to

Legislative Software on NetBeans

· Java Zone ·
Free Resource

My name is Sean McGrath and I am the CTO of Propylon. Propylon is a product/services company focused on enterprise IT solutions for legislatures and parliaments around the world.

Legislative Workbench

Kansas Legislative Information Systems and Services (KLISS) is our end-to-end solution for all the IT needs of the Kansas Legislature, from bill drafting to statute codification and everything in between, such as chamber management, voting, committees, and decision support.

KLISS is built on our core Legislative Workbench (LWB) product. LWB is a comprehensive set of business applications that support the running of legislatures. LWB includes full document and workflow management, automated amendment engrossment, and true in-context and point-in-time archiving. LWB is highly customizable and can be tailored to each legislature's own working practices. LWB is the core of our applications used in the Pennsylvania and North Dakota legislatures.

Here is the LWB implementation used by the North Dakota legislature:

LWB is also used in the Irish parliament and in the Welsh assembly in Europe. We are currently in conversation with four other US states with a view to LWB implementations.

In contrast to LWB, most external legislative solutions are typically combinations of custom-designed "one off" systems, created by small IT companies, and internal, organically grown solutions. There are a number of similar applications in specific sub-domains (e.g., committee management) but LWB is the only proven product that covers all the functional aspects of a legislature or parliament.

Functional Requirements for Legislative Software

Law making is a very, very, complicated business. Rigorous, microscopic control over how the corpus of law changes with respect to time is critical to success. Getting it right involves paying a lot of attention to project management and risk mitigation because generally the "go live" opportunity dates for these systems are measured in year-based cycles. I.e., miss the projected end-date by one month and you have most likely missed the opportunity for one and probably many years. That's because most legislatures (at least in the US) operate on biennium cycles.

Here are some screenshots to illustrate various features in KLISS. Firstly, the tool for the engrossing of bills in KLISS:

Secondly, the time machine tool, which is our temporal repository asset viewer:

Finally, here is one of the many legislative division specific applications, which is used for drafting annotations in a specific format based on user selections:

On the face of it, applications such as KLISS are document-centric. However, in truth, they are audit-trail centric. They have more in common, at an enterprise-architecture level, with accounting systems than with traditional document management systems. The need to blend document management with auditing/accounting methods was the key driver behind the creation of LWB.

Evaluating Web, Desktop, and Mobile Technologies for Legislative Software

We make extensive use of web "thin clients" for portals and intranet-based data-entry applications, such as chamber in-session recording.

We also currently have projects on the way on tablets, smart phones, and WebTVs. The primary focus for these technologies will be on the chamber side of legislatures. I.e. these will be user interfaces aimed at consumers of legislative information such as members, lobbyists, agencies, and the general public.

However, legislation can require the creation of a 1000+ page document with rigorous control over all aspects of its style and presentation, down to controlling line and page numbers! This is beyond the capabilities of current browser-based WYSIWYG tools, both native JavaScript and plug-ins. Deciding to move to thin-client browser-based document editing tools is a question of how powerful they become. At the moment there are two main inhibitors to a completely thin LWB:

  1. The need for fine control over line/page numbers for amendment cycles. Legislatures have been doing it this way for hundreds of years. The trouble is, the rest of the world is moving to a new paradigm where line numbers really don't mean anything any more because text gets reflowed to fit in windows.

  2. The need to be able to deal with very large documents. In Ohio, a single appropriation bill can be 2300 pages long.

We are not actively looking at JavaFX as we anticipate a degree of volatility in the near term in this space. I.e., Adobe Flash, JavaFX, Microsoft Silverlight. We plan to wait and see how adoption of HTML 5 and connection oriented server-side technologies like node.js go, before we plan any move away from Java Swing-based user interfaces.

We use the NetBeans Platform as our application framework since KLISS and its LWB framework are based on native Swing components for workflow automation. We also embed a fully-functional OpenOffice suite, on top of which we layer our lawmaking customizations. The NetBeans Platform handles the embedding/layering for us, allowing our engineers to spend more time on the "business-facing" features of our LWB thick client application suites.

We have many, many tools within each LWB implementation. We started by creating an over-arching NetBeans Platform framework for creating customized thick-client applications. Typically, we have NetBeans Platform application suites for particular organizational divisions, such as for the legislative council, the chamber, and for fiscal analysis. Then, within those divisions, we typically have different NetBeans Platform applications for different roles, e.g., the drafting attorney, the journal clerk, and the fiscal analyst.

We have developers working in the USA (Lawrence, KS), Europe (Dublin), and India. Generally, when we commence a new LWB project, we base a team directly in the legislature. Thus, we have had branch offices in Harrisburg, Topeka, and Bismark in the USA at various stages, working with our core engineering teams mostly in Dublin and Lawrence. A typical LWB implementation would be about 18 months, start to finish, with a team of 10 to 15 people devoted to each implementation. This covers project managers, business analysts, architects, and developers.

Learning About the NetBeans Platform

We've been watching NetBeans evolution from the days when Eclipse was the only dominant open source tool in this space. Tim Bray and Simon Phipps were strong supporters of NetBeans. Also, we are big Python/Jython users in Propylon and Tim Bray organized a Dynamic Languages summit at Sun that I attended.

The netbeans.org site has a lot of great stuff on the NetBeans Platform but also we have found it very easy (generally speaking) to get good information from web searches of all the usual locations: blogs, mailing list archives, etc.

We have found the NetBeans Platform to be a very solid, productive environment. There is a learning curve but stick with it and you will be rewarded! On a related note, please be aware that we have career opportunities where knowledge of the NetBeans Platform would be useful.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}