Skip ACF banner navigation
US Department of Health and Human Services US Department of Health and Human Services US Department of Health and Human Services US Department of Health and Human Services US Department of Health and Human Services US Department of Health and Human Services
Department of Health and Human Services logo US Department of Health and Human Services  
US Department of Health and Human Services Questions?  
US Department of Health and Human Services Privacy  
US Department of Health and Human Services Site Index  
US Department of Health and Human Services Contact Us  
US Department of Health and Human Services Download Acrobat® Reader™  
US Department of Health and Human Services   ACF Home   |   Services   |   Working with ACF   |   Policy/Planning   |   About ACF   |   ACF News Search  
US Department of Health and Human Services US Department of Health and Human Services US Department of Health and Human Services
Administration for Children and Families US Department of Health and Human Services
National Human Services IT Resource Center

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:

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:

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.

Diagram showing 2 entities exchanging services across an interface

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).

Block diagram of the typical entities and interfaces. Each of the entities and the types of interfaces are described in the following text.

Types of technology-related entities are:

Interface types include the following:

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.

Block diagram of the key IT entities and relationships. The Technology Platforms provide services to External Entities; Technology Entities are composed of Platforms, and are based on Standards; and Interconnections are based on Standards and connect Technology PLatforms.

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:

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.

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.

Block diagram of the application tiers (Presentation, Business Services, and Data Services Layers, and their subtiers (Business Data Storage and Access sublayers, and Web Service and Client Interaction sublayers). The interfaces between the layers is illustrated showing one layer invoking services of another layer. The tiers types are described in the following text.

The tier types in the figure are:

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.

Notional diagram of the architecture driven process. In the Agency Context, the Business and Technology Range defines the Technical Architecture that is used to guide and constrain the Agency Programs and Division. Within the Programs and Divisions, their Business and Technology decisions guide their target architecture - the technical environment for composing and deploying many (portfolio) applications, services, and components. The diagram is further described in the following text.

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).

Venn diagram of three intersecting domains - Business , Development, and Technical Opertions Environments. They are described in the following text.

This assumes the following three generic types of environments:

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:

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:

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).

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:

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:

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:

Diagram representing a technical reference model as a set of layers with interfaces between layers. Building from the bottom up, the layers are: External Environment (consisting of Networking, Information Exchange, and Users), Application Platform Services (Major and Minor Service areas, and common services), Support Applications, and Human Service Area Applications.

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.

Diagram illustrating the technical architecture documentation. Together, they are considered the Agency Technical Architecture Reference Set. It consists of the Main Body and three subparts: Technology Boundaries Descriptions, Integrated Technology Descriptions, and Technical Guidelines and Refernece Set. A set of building blocks, and the Agency Standards are used to construct the three subparts. The portions of the guide are further described below.

The portions of the guides are:

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:

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:

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



Last Updated: May 4, 2005 May 4, 2005