November 28, 2013 at 8:39 pm
Comments posted to this topic are about the item The Abstract DBA
November 29, 2013 at 2:00 am
I became a DBA because I needed those skills to do what I wanted to do with data.
I enjoy all aspects of database development and in particular get a buzz out of building a system that manages to make a complex task simple.
I have to say that service packing and hardware management aren't a point of interest.
Dev/Ops is an interesting exception.
As I've moved up to a Data Architect role I've had to relinquish permissions and that has hurt. The reality is that my role requires me to have a higher level view of systems and data flows so I can specify systems that balance many concerns and interests rather than focus exclusively on the needs of one particular group....... But I miss the development aspect, I really, really miss it.
November 29, 2013 at 3:30 am
I have been in I.T. for over 30 years now, and what you describe in your article is an example of a general trend that I have observed over time, and that is that roles are becoming narrower and more specialised.
In the early days, I.T. people tended to be generalists who knew a bit about most things, and would learn what they needed to get a job done. It was quite easy to move from one role to another, and employers did not demand a list of very specific skills as long as your arm before they would even interview you.
Now, although there are a lot more people employed in I.T. it is much more difficult to move roles because employers want you to have experience in all the tools, apps and techniques they are using. You can be rejected because your experience of a given product is not on the version of it that they are using, even though your domain knowledge of their business area is strong. (This has happened to me.)
Another downside to the role-narrowing trend is that people have less understanding of the roles and processes that interact with their own work. That can lead to decisions being made where the impact of that decision on dependent or related processes is not considered.
So whilst it does mean you can focus on one particular thing, it is bad for future employment prospects, and can have an impact on harmonious working.
November 29, 2013 at 6:40 am
I was in IT for over 40 years, and remained a pretty much a generalist throughout.
I think overspecialisation has caused problems in our industry; probably a fairly high ratio of specialists to generalists makes sense when some small fields are very complex, but in general employers and recruiters take it too far with the sort of detrimental (and silly) effects mentioned by John Riley.
I think being just a DBA is something that would have driven me bats.
Tom
November 29, 2013 at 6:53 am
I agree with John, the IT field (considered as a whole) has specialized and while it makes moving into new roles more difficult, having more positions available for narrower roles would create opportunities at least theoretically. That's a debate we could go round and round on all day.
What is interesting even with the specialization of IT, there is still a tendency in the business world to think of IT folks in the old 'generalist' mindset. If you do something with IT, you are assumed to automatically know everything there is to know not only about computers, but virtually every other electronic gadget out there as well. People all the time ask me about smartphones and the like and I look at them and say, "my cell phone makes phone calls." They look at me weird and then the light turns on. It's actually kind of fun in a way.
I haven't been in the database part of IT long enough to know for sure, but from over here in the cheap seats of the peanut gallery, I can't help but think the rise of data science and "big data" will bring even more specialization within the database field itself. Something to think about anyway.
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
November 29, 2013 at 7:14 am
I don't agree with system team, a DBA role shall not be narrowed to just instance of sql server,I think both the teams work together to get best out of the box. If someone thinks that DBA should have limited access as low as DBA can't make the system down, it mean's you shoudn't expact from that DBA can do much. I am assumesing that the DBA is not just a development DBA or Application DBA.
November 29, 2013 at 8:10 am
I am a developer and have never been a DBS. That I have known more about RDBMS than some DBAs does not say much about me (I am NOT claiming to be that good) but has more to say about some DBAs. As far as SQL Server is concerned, I have preferred the times when I have been writing an application and the DBA has stated that stored procedures written by programmers will be treated as a specification i.e. they will rewrite as they feel necessary. Sometimes that has been an ego boost when a stored procedure has needed no changes following review whilst other times I have been totally schooled.
I don't mind learning and have a reasonable understanding of my limitations so I couldn't go wrong.
So how does this fit in with the editorial? I am happy for others to specialise in what I may sometimes have done (or do) as a peripheral task of my role. There is more than enough to know without worrying about someone doing some of what used to be part of my ever expanding role.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 29, 2013 at 12:51 pm
Although I absolutely love the idea of not having to tend the hardware or Windows anymore, I'm still very aware of both and the things that can go wrong as well as the problems having to do with security. In that vein, nothing will convince me to use the Cloud because I don't know the people who are tending to that whereas I do know the people in my company. And, yes... I still know how to make the necessary changes in an emergency where I'd have to wait for some person in the Cloud to decide to work on my help-desk ticket request.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2013 at 7:46 am
I started as an IT generalist before gradually migrating to a development role then SQL data specialist and DBA. I still have a keen interest in storage and systems configurations to support the SQL Server infrastructure, but am happy to relinquish the daily sysops chores such as routine service pack patching, etc, to focus more on SQL tasks like planning and testing disaster recovery, performance tuning, scalability and such.
Andre Ranieri
December 2, 2013 at 7:52 am
In a large organization, database administrator (DBO) should be a different role from system administrator (SYSADMIN). There are plenty of roles where a DBA basically just needs to be the DBO on a specific databases, he built it and he maintains it, but he doesn't administer the server itself, especially in a case where multiple project teams share a single instance.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 2, 2013 at 8:53 am
When I first started working with SQL Server I was also heavily involved with the hardware and OS (NT 4.0). I was the backup for our SysAdmin and helped build and rebuild our servers many times. Installed the OS, SQL Server, upgrades and patches. As time went on I found myself moved further away from the hardware and OS levels dealing exclusively with SQL Server. In many ways I miss working closer with the hardware and OS levels, as it helped me understand more of what was going on when we had problems.
I am hoping to get back some of that knowledge and experience as I look at setting up more of a test environment to work with at home.
December 2, 2013 at 9:09 am
Lynn Pettis (12/2/2013)
When I first started working with SQL Server I was also heavily involved with the hardware and OS (NT 4.0). I was the backup for our SysAdmin and helped build and rebuild our servers many times. Installed the OS, SQL Server, upgrades and patches. As time went on I found myself moved further away from the hardware and OS levels dealing exclusively with SQL Server. In many ways I miss working closer with the hardware and OS levels, as it helped me understand more of what was going on when we had problems.I am hoping to get back some of that knowledge and experience as I look at setting up more of a test environment to work with at home.
I do think that as more roles move away from dealing with the whole stack then we find it harder learning in our own time as we have to regain skills that have been put to one side and often disallowed involvement at work.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 2, 2013 at 10:16 am
Gary Varga (12/2/2013)
Lynn Pettis (12/2/2013)
When I first started working with SQL Server I was also heavily involved with the hardware and OS (NT 4.0). I was the backup for our SysAdmin and helped build and rebuild our servers many times. Installed the OS, SQL Server, upgrades and patches. As time went on I found myself moved further away from the hardware and OS levels dealing exclusively with SQL Server. In many ways I miss working closer with the hardware and OS levels, as it helped me understand more of what was going on when we had problems.I am hoping to get back some of that knowledge and experience as I look at setting up more of a test environment to work with at home.
I do think that as more roles move away from dealing with the whole stack then we find it harder learning in our own time as we have to regain skills that have been put to one side and often disallowed involvement at work.
Going forward, I expect there will increasingly more abstraction between the logical model of a database and the physical model. For example, we may see a UNIX version of the SQL Server kernel that not only integrates with Hadoop (project Polybase or SQL Server PDW), but also contains it's table space with the HDFS file system. For the DBA and developer, the environment for creating objects, writing T-SQL, or even tuning query execution plans could remain virtually unchanged, but the physical architecture that lay underneath could be significantly different.
http://gsl.azurewebsites.net/Projects/Polybase.aspx
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 3, 2013 at 3:11 pm
As a few respondents have mentioned, in regard to IT roles in general, larger organizations have to operate differently than smaller ones. When I worked for a global financial services company, the auditors were pretty strict. "DBAs Don't Do Data!!!" was the maxim (for the most part). If a DBA could control the database, control the access, and control the manipulation of the data, it could get pretty ugly. That would be too much power to reside in a single individual for a large company. Yes, I would design databases, review developers' SQL, and performance tune poorly running queries, but I would not write the queries -- the app developers were responsible for this. The closest we came to doing this was within a DBA utility or job. I am now in a smaller shop and sometimes I am called upon to write queries. So it really comes down to the size of the company and the culture.
December 3, 2013 at 6:56 pm
jim.drewe (12/3/2013)
If a DBA could control the database, control the access, and control the manipulation of the data, it could get pretty ugly. That would be too much power to reside in a single individual for a large company.
I worked in a medium size bank for many years. I was the production DBA, the dev DBA on major systems (SQL, Oracle, etc.) as well as doing ETL between the stove-piped systems.
In the 10+ years we had only one high level embezzlement case. That also caused us to rebuild the whole Fixed Asset system. (He embezzled from a different source but built the FA system in his head and had no documentation.)
But the whole system we developed worked off the two "man" rule. Basically I would do whatever as commanded by the accountant. She had to verify it. The list of changes were written down.
But realistically if you hire people without honor, honesty, and respect -- they are going to find a hole in the system to exploit.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
Viewing 15 posts - 1 through 15 (of 30 total)
You must be logged in to reply to this topic. Login to reply