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:

enter image description here

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?

  • 2
    How large is this project? I can only imagine that, if you're already contemplating an org chart this intricate, that the project must be enormous, on the order of a million lines of code or more. – Robert Harvey Dec 29 '16 at 1:09
  • 3
    Then let the guy who knows the most about database architecture take the lead on it. – Robert Harvey Dec 29 '16 at 1:12
  • 2
    If he has the most architectural and database experience, yes. While it's fine to give specific titles to specific people, a healthy team of this size is going to be cross-functional; the specific categories of duties that each person is going to be responsible for aren't going to be nearly as neat and tidy as your diagram suggests. – Robert Harvey Dec 29 '16 at 1:14
  • 3
    Probably. However, if your database guy knows what he's doing, you shouldn't need to draw any database relational models. You sketch a tentative model on a whiteboard or napkin, create the database from that model, and then, when you're satisfied with your first stab, use automated tools to draw the relational model against the database so created. – Robert Harvey Dec 29 '16 at 1:22
  • 2
    You draw a plan to communicate the work you intend to do. There is no reason to do that if no one needs to know ahead of time. Don't spend a lot of time doing than when you could whip out one real table and see how well it works for people. Delivering something quickly and seeing how well it does is the heart of agile. – candied_orange Dec 29 '16 at 2:57

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.

  • Let us suppose that the organization just have 4 people in the team: Person A, Person B, Person C and Person D; where Person A do not have technical knowledge. Assume this, and assume that the question just asks about who should do the database relational model diagrams?. – Francisco Maria Calisto Dec 29 '16 at 12:02
  • 1
    Why not the inverse question ? Who shouldn't do the DERs ? It seems to me that you already has the answer to that. A non-technical guy shouldn't be messing around with the bits and bytes of the application (for instance, deciding if a database field should be float or decimal), simply because he does not have the backgroud for so. But non-technical people may have extreme knowledge of the domain of the problem being solved, which may impact the relation of your business entities, thus impacting your database model. – Machado Dec 29 '16 at 12:08
  • 1
    So, it's your job as a technical guy to do properly the model diagrams, but is also your role to listen to non-technical guys who does have knowledge about the domain of the problem. – Machado Dec 29 '16 at 12:09
  • 1
    A Project Manager (B) should be managing the project. Getting out of way with bureaucracy and finding resources so developers should get things done. A Scrum Master (also B) may have some say in the DB diagrams, but the final word must be from the developers (C) and team leaders (C) assuming the team leaders are technical leaders, people which really work directly with the database. – Machado Dec 29 '16 at 12:19
  • 1
    By the way, this other Joel's article may interest you also: joelonsoftware.com/2006/04/11/… – Machado Dec 29 '16 at 12:21

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.

  • I like "Any them should". However, there could also be a person F who designs and implements the database. Really this chart isn't about people. It's about roles. I've been all these people. Some times at the same time. You wear the hat(s) the team needs you to wear. – candied_orange Dec 29 '16 at 12:10
  • @CandiedOrange Changed person to role in some places. – Tulains Córdova Dec 29 '16 at 12:21

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.

  • I updated the question to be more clarify. Please tell me how to improve the question. Thank you. – Francisco Maria Calisto Dec 29 '16 at 16:17
  • Try to understand that Person B is the CTO + PM + SM. – Francisco Maria Calisto Dec 29 '16 at 16:19
  • 1
    @FranciscoMariaCalisto Is this from a book? – johnny Dec 29 '16 at 16:27
  • No this is from a real project with a similar problem. – Francisco Maria Calisto Dec 29 '16 at 16:28
  • 2
    @FranciscoMariaCalisto From my perspective it is impossible to tell who should do it. My experience is that it just doesn't work that way if you have to ask who should do it. The PM or CTO or whoever, should already know and if they don't they have to ask who is best at it. If someone was hired to do just that, then you know who should do it. Outside of that with only an org chart there is no way to know. – johnny Dec 29 '16 at 16:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.