Wednesday, March 11, 2009

How high is too high (level)?

One of the interesting things about being back on the market is dealing with job descriptions.

Many recruiters are not technical (nor should they always be) and you sometimes get the type of offer that was done by a full-text search for key words. The person never bothered to even read your resume before contacting you nor did they bother to see that I have no interest in moving to Malaysia.

Too Technical?

I had an interesting turn of events today that was truly a first for me. I was contacted by a recruiter who thought (as did I based on the req he read me) I would be a good fit for a position. He said they had one other person they submitted but the client wanted to see a few different resumes.

The job was for an architecture position. The client had a government contract for a health care system. I didn't get much more than that and I really didn't have any time to tailor my resume for them to highlight the architecture work I had done. I've got plenty of architecture work over the past 8 years from low level to what I assumed was high level. It's the route I want to take long term so I was very interested to get in front of the client and show them my Visio collection ;)

I got a call back from the recruiter who said the client wasn't really interested because they considered me "too technical".

Come again?

He read some of the keywords that the other guy had on his resume and it was definitely buzzwordy. Phrases like "alignment" and "vertical". Mine had no such words.

REALLY, REALLY, REALLY High Level!

I told the recruiter that there were no hard feelings but I was really curious what they meant by "too technical". Mind you I know how to talk to non-technical people. I've done customer presentations for my designs and talked to executives about things. I can get high level and consider myself pretty good at preventing that glazed over look that you see so many times when a non-technical executive is inundated with "geek speak".

The way it was explained to me is that they considered me the type of person who would take what the person they were looking for and implement it. They actually wanted someone who hadn't been hands-on in a while.

I couldn't wrap my head around it. Why would you want someone who WASN'T technical designing something technical. What possible big-picture architecture could someone possibly create without some idea of what's actually POSSIBLE with technology? I've done work for those types of people and it's never ended well. I distinctly remember a person designing something for a client and promising something that simply wasn't technologically possible.

He explained that they didn't want specifics designed. He kept using the phrases "really big pictures" and "really high level". He stressed that the didn't want technology designs to be a part of this. No talk of platforms or specific technology (i.e. AJAX or XML). No user stories or use cases. This really got me thinking. What exactly can you do at a high level that has value?

My attempt at "really high level"

So this has been bugging me all day. Here's what I know. It's a health care system for the government. Let's assume it's the Obama health care database that was part of the "stimulus" package.

What do we know about it? Well not much. The language is pretty vague. Here's what a google search turned up:

Health Care. Health care has been a recession proof industry but the implications making health care available to more people should stimulate new projects, new money available for research and all of the outpatient and auxiliary services, such as testing and analytics labs, that accompany this. The provisions of the Stimulus Package package that call for an extension of COBRA for the unemployed and the development of a national patient database, while not an immediate priority, will require the that technology be developed long before its potential implementation.
So we have a national patient database. From what I understand form other sources, this was to keep track of health care information for preventative purposes. E-health records and other such interesting stuff. Working off of that and trying to be "really high level" and "not technical", this is the best I could come up with:



Forgive me for using Gliffy. I don't have my copy of Visio installed right now since I put Vista64 on my Windows partition. Also forgive the lack of inappropriate UML.

Intemperate side note: Anyone who bought his own copy of Visio Professional with his own money has to have some love for Information Architecture.

So anyway, that's as high level as I can get it. Obviously this would be wrapped up in a document explaining (high level of course) the various aspects of the actors and messages (physical contact vs. an "internet" message) but really there isn't much else to be said. That's assuming of course that this is the type of high level they want. The problem is that I don't see the value in something THIS high-level. Obviously, when designing something like this you have to know what's possible with current technology so you have, even if you're 10 years removed from trends, and idea of how it might be done. I would argue that if you're 10 years removed from technology, your design isn't going to be that good because it's legacy before it even comes to fruition.

While I was rocking Gus back to sleep (who woke up halfway during the last paragraph), I actually did think about it a bit harder. There's a lot that can be said without getting down to "specific technologies" used but I just don't see the value in it. Let me give you an example of what I would consider high level without naming specific technologies:



It's not much different than the first one but I learned Gliffy the second time around so it's got COLOR!

My document would outline generic methods for each message (public web interface, e-health API - without details, XML not even mentioned), the concept of self-service and authorization (patient ultimately controls access to information and level of access to third-parties) and other information.

At this point I've not really gotten TOO technical. I still haven't mentioned any specific technologies. I've not said anything about XML vs. REST vs. SOAP. I've not provided a UI mockup of the web interface (but I have conceded an internet presence). I've not addressed the issue of security (but I would at a high level).

To me, this is high level. The next level down would probably cover technology without being specific. I would probably mention the web frontend in generic language, the concept of web services and a few methods for secure interaction from service providers (VPN, MPLS, HTTPS) and provide different Visio diagrams going into that detail for each one.

It would be a pretty large document. This is the level I enjoy working at. I don't care if the backend is IIS/SQL Server or Tomcat/MySQL/AXIS. I can design the system without needing to know any of that.

Leave it to the people doing the implementation to determine the specific technologies that they know best. I wouldn't presume to dictate that it be done in Java anymore than I would presume to dictate it be done in Rails. I have my opinions on each but a good dotnet programmer can write secure and functional code just as well as an experienced Java programmer can.

Mind you I also enjoy working on the level below that one as well but that's a different scope. If I were tasked with implementing my second level design in a highly available and secure method, I'd have a Visio page with firewalls and load balancers and clustering design but again, I wouldn't dictate the technology. I'm not going to say "This is a Citrix Netscaler. This is a Cisco IDS. This is a Juniper firewall.". Of course I can do that level of design as well. Down to the redundant switching mesh.

The Payoff

Having said all of that and having actually worked through the problem, I have no doubt I could have done the job. Of course the flip side is I'm adamantly opposed to the whole thing. I don't like the idea of the government having access to the information. I don't like the idea of insurance companies having unfettered access to patient information (if it were designed that way). I don't like the idea of a "national health board" that reviews the information periodically.

I COULD design such a system that would satisfy my concerns but I don't know that I would feel comfortable trusting it to the federal government. This is the same government that can't seem to get people of TSA watch lists because they have the same name as a known terrorist.

But this isn't the place for a political rant.

I'm curious if anyone who might actually READ this could give me some insight into what exactly "really high level" is.

No comments: