How to Initiate an Enterprise Architecture Effort in an Austere Environment

initiating enterprise architecture

Imagine yourself driving but not knowing where you are going, why you are going there, or how much it is going to cost. Taking a vacation in this manner may not result in the desired outcome. To ensure that your vacation is successful, many factors need to be considered first, such as desired goals and budget limits. Like planning a personal vacation, the federal government and Department of Defense (DoD) must strategically plan their business services, operations, and information systems to achieve their end goals.


Enterprise architecture (EA) is currently mandated for federal government organizations. In 1996, the ClingerCohen Act reformed the federal government’s approach to information systems acquisition. The intention of this act was to assist in controlling risks, minimizing costs, and improving the performance of federal enterprises. To build upon the Clinger-Cohen Act, the DoD adopted a similar approach in 2003 known as the Joint Capabilities Integration and Development System (JCIDS). Both approaches require the creation of disciplined architecture products to objectively provide key and accurate information for the architecture decision-making and assessment process.

The true intention of these mandates is often lost because federal organizations will sometimes focus on simple mandate compliance rather than the actual goals of the Clinger-Cohen Act and the JCIDS process. For example, EA products are often created to pass reviews, but there is no intent to use them as part of the decision-making process. The EA products should instead be tightly integrated into the strategic planning and acquisition planning activities to be effective and truly meet the objectives of the federal mandates.


Because EA products are mandated and may utilize an unfamiliar approach, many organizations become overwhelmed when deciding how to begin their efforts. Enterprises within federal government and DoD agencies are often very complex and usually quite large, as are their private sector counterparts. Tackling a structured, objective enterprise assessment with such complexity and magnitude can be quite intimidating. To add to the strategic planning and EA challenges, organizations often have limited funding to perform the full scope of EA analysis. With the intimidating size of the enterprise architectures and the challenge of limited resources creating an austere environment, organizations often find themselves quite overwhelmed and struggle with how to begin EA efforts.


To overcome an architecture’s complexity and potentially limited resources, MorganFranklin recommends several key startup activities that have proven to be essential to effective EA efforts. In the vacation analogy, in order to not drive aimlessly, the destination, arrival method, and many other factors need to be determined before traveling. In our past experience, there have been organizations that spend large amounts of money to ramp up architecture teams without strongly defining the desired goals and visions of their enterprises. To ensure architecture assessment consistency and overall success, we recommend three fundamental steps to successfully begin an EA endeavor:

1.  Establish and prioritize strategic business goals. What does the organization want to be as it evolves? What business services is it providing to the rest of the community and who are its users? What discriminators or strengths does it want to build or maintain? What overarching policies is it going to embrace?

2. Create high-level capability and concept views for common vision. Once the goals have been established, how will they be achieved? What is the common vision for the concept of operations? What options are there for new transformational concepts of operations and which concepts currently work successfully?

3. Capture a catalog of “as-is” processes, systems, applications, infrastructure, services, and standards. Too often the current systems, applications, and infrastructure are completely ignored. It is essential to have a validated, up-to-date catalog of all resources that currently support the organization’s mission set.


In an ideal, theoretical world, an organization can wait until the entire “to-be” enterprise architecture has been described and vetted before analyzing and describing a strategic plan forward. However, if organizations were to wait, they would lose valuable architecture assessments that could be completed in the meantime. Organizations can quickly start realizing value from architecture engineering efforts if they are focused on narrowly defined and near-term solutions. While the key startup activities should continue to be carried out by a set of undistracted team members, experience has shown that organizations can have small-scale architecture development successes. The practical and tangible results can also provide the necessary traction and advocacy often needed to continue support and funding for overarching EA efforts.

What are some of these focused architecture analyses? Our experience has shown that an organization can focus on the top-priority systems being acquired and transitioned within the next year. These architecture efforts can make certain that the systems are defined well enough to ensure integration into the greater enterprise. Another focused effort can involve saving operations and maintenance (O&M) costs by analyzing legacy systems and determining what type of redundancies exist. Additionally, a federal organization can explore what potential solutions could be used by obtaining the lessons learned from other organizations’ successes and failures. While the vision is being set, the organization can begin to adopt successful and applicable common practices and technologies.


Would you delay your vacation if you owned a Corolla but always dreamed of traveling in a Cadillac? If you did not have the money to buy a new vehicle, you would most likely still take your vacation. For architecture product creation, organizations do not need to wait until they bring in a robust architecture tool before capturing the necessary information. Architecture analysis can occur without a formal architecture tool. The effort can begin by simply using standard desktop commercial off-the-shelf (COTS) products, such as Microsoft Word, Excel, Visio, and PowerPoint. Basic architectural analysis and data collection are essential in strategic and acquisition planning and can successfully occur without a robust tool.

It is important to keep in mind that EA analysis is an ongoing, long-term endeavor. While the architectural assessments should continue despite tool constraints, bringing in a more formal EA tool should be considered for the long-term solution. EA tools are built to support information sharing and expedite architecture product creation. In the long run, a more robust tool will save time and improve collaboration among a large group of architects.


To achieve the vacation of your dreams, capturing the desired goals, objectives, budget, and timeline is essential to successfully arriving at your ultimate destination. EA should be treated no differently. While the ultimate destination is being determined, one can take mini-trips or complete short-term architecture projects that will realize immediate value and potentially provide insight into the end goal. Lastly, the type of transportation, or architecture tool, should not be the primary focus or a limiting factor at the start of an EA effort. Following these guidelines will help any organization get closer to achieving its vision.

About Ruth Burgess and John Forte 1 Article
Ruth Burgess serves as program manager for IT strategic planning projects at MorganFranklin. She possesses more than fifteen years of experience specializing in systems integration and engineering, with specific experience leading teams developing comprehensive and practical architecture products for several critical government enterprises. John Forte served as technical director at MorganFranklin, specializing in enterprise architecture, information systems modernization, and technology insertion. He currently serves as program manager for national command programs at the Johns Hopkins University Applied Physics Laboratory.