Handling Big Data IV: The Single Code Stack October 17, 2013 John Sumser, HRExaminer

Whether or not your software was built by a single team using clearly defined data elements matters. A whole lot.

Whether or not your software was built by a single team using clearly defined data elements matters. A whole lot. What seems like an esoteric question turns out to be the difference between endless wars with the same problem and wisdom.

Some commentators will refer to this as the “Integrated Suite” vs. “Best of Breed” argument. That’s how this played out in the early part of the Century. Many of the people who argued for best of breed solutions are now shilling for integrated suites.

The best in breed piece of software is focused on one area (performance, learning, on boarding, recruiting, scheduling, workforce management, payroll, succession planning, compensation). The theory is that a software company is likely to produce a better product if it focuses on one area. The company becomes a subject matter expert by building software in the area.

Integrated system refers to the fact that the only way there could be a single system with all of that functionality used to be mashing all of the functions together. Many of today’s integrated packages (the really big guys) are collections of cats and dogs loosely stitched together with a single sign on and modest data exchanges between functions.

Function mashing means that the central company purchased or merged with the providers of other functionality. A single company,y good at one of the areas, starts purchasing additional functionality by buying companies and/or licensing their software. In theory, you could end up with the best of the best. What actually happens is a train wreck of competing architectures, data structures, languages and operating system.

Companies that acquire multiple best of breed solutions are called roll-ups. There have been a number of them. Some are still operational. Most have short lives. Roll-ups are the source of the famous joke: “How do you get to be a millionaire in Silicon Valley? Start with a Billion dollars.”

In the single code stack, the entire sequence of functions is laid out, planned for a coded by the same team using the same data elements in the same language on the same platform. There is some book keeping that has to be done to control the proliferation of elements. In the end, what you get is a system where the data is the same in every quarter.

You may well be scratching your head. Why does any of this matter? This series is so arcane that I’m getting a headache.

The pressure from organization executives for HR to produce data the creates opportunity and demonstrates business outcomes will get stronger and stronger. Call it Big Data or call it the new architecture of work. We’ve moved into an evidence based way of doing business.

The first thing you notice when you start working with a single code stack is that things that were impossible are now easy.

In the best of breed world, when a recruiter finishes her job, she moves on to the next one. It’s ridiculously hard to get recruiters to complete the form that tells you someone has been hired. So, elaborate systems have been devised to get that data back from payroll and into the ATS. Mostly it just doesn’t happen. Without knowing exactly when someone was hired, many performance statistics turn to mush.

In a single stack system, the data is right there. No transport, no export no so called middle ware no nothing. It’s just there ready to be assessed.

Then, you start to notice that the walls of the silos in HR are drawn by the software that serves the silo.

In the end, no system is an island. All sub systems roll up to a higher set of analytics. But, in the case of HR software, none of it is so foreign or specialized that it can’t be a part of one unified single code stack structure.

Now that the era of administrative software is closing, expect to see increasing emphasis on the importance of clean timely data and there fore single code stack systems.

The series:



 
Read previous post:
Handling Data III: Your System Talking to Itself (or not)

This is the third in our series of pieces about the hassles of making data work. You'd think it would...

Close