Database Reorganisation

In 2014, I reorganised 1&1 Internet’s database structure to reduce tensions between IT teams.

The company’s database administration (DBA) team was flooded with requests from other IT teams in the company. Delivery times on those requests were long which, in turn, stalled other teams. Everyone was unhappy with the situation.

By giving other IT teams within the company access to databases, product and business teams became more agile. The database administration team could also perform better again.

The Customer: United Internet AG / 1&1 Internet

United Internet AG is one of Europe’s biggest internet specialists. The German company provides both internet access (DSL, mobile internet, etc.) in Germany, as well as web hosting, servers, software and a range of other applications all over Europe and North America.

1&1 Internet is a hosting and e-business solution provider and one of United Internet’s main brands.

The Issue: High Latency & Tensions Between Teams

The trigger for the database reorganisation project were tensions between the database administration team (DBA) and various IT teams at 1&1 Internet.

The long chain of custody

Whenever an IT team needed something related to databases, they had to put in a request with the DBA team, which is located in a different department. Requests had to travel through the chain of custody — from IT team to department head to another department head who would then hand the request off to the DBA team.

The DBA team got requests from not just one team in the company, but many. They prioritised those requests according to their own internal logic. Naturally, one team’s priorities didn’t always align with those of another team.

In the ad server business things sometimes have to move very fast. When customer-facing teams need a new database for a project, they may only need it for a few weeks, but they need it set up fast. A lead time of a few weeks would completely stall their project.

Different teams, different priorities

IT teams in other departments wanted to be able to move faster and felt hindered by the DBA team. The DBA team, in turn, got annoyed by the constant requests coming at them from all sides, many of them labelled “urgent”. Unfulfilled database requests stalled product teams in their work.

No one was to blame. It was simply that the perception of what was “urgent” was a little different for everyone. But the continuous tension between the two teams was becoming a problem.

The Solution: Distribute the workload

When IT teams didn’t have access to databases, the responsibility for projects was a shared one. The boundaries were unclear, and any collaboration between two teams became rife with friction.

To release the tension, we would have to unravel responsibilities and make sure everyone’s skills were put to their best use.

Teams can make their own database decisions

We shortened the chain of custody for requests and sped up delivery times by moving away from the standard siloed database model. The new database structure gives all IT teams access to databases that relate to their work. Over three months, we migrated more than 180 databases to directly responsible teams.

Giving IT teams team ownership over their databases — to the extent of their expertise — means they don’t have to bother the DBA team for “every little thing” anymore. We’re letting them make their own decisions about the urgency of their own projects. By doing a lot of their own database work themselves, IT teams can react faster and move their projects along at a greater speed.

Focusing on expertise

This has freed up the DBA team, allowing them to focus on work that requires their specific know-how and skills. By not having to deal with the constant small requests, they’ve become more agile when it comes to the big database issues that need their attention.

Now, whenever and IT team requires a database administrator’s expertise, the DBA team can quickly send someone to help.

All teams became more agile — and more satisfied. IT teams enjoy not having to argue their priorities with a team from a completely different department. Database administrators appreciate being asked to bring their expertise to actual database-related problems.

The Dangers & Difficulties: Changing Isn’t Easy

Databases hold valuable and critical data and are among the best-protected assets in companies. Consequently, they’re also well-protected from change. This makes it a little difficult to adapt an existing system to the changing needs of a company.

To successfully change such a delicate area of business, I had to figure out what each team needed and how I could help them achieve their goals.

To get everyone on board, I had to show them the vision of a database structure with clearly outlined responsibilities. We defined objectives together and facilitated communication across departments through regular meetings on an operative level.

A pre-defined escalation process

The transfer of database ownership from one team to another was thoroughly organised and accompanied by workshops. The DBA team themselves trained the people who would be responsible for their own databases. This way the DBA team was reassured that the databases would be in good and capable hands.

We also set up clear guidelines of what teams can solve by themselves and when the DBA team is to be called in for their expertise.

The Outcome: More Satisfaction for Everyone

The new database structure allows IT teams to move at their own pace, setting up new databases and changing things as needed. They are more agile and can move new projects ahead faster — an important point in any business.

The team of database administrators also gains agility from the new structure. By not summoned for minor requests DBA can focus on issues where their database expertise is essential. They now have the manoeuvrability that allows them to react faster to solve crucial database issues.

The whole company benefits from this: teams have more control over maintenance, there’s less downtime and faster delivery for requests. 1&1 Internet is a more agile company, and its employees are happier in their roles.  

The project in numbers: