Why is it so difficult to get good TDA?

For the purpose of gaining clarity, it may be judicious in the first instance to provide a definition for TDA (technical design authority) as it’s an abbreviation that’s often bandied around in the IT industry but not always fully understood.

Essentially, TDA is the ability to review a solution in detail to ensure that it:

• Is scoped to the true extent of the project
• Delivers to a set of agreed business objectives
• Ensures that the required technologies will work together
• Identifies any issues that have not been addressed in the requirement specifications and recommends solutions
• Highlight interdependencies that will exist within existing and proposed systems to ensure interoperability
• Pinpoints any limitations in the proposed solution

The challenge for most organisations is that very few people have the experience and breadth of technical knowledge to understand in detail all the systems within a solution and their individual working parameters and requirements. As converged networks are increasingly adopted, the consolidation of voice, video and data applications over a single network creates many technical hurdles that need to be eliminated; if you don’t have the breadth and depth of experience, not only will you not address them, you may also not realise they even exist. The end result is a solution that does meet the business requirement and a project that fails to deliver.

At a strategic level, the TDA function allows companies to overcome the complexities of scoping and installing converged voice, data and video infrastructures by addressing the project holistically and encompassing everything from the business requirements specification, technical architecture review and design through to carrier and vendor selection and management.

One common mistake is to incorporate the TDA function too late in the programme. TDA needs to be in place at the project’s inception such that risk can be minimised from the start. Too often TDA is engaged either after the solution has been procured, for isolated components, or after the project has failed.

When we talk about a “good TDA”, we’re really talking about the person who’s implementing the process; when you look at the list of skills essential to providing a good TDA, it’s not surprising that so few individuals cut the mustard:

• Excellent communication and interpersonal skills
• Excellent programme management skills and attention to detail
• Large deployed solutions knowledge (5-10 years)
• Carrier knowledge
• Manufacturer knowledge
• WAN technical knowledge
• LAN technical knowledge
• Application deployment knowledge
• Hardware knowledge

Assuming you’re fortunate enough to find this candidate, i.e. if you beat SAS to employing the individual, these are the primary benefits your TDA exec should deliver:

• Technical design team leadership
• Consultancy on industry best-practises for architecture design and quality control
• Global standards consultation and implementation
• Third part solutions auditing
• In-life support model design
• In-life support management

But seriously, if you’re in the market for a good TDA, my recommendation would be to look for an ex IT Manager/Director; someone with technical qualifications, such as a CCIE, Prince II and Microsoft MCE, who has long term experience of managing a converged infrastructure. As ever these people are difficult to find - let alone employ.

And beware. There are many imposters; people who can talk the talk but have limited ability to walk the walk. Some, I would almost describe as serial network killers, individuals who go from one failed project to another. Ultimately, good TDAs are few and far between; mediocre and poor TDAs are all too abundant. What’s more, as the knowledge gap starts to grow between employers and IT staff, the risk of recruiting a poor TDA becomes ever increasing.

At a personal level, I have seen so many customers that have placed their entire trust in an IT consultant who is peddling what they have peddled before and sometimes for the last 5-10 years. The same products and services are forced together into an ill fitting solution.

Convergence lends itself beautifully to these hoaxers and just looking at recent events, I could cite several examples where companies have deployed convergence with a non-CoS enabled network; generally, the TDAs have assured their bosses that CoS is an expensive and unnecessary solution. In one particular example, the company wanted to run six concurrent Citrix sessions, three voice calls along with background Internet and email traffic. The whole design centred on an MPLS product from a carrier that was not able to offer an MPLS network, let alone provide CoS. The proposed design also featured DSL circuits with a maximum upload speed of 256k and applications that were not optimised for WAN use. The whole project cost about £300k but was doomed from the outset so, not only had the company made a large investment in a network that didn’t work, it was also tied into a long term carrier with a provider that couldn’t provide. Alarming, but not that rare!

Overall, a good TDA can save you money, prevent your projects from failing, and help you keep your job. In all honesty, your best chance of getting a good TDA is to work with an infrastructure consultancy or contractor, but then of course I am slightly biased on that topic. However you managed to find a good TDA, do you best to keep them as long as you can. They are the most rare thing in IT and generally the key to every successful IT project.