Now permanently with dun & bradstreet
My career as a Software Engineering began as a Chemical Engineer. I take very great and specific pride in being just that; A Professional Software Engineer. Steve McConnell said it best in Professional Software Development: Chapter 4, Software Engineering, Not Computer Science. As such, I've spent 35+ years as an independent Software Engineering Consultant with a smattering of regular employment; Fortify Software, Cigital, and AlienVault. Finally, to harken back and paraphrase a quote from one of my ChemE undergrad text books; "An engineer does with $1 what anyone can do with $2." Those are the words that I have lived by professionally.
Fortunately, at least for me, many in my industry take an opposite approach. They... Do with $4 what any idiot can do with $2. Why? Too much process and not enough product. Too much talk and not enough talent. Too many with visions and not so many able to build the versions. The world of software development seems to be full of generals, flooded with soldiers, and woefully lacking in field commanders. Can you imagine a field commander in the military saying; "I'm not hands-on. I don't know how to fire a weapon any longer." In the Software industry, at some point and in many cases, this is completely acceptable to say; "I'm not hands-on. I don't write code any longer." Fine if you're a general, not so good if you still fancy yourself as a field commander. Title and role definitions will come and go. Languages and platforms will change. The latest development process will be replaced by the next. For me it's simply; Gary Hardy. Professional Software Engineer.
There are three reliable, mature, broadly understood non-COTS enterprise application platforms/frameworks circa 2014; JEE, LAMP, and .NET. For a number of years my development efforts have been focused on leveraging two of those well-understood technologies; Java Enterprise Edition and the open-source Linux stack. Effectively and efficiently capitalizing on those technologies to meet current business needs is always my primary goal. Dealing with the known limitations for a project’s/product's server technology stack [e.g. tomcat/java/spring-mvc/apache-cxf/hibernate/rdbms] vs. “exploring” the unknown limitations of a new [and, in theory, improved] technology is almost never in the best interest of any business. Put another way. Enterprise architecture [and development thereof] must be 99% solid product development and 1% R&D to succeed. And, of course, without a solid well-designed application architecture integration into a broader enterprise service oriented architecture is not possible.
With all that said, if the new technology frontier is non-browser based mobile computing with a fat[-ish] client/server model then 24/7 back-end reliably will be critical. That is not only full-circle from the 1980's/90's but what I firmly believe can be achieved with current resources [people] and tools [JEE/LAMP] available today.