All modern large-scale organizations depend on information technology to cope with their architecture data needs. However, information systems have to function within the larger business goals and strategies of the organization. Information technology systems and business enterprise have to run parallel with one another, while complementing each other. Enterprise architecture and strategic planning ensures that information systems do not operate in a vacuum.
RiVidium has been designing architecture for the enterprise for over fifteen years in the federal and private sectors. Our enterprise architecture approach leverages an organization’s operational processes, information processes, and personnel and other organizational subunits in order to align with the organization's core goals and strategies. Among other things, this allows the organization to encompass business architecture as well as information technology architecture.
RiVidium’s enterprise architecture consulting services lets the client draw in from an experienced pool of knowledge and services to optimize their business and IT strategies. We help our clients with all facets of architecture and we are the right team to provide a roadmap whereby both business and IT can fuel each other's strategies.
While enterprise architecture (EA) defines what needs to be done, planning defines when Enterprise Architecture framework will be implemented. Enterprise architecture planning is the process of defining architecture for the use of information in support of the business and the plan for implementing this architectural design. RiVidium can assist organizations with multiple frameworks, as we are experts in:
- Department of Defense Architecture Framework (DODAF)
- The Open Group Architecture Framework (TOGAF)
- Federal Enterprise Architecture (FEA)
To learn more about our EA services click the architecture tabs above.
The Department of Defense Architecture Framework (DoDAF), Version 2.0 is the overarching, comprehensive framework and conceptual model enabling the development of architectures to facilitate the ability of Department of Defense (DoD) managers at all levels to make key decisions more effectively through organized information sharing across the Department, Joint Capability Areas (JCAs), Mission, Component, and Program boundaries. The DoDAF serves as one of the principal pillars supporting the DoD Chief Information Officer (CIO) in his responsibilities for development and maintenance of architectures required under the Clinger-Cohen Act. DoDAF is prescribed for the use and development of Architectural Descriptions in the Department. It also provides extensive guidance on the development of architectures supporting the adoption and execution of Net-centric services within the Department.
RiVidium’s architects use DoDAF in many of their engagements and in fact, RiVidium’s EA2F is one of the analytical tools reviewed by DOD for integration with DoDAF 2.0. Our consultants enable architectural content that is "Fit-for-Purpose" as an architectural description consistent with specific project or mission objectives. We also take advantage of the key DoDAF 2.0 specification underpinnings:
- DoDAF Meta Model (DM2)
- Physical Exchange Specification (PES)
- International Defence Enterprise Architecture Specification (IDEAS)
DM2
The purposes of the DM2 are:
- Establish and define the constrained vocabulary for description and discourse about DoDAF models (formerly “products”) and their usage in the 6 core processes
- Specify the semantics and format for federated EA data exchange between:architecture development and analysis tools and architecture databases across the DoD Enterprise Architecture (EA) Community of Interest (COI) and with other authoritative data sources
- Support discovery and understandability of EA data:
- Discovery of EA data using DM2 categories of information
- Understandability of EA data using DM2’s precise semantics augmented with linguistic traceability (aliases)
- Provide a basis for semantic precision in architectural descriptions in order to support heterogeneous architectural description integration and analysis that further supports core process decision making.
The DM2 defines architectural data elements and enables the integration and federation of Architectural Descriptions. It establishes a basis for semantic (i.e., understanding) consistency within and across Architectural Descriptions. In this manner, the DM2 supports the exchange and reuse of architectural information among JCAs, Components, and Federal and Coalition partners, thus facilitating the understanding and implementation of interoperability of processes and systems. As the DM2 matures to meet the ongoing data requirements of process owners, decision makers, architects, and new technologies, it will lead to a resource that more completely supports the requirements for architectural data, published in a consistently understandable way, and will enable greater ease for discovering, sharing, and reusing architectural data across organizational boundaries.
PES
When exchanging architectural data, the PES is the specification for the exchange. The PES provides an efficient and standard means of ensuring that data sharing can occur in a toolset-agnostic, methodology-agnostic environment. Use of the PES by architects to document architectural data and information in tools, through spreadsheets, or other means, and deposit that data and organized information into federated repositories is facilitated by the common understanding underlying the use of the PES.
The DM2 PES XML schema (XSD) provides a neutral format for data exchange between EA data and data sources including:
- EA databases.
- DoD Authoritative Source Databases (e.g., DoD Information Technology Portfolio Repository [DITPR]).
- Unified Profile for DoDAF and Ministry of Defence Architecture Framework (MODAF) (UPDM) and SysML-based Unified Markup Language (UML) Tools.
- Other Information Technology (IT) and enterprise architecture Tools.
- Modeling and Simulation Tools that are used in EA assessments, e.g., AoA’s.
- Reporting Tools, e.g., for Chairman of the Joint Chief of Staff Instruction (CJCSI) or Department of Defense Instruction (DoDI) submission.
- Systems Engineering Tools.
- Other Federal agencies (e.g., Department of Homeland Security (DHS), Department of Justice (DoJ).
- Coalition partners and North Atlantic Treaty Organization (NATO).
- Other organizations with which DoD exchanges Enterprise Architecture (EA) data (e.g., industry, States, National Government Organizations [NGO’s]).
This role is illustrated in the figure below.
IDEAS
The DM2 is founded upon the International Defence Enterprise Architecture Specification (IDEAS); this is a formal ontology foundation developed by the defense departments and ministries of the United States, United Kingdom, Canada, Australia, and Sweden in coordination with the North Atlantic Treaty Organization (NATO). All DoDAF concepts and concept relationships inherit several rigorously defined mathematical properties from the IDEAS Foundation. A view of the upper levels of the IDEAS Foundation is shown in the figure below.
TOGAF defines "enterprise" as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.
The term "enterprise" in the context of "enterprise architecture" can be used to denote both an entire enterprise - encompassing all of its information and technology services, processes, and infrastructure - and a specific domain within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups within the enterprise.
The business operating model concept is useful in determining the nature and scope of the enterprise architecture within an organization. Large corporations and government agencies may comprise multiple enterprises, and may develop and maintain a number of independent enterprise architectures to address each one. However, there are often many common denominators between the information systems in each enterprise, and there is usually great potential for gain in the use of a common architecture framework. For example, a common framework can provide a basis for the development of an Architecture Repository for the integration and re-use of models, designs, and baseline data.
There are seven parts to the TOGAF
- Introduction: This part provides a high-level introduction to the key concepts of enterprise architecture and, in particular, the TOGAF approach. It contains the definitions of terms used throughout TOGAF, as well as release notes detailing the changes between this revised version and the previous version of TOGAF.
- Architecture Development Method: This part is the core element of TOGAF. It describes the TOGAF Architecture Development Method (ADM), a step-by-step approach to developing an enterprise architecture.
- ADM Guidelines and Techniques: This part contains a collection of guidelines and techniques available for use in applying TOGAF and the TOGAF ADM.
- Architecture Content Framework: This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts; the use of re-usable architecture building blocks; and an overview of typical architecture deliverables.
- Enterprise Continuum & Tools: This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise.
- TOGAF Reference Models: This part provides a selection of architectural reference models, which includes the TOGAF Foundation Architecture and the Integrated Information Infrastructure Reference Model (III-RM).
- Architecture Capability Framework: This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise.
The intention of dividing the TOGAF specification into these independent parts is to allow for different areas of specialization to be considered in detail and potentially addressed in isolation. Although all parts work together as a whole, it is also feasible to select particular parts for adoption while excluding others.
In September 1999, the Federal CIO Council published the "Federal Enterprise Architecture Framework" (FEAF) Version 1.1, the platform for developing an Enterprise Architecture (EA) within any Federal Agency for a system that transcends multiple inter-agency boundaries. It builds on common business practices and designs that bridge cross-organizational boundaries, most notable of these the NIST Enterprise Architecture Model. The FEAF provides an enduring standard for developing and documenting architecture descriptions of high-priority areas. It provides guidance in describing architectures for multi-organizational functional segments of the Federal Government.
These federal architectural segments collectively constitute the federal enterprise architecture. In 2001, the Federal Architecture Working Group (FAWG) was sponsoring the development of Enterprise Architecture products for trade and Federal grant architecture segments. The method is a prescribed way of approaching a particular problem. The FEA is partitioned into performance, business, data, services, and technology architectures.
Performance
The PRM is a standardized framework to measure the performance of major IT investments and their contribution to program performance. The PRM has three main purposes:
- Help produce enhanced performance information to improve strategic and daily decision-making;
- Improve the alignment — and better articulate the contribution of — inputs to outputs and outcomes, thereby creating a clear “line of sight” to desired results; and
- Identify performance improvement opportunities that span traditional organizational structures and boundaries
The PRM uses a number of existing approaches to performance measurement, including the Balanced Scorecard, Baldrige Criteria, value measuring methodology, program logic models, the value chain, and the Theory of Constraints. In addition, the PRM was informed by what agencies are currently measuring through PART assessments, GPRA, enterprise architecture, and Capital Planning and Investment Control.
Business
The "FEA business reference model" is a function-driven framework for describing the business operations of the Federal Government independent of the agencies that perform them. This business reference model provides an organized, hierarchical construct for describing the day-to-day business operations of the Federal government using a functionally driven approach. The BRM is the first layer of the Federal Enterprise Architecture and it is the main viewpoint for the analysis of data, service components and technology.
The BRM is broken down into four areas:
- Services For Citizens
- Mode of Delivery
- Support Delivery of Services
- Management of Government Resources
The Business Reference Model provides a framework that facilitates a functional (as opposed to organizational) view of the federal government’s LoBs, including its internal operations and its services for the citizens, independent of the agencies, bureaus and offices that perform them.
Data
The Data Reference Model (DRM) describes, at an aggregate level, the data and information that support government program and business line operations. This model enables agencies to describe the types of interaction and exchanges that occur between the Federal Government and citizens. The DRM categorizes government information into greater levels of detail. It also establishes a classification for Federal data and identifies duplicative data resources. A common data model will streamline information exchange processes within the Federal government, as well as between government and external stakeholders.
Services
The Service Component Reference Model (SRM) is a business and performance-driven functional framework that classifies Service Components with respect to how they support business and/or performance objectives. The SRM is intended for use in supporting the discovery of government-wide business and application Service Components in IT investments and assets. The SRM is structured across horizontal and vertical service domains that, independent of the business functions, can provide a leverage-able foundation to support the reuse of applications, application capabilities, components, and business services.
Technology
The TRM is a component-driven, technical framework categorizing the standards and technologies to support and enable the delivery of Service Components and capabilities. It also unifies existing agency TRMs and E-Gov guidance by providing a foundation to advance the reuse and standardization of technology and Service Components from a government-wide perspective.