Voice of the DBA

Category: Editorial

  • Taking Shortcuts

    Many of us work in situations where we feel pressure to get work done at a pace that’s faster than we might like to move. In some sense, this is the nature of life, where customers and clients always want something done immediately. Whether they’re ordering food or building a house, it seems that quite often the customer expects the creator to just work harder and faster, without making mistakes, and deliver the goods quickly.

    That may or may not work, but if does often result in issues in software. While we can fix them, there can sometimes be larger issues, especially where sensitive data is involved. There was an incident recently that reminded me of this, though fortunately, it appears the data loss was minimal in scope and sensitivity.

    The mobile app at a recent security conference leaked data. The builders of the app embedded security keys and passwords that allowed anyone that registered to download a database of attendees. Fortunately this was a limited set and it appears only names were exposed. However, it could have been much worse, especially if this were a typical non-normalized database that might contain all data about an attendee in one row.

    I don’t know the timeline here for development, and I certainly don’t know the requirements. I do know that embedding keys and passwords into application is a bad idea, and even worse when those applications are going to be installed on customer devices. These are fundamental rules, and I certainly hope that whoever worked on this application, and anyone reading about this story, knows not to do this again.

    No matter how rushed we are, it’s important that we follow some practices and include some seucrity in our systems. I’d argue that data security ought to be number one and built into the system from the start. As the GDPR asks, we should be ensuring this is included by design and default. As much as it might seem that new legislation is overreaching and burdensome, I’d argue that mistakes like this one are all too common when we feel pressure to get work done. We shouldn’t be making these mistakes, nor should be be pressured to ignore security for the sake of expediency.

    Steve Jones

  • 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.