Voice of the DBA

Category: Editorial

  • The CDO

    One of the cornerstones of GDPR compliance is appointing someone as a data protection officer for your organization. This person is responsible for ensuring that your systems and data are safe and protected, and presumably, complying with the various articles in the GDPR. Article 37 notes that both a data controller and data processor shall designate a DPO in certain cases.

    That makes sense for companies working under GDPR jurisdiction, but for those of us outside the EU, do we need a senior level data executive? I wonder. As I’ve been researching the work by others and working with various clients and customers, it seems that some companies do have an executive, not necessarily in charge of protection, but in charge of data.

    This week, I’m wondering if any of you have a Chief Data Officer in your organization. I’ve heard a few people say that if you do, it’s a sign of maturity in your organization, where data is treated as a truly strategic and important asset. You likely have some sort of data quality metric, you many have master data management systems in place, and the organization constantly looks to extract more value from the data they store.

    I don’t know if this is a sign of a more mature organization, but I do know that having some resources in place to ensure data quality, mapping your data estate, trying to ensure some level of consistency are signs of more data maturity. I know many of us realize data is important, and certainly our employers want our systems to run smoothly, but do they really make an effort to use data wisely? If so, then I think the company is mature. If not, maybe they’re letting opportunity pass by.

    Lots of us data professionals do look for opportunities to better use data, to build useful reports, and find new patterns in data. Whether there’s a Chief Data Officer or not, many of want to explore data and make use of information we find. I think if our organization supports that, we’ll enjoy our jobs more. If not, then maybe the job is just a job for many of us.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Cloud Snake Oil

    I’m sure that those of you reading this have a variety of opinions about the “cloud”. Actually, I’d guess that many of us have different definitions of what the cloud actually means. That’s fine, since it’s really an amorphous, marketing term that encompasses quite a bit of different technologies, services, and products from many different companies. Some of you might use the cloud, and if you do, then perhaps this will ring true to you.

    I was reading Dr. Greg Low’s blog, and he asked the question in a post about what a managed service was. In this case, Dr. Low was looking to host his blog on some service, and apparently the definition of a managed service varied from provider to provider. His first provider didn’t tell him that backups were being run, with each file being counted against the space that he’d contracted for. When he asked for them to be deleted, he was told it would take a day or two as there wasn’t anyone to provide the service.

    He continues looking at how other providers define service, which does vary, but the interesting thing to me is that many of these companies aren’t really providing management of systems. They’re selling you a product, which has some capabilities, but they aren’t really managing anything. At least, that is my impression. I know if someone asked me to manage a system, I’d expect to deliver some level of service that would be useful for the client.

    In the cloud, it’s really a wild west version of computing, where companies want to sell you some service, often touting various management aspects, but they may not necessarily provide the level of service you expect. Cloud vendors, even worse than other computing vendors I’ve dealt with, want to work at scale, and they want to standardize how things work as much as possible. They don’t want to engage in person to person communications if possible. I learned this lesson with Google and their products, few of which had any way for a user to contact a help desk.

    Apart from that, what I’ve seen too often in the cloud is that a company wants to offer some service or capability, but they don’t often have the tooling available for end users. This is especially true for new services, where it seems the purchase process works flawlessly, but the configuration or cancellation process doesn’t work, or might not even exist.

    The one piece of advice I’d pass on from my cloud experiences is that anyone using services needs to reconcile their bills regularly. We can add resources easily, but removing them is hard, and often a customer service person promising removal doesn’t follow through. I’ve had people in the support centers not even be sure of what resource I was referring to when requesting removal or credit. It’s a frustratrating experience that has led me to adopt another habit. I grow resources very slowly, ensuring that I know what the billing is and that I really need the service. That seems like the opposite of what the “cloud” is supposed to offer.

    Steve Jones

    The Voice of the DBA Podcast

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

  • New IT Departments

    I had a friend that used to run an Exchange system. Actually, he was part of a team of four that managed a 50,000+ mailbox system for a very large company. In 2000 or 2001, he told me that his job would be done by computers in a few years and he had decided to leave the industry. Over the last 15 years, he’s worked in another field.

    I have no idea if those Exchange systems are still around, and I would concede that mail is better purchased as a service for most organizations than managed in-house. However, I think my friend made a mistake. There are still plenty of people working in technology infrastructure in companies, making a good salary in good working conditions. I’ve spent my career in IT in one way or another, either as a developer, Operations staff, or manager. I see no sign of this going away quickly, though certainly many menial, simple tasks like checking logs and backups are being increasingly handled by automated systems.

    When I see articles like this one (Why IT as you know it is dead), I’m not sure what to think. One one hand, I do think IT is changing, especially in larger organizations, where there is pressure to reduce costs (often labor) as well as increase the speed of output. DevOps is one way that we try to improve our systems, though the cultural change is very hard. Often this means that developers produce work in smaller chunks, and may release more often, but don’t get more work done. This is because the cultural change is hard, and most of us don’t want to change our habits.

    On the other hand, I also think that in many ways IT is the same. We can’t respond as quickly as business analysts or customers come up with ideas. I know most of those ideas probably aren’t great, and IT doesn’t want to waste resources on something that will not prove to be valuable. Just as happened 30 years ago, departments will create their own POC applications. This used to happen in Lotus 1-2-3, then Access and Excel, now it may happen with low-code development tools, whatever those are.

    I don’t really worry about this, as I’ll find ways to make things better. If someone wants an Access or Power BI application, let them build it. If it’s really useful, and others need access, we can upgrade and invest in a better system. I’ll go along and get along, working to build the things that the organization finds useful. I just realize that my time is limited, and if someone else can prove a concept is valid, perhaps that means I should spend time ensuring that works or gets rebuilt in a better way. I also know many of those ideas and concepts won’t prove themselves, so it’s fine if there’s some sort of citizen development (or shadow IT) in an organization.

    To me, the key is that we enforce security for our data. If anyone wants to build software, that’s fine. They just need to ensure that they use the same security and authentication mechanisms that other systems use. We need to protect the data, no matter what application is going to be used to view, analyze, or manipulate it.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Keep It All

    I love this quote, though I’m not sure it’s accurate. From The Future of Data Storage, the piece states: “What’s the most expensive thing you can do with a piece of data? Throw it out.”

    That’s from a storage vendor, and obviously they’d prefer that you keep all your data, which means more storage and backup space needed. Certainly I do think that losing data that’s valuable can be expensive, but I also think that we often keep around older data that we don’t use, or won’t use, which is expensive. Not for individual pieces, but in aggregate, it becomes expensive. This is especially true if you move to the service area where you pay for what you use, as opposed to investing in a large chunk of storage that has a fixed cost.

    I didn’t really think a lot of the piece, though it did get me thinking about backups. I’ve run backups for my entire career, and in 99 point some number of nines cases, I haven’t ever used the backup file again. These were insurance against potential problems. Even in places where I restored the backup to verify the process worked, I often just discarded the backup file at some point.

    Early in my career, we had tape rotation systems to reuse the media a certain number of times, while also ensuring that we had off site copies and specific points in time saved. Today there are plenty of backups systems that perform deduplication and complex disassembly or re-assembly of files from blocks to use space more efficiently. That doesn’t always work well for database restores, especially when time is of the essence.

    As vendors look to add more intelligent, or at least more efficient, processing to backup systems, I wonder if they really think about databases and how we use files. I hope so, and I’d like something that was optimized for database restores. I don’t mind combining the duplicate parts of files into some index, but I need to have the latest files available for quick restores. What about backing up a database to a file and keeping this file online and ready. Then, after the next backup, move the previous one to an area that dedups it, maybe takes it offline, etc. That way I have the best of both worlds. I rarely go back further than the latest full backup for a restore, so keep this ready.

    Of course, we need to consider log backups, which really need to be kept online and intact if they have been made since the last full backup. Keeping track of that is a pain, but it’s something software could easily handle. Once we’ve made a new full backup, you can mark older log backups for deduplication. Though, if you’re building this into a system, perhaps performing a restore of the full backup files automatically should be included as well.

    Steve Jones

    The Voice of the DBA Podcast

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