This post was written by Matthew Skelton co-author of Team Guide to Software Operability.
Deployability is now a first-class concern for databases, and there are several technical choices (conscious and accidental) which band together to block the deployability of databases. Can we improve database deployability and enable true Continuous Delivery for our software systems? Of course we can, but first we have to see the problems.
Until recently, the way in which software components (including databases) were deployed was not a primary consideration for most teams, but the rise of automated, programmable infrastructure, and powerful practices such as Continuous Delivery, has changed that. The ability to deploy rapidly, reliably, regularly, and repeatedly is now crucial for every aspect of our software.
This is part 4 of a 7-part series on removing blockers to Database Lifecycle Management that was initially published as an article on Simple Talk (and appearing here with permission):
- Minimize changes in Production
- Reduce accidental complexity
- Archive, distinguish, and split data
- Name things transparently
- Source Business Intelligence from a data warehouse
- Value more highly the need for change
- Avoid Production-only tooling and config where possible
The original article is Common database deployment blockers and Continuous Delivery headaches
Poor naming of system components
On a related note, the way in which subsystems or components are named can lead to that system unnecessarily aggregating all kinds of functionality and data.
I once did some work for an organisation which wanted some help with moving older systems to Continuous Delivery, but all the systems had names like (let’s say) SPRUCE, REDWOOD, or CHESTNUT. The names were entirely opaque, giving no clues to their purpose, which had resulted in each new piece of functionality simply beingbundled into an arbitrary monolithic subsystem! The tendency to ‘lump’ data into a poorly-named (and so poorly-defined) databases is depressingly common.
You can probably imagine the conversation:
“Where should this Customer data go?” “Uh, just put it in SPRUCE, I guess”.
Whereas the answer should have been: “In the Customer service, of course!”
Now of course this isn’t unique to databases, but opaque names in any part of a system are bad for software. Well-named components tend to retain a good degree of coherence and focus, whereas their poorly-named cousins attract the unnecessary data and complexity we’ve just described.
Remedy: Name things transparently
This is a really simple fix, but we can dramatically improve deployability by using good names for databases and other software components, because opaque names tend to lead to arbitrary ‘clumping’ and coupling of features and data. Instead, use transparent names that describe the purpose of the subsystem or database, so that it is clear whether data should belong in that system.
If you want a little guidance in this area, I recommend “Uncle Bob” Martin’s classic book Clean Code, where Tim Ottinger lays out some ground rules for effective naming of things in software systems, including: ‘use intention-revealing names’; ‘avoid mental mapping’; ‘use solution domain names’; ‘don’t be cute’; and so on. Steve McConnell uses similar advice in his excellent book Code Complete.
Skelton Thatcher 