"Agile DBA" ?

[jim ke]

Hi :
Read the table of contents & some of the descriptions. The book sounds more like a programmer's guide than a DBA's guide.
Are they trying to encompass things like replication rules, service levels, access rights, and backup rules into the objects at the system design time ?
jim

[Serge Adzinets]

I guess the book aims not only to DBAs but data architects, modellers and everyone dealing with data in the project. The DBA is like the common word.

[Lasse Koskela]

There shouldn't be a DBA in a project. The ideal (in my opinion) is that every single developer knows the database schema. Yes, there should be a senior DBA to support the team with advanced stuff like query optimization, but the vast majority of applications suffice without such tweaking.
It would be difficult to be truly agile if the team can't make the changes they'd like to because the DBA is overloaded with work (most probably not related to the particular project...).

[Surasak Leenapongpanit]

From

[Surasak Leenapongpanit]

From An essay is taken from Chapter 19 of Agile Database Techniques :
1. The Role of the Agile DBA
When it comes to ensuring referential integrity and implementing business rules the role of the Agile DBA is to:
Be fluent in the technical issues described in this chapter.
Work alongside application programmers to implement the necessary code.
Be prepared to mentor application programmers and enterprise professionals, including both architects and administrators, in the technical issues.

[Serge Adzinets]

You have 2 options in the labour division in the project: vertical and horizontal. The first means a developer implements the functionality of the particular use case in all architectural layers. The latter implies a dev implementing code for different use cases within one layer. In this case a DBA could, for example, develop DAOs for all the schema.
I've worked in projects with the first approach only, but the second one seems to have some advantages, like better quality of code.
Anyway it depends on the experience of your team.

[Lasse Koskela]

In this case a DBA could, for example, develop DAOs for all the schema ... better quality of code.

How many DBAs do you know who you would trust on writing your data access code, i.e. Java code? If you know one of those, hang on to him!

[Ilja Preuss]

Originally posted by Siarhei Adzinets:
I've worked in projects with the first approach only, but the second one seems to have some advantages, like better quality of code.
[/QB]

In my experience, better quality doesn't come from specialization, but from collaboration...

[Serge Adzinets]

Originally posted by Lasse Koskela:
How many DBAs do you know who you would trust on writing your data access code, i.e. Java code? If you know one of those, hang on to him!

I am My primary responsibility is writing java code and as a background activity I have to create and support the data model. Of course, I'm not a true DBA, may be a data modeller...

[Lasse Koskela]

I am My primary responsibility is writing java code and as a background activity I have to create and support the data model. Of course, I'm not a true DBA, may be a data modeller...

Yep, I was referring to "the other type of DBAs". I am also often responsible for designing the database schema, but it's some other guy (the real DBA) who tweaks all the tablespace stuff and so forth, i.e. non-SQL related details.

[Serge Adzinets]

Originally posted by Ilja Preuss:

In my experience, better quality doesn't come from specialization, but from collaboration...

Could you be more detailed on this...

[Lasse Koskela]

Ilja probably means that "(1 x 2) < (2 x 1)". That is, two average developers tend to produce better designs together than one above-average developer typically does. The reason being that the lone above-average guy doesn't get the benefit of discussing his design as efficiently as the pair does.

[Scott Ambler]

Ideally everyone should be competent in every aspect of software development, but that's not realistic. For example, how many among us can claim to be expert at UML, data modeling, user interface development, J2EE, networking, your operating system of choice, requirements gathering, your business domain, ... ? The reality is that we need to build teams of people who collaborate with one another to get the job done. I would prefer that these people be generalizing specialists, someone with one or more specialities and a general knowledge of development and the business domain. An Agile DBA should be a generalizing specialist whose has a data-oriented specialty.
An agile DBA goes beyond the role of traditional DBA. A traditional DBA should have a handle on replication issues, database admin, transaction control, ... and all the other traditional data skills we would expect of a DBA. There are several good books on this subject so I didn't really feel the need to cover them in my book, why reinvent the wheel? What I do cover is skills that most DBAs are sorely lacking if they wish to be effective members of development teams -- evolutionary data techniques such as AMDD, TDD, database refactoring, and so on. Fundamental object/relational skills including mapping, encapsulation strategies, and other development issues.
I also cover fundamental skills that both developers and DBAs should have, but rarely seem to. Both groups should understand both the UML as well as data modeling. They should both understand data normalization as well as class normalization. They should both understand the implications of using object and relational technologies together as well as the contraints placed on them by legacy data sources. Without this common ground it's very difficult for developers and DBAs to work together effectively, something I'm sure that you've all observed in your career.
The vision is that some people will be "Java" generalizing specialists, some Agile DBA generalizing specialists, some testing generalizing specialists, and so on who will work together to get the job done. When data stuff needs to be done perhaps a Java GS will work together with an Agile DBA GS -- each person will learn new skills from the other, while at the same time ensuring that the work is being done by someone with the actual skills.
It's a different way to work, one that is very common within the agile community but not so common, in my experience, on traditional teams. At least not yet.
- Scott

[Surasak Leenapongpanit]

See Evolutionary Database Design

[Anushe Khan]

quote: The vision is that some people will be "Java" generalizing specialists, some Agile DBA generalizing specialists, some testing generalizing specialists, and so on who will work together to get the job done. When data stuff needs to be done perhaps a Java GS will work together with an Agile DBA GS -- each person will learn new skills from the other, while at the same time ensuring that the work is being done by someone with the actual skills
-------------

very interesting!

[Ilja Preuss]

Originally posted by Serge Adzinets:
Could you be more detailed on this...

In my experience, tasks which only need one specific skill are virtually non-existant. So, if you let one specialist work on a task alone, you will get quality in one dimension, but less good work regarding other criterias.
You get the best work when people with different skills work together on one task, for example a DBA working together with an experienced OO developer. Personally, I like the practice of Pair Programming.