Posted by: joeyv1333 | April 27, 2012

Conceptual Information Modeling

 These are 4 closely related concepts, which have not been linked or unlinked to my satisfaction.


Concept Description/Purpose Primary Domain Links
Conceptual Information Model Requirements/Communication tool.  Ex. Evaluate gaps in COTS. (*whats up with DRM refresh) Enterprise Architecture My Favorite description of why you have one
Canonical Model/Common Information Model Primarily purpose is integration. Data Architecture Wikipedia Definition is fine
Master Data Management/Model Data quality related to integration. Enterprise Application Integration Focus on common/primary data
Conformed Dimensions Analytical Reporting Data Warehousing Building star schemas


All of these models should be related; in my experience macro success is only achieved when the Conceptual Model is understood, either formally or informally.   Ideally, from a top-down EA perspective, all models should align with the Conceptual Information Model, which is the business model.

Posted by: joeyv1333 | December 7, 2011

V for Vendetta, Vivek, the cloud…


Seriously, what is this guy’s  story?  I’ll leave that as a google exercise for the reader, on the positive side this article motivated me to take a few minutes to write a blog post because this kind of stuff cannot be left unchallenged.   Some quick background, from my observation, Vivek had no use for EA on arrival at the federal government, as we learn in this article; this opinion/conclusion apparently was formed when he worked for the state of Virginia prior to federal service. 

Well Dorothy, we are not in Virginia anymore, a point I really want to drive home on this blog, as the author astutely describes the federal government is an inefficient bureaucratic “machine”.  This machine runs on “paper”, IMO I agree with Vivek, most Fed EA programs are ineffective (uh yeah, most of the government is inefficient/ineffective), this is more a slam on the way the Federal government works or doesn’t work than the practice of EA itself, i.e. the root problem is not “EA”, I believe EA is the only hope Obi wan.  I agree in “confronting the truth as is, not as I wish it were,” (BTW what is the truth, this fellowship is a promotion?).   I really wish the government didn’t work the way it does, OK, now can you join me in reality world?

Most FEA programs produce a lot of paper, why?  Like I said the machine runs on paper and we are trying to work with (align with) and change the machine as much as we can from “where we are” (BTW GS-14s/15s generally), we are not in a position to drastically fundamentally change the machine itself (uh, yeah, that would take someone like maybe … the CIO of the government), if you do not understand this I’d suggest getting your old Civics 101 book out.   “Paper that nobody ever reads”, again in a machine made of paper, why don’t they read this paper.  Is nobody reading the paper regarding contracting, HR, Procurement, Budgeting, Accounting, Contracting or just the EA paper, so we will effect these paper based domains with our force of will, maybe someone could compel this discipline like maybe the C…oh never mind.

Taking the approach of ignoring/bypassing the machine, to wing it, disconnecting from the paper, when that person leaves; it’s like the tree falling in the woods with no one to hear it, the machine is left unchanged, is that effective?  This approach allows for “quick wins”, “low hanging fruit”, or what EAs call “yet another disconnected silos”, or the classic pattern of “optimizing the part and sub-optimizing the whole”.    

Enough of this irrelevance, now on to the cloud…  So we do have the Cloud First guidance.  This assertion is sort of helpful, but if you think it affects the machine and now the government is running to the “cloud”, or the Federal EAs discovered the cloud via this document, please read my other blog posts.  “The cloud” will require a strong Enterprise Architecture, David Linthicum gets it, and describes it a lot better than I can, I strongly recommend his book.

Posted by: joeyv1333 | October 5, 2011


I am only partially through Disaster – Hurricane Katrina and the failure of homeland security but I feel I can already recommend it.  This book is illustrative of practical FEA IMO.  A couple quick follow up points because the horse is nowhere near dead as I wrote in my first post the government is not a business.

I’m likely to write more about this in the future, but in my view FEA is a management tool, or as I prefer discipline (period).  The discipline of EA can be effective at all layers and views, business, technology, data.  Can Tiger Woods use a cheap golf club?  Would a graphite driver help a hack like me?  One of the first things that caught my attention in this book was the description of the legendary government manager James Lee Witt’s transformation of FEMA.  As I said in my first post I was at FEMA during Katrina, but not during Witt’s tenure so I have no firsthand experience but plenty of folklore about what went down during that time.   A story that my boss told me about Witt, is that he would “drop in” on her and others when she was a single digit GS to see what she was working on.  This is what we used to call management by walking around in the old days.  My summary of this folklore:

–          Really gave a darn about the mission and had significant experience in the domain (had a grudge of sorts according to the book from dealing with FEMA during a flood in Arkansas)

–          Had a B$ threshold of somewhere around zero (pretty sure he was not a college graduate)

–          Lived in reality, management by walking around, understood the as-is architecture for what it was and had a business vision of what it should be.

–          Removed layers of bureaucracy, didn’t add them.

–          Changed the staffing criteria/practices

–          Had the influential support of his boss, in this case the president,

So the agency was transformed without an established formal EA program and there was still time to walk around remote offices, chatting with junior staff.  I suspect a proper EA would have assisted and be used by Witt, but IMO the greatest EA problem of all time will not help the business layer with-out strong internal management or strong external drivers such as OMB/Congress.  I would encourage you to look at the state of what I call uber-EA, which in the government would mean congress etc. would use EA information in decision making.

Post Witt, and during my time there, the first EA problem to jump out at me in this book is the inventory/tracking failure, that was pretty well known at the time, an agency whose core mission was having stuff in time of emergency, really didn’t know where the stuff was.  Described in the book as “holes in the antiquated tracking system, noting: the white house asked: where are the water trucks? …We don’t know”.  This is a good case study/litmus test in EA philosophy IMO.  Is the right approach to this problem a process/”business” oriented one, or an information/application oriented one?   The orthodox, mainstream, politically correct answer is process, I agree in an ideal world but I do not agree in practice especially in the government.   Having been there, I can tell you that there was not enterprise process thinking, As-Is: “We call Charlie in the South Region and he looks at his access db, then we call Nancy in the West…”, how do you vision this working in the future?, “Well we call Charlie..” The approach I’ve seen work is we will have a master db of truck and water data that will maintain its integrity, now let’s talk about processes.  Another EA/IT struggle that I was on the losing side of there, related to technology, I can tell you there was no legitimate excuse for this to have happened.

Posted by: joeyv1333 | September 20, 2011

Government is not a business; FEA can ≠ “EA”.

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.

My background

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: Pointone 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?