Bail out

This is actually a story from a colleague of mine who did a short piece of Technical Architecture work for a large European Telecommunications company.

He was contracted by the Architecture group who had just spent the previous several months putting together a plan to “re-architect” some of their systems, which had previously been put in place a few years before by a different team, and which were no longer performing as needed by the business. Part of this work involved putting together an RFQ for one of the main systems, approaching various vendors and inviting them to respond to the RFQ, and selecting one.

Now this team had three “Architects” working on this project. All of them were highly paid, wore sharp suits, and could knock up a mean Powerpoint. At a push they could probably draw convincing looking boxes on a whiteboard.

All of these are, of course, often the primary qualifications to be a “Technical Architect” in today’s world.

My colleague isn’t a typical Technical Architect: he actually knows stuff! More specifically, he actually knows products beyond the buzzwords and the marketing PDFs on the vendors website. Like me, he’s used most of these products and, when I say “used” I mean personally installed, configured, integrated, and operated them.

As such he actually understands these products very well. He is what I refer to as a Technical Architect Plus.

He was contracted by this group because, after several rounds of presentations and meetings, they had been given the green light on their re-architecture project, along with a budget of around £15 million. About £12 million of that was the cost of replacing the primary system with the newly chosen one including the costs of licences, professional services, integration, operational training, and so on.

At this point, they realised they were out of their depth, so the pulled in a real more experienced Technical Architect to help them, basically to bail them out.

When he came in, the first thing he did was to review their plans. Apparently they were not good. But the biggest issue was the vendor selection. He was asked to present his findings at a meeting which included the Architecture team and some of the bigwigs in the organisation, where he dropped the bombshell…

“The best system for what you are trying to do is the one you already have.”

It turns out that, as with so many other things, the people making the vendor selection not only didn’t understand the problem, but hadn’t considered that the product they already had was capable of doing what they wanted. I suspect that this is because a lot of people who really don’t understand technology that well also don’t understand that many platforms and frameworks are generic and customisable, and that customisation is often needed to make them do specific things.

They assumed that, as the existing system wan’t working well, it must be incapable. It hadn’t occurred to them that it simply hadn’t been programmed to support the new functionality required by the business.

In the end he saved the company the best part of £12 million and accelerated their plans by several months, all by actually knowing what he was doing.






Leave a Reply

Your email address will not be published. Required fields are marked *