The future of DBAs with ORM I am an aspiring DBA (I'd say in ~3 years I would be ready to apply for a job) and I currently am a programmer. I relayed my future goals to a friend of mine who is part of an Agile SCRUM team in a very heavy and fast-paced software development company. (SDLC to the core). 

He expressed his concerns for my career path goals - stating that DBAs for most software dev companies is a dying position due to the increase and development of ORM in the last ~ 5 - 7 years. He said that the company trusts the programmers and most of them are capable of doing most of the work DBAs do. (Stored procedures, encryption, SQL, backups, ddl, profiling, etc.)

Can anyone shed light on their experiences or if they have the same concerns/beliefs with the DBA position?

I am referring to NHibernate and those kinds of systems.

To stay aligned with the Q&amp;A formatting of this site - What are problems that will be faced in the future if everything is converted to and uses ORM and DBA positions are no longer weighing in with the same importance they have been the past decade or two?

I will be honest and admit, aside from basic research I have no first hand experience with ORM. I know this site is supposed to be used for professionals, which is why I feel those who know exponentially more about this circumstance would be able to better identify concerns/problems.
That is how it tends to work in small companies, but that is how it always used to work for small companies: at a small scale an expert database person was often seen as a grandiose expense when all the devs can do the basics. This is not really a factor of ORMs and noSQL becoming popular recently.

ORMs still have datastores behind them that someone needs to understand and be able to monitor, backup, repair, analyse, scale &amp; optimise and as companies and/or projects grow it still pays to have a specialist in that area. Trusting devs with no data handling specialism is often fine on a small scale, but can lead to significant problems when scaling up. It is quite common to see people gush about an ORM or noSQL solution and claim it means they don't need to worry about the database, only to complain bitterly later when something they tested on a few thousand records falls to the floor when asked to deal with tens of thousands or millions or more (or sometimes even "a few thousand plus one" for really bad designs) and they have quickly got to the point where throwing more hardware at the problem is no use. You'll often find massively complicated caching layers getting created which would not be required if a little more thought had gone into either the initial design of the data store (or a later refactor) - those layers need development and maintenance too so those projects are often not saving money long term by not having a "data guy". In fact if you can keep a foot in both camps (dev and data) then there is much interesting work (and good money) in certain "architect" roles: people either designing the model for projects or earning their bread from taking overly complicated &amp; inefficient monstrosities and helping the dev teams turn them into relatively sleek &amp; scalable creations.

Also don't constrain yourself to being a DBA for a dev team: all of our clients (banking types, councils, a small airline or two) have an infrastructure department in part populated by DBAs who are responsible for making sure their data is appropriately handled. They challenge us (and other suppliers) to ensure we are following good practise, they are responsible for wider issues such as integration of data from systems from desperate suppliers, and they are of course responsible for maintaining in-house databases (mirrors, backups, monitoring, ...) - so there are other places a DBA optimised skill-set is required.

Of course you must stay up-to-date with the newer tools, that goes without saying, but while the job overall has evolved a bit over the last decade it hasn't changed nearly as much as some would have you believe (nor I expect will it in the near future, though keep your ear to the ground for new developments to stay current and avoid obsolescence if I'm wrong about that).