Showing posts with label Federal Enterprise Architecture. Show all posts
Showing posts with label Federal Enterprise Architecture. Show all posts

September 11, 2010

Toward A Federal Enterprise Architecture Board


A Federal Enterprise Architecture Board (FEAB) would provide “teeth” to further implementing enterprise architecture across government.

We have a Federal Enterprise Architecture (FEA) that provides a government wide framework for architecture strategy and planning, but we do not have a FEA Board to govern the subsequent IT investments through capital planning and investment control (CPIC). CPIC is the governance process whereby we select, control, and evaluate new IT investments.

Interestingly, The Federal CIO Council’s Architecture Alignment and Assessment Guide (October 2000) specifically calls for complementary EA and CPIC functions (see graphics).

In this paradigm, the enterprise architecture (EA) informs, guides, drives the CPIC, and in turn the decisions from the CPIC governance process updates the EA planning, so that the EA and CPIC processes are seen as mutually supportive.

In the federal government, we have departmental and agency architectures and boards that serve to plan and govern IT investments at their respective levels. However, as we seek to build greater standardization, interoperability, and reuse across government with IT initiatives that cut across traditional government boundaries driven and guided by the Federal CIO and Federal CIO Council, there is a need for a FEAB to review new and major changes to IT investments.

There would be many purposes for the FEAB.

  • Strategic alignment: One would be to ensure strategic alignment not to any single department or agency mission, but rather to the greater federal government strategy and policy. Some examples of this would be data center consolidation, green IT, open government, and more.
  • Streamlining of investments: Additionally, the FEAB would assess IT investments to ensure that there is no overlap or opportunities for consolidation of initiatives. OMB performs some of this function today, but a FEAB would augment their capability with IT subject matter experts from across the government.
  • Other key benefits: Of course, the FEAB would also look at things like return on investment measures, risk mitigation plans, technical compliance to federal architecture standards and mandates (security, privacy, records, FOIA, Section 508, etc.).

The FEAB would not be a substitute for the EA Boards that provide oversight functions at the department and agency levels, but would provide governance for the largest and riskiest IT initiatives and those that cut across different agencies.

While the OMB currently assesses IT investments using Exhibits 300s and 53s, which include EA assessment questions, the FEAB would provide a governance board made up of cross-cutting governmental IT subject matter experts to vet these business cases from an EA perspective thoroughly and provide recommendations to the Federal CIO Council and the OMB on approval or denial. Therefore, and not unimportantly, the stand-up of a FEAB would add an important human factor to the Federal Enterprise Architecture and make it “real.”

Of course, with a portfolio of some 10,000 IT systems, the FEAB would not be able to govern every new Federal IT investment. Therefore, it would be critical to establish thresholds that would be practical for implementation.

I would envision the FEAB being chaired by the Federal Architect and the board being a recommendation body to the Federal CIO Council and the Office of Management and Budget, Executive Office of the President.

Critical initiatives by Federal CIO Vivek Kundra to effectively manage (i.e. CPIC control phase) IT investments through the Federal IT Dashboard and TechStat sessions would be augmented by the FEAB work to carefully recommend for selection (i.e. CPIC select phase) new federal IT investments.

Together, I see the federal select and control mechanisms of CPIC functioning in harmony to enhance governments IT planning, investment decision-making, and execution. Essentially, the FEA (architecture) and FEAB (governance) on the “front-end” will guide new IT investments, and the IT Dashboard and TechStat sessions on the “back-end” will ensure IT investments are properly progressing for the taxpayer based on cost, schedule, and performance measures.

In summary, the Federal Enterprise Architecture Board would be the governance arm of the Federal Enterprise Architecture, and serve as a support to the IT leadership of the Federal CIO, the Federal CIO Council, and the IT budgetary functions performed by the Office of Management and Budget.

Share/Save/Bookmark

July 12, 2009

Information Management Framework

The Information Management Framework (IMF) provides a holistic view of the categories and components of effective information architecture.

These categories include the following:

Information-sharing--Enable information sharing by ensuring that information is visible, accessible, understandable, and interoperable throughout the enterprise and with external partners.

Efficiency--Improve mission efficiency by ensuring that information is requirements-based, non-duplicative, timely, and trusted.

Quality--Promote information quality, making certain that information provided to users is valid, consistent, and comprehensive.

Compliance--Achieve compliance with legislation and policy providing for privacy, freedom of information, and records management.

Security-- Protect information assets and ensure their confidentiality, integrity, and availability.

All areas of the framework must be managed as part of effective information architecture.

Share/Save/Bookmark

June 18, 2008

Employee Onboarding and Enterprise Architecture

The human capital perspective of the enterprise architecture is often overlooked, and is not yet included in the Federal Enterprise Architecture (FEA), but I’m still hopeful.

A recent article in Federal Times, 9 June 2007, called “First Day on the job, first step to retention” demonstrates that human capital architecture is alive and well although not consistently used.

A report by the Partnership for Public Service found that “the government has no consistent approach to bringing new employees on board; new employees often aren’t taught about and initiated into their new agency’s culture; and technology that could ease the process and improve collaboration is underused.”

However, some agencies are coming up with new ways to welcome new employees, make them feel “at home” on the job, get them situated, acclimated and trained, so they quickly become productive employees with longevity at the agency.

For example in setting up the logistics for a new employee, “GAO and NASA have each developed case management systems to track new hires from the moment they accept the offer. The system alerts information technology offices to set up a computer network access and email account for a new employee; facilities staff will prepare an office and desk; and security staffs work in advance to arrange needed clearances.”

The Office of the Comptroller of the Currency (OCC) goes above and beyond when it comes to onboarding. OCC send new hires “a welcome basket with an agency-branded T-shirt, umbrella, luggage tags, and chocolates.” Not a bad introduction for someone starting new in a place.

GAO, NASA, OCC are all good examples of what human capital enterprise architecture is all about. I would suggest growing this list and building it into a FEA human capital perspective.

We cannot take our employees for granted. Their enthusiasm, determination, innovation, empowerment, and leadership is what will drive the organization ultimately to succeed or not.

The enterprise architecture human capital perspective can look at the lifecycle of the employee from recruiting, hiring, and onboarding all the way through their 30+ year careers and into retirement. The enterprise architecture can assess how we manage the human capital lifecycle in the enterprise today, establish a future target state, and develop the transition plan to move the organization towards best practices for managing our most critical asset, our people.


Share/Save/Bookmark

May 9, 2008

Gamers and Enterprise Architecture

More and more people are turning to gaming for entertainment, social interaction, some thrills and fun and even some challenge.

Many in society think that gamers, because they like to “play”, are childish, slovenly or irresponsible. However, there are many characteristics that gamers demonstrate that demonstrate that they are perhaps some of the best employment “catches” around.

Harvard Business Review, February 2008, states that “the gamer disposition has five key attributes. More than attitudes or beliefs, these attributes are character traits that players bring into game worlds and that those worlds reinforce. We believe that gamers who embody this disposition are better able than their non-gamer counterparts to thrive in the twenty-first century workplace.”

What are the gamer characteristics that can enable them to succeed in the modern workplace?

  1. Performance-oriented—“gamers like to be evaluated, even compared with one another, through systems of points, rankings, titles, and external measures. Their goal is not to be rewarded, but to improve.”
  2. Value diversity—“diversity is essential in the world of the online game. One person can’t do it all; each player is by definition incomplete. The key to achievement is teamwork, and the strongest teams are a rich mix of diverse talents and abilities.”
  3. Desire change—Nothing is constant in a game; it changes in myriad ways, mainly through the actions of the participants themselves…gamers do not simply manage change,; they create it, thrive on it, seek it out.”
  4. Learning is fun—“for most players, the fun of the game lies in learning how to overcome obstacles.”
  5. Innovative—“gamers often explore radical alternatives and innovative strategies for completing tasks, quests, and challenges. Even when common solutions are known, the gamer disposition demands a better way, a more original response to the problem.”

How do gamers, or for that matter people in general, relate to enterprise architecture?

Gamers are a growing segment of the population and their characteristics and skill sets need to be integrated in support of our business processes and technologies. The way to do this is through an enterprise architecture that speaks to a human capital perspective.

Many times, I have written about the need for a human capital perspective (reference model) to be added to the Federal Enterprise Architecture (FEA). This would address the “people/who” perspective of the Zachman Framework and address the critical issues of the most important asset of the organization, its people.

Unfortunately, the FEA is still anchored in the industrial revolution, with factories served by “indentured” workers on the assembly line; people no more important than the mind-numbing, repetitive tasks that they performed 12 or more hours a day for little pay and certainly little respect.

The Federal Enterprise Architecture needs to enter the information age, where knowledge workers are the catalyst of innovation, engineering, modernization and transformation. The addition and focus on a human capital perspective to the architecture would be a good start to recognizing the centrality of people and brain-power to the competitiveness and future of our industries and nation.

One of the issues that the human capital perspective should address are the types of skills and attributes (such as those that gamers demonstrate) that are best aligned to support the requirements of the enterprise and its mission.


Share/Save/Bookmark

September 29, 2007

James Madison, the First “Federal Chief Enterprise Architect”

James Madison, Jr. (March 16, 1751 – June 28, 1836) was an American politician and the fourth President of the United States (1809–1817), and one of the most influential Founding Fathers of the United States. Considered to be the "Father of the Constitution", he was the principal author of the document. In 1788, he wrote over a third of the Federalist Papers, still the most influential commentary on the Constitution. As a leader in the first Congresses, he drafted many basic laws and was responsible for the first ten amendments to the Constitution, and thus is also known as the "Father of the Bill of Rights". James Madison also drafted the Virginia Plan, which “called for a national government of three branches—legislative, executive, and judicial…The concept of checks and balances was embodied in a provision that legislative acts could be vetoed by a council composed of the Executive and selected members of the judicial branch; their veto could be overridden by an unspecified legislative majority.” (Wikipedia)

As the Father of the Constitution, Bill of Rights, and Virginia Plan, James Madison was the original Chief Enterprise Architect (CEA) for the federal government. As the Federal CEA, Madison architected the performance, business, and information perspectives of the federal enterprise architecture (the information technology side of the equation—services, technology, and security—would come later with the post-industrial, technological revolution)

Performance—The mission execution and expected results are laid out in The Preamble to the Constitution, that states: “We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America.” Additionally, the Bill of Rights ensures that the government performs its business functions all the while protecting the rights of its citizens.

Business—The functions, activities, and processes are detailed in the Articles of The Constitution, including the functioning of the legislative, executive, and judicial branches of government, as well as state and federal powers, and processes for amendments and ratification. Additionally, the checks and balances ensure that functions are well-defined and that limits are placed on each branch of the government to protect democracy and forestall tyrannical rule.

Information—The information requirements of the Federal government are provided for in the various branches of government. For example, the legislative branch, Article One provides for free debate (the archetype for information sharing and accessibility) in Congress. Additionally, the checks and balances between the branches, provides for information flow. For example, Congress enacts the laws, and these go to the Executive Branch to carry them out, and to the Judicial Branch to interpret them. Furthermore, the political value system, Republicanism, ensures that the people remain sovereign and that they not only elect their representatives and politicians, but also can provide information and lobby to affect the enactment of laws and regulations that will ultimately affect them. Citizens are asked to perform their civic duties and to participate in the political process, so there is a free-flow of ideas and information throughout the governing process.

James Madison is indeed the original federal chief enterprise architect and a very good one at that!


Share/Save/Bookmark

September 15, 2007

SOA – Does the Emperor Have Clothes?

Architecture and Governance Magazine, Volume 3 Issue 3, reports that one of the Top 10 Challenges in Enterprise Architecture is “Getting Ready for Service-Oriented Architecture (SOA)”.

- Why is SOA proving to be such a challenge?

The article reports that “most architects have not done much of either substance or significance in this area.” Further, “most of what enterprise architects have addressed in this space concerns aligning IT with the business and governance”—and this is something that EA has been doing all along anyway.

- So what has SOA changed?

“What has changed is the promise of abstracting services that can be reused.”

However, some have questioned SOA:

  1. Is SOA “just a revival of modular programming (1970s), event-oriented design (1980s), or interface/component-based design (1990s)”?
  2. Is SOA “just another term for Web Services”?
  3. Is SOA “merely an obvious evolution of currently well-deployed architecture (open interfaces, etc.)”? (Wikipedia)

Others have questioned if SOA and EA are even distinct disciplines?

“So, has SOA in fact evolved into EA? A to question to which the answer is yes and no." The author continues, “essentially there are three evolutionary paths:

  1. EA is absorbed by SOA
  2. SOA is absorbed by EA
  3. EA / SOA merge into a new concept”

Finally, the authors propose #3 merging EA and SOA as follows:

“SOA-A+EA = SOEA”

With the conclusion that “in order to create this holistic view EA and SOA must not be seen as separate disciplines, but to see the two as one will bring changes on such a scale that we are now talking about SOEA Service Oriented Enterprise Architecture.” (Journal of Enterprise Architecture, August 2007, Rasmus Knippel and Bo Skytte)

While the authors apparently seems to think SOA is important (although they call it "increasingly more abstract"), the relationship to EA is changing and unclear—Not sure this idea about SOEA is helpful at this juncture!

- How helpful to SOA development is the guidance from the Federal Enterprise Architecture (FEA), Service Reference Model (SRM), which talks about services and capabilities?

Not very! The SRM is supposed to “provide a high-level view of the services and capabilities that support enterprise and organizational process and applications.” (FEA, SRM). However, the service domains, service types, and capabilities listed in the FEA SRM are quite muddy, at best. Here is an example:

  • The domain of Process Automation is defined as “the set of capabilities that support the automation of process” [hasn’t every 5th grader been taught not to define a term with the same term?]
  • And it continues “and management that assists in effectively managing the business” [well that is a pretty broad definition— can’t all services assist in effectively managing the business?].
  • Then after the definition, you’re expecting some pretty extensive process automation services, but the SRM lists just 2 components:
  1. Tracking and Workflow (which includes capabilities like case management [what’s that doing here?] and conflict resolution [isn’t that a leadership skill set?])
  2. Routing and Scheduling, which includes just Inbound and Outbound Correspondence Management [so where the scheduling piece like calendaring or time management that one normally associates with scheduling and how does the routing as in Routing and Scheduling reflect the routing inherent in Tracking and Workflow category above—seems like some category overlap]

I’ll let you look at the SRM yourself to see evaluate the clarity of the other categories, but they are pretty much the same. Ok, I can’t resist, here’s one more:

  • The domain called Business Management Services, after the domain of Process Automation, actually has a service type in it called management of process {why isn’t this in the process automation domain?].
  • The other service types in this domain include Organizational Management [that includes workgroup/groupware and network management, huh?]
  • And Investment Management [ok]
  • And Supply Chain Management [which includes things like procurement, Warehousing, and Inventory Management— so why isn’t this part of back office services, like Finance, Human Capital, and Asset/Material Management?]

If this looks confusing, you’ve got my point, it’s because the FEA SRM is confusing.

- So what’s an enterprise architect to do?

Architecture and Governance Magazine says, enterprise architects need to take back the high ground here—and that must be done in 2007…today’s enterprise architect must re-engage with all the principals in the enterprise by making a case for seeing service and technology architectures as one.”— this is good advice, I suppose, but also more than a little vague!

I’ve seen a bunch of presentations (including a recent one from Department of Education) where EA has tied IT services (pretty much their IT portfolio) to requested business capabilities—again it seems pretty much like what EA is or should have been doing all along, aligning business and technology investments with a focus on reducing gaps, redundancies, and inefficiencies.

I’ve seen other people including some prominent computer and consulting vendors present this topic as well, and aside from pushing there wares, have seen them fall all over themselves tying to define and explain SOA. Honestly, it was pathetic!

Finally, I have seen one impressive implementation at a government agency, and it did actually have savings associated with it, but the application was done a few years back, was relatively small, and there has been little to no movement on further SOA development since (except for the purchase of an enterprise service bus) even though there is a mandate in this agency to implement SOA.

In fact, at a recent meeting with the business side from operations, the presenters said that they were going to spend oodles of money rewriting one (if not the) major operational application for the agency (over 1.2 million lines of code and growing) to make it .NET compliant. I asked the business if they were going to take this opportunity to do this using SOA, and they said no, they just want the same functionality as before!

So in the end, if the business doesn’t want it and the vendors and consultants can’t explain it, the final question with SOA is does the emperor really have clothes?


Share/Save/Bookmark

September 9, 2007

The Peter Principle and Enterprise Architecture

The Peter Principle—Formulated by Laurence J. Peter, the Peter Principle states that "in a hierarchy every employee tends to rise to his level of incompetence." More generally speaking, anything that works will be used in progressively challenging applications until it causes a disaster (i.e. ‘The Generalized Peter Principle’).”

How does the Peter Principle work?

“The Peter Principle's practical application allows assessment of the potential of an employee for a promotion based on performance in the current job, i.e. members of a hierarchical organization eventually are promoted to their highest level of competence, after which further promotion raises them to incompetence. That level is the employee's ‘level of incompetence’ where the employee has no chance of further promotion, thus reaching his or her career's ceiling in an organization…One way that organizations attempt avoiding this effect is to refrain from promoting a worker until he or she shows the skills and work habits needed to succeed to the next higher job. Thus, a worker is not promoted to managing others if he or she does not already display management abilities.” (adapted from Wikipedia)

The Peter Principle demonstrates various human capital issues in the organization that range from performance management to leadership development. While there are no simple answers, there is clearly a need to focus on these issues and for them to be included as part of overall enterprise architecture planning and governance. Perhaps (a far-fetched idea, although one that the military successfully uses) promotions—like new IT systems, products or standards—would be managed through a human capital review board that would catch some of these faulty promotions before they turn into disasters for the employees and the organization.

Let’s add a Human Capital Perspective to the FEA:

To clarify, EA is not only a technology function but is a business function, and as part of the business function, I am calling for the addition of a human capital perspective to the Federal Enterprise Architecture!

Further, while some erroneously consider EA an information or documentation endeavor, it is much more than that—it is a planning and governance mechanism for the organization. And to effectively plan and govern (to execute on mission and achieve success), EA must include a human capital perspective, since people are our organization’s most valuable asset.

In User-centric EA, issues like how to mitigate negative effects of the Peter Principle could be addressed with the addition of a human capital perspective (see usercentricea.blogspot.com posting for 29 July 2007), which would deal with the many behavioral, cultural, and managerial issues regarding human capital facing the enterprise.

A Human Capital perspective to EA would include the following types of information:

  • Professional and management development
  • Leadership development
  • Succession planning
  • Performance management
  • Skills management
  • Training
  • Team building
  • Labor relations
  • Recruiting
  • Retention
  • Morale

I encourage and call for the adoption of a human capital perspective to the Federal Enterprise Architecture (FEA).


Share/Save/Bookmark

September 7, 2007

Information Sharing Best Practices

There are currently two major federal best practices for information sharing: Netcentricity and the Information Sharing Environment.

The Department of Defense (DoD) adopted a Netcentric Strategy in May 2003.

  • Netcentricity—Netcentricity seeks to ensure data visibility, availability, and usability to accelerate decision-making. This includes data tagging (metadata), posting data to shared spaces, and enabling the many-to-many exchange of data (i.e. many users and applications can access the same data instead of point-to-point interfaces). Netcentricity is the realization of a networked environment.
  • Global Information Grid (GIG)—The GIG is a globally interconnected, end-to-end set of information capabilities, associated processes and personnel for collecting, processing, storing, disseminating and managing information on demand to warfighters, policy makers, and support personnel. The GIG includes all owned and leased communications and computing systems and services, software, data, security services and other associated services necessary to achieve information superiority.
Netcentricity is a strategy for sharing information. As the DoD strategy states: The data strategy is to “shift from private data to community or Enterprise data as a result of increased data “sharing” in the netcentric environment. Tagging, posting, and sharing of data are encouraged through the use of incentives and metrics.” (adapted from DoD Net-Centric Strategy from defense.link.mil, public site)

In 2004, the concept of Netcentricity was extended to the Director of National Intelligence (DNI)’s Information Sharing Environment with the passing of the Intelligence Reform and Terrorism Prevention Act (IRTPA).

  • Information Sharing Environment (ISE)The IRTPA requires the President to establish an ISE “for the sharing of terrorism information in a manner consistent with national security and with applicable legal standards relating to privacy and civil liberties” and the IRTPA defines the ISE to mean “an approach that facilitates the sharing of terrorism information.”

The ISE seeks to “facilitate trusted partnerships among all levels of government, the private sector, and foreign partners…[and to] promote an information sharing culture among partners by facilitating the improved sharing of timely, validated, protected, and actionable terrorism information.” (adapted from Information Sharing Environment Implementation Plan from ISE.gov, public site)

Both Net-centricity and ISE are best practices at increasing information sharing to improve and speed up decision-making and protect our nation and its citizens!

  • As the DoD Net-Centric Strategy states: “the core of the net-centric environment is the data that enables effective decisions.”
  • And similarly, in the ISE Implementation Plan, we read, “the highest priority in creating the ISE must be on facilitating, coordinating and expediting access to protected terrorism information.”

In User-centric EA, information sharing, as appropriate, is one of the primary goals of the architecture. Information is one of the six perspectives (performance, business, information, services, technology, and security, and a seventh to be added is human capital) of the EA. The primary principal of the Information perspective is information sharing and accessibility. Further, the Federal Enterprise Architecture (FEA) Data Reference Model (DRM) is driven by the enablement of sharing information across the federal government and to its partners. The methodology is as follows:

  • Consistently describe data (via metadata)
  • Register the data (to make it discoverable)
  • Develop standards for the exchange of data (to enable interoperability and accessibility)
  • Provide sound governance (including data policy and stewardship).

User-centric EA is driven to fulfill the vision of Net-centricity and ISE.


Share/Save/Bookmark

August 24, 2007

Why Isn’t There a Chief Data Architect in the Federal Government?

In the federal government, there is a Chief Enterprise Architect in the Office of Management and Budget (OMB) — this is a good thing.

But the question that I have is why there isn’t a Chief Data Architect as well?

We all know that one of the essentials to good architecture is having strong data architecture that provides for data descriptions (or metadata) to uniformly describe data, data context (or taxonomies) for discovery, and that supports data sharing (or exchange).

In the Federal Enterprise Architecture (FEA), there is a Data Reference Model (DRM). Moreover, in the FEA, data is the crucial touch point between on one hand, the business functions toward achieving desired performance outcomes, and on other hand, the services and technologies that serve up the data in order to perform the functions and activities of the enterprise.

Furthermore, in developing technology solutions of the enterprise, one very important question for the business is what their information and data requirements are. The answer to this helps drive the technology solution.

For the federal government, the benefits of maturing its data architecture could be significant, especially in being able to share vital information, and thereby fill gaps and reduce redundancy across the federal enterprise. Given the size and important scope of the federal government missions, the imperative is great!

The Chief Data Architect would focus on data issues and drive such things as data standardization, common lexicon, metadata development, exchange standards and directories, service oriented architecture, and overall information sharing.

What do you think--would a Federal Chief Data Architect be a good idea to help progress this?


Share/Save/Bookmark