Department of Interior

Enterprise Architecture (IEA)

SolutionArchitecture

Project:

Thursday,December28,2006

Chapter 2 Architecture Overview

12/28/2006

1.1.1 Scope
This blueprint solution architecture is based on the Interior Solution Architecture (ISA) Volume
I. ISA is the target logical solution architecture and service-oriented application reference
architecture for the Department of the Interior (the enterprise). ISA is intended to help the
department and its bureaus attain their business needs using cost effective, usable, and
maintainable enterprise applications. This blueprint core team plans to implement this unified
solution architecture throughout the enterprise to achieve a flexible business model that meets
the customers demands with greatly reduced cost and much improved efficiency.
This ISA document (Volume I) provides the relationship of the solution architecture (SA) with
business, data, application, technology, and security architecture domains. It also explains how
the solution architecture is driven by the enterprise business needs. Solution architecture and its
associated application architecture address multiple development and deployment platforms. It
applies Enterprise Application Integration (EAI) techniques in the application architecture.
Consistent use of the ISA will allow the enterprise to smoothly transition to a service-oriented
architecture (SOA).
Not addressed in this document is the ISA Volume II document which presents a Service
Oriented Architecture (SOA) roadmap for the enterprise and discusses SOA patterns, governance
and security best practices. The general the enterprise Application Architecture is laid out
Volume III, while platform-specific reference architectures are presented in Volume IV, .NET
Application Reference Architecture, and Volume V, J2EE Application Reference Architecture.
This document defines the enterprise target solution architecture, which supports an applications
business, data, application, technology, and security architectures. While it describes the
application architecture in detail, discussions of the other four architectures are beyond its scope.
The enterprise and its Bureaus are leveraging e-Government strategies to make themselves more
agile. This Solution Architecture (SA) initiative is a key step in improving the enterprises
customer service. The key business drivers behind this initiative are as follows:
Provide consistent human and application interfaces throughout the enterprise
Provide services that help reduce training costs
Provide interfaces that are easy to use
In addition, the department-wide initiative supports the goal of the Office of the Chief
Information Officer (OCIO) to improve the enterprises internal and external business practices
using electronic services. It promotes solution consistency and simplifies vendor selection.

1.2 Audience
This document is intended mainly for senior technical managers at the enterprise to foster a
common understanding on IT governance. It may also benefit the requirements analysts,

Chapter 2 Architecture Overview

12/28/2006

enterprise architects, solution architects, developers, and project managers who participate in
solution and application development.
Editor Notes:
Add comments for specific blueprint audience comments

1.3 Document Organization

This document provides an architecture overview and policy for the enterprise use of solution
architecture (SA) for information technology (IT) applications. It provides the service-oriented
architecture framework and the IT building blocks upon which the future the enterprise complete
solution will be developed. The ISA summarizes the main conceptual elements and the
relationships between these elements to aid a clear understanding of the enterprise target
architecture. It strives to achieve the following:
Outline the enterprise solution architecture that will help the department and its bureaus
achieve their business goals and IT Strategic Plans
Facilitate early validation of the solution architectures impact on the enterprise
Define the role of solution architecture in making the enterprise architecture more service
oriented, creating more reusable assets
Create a communication medium for the stakeholders: management, sponsors, users,
architects, developers, and implementers
Establish criteria and standards for product selection
Provide a template for the vendors to validate their proposed solutions
Provide a continuing path of analysis for EA blueprints
The document starts with an overview of enterprise and application architecture concepts and the
n describes the details of the sub-architectures. This chapter provides an introduction as well as
the purpose, scope, audience, and organization of the document.
Chapter 2, Architecture Overview, presents the context of solution and application architecture
within enterprise architecture. The following five chapters present each of the sub-architectures.
Chapter 3, Business Architecture, discusses the solution overview, use cases, and business needs,
requirements, and patterns.
Chapter 4, Data Architecture, applies the concepts Subject Areas, Information Classes, and
Conceptual and Logical Entities in the enterprise Data Reference Model (DRM) to the ISA. It
also presents Entity Relationship Diagrams and Object Role Model diagrams.
Chapter 5, Application Architecture, begins with application patterns and non-functional
requirements. It discusses architectural reference models, application interface types, and
service-oriented architecture. It presents component and operational models, and the n provides
a methodology for making architectural decisions. It also discusses test-driven development and
mapping the enterprise Service Component Reference Model (SRM) to solution functionality.

Chapter 2 Architecture Overview

12/28/2006

Technology Architecture and the enterprise Technology Reference Model (TRM) are reviewed in
Chapter 6.
Chapter applies Editor Notes to the other sub-architectures within SA: user security levels and
procedures; data security; application access, authorization, and security boundaries; and security
in the technology architecture.
A brief synopsis of the steps that are taken when applying the ISA is presented in Chapter 8,
Using Solution Architecture.
Appendix A has a glossary and a list of abbreviations and acronyms used in the ISA. Appendix
B contains a list of all the artifacts discussed in the ISA. A roadmap with pragmatic, concrete
steps for transforming the enterprise applications to the target service-oriented architecture is
presented in Appendix C.

1.4 References
[1] Patterns for e-business: A Strategy for Reuse, IBM Press, 2001
[2] Based on: Interior Solution Architecture Guidance Volume I: Target Logical Solution and
Service-Oriented Application Reference Architecture as provided by Service Oriented Integration
Center of Excellence, Chief Technology Officer Council (CTOC)
Editor Notes
Reference the team web site link and even the BFA Portfolio web site that captures the as-is
architecture. Cite the MBT products produced for this blueprint (or enterprise products) on the
site where any Figure you create in this document is sourced from.

Chapter 2 Architecture Overview

12/28/2006

2 Architecture Overview
Editor Notes
Overall focus on highlighting the scope and level of change discovered including:
As-Is State of the Architecture
Target Service Architecture Overview
Mission Validation against Architecture
o Scoring
o Portfolio Re-use Highlights
Major Gaps and Alternative Analysis
As-Is State of the Architecture:
Editor Notes
Highlight the following aspects of the portfolio architecture:
o Portfolio Counts (i.e. # of systems, investments)
o # of organizations
o Existing related PAR or PART scores for business focus area
o # of functions
Paste the Summary table below from the As-Is System and Services Scoring

Capture 5-10 sentences summarizing and noting specific rationale from As-Is System and
Services Scoring.
Target Service Architecture Overview:
Editor Notes
Summarize the Description of:
Value Chain Diagram
Stakeholder Overview Diagram
Target Systems and Services Interaction Diagram
Business Services Maturity Matrix points near-term and long-term
Describe in 2-3 paragraphs how the target architecture meets the service needs

Chapter 2 Architecture Overview

12/28/2006

Mission Validation against Architecture

Editor Notes
Scoring
Paste the Summary table below from the Target System and Services Validation - Summary

Capture 2-5 sentences summarizing and noting specific rationale from Target System and
Services Scoring.
Portfolio Re-use Highlights:
Editor Notes
Highlight what systems (from what organizations) are key for re-use in target services
highlighting rationale
Highlight what enterprise services (from what organizations) are key for re-use in target services
highlighting rationale
Highlight what federal services (from what organizations) are key for re-use in target services
highlighting rationale
Major Gaps and Alternative Analysis:
Editor Notes
Highlight what key Gaps that need extra resolve and (from what organizations) are key for re-use
in target services highlighting rationale.
As well, highlight tactical wins in alternative analysis (near-term) along with long-term endservice solutions architecture (long-term)

2.1 Enterprise Architecture

See Section 2.1 Enterprise Architecture in the Interior Solution Architecture document for a
review of the program and process on how this solution architecture document was created as a
part of the overall enterprise architecture.

2.2 Solution Architecture Principles

Principles establish the basis for a set of rules and behaviors for an organization. There are
principles that govern the IEA process and principles that govern the implementation of the
Chapter 2 Architecture Overview

12/28/2006

Interior Solution Architecture (ISA). Architectural principles for the IEA process affect
development, maintenance, and use of the IEA. These principles are documented in the
enterprise Conceptual Architecture Document Error: Reference source not found. ISA principles
for implementation establish the first tenets and related decision-making guidance for designing
and developing information systems.
Editor Notes
Further Non-Functional Requirement Principle detail will be captured in 5.2 Non-Functional
Requirements
The Solution and Application Architectures will encompass the following principles:
Flexibility
The enterprise will implement service-based application software that is independent of
hardware platforms, that is loosely coupled to infrastructure services, that places
reasonable demands on networks used for communication (i.e., minimizes traffic), and
that places minimal demands on users of the application.
Efficiency
The enterprise will create designs that reduce cost and implementation time, minimize
human intervention to preserve continuous and reliable operation, and reduce usertraining requirements. The architecture promotes user interfaces that optimize the nature,
efficiency, and effectiveness of the human operator.
Usability
The enterprise will implement easy-to-use solutions, accessible by people with
disabilities, which solve the enterprise business needs and provide needed information to
the public.
Balance
The enterprise will implement IT systems that provide availability and accessibility with
the appropriate level of security. Security shall be designed into all architectural elements,
balancing accessibility and ease of use with data protection commensurate to the
determined risks.
Reuse
The ISA, by creating standard application structure and leveraging SOA, provides the
foundation for their use of assets, including the solution architecture; business, data,
application, and run-time patterns; and business and infrastructure services. Reuse of
assets is key in reducing cost by eliminating redundant systems and promoting best
practices across the department.

2.3 Constituent Architecture Domains

See Section 2.3 Constituent Architecture Domains for a review of the purpose of solution
architecture as fits within purpose of overall enterprise architecture.

Chapter 2 Architecture Overview

12/28/2006

2.3.1 Business Architecture

Solution Architecture uses Business Architecture to ensure that the enterprise business needs are
addressed correctly and completely by every solution
Editor Notes
Summarize the lines of businesses covered by the solution architecture.

2.3.2 Data Architecture

Solution Architecture uses Data Architecture to ensure that an applications data is complete,
standardized, and can be accessed and reused across the enterprise (the enterprise).
Editor Notes
Summarize the subject areas covered by the solution architecture.

2.3.3 Application Architecture

The enterprise Application Architecture and associated technology-specific Application
Reference Architectures are described in Chapter 5.
Editor Notes
Summarize the as-is and target portfolio architecture as well as totals/differences such as
Portfolio Counts (i.e. # of systems, investments) and # of organizations involved.

2.3.4 Technology Architecture

Solution Architecture uses Technology Architecture for guidance in identifying the best platform
and infrastructure for each application.
Editor Notes
Summarize the service domains covered by the solution architecture.

2.3.5 Security Architecture

Security Architecture is an integral part of the overall Solution Architecture.
Editor Notes

2.4 Architectural Styles and Patterns

Review Section 2.4 Architectural Styles and Patterns in the Interior Solution Architecture
document.

Chapter 2 Architecture Overview

12/28/2006

2.5 Service-Oriented Architecture Overview

Review Section 2.5 Service-Oriented Architecture in the Interior Solution Architecture
document.

2.6 Solution Objectives and Scope

Editor Notes
Add additional notes on how the architecture is in support of the blueprint business focus area.
Much of this would be based off MBT Step 2 Blueprint products (primarily the SWOT Analysis).
Solution Architecture will give the enterprise an enhanced ability to:
Capture, integrate and share information from other sources
Identify needs (training, resources, etc.)
Drive Modernization Blueprints from the conceptual to the physical
Measure performance of programs and their management
Meet reporting requirements
Analyze and prioritize LOB-mandated efforts
Justify requests and expenditures
Manage citizen-oriented service programs
Protect natural and cultural resources
Business Drivers:

IT Drivers:

Improve Organizational Efficiency

Reduce the latency of Business
Events
Easy to adapt during organization
changes
Integration across multiple delivery
channels
Unified customer view across Lines
of Businesses (LOB)
Leverage current assets and
infrastructure

Chapter 2 Architecture Overview

Minimize total cost of ownership

(TCO)
Simplify skills base
Simplify Back end application
integration
Minimize enterprise complexity
Maintainability
Availability
Performance
Scalability
Security

12/28/2006

3 Business Architecture
3.1

Business Description

The business description defines at a very high-level for a solution the enterprise lines of
business, business functions, the users, and the interactions between users and functions. It can
be as simple as a couple of paragraphs. It should define the business functions that the solution
will perform along with the enterprise lines of business (LOBs) and external users for which the
solution will provide services.
Editor Notes
Extend off the Overview in more detail on each value-chain
Pull From Step 2 Vision Document
Revisit the lines of businesses covered by the solution architecture from 2.3.1
Cite Step 3 blueprint products related to business architecture (link to product instead of placing
hierarchy or table within document).

3.2

Solution Overview Diagram

The Solution Overview Diagram represents the business description pictorially, showing the
users, business functions, and their connections.
Editor Notes
< Insert an overview Target Systems and Services Interaction Diagram>
Exhibit 3- 1: Solution Overview Diagram (SOD) for the blueprint

3.3

Use Case Models

Review Section 3.3 Use Case Models in the Interior Solution Architecture document for
remainder of section including Use Case Template.
Editor Notes
In MBT Step 11 will be completed, but in MBT Step 4, process-system interaction will be listed
and modeled to IDEF0, BPMN, or similar activity modeling standards)

3.4

Functional Requirements Document

A functional requirements document can be useful at a number of points within a system

development lifecycle (SDLC), such as the design, testing, and acceptance phases. The
functional requirements are captured, primarily from the use case model, normally in a grid
presentation, such as a spreadsheet, a table, or a requirement modeling tool. The functional
requirements should contain, at a minimum, a statement of the requirement, the date the
requirement was captured, its context, source and priority, and the type of requirement (such as
Chapter 4 Data Architecture

10

12/28/2006

business, user, accessibility, etc.). The Functional Requirements Document should tie back to the
recommendations in the Modernization Blueprint, if applicable, as well as the solutions overview
diagram and the use cases.
Editor Notes
In MBT Step 11, the Functional Requirements will be completed, but in MBT Step 4:
From the As-Is State of the Architecture scoring, capture 5-10 sentences on specific points in
Performance and Business Criteria findings.
From the Target Service Architecture Overview, Capture 2-5 sentences summarizing and noting
specific rationale from Target System and Services Validation as related to Business Fit and Gap
Criteria.

3.5

Business, Integration and Composite Patterns

Business patterns are high-level concepts that establish the business purpose of any solution.
They define major objectives of the solution, identify participants, and help describe the
interactions between participants. Four basic business patterns are at the core of most (if not all)
composite business patterns: Self-Service, Collaboration, Information Aggregation, and
Extended Enterprise. There are also two integration patterns used to integrate two or more basic
business patterns: Access Integration and Application Integration.
Exhibit 3- 2: Business and Integration Patterns

Collaboration

Information Aggregation

Application Integration

Access Integration

Self-Service

Extended Enterprise
These business and integration patterns can be combined as composite patterns to implement the
enterprise-specific business solutions, making up composite patterns, discussed in Section Error:
Reference source not found, Error: Reference source not found. For more information on

Chapter 4 Data Architecture

11

12/28/2006

patterns, see Patterns for e-business: A Strategy for Reuse and Inside Patterns Error:
Reference source not found.
Exhibit 3-3: Business Pattern Selection Summary

Business Pattern

Description

Applicability to the
enterprise

Self-Service
(User-to-Business)

Applications where users interact with a

business via the internet or intranet

Good fit for a majority of

business sub-processes.

Collaboration
(User-to-User)

Applications where technologies support

collaborative work between users.

Good fit for a subset of

business sub-processes.

Information
Aggregation
(User-to-Data)

Applications where users can extract

useful information from large volumes of
data, text, images, etc.

Good fit for a small subset of

business sub-processes.

Extended Enterprise
(Bus-to-Bus)

Applications linking two or more business

processes across separate enterprises

Good fit for the integration

with other government
agencies.

Review Section 3.5 Business, Integration and Composite Patterns in the Interior Solution
Architecture document.
Editor Notes
In MBT Step 11 will be completed, but in MBT Step 4, service rationale on re-use, repeatable,
and redundancy inputs will be captured in rationale in the Target Systems and Services
Validation.
Highlight a paragraph for each Business Pattern based on reviewing the Ts/s Model

Chapter 4 Data Architecture

12

12/28/2006

4 Data Architecture
4.1

Subject Areas and Information Classes

Editor Notes
Summarize the subject areas and information classes in support of this segment. For each key
subject area, provide a brief description.
Cite Step 3 blueprint products related to data architecture (link to product instead of placing
hierarchy or table within document).
From the As-Is State of the Architecture scoring, capture 5-10 sentences on specific points in
Data Criteria findings.
From the Target Service Architecture Overview, Capture 2-5 sentences summarizing and noting
specific rationale from As-Is System and Services Scoring as related to any data related rationale
found in all Criteria.

4.2

Conceptual and Logical Entities

Summarize the conceptual entities in support of this segment. For each key subject area, provide
a brief description of the authoritative data sources.

4.3

Entity Relationship Diagrams

If it has been decided that the solution (or parts of it) must be one or more custom-built
applications, the types of data that will be required by each application should be organized into
logical and physical Entity Relationship Diagrams (ERDs). The logical ERD represents entities
and their attributes (and, optionally, categories) as well as the relationships between the m. The
physical ERD differs from the logical one in that it represents the tables and columns that will
actually be implemented in a database.
The basic ERD diagram is made up of rectangles that represent entities (i.e., tables in the
physical ERD) or views and lines that represent the relationships between the entities. A logical
ERD may also contain a circle sitting on a horizontal line that represents a category. Attributes
(columns in the physical ERD) are listed within the entity and view boxes, with primary and
foreign keys noted if known. A physical ERD may differ in several ways from its associated
logical ERD. Multiple logical entities may be collapsed into one or more tables. For example, it
is standard practice to represent every look-up entity (such as state codes, zip codes, etc.) as
separate logical entities, but they may be implemented as a single, generic reference table or as a
standard pattern of reference tables that includes a values, grouping, and sub-grouping tables.

4.4

Object Role Model Diagrams

For many newer applications, when custom-built applications are required, an Object Role
Model (ORM) diagram may be more useful than an ERD. The ORM starts at a much more
Chapter 4 Data Architecture

13

12/28/2006

conceptual level than an ERD, with no attributes and all facts stated as relationships between
objects. ORM tools allow ORM models to be mapped to relational database schemas. For more
information about ORM diagrams, see Information Modeling and Relational Databases Error:
Reference source not found. There is also a good overview by the same author on the Microsoft
Developers Network (MSDN) site.

Chapter 4 Data Architecture

14

12/28/2006

5 Application Architecture
Editor Notes
Summarize the as-is and target portfolio architecture as well as differences such as:
o Portfolio Counts (i.e. # of systems, investments)
o # of organizations
o Existing related PAR or PART scores for business focus area
o # of functions by services
Cite Step 4 blueprint products related to application and service architecture (link to product
instead of placing hierarchy or table within document).
From the As-Is State of the Architecture scoring, capture 5-10 sentences on specific points in
Application Criteria findings.
From the Target Service Architecture Overview, Capture 2-5 sentences summarizing and noting
specific rationale from As-Is System and Services Scoring as related to Project Fit and Gap
Criteria.

5.1 Application Patterns

Review Section 5.1 Application Patterns in the Interior Solution Architecture document.

5.2 Non-Functional Requirements

We have already discussed functional requirements. Other requirements, such as availability,
capacity, and performance fall into the category of non-functional requirements (NFRs). The
Modernization Blueprint and subsequent records of decisions may form the basis for many of the
systems functional and non-functional requirements. The blueprint should identify critical
performance indicators for a given business area that may be tied to actual performance metrics
in Bureau and Departmental strategic plans. NFRs specify the qualitative and other nonfunctional requirements that an IT system must satisfy. These requirements can pertain to an
individual system or a set of systems, to provide a related hierarchy of department- and
enterprise-level requirements. NFRs consist of:

Service level requirements (SLRs), which are run-time properties the system as a whole,
or parts of the system, must satisfy. SLRs include:

Capacity and performance (volumetrics)

Availability
Security
System management

SLRs sometimes relate to particular parts of the system, e.g., to particular use cases.

Chapter 5 Application Architecture

15

12/28/2006

Other required (non-runtime) properties of the system, such as:

Portability
Maintainability.

For convenience, NFRs can also include constraints the system must conform to or satisfy.
System Constraints include:
The business constraints which the system must satisfy (e.g., geographical location)
The technical standards the system must satisfy
The technical givens which constrain the system (e.g., which existing hardware or
DBMS must be used).
The following list can be used as a guideline for the NFR categories that need to be captured:
Availability
Backup & Recovery
Capacity Estimates and Planning
Configuration Management
Disaster Recovery
Extendibility/Flexibility
Failure Management
Performance
Reliability
Scalability
Security
Service Level Agreements
Standards
System Management
Editor Notes
Under each bullet, based on rationale points for each service, organize and summarize those
points as related to the operational qualities of the service. Further Non-Functional Requirement
Some NFRs are expected to change over time. For example, capacity requirements very often
increase as more workload is added to the system, or as the volume of stored data increases.
Exhibit 5 -4 provides a convenient way to capture this information.
Editor Notes
The exhibit table below should be reviewed again and finalized in Step 11

Chapter 5 Application Architecture

16

12/28/2006

Exhibit 5- 4: the enterprise Non-functional Requirement

5.3 Architectural Reference Models

See Section 5.3 Architectural Reference Models in the Interior Solution Architecture document.

5.4 Application Interface Types

See Section 5.4 Application Interface Types in the Interior Solution Architecture document.

5.5 Service-Oriented Architecture

See Section 5.5 Service-Oriented Architecture in the Interior Solution Architecture document.

5.6 Component Model

See Section 5.6 Component Model in the Interior Solution Architecture document.

5.7 Operational Model

See Section 5.7 Operational Model in the Interior Solution Architecture document.

5.8 Architectural Decisions

See Section 5.8 Architectural Decisions in the Interior Solution Architecture document.
Editor Notes
Insert summary of the Gap Alternative analysis and Architectural decisions performed in Step 4,
Task 4. More architectural decisions will continued to be captured up through Step 12 with a
majority addressed by Step 10.
Discuss the different architecture

5.9 Test-Driven Development

See Section 5.9 Test-Driven Deployment in the Interior Solution Architecture document.

5.10 Mapping the SRM to Solution Functionality

Editor Notes
Insert the Target Services and Systems Diagram. In a paragraph for each FEA SRM Service
Type, describe how the target services relate.

Chapter 5 Application Architecture

17

12/28/2006

6 Technology Architecture
The Technology Architecture applies to the Solution Architecture by guiding the following
decisions:
On what platform will the solution run?
What components of the technology-specific Application Reference Models are required
for the solution?
What business functionality and infrastructure components can be reused or purchased as
COTS products?
Editor Notes
Cite Step 4 blueprint products related to application or service architecture (link to product
instead of placing hierarchy or table within document).
From the As-Is State of the Architecture scoring, capture 5-10 sentences on specific points in
Technology Criteria findings.
From the Target Service Architecture Overview, Capture 2-5 sentences summarizing and noting
specific rationale from As-Is System and Services Scoring as related to Project Fit and Gap
Criteria.

Chapter Editor Notes

18

12/28/2006

7 Security Architecture
Security Architecture interacts with all the other constituent architecture domains of SA:
Business, Data, Application, and Technology. Per the Business Architectural components, the
Security Architecture includes determining the appropriate user roles, security levels, and
procedures. With regards to Data Architecture, it includes various types of data security. The
Application Architecture must consider its security policy, including authorization, identification,
and application security boundaries. Within Technology Architecture, how the required security
can be provided by the technology infrastructure must be determined.
The enterprise Security standards are documented in the Interior Enterprise IT Security
Architecture Blueprint V1.0 Error: Reference source not found and the Interior Enterprise IT
Security Architecture Standard V2.1 Error: Reference source not found. During all phases of a
solution lifecycle, it is appropriate to determine what security components can be reused from
existing enterprise solutions or purchased as COTS products.
Editor Notes
Cite Step 4 blueprint products related to security architecture (link to product instead of placing
hierarchy or table within document).
From the As-Is State of the Architecture scoring, capture 5-10 sentences on specific points in
Security Criteria findings.
From the Target Service Architecture Overview, Capture 2-5 sentences summarizing and noting
specific rationale from As-Is System and Services Scoring as related to Project Fit and Gap
Criteria.

7.1

User Security Levels and Procedures

User roles and procedures is the primary focus of security within Business Architecture. To
implement a solution, the security policies and procedures must be defined that will allow the
appropriate users to access and interact with the solution.
Editor Notes
To be completed in Step 11

7.2

Data Security

Security Architecture is concerned with two main dimensions in Data Architecture: data domain
security and security applied to domain cross-sections. In Exhibit 7 -5, for example, an
application could contain data about sites and projects (two data domains represented vertically).

Chapter Editor Notes

19

12/28/2006

Exhibit 7- 5: Example Data Domain and Cross-section Security

Project Data

Site Data

Data for a project at one site

A user could have access only to project data or only to site data (a given data domain) or could
have access only to data for a certain set of projects at a certain set of sites (a cross-section). The
solution dealing with this situation would have to be able to restrict access to project data in at
least two ways. First, only users who are authorized to see project data (the vertical security
slice) should have access to project data interface. Second, users authorized to see only
particular project data must be appropriately restricted. There may also be a need to define roles
for update versus read-only access to groups of data.

7.3

Application Security Policy and Boundaries

Each application must consider, as part of its business requirements, the levels of security
required and how and where it will be implemented. The enterprise Security Architecture lays
out the framework for applying the enterprise security policy to applications, such as:
Access to applications
Security at the application boundaries
Security of platforms on which the application components run
Physical security for system components and hardware
The Operational Models, based on the Technology-Specific Application Reference Architectures,
can be used to aid in the identification of application security boundaries, platform security, and
physical security.

7.4

Security in the Technology Architecture

Within the enterprise Technology Architecture, security is currently a major focus because of the
HSPD-12 directive. The Technology Architecture must recommend security technology
solutions that comply with the enterprise Security Architecture and that are as reusable and
interoperable as possible.

Chapter Editor Notes

20

12/28/2006

Using Solution Architecture

Refer to full checklist on using Solution Architecture in Chapter 8 Using Solution Architecture in the
Interior Solution Architecture.
These procedures are used (as appropriate) to apply the ISA to a particular solution. Note that the
following list is not meant to imply an order in which the steps must be executed many of these steps
may be performed concurrently. Also see Appendix B Solution Architecture Artifacts for a list of the
artifacts mentioned below.

F-21

9 Appendix A Glossary
See 9 Appendix A Glossary in the Interior Solution Architecture document.

9.1

Terms and Definitions

See 9.1 Terms Definitions in the Interior Solution Architecture document.

F-22

10 Appendix B Solution Architecture Artifacts

The following table lists the artifacts for a solution complying with the ISA.
Exhibit 10-6: the enterprise Solution Architecture Artifacts
Artifact

Related
Subarchitecture

Comments

Required

MBT
Step

MBT
Product
Name(s)

Blueprint
Supported

Business
Description

Business

Brief narrative

Required

Editor
note

Yes

Solution
Overview
Diagram (SOD)

Business

Enhanced in
subsequent steps
with business and
integration pattern
and service
components
overlays

Required

Yes

Use Case Model

Business

Diagram or text
high-level with text
documenting each
use case and actor

Required

Activity
Modeling
Input (for
use case)

Functional
Requirements

Business

List

Required

Services
listed,
interface,
stakeholder
exchange,
but not
bus. Rules

Solution Subject
Areas and
Information
Classes

Data

List

Required

Yes

Solution data
mapped to the
enterprise
entities or
classes

Data

List

Required

Key Areas
and Core
Areas only

Entity
Relationship
Diagram (ERD)

Data

Diagram

As needed for
new
development

Logical ERD
-Key Areas
and Core
Areas only

Object Role
Model (ORM)
diagram

Data

Diagram

As needed for
new
development

F-23

Application
Patterns and
Tiers

Application

Diagram

As needed

11

Non-functional
Requirements

Application

List

Required

4,11

Partial

SRM mapped to
business
functionality

Application

Diagram

As needed

Yes

Application
Reference Model

Application/
Technology

Diagram

Required for
COTS products
and new
development

Yes

User Roles and

Security Levels

Security

List

Required

11

Procedures

Security

Document

Required

11

Data Security

Security

Document

Required

11

Application
Access

Security

Document

Required

11

Application
Security
Boundaries

Security

Diagram

Required

11

Security
Technology

Security

Document

Required

11

F-24