Database Development & Throwing your Customers a Bone…
Tired of getting beat up by everyone? Tips to help save the day…
This article is for all of you toiling away in the software development world, (especially database architects and developers), who are getting beat up by your boss & your company’s customers…and you could benefit from some ‘best practice’ tips. 😊
Do you ever feel like there’s no end to the escalated support calls and negative feedback, simply because you can’t keep everyone happy…all the time?
Wouldn’t it be great if someone provided some insider info, which would help lower the volume?
Well today is the day!
I’ve been a database architect and developer for over 23 years, and I’ve supported projects in the biotech world for 15 years, for medical devices and hospital system applications.
I’ve come up with some commandments that I’ve utilized, which I think would be of great benefit to others who do the same work. I’m looking forward to your feedback later.
First step…what exactly is your team creating, who are you building the application for…and why?
While the questions may seem overly simplistic, the answers that they reveal will provide direction; not only for the initial design of the product, but also how you will architect for growth and change in the future.
If, for example, you are designing a data driven system that will allow users to mine large amounts of data that are being generated by an ever-evolving collection of devices, you will need to consider changes in data points being received from these devices; as well as the evolving needs and requests of the end users.
Large scale data driven systems present a number of problems that often do not become obvious until something is not working as expected, or a change request is made that requires disruptive work that destabilizes the entire system.
So, what not to do?
Do not presume that hardware and/or supporting systems will evolve at a rate fast enough to meet your data growth requirements. From the outset, you need to architect for data growth that you cannot currently anticipate. This means that your initial design must be flexible enough to split (or shard) databases, be run on multiple servers and take advantage of more than one type of database engine. After all, not all data is relational and not all data is unstructured.
Do not design monolithic systems. As with procedural code architecture, monolithic systems are difficult to maintain and are prone to being unstable. Think instead about plug-in architecture, where new functionality is added in a modular fashion. This is particularly true with ETL systems. Trying to accomplish too much in a single module makes it difficult for others to understand and for anyone to maintain.
Do not presume that the data you are designing for now will remain the same. Over time, data from your source will change and grow. New sources will be added. Novel ways to interpret new and existing data will evolve. Designing for extensibility will provide you and your team the ability to adapt to new data (and new data uses) as the product continues to mature.
Do not attempt to build a released product from a prototype. Some of the best ideas with the worst implementations are the result of a team being forced into this situation. Prototypes are just that; at proof of concept. Released products must be architected and designed from the ground up. There are a number of considerations that are not addressed for a prototype including; interoperability, growth, performance and security.
Do not skimp on documentation. Believe it or not, you will most likely move on to another project; maybe before you have completed your current project. Those who follow in your footsteps will benefit greatly by understanding why you made the design decisions that you did. Before any coding begins, documentation of architecture, requirements, specifications and detailed design need to be in place. During development, code such as procedures, functions and views need to have a header section that details parameters and expected output, the purpose of the code and a history of changes to the code.
For information about the flip side of the coin – what “to do” – Use the form below
