Application, Data Architects Duke It Out
One of our Challengers would like our advice. Here is a summary of his challenge:
"Occasionally a battle erupts in our department between the application architects and the data architects. For example, the AAs want to remove database referential integrity so that programming or data movement will be easier. As DAs, we attempt to convince them that this may be a good short-term plan but will be bad for the long-term integrity of the data, which should be at the forefront of our data design decisions. If we are deadlocked in battle, upper management becomes involved to break the tie. More often than not, they side with the AAs. We think this is because the managers understand application functionality much better than they understand data architecture. What steps can we take so that we will start winning more battles?"
Design Challengers Weigh In
Based on the large number of responses to this challenge, I see that many of us can relate to this situation. The four main suggestions are working with the AAs, finding proof that supports the DAs, focusing on the business and educating all parties.
Let's work together. There are a number of ways DAs and AAs can work together to come to a solution that is beneficial to the business. Forrest Carter, data architect, stresses that the DAs are responsible for determining where data integrity needs to be enforced, but not necessarily how it is to be enforced. Anne Huey, data analyst/modeler, agrees: "This does not need to be a battle over whether referential integrity is a good idea. It can be a discussion over what methods can best be used to enforce it." Ian Yates, programmer, database administrator, suggests if load performance is brought up as a reason for removing referential integrity, a compromise would be to temporarily disable constraints during the load and then turn them back on when the load is complete.
Show me proof! Review your environment for data integrity issues that came up as a result of relaxing database constraints, and demonstrate in a report to upper management the problems that were caused. Craig Boyd, data modeler, says many of these issues can be found by reading help desk trouble tickets. Richard Leach, data architect, suggests finding misquoted public figures, an inaccurate forecast based on poorly managed data or an embarrassing incident with a customer that led to loss of company revenue or a tarnished reputation. Ben Ettlinger, lead data administrator, says you can also look outside your organization: "Inquire of your peers in the same industry and outside your industry for examples of issues that can be presented to prove your point." Moshe Japha, manager of data architecture, says, "Demonstrate the amount of code written and maintained needed to manually support referential integrity."
Business as usual. Donna Burbank, product marketing, and Goce Smilevski, developer, both emphasize the need to better understand upper management. Goce believes that the data architects lose many of these battles because reasons such as "cheaper" are interpreted as "easier," "quicker" and "less expensive" by management. Eric Nielsen, enterprise architect, therefore recommends becoming the "business rule champion" on behalf of the organization. "Use the data model first as a means of documenting, validating and communicating data-related business rules, then as input into carefully balanced design and implementation decisions that keep business objectives in mind at all times." Jon Lessig, data architect, adds, "Data that is heavily dependent upon code to maintain its integrity will require greater maintenance costs and due diligence with every enhancement or expansion of an application's capabilities." Johnny Gay, data analyst, recommends crafting analogies the business can understand, such as this one: "Taking the job of enforcing referential integrity from the database and giving it to each application is like taking the keys to the store from the supervisor and giving them to each employee. Just one employee not locking up leaves the store open so anyone can put anything in and take anything out."
Teach me the ways. Many Challengers believe education can diffuse these battles. Navin Ladda, data architect, urges us to educate upper management and explain that data lives forever, but applications that access and present that data come and go. Norman Daoust, consultant, recommends that we educate not just management, but also ourselves. "Get together with the application architects to really understand their concerns. Discover ways you can make their lives easier. Later help them learn the downside of inappropriate past decisions and demonstrate how different solutions can eliminate those issues. Become partners with your enemy when you continually lose battles; you'll be much better off!"