Technical Architecture Background

This Guide describes a customizable process that can be used to guide the evolution of the technology in use within the HS Agency. Principles and concepts upon which that process is based are described in this background material. This builds upon the key principles that apply across the IT Planning and Management Guides.

 

Underlying conceptual models

Architectural elements

Solution delivery life-cycle using an HS Agency-wide technical architecture

The three primary environments of interest

The role of the agency technology architect

The role of standards in the architecture process

The role of an HS Agency-wide Technical Reference Model

Documenting the HS Agency technical architecture

Controlling the use and interpretation of the A-TARS

Underlying conceptual models

Building Architecture

The architectural approach adopted for this guide is influenced by concepts associated with the construction industry. In that context, highly trained and skilled individuals, the architects and engineering specialists, apply their creative and engineering talents to design buildings and oversee the entire construction life cycle. In some cases, the architect's responsibility may extend beyond initial occupancy, such as continual responsibility for public buildings, like the U.S. Capitol (see AOC 2001).

Architects ensure that the building they design meets its intended use and satisfies all applicable building codes governing the building and construction processes. This includes life-cycle concerns, such as development or lifetime maintenance costs; construction timeframes to meet occupancy needs; and environmental factors, such as snowfall or hurricane threats. An understanding of the environment is key to producing aesthetically pleasing, serviceable, and long-lived buildings. A building should maintain its essential character, yet adapt over time to handle emerging needs. It is the architect's responsibility to understand how the building will be used and provide for a range of uses-the building's function. This includes parameters on the construction process.

The architect translates needs into a design description. Others use that description to create and maintain the building. These descriptions take the form of building plans (or blueprints) where the overall form of the building is accurately portrayed. These descriptions show the key entities of a building, such as walls, windows, beams, joists, columns, and stairs. Composite relationships between entities are described in different interrelated views, such as framing, electrical, mechanical, grading, roofing, or foundation. These different views are organized to suit different stakeholder needs. Stakeholders vary and may include the customer-developer, occupant, county inspector, lender, and the construction trades, such as plumbers, framing carpenters, concrete, electrical, painter, roofing system fabricator, among many others.

When a detailed design decision is important to a stakeholder, then a detailed out-of-context description is developed and organized within the plans. An example of such detail may be a handrail that gives a home the essential character required for a contemporary style, a paint color for a traditional early American style, or a particular make of appliance for a gourmet kitchen. When specific processes or guidelines are to be followed, those are also called out in the architect's instructions, such as erecting barriers to control soil erosion during excavation.

The design reflected in the architect's plans is prepared to satisfy best commercial practices and to adhere to local and other building codes. The design process embraces conventions so that available basic building blocks can be used to keep costs reasonable (e.g., standard counter heights, door sizes, ceiling heights, or bathroom fixtures). The contractors and construction team have some flexibility to apply their judgment and expertise to create the building, guided by the decisions reflected in the building plans. Flexibility is necessary to allow for cost and time efficiencies, such as leveraging supplier discounts and availability of materials.

The architect is involved throughout the construction process to advise and oversee, ensuring that the plans are appropriately interpreted and the envisioned building is realized. The plans therefore guide, they are descriptive rather than prescriptive.

Summarized, the essential characteristics of architecture are:

• It depends on a highly creative and skilled team of individuals with technical and management knowledge. Individuals may specialize in different parts of the building or design process.

• It is life-cycle-oriented. Architects solicit the needs of all stakeholders and are involved in the entire design, construction, and optionally, the maintenance of the building.

• It requires the architects to understand the larger environments in which the building will be created and used, so its form follows its function.

• The architects consider both the building they are designing and the processes to produce and maintain it.

• The plans assume a set of building conventions and standards, commercially available parts are used, and custom parts are designed only when needed.

• The design is described in construction plans that are meant to be directly used by other stakeholders.

• The construction plans describe the entities of interest in many viewpoints, stressing one aspect over another, yet all views are interrelated.

• The descriptions in the plans are not of uniform detail, some are more detailed than others to ensure the design element reflects the architect's intentions.

• The plans do not over constrain; some flexibility is built in for making decisions to reduce cost, schedule, and other factors.

• Inspectors can check the resultant building against the plans and verify that it is a reasonable production.

Top

Technical Architecture

Architecture within the context of this Guide also implies a creative and disciplined process of design and technical management, generating a set of specifications to guide construction and maintenance of automated systems. The scope for the technical architecture is the HS Agency, which consists of a set of interoperating automated information systems. The technical architecture entails describing the services that collaborating entities provide one another across interfaces (see figure). For the HS Agency's technology, this consists of the following:

• The technology-related entities that are defined or managed at the HS Agency level, such as computers, applications, data, networking, business policies, and people
• The interfaces between these entities
• The services provided by the entities across the interfaces

Although the model in the entity figure appears simplistic, it captures the essence of good IT architecture. The key is the appropriate identification and definition of the entities that are of concern to the HS Agency; not every detail can be specified and controlled. The architects focus on identifying and characterizing the entities and their essential characteristics, allocating functionality and encapsulating essential behaviors behind interfaces. This encapsulation and the relationships between entities are key to establishing a robust structure that can adapt to changes, either anticipated or unforeseen.

There are many types of technology-related entities that an HS Agency may wish to define and manage. The elaborated figure shows a logical partitioning of the entity and interface types, adapted from ( Shultz 1995).

Types of technology-related entities are:

• Application Software. These are computer programs that provide services to a real-world process, such as an HS program, operations, or technology development process. Applications are assumed to be distributed across many computer processing platforms. Application software may be either custom-developed, configured from a tailorable set of preexisting functionality, or purchased and used as is. Data associated with the application, such as initialization parameters, is assumed to be part of the application software entity.

• Application Platform. This is defined as the computer processing resources upon which the applications are deployed and used. The platform provides common services to the (distributed) applications. Platforms may be specialized for specific roles, such as user interaction, application logic execution, or data access and storage.

• People/Users. These are the human or automated external end users that interact with the applications. Users access the application-provided services within a real-world setting, such as a county facility (e.g., office access to an intranet) or at home (e.g., dial-up access through an ISP). The setting defines the usage environment or context in which the application is accessed and used.

• External Data Storage Media. These media include any technology to persist data, such as memory cards, magnetic disks, tape, DVDs, or paper reports. The media format, reliability, and size (or change in size) may be of concern to the architect.

• Communication Network. The network is the composition of communications media and services generally under the control of a single provider organization. The network transfers information between computer platforms and/or information appliances and includes technology such as LAN, wireless, infrared, and satellite. The communications infrastructure is a set of networks viewed as a single entity by the network user.

• Information Appliances. The underlying software in these devices is not directly visible or configurable by the end user. This includes a fast-growing list of items such as Web-enabled cell phones, personal digital assistants, electronic books, and networked data storage devices.

Interface types include the following:

• Application-to-Application. This is an interface through which an application program may use the capabilities exposed by another application (e.g., accessing a spreadsheet application's objects from a custom application written in a scripting language).

• Application Program. Programmers build applications that access common, underlying services that are not application specific through this type of interface. Each type of platform may have different application-provided services and interfaces.

• Human Technology. This is the interface by which external entities (e.g., people) interact with the IT resources. The type of interface may depend on the assumed tacit level of knowledge and capabilities of the users, such as internationalization, multilingual, or accessibility features for persons with disabilities (see PL 1998).

• Information Storage. Information may be stored to provide access to permanent data sources that may or may not be removable, including the secure creation, read, update, retention, or deletion of data.

• Communication Service. This allows access between application programs residing on the same or remote platforms. It may include datagram, connection-oriented, remote procedure, or transaction processing services.

• Network-to-Network Interface. This is the exchange of communication connectivity services across networks, such as data exchange, quality of service, network management, and service charging.

Top

Architectural elements

Each user of this guide needs to establish the type of elements they wish to define and control for their HS Agency. The fundamental types of technology elements and their relationships are depicted in the figure. The essential characteristics of these elements should be described to promote consistency in their implementation. Note that standards are used as a basis for defining the elements, discussed in The role of standards in the architecture process.

Like the views and the detailed breakouts of a construction architect's building plans, the HS Agency technical architects build descriptions that show how the individual technology elements are aggregated and arranged. The two types of composite descriptions showing how the individual elements work together are:

• System Architecture

The System in the context of these guides is the ensemble of technical platforms that interoperate to provide common and HS program-unique services across the HS Agency programs and divisions. This is a wide (enterprise) view of system, broader than a single computer system dedicated to a single function. Beside working together within the HS Agency, platforms also interoperate with automated systems external to the HS Agency.

The arrangement of automated platforms and their interconnections is the system architecture. It is usually represented diagrammatically, such as with a block diagram. This diagram corresponds in concept to the floor plans of the construction architect. It defines the major building blocks and how they relate. Detailed specifications for the items in the system architecture can then be provided (in detailed breakouts). The system architecture will evolve as computer platforms and their function or interconnections change as new applications are deployed, others are retired, and IT advances. The system architecture will guide the highest level of technical evolution by defining what the overall technology arrangement will look like for each plateau.

• Application Architecture

The architecture approach of this guide assumes a distributed application model. In a distributed environment, an application is partitioned into distinct functional units in which each part may execute on a separate, networked platform. This allows for deploying specialized platforms for each type of function. The number and processing capability of the platforms can be adjusted to allow application throughput to economically scale up or down based on processing demand. This multitier application layering (n-tier) establishes the overall model for an application's structure- its application architecture.

The figure illustrates a simple logical partitioning concept for a Web-based application environment in which the application functionality at one level uses the services of a lower level, reading top to bottom. Many application models can be provided for each tier depending on the mix of legacy and new application design techniques in use at any one time.

The tier types in the figure are:

• Presentation (Client side). This portion of the application is the front end of an automated application, handling all user interaction and interaction with the external world. The formatting, display, and input logic are usually placed on (or downloaded to) the client platform, where it is close to the input/output devices. The programs on this platform make requests for information resources on the back end. Client processing may be very robust and contain many features (a Win32 -based application or "thick client") or require minimal support (a Web browser-based application or "thin client"). The form factor of the platform such as the screen size of a Web-enabled cell phone may play a critical role in designing information to be displayed and manipulated by the end user.
  
  
• Presentation (Server side). Some user interface processing such as navigation, validating inputs, and tailoring output to usage environments may be managed more efficiently on a centralized processor rather than downloading or installing on the presentation client. For example, transcoding may be used to transform data into content suitable for a mobile device's small screen, low resolution, and limited communications speed. Security services, such as a firewall to ensure appropriate user access, also may be implemented. Server-side scripting may be needed for a robust, user-interactive experience.
  
  
• Business Logic. This implements the back-end portion of the application logic associated with handling real-world processes and manipulating their objects. Rules associated with how the business is run and how the information can be manipulated are enforced here. The business logic tier maintains integrity over business data transformations.
  
  
• Data Access. This portion of the application hides the data storage format and access mechanisms from the business logic that manipulates the data. This layer maintains the integrity, accuracy, completeness, consistency, and security of the stored data. It may provide common data processing services such as analytical functions, image, video, or geographic data manipulation.
  
  
• Data Storage. This portion of the application handles physical access to data sources, replication, availability, recovery, protection, and other low-level functionality (e.g., RAID). Data sources can have any format (e.g., spreadsheets, relational databases, flat files, video, and voice).

Top

Solution delivery life-cycle using an HS Agency-wide technical architecture

Each user of this guide needs to adapt the processes described within it to fit their own usage environment. This implies integrating this guidance into existing technology design and delivery processes. Project staff must establish how the resultant technical architecture descriptions will be used and maintained across the HS Agency scope. The processes described by this guide assume the usage model illustrated in the figure below.

Within the HS Agency context (i.e., enterprise) the HS Agency-wide business domain is characterized, and the technology required to support it today and into the future is determined. The main source of input is the IT Strategic Plan as well as any HS Agency-wide business process design decisions. The result of the technical architecture processes is a set of documentation describing the Agency Technical Architecture.

The technical architecture documentation is used to coordinate a set of technology projects across the HS Agency programs and divisions. It constrains and guides choices in developing, assembling, and using existing, new, or commercial products to meet specific (program) requirements. Contractors, vendors, or internal HS Agency IT development resources can be tasked to implement all or a portion of the HS Agency's Technical Architecture. Existing applications and data, new HS Agency-unique applications, or vendor-preferred products can be chosen and adapted to create the target architecture. The target is a specific set of interoperating platforms on which the applications will be delivered and executed.

Solutions that address specific business application requirements are delivered by populating the target with applications. Applications are composed from engineered or purchased packaged application solutions and/or application-specific components. As applications and their constituent parts are added to the target environment, they enrich the suite of services available and become a means to compose additional applications. All applications are structured in accordance with the application architectures established by the Agency Technical Architecture.

The architecture approach allows for delaying implementation decisions until necessary and provides flexibility to choose products to fit within the structure. The architects control the HS Agency's Technical Architecture; the automated solutions design teams control the target architectures; and programmers or solution providers control the composition of specific applications.

When advantageous, an HS Agency may standardize on products, as in the case of proprietary standards or preferred applications (e.g., office productivity suites). The architecture framework allows for an HS Agency to support this choice, to use the architecture relationships to determine the impact of the decision and to assess the long-term effect on the HS Agency. The framework also allows for restricting building on proprietary features of vendor products, as some features may circumvent HS Agency-approved standards. Defining an HS Agency technical architecture makes the rationale for selecting and using products visible for an analysis of risk or benefit, such as vendor lock-in or rapid time-to-deployment to be made.

Top

The three primary environments of interest

The approach takes a broad enterprise focus. This implies that the definition of technology in use throughout the Enterprise takes into consideration all the environments of interest (see Figure).

This assumes the following three generic types of environments:

• Business. This is the environment in which business users interact with the applications to provide the HS Agency's core value-added services or enable key business processes. The information technology is used in a business setting by business users to obtain, produce, and deliver products and services on behalf of the HS Agency's customers, suppliers, business partners, and oversight authorities. The environment may be segmented to include organizational subsets, such as personal/individual, workgroups (e.g., teams), departments (e.g., functional organizations such as a specific program), small service units (e.g., caseworkers), HS Agency-wide (e.g., hundreds of users, core databases, and data warehouses), and extended-agency/global setting (e.g., local, county, regional, partner, or international access). Users can be employed by the HS Agency, by partners, or be the clients themselves.

• Development. This is the environment in which the applications and underlying infrastructure (or parts) are acquired, developed, integrated, tested, and deployed. Individuals interact in this environment to provide technology for the business users, other developers (e.g., custom tools), and operators (e.g., system management and administration tools). This includes both creation and maintenance activities. The environment may be segmented for development specialties (e.g., programming, test, and integration) or maintenance activities (e.g., field maintenance and post-deployment help centers).

• Technical Operations. This is the environment in which the existing applications are runtime configured, operated, and administered. This environment considers the technology to run the business as well as support the development environments. Individuals manage user access, help-desk inquiries, data administration and backup, installation and configuration of applications, licensing, network administration, and other functions.

These environments may overlap in time and space. For example, a citizen may access HS Agency provided services over the Internet using a home PC. They may take responsibility to install, configure, and manage downloaded applications on their computer. Each activity is different and requires distinct services, skills, and knowledge. Within the HS Agency, these support activities may be more formally defined and distributed across specialized professionals, such as a support staff. When dealing with platforms that are not accessible to the HS Agency support staff, remote help may need to be provided.

Top

The role of the agency technology architect

The Technical Architecture Team has full responsibility for establishing and maintaining the HS Agency Technical Architecture descriptions and ensuring acceptable implementation. Members of the team have composite expertise in all relevant technology areas under consideration within the HS Agency. The term architect implies one or more technical individuals on this team. The Chief Architect is the central figure in coordinating and providing technical expertise to the team. Architects serve as technical leaders and stewards of the technology in use within the HS Agency.

The primary role of the architect is to create descriptions that others consult to build the HS Agency's automated solutions. As long as the description provides adequate guidance, they can take any useful form, such as models, reference implementations, prototypes, or narrative documentation. The descriptions are not uniform in level of detail. Some parts may be addressed generally (where any reasonable solution will do), and some parts may be very detail-oriented (such as an API or data element). Architects determine which technology choices are best left to the projects and which should be managed by the HS Agency.

Architects are generally responsible for the following:

• Leading the use of technology to meet enterprise business objectives as provided for in the IT Strategic Plan.

• Eliciting, interpreting, translating, and consolidating individual business needs into a consistent use of technology; guiding the business planners in identifying and applying technology in a cost-effective way; communicating and obtaining management buy-in to realize the technical vision.

• Conceptualizing the unifying structure for the automated systems and their constituent parts, conveyed in system and application architectures.

• Identifying, organizing, and specifying the entities, interfaces, and services across and within the processing platforms for each of the primary environments of interest.

• Providing consultation, coordination, and oversight of the implementation of the technical architecture by advising and reviewing individual system fabrication projects. This includes overseeing the purchase of compliant products. This may lead to establishing a group that arbitrates interface disputes to ensure interoperability and integration, such as an Interface Control Working Group.

• Overseeing reference implementations, such as out-of-context prototypes for parts of the architecture. These exemplify how elements may be constructed, aggregated, and used. These prototypes are available for experimentation. Not all essential characteristics of a robust application are available in the reference implementation (e.g., reliability, scalability, availability, and maintainability). Reference implementations may be used to develop test suites for project-specific implementations.

• Ensuring that the elements they specify can be implemented cost-effectively and have the necessary properties (e.g., scalability, reliability, security, and maintainability). Architects are familiar with the various construction techniques and tools (although they may not be as skilled as one who works in a particular field, such as a highly skilled professional programmer).

• Organizing the application architectures for change; noting what changes are possible; indicating the interfaces, services, and protocols that will isolate changes; and ensuring that the mechanisms to manage change are life-cycle-oriented. They consider the useful life-time of the entities they specify and how they will adapt over time, until they are retired.

Top

The role of standards in the architecture process

The process to produce and maintain an Agency Technical Architecture involves standardization of HS Agency-wide technology products and processes. Product standardization results in HS Agency consensus on the selection of common technologies and their properties, as well as where they can be deployed in the HS Agency. Process standardization results in the establishment of HS Agency-wide conventions for activities to acquire, develop, and operate the technology resources. The benefit is reducing unnecessary variation and managing changes where the HS Agency as a whole may benefit.

The philosophy of standardization in this guide is based on that of the Internet community, which states the following in RFC 2026:

In general, an Internet Standard is a specification that is stable and well-understood, is technically competent, has multiple, independent, and interoperable implementations with substantial operational experience, enjoys significant public support, and is recognizably useful in some or all parts of the Internet.

The Agency Technical Architecture therefore is the basis of standardization within the HS Agency; it represents agreement on the technical elements and how they will be used. It should reflect voluntary agreement and consensus by those that will be subject to it. This includes those producing the Agency Technical Architecture, as well as the IT project development and business program staff. If all parties abide by these agreements, then the HS Agency as a whole will benefit. Buy-in is achieved by involving the appropriate stakeholders throughout the process, by forming and officially chartering the architecture teams, and encouraging the architects to promote active participation of all stakeholders.

HS Agency internal or external conventions determine the basis for defining the technology elements. These conventions are the base standards that the HS Agency can adapt as the foundation upon which it specifies technology. Depending on the reach of the HS Agency, the source of the base standards should be considered, such as the following (adapted from Shulz 1995:

• International Standard. These standards are formally developed and successfully balloted outside the United States, using an approach that may vary greatly from the U.S. approach. International implies a scope of ballot that is global (e.g., ISO/IEC and IETF.

• U.S. National Standards. These standards are formally developed and successfully balloted inside the United States, from formal or voluntary standards organizations, using a variety of procedures and following basic ANSI guidelines (e.g., IEEE and NIST).

• Regional Standards. These standards are formally developed and successfully balloted outside the United States, using an approach that may vary greatly from the U.S. approach. Regional implies a scope of ballot limited to a specific part of the world (e.g., European and North American).

• Federal or State Standards and Regulations - These are promulgated by a Federal, State, or other regulatory body.

• Public Specifications. These include any specification that establishes some consensus without formal balloting, usually a proprietary specification that becomes widely adopted in the marketplace.

• De Facto Standards. These are proprietary specifications that are widely adopted in the marketplace, based on marketplace success, and are made available by the developer of the technology in a public (free) or private (license) agreement.

• Consortia Specifications. These are specifications produced by consortia or associations, usually in an environment where collaboration is important to share costs or achieve critical mass, although not unanimous consensus, in the market (e.g., W3C and OMG).

• Private or Proprietary Specifications. These are developed within an organization and may be protected by intellectual property restrictions or agreements prior to use. They include specifications that are unique to and only used within an Enterprise (e.g., inter-system data interfaces within the HS Agency).

The lifetime of a base standard is limited. Base standards may be emerging, mainstream, or in decline - on their way to being withdrawn (e.g., FIPS 1971). The HS Agency should determine its preferred precedence, which may not be uniform across all technology areas. The following guidelines are recommended for giving precedence to certain standards ( Shultz 1995).

• Approved standards maintained by accredited international standards development organizations

• Approved standards maintained by accredited regional bodies

• Approved standards maintained by accredited national bodies

• Draft standards maintained by accredited international bodies

• Draft standards maintained by accredited regional bodies

• Draft standards maintained by accredited national bodies

• Approved (not draft) specifications (widely adopted, but not formal standards) developed or maintained in an open forum

• Specifications developed by a closed forum, such as in-house

The technology definitions in the Agency Technical Architecture are defined on top of adopted base standards. Because HS Agency technology must align with that of the external environments in which the HS Agency operates, the base technology standards are selected as a foundation of interoperation and integration.

In some cases, project staff could easily standardize on a vendor product for a particular function, such as an office suite for generating documents. However, by selecting a vendor early in the design process, the HS Agency limits further choice, such as selecting a more cost-effective product from another vendor when it later becomes available. The architecture approach in this guide recommends that the architects describe the underlying technical need- such as "document interchange," using HTML -based document interchange. Architects would describe only the document exchange technical services in the Agency Technical Architecture (e.g., based on the HTML 4.01 base standard). The architects would adapt the base standard to the HS Agency needs, such as describing how deprecated language elements will be handled or how conventions for accessibility ( PL 1998) will be integrated. This obtains the functional goal (document exchange) while decoupling from a vendor implementation. Selection of a cost-effective solution now becomes a commercial consideration for the IT projects and the HS programs.

The following specific HS Agency elements are defined following a process of adoption, adaptation, and tailoring of existing base standards to fit the needs of the HS Agency:

• Adoption. Guided by the HS Agency's TRM, the architects identify the types of technology that should be included in the HS Agency's application systems. They then determine the basis for the technology elements by considering published internal or external standards based on the reach of the enterprise (global, regional, or local) and its threshold for technology risk (an early or late adopter). A candidate set of base standards is selected.

• Adaptation. A published standard may address a large constituency, such as an international community that the HS Agency may not have as part of its external environment. The published specification also may recommend good practices that are not essential for conformance with the specification. The architects consider the requirements necessary for conformance as well as the non-normative parts of the published standard. The architects establish the HS Agency's interpretation. The architects determine what parts are necessary, optional, or discouraged for implementation within the HS Agency. This application of the base standards then becomes the foundation for defining the technology elements of the Agency Technical Architecture, which will be used via tailoring.

• Tailoring. The technical architecture descriptions are the basis of standardization within the HS Agency. Tailoring implies IT projects making adjustments to the descriptions based on unique needs. The Agency Technical Architecture descriptions indicate options to be exercised and portions that apply under different circumstances. For example, vendors may have added proprietary extensions to a published standard, such as the Document Object Model ( W3C 2001), or there may be known limitations with using certain features of an existing standard (e.g., lack of explicit error handling). The architects control when and how these concerns are addressed. The goal is not to prohibit extensions or modifications arbitrarily, but to establish the appropriate checks and balances on their use. These resultant technology descriptions then become the operational basis applied on the program or project, derived from the Agency technical Architecture.

The guidelines provide language conventions that architects follow to document the elements in the technical architecture. Those conventions indicate the degree of freedom users have when applying the Agency Technical Architecture descriptions.

Top

The Role of an HS Agency-wide Technical Reference Model

Application systems continue to grow in size and complexity. They can no longer be built from scratch by teams of programmers working for years. Off-the-shelf infrastructure and packaged solutions are available. Elements that make up the Enterprise systems must have an orderly arrangement. IT projects can use this arrangement to identify, select, and integrate parts into the HS Agency's IT assets.

A TRM aids in organizing the Agency Technical Architecture's descriptions and promotes communications among the stakeholders. It represents early decisions on the technology that will (or will not) be included in the HS Agency's automated systems. It serves as an outline to establish common concepts and enumerate the technology parts based on an analysis of a technology or business domain. It is descriptive, not prescriptive, in that it identifies and describes the types of things that may be in the Agency Technical Architecture. It is not a physical partitioning. It influences the way the architects and others view, select, and arrange parts. As it is a high-level abstraction of the technology elements, which can be used to identify assets that can be reused across application systems.

The reference model helps the architect answer the questions:

• What type of parts should be in the HS Agency's automated systems?
• How should they be cataloged?

Architects evolve a reference model for their HS Agency, compiled from other available models. Technologies, standards, and vendor (or HS Agency internal) products can be organized against the model. In this sense, the model serves as a taxonomy. Each HS Agency classifies the parts of its architecture differently to suit the way it views the technology elements and its style of application partitioning.

A conceptual framework for organizing the TRM is shown in the model figure. The elements in this model are organized into the following categories:

• HS Area Applications. These are elements specific to the HS Agency program missions, such as supporting interactive interviewing, eligibility determination, case management, and many others.

• Support Applications. These elements are essential to performing the HS Agency program but are typically based on a generic implementation that is tailored and adapted for use. This includes common facilities such as word processing, calendar management, and email.

• Application Platform Services. These elements provide the environment for the applications to interact and use the computing platform. These can include prepurchased packages, individual services, or components to support user interface processing, programming support, data management, data interchange, multimedia, and so forth. Each type of platform may require different application platform services because the application (or part) that is hosted on a platform will require different capabilities.

• Common Services. This category represents ubiquitous services that are used across application areas, providing fundamental services. This includes security, systems management, or application distribution.

• Operating System Services. When necessary to specify them, elements at this level can be included, such as kernel operations, clock, programming shells, or process management. Note that higher-level services may abstract these and provide some portability of applications across operating systems. Unless the upper layers are specifically accessing these low-level services, they need not be included in the model.

• Networking, Information Exchange, and Users. These represent the external entities that will interface with the automated systems.

Top

Documenting the HS Agency technical architecture

Just as the construction architect's design of a building is reflected in a set of building plans and accompanying specifications, the Agency Technical Architecture must also be recorded in an effective manner. The means by which this is done is the A-TARS. Throughout the guides, the term Agency Technical Architecture refers to the abstract design information, while the term A-TARS refers to its written description.

The A-TARS is a collection of engineering data and guidelines, consulted primarily by designers when building or maintaining a system. Ideally, it is readily available, well organized, and in a form that someone can easily reference and use. It possesses a reference look and feel, with minimum tutorial or additional information. It assumes the reader has the appropriate level of understanding. When needed, background information for training can be separately included. The means by which the ATA is rendered depends highly on each State's IT situation. The representation should be optimized for clarity, brevity, and ease of use to ensure that users find, interpret, and apply the guidelines consistently. For example, service interfaces can be partially described using type libraries.

The A-TARS described in this guide does not assume a particular implementation. The logical arrangement of the A-TARS is shown in the figure. The activities in this guide create or modify information in this logical structure. An HS Agency implementing an A-TARS can adapt it by modifying, adding, combining, or removing sections. Project staff may increase or decrease the degree of rigor for the descriptions, from applying formal notations such as UML to using narrative descriptions. The need for precision in the descriptions should be driven by the users of the A-TARS and the need to ensure conforming implementations.

The portions of the guides are:

• Main Body. This is the highest-level description of the Agency Technical Architecture, tying together all the other sections. It introduces and references general background information and items that are common across all the sections that make up the technical architecture descriptions. This is the entry point for all users of the A-TARS and contains discussions describing the essential properties, usage of the A-TARS, overall applicability of the guides, documentation conventions, glossary, general references, change notices, and approvals.

• Technology Boundaries Descriptions. This portion of the A-TARS identifies and describes the use of technology platforms by external entities. This forms the highest-level description of overall technical business needs for the HS Agency. This is where entities in the three usage environments interact with the technology.

• Integrated Technology Descriptions. This portion of the A-TARS identifies and describes how the technology elements work together. The application architectures and the system architectures are portrayed. This is similar in concept to the plan views for a building, showing all the architectural elements and how they are arranged. Items in these descriptions can refer to further specifications in the other parts of the A-TARS, as needed.

• Building Blocks. This portion of the A-TARS is the collection of the low level parts and sub-assemblies that are referenced from the Integrated Technology Descriptions. These are the fundamental units that will be built or purchased to construct the integrated solutions. It contains:

  • Services Reference Set. This portion of the A-TARS is a set of loosely coupled descriptions, capturing the design descriptions for a suite of commonly deployed services. These are organized against the TRM.

  • Data Sources and Business Rules Reference Set. This portion of the A-TARS is a set of descriptions defining the essential characteristics of: the HS Agency-wide data sources and associated storage and retrieval technologies; data management practices; and HS Agency-wide common business policies, procedures, rules and associated processing technology.

  • Networking Reference Set. This portion of the A-TARS is a set of loosely coupled descriptions of the common network media, interfaces, protocols and networking guidelines (e.g., addressing). It describes the connectivity and interoperability between processing elements.

  • Platforms, Equipment, and Packaged Solutions Reference Set. This portion of the A-TARS is a set of loosely coupled descriptions that define the common configurations, equipments (devices) and packaged solutions used by the HS Agency. These subassemblies are the specialized platforms (e.g., types of servers, client platforms or information appliances) that are the major building blocks. Existing legacy systems to be integrated into the Agency Technical Architecture are also described here.

• Agency Standards Reference Set. This portion of the A-TARS consolidates the list of HS Agency base standards and how they have been adapted. These are the foundation for the Agency Technical Architecture descriptions. These can be consolidated into one place, or distributed across the other parts of the A-TARS, as needed.

  The use of the term reference set implies a collection of documentation related to all or a portion of the architecture. This collection can be thought of as a notebook of information optimized for reference to quickly answer designers and developer questions. The Technology Boundaries and the Integrated Technology Boundaries portions of the A-TARS show how the elements detailed in the reference sets work together. This allows some ability to identify and separately control changes to the overarching organization and the individual elements. This is intended to minimize change impact, such as adding a new service description or data sources, while keeping the application architecture fixed.

• Technical Guidelines Reference Set. This portion of the A-TARS consolidates the set of overarching guidelines that are to be followed across the HS Agency. This may include process as well as product guidelines. The TRM and tutorial information may be described here.

• Companion Documentation. These are separately evolving documents that are considered a significant influence on the overall A-TARS documentation set. They may address other parts of the overall HS Agency design and implementation, such as the business process. The A-TARS should be consistent with these documents.

Additional general guidelines on applying the IT Planning and Management Guides can be found in the Application of the IT Planning and Management Guides.

Top

Controlling the use and interpretation of the A-TARS

The contents of the A-TARS may not uniformly apply to all portions of the HS Agency at all times. Provide information in the main body of the documentation to describe the circumstances in which each portion does or does not apply.

It may be necessary to grandfather specific technologies or practices, showing how they can be treated in a uniform way with emerging technologies. Services may be defined to bridge or isolate declining technologies when and where they are in use.

The HS Agency must clearly establish the degree of compliance expected to the HS Agency Technical Architecture. Consistent terminology should be used when describing the technical elements. The degree of compliance for an element of the Agency Technical Architecture (adapted from RFC 2026) is defined as follows:

• Required. An element of the Agency Technical Architecture is essential and must be implemented to achieve minimal compliance with the architecture.

• Recommended. An element of the Agency Technical Architecture is not essential, but it is highly recommended that the element be implemented as defined. Not following the recommendation may lead to less flexibility in the future or additional cost to evolve. Projects are expected to make this tradeoff when initially planned. It may be necessary to revisit the project funding and implement the recommendation if it has long-term benefits.

• Elective. An element of the Agency Technical Architecture is optional when it applies only to a portion of the HS Agency technology in special circumstances. It is up to each IT Project Manager to evaluate and determine when and how to apply the element during development.

• Limited Use. A limited-use element of the Agency Technical Architecture is appropriate only in unique circumstances. This may apply to emerging (e.g., early releases or drafts of standards) or declining technology (e.g., preexisting vendor standards). IT Project Managers may require explicit permission to implement the technology on their project.

• Not Recommended. Not every possible item can or must be fully specified in the Agency Technical Architecture. The Agency Technical Architecture can narrow choices by explicitly excluding some items. The IT Project Managers will require explicit permission to use one of the not recommended technologies.

Within each description, architects should use a consistent language to make it clear how specific items should be handled. Consider the following definitions, from RFC 2119:

• MUST, REQUIRED, or SHALL. These are absolutely essential; they cannot be negotiated.

• MUST NOT or SHALL NOT. This is an absolute prohibition of an implementation that cannot be negotiated.

• SHOULD or RECOMMENDED. These items in the description can be ignored after explicit consideration. The impact of ignoring the recommendation should be assessed. A cognizant architect must be advised and concur with the alternative (one of the architects responsible for the technical description in which the phrase occurs).

• SHOULD NOT or NOT RECOMMENDED. These phrases imply that the normal course of action should be not to implement the item. Under certain circumstances, the item can be implemented after an assessment. A cognizant architect must be advised and concur with the selection (one of the architects responsible for the technical description in which the phrase occurs).

• MAY or OPTIONAL. These choices are left to each IT Project Manager.

Because the contents of the A-TARS evolve over time, the architects may identify areas that will be addressed but are incomplete at the time of publication. This may manifest itself as the use of TBD (To Be Defined) statements. IT projects using information marked TBD must coordinate with the architects before implementing. This allows for publication of the A-TARS to be taken out of the critical path of a project. The architects can participate with an IT project to define the Agency Technical Architecture element concurrent with its implementation. The A-TARS descriptions then reflect best practices. A description in the A-TARS when in draft or other unapproved form may be used at risk by the IT projects.

General responsibility to ensure conformance to the A-TARS descriptions should be established for each fabrication or maintenance IT project. A project quality assurance function would have overall responsibility to provide mechanisms to determine conformance. The IT Project Managers should invite key architects to participate on the design team and attend project technical reviews.

Top