Voice of the DBA

Category: Editorial

  • The Evolving DBA

    It’s interesting to think about the role of the DBA and how it might evolve in the future. I regularly see predictions about the DevOps movement, and increasing ability of fewer staff to manage larger scales of systems (more systems or more data). There is also the fundamental way in which larger “cloud” type providers (inside your organization or third parties) can include features or services that reduce the need for DBAs.

    However I ran across a statement that I think certainly provides some view into how the DBA might be affected in the future. The statement was: “The more an organization values its data, the more the DBA is under pressure to provide access to this data.” That includes all the people working with and managing data, whether developers, sysadmins or dedicated DBAs. They must ensure the data is available and useful to clients.

    I’m sure many people unconsciously realize this is their role, but they sometimes get caught up in looking at performance, or normalization, or backups, or some other task as being the highest priority task. In reality, we must continue to ensure backups are available if we need them, and systems perform well, and all the other ancillary tasks, but remember that backups and tuning and everything else are tasks needed in support of making data available for users.

    More and more I really believe that anybody that functions as a data professional, whether that is a small part of their job or all they do, needs to keep this fact in mind. The data is the more important asset we work with and all our efforts need to be geared towards helping our users access in as many ways as possible.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.1MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

  • There Are Always Constraints

    Many of us have spent years learning about technology. I suspect that many of you might enjoy these pieces I write, but you visit SQLServerCentral for the same reason I started building it: to become better at your jobs. Many of you work regularly to improve your ability to make SQL Server perform as well as possible.

    I’m also sure many of you have had to deal with what you see as “bad decisions” from your management at some point. I’m sure many of you have felt that if we did something a little differently, or spent a bit more money (or time), we could have built a better application. That may be true, though I’ve found over the years that technologists sometimes don’t make better decisions than project managers. We often have different priorities, but also different views on what success means.

    There are always constraints involved with building systems. The most successful technologists I know may gripe about constraints, but it’s a passing comment. They don’t get bogged down in the limitations that are imposed on them. They move forward, deal with the constraint, and make things happen. They get the software working or the system running.

    Like many things in life that may irritate us, and potentially hold us back, the limitations will always exist. We need to accept the lack of staff, money, time, or even technology and do the best with what’s available. It’s fine to disagree and complain, but don’t let that hold you back from making the best of the reality that you work within.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 1.9MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Presenting Data

    Many of us that develop or manage database systems are concerned with the actual bits and bytes that compromise data. However our clients and customers are more interested in the information, in gaining knowledge from the numbers, strings, and dates that are kept in our database tables.

    I really think that one of those things that can truly allow a developer or DBA to show their employer they are valuable to the organization. Employees prove this when they can retrieve information in a way that clients find valuable. Not that we, as the technical people value, but in the ways that clients find valuable.

    This doesn’t mean you need to learn PowerBI or PowerPivot or any other Power tools, but that you learn how to present the data you work with in the best way you can. Whether that’s in an SSRS report, an Excel worksheet you email around, or a complex visualization, all of these formats have one thing in common: a query. One of the best things you can do as a developer or DBA is ensure you can write efficient queries that assemble data from a variety of tables in different formats. Queries that retrieve data that can answer a question or reveal a pattern.

    Learning how to build a fancy visualization is great, but be flexible. If you get the opportunity, work with a new technology and develop some comfort, take it. However make sure that above everything else you can get the data sets to the end user. Clients can always use their own tools, but the efficiency and performance they experience will often come down to your query writing skills.

    Make sure you are constantly improving those skills.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.0MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Continuous Delivery In Real Life

    I’ve been writing and presenting on Continuous Integration (CI) and Continuous Delivery (CD) for a few years now. In that time I’ve encountered a lot of excitement and a good deal of skepticism as well. Many people want to know more and more, who is actually using this stuff? It’s nice to talk about Spotify and Netflix, but their problem domain, resources, and above all, youth, are something few organizations deal with.

    What about Microsoft? They’re a large organization, fairly mature (now 40 years old), and have their own levels of bureaucracy to manage. However they’re fundamentally changed the way they perform development across the last decade and a half. Starting in the beginning of this century, they moved to make secure coding a priority. In the last few years, they’ve also started to truly speed up their development process with CI and CD, culminating (now) with an extremely quick Windows 10 development pipeline.

    I saw a piece noting Microsoft is releasing almost daily builds of the new OS. That’s an amazing feat of engineering, and certainly one that shows you can develop an efficient software pipeline. While I’m sure that individual engineers don’t necessarily have their code released daily, that’s not the point. The point is that changes can be checked into version control (please, please do this), tested, and then made available for release.

    You can build software this quickly, too, though not in a day. Probably not in a month. I would guess it will take a year or two for many organizations to assemble the processes, change a bit of culture, and get used to building your application daily. Above all, it will take time for you to build unit tests and get them automated. You’ll have issues along the way, and it will be painful, but isn’t releasing software painful for most groups right now?

    A year or two sounds like a long time, but really it isn’t. Look back a year at your company and job? How much have your process changed? If it isn’t a lot, doesn’t that feel like you could have done something to improve the way you release software? Is there the possibility of making a smoother process that makes it easier to get enhancements to customers? I’m sure there is, and I hope you think about starting to assemble your own software pipeline today with CI and CD. Take baby steps, and slowly make changes to automate and standardize your deployment process.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.6MB) podcast or subscribe to the feed at iTunes and LibSyn. feed