Imminent project failure Averted!
Sometimes even the best projects can suffer a devastating blow that leaves the team and stakeholders reeling.
Such was a project that I worked on a few years back. It was a two-year development project that started off the back of the previous eighteen months of requirements gathering and business analysis. The scope was huge and the vision ambitious; a world first for the broadcast industry.
One month before go-live, it suddenly came to light that one of the critical 3rd party systems actually stored its files across two separate file systems in Production. This was not the case in Dev, Test, or Staging environments, all of which used a single file system, as this would have introduced hefty additional licence costs on an already expensive piece of software.
The rest of the systems, that formed part of the solution, only catered for one file system on this component. Consequently, roughly fifty percent of the company’s content would be inaccessible in the Production environment. We would know it was there; we just wouldn’t be able to reach it.
The stakeholders were, understandably concerned (I’m being polite). This was an important piece of information to have missed and the entire project was suddenly at risk. A conversation with the vendor revealed that they could resolve the issue but the upgrade would take at least three months to implement, probably more.
The question went out to all internal teams; how long will it take to change your implementation to cater for multiple file systems on the Content Management System? The answers came back; six to eight weeks minimum.
When they posed the question to my team, our tech lead — a true Mule Whisperer — gave the matter some thought. In fact, he stayed up all night working on a solution. What he came back with was brilliant in its simplicity.
He whispered…
… and the Mule delivered!
He designed a service that was geared for multiple file systems, along with a simple config-driven routing mechanism to determine which file system contained a given piece of content. By switching all of our consumers from the 3rd party system to query this new API, the rest of our system could continue working in blissful ignorance of the underlying file infrastructure challenges.
Furthermore, any other system in the solution landscape could query this same API instead of calling the 3rd party component directly.
Design: one all-nighter
Implementation: 4 days
… and every system across the network switched. Crisis averted.