Five deadly sins of data architects in the agile world

My first encounter with agile was in the late 90s in a DAMA Chicago discussion forum. Data modeling experts and self-proclaimed experts vigorously debated the evils and benefits of agile design on the data modeling community. Many years have passed, but the passion around agile design is very much alive in the data architect community.

Karen Lopez recently hosted an agile webinar as part of her Dataversity The Heart of Data Modeling series. She walked through the 12 principles in the agile manifesto focusing on how data folk can thrive with agile development. If you are not familiar with the manifesto, here is my favorite poster outlining the 12 principles.

I acknowledge that agile development offers challenges to data folk. Data architects are often not on the main agile track. This disengagement may be due to cultural history, dysfunctional teams, or a flawed implementation of agile. The data architect may also bear the burden. Here are 5 sins that I see data architects committing when facing the agile world.

  1. They don’t involve me. Development folk drive most agile teams. Their focus is on application development and not database design. The data architect needs to assert the voice of data in agile teams. Sit with the agile team. Participate in the discussions. Chunk your deliverables into pieces that fit into the sprints. Above all, make your presence and the importance of data design known.
  2. You want a data model when? In traditional development, an ERD is produced after thorough analysis and design over many weeks. Agile sprints ask for deliverables in many pieces over many sprints. The data architect needs to develop a methodology of delivering data artifacts in smaller pieces. Often, this involves working a sprint ahead that sets the data architecture and delivers core data components that drive deliverables in the following sprints.
  3. Agile has been hijacked here. There is a good chance that your resident agile expert is homegrown with limited education and exposure. That person likely resides in the application development team. This may result in an agile methodology where non-development teams are minimized or absent. Agile is team-oriented and focused on cooperative development. Work closely with your resident expert on the roles, tasks and artifacts for agile data methods. They will most likely be very thankful for your input.
  4. Agile doesn’t really apply to me. It’s only a matter of time. An enterprise may not be involved in agile development at this time. However, it is becoming increasingly a standard for application development. If agile has not surfaced in your enterprise, you have a distinct advantage in shaping how agile will manifest itself in your methodology. Educate yourself and look for ways to develop data designs in an agile manner.
  5. I have other priorities. Data architects can find themselves on multiple agile teams. It’s the reality of the scarcity of data resources. The spirit of agile has all team members sitting together to deliver the sprints. This is challenge when you must share your time across projects. It’s a matter of managing your time, maintaining your presence on and responsiveness to the team, and meeting or exceeding sprint deliverable times. Your enterprise agile methods should detail the involvement of resident experts on teams. It is not an unusual concept but one that must be managed well.

This list may be short, but the effort to overcome these sins is a tall order. It takes time, commitment, support from management, and support of all team members to make agile data design a success. Tackling these sins one at a time or a few in an interactive manner is a likely course to become more involved in the agile world.

Tom Bilcze

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *