Who should develop the database relational model diagrams?

Question

Developing a co-founded idea software product can have sometimes misunderstood information about roles and responsibilities. A Management role is responsible for understand and delegate the operator's role.

The next figure will produce a possible and hypothetical project structure from Steering Committee, Management Team, Project Manager, Scrum Master, Team Leader and Engineers Team:

Furthermore a database model for some platform needs to be developed and needs someone from the team to have the responsibility of this development.

A product have two kind of users:

1) Company Users;

2) Single Person Users;

Assuming all of this team have Computer Science backgrounds except Person A and for instance we can exclude as well Person E to clarify the answer. Although Person B have Computer Science background let's assume that this person expertise is more focus on user and customer solutions as human-computer interaction-like, also consider the workflow concentration of this Person B that is merging responsibilities for their own. The questions is:

Who should develop the database relational model diagrams in an organization structure like this?

Answer 1

This is far too open question to have a single answer, and you should probably put the question in the right context for us to help.

For instance, any of the developers could come up with an entire database model to fulfil theirs specific needs for their platform, so you could have a local specific Android database, a local iOS database, a local front-end database or database-like storage models and then we have the backend guys.

For now, I'm assuming you're talking about an application which is fully served by some arcane business logic that resides in the backend and from which all other platforms will leverage by the use of some kind of services/REST architecture (it's a big leap of assumptions I'm taking here).

If this is the case, everyone product-related (that excludes CEO and CFO, for example) should be together discussing what the system should do, and everything discussed should impact the database at some point somehow. That being said, the database design should be left to the technical guys which will develop the application, with the final word from the most senior developers for that product (people who knows well the impacts of a new single field or the removal of an old field, for example).

That's why you have senior developers (you do have them in your team, right ?) You pay a lot to hire smart guys, let the smart guys do their job. (Joel Spolsky has a nice article not exacly about this but with some nice insights).

This quote in particular is interesting:

There were some great examples of this. Managers always refused to resolve conflicts. Typically what would happen is that a designer would get into an argument with a developer over what a feature should look like. They would argue back and forth, discussing the issue for an hour, and eventually, failing to reach agreement, they would stomp into some manager’s office hoping for a resolution. Now you’ve got three people in the room: a designer, a developer, and a manager. Who’s the person who knows least about the problem? Obviously, it’s the manager — who was just hauled in at the last minute for Conflict Resolution. At Microsoft, the manager would usually refuse to make the decision. After all, they have the least information about the problem. The manager would generally force the designer and developer to work it out on their own, which, eventually, they did.

Answer 2

Any of the following roles should be capable of coming up with a database model:

• Back-End Engineer
• Full-stack Engineer
• Mobile Engineer
• Android Developer
• iOS Developer

But designing a database is not work for a single person/rol, all the roles I mentioned should participate and brainstorm around it. Even person A, which is not a computer science person, should be invited to discuss in the conceptual stage. This conceptual stage is not about tables but about business entities and a non-computer-related business person is able to point out flaws in this stage and his/her inputs can be taken as specialized requirement gathering material.

The consultancy of a DBA would be of great help also. Dunno whether back-end engineer is also a DBA, he/she could be.

Answer 3

There is no way to know for sure how to answer this without more information. If I were the PM I would know my team. I'd talk to the group or pick out the senior members first and figure out what to do. For a project this large it is difficult to think the PM wouldn't already know who his/her team is. We also don't know how good the PM is at the design, maybe they should spearhead it. There are too many variables. I don't think you can say, for sure, this guy and only this guy, can do it. And, based on the org chart, it is simply a blind choice after the PM, based on the context given here. For all I know the CTO should do it. Maybe that's the only project going on and the CTO likes to be a DBA. Who knows.

Simply put, if it were me, and I were the PM, and I didn't know who was the best at this aspect, I'd put them all in a room until we figured it out. Then I'd assign it and watch over it without being a Micromanager.

The question is over who should do it. I have no idea with the information provided.

It looks like it came out of a book, so hopefully it gave you more context.