The Database Architect Role May be Changing

As you state, many design tasks that used to require a Database Architect are being handled by developers or development tools/frameworks; some of the latter being quite sophisticated. Contracting for these skills, as needed, or outsourcing routine work, are strategies I see more and more.

Smaller enterprises distribute the responsibilities among their IT staff based on interest and skills; the accidental DBA. Infrastructure support for software, database, server and network assets may be handled by the same person or small group, often the help desk (interesting: self-service tools are contracting staff in these areas, too). Larger enterprises hire a minimal staff to be the brain trust and lease contractor skills to match project workloads.

If these were the sole trending factors, I’d say that the Database Architect specialty is behaving like any other technology lifecycle with growth, plateau, contract, plateau (again) and decline/sunset phases.

We are building apps, not applications. We are using packaged software for all of the usual business support functions; we’d rather conform to an available accounting system than bear the cost of rolling our own custom solution (one of our junior consultants didn’t even know what GL was). These trends contract the need for a Database Architect.

Unless an enterprise is a commodity or willing to become one, it has a core business that requires a distinctive, mission critical IT solution and the staff to support it. If, as desired, it grows, the consequence of many small, sub-optimal design decisions, accompanied by the growth in retained data and transaction volume, eventually becomes unsustainable.

Agile development gets a solution operational quickly, but with the focus on the code, the data model, if any, may rapidly go out of date. An incomplete, incorrect or missing data model means that the big picture, the forward looking data design, cannot be seen and must needs eventually be lost.

Frameworks are a low cost build solution, but their large memory, disk and CPU footprint are the natural consequence of the “worst case” and “all things to everyone” paradigms on which they are built. They can’t now the business or data and thus be optimized to them.

While OOP can map nicely onto the relational model, redundant (with the risk of inconsistent) data, network-y pointers and absence of protective constraints creep into the design. Objects operate on collections of data, without regard to how the component elements are related or retrieved. They don’t want to know that a particular datum is used by another object or in another context. The consequence: accumulation of dirty data, breakdown of data integrity, and loss of performance. Do we not often decry the lack of foreign keys, excessive indirection or over-abstraction (sometimes mistakenly called over-normalization) in designs?

Eventually you can’t throw enough silicon at the problems; you need intelligence. You need a Database Architect, at least from time to time.

Several of my recent assignments have been to fix OLTP DB designs that were cracking under their own weight or where the pain points had become unendurable. I’m not generally asked to build a data model (though on my current assignment, that is exactly what I’ve been asked to do), but I always do; and the developers flock around it.