As a Federal contractor one of the biggest issues we face is access to request for proposals and valid opportunities. In the past this has been dependent upon relationships and subscriptions to services such as Input. A new web 2.0 service called the RFP database promises to create transparency and openeness during the procurement process. check it out.
http://www.rfpdb.com/
Going to restart the blog and really focus on a couple of areas. First area to focus on is social networking particularly in the context of enterprise architecture, improving business processes, and making information technology investment decisions. The second area is use of social networking to help us as taxpayers keep our political leadership accountable and see if the money we are spending is put to good use.
A key element to any enterprise architecture is the adoption of an operational based reference model. Many enterprise architectures utilize business, service, data, performance, and technical reference models to construct their enterprise architecture. These reference models provide the context by which to describe the various elements of the enterprise in a common way. While these reference models provide a good construct they are often not specific enough and do not provide users with a true enterprise operational picture. In our experience we have found that users do not receive an operational picture because the architecture tends to be esoteric and represents conceptual business functions, services, data, technologies, and performance measures. While an esoteric architecture can help to understand the enterprise’s big picture it does not help decision makers to make specific tactical decisions about how and what to change within the architecture. To facilitate decision maker’s ability to make tactical decisions we recommend developing an operational overlay for any enterprise architecture. The operational overlay establishes a set of criteria by which elements of the architecture can be described in a clear operational perspective. To create the operational perspective requires the architect to specifically describe the inputs, outputs, and results of each element of the architecture. We have found that clearly articulating these specifics in context of each element of the architecture enables decision makers to not only see the enterprise view but to understand how it is used.
Associations or relationships identified between the architectural layers and levels of the EA are the key to understanding redundancies or inadequacies within an organization and assist in understanding ways to unify the business functions and information technology resources. We incorporate an analytical approach to compare, evaluate, and analyze the relationships between all layers of an EA including:
- FEA reference models
- Stakeholders
- Mission, Vision, goals
- Business architecture metadata
- Data Architecture metadata
- Application Architecture Metadata
- Technology Architecture Metadata
The analysis presents a high-level, concise picture of what the metadata in the architecture represents. The high-level representation is ideal for senior level executives who need to make funding decisions or modernize the enterprise. For example, the following scenario demonstrates systems with a high-maintenance cost and a low number of users may need to be retired. Additional analysis may indicate the system may be obsolete and may need to be retired. As a result, our EA Approach can be used to determine:
- Duplication of effort
- Disparate and redundant processes
- Systems that impede information sharing among programs (ultimately resulting in untimely or inadequate service)
- Redundant IT support
- Overlap in other support functions
- If the business case for each IT investment demonstrates the relationship between the investment and the business, data, application, and technology dimensions of the EA.
Our last entry focused on how we define enterprise architecture and our approach to governance. This week we are going to start a series on the application of enterprise architecture. Applying or using an enterprise architecture is often the step that business people and architects never get to. Often time an architecture project becomes so engrained in the development of the architecture that they lose sight of the forest through the trees. Our first discussion (today’s blog) will describe our approach for developing problem-based enterprise architectures. Upcoming issues of the blog will discuss how enterprise architecture should be utilized to support strategic planning and portfolio management
Figure 1 from Chris Barlow’s three stepping stones is probably the best representation of our view towards enterprise architecture and how it can play a critical role in transforming organizations.
We have found that enterprise architecture delivers the greatest value when it is used as a tool to facilitate the merger of business and information technology by solving real business problems. Too often enterprise architecture is a documentation effort that is not focused on the needs and issues of the business line it is intended to support. Without a business line there is no need for information technology, let alone enterprise architecture.
Solving real business problems should be the goal of any enterprise architecture project. We have seen positive results from taking the time up-front in an enterprise architecture engagement to conduct an outreach effort with key stakeholders, leadership, employees, and customers of the organization. This outreach is intended to be bidirectional. We are making stakeholders aware of the enterprise architecture initiative and its associated outcomes. Stakeholders respond to our directed questions to help identify their issues and needs. This information should be well documented so that it can be referenced when prioritizing the issues and needs. The prioritization is critical to the success of an enterprise architecture project and is a differentiator between our approach and a typical approach to enterprise architecture. Rather than wandering down the path of dividing up areas to be modeled amongst the team and sending them on their way, we focus on the highest priority issues and needs and develop enterprise architecture products to address them. This is an iterative approach with the intention of revisiting products developed as additional issues and needs are addressed. While this may be perceived as some degree of potential re-work; the buy-in gained from focusing on key issues and needs is well worth it. As the issues and needs are addressed the merger between business and information technology begins to take shape and stakeholders begin to see the value of enterprise architecture and look to it as critical tool to solve real problems rather than something that have to do to meet mandated requirements. In our next entry in this series we will focus on how to identify issues/needs and how to engage the right stakeholder support.
Our Enterprise Management Consulting Group recognizes that managers need more detail about their operations to demonstrate the appropriate allocation of resources and to identify where additional resources are needed. Our EA Framework utilizes an adaptive enterprise architecture approach that effectively supports the business of government, enables information sharing across traditional barriers, enhances government’s ability to deliver effective and timely services, and supports agencies in their efforts to improve government functions and services. Adaptive enterprise architecture increases the government’s ability to deliver effective and timely services and to support agencies in their efforts to improve the overall functioning of government. Sharing information, maximizing resource investment, increasing technology reuse opportunities, and meeting the public’s ever-increasing expectations for electronic access to government information and services are major motivating factors driving the need for implementation of common enterprise architecture and standards.
Our approach to EA provides a holistic view that goes beyond enterprise-wide technical architecture models once believed to be solutions in the federal market place. We utilize EA as part of a suite of tools to enable rapid change in business processes and in the applications and infrastructure that enable them. In order to address complex government needs, we employ a performance enhancing suite of solutions that, in addition to EA, include:
Change Management—a key enabler to ensure the long term success of any process or technological improvement initiative. The Change Management process aligns the enterprise’s culture to the strategic business and IT goals.
The Enterprise Consulting (EC) practice provides strategic planning, performance management, and risk management services. We leverage our experience in enterprise architecture to provide our clients with value-added services. Our blog will provide new and innovative ideas to our customers, perspective customers, and other interested parties across government agencies. Today’s blog will focus on three areas; a brief introduction to our EC practice, a view on the state of enterprise architecture, and a discussion on upcoming blog topics.
The EC practice provides management consulting services to all levels of 
government agencies. We are a practice within the larger Strategic Enterprise Solutions, Inc. (SE) and can be found on the web at www.sesolutions.com. Our practice focuses on providing value-added services each and every-time we work with a client. Our core belief is a focus on impactful solutions that drive value for our customers. Our subject matter experts hit the ground running on day one and can be expected to immediately provide value.
One of our primary tools for helping our clients deliver results faster is the use of enterprise architecture (EA). We believe EA is a tool that can be used to improve an organization’s ability to achieve its mission. Although many in the EA community would agree with this statement, they quickly lose sight of the objective of architecture. Many practitioners of EA jump into creating models and views without having a clear understanding of the organizations mission and the problem (s) that EA is intended to help solve. Our operational approach to EA differs from the existing EA community in that it focuses on using EA as a tool to solve customer issues and satisfy their needs rather than using EA as a search and discovery effort of creating models and views that are “supposed” to provide answers at some point. We advocate that all practioners of EA begin to re-focus their efforts away from creating pure EA work products and focus on using EA as a tool to identify and solve client problems. We propose, for example, that instead of just creating a business architecture (i.e. set of business processes, functions, and activities across an organization) that an architect use the business architecture to help an client analyze their compliance with legislative, policy, and regulatory requirements. Clients find more value in a business architecture when it helps them make decisions and manage their business instead of just documenting the enterprise and hanging on the wall. In future episodes of this blog we will continue to explore how we believe EA used be used to help organizations identify and solve real problems.
Future episodes of this blog will focus on how to make an enterprise architecture operational, our experience with critical infrastructure protection, new approaches to strategic and performance planning, and our experience implementing portfolio management within the Department of Defense. Please feel free to leave us comments and ideas for future blog content.
Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!
You are currently browsing the archives for the Citizen Value category.
Business Architecture
