Preventing knowledge silos

Sam de Melo

Preventing knowledge silos

Hello all.

I've been working at a SaaS startup of about 50 employees, and I'm the only data professional. This is a company that experienced rapid growth in recent years, but has relied heavily on ORMs in software development, and sees data as a byproduct of its software.

The design of the data model in the RDBMS has been largely driven by application/technology needs, rather than business needs.

I've been trying to introduce business-driven data architecture, which involves normalizing our relational data models, but in order for an object-oriented application to work with such, it would require that it accesses our data only through the database's external layer (views, functions, procedures, etc).

There have been concerns in the organization that, if we were to implement this layer, I'd be the only person able to maintain it, thus creating a knowledge silo.

While I can understand that argument, I don't see how we're going to achieve our goals with  highly denormalized, tech-driven data models on an RDBMS.

Has anybody had similar experiences that you could share, and how you've handled them?

Merrill Albert

RE: Preventing knowledge silos
(in response to Sam de Melo)

I worked one place where I was the only one creating and maintaining data models.  The key was communication.  I had those data models documented to within an inch of their lives.  After initial creation, I conducted reviews so everyone could understand the models.  Whenever I made changes, I would do reviews and send out documentation of the before and after changes.  The meetings were informative and everyone wanted to come.  All seats were full and people standing in the back.  When I left the company, I gave my manager a review of all models and showed him where all the documentation was, including the full history of every change.  He said he had never seen something documented so well.  It's always going to be hard for someone new coming in and trying to understand the reasoning behind the data models, but it sure helps if you've thoroughly documented it.

Sam de Melo

RE: Preventing knowledge silos
(in response to Merrill Albert)

Merril,

Thank you for your reply.

You said you were the only one at your company doing the data modelling. Who was responsible for that before you joined, and how was that transition of responsibilities like?

I've already suggested documentation as a means to mitigate the effects of a potential silo.

Merrill Albert

RE: Preventing knowledge silos
(in response to Sam de Melo)

No one was responsible for it before I joined.  Someone had ideas, but he hadn't created anything, so I had the benefit of greenfield.

William McKnight

RE: Preventing knowledge silos
(in response to Sam de Melo)

Even some larger organizations do little to no custom data modeling, relying on industry models and data file layouts instead. I think they do this at their peril. At some point of maturity, an organization needs to model their business so they can understand it better and operate efficiently. A non-modeling approach will bog down development. You think your organization is at that point, but they are probably not trusting of doing anything different - learning curve, etc. I think you can find some selling points by showing how even one application will get to market faster if you actually do modeling for it. And then you also have a model that is leveragable to other uses. To do this, you'll probably have to be sure you're talking about a full lifecycle project and not a sprint. It's a matter of pulling the focus a little more broadly. 

Sam de Melo

RE: Preventing knowledge silos
(in response to William McKnight)

Hey William,

In our case we've been modeling data after our application classes and APIs. The tables are used to persist the state of these classes. One of the main reasons they're not trusting of doing it differently is that I'd be the only one who's able to maintain it. They're concerned about knowledge silos, especially when it comes to having a database abstraction layer to hide all the details and complexity of a normalized database.

I'm sure I'm not the only one in the city who knows SQL. If I left the company I'm sure they'd find someone else. In the mean time, there would be nothing stopping them from reverting back to how they've always done things, so I don't think this is a major business continuity risk like they're framing it.

Have you had experience navigating this sort of situation, or is this quite unique?

 



In Reply to William McKnight:

Even some larger organizations do little to no custom data modeling, relying on industry models and data file layouts instead. I think they do this at their peril. At some point of maturity, an organization needs to model their business so they can understand it better and operate efficiently. A non-modeling approach will bog down development. You think your organization is at that point, but they are probably not trusting of doing anything different - learning curve, etc. I think you can find some selling points by showing how even one application will get to market faster if you actually do modeling for it. And then you also have a model that is leveragable to other uses. To do this, you'll probably have to be sure you're talking about a full lifecycle project and not a sprint. It's a matter of pulling the focus a little more broadly. 

Edited By:
Sam de Melo[All DATAVERSITY Members] @ Jul 23, 2020 - 08:27 AM (America/Pacific)