In simpler terms: It's been a division between those that build the roadways, and those that build the contraptions that traverse them.
Out of this soup of techno-stuff comes things like Facebook, Google, Angry Birds, Netflix, Windows, iOS, Grooveshark, Twitter, Instagram, AutoCAD, 3DS Max, LinkedIn, World of Warcraft, VPN access to your office, home security cameras that you can watch from your smartphone, XBox and PS4, and, well, whatever it is you're reading this useless crap on.
Stick with me, there's a point to be made, eventually, trust me...
Both sides of this divide have their own logical infrastructure (pardon the pun), from conferences to certification credentials, to college degrees, and user groups and so on.
But more often, "engineers" are stuck between these two worlds. Remember that old Twilite Zone episode (or was it The Outer Limits?) where the futuristic solder is caught in a spot where half of his body is in a war zone from the 1800's while the other half is being shot at in a war zone from the 2100's? Okay, I told you I'm pretty old, so just pretend you remember that one. I've found myself in that situation more times than not, between 1996 and today.
These should be familiar job descriptions / titles to you:
- Server Admin
- Backups and Storage
- Network Engineer
- Firewall Services Engineer
- Web Developer
- Software Developer
- Mobile App Developer
- Scripter
But, do any of these sound familiar?
- Software Packaging
- Software Repackaging and/or Sequencing
- Application Virtualization
- Horizontal Services Integrator
- Data Mining and Aggregation (kind of hinges off Horizontal Services)
- Desktop Deployment Specialist (think MDT/WDS/ADK/OSD, etc.)
- Patching Automation
- Web Applications Layering over Server Infrastructure Operations
- Inventory Control
Sure, you can pick these apart and point at certs that address those pieces, but the sum of each bullet (e.g. Inventory Control) doesn't fall so neatly into a single book, classroom or online course, or even a user group.
As a side note, one role that has always made my head tilt sideways is Group Policy modeling. If ever there were a job that involves everything EXCEPT what the people who almost always perform it are comfortable doing, it's that one. Logical analysis of software services, layering, Boolean operations, context filtering, decision trees, and "what if" analysis. Standing at the doorstep of programming, holding a cardboard rose in hand, waiting for the door to open and there's a hot MCSE date ready to go. Talk about juxtaposed worlds.
Another "for instance", and this is one I'm really familiar with: Repackaging software. Desperately trying to shoehorn some poorly-written crap into an environment, using tools like AdminStudio or App-V or ThinApp. Then wrapping that into Configuration Manager deployments, or deploying into VDI environments. That bizarre world of making it possible for two application bundles to coexist on a single host without killing each other, or killing other things, through the use of painful customization contortions. Usually done in the name of making a customer happy, and avoiding the cost of a license upgrade (you know, the new version that was actually MADE to work on the OS version they're trying to make the unsupported version work on).
The point (I told you there was one somewhere in here) is that delving into these murky waters is becoming more and more commonplace. Particularly where the intersection of custom applications and distribution and management procedures occur. Once it was Batch, VBscript, KiXtart, Perl and whatnot, now it's PowerShell, and .NET services, and databases, and web services and XML, blah blah.
This "shift" isn't some prediction, it's already begun. Look at the ways many server admins and engineers are working with scripts across various vertical services stacks. Anytime you are handed tools that allow you to bend and shape the out-of-box toolset to do things which the base product simply cannot do alone, you are stepping into that world.
How do you put a certification track on that? How do you quantify the value or potential of that? How do you quantify the level of expertise in that? You don't. You can't. Because it rolls back around to human interaction and knowing what your colleagues do, and can do, with those tools. You can try. Even if you concoct some elaborate exam test to derive a score of how well someone knows a particular coding or scripting language, or even a battery of command utilities. What would that really produce for you? If I know ever noun/verb phrase, every method and event, every exit code, does that make me a fantastic problem solver? Does it mean the solutions I would provide would be better than another person's, who scored lower?
Eventually, this divide will be bridged in a more tangible and meaningful way. Until then, it exists as a voodoo art, rarely discussed in depth and relegated to a bunch of web sites with narrow focus on the pieces of a blurry whole.
Wine is a good thing. And so is sleep. Enjoy!
Hmmm..
No comments:
Post a Comment