Image
{{'2017-11-06T11:52:00.5089244Z' | utcToLocalDate }}
James Duggan

The problem with TDE and the challenge of T

I recently gave a SQL Supper talk as part of the Microsoft Future Decoded evening community events, and I made the point of not being impressed by Transparent Data Encryption (TDE), be it SQL Server, Azure SQL Database or Cosmos Db. I would like to explain why.

The problem of TDE

I have worked with data and storage engines for some time and therefore TDE seems straight-forward to me. I think a good overview of TDE for SQL Server, Azure SQL Database and Azure SQL Data Warehouse is given here, and I think a similarly good overview of TDE for Cosmos Db is given here.

I also interact with a lot of C# development teams on a daily basis and have done for years. I often find myself having to explain what TDE is, and more importantly, what it is not. And so it feels like Groundhog Day where I find myself repeating the same conversation, and over extended time, the same pattern of conversation.

Hopefully is should be clearer the problem is not really with TDE itself. It is an example or a technology nuance where it really matters that teams understand what it is and what it is not, and it seems making this understanding stick is hard. That this is perennial is inevitable and is a consequence of people churn, the departure and arrival of team members. This is illustrated below.

image

Departure, a knowledge drain, occurs for reasons such as promotion, seeking a new challenge in a new team or even in a new company. Arrival may be to replace an individual or to increase team size due to increased workload, and while every effort may be made to find a good fit, the new member will have gaps, perhaps not on TDE but somewhere else.

The challenge of T

Now that we see TDE is a specific within a larger problem, what is my beef with T. Well nothing actually. It is a lovely letter, just rolls of the tongue. Even its shape has become the common place analogy for describing an individual and their skills, the vertical bar representing the depth and expertise in a core skill, and the horizontal representing breadth, expertise and depth in more than one skill coupled with the ability to collaborate across disciplines. In the context of a development team requiring C# and Azure SQL Database skills we are seeking to move from individuals as experts in a single domain to individuals with breadth, having become strong in at least another domain, as show below.

T-Shaped

Certainly having a team composed of such uber-engineers should be a good thing. Indeed if all teams were similarly composed the problem would be solved, or would it? 

I think not, since people churn still has not been dealt with, for example:

  • How do we on-board new team members, what breadcrumbs are left behind to help them find their way?
  • What are a team’s responsibilities around ensuring they do find their way?
  • What should we be thinking about in the candidate selection and interview process to get individuals who are a good cultural fit and really do hit the ground running?
  • Do we need the weighty tome entitled “Our way or the highway” or is this best avoided?
  • What about contractors and consultancies? How do we ensure they are aligned to our enlightened ways?

Final thoughts

As I wrap up this post I realise that apart from seemingly going off-topic, I have posed more questions than provide solutions. So be it, as I have come to realise there are three areas of focus

  1. Educating teams in the nuances of the technology in use and the socialising of that knowledge.
  2. Developing skills breadth and depth
  3. Making knowledge sticky through culture and knowledge management to decrease new team member on-boarding and increase their effectiveness.
comments powered by Disqus