The (now) age-old question of “are DBAs going away” is something that’s been beaten up here and other places. One of the first things that usually puts this to rest is the discussion of design. It’s a little strange to watch the pendulum swing back and forth – disk became really inexpensive and people stopped worrying about storage; servers became commodities, so some worried less about scale-out operations – all the while the pendulum always swings back – managing that disk space is important, managing that scaling operation is critical. Some get lazy and put those bits in place, then come to find out that the less well-thought-out designs are a hindrance as systems further scale or have to be managed or modified.
Design is as much, or more, critical than ever now. With the integration of outside systems and outside resource and the use of on-premises and off-premises resources – all of that works really well well depending on your requirements, but you do have to know your requirements in order to plan successfully.
It’s extremely tough to build out systems that support external interface and data from and to other database platforms, multiple cloud providers and all of that, if you don’t have a well-managed and thought-out design for your information systems.
It’s a fair statement that it’s more complex and important now to have a good data plan, than ever before. Regulations and controls are coming into the mix, and the tools you have for analysis and management and all of that are important to both support and protect.
Yet today there are still a good number of people that simply apply more instances, or more storage or just open up the firewall “just a bit more” for that latest application. It’s happening in many organizations. When you wonder if there is a need for a DBA type position, this is where it fits and provides outstanding leverage (on top of managing the SQL Servers, instances and all of that pesky ability to keep things online).
One of the things that is missing in many plans is the support for external interfaces and tools. From analysis to straight-up reporting or OLAP or even more simple Excel-type connections to the systems you support. It seems like these come around a good bit in the reporting phase of the design – after the design of the systems and data plans that are in place. But with the increasing items that both feed and pull from your SQL Server, it’s important that this be moved way up in the order of things considered. It’s not like if it’s ignored it will wait. This is a crtical component to the success of your systems.
– External systems pre-processing data – where will it go, how will it be processed, what formats and information are supported, how is it managed?
– Reporting and analysis systems – will you be moving information to data warehouses? Will you be further pushing it to other systems? What data is needed/what will it look like?
– Data sharing needs – from Excel to that latest ad-hoc reporting system to PowerBI, what is needed in terms of security, data management, etc.?
By moving these to earlier stages of your design cycles, you save some serious challenges later down the road.