by Karen Lopez
I’m often asked to help clients fill IT professional positions – Database Administrators (DBAs), Data Architects, Data Administrators, etc. Most of the time the job requirements are sufficient to help them find a good list of candidates worth interviewing. However, in these times of limited budgets, I frequently see job descriptions that attempt to find the Wonder Candidate of the Century, a person so thoroughly talented that she is a master expert along an entire column of the Zachman Framework.
It would seem to make sense that if you were hiring a data professional you’d design a position that fills in the Data column, right? No? It turns out, though, that most people don’t think and work along a column. In my experience, people aren’t passionate about tasks that span columns from top to bottom. They normally aren’t skilled along the whole column, either. Referring to the Zachman Framework, what sorts of skills and passions would this candidate need: planning, architecting, designing, building systems, building parts, keeping the systems up and running. Think about all the technologies, tools, methods and approaches these candidates would need to master to work at the professional level up and down an entire column: business strategy tools, tactical planning tools, database technologies, design tools, data modeling tools, code generation, query performance tuning, semantic technologies, legacy database systems, query development… Well, I’m getting tired thinking about it.
I have this image when I read bad job postings of candidates being dragged by zombies up or down a column. This dragging means we’d need to find people who have great analytical skills while at the same time having great detail-oriented building skills. But having those skills isn’t enough; they’d also need to be passionate about every task along the column equally. That’s the rub. I’m not even certain I’ve met a person who is passionate about all the tasks from planning to keeping the enterprise functioning. In fact, I think there’s a type of Mason-Dixon Line somewhere around the middle rows that separates the more analytical tasks from the building and maintaining tasks.
“[T]he Mason–Dixon Line symbolizes a cultural boundary between the Northeastern United States and the Southern United States (Dixie).”
The divide I’m referring to isn’t about politics, but more about where one feels most comfortable. At a crude level, this is a difference between thinking and designing enterprise systems or building and running enterprise systems. The line may be higher or lower in the Framework and there may be similar lines as we cross each row and column, but I see the most pronounced difference as we move from top to bottom.
I see job postings all the time that call for a Strategic Conceptual Enterprise Information Data Architect who has strong skills in modeling, strategic planning, query tuning, XML, data syndication, mirroring, SANs, debugging and < insert your favourite development languages here >. Those people don’t really exist. There may be people who can do a lot of those things, but in my experience they aren’t passionate about all of them. New hires won’t be happy and the organization will not realize the economies that they think they will.
I recommend that if organizations want to combine responsibilities that they do so across the columns in the same range of rows. Combining positions where thought processes are similar (business and data analysts, DBAs and developers, etc.). Analysts in general make for good analysts in other columns. Operational people tend to think operationally, builders tend to think mostly of building, not planning well. Let’s not drag people up or down the rows.
Go now and check your job postings. Do they reflect the true nature of the job? Or are they actually full of zombies ready to drag someone to an assignment that they don’t really want?
Wikipedia contributors. "Mason–Dixon Line." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 2 Jan. 2011. Web. 3 Jan. 2011.