The State Bar had previously relied entirely on legacy midrange systems that were ill-equipped for web applications, necessitating a new class architecture on which to build the public site, including the My State Bar Profile and inter-agency web services (2GEFS) projects.

I created a 4-tier architecture that integrated the legacy data stores with current technologies, while maintaining separability in order to ensure easier platform migration in the future. In addition, this modular approach enabled seamless integration with third party vendors such as Lyris, Google, and Wells Fargo, as well as open source developments such as MoveableType and ASP.NET Forums.

Situation: The public attorney search application, the most popular page on the web site, was unreliable and cumbersome to use.

How I handled it:

1. Moved data and logic from legacy system onto ASP.NET platform: The original attorney search application was being served off of a legacy midrange server that was slow, expensive to maintain, and lacked modern web application features. I wrote a custom data mirroring application to regularly synchronize the data to a SQL Server, thereby creating a fast and reliable foundation on which to develop.
2. Accommodated natural user behavior: I collapsed the original 4-box search interface — bar number, first name, middle name, last name — into an intelligent one-box version that allowed users to type in full or partial names without having to separate the name (or bar number) into different boxes.
3. Offered alternate spellings: Forcing users to type search items in exactly can lead to frustration when the expected results don't show. I adapted the Double Metaphone algorithm (which is far superior to Soundex) to the search application and gave users the option to search on similarly sounding names and alternate spellings. Try it ».
4. Integrated with Google Search Appliance: Casual users, unaware of the specialized attorney search, simply typed in attorney names into the general site search, which produced seemingly random results that were sometimes misleading. I brought in a Google Search Appliance, for its flexible XML integration as well as its great search relevancy, and created a unified interface that searched web pages and attorney records simultaneously. Try it »

Result: The reliability shot up, and user complaints dropped from 3–4 per week to virtually none. Even the internal staff, who had access to much more sophisticated data access tools, often chose to use the public search application instead. The integration with the Google site search also reduced the number of libel threats from concerned attorneys who happened to share common names with disciplined attorneys.

Situation: Twice a year, the State Bar releases the bar exam results over the web at a specific date and time. The surge of traffic crippled the servers during the first ten minutes, subsequently generating many complaints.

How I handled it:

1. Re-evaluated entire delivery platform: Although the existing results application lived on load-balanced servers on a LAN connection inside a datacenter, it was still unable to handle the traffic. I assessed the entire process and determined that it was possible to deliver superior performance using a single server, in-house, on a pipeline that was 1/5 the size.
2. Created new optimized backend and frontend: Relying heavily on caching techniques, I tuned the application to deliver dynamic searches in microseconds, and minimized its dependence on the database server. On top of the heavy traffic, the results were also SSL-encrypted so page weight was another primary concern. I optimized the content and underlying HTML to fit inside a 2kb footprint.
3. Implemented end-user administration interface: The previous exam results application required manual handling by at least 2 different programming groups to get the results online. I streamlined the entire process to allow the non-technical exam administrator to prepare the release of the results with just a few clicks.

Result: The new application was able to handle up to 240 search requests/sec on a single server. The release of the exam results went by without a problem, and the Bar did not receive a single complaint about the application from any of the tens of thousands of users.

Situation: The State Bar lacked an intranet, relying on email or paper distributions to disseminate information. As a result, new or changed information was slow to reach every staff member, if at all.

How I handled it:

1. Created basic content management system: Because I wanted to leverage existing permissions defined by the Active Directory Service, I created a content management system in .NET to act as the foundation for the intranet. I also integrated MoveableType into the CMS to give nanopublishing capabilities to the Executive Director's office.
2. Extended Active Directory into searchable web interface: The existing methods to lookup employee profile information in applications like Outlook were very limited. Using the ADS's LDAP connector, I created a real-time web directory interface that allowed users to search for other employees by partial name, location, extension, department.
3. Implemented call center knowledge base: The Bar's various customer service representatives often received calls unrelated to their department, and lacked a central resource to find out where to transfer calls. I designed a knowledge base application that let representatives type in keywords or phrases, and get back a listing of related services along with their contact numbers and department descriptions.

Result: The intranet increased efficiency by bringing instant information access to users' fingertips, and drastically reduced the Bar's paper consumption — over 50,000 sheets/year alone on the employee directory.