Showing posts with label OMB. Show all posts
Showing posts with label OMB. 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

October 23, 2009

Business Process Reengineering and Enterprise Architecture

User-centric EA analyzes problem areas in the organization and uncovers gaps, redundancies, inefficiencies, and opportunities; EA uses this information to drive business process reengineering and improvement as well as to introduce new technologies to the enterprise.

According to the Office of Management and Budget (OMB) Circular A-130, Management of Federal Information Resources, business process reengineering needs to take place to achieve the benefits of new information technology: “Moreover, business process reengineering should accompany all attempts to facilitate a transaction through information technology. Often the full benefits will be realized only by restructuring the process to take advantage of the technology. Merely moving an existing paper based process to an electronic one is unlikely to reap the maximum benefits from the electronic system.”

In the book The 21st Century Organization by Bennis and Mische the authors explain how organizations can reinvent themselves through reengineering.

What exactly is reengineering?

Reengineering is reinventing the enterprise by challenging its existing doctrines, practices, and activities and then innovatively redeploying its capital and human resources into cross-functional processes. This reinvention is intended to optimize the organization’s competitive position, it value to shareholders, and its contribution to society.”

What are the essential elements of reengineering?

There are five:

  1. A bold vision
  2. A systemic approach
  3. A clear intent and mandate
  4. A specific methodology
  5. Effective and visible leadership”

What activities are involved in reengineering?

  • “Innovating
  • Listening to customers
  • Learning
  • Generating ideas
  • Designing new paradigms
  • Anticipating and eclipsing competitors
  • Contributing to the quality of the workplace and the community
  • Constructively challenging established management doctrines”

“Reengineering the enterprise is difficult. It means permanently transforming the entire orientation and direction of the organization. It means challenging and discarding traditional values, historical precedents, tried-and-true processes, and conventional wisdom and replacing them with entirely different concepts and practices. It means redirecting and retraining workers with those new concepts and practices...The very cultural fiber of the enterprise must be interrogated and redefined. Traditional work flows must be examined and redesigned. Technology must be redirected from supporting individual users and departments to enabling cross-functional processes.”

What are the goals of reengineering?

  • “Increasing productivity
  • Optimizing value to shareholders
  • Achieving quantum results
  • Consolidating functions
  • Eliminating unnecessary levels of work”

Reengineering seeks to increase productivity by creating innovative and seamless processes…the paradigms of vertical ‘silo’ tasks and responsibilities is broken down and replaced with a cross-functional, flatter, networked structure. The classical, top-down approach to control is replaced with an approach that is organized around core processes, is characterized by empowerment, and is closer to the customer....Reengineering constructively challenges and analyzes the organization’s hierarchy and activities in terms of their value, purpose, and content. Organizational levels and activities that represent little value to shareholders or contribute little to competitiveness are either restructured or eliminated.”

What is the role of EA?

EA is the discipline that synthesizes key business and technology information across the organization to support better decision-making. EA develops and maintains the current and target architectures and transition plan for the organization. As OMB recommends, in setting enterprise targets, EA should focus first and foremost on business process reengineering and then on technology enablement. If the organization does not do process reengineering first, the organization risks not only failing to achieve the benefits of introducing new IT, but also causing actual harm to the organizations existing processes and results. For example, adding a new technology without reengineering process can add additional layers of staff and management to implement, maintain, and operate the technology instead of creating a net resource savings to the organization, from more efficient operations. Similarly, without doing reengineering before IT implementation, the enterprise may actually implement IT that conflicts with existing process and thus either require timely and costly system customization or end up adversely impacting process cycle time, delaying shipments, harming customer satisfaction, and creating bloated inventories, and so on.

Bennis and Mische predict that in the 21st century “to be competitive, an organization will have to be technology enabled…the specific types of technology and vendors will be unimportant, as most organizations will have access to or actually have similar technologies. However, how the organization deploys its technological assets and resources to achieve differentiation will make the difference in whether it is competitive.”


Share/Save/Bookmark

December 31, 2008

Comments from OMB's Chief Architect: Kshemendra Paul

Recently, Kshemendra Paul, Chief Enterprise Architect, at the President's Office of Management and Budget (OMB) made the following critical comments to me about business cases and pilots and incorporating these in the Systems Development Life Cycle:

"I was online and came across your site -
http://usercentricea.blogspot.com/2007/08/system-development-life-cycle-and.html.

I had two comments I wanted to share. First, I would recommend you highlight a business case step, a formal decision to move out of select/conceptual planning and into control. While this is implied, it is such a crucial step and we don't do it well - meaning that we don't force programs to work through all of the kinks in terms of putting forward a real business case (tied to strong performance architecture).

Also, this is a step that is inevitably cross boundary - either on the mission side and for sure on the funding side.

Second, I'd like to see more emphasis on smaller scale rollout or piloting. The goal of which is to prove the original business case in a limited setting. Nothing goes as planned, so another objective is to have real world data to refine the over all plan."

I completely agree with Kshemendra on the need to develop business cases and do them well for all new initiatives.

Organizations, all too often, in their zeal to get out new technologies, either skip this step altogether or do it as a "paper" (i.e. compliance) exercise. Symbolic, but wholly without intent to do due diligence and thus, without any genuine value.

Therefore, whenever we plan for new IT, we must ensure strategic business alignment, return on investment, and risk mitigation by developing and properly vetting business cases through the Enterprise Architecture and Investment Review Boards.

It's great to want to move quickly, get ahead of the pack, and gain competitive advantage by deploying new technologies quickly, but we risk doing more harm than good, by acting rashly and without adequately thinking through and documenting the proposed investment, and vetting it with the breadth and depth of organizational leadership and subject matter experts.

Secondly, as to Kshemendra's point on doing pilots to prove out the business case. This is an important part of proofing new ideas and technologies, before fully committing and investing. It's a critical element in protecting the enterprise from errant IT investments in unproven technologies, immature business plans, and the lack of ability to execute.

Pilots should be incorporated along with concept of operations, proof of concepts, and prototypes in rolling out new IT. (See my blog http://usercentricea.blogspot.com/2007/08/conops-proof-of-concepts-prototypes.html)

With both business cases and pilots for new IT projects, it's a clear case of "look before you leap." This is good business and good IT!

Share/Save/Bookmark

September 28, 2008

The Outlook for Enterprise Architecture

Enterprise architecture in its current form is due for a review by the next administration—McCain or Obama.

Will EA be the same under the next president?

Government Executive Magazine, 15 September 2008, discusses “seven election-proof initiatives likely to go on in some form or another no matter who wins in November,” and enterprise architecture is one of those.

The Federal Enterprise Architecture is looked at as a mixed bag by the Office of Management and Budget.

On one hand, it has been “a jargon-filled, technical IT effort, and one of the toughest for the Bush administration to tackle.”

On the other hand, “prognosticators say it will survive in some form because it has been a useful planning tool for chief information officers.”

Indeed EA is a challenge for any organization—planning and driving business and technology change, breaking down organizational and functional silos, pushing for information sharing, interoperability, and reuse, mandating technical standards and preferred products, insisting on performance measurement, and enforcing compliance of IT security, privacy, Section 508, records management—EA is even more taxing for OMB which is looking to do these things across the entire federal government!

What is undeniable is that enterprise architecture plays a vital function in our organizations!

The vice president of FedSources, Ray Bjorklund, states: “As painful as an architecture is to create, it is really very helpful.”

Glenn Schlarman, former chief of Information Policy and Technology Brach at OMB, states “I don’t give architecture in its current state much of a chance of survival because it’s too complex. If they could distill it down to a couple of salient points and wrap it with security then maybe it can be saved.”

While the Schlarman’s points may sound harsh, I actually agree with him on the unnecessary complexity. This is a core tenet of User-centric Enterprise Architecture. As Schlarman says, we need to “distill” the message and clearly present it to our organizational decision makers. It needs to be useful and useable to them!

EA will not only be saved, but will continue to thrive. As global competition continues to heat up, the pace of technology change spins faster and faster, and constrained resources continue to press us to do ever more with ever less, our organizations will be forced to respond in strength. Organization’s will continue look to enterprise architecture to better plan business process improvement and IT enablement and to govern sound investments and change. User-centric EA will keep the efforts focused on valuable and actionable architectures.


Share/Save/Bookmark

August 30, 2008

A Federal CIO / CTO

Should the U.S. federal government have a Chief Information Officer (CIO) and/or a Chief Technology Officer?

“The chief information officer (CIO) is a job title for the board level head of information technology within an organization. The CIO typically reports to the chief executive officer.”

“A chief technology officer (CTO) is an executive position whose holder is focused on scientific and technical issues within an organization.”

“In some companies, the CTO is just like a CIO. In still others, the CIO reports to the CTO. And there are also CTOs who work in IT departments and report to the CIO. In such a situation where CTO reports to the CIO, the CTO often handles the most technical details of the IT products and their implementation. Despite the diversity of approaches to the CTO role, this IT department executive is increasingly becoming the organization’s senior technologist, responsible for overseeing current technology assets, and more important, for developing a technology vision for the business.” (Wikipedia)

For the purpose of this blog, I will use the terms synonymously.

In the federal government today, we do not actually have a federal CIO or CTO. The closest thing we do have to it is the Administrator for the Office of E-Government and Information Technology in the Office of Management and Budget (OMB). Within that office, we also have a chief architect.

MIT Technology Review, September/October 2008 has an interview by Kate Greene with Mitch Kapor, the founder of Lotus, founding chair of Mozilla, and a board member of Linden Research who advocates for a federal CTO.

Here’s why Kapor thinks we need a federal CTO:

The government needs cohesive technology practices and policies…tech is intertwined with virtually everything. You can’t talk about homeland security or education or energy without it being in large part a conversation about technology. The president will be well served if policy making is done in a more technologically sophisticated way.”

What are some policies the federal CTO would champion?

  • Ubiquitous and affordable broadband deployment
  • Tech policies that stimulate innovation in the economy are very important, because innovation is the engine of growth.”
  • Net neutrality is also a huge issue in ensuring the Internet isn’t controlled by the people who own the wires, because that us just going to impede innovation.”

While I believe that this is a good start, there are so many other areas that could benefit, such as—

  • Information sharing and data quality
  • Interoperability and component reuse
  • Standardization and simplification of our infrastructure
  • Beefing up our IT security
  • linking resources to results (i.e. driving performance outcomes and having our business and mission drive technology rather than doing technology for technology’s sake)
  • And of course, overall enterprise architecture planning and IT governance.

Overall, Kapor says “The advantage of a CTO is that there can be coordination. There’s a ton of work that goes on within different agencies: there needs to be someone to identify the best ways of doing things and some common practices.”

In the federal government, we do have the federal CIO Council to help coordinate and identify best practices, but the role that Kapor envisions is more of a visionary, leadership role that will truly drive the technology of our government and “lead by influence and not by command.”

As we enter the last few months before the presidential election of 2008, perhaps it is a good time to think not only about the next Commander In Chief, but also about the leadership role(s) of tomorrow—such as a federal CIO/CTO—that will be necessary for maintaining and solidifying our nation’s technological superiority for now and the future.


Share/Save/Bookmark

May 18, 2008

Competitive Sourcing and Enterprise Architecture

Our economy is heavily based on ensuring a competitive environment to drive innovation, cost-competition, and consumer value.
One of the reasons why mergers and acquisitions are reviewed so carefully is to ensure that they are not anti-competitive, which would result in antitrust action.
Competition law, known in the United States as "antitrust law," has three main elements:
  • Prohibiting agreements or practices that restrict free trading and competition between business entities. This includes in particular the repression of cartels.
  • Banning abusive behavior by a firm dominating a market, or anti-competitive practices that tend to lead to such a dominant position.…
  • Supervising the mergers and acquisitions of large corporations, including some joint ventures. Transactions that are considered to threaten the competitive process can be prohibited altogether, or approved subject to "remedies" such as an obligation to divest part of the merged business or to offer licenses or access to facilities to enable other businesses to continue competing. (Wikipedia)
Competition law has been extended to the federal workforce as follows:
The Office of Management and Budget Circular A-76 mandates that “To ensure that the American people receive maximum value for their tax dollars, commercial activities should be subject to the forces of competition.” This includes the following activities:
“a. Identify all activities performed by government personnel as either commercial or inherently governmental.
b. Perform inherently governmental activities with government personnel.
c. Use a streamlined or standard competition to determine if government personnel should perform a commercial activity.”
The concept of A-76 is that without federal workers having to compete for their positions against for example, the private sector, then there is no way to ensure value for the American taxpayer. Where is the incentive for the federal workforce to perform if when they aren’t performing competitively, and they are not threatened with replacement by a better, more effective and efficient provider?
Federal Times, 12 May 2008 reports that “all indications are that as the Bush administration winds down, so too has its most controversial government reform: competitive sourcing.”
“Many in Congress have aggressively challenged the practice as being unfair and demoralizing to federal employees and last year they passed myriad reforms and restrictions that are already being felt.”
While I agree that competitions drive efficiency in the marketplace, I think A-76 has missed the mark in terms of reforming federal human capital.
Why?
Competing federal workforce against private sector contractors on a cost basis does not necessarily ensure best value. From an enterprise architecture perspective, we are missing something crucial in A-76 and that is the human capital perspective.
The human capital perspective on EA is one that was initially proposed by John Zachman, the founder of EA, and I am a strong proponent of it. Essentially, it says that just like the other business and technology perspectives of the EA, human capital is a filter through which you must make organizational decisions.
The human capital perspective of the architecture provides us an opportunity to optimize federal workforce performance in the first place, before getting to an outsourcing decision point. Additionally, if you can’t effectively manage your own workforce, what makes you think you can better manage a contracted-out function? (In the same issue of Federal Times, there was an article about how the federal procurement officials are resigning in droves!)
What can we do to first improve performance results from the federal workforce (and I’m not saying that there is any problem to begin with)? The same as with any organization—provide strong leadership to them. Provide them with a bold vision. Hire the best and the brightest. Accelerate the hiring and clearance processes. Make clear their roles. Inspire them as President Kennedy did when he stated “Ask not what your country can do for you, ask what you can do for your country.” Challenge the workforce and empower them. Provide training, career growth, and financial and other incentives. With these, the federal workforce can truly be competitive and best value—if not all the time, then certainly much of the time.
The enterprise architecture way to do this is to first, baseline your current workforce. Then, look at best practices, benchmark, and set the targets for your people. And finally, develop a transition plan to move your workforce from the baseline to the target.
There is much more work to be done in this area, and obviously this is just a cursory overview or sketch of what the human capital perspective of EA would do. On a personal note, this is an area of great interest to me and I look forward to exploring it further.
Share/Save/Bookmark

March 26, 2008

The Enterprise is Unwieldy and Enterprise Architecture

Enterprise architecture develops the architecture for the enterprise, right? You’d think that’s a no-brainer. Except what happens when the enterprise is so large and complex that it defies the efforts to architect it?

Federal Computer Week (FCW), 24 March 2008 reports that Dennis Wisnosky, the chief architect and chief technical officer for DoD’s Business Mission Areas states that “the Department [of Defense (DoD)] is too large an organization to attempt to encompass all of its activities in a single enterprise architecture.”

Similarly, FCW, 26 November 2007, reported that “the size of the Navy Department and the diversity of its missions make it impossible to describe the service in a single integrated architecture.”

Dennis Wisnosky goes on to say that “DoD must achieve business transformation by breaking off manageable components of an enterprise architecture rather than trying to cover everything at once…[this is how we will achieve] the goal of an enterprise architecture [which] is to guide future acquisition and implementation.”

Richard Burk, former chief architect of the Federal EA (FEA) at OMB states: “there is no practical way to create a useful architecture for a large organization. You can get an overall picture of an agency using an [enterprise architecture] of everything the agency does, but when you get down to making it operational, at that point you really need to break it down into segments, into the lines of business.”

The Navy is using the concept of segment architecture, but is calling it “architecture federation.”

Michael Jacob, the Navy’s chief technology officer, “compared the architecture effort to the development of a city plan, in which multiple buildings are built separately, but to the same set of standards and inspection criteria.”

Mr. Jacob continues that “our effort will allow common core architecture elements [technical standards, mission areas, business processes, and data taxonomies] to be identified so that architecture efforts can be aligned to those same standards.”

I believe that every level of an organization, including the highest level, can have a architecture, no matter what the size, and that we should tailor that architecture to the scope of the organization involved. So for an organization the mega-size of DoD, you would have very little detail in at the highest level, EA (like the FEA Practice Guidance demonstrates), but that the detail would build as you decompose to subsequent layers.

For any organization, no matter its size, every level of the architecture is important.

Within the enterprise architecture itself we need multiple views of detail. For example, from an executive view, we want and need to be able to roll up organizational information into summary “profiles” that executives can quickly digest and use to hit core decision points. At the same, time, from a mid-level manager or analyst view, we want and need to be able to drill down on information—to decompose it into models and inventory views--so that we can analyze it and get the details we need to make a rational decision.

Similarly, within the overall architecture, we need the various views of enterprise, segment, and solutions architecture. The enterprise view is looking at strategic outcomes for the overall enterprise; the segment view decomposes this into actionable architectures for the lines of business; and the solutions architecture “brings it all home” and operationalizes the architectures into actual solutions.

Just like with the profiles, models, and inventories of enterprise architecture where we can roll-up or down, the key with these various architectural levels is that there is line-of-sight from the enterprise to the segment and to the solution. The lower levels must align to and comply with the levels above. This is how we achieve integration, interoperability, standardization, and modernization.


Share/Save/Bookmark

September 10, 2007

Getting People to Use Enterprise Architecture

There is a terrific white paper from the National Institute of Health (NIH) called Enterprise Architecture: Engaging and Empowering People while Creating Opportunity for Change.

NIH conducted a qualitative research study involving 15 users to understand how user behave and work in order to identify opportunities to foster adoption of EA.

First, NIH identified a clear mandate to not only develop and maintain EA, but for its end use:

Enterprise Architecture (EA) is a critical part of IT strategy in any organization. However, just defining enterprise architecture doesn’t bring its true value of efficiency to the organization nor support for the organization’s strategic objectives. In the EA Assessment Framework 2.0 published by the Office of Management and Budget (OMB) in December 2005, three capability areas, Completion, Use, and Results are defined as primary objectives of every government agency’s EA program. It is clear that EA is not just an assignment for CIOs to document architecture standards for the agency—for the future value to be realized, it must be used to achieve results.”

Second, NIH identified 3 user segments that are each looking toward the architecture for satisfying different needs. (While the study views all three segments as belonging to EA, I believe that only the first is EA, while the other two are segment and solution architecture.)

  • Trend Finders—want to know “where we are going?” They are interested in understanding the current and future business and IT landscape. (I believe this equates to enterprise architecture and its focus on developing the as-is, to-be, and transition plan.)
  • Fit Seekers—want to know “Does it fit my projects?” They want to find a solution for the project. (I believe this equates to segment architecture and its focus on developing solutions at the line of business (LOB) level.)
  • Fixer-Doers—want to know “How to make it work?” They want to build, maintain, or support a project. (I believe this equates to solutions architecture and its focus on developing technical project solutions for the end-user.)

While the study posits that user segments are not mutually exclusive and that users can actually evolve from one segment to another (and of course this is possible in some cases), I believe that generally speaking the segments do represent unique architecture perspectives in the organizations (enterprise, segment, and solutions architectures as defined in the Federal Enterprise Architecture Practice Guidance, December 2006).

In summary, architecture users are looking to understand the big picture (the EA and IT strategic plan), justify decisions (develop segment architectures that are ‘justified’ by aligning to and complying with the overall EA), and make it work (develop solutions architecture using technical details from the enterprise and segment architectures).

User-centric EA can satisfy the various segment needs by following the opportunities identified in the study to improve EA use. These are as follows (modified to more accurately represent what I believe is their correct application to users.)

For trend seekers/EA:

  • Show the big picture—high-level, non-technical information about the EA (this equates to EA profiles) and the direction of overall business and IT initiatives (this is the business, EA, and IT strategic plans)
  • Provide access to the source—ways to find more information and points of contact

For fit-seekers/segment solutions:

  • Lead to the right information—clear guidance through understandable nomenclature and information structure
  • Provide proof—through IT investment Review Board and EA reviews that include findings and recommendations.

For fixer-doers/solutions architecture:

  • Give specifics for immediate help—through more detailed EA models and inventories as well as SDLC job aids.

For all:

  • Share and enhance—capture performance metrics on EA program and products, especially use of EA information and governance services.

At the end of the day, EA needs to fulfill user’s requirements and empower them to leverage use of the information and services.
Share/Save/Bookmark