Showing posts with label DBA. Show all posts
Showing posts with label DBA. Show all posts

Sunday, 11 February 2018

The DBA and the Data Platform





I've been consulting now for well over a year, it's been a fantastic experience so far; I've had the pleasure of meeting and working with some truly incredible people and it's also been amazing to be helping organisations get the most from their SQL Server platforms.

The last 12 months have been extremely interesting considering the current technical shift towards a seemingly endless list of new platforms and capabilities. For many organisations this shift has fundamentally changed how they do things (or going to do things) and many are going through their own journey of digital transformation understanding these new technologies and how to leverage them to improve their existing processes.

Right at the centre is data, nowadays considered to be a companies greatest asset, so how we use data or to be more exact how we extract more value from it is a frequent aim of these transformation projects. As a result the data professional roles within an organisation have changed too and many teams and individuals are having to broaden their technical skill set to design, deliver and support these new capabilities.

There is no truer example of this than the role of DBA but yet the question still remains on which direction(s) they should be focusing their future on? By that I mean development; which skills should they be learning, what certification, what products, platforms etc? It's easy to see why it's confusing; there are lots and lots of new technologies available to us but that also means there is no consistent path for administrators to set out on. 

It was easier in the not so distant past; the DBA role tended to come in two distinct flavours; development or operational, but now the line between the two has became far less apparent and in many cases non-existent. The DBA role has without question become much more rounded containing core elements from both "sides" but it goes beyond that. Modern approaches to database administration have reduced the footprint of the operational side of the role so a more DevOps orientated DBA is an essential part of the roadmap, for organisations and individuals alike.

This shared roadmap is actually an integral component of an evolving data platform. I've worked with many different organisations at different stages of development but a key component in each has always been a collaborative working practice between data professionals and I'd say the success of a platform depends on it. Over the past year I've worked alongside many different teams; architects, DBA's, developers, release analysts, change and testing specialists, when working together they all have a great influence of the effectiveness of a data solution. 



Whilst it's fair to say organisations should be encouraging this type of working practice it is very much dependent on individuals to pursue and implement it. For DBA's this means engaging with other teams much more frequently, understanding their skills and processes but also adding their own expertise and skill set to produce a much more co-operative function. 

It might not fully answer this common question of what next for DBA's, there's a lot of factors involved, not least your personal career aspirations but it does show how when looking for your next phase of self development the paths that you need to take could be very close to your current role. 

Your skills as a DBA will always be of paramount importance towards availability, security and performance, but by widening your technical scope by working much more closely with those around you not only improves you as an data professional but also the overall effectiveness your data platform. The starting point is to seek out these opportunities; start building relationships, start knowledge sharing and developing new ideas and different ways of working. 

In many ways the data platform is a reflection of the people tasked with shaping it. If we choose not to broaden ourselves, learn new ideas then at some point we come to a standstill, especially in this rapidly evolving technical landscape. If that happens a data platform stops growing, not in terms of data quantity but most certainly in terms of both capability and perhaps most critical of all, value. 

This puts a big emphasis on self-development but we've always had that, it's nothing new. The key is to seek out those opportunities, start close and work with teams that you will probably already have a working relationship with. As these relationships grow so does the collaborative skill set and as a result business processes improve and technical solutions get faster and more productive.

This also cuts down reactive measures, less time fire fighting means more time delivering enhancements and of course, more learning. Any learning process shouldn't have a cut off point, the more we broaden our horizons the more the effective we become and in turn, our products, our services and our platforms keep on evolving.

This is the true nature of a technical platform and we as data professionals play such an important part not just in the support or development of them but towards shaping their growth, effectiveness and their value. Perhaps the key to all of this is realising the value of our own development alongside it.   

Friday, 17 November 2017

Interview advice for DBAs?

Earlier today I saw an interesting book being advertised on a social media channel I use regularly. The books subject matter was around interview questions for the DBA and had been gathered by a bunch of people who had interviewed at various organisations and presumably the book (because I haven't read it) is being aimed as the how-to-get-that-DBA-job manual.

I'm not going to single the book out because I hope that the author had genuine good intentions when writing it however having on been on both sides of the interview table I can honestly say that an interview guide for this type of role isn't actually going to help as much as having two particular things; relevant skills and experience.

For a technical I'm sorry to say that is all you need. If you've simply studied on the "popular" interview questions and their corresponding answers and you don't have any technical understanding then I'm afraid to say you'll be worked out in a matter of seconds by whoever is conducting the interview and it's probably going to end very quickly.

The other thing to bear in mind is that no interviews are ever the same. Some favour intensive technical tests whilst others can be very informal but in both cases they're designed to and will assess your actual abilities and no matter how hard you try, you cannot take any shortcuts, no matter how well they're advertised!

Sadly this particular book isn't on its own; there are quite literally hundreds of books, ebooks and web articles out there that quite frankly are setting you up to fail and it's wrong. So if you are looking for a new role in the SQL platform please avoid the temptation for taking the fast route, because it's not going to happen.

Now it's fair to say actually preparing for an interview is very different and there are certain things you can do to help your cause, it's pretty high-level advice though; make sure you can talk about (and back-up) your skills listed on your CV, give examples that relate to your previous and/or current job(s) and research the subject matter that you might not be as clued up on if the job description asks for it.

The last point is crucial. I don't mean look into the top 5 interview questions about Always On but if the job asks for it and you haven't had too much exposure then look into the technical guides that are out there and spin up some test scenarios. You can't know everything, the interviewer should be aware of that and a candidate who makes that sort of effort does stand out in an interview, that I can assure you.

So if you are looking for a role right now in the data platform don't forget there are also a wealth of people in the community that there to help just avoid anyone who is offering a clear short-cut that will only end up leading to a dead end.

Wednesday, 30 August 2017

The future of the DBA role.

For quite some time now there has been a lot of talk on the various social media platforms regarding the future of the DBA role and whether or not it still has a place in the not so distant future.

I've actually wrote this post a few times but it's always ended up being a very lengthy read of epic proportions so I've decided to hack it to bits and get straight to the point(s) and hopefully open it up for some more discussion because I think it's a very hot topic still and I'm really interested to hear peoples opinions on where the role is heading.




Lets get straight to the point; is there a place for the DBA role? The answer to that is most definitely yes, whilst databases exist there will always be the need for administration, but as core administrative tasks are being automated there will be less for DBA to do along these lines.

One example I hear of why the DBA will still be very important is performance tuning, after all in cloud platforms you are literally going to pay for poor performance but then with the likes of automated index management and the arrival of the adaptive query processing family in SQL 2017 we can see that the time we spend on tuning activities could well be shrinking as well.

This is really where the concern is coming from but perhaps this is the wrong way of looking at things. Instead of worrying about what we're going to be doing, or rather not doing, we should be looking at how the technical landscape is changing and looking at the opportunities that lay within it.

Now I'm not saying for that we should all become data scientists (and nobody else is by the way), data science is hard but it is a great example of an emerging area within the data platform that we may seek to explore for own careers, in fact there is no real reason why anyone shouldn't spend at least a bit of time familiarising themselves with the technology and its capabilities. This goes for a lot of functionality now present within SQL Server; it's native support for R and Python, the likes of Always On and In-Memory OLTP becoming more prominent and the rise and rise of PowerShell automation, we can even run on Linux now and of course there is that cloud thing that everyone is talking about.

All of these technologies are integral parts of the Microsoft's vision for an ever widening data platform and as organisations look to implement them and leverage their advantages it is the DBA that can be at the forefront of this technical transformation, if they want to be.

This for me is the real point. The changing technical landscape is only a threat to those unwilling to explore new areas and learn new skills and this certainly doesn't apply exclusively to DBA's, whatever your involvement in IT this technical shift effects you and to put it bluntly, you can either go with it, or be left well behind. 

For DBA's there could be some areas that are out of the comfort zone, perhaps the Dev/BI stacks or architecture but thankfully there is an abundance of training material out there which doesn't cost a small fortune or in some cases anything at all, not to mention all the support coming from within the technical communities. The decision really is yours how you'd like to advance.

Now it is fair to say that organisations won't be simply moving to a new platform overnight, after all how many companies are still on SQL 2005 for example (if you need upgrading, give me a call) but rather than sit back and worry about what might happen and even worse do nothing about it, it's time to start looking at how the emerging technologies can benefit not just the organisations that you work with but how they can benefit you as a data professional.