|
This is pretty much a "software process" question: When your organization is split into two teams: software team and database engineering team (the organization is in ETL/BI/Data mining delivering terabyte sized reports and database dumps for research organization), What are the most common issues in coordination between such two teams? and how do you work around them? Precisely how much authority does a DBA have in dictating design versus a Software Engineer? |
||||
|
|
|
The database and development teams both have different perspectives. Both are important and need to be coordinated. Having someone from the database team as part of the development team would be a good idea. They should come to the project with standards and the ability to leverage existing corporate data for this project. The development teams perspective will be focused on the needs of the project. The life-cycle of the data within the project is typically measured in hours or days. After that data in many tables becomes historical artifacts. From the database teams perspective the data becomes part of the corporate assets. The data may need to be kept available for years. It is the database team which will have to maintain this data and eventually dispose of it. The database team should be more familiar with regulatory compliance issues which apply to the data. The issues under consideration should dictate whether the software team or database team should have precedence. Aiming for consensus is the best option. The two teams should be prepared to listen openly to the concerns of the other. Actively engaging the database team in the design should be encouraged. Try to avoid throwing issues over the wall. |
|||
|
|
|
The developer team needs someone with DBA-like skills, but they do not need a DBA because most of what the DBA does isn't of any use during the development project. The usual problems are that the database is handed over to the DBA for "tuning" before deployment, but then it is too late. The problem is that the DBA doesn't have a clue what the tables are supposed to be used for, how they are queried, who will be using the database and when they do it. When they find something to improve on, it often turns out to require a redesign. Very costly. Problems from the other perspective is that DBAs who aren't actively involved with the development lacks an understanding of most of the problems that needs to be dealt with during analysis or development and dismisses most issues as "it shouldn't happen with proper analysis". Which is true in a way, but too simplistic to be of any use. Rotating people between the different functions is a great way to transfer knowledge and enhance the working methods of both teams. Adds some project knowledge to the DBA team, and adds some DBA skills to the development teams. While I agree with much of what is written in this article, I think one-man teams are not optimal because of the lack of knowledge transfer. But I do agree with staffing teams with people like they describe. |
|||
|
|
|
Make database specialists part of the team rather than separate them. Database developers / development DBAs don't have to be full time on every project but they absolutely should be part of the team, be part of daily standups, reviews, etc and have joint ownership of deliverables along with the rest of the team. Produce database development guidelines up front and make sure everyone knows what they are for and how to apply them. Make sure that testing with realistically-sized data is part of every iteration and every test cycle - not just the later ones. This step alone should address most of the problems and tensions that can occur between developers and DBAs. Adopt agile, iterative database development approaches. That means evolutionary database design, continuous integration, a high degree of database normalization and a rigorous approach to business rules (apply keys and other integrity constraints early and then remove them later if you find the need to). |
|||||||
|
|
I don't think there's a right or wrong answer to this one. However, I've been in similar situations in the past, and often the politics and organisational history determined who had which role, rather than a rational decision based on the needs of the project. For instance, in one team, every database table had to be approved by a dba; this slowed down the team tremendously, made the DBAs grumpy and overworked, and when we asked why this process was instituted, nobody could remember -so we got rid of it. In your case, I'm guessing database performance is a key part of your success. The best model I've seen is to have multi-disciplinary teams work on specific features; within the team, you work out who's in the lead. It's much, much easier to work in a team where every specialism is represented (even if only part time) than between formal department boundaries. |
|||||
|
|
In our case DBAs do not dictate design. However - they do have a set of guidelines (Do's/Donts) for the development team to follow while creating databases, deploying databases or deploying scripts or SSIS jobs or SSRS reports. The nature of DBA role is shared across projects and they are mostly overloaded with requests and thats the most common problem or issue. The solution is enough lead time and follow up. How much is enough?? - Talk to your DBA and know.. |
|||
|
|
