Thursday, July 12, 2018

Changing Frameworks – The Court Component Model and Agile Approaches

Graphic courtesy of Oriental Journal of Computer Science and Technology article "Component
As promised in the recent post introducing the Court Component Model (CCM), some of our NCSC colleagues and partners will be sharing their perspectives on the CCM and ways it can be applied in real-world projects.

NCSC's very own Barb Holmes shares the following on her experiences working in the Pennsylvania Courts and how they combined a component-based approach with agile methods to tackle complex business problems and ever-changing requirements.

---


After 25 years in software development for a statewide court system, it was easy for me to understand the usefulness of agile approaches.  We developed iterative and team approaches very early after many challenging projects that involved water-fall approaches that were painful, especially when contracting for services.  Every change was an issue and the battle cry of “that is a new requirement!” often sparked heated conflict between developers and business stakeholders.

Our more agile approaches promoted user involvement and team development, reducing conflict and allowing for the ever-changing nature and evolution of business requirements. As our processes improved, they greatly reduced re-work and the introduction of bugs.

I understand more about why this approach works as I have become more deeply involved in SCRUM.   The empirical nature of the framework promotes transparency, inspection, and adaptation.  It engages users and promotes constant feedback to better meet business needs. Breaking product backlog into sprint backlogs – logical portions of functionality - is important for continuous feedback.


The Court Component Model intertwines with agile approaches in breaking down the business needs of courts logically.  While the court system I worked for often chose to build rather than buy software, when the time came to purchase Electronic Content Management (ECM) software, we had to take a step back and say “can we efficiently build something better than what is on the market to manage our documents?”  After a lot of research, the answer was definitely “no!”  In the changing environment of highly configurable software that is more reasonable to purchase, there are a lot more options across the board for all types of software with accessible interfaces.

My ECM experience taught me that these companies often purchased components separately as well.  For example, we could trade out their “default” full-text tool for another tool that worked better.  Companies throughout the software industry are picking and choosing other tools to acquire and other business partners to work with to leverage their own component models.

Another example of this is the use of e-commerce interfaces to interact with bank software for electronic payment processing. In many cases, these can be traded out rather easily as most of their banking processes and interfaces are very similar.

Looking at court business software needs from a component perspective can allow you to constantly re-evaluate the changing and evolving nature of industry offerings, potentially without requiring you to do a lot of recoding because of the standardization of interfaces.  You may decide to completely replace a component with a richer offering on a periodic basis, much like we would often re-write entire modules.

How have you have begun to mesh the Court Component Model with your agile software environment and what components have you begun to explore?  Examples of practical uses of this framework can benefit other courts and help us all work toward a more agile business environment.

No comments:

Post a Comment