The Standards Viewpoint is responsible for answering several questions: “Which standards do we currently adopt or aspire to adopt?” “Which standards are changing or being superseded and when?” “Which standards are forecasted to be in widespread use and which standards are still trying to gain traction?” The answers to the first question can be documented in a standards forecast and the answers to the second two questions can be documented in a standards forecast. For larger organizations or enterprises with commercial interests in a standard or vested interests in proprietary products and services that either depend on a standard or standards or threaten to become a standardized commodity, these questions may need to be answered: “What are emerging standards?” “Which standards bodies are working on which standards that may have a direct impact on our business?” The answers to these questions can be documented in a standards profile.

The scope of standards spans not just the technology aspects but rather all the viewpoints of the enterprise. Operational standards may be conventions for codes and values that are agreed upon by an industry association or body. Three-letter codes for countries are established by the International Organization for Standardization (ISO). Domain-specific standards are established by bodies that govern the domain.

In the DoDAF, the Standards Viewpoint was originally intended to deal with technology standards. However, it can also be used to document business standards such as standard operating procedures, relevant laws and regulations, and security standards. The technology standards may be de jure standards developed and published by standards organizations such as the American National Standards Institute (ANSI), Institute of Electrical and Electronics Engineers (IEEE), ISO, and Object Management Group (OMG), or the technical standards may be proprietary offerings that have become de facto standards, such as Microsoft Windows. The Standards Viewpoint can also deal with enterprise-specific standards including such things as the standard technology configurations for workstations or servers.

The need for standards, especially technical standards, is driven by the need for interoperability. The world runs smoothly on standards. When you swipe a credit card inside the card reader on the gas pump, the use of a common standard guarantees that the card reader reads the magnetic stripe and retrieves the encoded information that was stored by your bank or credit card provider. When you slide the boarding pass issued by one airline into a card reader operated and used by another airline, your flight and booking information travels smoothly to the carrier and you are authenticated and welcomed into the aircraft.

The Standards Viewpoint (StdV) provides the minimal set of rules governing the arrangement, interaction, and interdependence of system or service parts or elements. The StdV provides the technical systems implementation guidelines upon which engineering specifications are based, common building blocks are established, and product lines are developed. It includes a collection of the technical standards and standards options that can be organized into profile(s) that govern systems and system or service elements in a given architectural description.

The Standards Viewpoint caters to the need of people responsible for interoperability, integration and federation-related activities and supports acquisition. For example, operational interoperability requires common semantic vocabularies between multiple performers. In an emergency response scenario, first responders use an abbreviated (terse) form of communication that is understood by everyone who is familiar with and using that standard. A standard used in the past are 10-codes by police and citizens band radio operators.

The lack of standards can result in significant breakdown of communications in an urgent operational scenario. In the tragedy at Charlottesville, Virginia, involving protest events in 2017, one of the failures of standards involved Charlottesville Police Department (CPD) and Virginia State Police (VSP) operating on separate communications channels. CPD zone commanders could not communicate with assigned VSP personnel via radio during the height of violence on July 8, 2017 [Hunton & Williams 2017].

We are all familiar with the effect of standards on interoperability. Major advances in widespread proliferation of computer communications began to occur after the majority of vendors adopted TCP/IP. The HTTP and XML standards are other examples of communications protocols that have been behind the explosive adoption of the World Wide Web. In the area of data standards, financial institutions have established interbank funds transfer standards to enable disparate banks to conduct financial transactions automatically through messaging.

The Standards Viewpoint provides the following:

• A plan to enhance interoperability by publishing enterprise-wide guidance that requires adherence to standards for items such as business processes; military operations; systems hardware and software components or interfaces; communication devices, protocols, and links; and materiel that is used by processes

• A documentation of the disparate standards currently in use with an intent of reducing variety and fostering more uniformity and consistency in the future

We draw the distinctions between standards profiles that describe the list of applicable standards and inventories of technology assets that record actual instances of technology use in the enterprise. The DoDAF Standards Viewpoint is geared toward a profile-based approach. The Defense Information Standards Registry records these profiles. Systems Viewpoint and Services Viewpoint views such as the SV-9: Systems Technology and Skills Forecast or the SvcV-9: Services Technology and Skills Forecast list actual technology instances that are used by systems or services and their projected lives and replacement strategies.

Views of the Standards Viewpoint

The Standards Viewpoint is supported by two views, both of which are based on the profile rather than actual instances of technology:

• StdV-1: Standards Profile Lists the various standards that are used by an enterprise. These standards relate not only to technology but also elements of the operations such as airport codes, aircraft types, and country codes and are used to promote interoperability across operations and systems.

• StdV-2: Standards Forecast Shows a predictive view of where the standards are going within the windows of the architecture time frame.

The StdV-1 and StdV-2 views must share the same classification scheme and standards coding scheme to enable traceability and for integration. The StdV-1 and StdV-2 are sometimes combined into a comprehensive standards reference that shows the current standards with the dates when they will no longer be accepted in new systems or services and when they must be removed from all operational systems and services. It also shows the future standards and the dates when they must be used in all new systems or services.

Standards Profile View

The StdV-1: Standards Profile records the current list of standards that are used within an enterprise organized by a normative classification scheme that is sometimes called the technical reference model (TRM), plus operational standards. The StdV-1 provides engineers with an opportunity to identify duplicative or overlapping standards and to identify opportunities for improvement by reducing the number of standards or justifying the need for multiple standards based on mission needs.

The importance of using the same classification scheme for standards across cooperating and collaborating enterprises is that they can lay their StdV-1 models side-by-side and make comparisons that find potential conflicts in their standards postures. Because of the sheer magnitude of the lists of standards that are applicable to an enterprise, a commonly understood and adopted classification scheme is necessary to make comparisons easy and to reduce errors.

Federal agencies must use the FEAF2 TRM (see Chapter 23) as the overarching technical standards categorization scheme. Individual agencies may develop their own standards profiles that extend the FEAF2 TRM and may also list agency standard technology configurations in addition to technology standards.

Department of Defense enterprises must use the Defense IT Standards Registry (DISR) provided by the DoD both for a standard classification scheme as well as the list of registered standards. In general, not all standards that are used by all DoD enterprises are available in the DISR—only those that are common to multiple enterprises.

There are other classification schemes for technology standardization. Standards bodies such as ANSI, IEEE, ISO, and International Civil Aviation Organization (ICAO) have also developed standards using committees and working groups that are laid out according to their own internal grouping schemes.

Standards Forecast View

The StdV-2: Standards Forecast view supports planner’s needs for developing roadmaps for future standards adoption and implementation. The StdV-2 collects projections of standards maturity over a time period to determine which standards will become obsolete, which standards will be supplemented with newer versions, and which new standards will emerge within the time frame of interest.

Standards Viewpoint Integrated Views

The Standards Viewpoint views tend to stand alone, more as guidance for the enterprise in the acquisition process and to promote interoperability as early as possible. However, the SV-9: Systems Technology and Skills Forecast and SvcV9: Services Technology and Skills Forecast, both must be consistent with the StdV-1: Standards Profile and StdV-2: Standards Forecast. Figure 19-1 provides the integrated view set for the Standards Viewpoint.

Figure 19-1   Integrated view set for the Standards Viewpoint

StdV-1: Standards Profile

Dictionary entries for each standard should include a brief outline of the features of the standard and should specify any options of the standard that are required.

Because the categorization scheme is used to group literally thousands of standards in large enterprises, the importance of standardizing the categorization scheme itself is considered a very important exercise in architecting the enterprise.

The Department of Defense maintains a standard technology classification using the DISR, which is intended to provide a common classification model for all defense enterprises. This means that DoD StdV-1s can be unified and aggregated at higher levels within DoD. The FEAF2 TRM provides a standard list of categories under which technology standards can be grouped. TOGAF also provides for a TRM that implementing organizations can use to categorize their technology standards. The technology architecture for an enterprise is one of the important TOGAF 9 components of architecture. The TOGAF distinguishes between technology standards such as POSIX or FIPS 127 Structured Query Language that are modeled in the technology standards catalog from the actual instances of technology such as an Oracle Database or a Microsoft Server, which are modeled inside the technology portfolio catalog.

The StdV-1 may also be tailored to show cross-reference to the architecture elements that use or reference a specific standard. The following example shows the issue date (year) of the standard as well as the status of the standard at the time the architecture was built.

Example: Passenger Identification StdV-1

In this example, we have invented a classification scheme for RMN Airport that has a progressive three-level structure: Service Area, Service, and Subservice. Standards are then categorized by this three-level classification scheme.

StdV-2: Standards Forecast

Dictionary entries for each standard should include a brief outline of the features of the standard and specify any options of the standard that should be required.

Example: Passenger Identification StdV-2

In this StdV-2 example, we depict a timeline of ten years with short-term, mid-term, and long-term forecasts for each standard of interest. The purpose of the StdV-2 is to assist in developing a standards roadmap for RMN Airport that will lay out a blueprint for architects that clearly shows some of the assumptions for standards evolution and will guide stakeholders in making acquisition-, design-, and development-related decisions.

Alternatives

The TOGAF and FEAF2 have alternative approaches to the DoDAF Standards Viewpoint.

TOGAF Technology Architecture

The TOGAF recommends the following type of artifacts to represent the technology architecture. Note that some of these artifacts are at a much lower level of abstraction and detail than those included in the DoDAF.

• Technology Standards Catalog   This catalog documents the agreed-upon standards for technology across the enterprise covering technologies and versions, the technology life cycles, and the refresh cycles for the technology. This catalog is an extended version of the StdV-1: Standards Profile view of the DoDAF.

• Technology Portfolio Catalog   This catalog identifies and lists all the technology in use across the enterprise, including hardware, infrastructure software, and application software. An agreed-upon technology portfolio supports life cycle management of technology products and versions and also forms the basis for definition of technology standards. It contains the following metamodel entities: Platform Service, Logical Technology Component, and Physical Technology Component. The Technology Portfolio Catalog is an instance catalog while the Technology Standards Catalog is a list of standards.

• Application/Technology Matrix   This artifact documents the mapping of applications to the technology platform.

• Environments and Locations Diagram   This artifact depicts the relationships between enterprise locations and the applications they host. It also identifies what technologies are used at which locations.

• Platform Decomposition Diagram   This artifact depicts the technology platform that supports the operations of the information systems architecture. A platform is associated with a stack—a set of interdependent technology items that collectively provide the platform’s capabilities.

• Processing Diagram   This artifact focuses on deployable units of code and how these are deployed on the processing platforms.

• Networked Computing/Hardware Diagram   This artifact depicts how logical application components are deployed in a distributed network computing environment.

• Communications Engineering Diagram   This artifact maps the logical interfaces between application components to the physical networks, boundaries, and communications infrastructure. It is similar to the SV-2: Systems Resource Flow Description or the SvcV-2: Services Resource Flow Description in the DoDAF.

FEAF2 Approach to Standards

The FEAF2 deals with standards both in the infrastructure subarchitecture domain and in the infrastructure reference model (IRM) as described in the following sections.

FEAF2 Infrastructure Subarchitecture Domain

The infrastructure subarchitecture domain within the FEAF2 contains the elements of information technology that support the execution of applications and services. However, the DoDAF Standards Viewpoint covers standards not only for technology but also for supporting operational activities. For example, the ICAO’s list of airport codes may be a relevant standard for RMN Airport, as does the specifications from the FAA for airport minimum functions or runway lengths and airport classification categories. The following artifacts are recommended for the infrastructure subarchitecture domain:

• Network Diagram (I-1)   Describes the means that implement the resource flows in an architecture. The DoDAF SV-2: Systems Resource Flow Description and SvcV-2: Services Resource Flow Description are equivalent views.

• Hosting Concept of Operations (I-2)   Presents the high-level functional architecture, organization, roles, responsibilities, processes, and metrics and strategic plan for hosting and use of hosting services.

• Technical Standards Profile (I-3)   Collects the various system standard rules that implement/constrain choices in the design and implementation of the architecture. This artifact is equivalent to the DoDAF StdV-1: Standards Profile.

• Technology Forecast (I-4)   The emerging technologies, software/hardware products, and skills that are expected to be available in a given set of time frames and that will affect future infrastructure development. This artifact is equivalent to the DoDAF SV-9: Systems Technology and Skills Forecast or the SvcV-9: Services Technology and Skills Forecast views.

• Cable Plant Diagram (I-5)   Diagrams the wires and connectors used to tie a network together. (Not included in DoDAF architectures.)

• Wireless Connectivity Diagram (I-6)   Diagrams a communications network that provides connectivity to wireless devices. (Not included in DoDAF architectures.)

• Rack Elevation Diagrams (I-7)   Two-dimensional elevations drawn to scale and show everything that needs to be placed in a certain area, which describe the organization of specific equipment on a rack. (Not included in DoDAF architectures.)

• Data Center/Server Room Diagram (I-8)   Diagrams the layout and contents of a data center or server room. (Not included in DoDAF architectures.)

• Wiring Closet Diagram (I-9)   Diagrams the layout and contents of a wiring closet. (Not included in DoDAF architectures.)

• Point of Presence Diagram (I-10)   Not described in FEAF2. A point of presence (PoP) is an artificial demarcation point or interface point between communicating entities. The PoP indicates where an external carrier such as a telecommunication company enters the locations of the enterprise such as a data center. An Internet point of presence typically houses servers, routers, network switches, multiplexers, and other network interface equipment. It is typically located in a data center. ISPs typically have multiple PoPs.

• Asset Inventory (I-11)   Lists infrastructure assets with details about each asset (installation date, original cost, condition, and so on). (Not included in DoDAF architectures.)

• Facility Blueprints (I-12)   Represents technical drawings of the facility. (Not included in DoDAF architectures.)

FEAF2 Infrastructure Reference Model

In the FEAF2, the IRM is the taxonomy-based reference model for categorizing IT infrastructure and the facilities and network that host the IT infrastructure. The IRM supports definition of infrastructure technology items and best-practice guidance to promote positive outcomes across technology implementations. The generic (underlying) platform consists of the hardware, software, and delivery platform upon which specific/customized capabilities (solutions, applications) may be deployed. In addition to providing a categorization schema for IT infrastructure assets, the IRM enables analysis of IT infrastructure assets at a department or an agency level as well as at a federal government level. In the federal context, the IRM is adopted and used to conduct government-wide analysis of IT infrastructure assets and to identify consolidation initiatives. In the department or agency context, the IRM is used to drive good IT infrastructure asset management practices such as identifying end-of-life assets before they affect the mission of an organization and to identify opportunities for sharing and consolidating infrastructure.

The IRM taxonomy is intended to provide a categorization scheme for physical IT assets, the operating systems and firmware that run them, and the locations or facilities that host the assets. The IRM is divided into three levels, as shown in Figure 19-2:

Figure 19-2   Infrastructure reference model (used with permission from TOGAF)

• Level 1, Domain   Consists of 3 entities, Platform, Network, and Facility, which are linked and related to each other to enable analysis of IT assets across the three dimensions.

• Level 2, Area   Consists of 13 total areas (such as Hardware) linked to the three domains in Level 1.

• Level 3, Category   Consists of 90 total categories (for example, Personal Computer – Laptop) linked to the 13 areas in Level 2.

Summary

The StdV-1: Standards Profile and StdV-2: Standards Forecast views are useful for baselining existing standards (profile) and planning future investments in products and service platforms with an understanding of where these are headed (forecast). Industry consulting organizations such as the Gartner Group or the Forrester Group, which are consultants for technology strategy, surveille technology trends and provide forecasts that drive entire segments of industry toward emerging standards. The StdV-1: Standards Profile is useful for looking at the enterprise’s current baseline of standards, determining whether a shift is necessary, and planning an orderly migration strategy toward contemporary or emerging standards (Standards Forecast). The migration path for an individual system may be represented using the SV-9: Systems Technology and Skills Forecast in the case of the DoDAF.

Questions

1. Why are standards important to the enterprise? Who is the audience for the Standards Viewpoint? Why?

2. Why are standards important across enterprises? Name some examples of scenarios where multiple enterprises are involved and where the lack of standards is a serious impediment to interoperability.

3. What is a technical reference model? Why is a common standards classification scheme important for various parts of the enterprise to interoperate?

4. What is a standards profile? How does your enterprise generate a standards profile? Does the enterprise standards profile match one of the reference models mentioned in this chapter—National Institute of Standards and Technology (NIST), the FEAF2 TRM, or the Defense Department’s DISR? Does your enterprise standardize the classification scheme and categories and standards specifications or does it categorize vendor platforms such as IBM DB2 or Oracle for RDBMS, IBM Web Server for web services, and so on? Why?

5. What is a standards forecast? How does your enterprise generate standards forecasts? For what time frames? How do the time frames in the StdV-2 tie in to/be consistent with other time frame models such as the SV-9: Systems Technology and Skills Forecast?

6. What is the relationship between the StdV-1: Standards Profile, the StdV-2: Standards Forecast, the SV-9: Systems Technology and Skills Forecast, and the SvcV-9: Services Technology and Skills Forecast views?

7. Contrast the FEAF2 infrastructure standards approach to the more general Standards Viewpoint of the DoDAF. How will you describe operational standards through the FEAF2 artifacts? Which artifacts?

8. Compare and contrast the TOGAF technical architecture artifacts against the FEAF2 artifacts.

9. Compare and contrast the TOGAF technical architecture artifacts against the DoDAF Standards Viewpoint views.

References

American National Standards Institute (ANSI). Home page. www.ansi.org/.

CIO Council. 2013. “Federal Enterprise Architecture Framework, Version 2.” https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/egov_docs/fea_v2.pdf.

Department of Defense. 2010. DoD Architecture Framework Version 2.02. http://dodcio.defense.gov/Library/DoD-Architecture-Framework/.

Department of Homeland Security, FEMA. “Plain Language Guide: Making the Transition from Ten Codes to Plain Language.” www.fema.gov/media-library/assets/documents/25461.

Fernandes, James. 2005. Academic Dictionary of Internet. Isha Books, p. 316.

Hunton & Williams. “Final Report: Independent Review of the 2017 Protest Events in Charlottesville, Virginia.” www.hunton.com/images/content/3/4/v2/34613/final-report-ada-compliant-ready.pdf, p.79.

Institute of Electrical and Electronics Engineers (IEEE). Home page. www.ieee.org.

International Organization for Standardization (ISO). Home page. www.iso.org/iso/home.html.

National Institute of Standards and Technology (NIST). Home page. www.nist.gov/index.html.

The Open Group. 2011. “Sample Catalogs, Matrices and Diagrams,” Version 3, TOGAF Enterprise Edition Version 9.1. Microsoft PowerPoint presentation. www.togaf.info/togaf9/togafSlides91/TOGAF-V91-Extra-Catalogs-Matrics-Diagrams-v3.pdf.