Before I really get starting blogging, I want to make it clear where I’m coming from and why everything I post going forward will be targeted at the government only. All opinions are obviously my own, in this post I am mostly asking questions and linking to public domain publications. There are a great deal of esoteric conversations related to EA in the government: FEA is confusing to Business EAs, some think its a joke, just doesn’t work and plenty more.
I read a great deal on EA, all the blogs I link to in this post are EA thought leaders who I hold in very high regard, in fact I don’t have any material issues with any of the 3 opinions I linked to from their perspective/frame of reference. That said; I have to admit I am stunned every time I read something referring to the practice of EA in the government and business as some kind of apples to apples comparison. This is important for a couple of reasons, a vital aptitude of practical/realistic Architect, is the ability to see the essence of things as they really are, in the as-is state, and the causal relationship between things. We federal EAs can use all the help we can get but it won’t be helpful for us to act like we are in an ecosystem/culture that we are not in.
My premise is this: the government is not a business and government IT shops are not like commercial IT shops. There are calls to split EA into specialties; my modest proposal to the broader EA community is simple: Please treat Public Gov EA as a separate practice from Business EA.
I am a practitioner not an academic, I have a degree in Computer Science, most of an MBA, I cert in Software Architecture, and one in EA, over 25 years in IT, came up as a developer. For over 16 my business cards said “Enterprise Architect” on them. To say I’m old-school when it comes to IT doesn’t quite get the point across. I’ve worked IT in a car factory, large corporations, start-ups and now the government. I am practicing what I call EA (TOGAF based) and will describe in a future blog, others might call this EITA, when I refer to a non IT oriented EA; I will call it Über-EA, no one in government or industry is having much success with Über-EA.
When I refer to what I’m doing in the government in future blogs I will simply call it “EA”.
A little background on Government IT
The following section is not meant to be provocative or controversial only to be clear, I’m assuming some readers are not familiar with how the government works and this is a source of confusion. If you were to independently analyze what we would call in the old school days the “core business” the Raison d’être of the average government IT shop what do you think it is? I assert that government “IT” shops are by design primarily about procurement, accounting and contracting. This is very obvious and is based in legislation etc., it affects the way EA has to be approached in the government. We have the FAR and “performance” contracts, which means that we can’t be prescriptive in the contract language from an EA perspective, we must rely on strong mission/performance goals documented by the business. How do you think that’s working so far? Government has the FASAB; we don’t even follow GAAP, like a “business”. I understand there is a lot of outsourcing since I left industry (again I will not post about industry for this reason among others), but I don’t believe the ecosystem is similar. Something that may surprise someone outside of government is that we have IMO a hugely disproportional number of IT operations people, who are staff. Typically, there is not what I would consider in house technical staff; these are the people who by sheer osmoses would have developed an understanding of the mission, processes, data, and technologies of the organization. Much of EA is outsourced, if you have someone who is “technical”, he/she is likely to be in EA. Surprisingly there are relative large amounts of fed operational staff doing what is from an Architecture perspective commodity work, patching systems configuring networks; they would be doing the exact same tasks at your agency as at the local bank. Why?
A few short stories
By definition the government is not a business; do you think EA is different in an organization without profit/obvious performance drivers? But it’s really more than that, I wrote up a typical EA analysis, but it was more of a whitepaper than blog post so I’ve decided I don’t want to post it. I’d rather pay homage to my first EA mentor. Kenny liked to tell stories, and he believed that the purpose of EA was to ask the questions no one else in the organization wanted to ask (Zachman-esque). So this is how Kenny might have approached it, with scenarios/thought experiments/stories whatever you prefer to call them:
1: Fed IT: In business you have contracts, you have contractors, you have procurement and budgeting functions, you have IT shops. We have the same things in government so we are very similar, the relationships are the same? Here are some links to this week’s primary government IT news; my only question for you to ask yourself, is this how your company/industry works: Point – one of the counter points? Another thing that seems to be assume is that we have is EITAs; in general most agencies absolutely DO NOT HAVE USABLE EITAs. Who would produce these in the structure I described earlier, what would be the motivation? We are trying to work with not only the business/mission but the accountants(CPIC)/procurement over what will be built and how, this is why what we produce are considered strange artifacts. Is this an EA problem? A lot of what government EA programs produce has nothing to do with Enterprise Architecture per se, but a lot to do with how Fed IT works.
2: “Business” Architecture”: The FEA BRM is a cool taxonomy, do you suppose the “business” cares about this structure, that this is useful to FEA? If you took a simple scenario into a federal HR or say Budget shop where the work is standardized and asked are you doing budget formulation or execution? Could they be compelled to care, by whom, how?
One of the phone companies I worked for, let’s call them ETG. ETG would gobble up little telecoms, until we were eventually gobbled up ourselves. We did not have a massive proliferation of systems and processes and decent “alignment” (relatively), I was in a meeting once where a gobble-ee was inquiring as to which of their systems we would keep, the answer was the same as we gave the other goble-ees “none”. Why could we do this? I believe we practiced a form of EA, we knew the capabilities/functions/processes (business architecture) required to run a basic phone company, this was documented (I’d like but I don’t remember); we knew which systems supported which capabilities/business functions, if there was a business capability that we didn’t have, say phone cards back in the day, “the business” would probably keep that capability/organization/system of the acquired company or build that capability/component. I also worked for FEMA during the DHS integration; do you think these experiences were similar?
3: Federal Über-EA: You can’t understand government Über-EA attempts, without understanding the role of OMB, this is something you can easily Google. Story 3 is about management controls/reporting/information, maybe it would be called governance today, when I was in MBA School in the 80s the emphasis was on things like management controls not emotional intelligence. The biggest knock I hear about government EA is all the paper, data calls, reporting, even the federal CIO at OMB Vivek Kundra said that the federal EA community has been often focused on compliance documentation at the expense of supporting mission improvements. If I read this and still worked in private industry, I would wonder why are federal EA programs producing this paper, for whom, what is being done with this information? This information is being produced nearly exclusively for OMB. When I was in telecom we had a network management group which we acquired, that either couldn’t or wouldn’t (the motivation really didn’t matter) provide basic inventory/asset information on their switches one of their core functions, I remember the meeting to this day, because it was quite memorable. Is this an “EA” problem?
4: Fed-EITA issues current example: We have a new federal CIO; one of his first actions is to stop the proliferation of web sites. If you are a good EA, you know that the proliferation of web-sites/systems/applications/servers is more of a symptom of fundamental problem than a problem, but I am 100% supportive of this action under the stop the madness mantra. This should give you a sense of where we currently our in government IT from an EA perspective. Why do we have some many websites? If you read the above link, you will see that we don’t systematically understand what they even do? This is what many wanted EA to “fix”, as I said early many agencies do not have a rudimentary EITA, IMO, because much of their resources are spent on reporting as described early, and black-belt Über-EA efforts in organizations that don’t have their white-belt EITA.
The other question I would have is how could this have happened? I haven’t even talked about the rigorous government security requirements, each of these web-sites is a potential attack vector, and do you think they have accreditations and authorities to operate? Can you really have Über-EA approaches/strategies when you don’t know how many websites you have and why?
I will leave you with one last thing to ponder critically on this subject in the Context of EA, EITA, Strategy and “businesses” and government. Great government strategic achievements from the past: Man on the Moon, WWII, and Marshall Plan (you can obviously come up with your favs). These were done w/o EA, how would they work with EA in the current government ecosystem?