Data architects live in a world caged by bars of process, standards, and documented procedures—things many would consider a high ceremony lifestyle. As an industry, information technology has been migrating more and more into agile frameworks for some time now. High ceremony is often seen as an earmark of “waterfall” approaches, which constitute the evil empire that agile frameworks are fighting to replace.
The result of this opposition is that formal data architecture groups often do not fold easily into agile approaches. Increased hand-offs and questioned specialization are discussed and looked upon suspiciously. The agile goal is to simplify the development process. Handing work over to a data modeler and then handing it over to engineers is seen as extra clutter. But, at the same time, a quality output is very important. If an organization wishes to maintain logical and physical data models within professional tools and have them properly maintained, then specialization is literally required.
Documentation
Sustaining those logical and physical data models requires templates, naming standards, standard abbreviations, and many other details that help ensure continuity. Often, it seems that misplaced anxiety arises as documentation is looked at as inefficient, if not malevolent. But documentation in and of itself should not be reviled. Documentation is not the enemy; documentation is critical, but too much or the wrong documentation can be a problem. Establishing and maintaining active and living data models necessitate a level of supporting documentation. How much and what kinds of documentation are needed will vary across organizations. The documents necessary are those documents that are used—used to help a new person learn and used to remind a seasoned professional on the details that might have become fuzzy. Documents that are not actively used should be looked at to consider their value. Quality results are the goals. Additionally, having data model reviews can be a way to establish quality outputs and potentially then require less documentation. In an environment utilizing reviews, some documents supporting the data modeling process might be smaller documents—focused on goals and desires rather than trying to address every possible decision that may arise. If instituting data model reviews in an agile environment, the review process must be set up in a fashion where the reviews may happen as and when needed. Having work wait an extra day or more simply to be approved would be an actual roadblock.
Collaboration and Review
It’s been said that one cannot inspect quality into a product, and that may be true; but that statement was made about a manufactured product. Database designs can hardly be called “manufactured.” Yes, they are an output from the data modeler and team, but the design process is a bit more fluid than things flowing off an assembly line. A finished data model is an output of part artistry—part pattern recognition and application, and a large dose of opinion. Collaborating and reviewing data models to determine how individuals have applied “standard practices” are ways for the data architecture team to both arrive at consistent, quality deliverables and to assist these individuals in growing as a team.
Certainly, if one believes the database design team is composed of highly experienced individuals who have been in place for so long that any designs coming from them are virtually guaranteed to be the same, so that reviews and work-output assessments such as those mentioned here would provide no value, then maybe those reviews are unnecessary. Or, it may be possible that things need to be shaken up a bit because growth and learning seem to have stymied to a stop. Change is a part of life; data modeling teams, similar to everyone else, likely must cope with a level of change too. New people can gain insights from the experienced, and the experienced can gain insights from fresh eyes and minds.