datachick

We have separation of duties for all kinds of reasons. I think the isssue is mainly because teams let production folks do design, but that's not really a good thing in the long run. Two separate points of view. I call this the "Mason-Dixon Line of Data Driven Systems."

You are missing a "!"

But I bet you've worked with those guys who think "just enough documentation" means "just go ask the guy who wrote it*". Of course, the guy who wrote it has been long gone from 5 companies since he worked on your project. I think the main issue is that people think documentation means sitting down and writing a single 800…

Wow. Thanks. I struggle with finding the right balance. I hope you dig in with more reading. studying people and teams is one of my favourite things.

Me, too!

Having lived and worked (and paid taxes) under both kinds of systems (and all the myriad of systems in the US) I'd be happy to chat with you about the pros and cons of both. Not here, though.

There is also a dark side here, and that is when people in power control the data you are able to receive. Good point. That happens on my projects when I have to do a database design, but don't have access to the databases under development to measure the impacts of the design or to help developers with performance issues…

Test twice, delete once?

I noticed that as well. Here's a photo of people celebrating DATA! to add some cheer.

I think the humility part is important. But one of the best characteristics I see in great co-workers is empathy. Feeling their pain, showing them you feel their pain, whether it's users, teammates or customers goes such a long way in getting help or resources when you need them, too. It also shows an important, "we are…

Great comments. And I'm really focusing on the questions, not just which ones are easy to answer. Or even possible. Here's a secret: I'm not a DBA, either. But as a Project Manager and Architect, I ask these sorts of questions all the time. Mostly because I want in increase the organization's success rates for data and…

Yes. I've seen training that is primarily a collection of someone's user group slide desks. Helpful, to some degree, but not training. It's a type of knowledge exchange, but not engagement to learn a profession. And I include my own user group presentations in this.

Great points about being able to say "I don't know" and to realize when help is...helpful.

Glad you liked it. I think people can get better at troubleshooting. First, knowing more about the components they support is always helpful, especially deep dives about the underlying designs and internals. Second, being trained on where to find the data that helps them diagnose issues is always helpful. Finally, people…

I'd think the primary measures for Operational Excellence would be based on database uptime RTO, RPO and uptime stats. Maybe a measure of planned outages versus unplanned, duration, and scope. I think it would be important to realize that expectations (SLAs) are likely more important in these measures that some sort of…

Thanks for sharing your thoughts. I does depend on management culture. I specialize in helping troubled projects get back on track. I see a lot of dysfunction that leads to projects getting themselves down some rat hole. Often, it's because management needs to micro manage technology and they lose sight of the business…

I’m happy you liked it. I hope the next posts are helpful as well.

Tom being great during our workshop

I hear you on the time thing. There's so much new tech out there that I'm dying to learn about. And I feel overwhelmed with not having even .001% of the time I'd need to even read up on it all.

Sadly, I've heard that before, too. It's kind of crazy. Just randomly running scripts from the Internet is a bad thing especially if you don't test them first and don't understand what they do. But there's a way of either using very reputable tools automating what you can, then enhancing as you go. It's not a yes/no…

The best documentation is just "writing stuff down" so that you can see it right where you need it. In the code, in a model. My writing stuff down happens right in the data and UML models. It's just part of the modeling effort as far as I'm concerned.

I agree. I see to many people learning in DEV, when DEV is production for Developers. So it's nice having a cheap sandbox for learning and for a few hours costs less than a Starbucks.

Which is a good thing if done correctly.

I have a feeling your comment will be enjoyed by many.

I guess the cynical side of me says organizations will never pay for all that, so it's cheaper and easier to use constructed test data and then no production data is at risk. Of course audit for real data being in the wrong place.

I try to wedge as much of this writing into the models themselves. Whether it's an ERD, or a data lineage design mapping, I want those decisions and discussions right in the models so that as the models change, I can update those thoughts. Plus I don't have to go find some word document or SharePoint site to find some…

It's difficult to settle on that right balance of data collection and data hoarding. That's why I like the ability to configure and tweak the metrics in SolarWinds tools.

Another great example of how to bring data - find industry data or sector data. Then check to see how relevant it is to your environment. Put it in context.

I think this is the big difference between 2015 and 1995. For those of us older than databases, we had no real way to learn new tech other than getting hands on at work or having work send us to a conference or course. Now, with downloadable evals, MSDN, SQLSaturdays, online learning, etc. we have virtually no barriers to…

I think that's why eventually we all start looking alike.