It seems that business people rarely hesitate to over-simplify a situation. One pervasive over-simplification concerns resource expense related to software applications and databases. Business often clings to the idea that once an application migrates into production, then everything is done and forever afterward such tools are "free." The need for some level of maintenance or constant improvement to keep system performance and flexibilities "up to snuff" is not so well-understood, causing many people to view such expenditures as unnecessary and resulting in the far-too-prevalent opinion that views IT as a "black hole" for expenses.
Compounding these simplified circumstances are the endless lists of new or enhanced IT deliverables requested by the organization. Then the cycle continues with business always and forever asking for things, and believing that once "done" each thing never requires it be looked at or touched again. In this over-simplification, the importance for any necessary maintenance is lost. And business people wonder either why new development bandwidth continues to shrink under the burden of maintenance or these business personnel remain in a state of mistrust over the presented maintenance costs. The world around us provides plenty of contrary evidence in support of the need for continued maintenance costs for even the most mundane things. One example seen every day across every city in the world is in the tearing up of "completed" roads, which often have some level of rework applied, and then get paved-over again. The road was done; shouldn't it now be free forever? When such over-simplified beliefs control resource expenditures, these beliefs leave IT workgroups effectively ham-strung. An attitude develops that presumes everything developed is a one-shot task–one-off reports, one-off databases, one-off screens. This can snowball across development efforts so that over time even things that should be small changes to existing databases and applications evolve into complete rewrites and replacements. IT consultants sometimes make matters worse by their own blindness to aspects of ongoing maintenance; often they come in to build something new and then just leave.
When encountering such an environment, how can a data modeler or developer improve things? Database designers and software architects must be their own best prognosticators. Every application needs flexibility in specific areas. In any given circumstance, hyper-awareness must be focused on the important flexibilities, whereas the design of other areas needs very straightforward structures/approaches. Designing for infinite flexibility often creates systems that are so abstract that few individuals will ever understand them, an outcome which only exacerbates maintenance cost-related issues. Designing systems that are too inflexible can result in necessary changes being inappropriately avoided. Since change eventually will be unavoidable, it is necessary to identify likely candidates for later change and enhancement in the initial designs. Properly setting up this type of design can create change costs that may not overwhelm business when the time comes for modest changes. Otherwise, even "simple" changes may remain undone or ignored until such time as the related issue escalates from a convenience to a dire necessity. Even if there are times where the designer guesses incorrectly, and the future-change-now-arrived does not map well to the existing abstractions and flexibilities, the effort must be extended to make those guesses in the blueprints.
As designers get more wily and familiar with an organization, they should become more adept at creating schemas that correctly address likely changes. When business asks, "Are we done yet?" the short answer from IT really is, "Never." But some level of further clarification may be required of the one answering the question. IT managers and software engineers must work with business stakeholders in raising awareness about the concept of maintenance, and help foster an understanding that information services really are a process and not a set of artifacts to be spit out and disregarded. Whether operational or business intelligence systems are under discussion, each is a journey and not a numbered set of destinations. When done well, systems will naturally grow and improve with time; but this evolution is not without some cost.