Blue Lucy – It’s time to hit refresh on the product roadmap
Joshua Martin, head of product at Blue Lucy
We’re always being asked about our roadmap for BLAM, when really what most people want to know is what features or integrations we’ve got planned. And if you think that’s the same thing, think again.
Technology that serves the media and entertainment industry has historically suffered long product development and rollout cycles – planned way in advance and released twice a year around key industry exhibitions. This made sense because developing and updating hardware was expensive and time-consuming, and doing so more frequently than twice a year just wasn’t financially viable.
The move to SaaS has removed these barriers to product releases and rollouts which now happen at the push of a button. As a result, many products are now released quarterly and some even more frequently. We release major BLAM updates up to nine times a year because we believe that making smaller, more frequent changes to the product code brings the risk profile down.
But, while updates may take place more frequently, the features and integrations for most products are still dictated by a roadmap that extends as far ahead as the next 6, 12 or even 18 months. In the same way that SaaS redefined the rollout of updates, we believe that the move towards microservices has the potential to change how we roadmap product development.
It’s not the destination it’s the journey (that’s changing)
The fact of the matter is that technology, and the industry’s requirements from technology, now move way too quickly for all product planning to be done on an annual or even biannual basis. The industry demands an agile approach to development that can respond to changing needs as they evolve. In the same way that the RFP and RFC processes are facing criticism and calls for redesign because (amongst other things) the solutions they describe are outdated by the time they are delivered, so too have lengthy product development cycles become poorly suited for purpose.
To be clear – we’re not suggesting that a roadmap isn’t an essential part of any product’s development, we’re just questioning what a modern roadmap should look like.
Our situation is not too dissimilar to the evolution of actual roadmaps. Years ago, you might spend a considerable amount of time plotting a detailed route from your starting point to your end destination in an A-Z guide – and any deviation from this route required significant effort to ‘get back on track.’ Now, we simply enter our end destination into a satnav that automatically calculates the best route and continues to optimise that route throughout the journey based on changing circumstances, whether that be an unexpected diversion, traffic conditions or anything else we throw at it.
Similarly, we believe that technology roadmaps should still have an ultimate destination – but that not every twist and turn in our journey towards that destination needs to be decided before we pull out of the driveway. This is where the differentiation between core architecture and integrations comes in. If you think of the core architecture as the destination, the development of this underlying technology should absolutely be road mapped and planned in advance in the same way that decide where you plan to end up before you get in the car. But, like pitstops and photo opps along your route, individual integrations with different products don’t necessarily need to be mapped out far in advance – and changes to these shouldn’t affect the ultimate destination.
How microservices deliver the best of both worlds
BLAM makes use of microservices to integrate different products and tools into our platform, achieving the ‘best of both worlds’ by combining the stability of a defined roadmap for the core product with microservices providing the flexibility to accommodate changing industry needs and specific customer requirements. In BLAM, these microservices are developed according to industry needs, specific client requests or partnerships.
So, instead of having to embark on a lengthy development project to incorporate a new AI tool into your workflow, we can quickly create a microservice to integrate the tool into your workflow in far less time. And, if you find another tool that you prefer, we can simply swap that microservice out for another, because an orchestration engine is only really effective if it’s agile enough to integrate with the tools you need, when you need them. This approach improves our product, makes it work well with other technologies and provides essential functionality for our clients – allowing you to take advantage of better pricing and new product capabilities while benefitting from the efficiencies of workflow automation.
But you won’t find microservices on our roadmap because they’re an addition to, rather than a part of, our core product. And, because they can be developed at any point without throwing our product roadmap off course, you get all the benefit of the integrations they provide without getting stuck in development traffic jams.
