Modern Information Technology work is all about outcomes.
Market pressures, competitive differentiators, customer service expectations and new capabilities are just a few of the reasons that insurers are sprinting to enable new technologies and processes that support their strategic goals and objectives. For people consulting and working in IT divisions that usually means long hours, shifting priorities and making decisions as quickly as possible with the information available. That’s all well and good, but a recent experience has suggested an alternative approach.
One of the issues with the current technology tsunami is that it can be difficult for those working on IT initiatives to gain a fuller understanding of why a particular technology project is being put together the way it is, as opposed to just having a rudimentary understanding of what the technology is supposed to be doing. That's an important distinction and one that deserves further consideration, as this article will attempt to do.
For most developers, architects, data administrators and others on IT projects, it can be very easy to fall into the trap of only understanding how something is supposed to work in a rush to get new capabilities into production. One sure sign of this can be the introduction of new tools and frameworks as part of a new project that is duplicative of the tools and frameworks already in use. This leads to technology tunnel vision, with IT resources having an even narrower understanding of a new project, focusing only on their piece of the technology pie for the effort.
Again, this is understandable given the short-term pressures of delivering, but it can be detrimental over the longer term in the context of developing well-rounded IT people who understand more than what something is supposed to do. The problems with this kind of approach are many and well documented, but a short list includes the likelihood of repeating patterns and mistakes from previous projects, IT people who are too narrowly skilled and focused on only what they’ve done in the past, and an unwillingness to be open to new technologies and approaches that might be beneficial to any insurer. And a good deal of this can be attributed to focusing on the execution-driven issues (what and how), rather than the purpose-driven (why) business technology issues.
That said, there are a couple of ways to begin to break this cycle, but both will take a company’s commitment to altering at least some of its IT project approach. One is to allow the time on a new project to focus on the why, or purpose-driven questions: why that architecture, why that platform, why that technology stack, why that database approach, etc. And when time doesn’t allow such an approach (which might be almost always), an alternative and perhaps more practical approach is to allow the purpose-driven questions (as opposed to the execution-driven questions) to be considered on subsequent project rework, maintenance and upgrade cycles. There’s a risk to that, but there’s also a risk of being late to the market with new technology capabilities, so those tradeoffs must be considered.
Of course being part of a team considering the purpose-driven questions when implementing a project from the ground-up can provide valuable experience for IT developers and others. Among them are:
• Ingraining the importance of considering the purpose-driven questions before starting on any subsequent IT project
• Providing time to evaluate technology and process patterns for the best fit for any particular project
• Offering time to dissect previous decisions made about architecture and database approaches
• Giving IT people an opportunity to discover and discuss the things they don't know about technology or project
As suggested earlier, recent experience on a project provided a valuable opportunity for asking such purpose-driven questions. The application had the same architecture and technology stack as the one from an immediately prior assignment. This provided a good opportunity to look at another application using the same technology stack, and evaluate more closely the why, instead of merely accepting the architecture and copying it blindly in the new project. Essentially the prior project could be used as a reference architecture comparison point leading to asking why it was designed as it was and why a specific approach was chosen for the project.
This proved invaluable from an educational and a qualitative perspective and forced the kind of thinking and re-evaluations to occur that often don't happen in the first go-round of IT projects. In this latest project, the opportunity to consider the purpose-driven questions proved essential for professional development and skills growth, and the ability to carry the lessons forward into future projects.
And from a more practical perspective, having more than just the architect understand why certain decisions have been made is a good hedge against sudden staff changes and critical knowledge walking out the door. When that happens, the use of ineffective patterns in the race just to complete the project at whatever the cost can quickly dilute the deliverables for any project. That said, the experience of being able to ask purpose-driven questions allowed for the reconsideration of the architectural approach rather than just accepting what was already in place. Asking the fundamental why questions also opened the doors to better problem-solving skills.
After all, architecture or technology that works well for one project may not be the right thing for the next project. It may seem obvious in hindsight, but seeing and understanding the patterns and architectures – along with the reasoning – behind something can easily and quickly get lost if there isn’t enough time to carefully think about an approach and ask questions about why things were done the way they were done. For this project, some of those why questions were things like:
• Why was this application designed the way it was?
• Is this application solving the problem it was created to address, and why is it or is it not doing it well enough?
• Why was the architecture deployed chosen over others?
• Is there a better approach or why should this application remain in place?
Determinedly answering these questions has a direct impact on the overall quality of the project and its deliverables. In all, the purpose-driven approach can lead to benefits such as:
• Technology Agility: knowing when and when not to use specific patterns
• Maintainability: hedging against IT staff changes by spreading knowledge
• Upgradability: designing and implementing with upgrades in mind
• Integration: understanding ahead of time prevents problems later
• Skills Development: overall IT staff gets better
These and other benefits seem like as good as reasons as any to ask and answer the why questions. And while that might take a little more time up front, it will inevitably take several times longer to answer them after the project is in production.
By Jason Brown, X by 2