Professional Documents
Culture Documents
IT ARCHITECTURE
CONTENTS
EXECUTIVE SUMMARY .......................................................................................................................... 3
I.
II.
III.
IV.
BACKGROUND .................................................................................................................................... 3
VISION AND STRATEGY ...................................................................................................................... 3
OVERALL ARCHITECTURE .................................................................................................................. 4
BUILDING BLOCKS OF E-GOVERNANCE ............................................................................................... 5
APPLICATION ARCHITECTURE........................................................................................................... 6
I.
II.
III.
IV.
DEFINITION ......................................................................................................................................... 6
INTRODUCTION AND BACKGROUND .................................................................................................... 6
PRINCIPLES ......................................................................................................................................... 7
TECHNICAL TOPICS............................................................................................................................. 8
INFORMATION ARCHITECTURE....................................................................................................... 14
I.
II.
III.
IV.
DEFINITION ....................................................................................................................................... 14
INTRODUCTION AND BACKGROUND .................................................................................................. 14
PRINCIPLES ....................................................................................................................................... 14
TECHNICAL TOPICS........................................................................................................................... 15
GROUPWARE ARCHITECTURE.......................................................................................................... 22
I.
II.
III.
IV.
DEFINITION ....................................................................................................................................... 22
INTRODUCTION AND BACKGROUND .................................................................................................. 22
PRINCIPLES ....................................................................................................................................... 22
TECHNICAL TOPICS........................................................................................................................... 23
COMPONENTWARE ARCHITECTURE.............................................................................................. 33
I.
II.
III.
IV.
DEFINITION ....................................................................................................................................... 33
INTRODUCTION AND BACKGROUND .................................................................................................. 33
PRINCIPLES ....................................................................................................................................... 33
TECHNICAL TOPICS........................................................................................................................... 34
DEFINITION ....................................................................................................................................... 39
INTRODUCTION AND BACKGROUND .................................................................................................. 39
PRINCIPLES ....................................................................................................................................... 39
TECHNICAL TOPICS........................................................................................................................... 40
DEFINITION ....................................................................................................................................... 55
INTRODUCTION AND BACKGROUND .................................................................................................. 55
PRINCIPLES ....................................................................................................................................... 55
TECHNICAL TOPICS........................................................................................................................... 57
INTEGRATION ARCHITECTURE........................................................................................................ 61
I.
DEFINITION ....................................................................................................................................... 61
II. INTRODUCTION ................................................................................................................................. 61
III. PRINCIPLES ....................................................................................................................................... 61
Page 1 of 103
Private & Confidential
DEFINITION ....................................................................................................................................... 68
INTRODUCTION AND BACKGROUND .................................................................................................. 68
PRINCIPLES ....................................................................................................................................... 68
TECHNICAL TOPICS........................................................................................................................... 70
PLATFORM ARCHITECTURE.............................................................................................................. 76
I.
II.
III.
IV.
DEFINITION ....................................................................................................................................... 76
INTRODUCTION AND BACKGROUND .................................................................................................. 76
PRINCIPLES ....................................................................................................................................... 76
TECHNICAL TOPICS........................................................................................................................... 77
DEFINITION ....................................................................................................................................... 84
INTRODUCTION AND BACKGROUND .................................................................................................. 84
PRINCIPLES ....................................................................................................................................... 84
TECHNICAL TOPICS........................................................................................................................... 86
DEFINITION ....................................................................................................................................... 95
INTRODUCTION ................................................................................................................................. 95
PRINCIPLES ....................................................................................................................................... 95
TECHNICAL TOPICS........................................................................................................................... 96
Page 2 of 103
Private & Confidential
Executive Summary
I.
Background
Government of Andhra Pradesh (GoAP) has undertaken multiple initiatives using Information
Technology as a strategic tool to provide improved service to citizens. The pilot projects FAST,
CARD, MPHS & TWINS have been successfully piloted and widely appreciated. Capitalising on
the success of these pilot projects the government departments were keen to go ahead and
rollout the solutions to other locations. The Information Technology & Communications (IT & C)
department wanted to develop an overall architecture for the state along with standards and
policies for key technology components, so that applications developed are interoperable.
II.
Government of Andhra Pradesh (GoAP) is a progressive state, which has set itself aggressive
targets(Vision 2020) to bring prosperity and well being of its people. In order to achieve this level
of development the state has embarked on various efforts to bring about economic growth.
Information Technology (IT) is one of the major contributors for achieving this vision.
Page 3 of 103
Private & Confidential
GoAP envisions to improve its services to citizens and businessmen by providing Simple,
Morale, Actionable, Responsive and Transparent (SMART) governance. The government
foresees that services to citizens will be made available through various delivery channels
(department interfaces, integrated citizen interface counter, Internet, kiosks, etc). Some key
benefits that can be achieved through e-Governance are :
!
Information accessed through various delivery channels must be uniform, reliable & secure
The services offered through various delivery channels should be economically viable to
develop, operate and maintain
Information technology can be used effectively to achieve the vision in light of the business
imperatives. Key IT imperatives for e-Governance are:
!
Increased IT investments across multiple levels of governance (Mandal, division, district, etc)
III.
Overall Architecture
The overall architecture for e-Governance needs to ensure that the architecture components are
extensible and scalable to adapt to the changing environments. In order to minimise the risk,
there is an increasing trend where the applications development is moving towards n-tier
architecture. Communication cost will continue to fall in the years to come with convergence of
technologies. The cost of skilled technical resources will continue to increase in the future.
Page 4 of 103
Private & Confidential
The architecture options are decentralised architecture, hybrid architecture and centralised
architecture.
It is recommended that the state government architect its solutions around
centralised architecture. The government employees will access the applications over a secure
Intranet using browser as their front end. Citizens and businesses can access the services over
internet. This target architecture would achieved in phased manner based on availability of
infrastructure such as communications, PKI, payment system, etc.
IV.
Application
Information
Group ware
Component ware
Data
Applications Middle ware
Integration
Network
Platform
Security and Directory Services
Systems Management
For each of the architecture components, key guiding principles, best practices and standards are
outlined below.
Page 5 of 103
Private & Confidential
Application Architecture
Application Architecture
I.
Definition
Application Architecture identifies criteria and techniques associated with the design of
applications for the states distributed computing environment that can be easily modified to
respond quickly to the states changing business needs, as well as to the rapidly evolving
information technologies available to support those needs.
II.
Recently, application development tools and technology have begun to evolve to help address
these problems. A number of options now exist for meeting business needs and delivering
information to people when and where they need it. These options include:
Reuse of Code: Units of code previously duplicated in many applications can be packaged
into components or services that can be easily reused by different applications.
Middleware: Shared software can allow applications to communicate with each other, access
data residing on different platforms, and access shared services.
New User Interface Options: An expanding array of user interface options including Web
browsers, personal digital assistants (PDAs), and interactive voice response units (IVRs) have been introduced.
Page 6 of 103
Private & Confidential
Application Architecture
Application Architecture
Application Portfolio
Executive Information System
Geographical Information System
Employee Payroll and
Human Resource Management
Attendance Recording
Employee Payroll
Expense and travel processing
Loans and advances
Training & career development
Policies and employee info
Requisition to Payment
Requisitions/Indents
Tendering/Quotation
Purchase order
Inventory management
Accounts payable
E-Mail
Integrated messaging system
Electronic meeting
Electronic bulletin board
Planning
Financial modeling
Development Planning system
Content Management
Personalisation
Customer Relationship Management
E-Business Applications
Citizen services
Lodgment /Registration
Issue of permits, licenses,
certificates,etc
Receipt of payment
Payment to citizens
Complaints management
Project/Schemes Management
Project planning
Project monitoring
Project reporting
Communications
Groupware
III.
Principles
The principles listed below are key guidelines for the design or purchase of applications and
application components supporting distributed, client/server computing across the state.
The designer should allow for the possibility of re-partitioning an application in the future.
Being highly granular and loosely coupled provide flexibility in physical implementation (i.e.,
in the deployment of application components on different platforms).
Highly granular, reusable application components are key to increased productivity and rapid
application deployment. The Componentware Architecture supports a highly granular design.
Applications must evolve to support new business requirements and make use of new
technologies.
Extensibility provides functional scalability.
Applications should be built by assembling and integrating existing components, rather than
by creating custom code. Shrinking cycle times do not allow for artisan programming.
Managing component reuse is supported by the Componentware Architecture.
Page 7 of 103
Private & Confidential
IV.
Application Architecture
Technical Topics
Page 8 of 103
Private & Confidential
Application Architecture
Application Architecture
Development Approach
OLTP Applications
Development Approach
Custom Development
Citizen services
Employee Payroll
Package
Package
Purchase
Package
Planning
Package
Package
Project/Schemes Management
Package
Package
Package
Content Management
Package
Personalisation
Package
Web Server
Package
Note : The above are some sample list of package vendors available in the market.
While many of the problems inherent in the monolithic and two-tier applications can be
overcome by implementing applications with a three-tier architecture, large, complex projects
that are anticipated to have high usage volumes and/or long life spans will be better served
by an N-tier service oriented architecture.
N-tier applications are easily modified to support changes in business rules.
N-tier applications are highly scaleable.
An N-tier architecture offers the best performance of any application architecture.
Any combination of user interfaces (e.g., character, graphical, web browser, and telephone
interfaces) may be implemented in an N-tier application.
N-tier applications are less expensive to build and maintain because much of the code is prebuilt and shared by other applications (see Componentware Architecture).
Page 9 of 103
Private & Confidential
Application Architecture
The code providing input and output to the user interface should be designed to provide input
and output to as wide a range of interfaces as possible. This should include other
applications as well as other types of user interfaces.
Do not assume that application components will always be accessed via a graphical user
interface (or any other user interface).
Avoid assuming a specific page size, page format, layout language or user language
whenever possible.
Assign responsibility for defining and maintaining the integrity of business rules to business
units.
IT staff is responsible for coding and administering the software that implements business
rules in the network.
The business units are responsible for the definition and integrity of business rules, and for
communicating changes in business rules to IT.
Every business rule should be assigned to a custodian.
discrete
executable
components
or
services
(see
Coding standards make debugging and maintenance easier. They should address (but not be
limited to):
Page 10 of 103
Private & Confidential
Application Architecture
Naming conventions for variables, constants, data types, procedures and functions.
Code flow and indentation.
Error and exception detection and handling.
Source code organization, including the use of libraries and include files.
Source code documentation and comments.
Even the earliest code developed in a project should adhere to the standards.
Standards
The standards in this section pertain to the design and development of applications.
Standard 1: Develop 3-tier or N-tier Applications
All new Department applications should be developed using 3-tier or N-tier architecture in
order to maximize flexibility and scalability.
Large, complex projects that have high usage volumes and/or long life spans will be better
served by an N-tier service oriented architecture.
The logical separation of the tiers for: user interface(s); business rules; and data access code
allows for simple, straightforward additions to each of the three tiers without undue impacts
on the others.
The logical separation of the tiers also allows for changing the platforms where the tiers are
deployed, resulting in a high degree of scalability. As transaction loads, response times, or
throughputs change, a tier can be moved from the platform on which it executes to another,
more powerful platform - or be spread over multiple machines - without impacting the other
tiers.
While many of the problems inherent in the existing monolithic and two-tier applications can
be overcome by implementing applications with a three-tier architecture, the goal should
always be true, N-tier applications.
The maximum benefits of an N-tier architecture are realized when many N-tier applications
are deployed across the state, sharing common software services and offering multiple user
interfaces.
Large, complex projects that are anticipated to have high usage volumes and/or long life
spans will be better served by implementing applications with a three-tier architecture with
access to an N-tier service oriented architecture.
With three-tier client/server applications, there is less risk in modifying the code that
implements any given business rule.
Three-tier client/server applications can be made to support multiple user interfaces:
character, graphical, web browser, telephones, and others.
Isolate customizations into separate modules from the purchased software itself to improve
the ability to upgrade and move to new releases as required over time. For purchased line-ofbusiness applications, loosely couple custom developed modules from the standard
application software.
Standard 3: Avoid Common Gateway Interface (CGI) for business logic or to publish
information to the Web.
Page 11 of 103
Private & Confidential
Application Architecture
The Common Gateway Interface (CGI) does not scale, is not portable and is not easily
integrated with application servers. Avoid use of CGI for information publishing, back-end
applications or data access.
Publishing information to the web with HTML or XML via Java servlets reduces overhead and
works in conjunction with EJB-based components.
The use of ASP or other HTML publishing is acceptable for publishing only (not business
logic) but JSP and Servlets are preferred.
Manage the application as a whole entity by managing every component of the application
and everything each component depends on. Application developers must instrument every
component of the application to facilitate its management.
Application dependencies include infrastructure (e.g., middleware, databases, and networks),
other applications, and shared software components. Application teams must specify these
dependencies when an application is deployed.
Application reporting should be standards based and must be compatible with the states
SNM tool.
Best Practice 2: Design for proactive rather than reactive application management.
Page 12 of 103
Private & Confidential
Application Architecture
Best Practice 3: Instrument applications to report the information necessary to manage them.
Applications should report status, performance statistics, errors, and conditions. Decide at
design time what status events the application should report to users (e.g., erroneous input);
to application managers (e.g., database table 90% full); and to both (e.g., cant find needed
file).
Operations staff must be provided procedures for dealing with all conditions that are detected
and reported. For example, if an application reports it can no longer access its database,
operations staff must have instructions for handling the situation.
At design time, decide the specific reporting requirements of an application module. Different
applications may have different management needs, depending on their respective impact on
the business the applications support.
Applications should only report. Interpreting the reports and deciding on the appropriate
response should be performed external to the application, by agents and the SNM
framework.
Application reporting should include run-time tracing to assist trouble-shooting operational
problems. Tracing should be able to be turned on and off by administrators.
If no SNM environment exists, applications should still report status to local log files that can
be monitored by administrators. Applications should still be able to read and respond to
commands from administrators.
Standards
The standards in this section pertain to managing applications.
Standard 1: All applications deployed must be designed to be managed by SNMP.
Page 13 of 103
Private & Confidential
code.
Information Architecture
Information Architecture
I.
Definition
Information Architecture provides standards for accessing data for online analytical processing
(OLAP), including executive information systems (EIS) and decision support systems (DSS).
II.
Important data is stored in multiple application systems across the state and is used to perform
day-to-day operations. If this distributed data is grouped together in a meaningful format, it can
provide valuable information to the states business organizations. Information is a compilation of
data used for reporting, analysis, and decision support. Information compiled from data coming
from many sources, including historical and summary information, can facilitate business
decisions.
III.
Principles
How the data is used is far more important than the data itself (i.e., even if data is accurate, it
can still be used ineffectively).
The most effective use of data is to turn it into proactive information that responds to
business events (e.g., the push model of information).
Page 14 of 103
Private & Confidential
Information Architecture
Too much information gets in the way of focusing on the most important issues that arise at a
specific point in time. Some data warehouse efforts put any data in a data warehouse that
may be useful in the future, not just the information to assist in a business need. If there is
much more information than is needed, it can overwhelm an end user rather than answering
their specific decision support need.
Information that supports OLAP analysis should be proactively presented to business users.
Information in a data warehouse can be presented to business end users so that they know it
is available and they can use it.
IV.
Separate data storage isolates OLTP systems, which perform mission critical business
processing, from large ad hoc queries and online analytical data processing. If data storage is
not separate, ad hoc queries and direct access of data for OLAP systems can adversely
impact online transactional processing.
Data design for each type of application, OLTP or OLAP, can be optimized for performance.
OLTP and OLAP may require different database designs. OLAP typically includes complex
operations involving time series and trend analysis, which do not perform well with relational
database technology alone (e.g., sometimes other methods of data storage are needed to
support OLAP, such as multi-dimensional databases or flat files).
For more information about OLTP data, refer to the Data Architecture chapter.
Technical Topics
Information Architecture
used should be designed to support a very large data warehouse, instead of using data mart
specific products.
Recommended Best Practices
The recommended best practices in this section pertain to the implementation of a data
warehouse.
Best Practice 1: Begin data warehouse efforts by addressing a specific requirement for a
specific decision support application, keeping growth and scalability in mind.
This practice is similar to data mart design, but the tools and databases used should be
designed to support a large data warehouse.
Use vendor supplied products designed to support a large data warehouse. Vendor-supplied
data mart tools are not typically scaleable to support the migration from a data mart to a data
warehouse solution. These tools are designed to quickly implement a specific solution.
Best Practice 2: Identify specific requirements for data availability, freshness (i.e., live, 24
hours old, etc.), and recoverability.
Some data warehouses need to be updated more frequently than others. When the original
data is frequently changing or is more volatile, it may be necessary to update the data
warehouse on a near real time basis.
On the other hand, if the original data is fairly stable and not as volatile, the data warehouse
may only need daily, weekly, or even monthly updates. For example, a data warehouse that
stores criminal data contains more volatile information and needs to be updated more
frequently than a data warehouse that stores state registered corporation name and address
information for public access.
Best Practice 3: Perform benchmarks on the database design before constructing the
database.
Best Practice 4: Allow only read only access to end users of data warehouses.
Updates should only occur to the operational (OLTP) source where the data originates.
Best Practice 5: Direct all information queries against decision support databases, not OLTP
databases. Conversely, operational transactions should be directed to operational databases
only, not OLAP databases.
Data warehouses, and data marts contain data that has been checked for consistency and
integrity, and represents a cross-functional view of data.
Data in transaction (OLTP) systems typically support a specific business group or function.
OLTP transactions should not depend on a data warehouse database. They require a stable
operational environment that is not affected by ad hoc usage or external data.
Page 16 of 103
Private & Confidential
Information Architecture
Best Practice 6: Store atomic-level data in the data warehouse in addition to summary data.
Atomic data is transaction-level data. It contains much more detail than summary data.
Atomic-level data addresses the business need to recast history. Due to the fast pace of
business change, many organizations are going through multiple reorganizations. After a
reorganization, many decision makers want to recast history (e.g., to get a feel for what test
scores would have been like if the number of school districts was already reduced to respond
to legislation or funding).
If only summary level historical data is kept in the data warehouse, it is not possible to recast
history.
Best Practice 7: Perform periodic validity audits against the data warehouse information
model to ensure a high level of confidence in the quality and integrity of the data.
Accelerated decision making requires high quality data. If operational data has changed or
additional data is needed, changes must be made in the information model and in the data
warehouse itself.
The data stored in a data warehouse should conform to the information model.
The source data populating a data warehouse should be verified for consistency and
accuracy.
The data warehouse should still correspond to business needs.
Ensuring the integrity and quality of data is the responsibility of both the business users and
IS.
Federated data definitions for the data stored in the data warehouse database.
Aliases that can be used to reference the data.
Data structures.
Systems where the original data is found, including the format of the original data.
Processes used to extract the data from the original location.
Sources of record for the data. A source of record is an authoritative source for data, where
data in a source of record is trusted to be accurate and up-to-date. The original data and the
source of record may be the same.
If changes are made that may affect systems and users using the data, it is important to keep this
type of information in the repository.
Recommended Best Practices
The recommended best practices in this section pertain to the selection, design, and
maintenance of a repository.
Best Practice 1: Maintain a repository for every data warehouse.
The repository contains metadata, or information about the data, in the data warehouse.
The repository represents the shared understanding of the organizations data.
The repository can be built incrementally, in stages, based on data warehouse design and
implementation.
Page 17 of 103
Information Architecture
The repository should support multiple types of data elements, such as graphics.
Changes in the repository must occur before the changes to the data warehouse
environment.
The information about how the data is to be scrubbed should be saved for historical
purposes.
Best Practice 2: Ensure data entry quality is built into new and existing application systems to
reduce the risk of inaccurate or misleading data in OLTP systems and to reduce the need for
data hygiene.
Provide well-designed data-entry services that are easy to use (e.g., a GUI front end with
selection lists for standard data elements like text descriptions, product numbers, etc.).
The services should also restrict the values of common elements to conform to data hygiene
rules.
The system should be designed to reject invalid data elements and to assist the end user in
correcting the entry.
All updates to an authoritative source OLTP database should occur using the business rules
that own the data, not by direct access to the database.
Attention to detail should be recognized and rewarded.
Best Practice 3: Move to Commercial off the Shelf data hygiene software.
Over the past few years, data warehousing software products have become a commodity.
Use of these existing technologies is recommended to ensure quality and stability. Often
times these types of technologies are included with an ETL suite of tools.
Page 18 of 103
Information Architecture
Planning for data extraction and transformation should start at the same time the data
warehouse design starts.
Data extraction and transformation is an important process for populating the data in a data
warehouse and for ensuring that the data in a data warehouse is accurate.
Data extraction and transformation logic includes data conversion requirements and the flow
of data from the source operational database to the data warehouse.
Best Practice 2: Assess the source data that will populate a data warehouse for accuracy and
quality.
Select products that are capable of interacting with the metadata repository and the data
warehouse.
Metadata drives the operations of the extraction and transformation tools. If the data
warehouse repository is not supported by a vendor-supplied extraction and transformation
product, a separate metadata repository must be developed and maintained.
Information Architecture
offices that require data to be loaded in their local environment in order to meet their performance
needs. Also, there are mobile users, who carry laptop PCs, who do not have a constant
connection to the network. In both cases, when the distributed users are using a data warehouse
application, replication is needed to propagate the data warehouse data to the remote systems.
Recommended Best Practices
The following recommended best practices apply to data replication for decision support,
executive information, and OLAP systems.
Best Practice 1: Replicated data should be read-only, except where business practices clearly
allow inconsistencies.
It is easiest to manage data quality and integrity when replicated and distributed data is read
only.
Some business applications require updates to occur against the local database.
Distributed independent updates require a reconciliation process that may be quite complex.
By developing and application system in N tiers, systems can respond quickly to changes in
business needs.
Decision support and executive information systems application programs benefit from the
use of N-tier and reusable and shared components.
For more information about N-tier application programs and reusable components, refer to
the Application Architecture and Componentware chapters.
Standard 1: When accessing relational databases, use the industry standard of ANSI Standard
SQL.
When using a database access tool that uses SQL calls, do not use any vendor specific
extensions.
Page 20 of 103
Private & Confidential
Information Architecture
Standard 2: Use ODBC from any data access programs rather than vendor-specific database
access tools.
ODBC allows flexibility in programming. A database can be easily modified or relocated. If a
change is needed, the change is made to the ODBC configuration file, not to each business
intelligence program or tool.
Standard 3: Implement a server-based ODBC solution rather than a workstation-based ODBC
implementation.
A server-based ODBC solution is easier to administer. ODBC database changes and additions
are easier to manage, since updates are made to ODBC servers, not every workstation that uses
ODBC.
Standard 4: Use domain name system (DNS) names for databases that are accessible via
TCP/IP.
A DNS server provides the capability for a long or complicated TCP/IP location to be
accessed by a generic, short alphabetic name. It is basically a lookup service. It maps the
generic alphabetic DNS name to its complicated TCP/IP location. The client application
programs can be configured to use the generic names when they need to access a database
(e.g., a database can be accessed by a client by using the generic name Summary. The
DNS
server
accepts
Summary
and
translates
the
address
into
\\MIX00001\SRV1\DBASE\DATAWAR.FIL. The client then is able to access the database). If
the database location changes, the DNS configuration is changed, and no changes are
needed to each client configuration.
Page 21 of 103
Private & Confidential
Groupware Architecture
Groupware Architecture
I.
Definition
II.
III.
Principles
The following principles are provided to guide the design and selection of groupware components
that will support distributed client/server computing activities.
Content exchange, directory services, and authentication services are key infrastructure
components necessary to facilitate communication and collaboration.
Email is the communications infrastructure component within and outside the state. A
significant portion of business communications is occurring across email services.
Page 22 of 103
Private & Confidential
Groupware Architecture
Work
Document Management
Conferencing and Meetings
Calendaring and Scheduling
Electronic Mail
Distance
Any Time
Same Place
Any Time
Any Place
Same Time
Same Place
Same Time
Any Place
Time
IV.
Groupware technologies must encompass all scenarios from working the same time at the
same place to working any time from any place.
Geographical boundaries are eliminated by groupware technologies, providing
communication and real-time access to information from any location.
The efficiency and quality of a process are partially measured by the timeliness in which the
work is performed. The notion of timeliness must be qualified for each task to determine if
groupware is providing value to that process. For example, a month may be considered
acceptable for passing a specific group of documents through an organization for approval. In
contrast, a month to send email to that same group of people is unacceptable.
Technical Topics
Page 23 of 103
Private & Confidential
Groupware Architecture
Best Practice 1: Avoid proprietary formats in anticipation of document exchange with outside
users and applications.
Proprietary formats inhibit document exchange, and may create future barriers to
communication.
If proprietary formats are used, the capability must be provided to convert documents to
standard formats for content exchange. Any vendor using proprietary formats should provide
a conversion routine.
Standards
The following standards have been established for content exchange. These standards ensure
seamless processing of documents across the state, and are summarized in a table for easy
reference.
Standard 1: For non-editable documents, the standard file format is PDF. Typical application
software using this file format includes word processing, imaging systems, and World Wide
Web publishing.
Monochrome
drw
documents
or
Facsimile documents
Multimedia images
Multimedia
Word Processing
Digital Publishing
Pattern Recognition
Geographic Information
Systems
Word processing
Archival and Retrieval
Workflow
Multi-media
GIF
JPEG
Page 24 of 103
Private & Confidential
Groupware Architecture
Standard 2: For monochrome documents or drawing, the standard file format is TIFF using
CCITT/ITU Group IV compression.
Typical application software uses this file format includes word processing, archive and
retrieving, workflow, multimedia, medical systems, digital publishing, pattern recognition, and
geographic information systems.
Standard 3: For color documents, drawings, or photographs, the standard file formats are GIF
and JPEG.
Typical application software using this file format includes multimedia, word processing,
medical systems, digital publishing, and geographic information systems.
Standard 4: For facsimile documents, the standard file format is TIFF using CCITT/ITU Group
III compression.
Typical application software using this file format includes word processing, archival and
retrieval, and workflow.
Standard 5: For vector or geometric data, the standard file formats are DGN and DWG
Typical application software using this file format includes CADD and geographic information
systems.
Page 25 of 103
Private & Confidential
Groupware Architecture
Best Practice 1: Email servers should be administered and managed as a part of the strategic
infrastructure.
A properly structured email system can provide the state with a comprehensive, effective,
inexpensive, and widespread method of communication, while permitting a choice of email
clients.
Email is a valuable tool because it provides the structure for easily moving messages and
attachments in a timely manner between clients, thereby increasing workflow and
productivity.
Email service should be available at all times from any location. Time, distance, and location
should not restrict email service.
A properly structured email system can provide the state with a comprehensive, effective,
inexpensive, and widespread method of communication, while permitting a choice of email
clients.
Best Practice 3: Use a common email directory service throughout the state.
Best Practice 5: Implement security for email message transport and storage.
Private and official correspondence will require varying degrees of protection including
authentication and encryption. SMTP/MIME was created as a means of casual
communication over the Internet. It was not created to be a completely secure medium.
Protocols are currently being developed bridge the security gap.
Standards
Similar to other groupware products, email protocols and standards are still emerging. For almost
every protocol, there are several competing, non-compatible standards. If two email systems
conform to different standards to access their mail servers, errors may occur when messages are
Page 26 of 103
Private & Confidential
Groupware Architecture
sent between the two systems. Approval of new standards is slow, leading to the proliferation of
proprietary protocols and protocol extensions. Without consistent standards, a barrier in
communication is created between platforms, applications, and components. To overcome these
barriers, email gateways have been developed to integrate incompatible email systems.
Standard 1: Use Simple Mail Transport Protocol (SMTP).
Simple Mail Transport Protocol (SMTP) is the standard transport protocol for sending
messages from one MTA to another MTA over the Internet. Using MIME encoding, it enables
the transfer of text, video, multimedia, images, and audio attachments. It is the predominate
transfer protocol utilized by web browser-based email user agents.
Multi-purpose Internet Mail Extensions (MIME), a SMTP message structure, is the standard
specification for the attachment of audio, video, image, application programs, and ASCII text
messages. The content type is stored in the message header as mail extensions. When the
message is delivered, the player or application specific to the content type is opened so that
the attachment can be viewed in its native format. If the player or application is not included
with the browser, then the user must load it. Common image and video players are included
with most browsers.
The MIME standard will require standardization of certain protocols in the near future. By its
definition, MIME is transformable. Although two applications may be MIME-compliant, each
application can use a proprietary or custom set of extensions. The data associated with the
proprietary extensions may be lost in transfer. Common protocols cut down on the risk of a
loss of data occurring.
Internet Message Access Protocol version 4 (IMAP4) is the standard protocol for access to
the mail server. The user has the option of storing and manipulating messages on the mail
server, which is important for job functions that require the user to access email from several
different clients. IMAP is also ideal for situations where the user has a low speed link to the
mail server. Instead of downloading all messages to the client, IMAP allows the user to select
which specific messages to download. If a message has several MIME attachments, the user
can specify that only the text portion of the message is to be downloaded for viewing. This
practice is considerably more efficient in the event that a high-speed link is not readily
available.
Note: Options sometimes exist to configure email servers and clients without IMAP4 settings.
Email servers and clients should be implemented using IMAP4.
Lightweight Directory Access Protocol (LDAP) is the standard directory access protocol.
LDAP is based on Directory Access Protocol (DAP), an X.500 standard access protocol.
X.500 is a set of CCITT/ITU standards for electronic directory services. LDAP has been
proven to be more efficient for MUA to directory services transactions. In addition, LDAP can
be utilized to access databases other than the email directories, which will add value to other
groupware applications, such as scheduling.
Standard 5: Select an email server system that allows multiple standards-based email clients.
When an email server uses IMAP4 standard, any IMAP4-based client can access that server.
Page 27 of 103
Groupware Architecture
The C&S system must be capable of supporting multiple server platforms and client
platforms. The operating environment within the state is, and will remain, heterogeneous. The
C&S system must therefore be capable of transparently transferring schedules and meeting
information across each of the operating systems.
C&S applications are typically purchased independently by each department based on the
particular needs that the departments must satisfy. The selected applications must be
capable of exchanging schedules, notifications, and materials with the C&S applications
utilized by other departments. The user of one application must be capable of viewing a
users calendar created and stored on another application.
Best Practice 2: Select a C&S application that provides a mechanism for attaching supporting
documentation, such as meeting materials, to the notification message.
Best Practice 3: Select a C&S application that allows the user to create both public and private
notification groups and contact lists.
Public and private notification groups are lists of people and/or resources that have common
calendar and schedule needs, such as project groups or a list of conference rooms. Users
can assign selected individuals to their private groups, and administrators can assign
selected individuals to public groups. When a group name is entered as a participant,
available times can be selected based on the groups information, and a notification message
is forwarded to all individuals included in that group. This feature streamlines the use of C&S
applications, making them more efficient.
Page 28 of 103
Private & Confidential
Groupware Architecture
Best Practice 4: Select a C&S application that enables task and resource management.
In addition to people, the user must have the ability to schedule facilities and equipment. For
example, the user should be able to reserve a meeting room and an overhead projector
through the C&S application.
The C&S application should be capable of tracking tasks (e.g., To Do lists that automatically
send reminder messages for upcoming deliverables).
Best Practice 5: Select a C&S application that allows remote and proxy access.
The user should be capable of disconnecting from the network and still maintain access to
personal and shared calendars. Any updates to the calendars or schedule notifications made
while the user is offline should be uploaded and synchronized at the time that the user
reconnects to network.
Incoming schedule notifications should be held by the C&S server until the user reconnects to
the network at which time the messages are synchronized with the users local calendar.
Proxy access enables a C&S user to allow another authorized user or users to administer
their personal calendar. This function may be limited to viewing, or allow full maintenance
capabilities.
Best Practice 6: Select a C&S application that can be accessed through a web front-end.
Both Intranets and Internets are accessible by anyone within the organization via a webbrowser. Web enabled C&S applications allow users access to C&S information for anyone,
anywhere in the state.
Page 29 of 103
Private & Confidential
Groupware Architecture
Best Practice 1: Evaluate potential requirements over a longer term basis and implement a
platform that can be used to develop document-enabled applications and provide a uniform
approach to document storage and access.
Use the standards guidelines to assure the implementation of scalable, open systems.
Adhere to APIs and integration standards being advanced by the Association for Information
and Image Management.
Best Practice 3: Select EDM and workflow tools that comply with AIIM open standards, are
platform independent, and can be shown to be inter-operable with similar tools and other
components of the statewide technical architecture.
Selecting application components that adhere to industry standards is important for flexibility
and adaptability.
Products must support multiple server, workstation, and application platforms.
Workflow components should trigger or send some message-based notification when human
intervention is needed (using middleware, email, etc.) Partial automation of the office
environment will cause confusion as to which activities need human initiative and which
activities are being managed by the workflow system. This confusion will cause inefficiencies
and leave a wider margin of error in work to be performed.
Workflow systems should provide a standard interface to other workflow systems for the
purpose of passing and processing work items between business units and processes.
Standards
As the state progresses with the development of a departmental and statewide document
management infrastructure, and universal access to information, there are many obstacles to
overcome related to the inter-operability between departmental systems and their interaction with
an evolving enterprise level locator service. In the standards area departments planning for EDM
systems and services needs to take into account three general sets of guidelines.
Existing and evolving standards and guidelines being advocated by public institutions and
private industry through the Association for Information and Image Management International
(AIIM).
Other standards and guidelines put forth by related parts of the Statewide Technical
Architecture, especially as they relate to the development of document and/or business
process-centric applications in an n-tier architecture.
There is no limit to the creativity and innovation occurring in the development of solutions to the
problems of document management, workflow, and universal access. The framework embodied
by these standards is intended to be moving users and developers toward the goals described
previously.
Standard 1: Implement document management systems and components that conform to the
Document Management Alliance specifications (DMA 1.0 and ODMA 2.0).
Groupware Architecture
The Document Management Alliance (DMA), is a task force of AIIM. DMA conforming
products will support open design for user interfaces, workstations, network operating
systems and servers. The DMA provides a framework for vendors to deliver products that
provide query services (simple transparent access from every desktop to information
anywhere on the network), and library services (including check-in and checkout, version
control, security, and accountability). The DMA is working with the Open Document
Management API (ODMA) group which specifies the common application program interfaces,
and high level call interfaces that enable other client applications (such as MS Office) to work
seamlessly with DMA compliant document management systems.
standards
programs,
refer
to
the
Web
site:
Standard 2: Implement workflow systems that conform to the interface specifications of the
Workflow Management Coalition (WfMC).
WfMC is another working group of AIIM and is closely aligned with the work of the DMA. As
automated workflow systems continue to evolve, the complexities associated with a common
approach to process definition, process repositories, object manipulation and transport, and user
interfaces are enormous. The Workflow Management Coalition (WfMC) has proposed a
framework for the establishment of workflow standards. This framework includes five categories
of interoperability and communication standards that will allow multiple workflow products to
coexist and inter-operate within a network environment. This framework is contained within a
Reference Model for workflow management systems that includes five interface specifications.
The model includes the following:
Standard 3: Use Adobe Acrobat Portable Document Format (PDF) for Non-editable Electronic
Documents.
All documents in final form and prepared for distribution and publishing with no intention for
further modification must be stored and delivered in Adobe .PDF format.
Standard 4: Ensure hardware/software and image file compatibility using TWAIN, ISIS, and
TIFF standards.
For typical business document imaging applications, software that controls the operation of
the scanner (and some other recognition peripherals) is provided. Not all scanner hardware
and scan software are compatible. The industry standards to adhere to are TWAIN and more
recently ISIS (Image and Scanner Interface Specification). These are API standards that
provide low level integration facilitating the control of the peripherals from many common user
Page 31 of 103
Groupware Architecture
applications. For specialized applications (e.g. hand held devices) other standards
requirements need to be investigated.
The scanned images of typical business documents should be committed to storage in
Tagged Image File Format (TIFF) Version 6.0 using CCITT/ITU Group III or IV compression.
Organizations planning imaging applications should investigate and demonstrate that any
product selected is capable of exporting images in a format that they can be reused. Images
that can not be shared are a wasted investment and could result in the loss of critical data.
Avoid new deployment or migrate away from proprietary image file formats. The current
technology direction for image file formats is TWAIN. The emerging technology file format is
ISIS.
Standard 5: Select magnetic storage subsystems. Select optical storage subsystems based
on smaller standard form factors.
Typical electronic documents, created with office automation suites, will reside on industry
standard magnetic disk that is server or network attached. This will generally be transparent
to the users of an EDMS. The images of scanned paper documents might also be stored on
standard network attached magnetic disk. Magnetic storage will always provide the most
performance in the speed of retrieval, and magnetic disk is increasingly cost competitive with
optical disk storage. When selecting any magnetic storage solution, adhere to other parts of
the STA that provide the standards for these types of systems.
Very large document collections (usually image applications) will probably require optical
storage subsystems (many are proprietary). Where there is a requirement for the permanent
storage of unalterable documents, optical is chosen in the form of Write Once Read Many
(WORM) disks. These types of systems generally involve special software that is used to
manage the storage and movement of documents from optical to magnetic when documents
are requested by users. Optical disks may be mounted in single standalone drive units or
they may be loaded into various sizes of juke boxes. Software handles the retrieval and
loading of specific disks in response to user requests. Typical EDMS systems today will use a
5 form factor and will be WORM or Compact Disk type formats. Larger disks are available
for specialized applications and are generally proprietary.
Avoid new deployment or migrate away from proprietary or large format optical storage
subsystems. The current technology direction is WORM and various types of compact disc in
5 format. The emerging technology is magneto Optical and DVD.
Standard 6: Use eXtensible Markup Language (XML 1.0) when capturing or authoring
document content that requires further automated processing by other information systems
and Web based clients using standard XML enabled browsers.
Page 32 of 103
Private & Confidential
Componentware Architecture
Componentware Architecture
I.
Definition
II.
Components are program modules that provide a complete package of business functionality.
Shared components must be designed for portability across platforms.
Components within an application system can be developed in any supported language, with any
development tool appropriate for the particular tier where they are deployed. Monolithic
applications perform comprehensive business functions and operate independently from other
applications. Making changes to a monolithic system is a major undertaking because changes in
one area often cause problems in other areas.
III.
Principles
These principles provide guidelines for the design or purchase of application components that
support distributed, client/server, and adaptive computing across the state.
Sharing components across the enterprise greatly increases the ability of the system to meet
the changing needs of the business.
The use of proven components enhances the accuracy of information processing.
Page 33 of 103
Private & Confidential
Componentware Architecture
IV.
Technical Topics
Page 34 of 103
Private & Confidential
Componentware Architecture
Classify the business requirements by service type (e.g., application, interface, support, or
core).
Search the repository for reusable components that support the business or functional
requirements.
Analyze candidate components to ensure they fully meet the requirements.
Incorporate the selected components into the new or re-engineered application using
standard IDLs.
Harvest new components from new or existing applications that have not been
componentized yet. Placing the new component information into the repository.
Incorporate the reuse methodology into the system development life cycle.
To successfully implement the Componentware Architecture, the Network and Middleware
Architecture must be in place.
Best Practice 3: Establish a repository for maintaining the information about available
reusable components.
The repository provides a place to store documentation about the component APIs.
The repository should be made available to all application developers as a tool for performing
their jobs.
A published API defines the public interface for a component or service. The API is how other
applications will communicate with the component. Documentation should include input and
output parameters, which parameters are required, which parameters are optional, and the
lengths and types of the parameters.
Page 35 of 103
Componentware Architecture
The API should be entered into the component repository that is available to all application
developers.
Best Practice 5: Harvest components from existing applications to initially build the
component repository.
Standards
The standards in this section pertain to component reuse.
Standard 1: No vendor proprietary API calls for infrastructure security services. Use Generic
Security Services-API (GSS-API) or Common Data Security Architecture (CDSA) compliant API
calls and products.
Applications requiring security services prior to CDSA products or services being available
can use the GSS-API.
The GSS-API is an Internet Engineering Task Force (IETF) standard (RFC 2748, released in
January 2000, obsoletes RFC 1508 and RFC 2078) and supports a range of security services
such as authentication, integrity, and confidentiality.
It allows for plug-ability of different security mechanisms without changing the application
layer.
It is transport independent, which means it can be used with any underlying network protocol.
Applications using GSS-API can be retrofit to a CDSA foundation without major modifications,
therefore providing an interim step to CDSA based services.
Components must be designed and developed with the understanding that the process that
invokes it may or may not be developed in the same language or in the same environment.
A component should be callable from any supported language on any supported platform.
Page 36 of 103
Private & Confidential
Componentware Architecture
Standards
These standards in this section pertain to component services.
Standard 1: Custom developed application components must be written in a portable,
platform-independent language, such as C, C++, or Java.
Application components written in a portable language are easier to move from one platform
to another because they require fewer modifications to conform to the new host. This
portability allows an application to be more adaptive to changes in platform technology.
The CDSA version 2.0 architecture is an Open Group specification for providing security
services in a layered architecture and managed by a Common Security Services Manager
(CSSM). CDSA provides a management framework necessary for integrating security
implementations. Version 2.0 of the specification is a cross-platform architecture, which
includes a testing suite for inter-operability testing.
A wide range of vendors has announced support for the specification and products for a
broad set of platforms can be expected.
Security protocols such as SSL, S/MIME, IPSec can all be built from the Common Data
Security Architecture base.
Object oriented programming starts with the definition of objects. Therefore analysis and
design are critical.
Object-oriented design and development is well understood by many developers and the
software industry often provides solutions based on objects rather than APIs.
EJB together with Servlets hide most of the required infrastructure service requirements
programming for web based applications. Where sharing of services is desirable,
departments can offload the burden of such programming and can focus on the business
logic rather than communication code.
Standards
The standards in this section pertain to object-oriented components.
Page 37 of 103
Private & Confidential
Componentware Architecture
Standard 1: Purchased applications must be CORBA 2.0 or later and IIOP (Internet Inter-ORB
protocol) compliant.
CORBA and IIOP standards are open standards devised for platform independence.
Standard 2: Build or purchase Enterprise solutions on an Enterprise Java Bean and servlet
model. Application servers should be compliant with EJB 1.1 or better.
Enterprise solutions benefit from reduced requirements to code underlying services and can
focus on business logic.
Vendors provide solutions based on an EJB model. These solutions can be purchased and
used without customization.
Standard 3: Avoid OLE/DCOM and the Windows DNA object model for applications with
Enterprise or strategic implications.
OLE/DCOM standards do not scale well and run only on Windows platforms.
OLE/DCOM applications are not easily portable or integrated into enterprise-wide solutions.
Page 38 of 103
Private & Confidential
Data Architecture
Data Architecture
I.
Definition
II.
Data and information are extremely valuable assets of the state. Data architecture establishes an
infrastructure for providing access to high quality, consistent data wherever and whenever it is
needed. This infrastructure is a prerequisite for fulfilling the requirement for data to be easily
accessible and understandable by authorized end users and applications statewide.
III.
Principles
The following principles apply to the enterprise Data Architecture. Enterprise principles are
relevant to both statewide and department-wide data.
Design the data infrastructure to easily accommodate changes in the data model and
database technology. The data infrastructure is a crucial component of establishing an overall
adaptive architecture.
An adaptive data infrastructure provides extensibility in adding new functionality and
facilitates vendor independence.
Separate data sources isolate OLTP systems, which perform mission critical business
processing, from large ad hoc queries and online analytical data processing. If the data
Page 39 of 103
Private & Confidential
IV.
Data Architecture
sources are not separate, ad hoc queries and direct access of data for OLAP systems can
adversely impact online transactional processing.
Data design is adapted for optimal performance for each type of application, OLTP or OLAP.
For optimal performance, OLTP and OLAP may require different database designs. OLAP
typically includes complex operations involving time series, dimensional, and trend analysis,
which do not perform well with relational database technology alone (e.g., sometimes other
methods of data storage are needed to support OLAP, such as multi-dimensional databases
or flat files).
Technical Topics
Page 40 of 103
Private & Confidential
Data Architecture
Data Architecture
Metadata - Sample
Data Element
Attribute Name
Element
Definition
Field
Length
Data Element
Type
Example
Remarks
Unique number for
each person
SSID
Social security
identification number
12
Number
First Name
20
Varchar
Sachin
Middle Name
15
Varchar
Ramesh
Surname
Persons surname
15
Varchar
Tendulkar
Father / Husbands
First Name
Father / Husbands
Middle Name
Father / Husbands
surname
Father / Husbands
first name
Father / Husbands
middle name
Father / Husbands
surname
20
Varchar
Ramesh
15
Varchar
Nandan
15
Varchar
Tendulkar
Date of Birth
Date
12-09-1965
In DD-MM-CCYY
format
Sex
Varchar
Caste Category
Caste category
of the person
Varchar
01
SC/ST/BC/Others etc.
123-456-789-123
International
convention (Banks,
colleges, etc)
Election commission
in India has the same
convention
There are some
examples given in
the end
Data Architecture
Metadata - Sample
Sample names for data entry Probable convention
First Name
Middle Name
Surname
Krishna Reddy VV
Manoj
Leander
Sachin
Dipti
Gandhi LN
Prasad SRKS
Abdul Aziz
Srinivasa Rao
-Kumar
-Ramesh
Dilip
-----
Kurapati
Bajpai
Peas
Tendulkar
Bapat
Challasani
Mullapudi
Mohd
Palakodeti
Page 41 of 103
Private & Confidential
Data Architecture
Data Architecture
Metadata - Sample
Data Element
Attribute Name
Religion
Address1
Address2
Element
Definition
Religion Code
Persons address
First line
Persons address
second line
Field
Length
Data Element
Type
20
Varchar
50
Varchar
50
Varchar
Example
Hindu
Remarks
Codified field with
name displayed
District
District code
Varchar
02
Division
Division Code
Varchar
0103
Mandal
Mandal Code
Varchar
1100
Varchar
25026
Municipality
Mandal Code
Varchar
1155
Panchayat
Panchayat Code
Varchar
22652
Habitat
Habitat Code
Varchar
Data Architecture
Metadata - Sample
Data Element
Attribute Name
Element
Definition
Field
Length
Data Element
Type
Example
Varchar
Marital Status
Marital Status
Phone No.
10
Number
Fax No.
10
Number
040-4058364
040-4058364
E-Mail ID
Electronic mail id
50
Varchar
Ramachandra.sarma@
rediff.com
PAN No.
10
Number
ABTPR2507M
Survey No.
30
Varchar
12/24/345/
496-A1
Registration No.
Owned vehicle
registration no.
10
Varchar
AP37 AX 8420
Passport Number
Varchar
A1155679
Varchar
AP37/4235/
BVRM/99
20
Remarks
Y / N Flag
STD code followed by
ph.one number
STD code followed by
ph.one number
Electronic mail id
Number as allotted by
Income Tax dept.
Survey no. where
property is located
Number as allotted
by RTA
Number as issued by
Passport authority
Number as allotted
by Licensing authority
Page 42 of 103
Private & Confidential
Data Architecture
Storing data element definitions in a central repository incrementally builds the enterprise
data model.
The repository must be actively maintained (e.g., changes to metadata occur in the repository
before the changes occur in operational applications).
The repository serves as a centralized data administration tool and helps promote data
reusability, reliability, and sharing across the enterprise.
Best Practice 2: When designing or modifying a database, review the Centralised Metadata
Repository for existing standard and proposed data elements before implementing a new
database to ensure data elements are defined according to CMR standards.
Design reviews are essential to ensure that shared statewide data is defined consistently
across all applications. Design reviews also determine whether data that already exists is
consistently defined and not redundantly stored.
Design reviews should document the following:
Where is this application getting its data?
What other applications are getting data from this application?
Is data used by this application defined consistently with statewide definitions? If not, is
there a plan to define the data according to enterprise definitions?
A design review evaluates the data requirements of a project and identifies the following:
A data requirement that can be solved by using existing centralised metadata element.
Data not already identified as centralised metadata must be proposed as an interdepartment or statewide standard to the Metadata Element Review Team to become
centralised metadata.
Access is available for application development projects to reference the CMR in order to
actively research data requirements. Review the existing standard and proposed data
elements in the CMR before implementing a new database to ensure data elements are
defined according to standards.
Key information about data is stored in the systems that are already implemented in the state.
If possible, evaluate existing systems to propose statewide and department data elements.
Best Practice 3: Use the CMR and the Metadata Element Review Team to create centralised
definitions of enterprise level data and encourage the sharing of data across departments.
Data used by multiple business units must be commonly understood and consistently
referenced by all business users. Enterprise sharing of data can only be achieved by creating
centralised definitions.
Centralised definitions of data emerge through the context of projects. An enterprise model
evolves over time through ongoing projects.
In order to create centralised definitions of data, cooperation is needed among the business
data owners.
Centralized management of distributed enterprise-level data is provided through the states
Centralised Metadata Repository. This repository is available through the Internet.
Page 43 of 103
Private & Confidential
Data Architecture
Authoritative business sources for centralised metadata must be identified, documented, and
actively maintained in the repository. Authoritative business sources are the business units
responsible for the accuracy of the data stored.
A source of record is an authoritative source for data. Data in a source of record is trusted to
be accurate and up-to-date. All other data stores should synchronize to the source of record.
The data in record sources must be actively managed and the data model should be verified
by data administrators. Tools and quality control techniques must be applied to the contents
of the data stores themselves, in order to ensure the quality of the data.
Each application must identify data sources for all data that it does not originally capture. The
application capturing the original data is the authoritative source, and is responsible for the
quality of the data. All application data models for ongoing projects should be reviewed to
ensure that data existing in authoritative systems is reused and not redundantly stored.
Standards
Standard 1: Custom systems must comply with CMR standard data element definitions.
New databases belonging to custom systems must comply with CMR element definitions.
The Metadata Element Review Team will review the data elements to determine if the
elements conform to existing standards.
Any new potential data element standards must be proposed and reviewed for approval as a
state standard.
If the data element definition cannot be customized to conform to existing standards, a waiver
must be requested.
If an off-the-shelf system has data formats that can be modified, the data elements should be
adapted to conform to the standard data requirements.
If the data element definition cannot be customized to conform to existing standards, the
vendor must provide conversion routines to conform to the CMR metadata exchange
standards.
Standard 3: Use Centralised Metadata Exchange Standards when exchanging data across
departments.
If data needs to be exchanged across department boundaries and the data is physically
stored differently, then the data must be exchanged through the exchange standard as
specified in the CMR.
Page 44 of 103
Private & Confidential
Data Architecture
The third normal form is the most commonly recommended form for the ER model.
In some cases, a denormalized database can perform faster as there can be fewer joins, or
reduced access to multiple tables. This process saves both physical and logical input and
output requirements.
In the design phase, consider the values that may be input into a field. These values or
domains should be normalized so that data is consistent across records or instances. For
example, using consistent values for gender or address information.
Use look-up tables and automate data entry for column or attribute domain values to restrict
what is entered in a column.
Limit the number of indexes on databases that will be experiencing significant insert and
update activity. When an insert is performed, not only is the record updated, but all the
indexes are updated as well.
Increase the number of indexes on databases where importance lies in retrieval time.
Indexes can increase performance on retrieval time.
Before creating a database, indexes, or data access programs, verify that all relationships
have been documented.
Best Practice 5: Design the data model to allow for growth and/or change.
Design data models to accommodate any future changes, including growth and changes in
business requirements or database technologies.
Data models store a wealth of department and statewide information and must be archived
and protected.
Data models should be catalogued with the departments project documentation and used to
facilitate future revisions.
Best Practice 7: Each department should standardize on a common data-modeling tool for
designing and maintaining all new database instances.
Department Technical Architectures specify each departments common data modeling tool.
Page 45 of 103
Private & Confidential
Data Architecture
A data model ensures that data is defined accurately so it is used in the manner intended by
both end users and remote applications.
Data modeling tools can evaluate an existing database structure and reverse engineer a data
model. The reverse engineered data model can be used to capture valuable information
about the existing database.
Typically, workstations and servers are used for multiple applications and require connectivity
to multiple databases. If administration for data access middleware is provided by central IT
staff, any changes that are required are more easily managed and executed
Support costs and efforts to support data access middleware are reduced.
To differentiate their database from other vendors, many database vendors have
implemented special extensions beyond the SQL-compliant commands. Although sometimes
these extensions may be useful for a particular function, they are not recommended.
Standards
The standards in this section pertain to data access middleware.
Standard 1: Use OLE DB or JDBC database access middleware when accessing a database.
Use OLE DB or JDBC to access a database instead of vendor specific database middleware.
OLE DB and JDBC allow flexibility in programming. A database can be easily modified or
relocated. If a change is needed, the change is made to the OLE DB or JDBC configurations,
not to each data access program or tool.
These technologies are widely supported by the industry and make an application more
adaptable to changes in database or other technology requirements.
Page 46 of 103
Private & Confidential
Data Architecture
Standard 2: Implement a server-based OLE DB or JDBC solution as opposed to a workstationbased OLE DB, ODBC, or JDBC implementation.
A server-based solution is easier to administer. Database changes and additions are easier
to manage, since updates are made to database middleware servers, not every workstation
that requires access.
Standard 3: Use domain name system (DNS) alias names when accessing databases through
OLE DB and JDBC.
If the database location changes or if the server name changes, the DNS configuration is
changed, and no changes are needed to each client configuration.
Business requirements change frequently. The data infrastructure and design must be
adaptive and allow for changes to be easily implemented.
Technology changes are fast emerging. The infrastructure must allow for replacement of the
database technology if necessary.
High-volume transaction data that is shared across locations and that needs to be current for
all locations must be centralized so all locations have access to the same data source
Replicating frequent updates to distributed databases increases systems complexity and
network traffic.
Data must be centralized when one or more of the following criteria occur:
Many users need access to latest data (i.e., OLTP systems).
Page 47 of 103
Data Architecture
Best Practice 3: Design databases to be modular, business driven and aligned with application
services, not monolithic.
Aligning data with the application service facilitates changes in business processes. Only the
data associated with a particular business process is potentially affected when a change is
needed, not all the data associated with an entire application. It also increases performance
for backup and recovery and provides higher reliability, availability, and scalability.
By modularizing data, this practice provides better performance for backup and recovery,
higher reliability, availability, and scalability, and better transaction performance due to
parallelism (e.g., a complex request can be broken down and be processed by multiple
databases at the same time).
Very large databases (VLDBs) typically use a terabyte or more of storage. It is recommended
that VLDBs be partitioned based on the appropriate business elements to improve application
and database performance. VLDB partitioning can enable more efficient backup and recovery
capabilities (e.g., it is more efficient to backup five 10 million row tables simultaneously than it
is to backup one 500 million row table).
In order to align data with application services, the following items need to be defined:
Business processes.
Data required to service the business processes.
Business units responsible for providing the business process.
Access to the data, and the know-how to use the data, by other business units or
applications.
Best Practice 4: Minimize the replication of data within operational applications by replicating
only stable data when necessary and based on business requirements.
It is better to maintain only one version of data whenever possible, particularly for mission
critical OLTP systems.
Replication must not be used unless it is required for performance or decision support.
A replication infrastructure is simpler to design for stable data. If replicated data is updated
frequently, it is much more difficult to design and maintain a replication infrastructure.
Replication may be appropriate when there are users in different locations needing similar
data that does not need to be current 24 hours a day and a central source database is not a
possible solution.
Specific application requirements for data availability, recoverability, and freshness (near real
time, 24 hours old, etc.) must be identified.
Best Practice 5: Design the data access infrastructure to support the transparency of the
location and access of data by each application.
This means designing an N-tier architecture where all data access is managed through a
middle tier. This design makes databases easy to relocate, restructure, or re-platform the
back end services with minimal disruption to the applications that use them. It is essential for
adaptive systems.
A client should not send SQL requests directly to a server. Instead of using SQL code, the
client should communicate with the database through data access rules. The application
receives a request from a client and sends a message to the data access rule. The data
Page 48 of 103
Data Architecture
access rule sends an SQL call to the database. With this method, the client does not send
SQL to the server, it sends a request for work.
Best Practice 6: Design for data to be accessed only by the programs and business rules
owning the data, never by direct access to the database.
This practice ensures security, data integrity and accurate interpretation of the data and
allows for adaptability to changes in business needs.
Best Practice 7: For data quality management, implement tools, methods, processes and
policies to provide high-level data accuracy and consistency across distributed platforms.
Both business users and Information Technology (IT) staff are responsible for data accuracy
and consistency. Policies and procedures must be established to ensure the accuracy of
data.
IT staff is responsible for and must provide security mechanisms to safeguard all data under
IT control. The business users must determine functional security requirements, while the
physical security must be provided by IT.
Applied systems management provides safeguards against data loss and corruption and
provides the means of recovering data after system failures. This implies that effective
backup and recovery systems are imperative and that data can be recovered in a timely basis
regardless of the cause of loss.
To satisfy service-level requirements, if the data is not too volatile, data replication can be
used. If the data is extremely volatile, using replicas must be avoided. Additional
requirements may include providing redundancy for extra bandwidth for communications
volume and for availability in the event of a disaster. For critical functions, plan for
survivability under both normal operations and degraded operations.
It would be ideal to record the flow of data across systems, even if it is built incrementally
starting with existing application development projects.
Best Practice 8: Optimize the physical database design to support an optimal total
performance solution.
As with all application and data access design, performance is always a factor to consider.
However, database performance is only part of the total solution and must be evaluated in
conjunction with other components that impact performance, such as network and application.
When implementing data access, several practices can help performance, including:
Limit the number of indexes in a database. When a record update occurs, not only the record
is updated, but all the indexes are updated as well.
Limit ad hoc data access. End user ad hoc access can impact the performance of the
database.
Limit the number of rows returned in a query. In OLTP, most users normally work with only a
single row at a time or a few rows displayed in a grid, list or combo box. If a user will only be
working with a handful, there is no reason to return all the rows in a table.
Return only the columns needed. Provide an explicit column list instead of a SELECT *
query.
Limit the number of joins. Complex multi-table joins have negative performance ramifications.
Avoid sorts. Sorts can be slow, especially if sorting large amounts of data. If sorting is
required, sort on indexed fields.
Limit the rows used for pick lists, combo boxes, or lookup tables. If a large list is necessary,
find an alternate method to provide the list.
Page 49 of 103
Private & Confidential
Data Architecture
A typical n-tier application has numerous business rules. The data access logic for these
business rules should be shared through a minimal number of reusable data access rules.
Due to the commonality of database queries, many similar queries can execute using a
single, properly planned data access routine.
Portability to another database platform or vendor is simplified by having a fewer data access
rules.
Best Practice 10: Use ANSI-Standard SQL programming language to access a database.
Data access to relational data stores must be through ANSI-standard SQL programming
language access, not proprietary SQL extensions.
Best Practice 11: Implement a minimal amount of data access rules stored in the database as
stored procedures and triggers to avoid vendor lock-in.
Code data access rules into a data access service. When implemented through the Andhra
Pradesh Service Broker (APSB), these services are callable by multiple applications. If a
database changes, there is minimal impact to the calling applications since the API should
not change.
Stored procedures and triggers are specific to the database vendor and are more difficult to
migrate to a new database if required.
Database triggers must only be used to support referential integrity.
Other technologies such as object transaction monitor (OTM) can be used to negate the
impact of executing dynamic SQL.
Best Practice 12: Use the State Service Broker for intra-department and intra-application data
sharing.
The department owning the data is responsible for writing the shared service to access the
data. This ensures data integrity and proper data interpretation.
The department requesting the data is responsible for writing the request to retrieve shared
data according to the shared service specifications.
Best Practice 13: Use the states interface engine for data sharing of legacy platform data or
other data where the application source code cannot be modified or interfaced.
Some legacy systems do not have an application program interface (API) and there is no
access to the source code. When requiring data access to one of these systems, use the
state's interface engine.
The states interface engine can be used in instances where the source code is unable to be
modified or the data layouts are unavailable. It is an unobtrusive interface to accomplish data
sharing.
Use of database gateway or database-specific middleware must be avoided.
For more information about the interface engine, refer to the Integration Architecture.
Standards
The standards in this section pertain to Data Access Implementation.
Page 50 of 103
Private & Confidential
Data Architecture
Standard 1: Use the State Service Broker (APSB) for inter-department data sharing.
Service Broker is the standard for inter-department data sharing. Inter-department services
deployed using APSB can be easily leveraged by other authorized applications.
The department owning the data is responsible for writing the shared service to access the
data. This ensures data integrity and proper data interpretation.
The department requesting the data is responsible for writing the request to retrieve shared
data according to the shared service specifications.
Standard 2: Use the industry standard of ANSI Standard SQL when accessing relational
databases.
When using a database access tool that uses SQL calls, do not use any vendor specific
extensions.
When a generic, protected user account is used, each individual user account is not defined
to the database, so end users are unable to gain ad hoc access to the data. Their only
access should be through the application.
The individual user account is only defined at the application level, and does not have to be
maintained in more than one place.
Implementing generic users makes applications scaleable since each process is not tied to a
specific user.
The generic user account and password used to access data in the back end must not be
protected and not accessible to end users.
Best Practice 2: Implement data security to allow for changes in technology and business
needs.
Data Architecture
Confidential or private data must not be stored on a laptop without password protection or
encryption. Laptops are vulnerable to loss of data through hackers, thieves, and accidents.
Sensitive data must be secured on a database server with proper policies and procedures in
place to protect the data.
Ensure that passwords are encrypted both inside application executables and across the
transport layer.
Password and data encryption in databases and laptops can be provided by third party
products.
A backup and recovery plan for databases and laptops must be in place.
Best Practice 4: Provide measures for laptops to backup their data, like zip drives, etc.
Only non-sensitive data should be stored on a laptop. If possible, the authoritative source
must be on a server, and data should be replicated to the laptop.
When data is stored on a laptop, provide easy-to-use backup facilities. Implement policies to
ensure and automate backup.
Best Practice 5: Record information about users and their connections as they update and
delete data. Auditing can determine who updated a record and their connection data.
The information that can be captured by the application includes:
The user account the user logged in with.
The TCP/IP address the connected users workstation.
The certificate information (if using certificates) about that user.
The old values that were stored in the record(s) before the modification.
The new values that were input to the record(s).
Best Practice 6: Implement transaction logging so recovery of original data is possible and
protect the transaction log.
Transaction logging records activity on the database and can be used to roll back a
transaction.
Protect the transaction log through access control and backup. Only the database should be
writing to the transaction log. All other access should be read only.
The transaction log should be located on a separate physical disk if possible. If not possible,
use RAID to protect the integrity of the log file.
Best Practice 7: Implement security scanning and intrusion detection at the database level if
possible.
Scan the database and database server for potential weaknesses before they become a
problem. Implement any recommendations of the security management tool. For example, a
tool may advise to disable FTP services on a database server.
Page 52 of 103
Private & Confidential
Data Architecture
Monitor the database for possible intrusions. For example, monitor and alert when multiple
invalid login attempts occur. Intrusion detection protects the database server from attacks
from both sides of the firewall (e.g., internal network, WAN, or Internet).
Audit logins, user account creation, and failed login attempts.
Best Practice 8: Ensure data integrity by securing data movement or data transport.
When high impact, sensitive data is transported through the LAN, WAN, or Internet, ensure
that the data is encrypted and protected from alterations. This can be accomplished through
Secured Socket Layers (SSL) or Virtual Private Network (VPN).
Other types of data must be encrypted and protected if there is a risk of the data being
altered.
Best Practice 9: Protect database servers from hardware failures and physical OS attacks.
Best Practice 10: Protect source code in data access rules, particularly if it contains password
information.
On the back end, an application needs to store account and password information in order to
authenticate to a database or other application service. Protect the source code from
unauthorized viewing.
Store passwords in an encrypted format when possible.
Best Practice 11: Do not store credit card numbers in the database for non-recurring charges
or infrequent recurring charges. Store authorization numbers and discard credit card numbers
after use.
For infrequent recurring charges (for example an annual fee), or non-recurring charges (for
example a one-time fee), storing credit card numbers and expiration dates in a database,
even encrypted, can present an unjustifiable risk for the state.
A credit card number is only necessary to request authorization. Keep the credit card number
only until authorization is complete, then discard. The authorization number can be used to
track activity and verify authorization.
Best Practice 12: Protect and encrypt credit card numbers when storing for recurring charges.
Store personal verification information independently.
Certain business requirements, such as frequent recurring charges, may require credit card
numbers to be stored in a database.
When it is absolutely necessary to store credit card numbers, encrypt the credit card number
in the database. To further protect the credit card, store personal verification information,
such as name and address, in a separate database from credit card information. Use
different user accounts for each database connection.
Standards
The standards in this section pertain to Data Security.
Page 53 of 103
Private & Confidential
Data Architecture
System administrator accounts have full access to all databases in a database server.
Hackers often attempt a login to a system administrator account using a default password. As
soon as a database is set up, change all default passwords.
Page 54 of 103
Private & Confidential
Definition
II.
III.
Principles
The following principles guide decisions on the use of application communication middleware.
The tiers of a distributed application, which often run on different hardware and operating
systems, must communicate.
Application communication middleware enables both inter- and intra-application
communications.
RPCs are the easiest transition for mainframe programmers. An RPC is simply a subroutine
even though it is running a business rule on the network.
Page 55 of 103
RPCs are a mature technology. They are already bundled with many operating systems and
databases.
Distributed transaction monitors are becoming less and less a requirement as high speed
networks and messaging subsystems are deployed.
The need for a transaction monitor can be eliminated or reduced by using features of
message oriented middleware, combined with application design.
A broker provides access to common services that can be reused and shared, thus reducing
development costs. See Componentware Architecture.
The state can reduce the resources spent on developing and maintaining islands of
applications, which include redundant code. Application developers can focus on new work
rather than rework.
New applications will be a combination of new business rules and common shared business
rules. Since part of the application is pre-written and pre-tested, delivery of the total
application should result more quickly.
In the long term, use of middleware by many applications is of more strategic importance
than any one application development tool. Middleware selection should drive the choice of
application development tools, not vice versa.
A range of communication methods is available through middleware. A combination of
products may be required.
De-coupling the middleware from the application development tool provides more flexibility in
changing development tools in the future. For example, integrated CASE tools often provide
third-party message oriented middleware as well as their own, proprietary message oriented
middleware.
When given the choice of proprietary middleware versus third party middleware, select the
third party middleware option. For instance, message oriented middleware provided by the
Page 56 of 103
Private & Confidential
integrated CASE tool vendor limits flexibility and links to a specific vendor and product
strategy more closely.
If message oriented middleware is linked directly to a specific development package, then
there is the risk of limited usefulness with other applications that are not developed with the
same tool.
IV.
APIs and IDL for components and services must be documented so that developers know
where they are and how to use them.
Technical Topics
Best Practice 2: Use Remote Procedure Calls (RPCs) when message oriented middleware is
not available.
Standards
The standards in this section pertain to application communication middleware types.
Page 57 of 103
Private & Confidential
Standard 1: There is no Remote Procedure Call (RPC) standard. Use the Andhra Pradesh
1
Service Broker (APSB) for inter-application communication.
Even with an RPC that is endorsed by a vendor neutral party, such as The Open Group,
there is no standard RPC.
RPCs are available from different vendors, such as The Open Groups DCE RPC, Sun
Microsystems
ONC/RPC, and Microsofts RPC.
Each vendors version has a different application programming interface and they do not
inter-operate with one another.
Standard 2: There is no Message Oriented Middleware (MOM) standard. Use the state of
Andhra Pradeshs service broker for inter-application communication.
At present, all message oriented middleware is proprietary. Products from different vendors
have different application programming interfaces, which do not inter-operate with one
another.
Standard 3: There is no distributed transaction processing (TP) monitor standard. Use the
state of Andhra Pradeshs service broker for inter-application communication.
The applications coordinated by a transaction monitor will run on different platforms with access
to different databases and resource managers.
The applications are often developed using different tools and have no knowledge of one another.
Industry standards specify how a TP monitor interfaces to resource managers, other TP monitors,
and its clients.
X/Open XA specification defines specifications for two-phase commits that work with
distributed databases.
X/Open TX standard defines transactions.
X/Open X/ATMI provides a standard transaction management interface.
Service brokers are a proven technology. However, there are no industry-standard service broker
products available. Successful implementations of service brokers usually require the interface to
be developed specifically for the organization. Like other organizations `using a service oriented
architecture, the state must invest in the development and maintenance of the service brokers
generic interface.
Since object technology promises the greatest gains in productivity and adaptability, the state will
ultimately transition software development to a fully object-oriented approach. Requests for
service will be conveyed by an Object Request Broker. In the meantime, the state will use a
service-oriented architecture, with requests conveyed by a Service Broker.
To assure their long-term contribution to the state, it is important that services developed to
support the service-oriented architecture be designed in such a way that they can be accessed
via either a Service Broker or an Object Request Broker.
Recommended Best Practices
The recommended best practices in this section pertain to application communication middleware
brokers.
Best Practice 1: Manage a statewide broker as a strategic infrastructure component.
The service broker is a critical part of the distributed computing environment because it
allows the technical architecture to meet the three goals of efficiency, sharing of information
and Department autonomy.
Strategic infrastructure benefits all departments and should be centrally managed.
The purpose of the service broker is to facilitate communication in a multi-platform, multilanguage environment. If the service broker is tied to a single vendors product, then the goal
of facilitating communication in a diverse environment has not been met.
Implementing a service broker that supports multiple vendors products helps protect the
state from being negatively impacted by market forces.
A best of breed approach should be taken when selecting the application communication
middleware.
Best Practice 4: Use the state s inter-application middleware, the service broker interface, for
inter-application communication between state-developed applications. For interfaces with
other applications, such as purchased packages or applications owned by other entities, use
the Interface Engine.
State-developed applications gain performance and flexibility by using the service broker for
inter-application communication.
In-house or out-sourced custom-developed applications requiring inter-application
communication should be capable of using a service broker. Applications sharing or requiring
services from external application systems should provide the capability to use the standard
inter-application communication middleware architecture.
Page 59 of 103
In instances where the application code cannot be modified, such as purchased applications
where the state does not have rights to source code, use the interface engine. For more
information about application integration, refer to the Integration Architecture chapter.
For more information on the Interface Engine, see the Integration Architecture chapter.
Standards
The standards in this section pertain to the application communications middleware brokers.
Standard 1: Use of the service broker is required for inter-application communication.
The service broker was put in place due to the lack of standards for inter-application
communication types such as RPC, MOM, and TP monitors.
While the lack of standards is not an issue for development of any single application, it poses
problems for communication between applications. The broker is proposed as a standard
communication paradigm for inter-application communication.
Page 60 of 103
Private & Confidential
Integration Architecture
Integration Architecture
I.
Definition
II.
Introduction
Integration is key to bridging the gap between heterogeneous operational application systems
while still maximizing the investment in existing hardware and client platforms. Integrating new
client/server, adaptive, and distributed systems with existing systems while still optimizing
performance, minimizing maintenance and utilizing existing platforms is a major technical
challenge. When new client/server systems are developed, they need the ability to access
business processes and data from legacy and purchased systems developed under different
technical architectures or built in features for future systems to access and interact with these
systems.
III.
Principles
The principles in this section are designed to provide guidelines for Integration Architecture
components that will be used throughout the state.
The Integration Architecture encompasses the multiple layers of new and existing systems
and the middleware in between.
The Integration Architecture should take into account the need to use existing workstations,
peripherals and existing transports to access existing and new applications.
Page 61 of 103
Private & Confidential
Integration Architecture
Principle 3: When making integration decisions, the life span of the solution is
a key factor.
A temporary solution may be engineered very differently than a long-term solution. Cost and
effort need to be taken into consideration when providing a solution that is only needed on a
temporary basis.
Short-term solutions are often hard-wired and often have low performance. They are
designed to be replaced or easily removed. Cost and effort should also be considered for a
short-term solution.
Long term solutions must be standardized, adaptable, and engineered for high performance.
It is more cost effective and easier to maintain applications that use middle service tiers than
to modify multiple legacy applications.
New N-tier applications still need access to the legacy information stored throughout the
enterprise.
To the extent possible, the Integration Architecture should enable new applications to use
existing resources with minimal disruption.
Where possible, use non-invasive techniques for integration.
Integration requires good communications infrastructure. If the basic network infrastructure is
not in place, a single integrated network of application communication cannot be achieved.
(Refer to the Network Architecture chapter.)
To the extent possible, use the same technologies in the Integration Architecture that are
used in the Statewide Technical Architecture.
Limit the heterogeneity of the technology used in order to simplify integration and enable
migration to future technologies.
Page 62 of 103
Private & Confidential
IV.
Integration Architecture
Technical Topics
Data translation and mapping. Translates the different communications and data
interchanges between two applications.
Transaction explosion. If configured properly, an application integration interface can take
one client transaction and spawn multiple transactions in remote applications.
Front-ending other applications. An interface can provide a single front end for integrating multiple
application systems.
Recommended Best Practices
The recommended best practices in this section pertain to application integration.
Best Practice 1: Use application integration strategy for online transaction program (OLTP)
application systems, not decision support systems (DSS).
Data warehouses or other solutions should be used in decision support applications. (For
more information on data warehouses, refer to the Information Architecture chapter )
Best Practice 2: Design an integration solution that does not write directly to an operational
database
Existing application logic or business rules should be used when updating an application
database. An external user or application could inadvertently corrupt operational data.
Best Practice 4: Use direct program-to-program interfaces for high transaction volumes.
Best Practice 5: When designing an application integration solution using an interface engine,
give careful consideration to the design and planning of the application interfaces and
connectivity.
At the beginning of the design stage, involve application developers who are knowledgeable
in the business rules and interfaces to each system that needs to be accessed.
Page 63 of 103
Private & Confidential
Integration Architecture
Some application systems may have multiple entry or exit points that can be used. If a noninvasive solution is selected, capitalize on using the entry or exit points that best apply to your
application needs.
Standards
Standards in this section pertain to the application integration.
Standard 1: Clearly Define Application Interfaces
To integrate applications for which the state has no source code rights, application interfaces
must be clearly defined in order to allow reliable communication between applications.
To facilitate purchase of best-of-breed software while easing application integration issues,
the application interfaces must be clearly defined.
A message or transaction is the mechanism for extracting data from an application or sending
data to an application.
Programmers integrating applications need to know record length and type (i.e., whether it is
a variable or fixed length record, and if its variable, the delimiting characters used to
separate the fields), and know which fields are optional versus required.
A description of the data for each field is also necessary.
Explanations and examples of record formats and field descriptions are helpful and should be
included.
Standard 3: The application must be able to transmit and receive messages using a
client/server model.
The client is the process that sends or originates the message. The server is the process that
receives the message.
Clients and servers may communicate using TCP/IP and sockets, or other communication
protocols, such as Serial and FTP, as long as they perform the same transmit and receive
functionality.
Packetization characters, which identify the start and end block strings, and message
acknowledgment format must also be provided.
Purchasing line-of-business application software can permit the state to respond to business
needs in a more timely manner than custom developing software.
Published APIs are insufficient because their use requires custom development of state
applications and it may be impossible to interface two purchased applications. Use of an
interface engine provides greater flexibility.
Page 64 of 103
Private & Confidential
Integration Architecture
Additional layers of middleware in between an application and the database gateway could
hinder performance of mission critical applications. For example, an application that needs to
access a database gateway can implement an ODBC middleware layer that ultimately
accesses the gateway middleware. Application performance can be increased if the
application was written to make direct calls to the gateway middleware, omitting the ODBC
layer.
If there are fewer middle conversion tiers, there are less operational layers to maintain in the
event of maintenance or upgrades. For example, if there is a change to a application
database location, or an upgrade or maintenance update to the middleware software, it can
effect all end user workstations and servers that access that application.
The more complicated the strategy, the more difficult it is to maintain and change.
Best Practice 3: Code data integrity verification rules into the DBMS whenever possible,
particularly when external users and programs will be writing data directly to the DBMS.
Since most DBMS vendors can code triggers and rules into the database, it is recommended
to use this technology wherever possible in order to ensure data integrity.
For more information on databases, refer to the Data Architecture chapter.
Best Practice 4: Separate decision support systems (DSS) from online transaction processing
(OLTP) databases whenever feasible.
If this practice is feasible, it will reduce the impact of ad hoc and large queries from decision
support systems onto production operational application databases that are used by online
users for day-to-day operations.
Implementation Guidelines
Once the best method for data access has been selected, the following guidelines may apply:
Guideline 1: Implement a hub topology as opposed to distributed data access topology
whenever possible.
The distributed data access topology is where each point-to-point connection makes sense by
itself, but the infrastructure as a whole is a tangled mass of connections.
The star or hub technology is less complex and easy to maintain.
Guideline 2: Use a database gateway technology to combine queries of SQL data with nonSQL data.
Page 65 of 103
Private & Confidential
Integration Architecture
Guideline 3: Do not use any vendor specific extensions when using a database gateway that
uses SQL calls.
Use the industry standard of ANSI Standard SQL
Guideline 4: Once the database gateway product is selected for use as an integration tool, use
the gateway from the central IT location whenever possible, particularly in situations where
the requirement is to access application data from the central systems/locations.
Expertise is centralized so the application developers do not have to duplicate efforts and
relearn the gateway technology in each department. The departments also do not have to
retain personnel with gateway expertise in addition to hardware and software experts to
maintain the system.
Security is centralized and controlled in a unified manner for all departments. With centralized
security administration, the effort to limit access to authenticated users of an application is
reduced.
Dedicated gateway servers can be used that are easily administered, monitored and
controlled, which contributes to the state effort for performance monitoring, error recovery
and disaster recovery.
The state has to establish a central license agreement that would simplify the addition of
users and allows the departments to share the cost of the gateway more economically.
It is a global standard, meaning that tools and solutions to be used for developing
applications will either be complying with it already or will comply in their future releases.
This will significantly reduce the cost and effort for building and maintaining interfaces
between applications when compared with similar non-standards based tools.
Apply the normal cost/benefit analysis criteria while using XML
Best Practice 2: Developing the DTD/schemas can be a top down as well as a bottom up
approach
Some of the DTD/schema can be defined based on metadata, which have been already
defined in the Data Architecture chapter. However, while developing and implementing other
state applications, a number of DTD/schemas are likely to be defined and can be made
available. These can be added to the standard DTD/schemas which the state can use.
Page 66 of 103
Private & Confidential
Integration Architecture
Implementation Guidelines
Guideline 1: Check available/accepted schemas before developing them bottom up
Globally, a number of initiatives are have been underway towards defining DTD/Schemas.
These are initiated by various industry groups and address industry specific need for
exchange of information. Considerable effort can be saved if some of these schemas can be
found to be deployable by the state, either as-is or with some modifications.
Developing DTD/schemas and maintaining them, updating them in view of changing needs of
the state will be an ongoing process that will require constant monitoring
Compliance and enhancements can be enforced better if the responsibility is centralised by
the creation of a repository and an organisation to maintain it.
Guideline 3: Rely on the network other security infrastructure for building and enforcing
necessary secure environment for exchange of data.
The XML standard addresses data transformation only, hence it relies on other systems for
security services.
Standards
Standard 1: Clearly define and publish DTD/schemas
Related Information
www.oasis-open.org Organisation for the Advancement of Structured Information Standards,
that creates XML standards
www.xml.org and www.w3.org/xml the source of information on XML standards, schemas,
tools,etc.
www.w3.org/TR/XSL information on XSL
www.xbrml.org source for work on business reporting using xml
www.hr-xml.org source of information on HR related XML schemas
Page 67 of 103
Private & Confidential
Network Architecture
Network Architecture
I.
Definition
Network Architecture defines a common, uniform network infrastructure providing reliable and
ubiquitous communication for the States distributed information-processing environment.
II.
The Network Architecture specifies how information processing resources are interconnected,
and documents the standards for protocols (for network access and communication), topology
(design of how devices are connected together), and wiring (physical medium or wireless
assignments). The Network Architecture defines a unified, high-speed statewide network based
on open systems standards. The biggest benefit to a statewide network solution is the ability to
efficiently share information processing resources across the enterprise. Sharing resources is a
common theme in all aspects of the Statewide Technical Architecture because economies of
scale and efficiencies in operation result from collaborative approaches to technology. When
departments share common application services and data, they avoid duplicative efforts and
costs. The key to successfully sharing these resources is a network connecting all state
departments together in a way that reduces redundancy.
A statewide telecommunications network must be strategically planned, strongly backed, and
expertly managed. This network must:
III.
Principles
The following principles are provided to guide the planning, design, and selection of network
technology and services:
Network Architecture
It acts as the delivery mechanism for the distributed computing services required by the fastpaced, dynamic business.
Networks provide an increasingly important and necessary role in the execution of business
functions and processes. The availability of the network seven days a week and twenty-four
hours a day must be maintained in a consistent and complete manner.
Networks consist of and rely on many interrelated and often highly complex components
distributed across a wide geographic area. Failure of any single component can have severe
adverse effects on one or more business applications or services.
Reliable networks contain no single point of failure. Networks are comprised of many
components, and are only as reliable as the weakest link. Reliability must be built-in, not
added-on.
Bandwidth must be sufficient to accommodate new and expanding applications, different
types of data (e.g., voice, data, image, and video), and a variety of concurrent users.
The network must support software distribution and installation to a widely dispersed user
community.
The network must be designed to minimize latency. Data must pass across the network in a
timely manner so that business decisions can be based on up-to-date information.
An open, vendor-neutral protocol provides the flexibility and consistency that allows
departments to respond more quickly to changing business requirements.
An open, vendor-neutral network allows the state to choose from a variety of sources and
select the most economical network solution without impacting applications.
This approach supports economic and implementation flexibility because technology
components can be purchased from many vendors. This insulates the state from unexpected
changes in vendor strategies and capabilities.
Applications should be designed to be transport-independent.
All users must obtain authentication via a user identification method consistent with the
standards and usage guidelines set by the enterprise.
Authorization of users must be performed according to the security rules of the enterprise and
the local business unit.
In order to perform their job functions, users need to access services available from multiple
sites within the enterprise, from a variety of public and private networks, and from the
Internet.
Page 69 of 103
Private & Confidential
IV.
Network Architecture
Technical Topics
The increasing investment of funds in network infrastructures dictates that the life span of
each additional component or enhancement be as long as possible. This can be
accomplished if the design supports current needs but includes an anticipated growth
potential. For example, installing Category 5 cabling today to run a 10 Mbps network
positions a site to upgrade to a 100mbps speed in the future without replacing the cabling.
As businesses expand, networks expand. A flexible, open network design will allow a
business to minimize the costs and disruptions of configuration management while providing
timely and responsive network changes when and where required.
Best Practice 2: Configure all servers supporting mission critical applications, including
desktop applications, to minimize service interruption.
Select a computer constructed to perform as a highly available, highly reliable, fault tolerant
server with such features as redundant disk arrays, network cards, power supplies, and
processors.
Select a server with sufficient growth capacity to accommodate the anticipated increase in
application requirements over time.
Formalize security, disaster recovery, and backup procedures to ensure the integrity of both
the server and the application. Test those practices on a regularly scheduled basis.
Implementation Guidelines
Guideline 1: Configure the topology (physical wiring) in a Star pattern
Star topology uses a central hub/switch to which each network device is connected.
Problems with a connection in a star network only affect that one device.
A star topology provides the capability to easily add and remove devices as necessary.
A star topology responds well to dynamic infrastructure changes in order to meet the growing
demands of data movement. With ever increasing demands of information movement, more
data, secure paths, new paths, and faster access, a star topology allows different,
changeable, connections.
The hub is an ideal point for network management due to its central location and because all
network traffic flows through it.
Network switches provide the ability to break a network up into smaller sub-network
segments.
Page 70 of 103
Network Architecture
Switches can be used in conjunction with hubs. They improve LAN performance. With
switching, network traffic is balanced across multiple segments thus reducing resource
contention and increasing throughput capacity.
Switching allows networks to assign increased speed or performance capability to particular
segments in order to respond to heavy usage or application requirements.
Standards
The following standards have been established to assist departments in the implementation of
LANs. The goal is to employ only open systems based on industry approved standards, but a full
complement of open standards does not yet exist for all components of LANs. Therefore, a
combination of industry standards, de facto industry standards, mutually agreed upon product
standards, and open standards are currently required to support the states heterogeneous
operating environment. All standards will be periodically reviewed.
Standard 1:
The standard for LAN cabling is Category 5, 6, or 7 Unshielded Twisted Pair (Cat 5 UTP, Cat 6
UTP, or Cat 7 UTP). Unless specific needs exist, such as high EMI or long distances, UTP should
be considered for the horizontal runs in cable layouts.
Standard 2:
The standard for standard link layer access protocol is Ethernet, IEEE 802.3 Carrier Sense
Multiple Access/Collision Detection Access Method (CSMA/CD).
Page 71 of 103
Private & Confidential
Network Architecture
A single uniform network infrastructure allows an enterprise to respond more efficiently when
faced with requests by departments for WAN component upgrades and installation.
A centrally developed and managed infrastructure provides a more cost effective use of
infrastructure resources.
Departments or business units should focus their WAN requirements on functional
specifications such as level of service needed, throughput needed, and response time
needed. The implementation of an appropriately responsive WAN should be a specialized
function performed for the enterprise in its entirety.
Standards
In telecommunications, standards for products and services were created by the originating
industry monopoly (i.e., the phone company). Therefore, even though the monopoly has been
disbanded, the proven standards that were established have remained. With data
communications, however, there have always been many companies offering individual products
and services. Therefore, although interim product standards have emerged as one companys
product gained market share, there has been a lack of industry level standards. Therefore, until
industry standards are established, an enterprise must choose to implement product based
standards in order to create a manageable solution to the maintenance and management of its
data communications infrastructure.
The following standards have been established for the implementation of department-based
components to connect with the statewide WAN. A combination of industry standards, de facto
industry standards, and open standards are currently required to support a heterogeneous
operating environment.
Standard 1: The standard protocol technology is TCP/IP.
Open protocol.
Allows Internet access.
Allows creation of Intranets and VPNs.
Standard 2: The standard internet access technology is Domain Name System (DNS) and IP
address assignments are provided by the State for those departments participating in the
Andhra Pradesh State Wide Area Network (APSWAN).
State must assign IP addresses to allow LANs access to the AP State WAN.
It allows a structured naming conviction and IP address allocation for the states WAN and
domain names.
Page 72 of 103
Private & Confidential
Network Architecture
Including network expertise ensures correct planning, documentation, and standard practices
are followed.
Requirements definition should include application performance, as well as capacity planning
for network usage (based on the predicted number and size of transactions).
Define any special networking requirements or constraints and perform the associated
network design before development tools are selected. Otherwise, the tools used may not
support the network architecture required to support the business.
The network can be modified (upgraded) while applications are under development.
Performance and the cost to move information should be balanced during application design.
Multiple perspectives of a cross-functional group can ensure all viable options are
considered.
Isolate the application code from the network specific code so business rules and data
access code can be redeployed on a different platform, if necessary.
Code to a middleware API, not to the network API.
For a network to remain scaleable and portable, applications must be developed without
regard to the type of network (i.e. WAN or LAN) they are to be deployed on.
Network-specific design (e.g., wireless or guaranteed high-bandwidth) should only be
performed when business requirements dictate.
When possible, schedule heavy network use for off-peak hours. For example, where
requirements for data freshness permit, perform database synchronization at night.
Data warehouses typically are used for decision support applications requiring large amounts
of data to be transferred through the network.
When replicating databases, consider partitioning and distributing subsets, rather than
duplicating the entire master database.
Decoupling the application layers provides the most efficient use of network resources by
allowing the data access layer to be placed near the data.
Perform all transaction commits locally, between the resource manager and the queue.
Asynchronous store and forward messaging can limit the scope of a transaction.
Decouple transactions as allowed by business rules. Reconcile data at low-cost times.
Using store and forward, work can occur at a site even if the network link is down.
Best Practice 5: When data has to be distributed to multiple points (e.g., software and content
distribution), move it once and only once across each data link.
Use push technology, rather than using client polling. It overloads servers and network links
to servers.
Page 73 of 103
Network Architecture
Best Practice 6: When designing distributed applications, make no assumptions about the
speed of the network on which the application will be deployed.
Since bandwidth is unpredictable at design time:
Minimize the amount of data to be moved between components. This will enhance
performance regardless of the speed of the network on which the application is deployed.
Use asynchronous rather than synchronous communications between application
components (except in cases where business rules require synchronous communications).
This will prevent application components waiting for a response from a server.
For users and application requests that may be intermittently connected, use store-andforward messaging to communicate with application components.
When multiple, independent units of work must be performed, initiate all so they can be
performed in parallel, rather than waiting for the completion of one before initiating the next.
Measure application performance often, especially before and after any component is moved
to a different platform. This helps quantify the performance impact of the redeployment, and
helps isolate any problems associated with a network link or platform.
Use load testing tools that simulate many users accessing the application. This testing
method will provide information that will not surface during single user test scenarios.
Load testing will identify network bottlenecks (and application bottlenecks) before the
application is deployed in the production environment.
Best Practice 8: Deploy heavily used data sources close to the applications using them.
Close does not imply physical proximity. It means deployed on platforms that have highbandwidth connections between them. Do not perform heavy data movement across the
WAN during peak hours.
One of the biggest cost factors in designing a network is the transmission of the data over the
communications system.
For applications requiring very large amounts of data movement, try scheduling the execution
of these queries to run during off peak hours to minimize the impact on network performance.
Implementation Guidelines
Guideline 1: Use asynchronous rather than synchronous communications between
application components (except in cases where business rules require synchronous
communications).
Page 74 of 103
Private & Confidential
Network Architecture
Guideline 2: Where business rules allow, use off-peak hours for scheduled data transfers.
Guideline 3: Code applications to middleware APIs where there are no specific business
requirements. (e.g., wireless)
Page 75 of 103
Private & Confidential
Platform Architecture
Platform Architecture
I.
Definition
Platform Architecture identifies hardware platforms and associated operating systems supporting
the states business.
II.
The Platform Architecture describes the platform requirements for building a client/server
infrastructure as well as the storage architecture associated in maintaining the data generated.
Technical topics to be discussed under platform architecture include client architecture and server
architecture.
III.
Principles
The principles listed below provide guidelines for the design and selection of platform technology
components that will support distributed, client/server computing activities across the state.
Using multiple servers from the same vendor with the same operating system release is cost
effective because a group of uniform servers is easier to manage and integrate across a wide
geographic area and multiple departments.
A highly granular, loosely-coupled server design supports modular application code sets in an
N-tiered application architecture.
With binary compatibility, there would be no need to recompile an application for different
platforms. For example, if an application that is going to be deployed on servers located in
registration department offices, all servers running that application should be binary
compatible -- this must be ensured even if the platforms are from the same manufacturer.
The platforms must run the same version of the operating system and must not require any
recompilation of the line of business application to deploy from one office to another.
Total binary compatibility will support automated software distribution across servers and
associated strategies which reduce support costs and provide stable computing platforms
that can be reliably shared across departments.
Page 76 of 103
Platform Architecture
Open, vendor-neutral systems standards provide flexibility and consistency that will allow
departments to respond more quickly in an environment of changing business requirements.
Vendor-neutral systems support economic and implementation flexibility.
Vendor-neutral systems also protect the state against unexpected changes in vendor
strategies and capabilities.
IV.
Technical Topics
Page 77 of 103
Private & Confidential
Platform Architecture
Migration from 16-bit operating system platforms to 32- or 64-bit operating system platforms
will support faster processing, access to more memory, and better memory and process
management.
In an N-tiered, client/server environment, speed, memory capacity, and memory and process
management become increasingly important as processing is distributed across platforms.
The 32-and 64-bit operating systems provide more stable, reliable platforms in an N-tiered,
distributed client/server environment.
Best Practice 2: For reliability and ease of support, place each major application on a
uniformly configured server. This may require that each major application be implemented on
its own server.
Use the same reference configuration on these servers. Important items to consider when
planning for consistency include using the same versions of network software, using the
same network hardware cards, etc.
Tuning performance through configuration changes can make overall maintenance more
difficult. In the long run, it may be less expensive to buy more powerful hardware than it is to
spend time on individualized tuning and maintenance.
The Network Operating System should be considered a major application and run on its own
platform.
Best Practice 3: Consider normal anticipated future application growth when determining
capacity requirements for server platforms.
A server platform should be purchased that will accommodate the current demand as well as
support anticipated normal growth without requiring the purchase of a new server chassis.
Rather than purchasing a fully configured server, purchase the next larger size platform to
allow for expansion. This will permit upgrades to an existing platform to accommodate growth
rather than forcing the purchase of another machine.
Best Practice 4: Balance business adaptability and ease of systems management with server
platform choices. However, when there is a conflict between business adaptability and ease of
systems management, the business requirement for providing adaptability should have the
highest priority.
Implementation Guidelines
The following implementation guidelines pertain to the server platform.
Guideline 1: Make server platform decisions after the business makes some basic
determinations regarding growth, scalability, portability, and openness.
Growth: Must the technology accommodate substantial growth beyond present data and
transaction volumes?
Page 78 of 103
Platform Architecture
Scalability: In accommodating growth, must the technology be able to start small and grow by
continuous small increments? Alternatively, is it acceptable for the technology to grow in
major, discontinuous steps?
Portability: Will it be necessary to move software across server platforms at some point in the
future?
Openness: What are the business implications if a proprietary system is used, thus
eliminating the option to choose system components from many vendors?
Standards
Standard 1: Run Distributed application servers on platforms supporting open operating
systems.
Open operating systems are available from multiple vendors, such as UNIX
Open operating systems run on hardware available from multiple vendors, such as Windows
NT.
Open operating systems are in the public domain, but have significant industry support, such
as Linux.
Standard 3: Make sure server platforms comply with third party certifications:
UNIX
Manufacturer is ISO 9002 certified
XPG4 Branded UNIX 93
Microcomputers
Manufacturer is ISO 9220 certified
Gartner Group Tier 1 or Tier 2 classified
Third party certifications foster quality product purchases from manufactures that have
demonstrated abilities to deliver and support these products.
Page 79 of 103
Private & Confidential
Platform Architecture
Choose a device and host software that is already in use elsewhere in the enterprise.
Consider other potential uses for the device and host software in the enterprise.
Best Practice 2: Ideally, client platform choices should satisfy both end-user ease-of-use and
ease of systems management. When there is a conflict between end-user ease-of-use and
ease of systems management, give priority to end-user needs.
Best Practice 3: Choose client platforms that support personal productivity and connectivity.
This may require multiple client configurations to support business needs.
If personal productivity applications are run on the desktop, a 32-bit or 64-bit operating
system is required. Migration from 16-bit operating system platforms to 32- or 64-bit operating
system platforms supports faster processing, access to more memory, and better memory
and process management. The 32- and 64-bit operating systems provide more stable,
reliable platforms in an N-tiered, distributed client/server environment thus reducing the
number of system crashes caused by lack of client resources. In addition, 64-bit operating
systems provide better performance for process intensive applications such multi-media and
engineering (CAD) applications.
Best Practice 4: The client platform displays the interface to an application. In the design of
applications, minimize dependency on a particular client platform as much as possible.
Implementation Guidelines
Following are the implementation guidelines for the client platform architecture.
Page 80 of 103
Private & Confidential
Platform Architecture
Guideline 1: When selecting a client platform, consider the financial viability of the vendor, the
availability of packaged software, the ability to meet department needs, adherence to state
standards and direction, cost, availability of skill sets for development on the platform,
support availability, and service terms and conditions.
Technology and technology companies come and go. Consideration of vendor viability and
availability of support, service, and skill sets mitigates risk associated with a dynamic and
volatile market place.
Guideline 3: Use existing standards for user interfaces, such as Open Look or OSF Motif for
UNIX Workstations, Windows GUI for personal computers or web browser for workstations or
personal computers.
This approach increases reuse, makes user training easier, and enhances the maintenance
process.
Standards
The standards listed below have been established for the client platform architecture.
Standard 1: Two-dimensional (2-d) bar codes should use PDF417 coding standard.
The PDF417 bar code standard is used by the Department of Motor Vehicles. It is capable of
storing data such as product information, maintenance schedule, shipping information or others.
Standard 2: Platforms must comply with third party certifications.
Client platforms must comply with third party certifications as specified in the table below.
UNIX
Manufacturer is ISO 9002 certified
XPG4 Branded UNIX 93
Microcomputers
Manufacturer is ISO 9002 certified
Gartner Group Tier 1 or Tier 2 classified
Page 81 of 103
Private & Confidential
Platform Architecture
No standards exist for smart card reader-side APIs for application and platform integration. Use
reader-side APIs from established platform vendors, such as PC/SC for the windows environment
or use APIs that strictly adhere to the ISO 7816/4 command set.
Page 82 of 103
Private & Confidential
Platform Architecture
Standard 3: SAN based fibre channel technology for large scale storage deployments running
mission-critical applications to be the defacto standard.
Page 83 of 103
Private & Confidential
Definition
Security and Directory Services Architecture identifies criteria and techniques associated with
protecting and providing access to the states information resources. It facilitates identification,
authentication, authorization, administration, audit, and naming services. The states
technological resources must be available to users across the enterprise regardless of location or
platform. Therefore, the state must implement security and directory services in such a manner
that its information infrastructure is protected and accessible while, at the same time, its
functionality is unimpeded and its business services are readily available.
II.
The purpose of security is to protect and secure the states information resources in order to
provide an environment in which the states business can be safely transacted. A directory is a
natural place to centralize management of security. It is the vault that contains the most trusted
and critical components of an enterprise security strategy. This will require authorization and
authentication services and a common enterprise repository of digital certificates that secures and
supports E-commerce applications. Security services apply technologies to perform the functions
needed to protect assets. Historically, such services have consisted of door locks, vaults, guards,
sign-in/sign-out logs, etc. As the state performs more business functions electronically, it must
transition to security services designed to protect the electronic environment. For example, the
use of face-to-face identification must be superceded by an equivalent electronic method that
does not require the physical presence of the person.
III.
Principles
Security is a business enabler with associated costs. Security costs should be rationalized to
the intended benefits.
Requirements for security vary depending on the information system, connection to other
systems, sensitivity of data, and probability of harm.
Each transaction type will have individual security requirements.
Security costs potentially increase beyond the value of the assets protected. Dont use more
security than is required.
An architecture that defines an integrated set of security services permits state departments
to focus on the business goals rather than on the implementation of security.
Integration of security services will enable interoperability and provide flexibility in conducting
electronic business across and beyond the enterprise.
Integration will reduce the costs of protecting the states resources.
Integration will increase the reliability of security solutions.
Centralized Directory services
Principle 4: An accurate system date and time are essential to all security
functions and accountability and must be maintained.
The validity of digital signatures and electronic transactions depends on precise, reliable date
and time information.
Audit accountability relies on placing events sequentially according to date and time.
Whenever security is required, the location in a communications protocol will have an impact.
The impact may be on performance, reliance on an underlying network protocol, and on
developers. Choosing the appropriate layer in a communications protocol will maximize
usability and minimize future changes.
Security services can have an impact on performance. The impact is minimized when
security services are located at lower layers of a communications protocol.
Security services can have an impact on developers. For example, services provided at the
transport layer have less impact on application programmers than services that run above
that layer.
Security services can increase reliance on a network protocol. An appropriate choice
depends on the communication requirements of the business system.
Page 85 of 103
Private & Confidential
IV.
Technical Topics
Standards
The standards in this section apply to security identification.
Standard 1: ISO 7816 Smart Card standards for contact smart cards.
ISO 7816/1-4 standards define the electrical resistance, positioning of electrical contacts,
communication protocol between card and card reader, and command set recognized by
smart cards.
They correspond roughly to the OSI layered model.
The command set defined by the ISO 7816-4 standard are included in whole or in part by
most smart cards on the market.
Standard 2: ISO 14443A and Mifare Smart Card standards for contactless smart cards.
ISO 14443A standards for contactless smart cards define the characteristics and
communication protocols between contactless cards and card reader. These standards are
still in development.
The Mifare architecture is the de facto global interface standard for contactless and is based
on ISO 1443A.
Contactless cards under this standard use RF power and frequency protocols and cover
read/write distances up to 10cms of the reader.
Standard 3: Use PKCS #11 or PC/SC for integration of smart cards and host/reader-side
applications.
PKCS #11 from RSA is a widely accepted standard for integrating smart cards to applications
supported by many vendors.
Page 86 of 103
SVAPI is an API used for incorporating speaker-recognition technology into desktop and
network applications.
A consortium of vendors, technology developers, researchers VARs and end-users
developed the SVAPI.
The SVAPI offers interoperability over distributed environments with related APIs.
They include SAPI, the telecom industrys S100, a standard architecture for developing
computer-telephony applications, and JavaSpeech, a standard for speech recognition using
Java.
The Human Authentication API (HA-API) is a generic API designed to allow a common set of
instructions to integrate biometrics into applications requiring identification.
It supports the enrollment sampling, processing and verification of biometrics.
The API supports multiple biometric template types and multiple vendor technologies for each
biometric type in one database. This permits an enterprise wide approach to biometric
identification while allowing different application-specific biometrics to be used. A single
database also facilitates the use of multiple biometrics in a single application.
The API permits changing the biometric used without requiring application code changes.
Standard 6: Use open standards for smart card masks such as MULTOS.
Allowing only authenticated users to access system resources protects those resources from
inappropriate access.
Authenticating users is the basis for providing accountability.
Page 87 of 103
Private & Confidential
Best Practice 2: Use Public Key / Private Key technology for authentication when digital
signatures are required.
Public Key / Private key technology is the most widely accepted form of digital signatures.
Digital signatures are central for most electronic business.
Best Practice 3: Use token-based or strong password based authentication where public key
certificates are not feasible.
Collaboration and co-operation will be required to support security services across the
enterprise.
A unified approach to a Public Key infrastructure enables the state to respond to changing
requirements and conditions.
A fragmented approach to a public key infrastructure will complicate administration and
management of security across the enterprise.
Standards
The standards in this section pertain to security authentication.
Standard 1: Public Key Certificates (X.509v3)
Page 88 of 103
Private & Confidential
The recommended best practices in this section pertain to authorization and access control.
Best Practice 1: Authorize users based on least privilege.
Best Practice 2: Use appropriate security service levels for each part of the technical
infrastructure according to enterprise-wide standards.
Identifying the necessary security service levels allows appropriate choice of a security
mechanism.
A subdivision of infrastructure along security requirements will minimize security
management and response to changes.
A basic level of communication security will reduce the number of applications that must be
security-aware.
Security implementations vary widely. Use of proprietary solutions may make it difficult to
adapt to advances in security and standards development.
Security management across the enterprise requires a consistent and open standards based
implementation of security solutions.
Implementation Guidelines
The implementation guidelines in this section pertain to authorization and access control.
Guideline 1: Secure transmission of data where appropriate.
Data in transit to and from the enterprise must be protected in compliance with legal
requirements for confidentiality and privacy.
Web-enabled applications must protect confidential or critical data from unauthorized access.
Use secure server-to-server communication to protect confidential or critical data
transmission.
Guideline 2: Avoid Virtual Private Network (VPN) solutions for connecting trading partners
outside the enterprise that are not IPSec compliant.
VPN solutions today are proprietary. All outside trading partners are unlikely to use the same
or similar technology.
Most transactions can be done with SSL.
VPN solutions should be chosen on compliance with IPSec and inter-operability among
IPSec compliant VPNs.
Guideline 3: Web-enabled applications that require user authentication should use SSLv3 with
client authentication and client public key certificates where appropriate.
For certain payments over the Web, for example credit card purchases, SSLv3 without client
authentication is sufficient protection for client and server confidentiality.
For purchases or changes to state data, which mandate user authentication, SSLv3 with
client authentication should be used.
Page 89 of 103
Guideline 4: Use encryption for stored data or email only when appropriate.
Standards
The standards in this section pertain to authorization and access control.
Standard 1: Secure Sockets Layer version 3 (SSLv3)
SSLv3 is the most commonly supported protocol for communication between Web Server
and browser.
It authenticates the Web Server and optionally authenticates the user browser.
Current implementations allow for client authentication support using the services provided by
Certificate Authorities.
Cryptographic services identified in this document are based on open, industry accepted,
standards.
The following business requirements and associated cryptographic standards have received
wide acceptability and can be found in most products. Only full strength cryptography should
be used. For example browsers are often supplied with weakened versions such as 40 bit
DES, RC2 and RC4. Only browsers with full strength keys should be used for transactions
involving the state. Cryptography with variable length keys should use a minimum key length
equivalent to 56 bit DES.
Cryptography Algorithm
Standards
Secret Key
Message Digest
MD5, SHA-1
Page 90 of 103
Private & Confidential
S/MIMEv3 provides a consistent way to send and receive secure email including MIME data.
S/MIME defines a protocol for encryption services and digital signatures.
Email clients should be evaluated for support of the standard and for interoperability.
Standard 5: Services provided through the Internet (Web-enabled applications, FTP, Mail,
News, DNS, etc) must be placed on the DMZ or proxied from the DMZ.
Application services must be protected from unwanted external access and must be located
on a DMZ or proxied from the DMZ.
All communication from servers on the DMZ to internal applications and services must be
controlled.
Remote or dial-in access to the enterprise must be authenticated at the firewall or through
authentication services placed on the DMZ.
The enterprise is one security policy domain with a specific security policy that must be
implemented. Other domains may be executive departments or county and local government.
Establishing security domains simplifies the analysis of security requirements and focuses
attention on security policy requirements.
Identifying security domains allows policies to be applied at the appropriate locations in the
architecture.
Security policies may vary between domains requiring protective measures or gateways to
traverse differences in policies.
Implementation Guidelines
Role-based administration and multiple security domains are easier to administer and
maintain than user-based privileges and single enterprise security domains.
If the directory becomes inaccessible, the resources to which a user has rights become
unavailable. Therefore, a directory must be available at all times to accept authentication
requests. This can be accomplished with a planned fail-over strategy to ensure that, if one
server fails, another backup server can pick up the requests. This should include a replication
strategy with hardware solutions that include disk or system duplexing, disk or system
mirroring, disk arrays, and UPSs.
Page 92 of 103
Private & Confidential
Standards
Standard 1: Use the statewide directory services infrastructure.
Using the statewide directory services has several benefits:
The infrastructure is simplified by providing a common interface to view and manage all
available resources.
Directory services are a critical component to statewide initiatives like E-mail and Electronic
Commerce. The current enterprise directory is fault tolerant and highly available from any
location that participates. Time, distance, and location do not restrict access to the
information contained within the services.
Coordinated directory services will improve communication between our applications,
databases, and network operating systems by providing consistent, reliable information in an
efficient and effective manner.
It is more efficient to link like directories into a single tree. Most vendors of directories have
implemented either the standards that currently exist or standards that have been proposed.
These standards include a mechanism to connect their directories together to build a single
tree. This provides the optimum integration of Public Department resources and people
without regard to location. A single tree minimizes infrastructure costs while maximizing the
potential for departments to choose how they share resources with other departments
including local governments. The single tree approach also allows for improved fault
tolerance and better performance especially for departments with geographically dispersed
operations. Joining a tree, regardless of manufacturer, must be coordinated with Information
Technology Services.
It is necessary to tie these single trees from various manufacturers to the authoritative
enterprise directory in order to provide authentication services to the authoritative enterprise
directory. However, achieving connectivity from one manufacturers directory to another is
complex and difficult. For example, tying one Netscape directory to Novells NDS can be
done but is difficult to implement and maintain. The state currently has dozens of Netscape
directories in place. The process would then need to be performed for each of them.
However, tying all Netscape directories together into a single tree is fairly straightforward and
facilitated through their product. Then the one Netscape tree can be tied to the one NDS tree.
It is a complicated task but it is performed once. Through the Enterprise Directory Services
Initiative, this interoperability between dissimilar directories will be implemented. This will be
accomplished through the use of meta-directory technologies.
Standard 3: Use the Andhra Pradesh Service Broker (APSB) services for directory functions.
As in-house applications are developed, we must make use of the services that are already
available rather than to constantly build new ones. An enterprise directory services
infrastructure provides an addressable security service for authentication and authorization
as well as a repository for digital certificates.
These services are addressable directly from the enterprise directory or through a service via
the Andhra Pradesh Service Broker. For more information about the Andhra Pradesh Service
Broker, refer to the Componentware Architecture chapter.
Page 93 of 103
Private & Confidential
Standard 4: Use the Centralised Metadata Repository directory schema attributes and object
classes.
A directory is basically a database that has been tuned to perform massive reads and
infrequent writes. Like other databases in our enterprise, directories and their elements must
be centralised. For example, where a person object class may have an attribute of Pager
Number, Pager Number should be registered in the Centralised Metadata Repository and
populated according to that definition. Therefore, when the directory is queried for that
information, the data returned will be as expected. In the past there has been a tendency to
populate currently unused directory attributes with data that is not consistent with that
attribute. For example, there may be a requirement to enter a pager number in the directory
for a user. If there is no attribute for Pager Number, there may be a tendency to select an
attribute that is unused such as Title. Instead, extend the schema to include a new attribute
that precisely defines the data that will be placed there and register it with the Centralised
Metadata Repository. Do not store inconsistent information in an unused attribute.
Any data source is only as good as the data it contains. If that data is missing, incorrect, or
incomplete, the data source cannot be depended upon as an authoritative source for that
type of information. A directory is no different. Directories have become much more than an
authentication point for network users. In order to supply information on our users, network
devices, and organizations, directories must be built in as complete and reliable manner as
possible.
Standard 6: Use Lightweight Directory Access Protocol version 3 (LDAPv3) for directory
access where strong security is not required.
LDAPv3 is the industry standard lightweight access protocol and does not offer strong
authentication or access controls. However, LDAPv3 can provide standards based access to
directories for lookups, as a communication mechanism for synchronization tools, public key
retrieval, and others. Commercial off-the-shelf (COTS) applications often require their own
directories. Access to the application directory from outside or for the application to
communicate with an external directory will require a standards based approach. Therefore,
when purchasing COTS applications, LDAPv3 compatibility is required. LDAPv3 also
provides a standards based access to the directory for lookups, as a communication
mechanism for synchronization tools, public key retrieval, and others.
Page 94 of 103
Private & Confidential
Definition
Systems Management Architecture defines the framework for efficient and effective management
of the states distributed information processing environment in order to support and enhance the
productivity of its automated business systems.
II.
Introduction
The states Systems Management Architecture is the framework that identifies the requirements
for managing and supporting the enterprise-wide technical architecture with primary emphasis on
centrally managing distributed systems at geographically disbursed sites. Resources managed
include the systems, databases, applications, networks, and Internet components necessary to
conduct the automated business functions of the state.
III.
Principles
System management must facilitate the business process. Business unit needs should play a
primary role when identifying requirements and selecting technology and applications.
Business units are assuming a larger role in driving technology selection and its application.
Whenever a business need conflicts with a systems management need, the business need
must take priority.
Business units should have as much autonomy as possible to select applications that meet
their needs. As long as the business functionality justifies the cost and the business unit is
willing to pay the price, then the selected application is acceptable. Support costs should be
considered by the business unit.
To support business processes, systems management must focus on increasing system
stability and availability while reducing costs. It can achieve these goals by setting standards,
establishing guidelines and centralizing systems management functions along business
functional lines.
Centralization/standardization should occur within a business function. However, a single
standard does not apply to all lines of business. For example, all operators using the same
system should have a minimum standard hardware and software configuration to meet their
needs. Operators using other systems may require different tool sets to meet the needs of
their unique business applications. Configurations can be different, however all configurations
can be based on the same architectural components.
Identical configurations are easier to support. In the long term it may be much more
expensive to support multiple types of configurations than it is to invest in replacing them with
consistent configurations.
Purchasing hardware that exceeds the immediate need often saves money in the long run, as
it promotes expandable systems and reduces the need for tuning and support.
It is more cost effective to use capital dollars to improve operations than to spend support
dollars on outmoded technology. The cost of continuing to support an aged configuration is
often higher than the cost of new equipment that will improve performance and reduce
support costs.
The practice of using hand-me-down equipment perpetuates obsolete technology and can
greatly increase the support burden by increasing the number and kind of devices requiring
support and its associated costs.
IV.
Open, vendor-neutral systems standards provide flexibility and consistency that will allow
departments to respond more quickly to changing business requirements.
Vendor-neutral systems support economic and implementation flexibility.
Vendor-neutral systems also protect the state against unexpected changes in vendor
strategies and capabilities.
Technical Topics
The central help desk provides the focal point to mediate problems.
Support tools should empower both the help desk analyst and the end user with self-help
capabilities.
Best Practice 2: A single consolidated help desk design supports an enterprise model.
A consolidated help desk does not have to be physically located in one place. However, it
should have one constituency, one phone number, one set of procedures, one set of defined
services, and one set of integrated network systems management (NSM) platforms and
applications.
The implementation of the virtual data center (VDC), where many remote LANs are managed
as a single entity, supports the corresponding development of consolidated help desk
services.
Page 96 of 103
Best Practice 3: Each centralized help desk unit must provide a single point of contact (SPOC).
A SPOC minimizes user inconvenience and confusion. In its broadest sense, SPOC means
that the end user makes one attempt at contact and the help desk request is channeled by
some automated means to the organization that can best service the request.
The help desk should mediate all problems.
Best Practice 4: In order to leverage support resources and provide effective client support,
multiple tiers or levels of client support are required.
Tier/Level 1 client support should have end-to-end responsibility for each client request. The
help desk analyst should be empowered to resolve as many requests as possible. Tier 1
provides the client contact point (CCP) or call ownership, which is the single point of contact
for the end user to request a service. Organizations should retain control of the Tier 1 help
desk in order to ensure the quality of the customer relationship.
Tier/Level 2 client support provides advanced technical expertise to the tier/level 1 client
contact points. Their responsibility is to analyze the requests routed to them and resolve the
problems. Resources at this level can be composed of staff specialists and/or third party
providers/vendors.
Tier/Level 3 support is composed of highly specialized technical experts. Calls which cannot
be solved at tiers/levels 1 and 2 are routed to this level. Resources at this level can be
composed of staff specialists and/or third-party providers/vendors.
Best Practice 5: Geographically dispersed help desk units must inter-operate and share
information.
All requests for service should reside in a database that is shared by technology and
application-based help desk units serving specific constituencies throughout the state. This
process shares information and makes it possible for one help desk to electronically pass a
service request to another help desk without forcing the user to make another contact
attempt.
The use of technological advances, such as distributed processing, dynamic control of users
desktop, improved telephony, and client support software, make it possible for geographically
dispersed help desk groups to function as a cohesive support unit.
Best Practice 6: Resolution databases that contain solutions to recurring problems should be
built to improve service quality and contain costs.
Building and using a knowledge base of prior resolutions to solve problems improves the
quality of resolutions.
Help desk operations should include problem resolution links to external systems.
Implementation Guidelines
Guideline 1: Consolidate help desk services when common functions are being supported
across business units
Support resources can be leveraged more effectively when support for common functions are
consolidated.
Page 97 of 103
Private & Confidential
Service requests or problems often begin with one help desk and require the services of
another help desk. Support hand-offs and tracking are made more effective when linked
electronically.
A single point of entry function, responsible for resolving customer needs and routing cases
to the appropriate function, reduces customer issues associated with locating and obtaining
support.
Guideline 4: Identify common data elements. Enable electronic interchange of problem and
solution information.
Common data elements facilitate the electronic interchange of problem and solution
information because translation of data definitions is not required and information can be
more easily re-used.
Best Practice 2: Systems management functions for the virtual data centers should be
remotely performed.
Some examples of remote systems management services include:
Page 98 of 103
Private & Confidential
Best Practices 3: Under the Virtual Data Center concept, responsibilities of customers for
systems management are limited.
Even though the equipment is located close to the customer community, for the most part,
local user efforts should be concentrated on performing their business functions rather than
on system management tasks such as system configuration, debugging and/or backup.
Best Practices 4: System components should proactively alert in advance of failure including
predictive capability.
System generated alarms and alerts should be automatically routed to the appropriate systems
management resource. For example:
Implementation Guidelines
Guideline 1: Centralize remote systems management for mission critical applications
Guideline 3: Use integrated management suites. Use best-of-breed point products when the
integrated management suite cannot substantially meet the business requirements.
Use of integrated tools reduces the costs associated with implementation and support.
Common methods and procedures are used for bringing managed objects into the
management framework and for ongoing management of these objects.
Guideline 4: Use a Relational Database Management System (RDBMS) as the underlying store
for managed objects, policies, events, and alerts.
Use of an RDBMS facilitates access to management data for functions beyond those
provided by the management framework e.g., query and reporting tools.
Page 99 of 103
Private & Confidential
Standards
The following standards have been established to support operational systems management for
the enterprise.
Standard 1: Use SNMPv1 (simply called SNMP) protocols.
The Simple Network Management Protocol (SNMP) is a group of internet protocols that is the
standard for managing TCP/IP based networks.
It is built into the devices (e.g., concentrators, routers) in the network and in the network
operating systems of the servers and workstations.
The network management system uses SNMP to collect statistics and other information on
network devices.
SNMP is also used to send commands that control the state of network devices.
RMON products are predicted to become increasingly used in most enterprise networks.
RMON products provide packet collection, decoding and analysis to the MAC layer of the
Operating Systems Interconnection (OSI) stack using a combination of consoles and
hardware and software probes that relied on SNMP MIB data collections.
In 1992, the Internet Engineering Task Force, IETF, specified the RMON1 standard in RCF
1271. The RMON1 MIB extends SNMP capability by monitoring sub-network operation and
reducing the data collection burden on management consoles and network agents.
The RMON2 standard was approved by the IETF in January 1997 in RCF2021. RMON2
includes a new MIB to extend network monitoring into the application monitoring layer.
RMON functionality is growing to include functions like applications monitoring, report
generation and bandwidth allocation.
All major network device vendors have added RMON MIB collection capability to their
products, although the depth of implementation relative to the full RMON specification varies
among vendors and products.
The DMI standard was developed by the Desk Top Management Task Force (DMTF), which
sets specifications for the management of the desktop environment.
The DMI is a set of APIs that allow different vendor applications to consistently share the
desktop.
It sets the standard for a management platform that enables a common standardized
mechanism for systems management of the desktop while permitting vendor differentiation.
As vendors build desktops with embedded DMI standards, important desktop management
information will become available from the newer desktop units.
advantage of other less expense alternatives (ie. Tape, Fiche, etc.) for storing older data that is
not accessed as often. In many cases, the process for retention and storage is automated to the
point of being able to access Terabytes of data quickly without having the high cost of storage to
maintain it.
Recommended Best Practices
The following practices are recommended as guidelines for developing a storage management
process within distributed systems.
Recommended Best Practice 1: Structure for audit and policy management
Systems and tools selected for distributed systems should be deployed with tools for auditing and
managing storage processes. This would include the following areas:
Auditing and Reporting on space usage, aging of data/files, and ownership of data
Trend reporting for space usage to plan ahead for future needs
Set policy guidelines and auditing for user retention of data
Implement consistent routines for removal of backup (.BAK, etc.) and log files
Structure appropriate rights and expectations regarding public stores
Outlines archival rules for old data, communicating the aging process and where backups of
the data would be stored
Verify the archival process maintains a minimum of 2 backups (separate media) of files
before deleting these items. This will protect faulty recovery or failure of the media (ie. Tape
break, etc.)
Initially, setup rules and processes for accounting of space usage (automated)
In the future, design accounting process by user/group/business unit and leverage reporting
to track costs of the systems towards their proper owner
Leverage this information on the short-run for identifying high-cost owners and abusers of
space requirements
Maintain default values unless tested and proven, or instructed from appropriate resources
within the product vendor
Document changes from defaults and reasoning for changes in a Change Log Manual
Review changes semi-annually and determine if additional issues should be reviewed or
updated
Outline a common report cared for monitoring performance results, and provide online via
Web-services
Determine method of tracking a dashboard for current values and issues within the system.
This can coincide with the report card but should be managed and implemented differently
due to the timeliness of data from these mechanisms
Publish SLAs for both expected results and actuals, and educate the staff on their meanings
Outline the expectations and schedule for maintenance and communicate to the users
Provide a change management process for testing and implementing maintenance that does
not impact the users negatively and reduces risk of a poorly implemented change
Quarterly reviews of these trends, and a review of the analysis topics to identify new areas
that should be monitored