I have this memory way way back as an undergrad completing the IST program of being confused about intermediary levels of abstraction.  Specifically, we learn about bits, bytes, ones and zeros as the building blocks of all things computer.  A little later on, a lot of the math behind why this is so powerful….IST 230 I think, with truth tables, Boole & De Morgan, and propositional logic concepts.  In my case, I actually got a little more practical experience with this stuff, I took a few CSE courses my first semester and one of them was a digital logic course where we built out logic circuits on breadboards.  But then, all of a sudden, it’s coding classes, jumping a couple levels of abstraction.  Yeah, they mention assembly and how the code is compiled and linked into machine code….but they never really EXPLAINED how that works.    (As an aside, if you enjoy puzzle games, check out TIS-100 by Zachtronics.  It’s a puzzle game where you solve problems by coding in a psudo assembly language on functional 8088 era hardware and it’s a blast!  http://www.zachtronics.com/tis-100/) 

Now, in my case, I had completed CSC 120 prior to switching to IST, so that counted as my first three programming credits.  That was in C and we learned about pointers and memory management…contrasted with IST 240 a few years later which was programming in C# which has a garbage collector…memory management didn’t come up once.  So where am I going with all of this?  I sometimes feel the same way about EA models…and to a lesser extent, to IT road maps/blueprints.

I’m sick of sitting in meeting and having people speak in such high level terms that they’re not actually SAYING anything.  Oh, IT is moving from a vertical to a horizontal organization!  Ok….so what does that mean?  We’re doing the exact same things now that we’ve been pulled out of the various different divisions into a centralized shared service, except now I have “two” bosses and am doing the exact same thing.  Or on the EA side of things, you can look at a high level model all you want, but a lot of times you can’t tell if a process is a robust IT system or a literal “swivel chair” person reading data from one system and entering it into another.  Models are great tools for documenting systems because lots of times they omit levels of granularity that decision makers simply don’t need or don’t care about…but it is absolutely critical that someone somewhere is still aware of the details and involved enough to be able to raise the alarm if things go to far off the rails.

I read through the Gartner job description for an Enterprise Solutions Architect and that fits my day to day responsibilities to a T.  The thing I struggle with is everyone wants to deal with the high level concepts and skip over the details of how the work actually gets done or how the system actually needs to function.