For context, I’ve spent my entire career on the IT side of the shop and in my sixth and final semester of the EA MPS program, it’s been my experience that students in the program with an IT background are in the minority. This has been valuable to me, because in a lot of ways, it’s a microcosm of my professional experience: a LOT of my day to day revolves around convincing non-technical people to spend money on something that they don’t see any value in. (It’s even tougher than you may expect, because my projects focus mainly on infrastructure, service management, and risk mitigation. It’s somewhat easier to pitch an integration project to combine several CRMs into a single system to a bunch of sales execs compared to telling them they need to spend money to upgrade network switches to mitigate some theoretical future threat. Generally if IT infrastructure is currently functioning, no one is ever willing to spend money on it.) In the same way some organizations think they’re being “agile” by holding a daily stand-up or ITIL because they have a CAB that rubber stamps everything, EA suffers a bit from a lack of definition. Everyone wants to do EA, but not everyone really knows what this means.
In the same vein, there is limited consensus on what constitutes an enterprise architect and their day to day duties. I went on the job search site http://indeed.com and searched for “enterprise architect” and the job descriptions and requirements are all over the place, describing duties of a CTO or director level position, all the way down to an entry level help desk tech. Things like:
Desired Experience: JIRA, SVN, JavaScript, Xamarin, .Net, Agile, C/C++, Swift Or Objective C, OOP, Oracle, Java, Knockout Js
What is completely clear from the first few pages of the search results is that EA is a sub-field of IT. The educational requirements say something to the effect of “Bachelors in IT related discipline, Masters preferred.” This is consistent with my own experience, albeit with a limited sample size. Every organization I’ve been a part of had the EA org reporting to CIO/CTO and maybe a dotted line to a department on the business side. But at the end of the day, EA = IT. And this is completely at odds with my experience with the program at PSU, which I feel is a good thing. EA from an architecture standpoint ostensibly exists to bridge the gap between business needs and IT capabilities. It also exists to mediate the cultural gaps between IT and business personnel, which approach relations with each other ambivalently, jockeying to meet their respective short term goals while losing site of long term.
Even the first set of readings for this lesson on application architecture are abstract enough for a non-technical person to grasp with no issue. The IT person may prefer models with more technical details, the business side may only be concerned with process inputs, outputs, and constraints. It’s the enterprise architect’s job to facilitate agreement between both sides.