In part one, I discussed the
One aspect of the new development effort that hasn’t changed much in concept, but that has improved with time and experience, is the methodological approach. We have (almost) always been Agile development proponents, and as with anything practice makes one better. When we first worked on this initiative, Agile processes weren't exactly the rage, but from the earliest days of our firm we embraced the spirit of Agile processes and continue to do so to the present day.
Fast forward to 2015 and our development approach has continued to mature and improve. Today, as more and more organizations have been exposed to Agile methodologies, we find ourselves speaking with the business people constantly, developing and delivering the system incrementally, and adjusting quickly and dynamically when needed. I’m happy to report that some of the things we employed originally on the project have served us well on this new effort, including:
- A strong business team assigned by the client to the project. These were very knowledgeable and empowered people. As a result, we were able to understand key processes in a handful of sessions and we could make needed changes very efficiently.
- A small team of "coarse-grained" individuals on the team. We did and do have a relatively small team for the size of the system; all the developers were and are very strong and able to understand the areas of the business they worked on. We also had a small and hands-on leadership team that understood the business problems.
- A streamlined communications process. The development team was co-located and was constantly collaborating. Then as now, the client's key business and IT resources were always available to offer guidance to the team.
- Iterative development and release. The first version of the system, from ten years ago, went live with only the necessary modules. Since then it has grown very significantly in function as a result of a lot of user feedback that was incorporated over time.
The net of all of this is that rather than either IT or business holding knowledge tightly to their respective bosoms, we have worked collaboratively with business experts, freely exchanging information and ideas, which has resulted in more durable software.
Of course in any development project there are challenges, and even having a decade between projects can’t fix everything. Fortunately, a decade’s worth of experience and tool improvement helps immensely. One challenge was to find a way to develop the new system while keeping the old one up and running. This combined system then had to be presented to the end users as a single cohesive system. To this end, much of the early development effort went toward displaying the old systems pages in the new system’s user interface. However, even with this in place, we still had additional challenges when moving between systems.
A good example is customer search. As part of the new development effort, customer search was rewritten to be more intuitive to the users, eliminating fields that they didn’t use, making frequently used fields easier to access and adding more abilities to refine results. But the process of finding a customer might lead into a business process that we hadn’t rewritten, which was still running in the old system. So customer search had to seamlessly lead to either the new or old system depending on the process; and closing processes in the old system had to seamlessly bring you back to the new system.
More fundamentally, we have been challenged with an exercise in data modeling due to the data needs of the new system. An example of this is keeping historical versions. The old system generally kept only the current customer data. Going forward we wanted to be able to version this data so that we could see what it was like at a given point, and how the customer’s situation changed over time. In addition to rewriting the UI to bring this concept to the users, we had to rewrite the backend, including adding complexity to the database model.
However, there were still active pages in the old system that needed to read from and write to these tables. We ended up rewriting the stored procedures that these pages used so that the users didn’t see anything different, but behind the scenes we were going through the historical data and returning the version that this page was expecting. In the end it all worked seamlessly, but it’s just these kinds of challenges that make the balancing act between old and new systems so difficult and interesting.
As consultants, we’re almost always in situations where we’re reviewing and critiquing the systems and code writing of others, and it’s usually easy to find areas for improvement. However, when you’re reviewing your own, or at least your company’s system and code writing, it gets a little more delicate, particularly if some of the original resources are still involved. It’s human nature to think about things we’ve done in the past, and wish that we could somehow go back to something and do some of it differently. We’ve just had that chance, and I’d like to think we’ve made it better.
This blog entry has been republished with permission.
Readers are encouraged to respond using the “Add Your Comments” box below.
The opinions posted in this blog do not necessarily reflect those of Insurance Networking News or SourceMedia.
