Federal Enterprise Architecture

For Reference – Business to Systems Architecture Modeling Technique (Old – 2002 Document)

This is a document that I wrote during 2002. Although old, it still has some interesting discussion about business to software transformation in terms of modeling and techniques. Hope readers will find it useful.

Click link below

Business to Software Architecture Modeling Techniques

EA Modeling
EA Modeling

What we want Federal CIO to do

Vivek Kundra’s Resume: Much Ado About Nothing?.

Vivek Kundra’s Resume: Much Ado About Nothing?
Andrea DiMaio

August 14th, 2009 · 2 Comments

Over the last two days, the blogosphere has witnessed an interesting debate about whether Vivek Kundra’s resume is entirely accurate and sufficient for his current role as U.S. Federal CIO. It all started with a blog post by John Dvorak, where he casted doubts about Vivek’s academic achievements and his experience outside the public sector, followed by a post by Gauthan Nagesh on NextGov, shedding light on Vivek’s academic records and challenging Dvorak’s positions. It is quite intriguing to look at comments on either blog, as well as on many other blogs and online articles (just search for “Vivek Kundra qualifications” and you’ll find quite a lot).

Besides observing that politics are the same pretty much anywhere, with political appointees being regularly targeted by their opponents, the press and more recently by blogs (quite ironic in Vivek’s case, as he is a fervent believer in the power of Web 2.0), I am not really interested in whether these allegations are founded or not.

What I am more interested in is the fundamental question behind much of these discussions, i.e. is he qualified for the job at hand? In order to answer this question one has to looks at (1) the exact job description and (2) his achievements in related positions.

As far as (1), the job description in the White House’s announcement of Vivek’s appointment was:

The Federal Chief Information Officer directs the policy and strategic planning of federal information technology investments and is responsible for oversight of federal technology spending. The Federal CIO establishes and oversees enterprise architecture to ensure system interoperability and information sharing and ensure information security and privacy across the federal government. The CIO will also work closely with the Chief Technology Officer to advance the President’s technology agenda

Words are important here. He is not responsible for the federal IT budget (agencies are), but for its oversight. He directs policies and planning in order to advance the President’s technology agenda. Obama’s agenda clearly is about change in a number of areas, including IT as an important enabler of change. So I guess one of the most important trait the President was looking for was the ability to be a change agent.

Here comes (2), what did he do in the past to show such a trait? Well, I would argue that his achievements in D.C. as a CTO got the attention of many, ranging from how he changed portfolio management to how he made procurement more transparent up until his venture into crowdsourcing applications. He also got a number of recognitions during his tenure in D.C.

Those who have been reading this blog for some time know that I like Vivek and wished him well when he went into some trouble shortly after his appointment. I do not think that allegations or even facts about his qualifications as a student or an entrepreneur can deny his nature of change agent.

Where I believe challenges are for him as well as for the whole administration, is in deciding how to prioritize change, and how to find the right blend between continuity and innovation.

The risk is that in between open data, cloud computing, government 2.0, support to major programs like national broadband and health IT, Obama’s IT team finds itself chewing too much too soon.

If there is one thing that needs to be sorted out now, is how the CIO and CTO role relate to each other. A few days ago I watched an interview that CTO Aneesh Chopra gave to CNET, and could not get a straight answer to this, although the interviewers asked him a direct question. It is quite possible that roles, responsibilities and priorities have already been sorted out. But then, could we please know?


Tags: e-government
Jeff DePasquale // Aug 14, 2009 at 7:48 am

Net-net: I support Vivek as an Executive Partner under EXP. I find his approach to be refreshing and focused. Not sure what his paper qualifications are, but he’s demonstrated to our team his calculated ability to step outside the “beltway box”.

Srinidhi Boray // Aug 14, 2009 at 11:08 am

“”The Federal CIO establishes and oversees enterprise architecture to ensure system interoperability and information sharing and ensure information security and privacy across the federal government.””

Enterprise Architecture, no doubt is a mechanism that can help facilitate change. John Zachman, himself in his FEAC training mentions, that change a ’step function’ can be best anticipated via structures described in the Enterprise Architecture. And, EA is something that is learned over a period of time from experience. Unless, one is born savant.

In lack of architecture experience, most CIO’s in both federal and commercial sectors have made strategic decisions that have not manifested tactically with the desired results. There are numerous cases in the Federal. Should OIG in each agency work with motivation, then a lot of ill-conceived plans and associated ill spent millions of dollars can be purged. But who cares. Talking EA has become a fashion. And, planners lacking design mind introduce ‘empirical dilemma’, that is evident in the Federal Segment Architecture Methodology.

Within the CCA, A-130 Circular ‘information dissemination’ is just one portion of federal responsibility. Web 2.0, or any social networking although good, does not solve the country’s looming problem. Such as, the problem that HHS confronts – medicare, medicaid; that VA confronts – Veteran Patient Health Information system. So on and so forth, there are some very serious problem looming and they have no easy answers both in terms of budget planning and managing the architecture complexity. Here is where we want the Federal CIO to be active. Not dealing with superlatives and in the conceptual solutions domains. Government must be concerned with defining accurately the ‘problem domain’, not engage with ’solution domain’, but seek it instead.


User-Centric Enterprise Architecture: Enterprise Architecture Design

By Andy Blumenthal

User-Centric Enterprise Architecture: Enterprise Architecture Design.

User-centric Enterprise Architecture provides information to decision-makers using design thinking, so as to make the information easy to understand and apply to planning and investment decisions.

Some examples of how we do this:

  1. Simplifying complex information by speaking the language of the business (and not all techie).
  2. Unifying disparate information to give a holistic view that breaks the traditional vertical (or functional) views and instead looks horizontally across the organization to foster enterprise solutions where we build once and reuse multiple times.
  3. Visualizing information to condense lots of information and tell a story—as the saying goes, a picture is worth a thousand words.
  4. Segmenting end-users and tailoring EA information products to the different user groups which we do with profiles geared to executive decision makers, models for mid-level managers, and inventories for the analysts.

Interestingly enough, in the summer issue of MIT Sloan Management Review, there is an article called “How to Become a Better Manager…By thinking Like a Designer.”

Here are some design pointers from the experts that you can use to aid your enterprise architectures (they are written to parallel the principles from User-centric EA, as I have previously described above):

  1. Embrace simplicity—“people often confuse simplicity…with simplistic….it takes courage to be simple…and the simplest solution is often the best.”
  2. Look for patterns in the data—“good problem solvers become proficient at identifying patterns.” Further, designers seek “harmony to bring together hierarchy, balance, contrast, and clear space in a meaningful way.”
  3. Apply visual thinking—often managers…rely heavily on data and information to tell the story and miss the opportunity to create context and meaning,” instead managers need to “think of themselves as designers, visual thinkers or storytellers.”
  4. Presenting clearly to specific end-users—“good design is about seeing and communicating clearly.” Moreover, it’s about “seeing things from the clients point of view…designers learn pretty quickly that is not about Me, it’s about You.”

MIT Sloan states “we have come to realize over the past few years that design-focused organizations do better financially than their less design-conscious competitors…design is crafting communications to answer audience needs in the most effective way.

This is a fundamental lesson: organizations that apply the User-centric Enterprise Architecture design approach will see superior results than legacy EA development efforts that built “artifacts” made up primarily of esoteric eye charts that users could not readily understand and apply.

Game Theory : The essence of Enterprise Architecture is about establishing a “Dominant Strategy”

There is Darwinian in the below idea; however more congenial idea is Generative having more systemic congruent results

Same ideas can be repurposed in a better way.

The essence of Enterprise Architecture is about establishing a “Dominant Strategy”, that best achieves ‘economy of scale’. The economy of scale will apply to each of the architecture design decision selected. The set of design decisions that leads the architecture planning from strategy to tactical and from tactical to execution needs to converge to a dominant strategy engaging all the stake holders led by a cohesive mechanism of Governance.

Note: EA is about discussing the largest picture of the enterprise. Hence, any decision made must ensure that it lends sufficiently across the enterprise while increasing its “reuse”. This means ‘economy of scale’. All decisions, including the technical design decisions must yield a better ‘return on investment’ from optimized ‘performance vs cost’ perspective.

The main goal of the Governance, is to lead the dialogue that an enterprise riddled with complexities is engaged in,  towards a –“Dominant Strategy”. In many ways the array of events that Governance trigers, while working towards converging the decisions to a cohesive set of results, is similar to the behavioral probabilities  studied in Game Theory.

When a system is riddled with constraints, especially when  ‘money’ as  a resource is scarce, then it dominates the decisions needed to achieve the strategy. A system’s behavior  is governed by both micro and macro considerations. There is a threshold until which the system is probabilistically stable and is not affected by the micro behavior. After a certain threshold the micro behavior is unable to sustain the desired macro outcomes.

When Scarcity arises – Economics is Hot

Dominant Strategy

A strategy is dominant if, regardless of what any other players do, the strategy earns a player a larger payoff than any other. Hence, a strategy is dominant if it is always better than any other strategy, for any profile of other players’ actions. Depending on whether “better” is defined with weak or strict inequalities, the strategy is termed strictly dominant or weakly dominant. If one strategy is dominant, than all others are dominated. For example, in the prisoner’s dilemma, each player has a dominant strategy.

Introduction to Game Theory

Enterprise Architecture – Fifth Discipline


A calm élan – Architect.

Self Discipline critical to Personal Mastery

Self Discipline critical to Personal Mastery

Cardinal to be successful in the Enterprise Architecture area is – Personal Mastery. Like a lone Samurai one has to wander from project to project with the best intension in heart and mind. Each project with its accompanied defeats and successes comes experience that influences ‘Learning’. It is this learning that over the period of time imparts one with mastery of the subject. Most importantly all architecture related discipline can only be acquired by experiential learning. Nothing can replace experience. It is the only way to know what is salt , what is sugar, and also what is dope, when they all appear as mere white powder. And, yes EA area is full of dope. One should hazard its masquerading appearances.

With Personal Mastery comes awekening, this brings in Compassion. All these together will make one become ‘Extraordinary in an Ordinary World’.

Without ones personal usefulness there is no team work. As team work pre-supposes ‘Collaboration’. That means each member needs to bring something valuable that is intrinsic to the subject. This is not a schmoozing game.

In the following duel which is the last scene from movie Samurai Trilogy. The protagonist in the movie begins as a clumsy idiotic village bumpkin. And, he traveling through the experiences of life accompanied by human travesty learns the art of Samurai for which he has deep reverence. The constant learning of this art guided by the noble virtues of the Buddha’s teachings he emerges as a Calm élan Swordsman with compassion for his fellow men. The culmination of his mastery as a Samurai is depicted in the last duel rather very majestically. In the duel the presentation of the mastery is much filled with aesthetic sense, that the most able opponent is overcome by the  unseen deft handling  of the sword. In all awe for the Master Samurai and his swordsmanship, the vanquished warrior falls to his ever lasting sleep. The contrast between the warriors is worth noting that one is a highly schooled in one of the best traditional system, while the other is tamed by the rough edges of the experiences that the life had to offer. It was the ‘experience’ that although ruthless endowed  the wandering idiotic nincompoop with mastery of Samurai, rendering him into a Calm élan and an Aesthetic fighter.

The Five Disciplines

The five disciplines of the learning organization discussed in the book are:

Chasm in Federal Enterprise Architecture : FSAM & FEAF – The dilemma of divisive decisive


The Chasm between FEAF & FASM

Following Questions arises between FEAF and FSAM :-

Does the above questions make Federal Enterprise Architecture a boon or bane?

First of all “Segment” definition seems to be seriously flawed and riddled with “empirical dilemma” because of which it renders itself not anything architectural. It has confusing classification scheme that seems to follow no construct nor order. Schemes like this when applied to investment profiles, they seem more like apparition than anything real meaningful numbers on the Federal IT Dashboard.

Also, it seems that there is unconscious fascism, underpinning the modality of bringing together people (architect ?? ) to define ‘The Federal Segment Architecture Methodology’ (Architecture??). Many times in such scheme of thing certain locational existence gives people “power” not necessarily genuine “purpose”. This provides authority to a certain group of people, who have no real cause nor motivation ‘Serving the Citizens’ in all humility.


The term fascismo is derived from the Italian word fascio, which means “bundle” or group, and from the Latin word fasces; a fasces was a bundle of sticks used symbolically for the power through unity.[21][22] The fasces, which consisted of a bundle of rods that were tied around an axe, were an ancient Roman symbol of the authority of the civic magistrates; they were carried by his Lictors and could be used for corporal and capital punishment at his command.[22]

Furthermore, the symbolism of the fasces suggested strength through unity: a single rod is easily broken, while the bundle is difficult to break.[23] This is a familiar theme throughout different forms of fascism; for example the Falange symbol is a bunch of arrows joined together by a yoke.[24]

FSAM EA Assessment Version 3.0 – Revisions / Changes

Emphasis On Results

Emphasis seems to have moved towards Outcomes / Performance achieved as a consequence of an integrative approach- EA – CPIC – PMO, rather than mere architecture work-products (artifacts). Most importantly the revised FASM seems to arrest the OMB submissions by the agencies that masquerades in meeting the compliance while the enterprise architecture integrity still remains grievously in the lacking.

EA – PMO – CPIC Integration

Unless agencies strives in working as a collaborative unit while relying on a coherent governance that is built around sound integration of EA, CPIC & PMO no clear picture can ever be achieved. Especially, all the efforts in determining the ‘Total Cost Of Ownership’ for the prioritized businesses needing IT enablement will end in inevitable futility.

More Frequent Monitoring By OMB

OMB in the proposed revision will be monitoring the EA assessment submissions more frequently. Earlier only one submission a year was needed, now it will be necessary to submit 4 times a year. What does this mean? more paper work (defeats the very purpose of eGov 🙂 ). Should EA repository achieve architectural integrity, reflect accurately the state of the project and change management is efficiently maintained, then frequent submission will no more be a challenge . If inherently EA is in the lacking, then all efforts including the increased frequency in conducting EA assessment will fail in arresting the the inherent atrophy. When one begins to designs in quality, then testing and assessment will prove to be redundant functions.

Assessment of Target Architecture under FSAM

Assessment of Target Architecture under FSAM

EA Assessment requirement under new FSAM

EA Assessment requirement under new FSAM