Jaa

What EA Means to One Agency of the Federal Government

  • Artikkeli

I ran across a document from the Dept. of Commerce that describes Enterprise Architecture as follows:

“An Enterprise Architecture (EA) is a blueprint that explains how the results of Strategic Planning, Performance Planning, Budgeting, Capital Planning and Investment Control, Security and Privacy procedures, Acquisition, and other related information technology (IT) and general management processes work together to meet the enterprise's mission and objectives.  The EA development process leads to an integrated framework, based on principles and standards, which explain Commerce’s mission and how resources will be deployed to accomplish that mission. The EA documents the future state of the Department’s information technology based on business and technology drivers as well as the transition plan for moving from the current (as-is) state to the future (to-be) state. An EA modeling toolset helps enable the development and implementation of the EA.” (source link).

Fascinating.  Breaking this down a bit, the first sentence of the definition says:

  • A bunch of processes exist, specifically including but not limited to: Strategic Planning, Performance Planning, Budgeting, Capital Planning and Investment Control, Security and Privacy procedures, and Acquisition.
  • Other processes exist that are grouped under “related information technology (IT) and general management processes.”
  • Those process work together to meet the enterprise’s mission and objectives.
  • An EA is an artifact that provides a blueprint to explain how these processes work together to meet the mission and objectives.

 

The second sentence says:

  • An Enterprise Architecture (the artifact) is developed through a process. 
  • Following the EA development process, an enterprise produces an integrated framework.
  • The integrated framework is based on principles and standards.
  • The integrated framework explains the mission of the agency.
  • The integrated framework explains how resources will be deployed to accomplish that mission.

 

The third sentence says:

  • An Enterprise Architecture (the artifact) documents the future of agency technology.
  • The future is based on business drivers and technology drivers.
  • An Enterprise Architecture (the artifact) documents the transition plan for achieving the future.

 

The fourth sentence says:

  • Tools are helpful (but not required) to enable the development of an Enterprise Architecture (the artifact).

 

There are 13 statements in that definition of EA.  Is it really necessary to make 13 statements in order to create a definition of Enterprise Architecture?  Apparently the US Department of Commerce thought that it was.  There are some interesting statements in there, that represent a particular viewpoint on EA.  There are also some statements that may reflect internal politics or discussions.  

I am interested in solving a specific problem: how should all EA programs describe themselves?  Given that problem, I find the following statements interesting:

  • An Enterprise Architecture is a thing.  It is tangible.  It can be delivered, and the act of delivering it can be measured. 
  • An Enterprise Architecture specifically includes IT resources and excludes everything else.
  • This thing called an EA contains a couple of interesting parts:
    • An explanation of the agency’s mission and objectives.
    • An explanation of how the agencies’ resources should, in the future, work together to meet that mission and those objectives.
    • A transition plan to explain how gaps will be addressed.

 

I have a couple of big problems with this definition. 

  1. The biggest problem I have is the second statement: that an EA is limited to technology.  That doesn’t make sense to me.  Technology cannot be mapped to the enterprise without a full understanding of the process architecture and shared information requirements of the enterprise.  It is good to create a future state technology roadmap after the enterprise architecture is developed, but not before, and not necessarily as part of the enterprise architecture itself. 
     
  2. A smaller problem is that the definition goes into detail by saying that a blueprint will be created, but not much detail on why it is created, how it is created, and when it is supposed to be used.  So what is the purpose of defining Enterprise Architecture if you don’t use the opportunity to answer some of these key questions?
     
  3. Lastly, the definition describes a couple of interesting deliverables, including a blueprint and a transition plan.  Why should a select group of experts create them?  Can anyone create them?  Is there a low bar of quality that we should not fall below?  It justifies the creation of the artifact, and even discusses the tools, but not the people who will create it or the skills that they must possess to do so effectively. 

What are your thoughts?  Is it useful for all organizations to leverage the same definition of Enterprise Architecture?  Do you agree with the statements made in this definition?  Is an EA a thing?  Should the definition of EA mention all of the items mentioned?  Should it be extended to fill in the gaps identified?