Advertisement

Database Reflections: Ten Things to Consider

By on

Click here to learn more about author Michael Blaha.

I’m going to do something different this month and reflect on some observations of the IT industry. My comments will focus on database-related topics. This is a smattering of ideas that is not intended to be comprehensive. I’m hoping that this article will stimulate dialogue. I welcome comments on my opinions as well as your own insights.

  • IT vs. engineering. I started my career in engineering, working as a chemical engineer for seven years. Since then I’ve worked in the IT industry for thirty years. So I’ve seen both worlds. The engineering world does not tolerate the level of failed projects, cost overruns, and quality shortfalls that happen with IT. The situation is about the same now as it was thirty years ago.
  • Data Model as a specification. A Data Model and database design should be part of the specification for building an information system. Vendors should be required to conform to the model and the schema unless a deviation is explicitly approved. The current practice of letting the vendor prepare the model and schema is flawed. The customer should provide these as specs for the vendor.
  • Advanced database skills. Business has much need for advanced database skills. I see it over and over again. But there is a lack of available talent. One reason for the shortfall in talent is that management often does not reward technical excellence. I think that’s because management has trouble assessing and measuring technical excellence.
  • Deep thought. IT places too much emphasis on doing something and not enough on thinking. Brainstorming on different architectures and attention to Data Modeling can improve project outcome and save a lot of work. Too many projects stumble into the first Data Architecture they come upon and fail to consider alternatives.
  • Analytics. Data analysis is really taking off. I believe this is real and not a fad. Computer systems are acquiring vast amounts of data. More and more organizations are trying to mine this data for deep insights.
  • UML Data Modeling. The UML seems to have reached maturity in the data world. The UML is no longer seen as a new technology and in vogue. Some data projects use the UML but most use the notations in conventional Data Modeling tools. The UML seems to be more successful with programmers.
  • Database vs. programming. The IT community is still obsessed with programming. Universities emphasize programming. Publications emphasize programming. But the big business payoff lies with data. Most organizations buy software but their data is specific to their business. Many programmers are still “afraid” of databases.
  • Two Data Architects. For complex projects it’s a good idea to have two architects in the lead. Two minds are better than one. I’ve encountered a few projects like this and two architects really increase the odds of success.
  • The consulting body game. Many organizations pay vendors on the basis of time and material rather than for results. This gives consulting companies an incentive to sell bodies and hours. Consulting companies are disincentivized to find quick solutions to problems and to cut costs.
  • Consulting credibility. I often see situations where I could help a customer. Their cost to pay me would be greatly exceeded by their business benefit. However, often nothing happens. I know I can help them, but they don’t know that and it’s hard to bridge the chasm. Many organizations pay too much attention to cost per hour and not enough attention to cost per output.

In Conclusion

I have presented a number of opinions. Some of these items are difficult to solve and act on. Nevertheless, savvy managers should be aware of these issues and consider them when making decisions.

Leave a Reply