A Practical Service of Oriented Architecture - 87p

A Practical Service
Oriented
Architecture
A Vision for the use of

Information Technology at MDH
MDH Architecture
Project Team: 2007
A Practical Service
Oriented
Architecture
A Vision for the use of Information
Technology at MDH
October 2007
Approved Version 1.0
For more information, contact:
MDH Architecture Project Team
Information Technology Coordinating Committee (ITCC)
http://fyi.health.state.mn.us/comm/itcc/handouts/index.html
Produced by MDH Architecture Project Team: Version 1.0, October, 2007
Approved by the Executive Steering Committee for IT (ESC)
Table of Contents
About this document
Version 0.9 Draft for Reveiw and Comment 05/18/07 ...........................................4
Version 0.95 Draft for Approval....................................................................................4
Version 1.0 Department Approved October 24, 2007 ...........................................4
Executive Summary...............................................................................................................5
Part 1: Introduction.......................................................................................11
What is Architecture..............................................................................................................11
What do we mean when we talk about an architecture for MDH?....................11
“Accidental Architecture” ...............................................................................................12
Federal and State Architectures ........................................................................................13
Federal Enterprise Architecture (FEA) .........................................................................13
State of Minnesota Architectures .................................................................................14
MDH Architectural Background.........................................................................................14
Scope of this Project .............................................................................................................15
Process to Develop this Architecture...............................................................................16
Diagram of the Process of Developing this Architecture ......................................17
Part 2: Analysis and Requirements ..............................................................18
Strategic Planning..................................................................................................................18
Summary of Strategic Plan Analysis: ...........................................................................22
External and Internal Drivers ..............................................................................................22
Discovery and Analysis of our Current Architecture ...................................................24
Description of Current Architecture ...........................................................................24
Table: MDH Web Servers, Application Servers and Database Servers ..............26
A Practical Service Oriented Architecture

2
Part 3: Design and Architecture ...................................................................28
Architectural Principles ........................................................................................................28
Proposed High Level Architecture....................................................................................33
High Level Architecture Diagram .................................................................................35
Expanded High Level Model .........................................................................................36
SOA Example - Licensing .....................................................................................................38
Detailed Architecture ...........................................................................................................41
Service Access and Delivery Service Area .................................................................42
Service Platform and Infrastructure Service Area............................................................... 43
Application and Component Framework Service Area..................................................... 48
Service Interface and Integration Service Area ................................................................... 51
Data Service Area.......................................................................................................................... 52
Architecture Implications ................................................................................................................ 53
Application development changes ......................................................................................... 53
Continuity of Operations Plan (COOP) ................................................................................... 54
Operational efficiency ................................................................................................................. 54
SOA Governance ........................................................................................................................... 55
Part 4: Maintaining the Architecture ...........................................................59
Maintaining the Architecture ......................................................................................................... 59
Proposed Governance Framework .......................................................................................... 59
Architecture Processes ................................................................................................................ 60
Appendices .......................................................................................................................................... 63
Appendix A: MDH Architectural Team Members ................................................................ 63
Appendix B: MDH Architectural Drivers and Requirements ............................................ 64
Appendix C: Current Infrastructure ......................................................................................... 68
Definitions ............................................................................................................................................ 80
References ............................................................................................................................................ 83

3
About this Document
Version 0.9 Draft for Review and Comment 05/18/2007

This is a draft version released to MDH for review, discussion
and comment. It has some known gaps and weaknesses. However,
the MDH Architecture Project Team wanted to provide a draft for
department input while it was clear that there was an opportunity
for that input to have an impact. We sincerely value your feedback
on this proposed architecture. Comments on the proposed direction
and vision are welcome, as well as comments on the clarity of the
document.
Version 0.95 Draft for Approval

This draft is for approval by the Information Technology
Coordinating Committee (ITCC) and the Executive Steering
Committee (ESC).
Added: Maintaining the Architecture section
Added: Appendix D: Response to Comments on the Draft Version
Added: Illustrations and discussion of an example SOA application

(licensing)
Numerous changes have been made throughout the text to correct

errors and clarify the meaning.
Version 1.0 Department Approved October 24, 2007

This version has been approved by the the Information Technology
Steering Committee (ITCC) on August 8, 2207; the Executive
Steering Committee for IT (ESC) on August 21, 2007; and the
Health Steering Team (HST) on October 24.
There were minor changes and corrections including:
The Architecture Review Board now reports directly to the

Executive Steering Committee.
The document will be formatted and posted on the Internet.

4
Executive Summary
Abstract:
The Information Technology Coordinating Committee’s MDH
Architecture Project Team analyzed the department’s strategic
plans and major initiatives for information technology implications.
We developed a list of requirements and drivers that are pushing
on the department, and we analyzed the current department’s
infrastructure to see how well it could meet our needs. The project
team proposes that MDH move toward improved efficiency of
information technology operations, better availability of our
systems and an architecture based on component services that
can be reused and shared. We describe this careful evolution as
a practical service oriented architecture. This proposal is based
on the strategic direction of the department and on the need
for increased flexibility to meet the changing needs of health
information technology. It will also lead to more efficient use
of our information technology assets by reducing redundant
development and sharing expensive software components.
This architecture will require increased standardization, well

considered and deployed continuity of operations plans, new
security policies, and changes in our approach to department
applications. An architecture review board will be an important
entity to over-see service oriented policies and development.
The Architecture Problem

Ideally, the department’s investments in information technology
will support our strategic goals and objectives. However, in the
absence of explicit plans, it is easy for an organization to drift
into a situation where the over-all goals of the department are not
being addressed. This has been called “the accidental architecture”
(from David Chappell, “The Enterprise Service Bus”). When each
application and each tool is developed or selected for the particular
end or case at hand without consideration of wider implications,
it is likely that the department will end up with unnecessary
redundant systems, systems that cannot share information or
interoperate, and increased support and maintenance costs.
What is needed is a kind of strategic planning to align information

technology efforts with MDH goals. An architecture is a plan to
guide the purchase and development of computers and applications.

5
It is future directed and asks, where do we want to be with regard
to information technology in three years? Or five years?
The MDH Architecture Project

To address this problem, the Information Technology Coordinating
Committee (ITCC) determined that the development of an
architecture was its top priority project. This project is focused on
the development of a high level architecture for the department’s
technology, applications and data. It will establish an over
all approach, but not specify detailed standards and products.
There were three major parts to the project: 1) analysis of the
department’s needs and requirements, 2) assessment of ability of
the current architecture to meet those needs, and 3) design of a high
level architecture to meet those needs.
Analysis Phase
The project team looked at the department’s strategic plans and
recent initiatives for technology implications. We also examined
internal and external pressures and requirements that we compiled
into a list of “drivers”.
MDH strategic plans and projects focus on the need for efficiency
in the use of our information technology resources, better
communication with our partners, and improved integration of the
programs within the department.
The drivers are diverse, from specific CDC requirements to general

pressure to deal with the aging work force. There is a movement
toward increased system-to-system electronic communication.
More information will be extracted from an existing system
(e.g. hospital, electronic medical record) and transferred
automatically to MDH systems. MDH must be able to support
that communication. There is an increased need for flexibility and
adaptability. As our partners (local, state, and federal) implement
systems, we need to adapt to handle the formats and protocols with
which we receive and send the information.
The project team completed an inventory and an evaluation of

MDH applications, servers, and desktops. MDH is moving toward
more coordinated and standardized systems. However, there are
many opportunities for improved efficiencies and, we still have
many individual programs that have purchased the same or similar
expensive software components that have already been purchased
for department-wide availability. In the area of applications, we

6
have developed many independent systems with their associated
databases. It is challenging to integrate systems that were not
designed for a broader perspective.
Design Phase
The project team developed a list of design principles for the
proposed architecture. These principles guide the design of the
architecture and the selection of technology building blocks.
Principle 1: Customer-Centric Service Delivery

Principle 2: Department Focus
Principle 3: Department Data Focus
Principle 4: Interoperability and Reusability
Principle 5: Resilience
Principle 6: Follow State and Department Standards
Principle 7: Comply with State and Federal Statutes
Principle 8: Ownership Value Driven
Principle 9: Mainstream Technology Use
Principle 10: Department Security Focus
Principle 11: Open Standards and Open Source Software
Proposed Architecture
Based on an assessment of the drivers that are pushing the “Our over-all architectural vision is
department, an analysis of its strategic goals, and an evaluation of one where we become very efficient
its current architecture, we are proposing that the department move at the foundational operations of
information technology such as
toward a service oriented architecture (SOA). server administration and help desk,
reduce our risk of service failure
A service-oriented architecture is an approach to developing with appropriate redundancy and
back-up, and flexibly develop and
applications using independent reusable modules called services. deploy component services to help
These may be purchased software that provides services such as our programs meet the needs of the
creating maps or creating reports. It may also be modules that department.” Page 34
are developed by MDH developers. When these services are
constructed to be available in an intranet or on the Internet, and
they are constructed using a specified set of standards, they are
called “web services”.
As an example, consider applications that require a log-in. In most

cases, an application developer had to design and construct the
security structure, a module to administer the users and a log-in
module to capture the username and password. If a well tested
secure log-in module were constructed and deployed as a common

7
service, then the department’s application developers could
connect to that module. They would not have to develop their own.
Similarly, other common and program specific services could be
developed.
In an SOA, many of these services would already be available, or

would be created for future reuse. Thus, developing applications in
this environment becomes a process of creating and using services.
As more services are built, applications become a collection of
services. In a full-blown service oriented architecture, whole
applications and new services can be constructed as composites of
individual services.
Why SOA?
The advantage of reusing or sharing component services is
considerable. It would reduce the purchase and development of
redundant systems. Currently, each application development group
in the department must figure out the security and develop a log-in
system for their applications. Instead, they could use a well-tested
service.
If a business process changes, applications in an SOA can adapt

quickly by just changing the component services that are affected.
For instance, if the state chooses a different vendor for credit card
transactions, all that needs to be changed is the credit card service.
Moving toward a service-oriented architecture will allow MDH

to share expensive software components, reduce the redundant
development of many common components, and become more
flexible and adaptable to meet the expected changes in health
related information technology.
We are not alone in moving in this direction. The project team

used the Federal Enterprise Architecture (reference 4) framework
as our model for the MDH architecture. Several federal agencies
are also adopting service-oriented architectures. The Office of
Enterprise Technology released a white paper in November, 2005
advocating that the state of Minnesota move toward service-
oriented architecture. Other state health departments such as
Arizona and Massachusetts have stated their intent to deploy a
SOA.
Many of the systems that we will need to connect with in the

8
future will expect that we can consume and deliver web services.
It is important that MDH begin the measured adoption of service-
oriented architecture.
A View of the Proposed MDH Architecture

A view of the proposed architecture is provided on the diagram on
page 37.
Each dark (blue, in color) rectangular block represents a service

area that contains the building blocks of the architecture.
The Technical Reference Model from the Federal Enterprise
Architecture framework consists of a hierarchy of service areas,
service categories and service standards. In the diagram, service
area boxes show some of the categories within them.
In this diagram, moving from left to right, MDH customers,

partners and employees connect to component services and
applications with a variety of service access and delivery
mechanisms. Those services and applications interoperate with
each other and databases through protocols and other services that
are part of the “Service Interface and Integration” service area. The
interface and integration services provide the “glue” that makes
that communications and integration work.
Security is an over-riding consideration that is part of each of the

service areas. The “Service Platform and Infrastructure” service
area supports all of the services, databases and access mechanisms.
This is a conceptual diagram, and it does not designate where the

pieces of this architecture will actually be located. It describes
how users of department resources will connect to applications
and services (in the component framework) through certain access
channels. Those components run on servers and networks (Service
Platform & Infrastructure). The services connect to each other and
to databases using networking protocols and data transformation
tools. Security is an inherent concern of whole diagram.
Implementing the Architecture:

Although a complete implementation plan was out of scope for this
project, the following lists some implications of this proposal:
• Application Development: Big changes will be needed in

methods, coordination, organization, and training of MDH
application developers. A thorough analysis of MDH business

9
processes is needed.
• Operational Efficiency: Continue moving toward standards
in our operations and tools. Further automation of desktop
administration and help desk should be accomplished.
• Continuity of Operations Planning: Work toward standard
platforms. Supporting a redundant recovery site will be too
expensive if we must replicate diverse servers and operating
systems.
• SOA Policies and Processes: SOA will require new security and
service use policies and procedures.
• Architecture Review Board: We propose that an architecture
review board be created to guide the development of policies,
update the architecture, and review requests for exceptions.

10
Part 1: Introduction
What is Architecture? Architecture in Antiquity

ARCHITECTURE: (ANSI / IEEE Std 1471-2000) Seshat was the
“the fundamental organization of a system, embodied in its Ancient Egyptian
goddess credited
components, their relationships to each other and the environment,
with inventing
and the principles governing its design and evolution” writing. She
had dominion
Architecture is about design. Based on certain principles, it over accounting,
answers, how will we build and structure our applications, mathematics,
databases and computer systems? Will there be a few large historical record keeping
applications or lots of small ones, integrated databases or separate, and architecture. She was
large servers or small? We need a plan that answers these design known as ‘Mistress of
decisions based on agreed upon principles. That plan will lead to the House of Books’ and
our architecture. We want to develop an architecture that answers ‘Mistress of the House of
these questions in a coherent way so that we use our resources Architects’. Her symbol was
efficiently, and our systems work well together to accomplish a star.
public health goals. http://www.touregypt.net/
featurestories/seshat.htm
What do we mean when we talk about an architecture for MDH?
An enterprise architecture provides a systematic approach to
aligning information technology with the department’s goals and
priorities. An architecture describes the framework of applications,
databases, hardware and software that the department should move
toward to efficiently support its programs and goals. It is future
directed. Implementing enterprise architecture and the processes
to sustain it will provide the department with a comprehensive
approach to management and development of our IT environments.
An architecture is a design plan for future applications and

infrastructure. Except in special circumstances, it will be too
expensive to go back and change existing applications to comply
with the new architecture. When a system or application is being
changed for business reasons or maintenance costs, then we should
consider a redesign of the system to comply with our architectural
plans.
This project is aimed at a high-level architecture. It will provide

the basic approach to the structure of the department’s information
technology. When the department considers technology
purchases, the architecture can guide the selection of products.

11
The architecture is a necessary precursor to the development
of technical standards. It can guide their selection and maintain
interoperability.
“Accidental Architecture”
Without an architectural direction, we have no plan to guide us
in the selection of information system tools and the development
of applications. The result has been called “the accidental
architecture” (from David Chappell, “The Enterprise Service Bus”
(1)). Each application and each tool is developed or selected for
the particular end or case at hand without consideration of wider
implications. There is little over-all planning to ensure efficient
use of IT resources or that parts of it will interoperate effectively.
We end up with
1. Unnecessary redundant systems,

2. Systems which cannot share information or interoperate,
3. Increased support and maintenance costs because we are
running several tools to accomplish the same thing,
4. Less opportunity to share technical skills and knowledge,
5. Increased training when staff move from one program to
another,
6. Information technology services that are only available to
certain programs, but not others,
7. Difficulty assessing our compliance with state and federal
requirements because of a hodge-podge of systems, and finally
8. No idea about whether the systems are consistent with the
department’s priorities.
There are many reasons for the department to evolve toward an
accidental architecture. Program specific funding is the driver
for most of our technology purchases and applications. Federal
programs require certain hardware or software. The department
has considerable functional diversity – licenses, surveillance,
prevention, monitoring, records, laboratory, and analysis.
Without detailed plans and architectures, this leads to databases,
applications and hardware that are program specific.
The department has attempted to optimize its efficiency and

effectiveness at the program level. But, a system cannot be
optimized by optimizing its parts. We need to gain efficiency by
coordinating expensive services across the department so that we
can invest those gains in technology that improves our delivery of
public health.

12
Federal and State Architectures
Federal Enterprise Architecture (FEA)

As part of the Information Technology Reform Act and the Federal
Acquisition Reform Act of 1996, the Office of Management and
Budget (OMB) was charged with coordinating the development of
enterprise architecture for the federal government. Federal agencies
were required to develop a compliant architecture in order to obtain
funding.
OMB developed a high level architecture based on five reference

models:
1. Performance Reference Model: a framework for performance

measurement providing common output measurements
throughout the federal government.
2. Business Reference Model: a functional (rather than
organizational) view of the government’s lines of business and
their constituent parts.
3. Service Component Reference Model: a classification of
services that are common across the government’s lines of
business. The department could use this model to assess the
completeness of technology services.
4. Technical Reference Model: a technical framework that
categorizes the technologies that support the delivery of service
components. We use this model as a framework for our detailed
architecture.
5. Data Reference Model: classifications of data to support
appropriate sharing and use of data.
The FEA has had a broad impact on government information

technology planning. The Centers for Disease Control’s (CDC)
Public Health Information Network (PHIN) is their effort to
comply with the federal architecture. The Centers for Medicaid and
Medicare Services (CMS) are developing a Medicaid Information
Technology Architecture (MITA).
The State of Minnesota’s Office of Enterprise Technology

(OET) has used the FEA in the development of their most recent
architecture, and we propose to use the FEA’s Technical Reference
Model as a framework for identifying the needed building blocks
of the MDH architecture.

13
State of Minnesota Architectures
In 2002, the Information Policy Office (now incorporated into
OET) released version 1.0 the Minnesota Enterprise Technical
Architecture. It has been updated several times since the initial
release. Legislative initiatives and development projects within
state government must comply with this architecture to receive
state funding.
In December 2005, OET released a whitepaper from an on-going

enterprise architecture project called the State of Minnesota
Enterprise Architecture Whitepaper. This paper advocated moving
the state toward a service oriented architecture (SOA). An SOA is
an architecture based on reusable components. That architecture
project is still in progress.
MDH Architectural Background

The following timeline depicts the approximate dates of some
important state and department standards and architectures. Also,
it brackets the time span for different eras of computing at the
department. The bracketed dates are very loose and not exclusive.
There are some client-server applications being developed at
the present time, and proposed service oriented architecture
usually uses Web applications. The “service orientation” refers
to the structure of the application and the standards that it uses.
2000
M DH W eb B ased
A rc h ite c tu re
2002
1999 2000
M N E n te rp ris e W i d e
D a ta b a s e S e rv e r D e sk to p
T e c h n ic a l
S ta n d a rd H a rd w a re
A rc h ite c tu re
1999 S ta n d a rd 2002
W e b B ro w s e r 2000 W e b A p p lic a tio n
D e sk to p 2007 - 2010
1996 S ta n d a rd D e v e lo p m e n t P o lic y
S o ftw a re S e rvic e O rie n te d
E m a il S ta n d a rd A rc h ite c tu re
S u ite
(P e g a s u s ) (P ro p o s e d )
1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009
1999 - 2008
1994 - 1999 W e b B a s e d A p p lic a tio n s
C lie n t S e rv e r C o m p u t in g (C o ld F u sio n , J a v a )
(D B A S E , F o x P ro ,
O ra cle F o rm s P o w e rB u ild e r )

14
During this time span, the department has had two incarnations
of technical standards and architecture committees and several
different information technology steering committees (MITAC,
IRM Steering Committee, DISAT, ITCC).
The department developed a “Web Based Architecture” in 2000.

This architecture was an attempt to move MDH toward the
development and use of Web applications. It was the guide for
the implementation of the MDH Web Application policy and the
organization of the Web Services Unit in IS&TM.
In the data standards area, the Data Inventory and Standards

Committee (DISC), a subcommittee of the IRM Steering
Committee, developed several MDH data standards. These include:
1. Database Naming Conventions (August, 2001)
2. Race Ethnicity Data Standard (November, 2001)
3. Mailing Address Data Element Standard for Databases (May,
2002)
4. Person and Organization data Element Standard (August, 2002)
Scope of this Project
This project has a department-wide perspective. It is focusing on

how information technology is used to support the department’s
goals. Just as the department organizes and allocates staff and
financial resources to support public health, it should organize and
deploy information technology resources to effectively meet its
ends.
The scope of this project can be better understood if we look at a

model that depicts the relationships between the processes that we
use to accomplish the business of public health and information
technology components. We design and organize the processes
that are used to accomplish our objectives. Those processes are
supported by applications that access databases and run on some
kind of computing infrastructure. The following diagram illustrates
these relationships.

15
B usiness P rocesses
A pp licatio ns
Access or
Capture Run on
Info rm a tion/D ata P la tfo rm /Infra stru ctu re

Support
The purpose of this project is to develop a high-level conceptual

architecture for the department. We will not be identifying the
vendor nor model of parts of the infrastructure, but we will
describe what infrastructure services must be available.
INSIDE the scope of this project:

• High-level technical, application and data architecture for the
Department.
• A policy that incorporates the use of the architecture in
Department IT decision making.
• Recommendations for maintenance of the architecture.
OUTSIDE the scope of this project:

• Detailed architecture decisions (product and vendor) except
where there are strong existing current standards.
• Detailed analysis of the Department’s applications.
• Thorough business process analysis of the Department. This
project will not aim at changing the basic processes.
• Detailed data analysis to identify common entities and data
elements.
• Thorough analysis of information in the Department.
Process to Develop this Architecture

In thinking about architecture we might ask, how well are our
applications structured to support our goals and objectives?
Does the structure and choice of our infrastructure support our

16
applications and other goals? Is our data organized and deployed to
effectively support the department’s programs and goals. The major
process steps are outlined below. A diagram of the process is also
included.
• In order to evaluate how our architecture is meeting our

goals we need to analyze MDH strategic plans and major
new initiatives and determine their information technology
implications.
• There are many pressures and requirements that the department
needs to meet or respond to. In this step we will analyze
external and internal requirements and drivers.
• We need to assess the current MDH infrastructure in light of
our strategic goals and requirements to determine how well it is
meeting our needs.
• Develop requirements and design principles which will be used
in the development of the proposed architecture.
• Draft a high level architecture that meets our design principles
and requirements.
This project has established a team with staff from each division
or bureau to perform these steps and communicate with the
department.
Diagram of the Process of Developing this Architecture
Strategic
Plan
Architectural
info
Im plications of Plans
S trateg ic
An a lyze MD H
Plans
MD H A rch ite cture
Strate g ic Docum ent
Pla ns MD H Pa rt 3:
R equirem ents
A rch ite cture D e sig n an d
N ew Technologies Docum ent A rch ite cture
Te ch n o lo gy D rivers List Pa rts 2: D eve lo p H ig h
D riv e rs R equirem ents Analy sis an d R equirem ents L eve l
And Plans R eq u ire m ents And Assessm ent Architecture
A rch itecture D ecisions and Plan
Fede ral An a lyze
D riv e rs R equirem ents P ressures
And Plans Strategic Assessm ent of
a n d Drivers D rivers Plan D eve lo p
C urrent Infrastructure
Im plications A rch itectura l Legend
S tate D esig n D esign
D riv e rs P rincip les Principles
N eeds and P rocess
An a lyze
Pa rtne rs Pressures
C urre nt
an d Citizen Infrastructure D esign
D riv e rs Principles D ata Flow
N eeds and Plans
So urc e or
R e c eiv e r of D ata
Inventory D ata
MD H D e sig n
Divisio ns D eve lo p Princip les
H ard w are Current Infra structure D ata S tore
a n d Softw are Spre adshe et
Inve ntory
Inventory
Inform ation
Inventory D ata

17
Part 2: Analysis and Requirements
Strategic Planning
An enterprise architecture should be designed to help MDH meet
its strategic and tactical goals. Therefore, one of the important
activities in the development of this architecture is to review our
strategic plans for any information technology implications.
The department’s most recent strategic planning produced a

“Strategic Map and Strategic Profile” in November of 2005 (http://
fyi.health.state.mn.us/fadmin/hrm/workforce/materials/MDH_
strat_plan.pdf). That was followed by an “IT Strategic Map: 2006
2008” (http://fyi.health.state.mn.us/comm/esc/stratmap.pdf). Few
divisions have produced strategic plans, but the Policy Quality and
Compliance Bureau produced an “IT Strategic Plan 2005 – 2007”.
Although the department regularly develops high-level strategic

plans, it often makes decisions about major initiatives and projects.
These projects are usually based on the strategic plans, and they are
an implicit expression of strategic direction. For that reason, we are
including an analysis of the architectural implications of some of
the recent major projects within the department.
The following table lists items from these strategic plans that have
architectural implications.

18
Strategic Goal Objective or Description Architectural Implications
Document or
Project
MDH Focus on Clear This goal focuses Requires systems that can
Strategic Map Priorities for on department- share information that can
and Strategic Improving Health wide coordination in be consolidated across the
Profile Outcomes establishing priorities and department
outcomes.
Increase Policy One object of this goal One aspect of this objective is
Impact is to “Provide Credible to collect quality information
Information to Internal and provide the IT tools to
and External Policy analyze the data and report
Makers.” the findings.
Align Resources with This goal “recognizes Need to keep abreast of
department Priorities the need for state-of-the technological changes.
art systems – such as
information technology
and laboratory equipment
and facilities – to provide
essential support to the
department.”
Secure balanced and Maintaining and supporting
sustainable funding effective IT resources requires
sources continuing funding.
Leverage Resources Need effective
Through Partnerships communication tools to
maintain partnerships.
Strengthen the This goal calls for Need information systems

department’s measuring performance on that are designed to capture
Organizational a department-wide basis. the right data and to deliver it
Effectiveness to the right people at the right
time.

19
MDH IT Define and establish Need an effective
Strategic Map application and architectural plan.
infrastructure architecture.
Improve Our Ability Objectives point to Need an architectural plan
to Electronically integration, coordination, for securing and handling our
Exchange Data exchange and security of data.
data.
Strengthen IT Need an architectural plan to
Governance & mesh with IT governance.
Organization
Capacity.
Minnesota Create the • Respond to • Need an MDH
Public Health infrastructure and community health architecture that can
Information policies that enable threats. communicate with LPH.
Network (MN statewide exchange • Protect the public In fact, this project is
PHIN) of public health from serious but about developing an
information. preventable diseases architecture for public
or injury. health communication in
• Make Minnesota Minnesota.
communities healthier • Need data standards for
places to live. public health information.
• Enable consumers
to access public
health and prevention
information.
e-Health Accelerate the use of Person focused • Need an architecture that

Health Information (information across can work with electronic
Technology in all facilities) health records. It needs to
areas of the state Public- Private be flexible and adaptable
using an Electronic collaboration to accommodate record
Health Record (EHR) and communications
changes.
• Need an architecture
which can support
effective security
measures

20
Child Health Improved … health • Enable rapid access to • Need to support a
Information services statewide child health data common identifier, yet
System (CHIS) for Minnesota’s • Standardize collection, maintain data practices
children, through management, and policies.
the enhanced use secure exchange of • Need to support better
and interoperability public health data computer-to-computer
of child health • Implement routine communication within
information systems data quality assurance MDH applications.
in Minnesota. procedures • Need to develop child-
• Foster program focused tracking and
evaluation and evaluation.
assessment
Disease Implement an • Interoperate with • Need better integration
Surveillance integrated disease nation-wide health of disease surveillance
Modernization surveillance system infrastructure applications.
• Early detection of • Need flexible
disease events communications with
• Electronic disease clinics and hospitals.
reporting • Architecture needs to
• Electronic laboratory support secure electronic
reporting messaging.
• Rapid dissemination • Need data translation and
of information to formatting services
health community and • Need to support rapid
public development of reports
and maps.
Environmental Improve the • Integrate information • Need data translation and
Health (EH) environmental to support and formatting services.
Knowledge health services that improve EH practice • Need data standards.
Management Minnesotans receive in all state and local • Need flexible electronic
through strategic agencies communications.
application and • Interconnect local,
management of tribal, state, federal
environmental health and other key
data on a statewide partners to support
basis electronic exchange of
environmental health
information.
• Inform consumers
about EH information
Table 1: Strategic Plans, New Projects and Architectural Implications

21
Summary of Strategic Plan Analysis:
The MDH strategic plans and IT strategic plans point to the
need for enhanced communication with our partners, increased
department-wide planning of information technology, and the need
to keep up with technology. Many of our public health partners
have migrated to sophisticated information systems, and they
expect us to be able to electronically communicate with them.
In addition, we need to move toward improved ability to integrate

data and appropriately protect the data that we have.
External and Internal Drivers
MDH should be making information technology decisions based

on department needs and priorities, and the architecture that we are
developing should be able to support solutions that address those
needs. The needs range from specific requirements to a general
pressure that is pushing on us. We have chosen to refer to those
needs and pressures as “drivers”. They come from many different
sources, and in some cases, they are somewhat contradictory.
Appendix B contains a detailed listing and rough ranking of the
drivers that the department faces. The following list provides a
summary of the important business drivers.
1. Partner Communications: MDH has a myriad of different

partners and applications with different data formats. We need
to flexibly and efficiently handle communications with them.
2. CDC’s PHIN: MDH must meet CDC’s Public Health

Information Network (PHIN) requirements.
• Messaging -- Construction, automatic routing, encryption,

digital signatures, support ebXML protocols, SSL
compatible, compliant with PHIN Messaging Service
• Directory Services -- Contact info and roles, access control
• Object Identifier Support -- OIDs -- Globally unique
identifiers to identify organizations, code sets, etc.
• Audit trail -- Must support audit trail of data records and
access attempts to systems

22
• Vocabulary Standards -- Support system to maintain and
update coding systems
• Data Modeling -- Support PHIN Logical data model
mapping
• Operational best practices -- Clear processes and
documentation, Continuity of Operations Process (COOP)
• Authentication -- support two factors, X.509
• Authorization -- role based authorization
3. Improved Reporting: Our clients and partners need more
reports and information from MDH in order to make better
public health decisions.
4. Information Technology Efficiency: MDH needs to
find ways to efficiently provide information technology
services. We cannot afford to support unplanned redundant
systems. We need to move away from sole purpose systems/
applications and move to interoperable systems.
5. Information Security: Information must be appropriately
protected and secured. The department should consider
planning to meet HIPAA requirements.
6. Customer Centric Approach: MDH must move toward a
more customer centric approach to its information systems.
This means better administration of our users and better
integration and interoperability of our systems.
7. Flexibility and Adaptability: There are many new initiatives
in progress that will require interoperability with MDH
systems, e.g., eHealth. These projects point to the need for an
architecture that is flexible and adaptive.
8. OET’s Enterprise-wide Technical Architecture: MDH must
comply with OET’s Enterprise-wide Technical Architecture.
Legislative initiatives that do not comply will not be funded.
9. Electronic Payments: MDH must support the ability for its
customers to make electronic payments.
10. Interoperability: There are several technologies that MDH
must support in order to develop or maintain interoperability
with our partners, and to meet our customers’ expectations.

23
Discovery and Analysis of our Current Architecture
Description of Current Architecture
Applications:
An over-all architecture looks at the business functions, their
associated applications, the structure of the data with which those
applications work, and finally, the technical infrastructure that
supports the applications. A thorough analysis of the department’s
business functions and application structure is outside the scope of
this project. However, some discussion of the current application
environment is appropriate.
This section provides an over-all view of the current infrastructure.

More discussion is provided in the Detailed Architecture section
of this document where we compare the current situation to the
proposed future state. Finally, Appendix C provides information
about the inventory of hardware, software and applications which
the project team conducted.
The department has a blend of centralized and de-centralized

functions. Networking, email, and Internet services are mostly
centralized, but the divisions have considerable autonomy
regarding application development and user support. Some
divisions have integrated their applications across program
boundaries. Other applications and their associated databases have
been developed in specific program areas.
Although many of them use a common programming language,

there is little sharing of application code or data. For instance,
many applications use a table of county names and codes, but few
if any share a standard table. Similarly, many applications have a
module for logging into the application, but each of those modules
has been written for the specific application.
Few applications in the Department have been developed with

broad knowledge of the whole process including its impact on our
partners and clients. As a result, our programs tend to be unaware
of the impact of similar data collection efforts.
Application development groups in the department differ

considerably. Some have staffs that are sufficient to support several

24
applications and to fill in when particular people are absent.
Others consist of one or two people. Few development groups
in the department are able to adequately specialize so that there
are separate roles for business analysis, application architecture,
programming, database design, testing, quality assurance,
implementation, documentation and training.
Network
The department used the move to the new buildings to upgrade
much of our network infrastructure and to redesign our networks.
Our connection to the Internet is through the Minnesota Office of

Enterprise Technology (OET). They also manage the routers that
connect to our district offices, connect to the metro fiber loop, and
connect the T1 line to the Snelling Office Park.
Information Systems and Technology Management (IS&TM)

administers the internal network switches, Internet protocol
telephone switches (VOIP), firewalls, and network monitors.
We have fiber connections between the Lab Building, Freeman

Office Building and the Golden Rule Building. IS&TM also
manages domain name services (DNS) and dynamic host control
protocol services (DHCP).
Over-all, MDH networks are very robust. Potential improvements

include a faster line to Snelling Office Park, and a redundant
Internet point of presence.
Web Infrastructure
The department administers web servers for our Internet and
intranet. Those servers also support applications developed using
Cold Fusion, PERL, PHP and Python. Applications that were
developed with the Java language are supported on separate servers
using Oracle’s Application Server. Each of these production
environments has development, test, stage, and production
environments on separate servers. (See the following table.)
The current architecture has considerable redundancy to protect

against disk failure. There is no immediate recovery available for
server failures. However, at the present time, many of the servers
are identical. It would be relatively straight-forward to substitute a
stage server for a production server that failed.

25
Table: MDH Web Servers, Application Servers and Database Servers
Computing Environment
Development Test Stage Production
Web/ColdFusion
Servers Intranet/Internet Intranet/Internet Intranet/Internet Intranet Internet
Java Web
Applications
Intranet/Internet Intranet/Internet Intranet/Internet Intranet Internet
Oracle Database
Servers MIIC PHL and MIIC PHL and MIIC PHL and MIIC PHL and Others
MDH MDH MDH
Other Servers
FTP SAS/Dataflux Web Trends
(Note: MIIC is the Minnesota Immunization Information
Connection; PHL is the Public Health Lab; MDH represents
other databases that are associated with web applications; FTP is
the file transfer protocol; SAS provides statistical and reporting
capabilities; DataFlux is a data quality tool that provides GIS
coordinates and US Post Office addresses; WebTrends provides
analysis about web user activities.)
There are other web servers in the department. Some divisions

have their own intranet server, and there are many internal web
servers that run division specific applications. There are some
Internet facing servers that are managed by divisions.
Databases
Because most of our data structures (tables, files, datasets) are tied
to particular applications, we have many special purpose datasets.
Although the department has developed data standards, these have
been rarely used in department databases because, 1) the database
was created before the standards were developed, 2) the developers
did not know about the standard, and 3) meeting federal standards
was the priority.
The department has data in databases on which we would like to

report, but we do not have the tools, staff resources or training to
extract it.
Databases tend to be created for each application system. Most of

26
the large databases in the department use Oracle (the department’s
standard), but there are a few that use Sybase, Microsoft SQL
Server or MySQL database. There are many smaller databases
using Microsoft Access and Microsoft FoxPro.
Database servers to support the application and web servers

are listed in the table above, but there are many division-level
databases, as well. The department’s database servers connect to
a storage area network (SAN), which provides protection from
disk failure. The test and stage servers will act as backup for each
other. If the test database server crashes, there is a copy of the
test database that can be started up. Similarly, the two production
database servers provide backup for each other.
Desktop
The Department has at least 1200 desktop units and 620 Laptops.
Each division or bureau provides support. The department is
adopting a common software image that will provide a common
base set of desktop software and network configurations.
Additional software will be installed to meet particular user needs.

Helpdesks are set up in some division, but not in others. These
Help Desks support both internal users and external partners.

27
Part 3: Design and Architecture
Architectural Principles
Architectural design principles are the values and guidelines that
will be used in the creation of the architecture. They are similar to
the drivers that were identified in Part 2, but the drivers are focused
on business requirements. The principles guide the selection of
building blocks and the over-all structure of the architecture.
While the drivers may point to the need for a particular service, the
principles determine the quality or structure of that service. The
drivers are aimed at “what” is needed; the principles lead to “how”
will it be deployed.
Principles express values. In fact, in some architectures that is what

they are called. As a result, there can be considerable controversy
about the principles that are used to design an architecture. It is
not uncommon to have principles that are somewhat contradictory.
For instance, the performance (speed) of an application may be
hindered by ease of use or monitoring considerations, but all three
are important design principles. Designing an architecture requires
balancing several different principles.
Principle 1: Customer-Centric Service Delivery: The architecture

should be focused on the delivery of public health to the citizens of
Minnesota.
Rationale:
In order for the department to be effective in the delivery of public
health services, it must be focused on meeting the needs of the
State’s citizens.
Implications:
The architecture should be developed to support the complete
process that delivers public health services.
Principle 2: Department Focus: Architecture decisions will be

made based on the over-all value and efficiency for the state
and department, while considering the needs of individual health
programs.

28
Rationale:
Planning and coordination at the department level, with input
from the program levels, will best deliver systems that support
the department’s mission, goals and activities. Decisions based
on a department perspective will tend to have greater long-term
value than those made at the program level. However, delivering
necessary functions to department programs is more important than
the technology that is used to do it.
Implications:
Some systems will be sub-optimized. The department needs to
have a process in place to support architectural decision making at
the department level. Programs should plan their initiatives to mesh
with the department’s architecture.
However, the department has always supported exceptions to

its technical standards for legitimate business reasons. There
may be some systems that are implemented that do not fit the
architectural principles, but deliver considerable functionality to
the department’s programs. Functionality and business processes
take primacy over IT structure.
Principle 3: Department Data Focus: It is important to coordinate

and carefully manage the department’s data collection, storage,
integrity, retention, and use.
Rationale:
The department’s data may have many uses. Data is costly to
maintain, and a burden to our data providers. Data collected for one
purpose may have insufficient quality to be used in another.
Implications:
The department should analyze its business processes to identify
and coordinate data collection from its data providing partners.
Databases should be designed so that data could be shared if it
was proper to do so under the Government Data Practices Act. The
department should promote its data standards and have a review
process for the design of new databases.
Principle 4: Interoperability and Reusability: Systems will be

constructed with interoperability and reusability in mind.
Rationale:
It is difficult to foresee what systems will need to interoperate.

29
Organizational changes, new mandates, and new public health
emphases can require interoperability of systems that were seen
as separate. Designing systems to interoperate based on reusable
component services will reduce redundancy, save resources and
allow systems to change quickly to meet changing public health
needs.
Implications:
The architecture and systems that are built within it should be
based on reusable, loosely coupled components. The architecture
will need to support messaging between components. Application
developers will need to alter their approach to application design.
Support and enforcement of data standards will be essential to
achieving interoperability.
Principle 5: Resilience: The architecture will prefer systems that

are stable, robust, reliable, maintainable, flexible and extensible to
meet business needs.
Rationale:
The department and its partners and customers depend on the
availability and functionality of its information systems. Systems
that are 1) easy to manage, 2) able to scale to greater capacity, 3)
reliable, and flexible will assure that they will do what we want
when we need them. Those systems will also be more cost effective
due to extended utility.
Implications:
Appropriate availability and reliability should be designed into
the architecture and systems that are developed within it. An
assessment of recovery requirements is required when acquiring,
developing, enhancing or outsourcing systems. The architecture
must be frequently reviewed to be sure that it is following business
needs, and the technology infrastructure must be open (not
proprietary), easily modifiable and extensible.
Principle 6: Follow State and Department Standards: The

architecture will comply with state and department standards.
Rationale:
Following state and department standards will lead to: better
interoperability of systems, opportunities for reuse, easier transfer
of systems to other servers, reduced training costs, and easier
merging of systems after organizational changes.

30
Implications:
System developers and purchasers must be informed of
technology standards, and they must build time into their plans to
accommodate them. Developing systems based on standards can be
more efficient because many decisions are already made, and you
can often reuse or modify existing components.
Principle 7: Comply with State and Federal Statutes: The

architecture will comply with all relevant laws, policies and
regulations.
Rationale:
Compliance with laws, policies and regulations is required. The
department’s ability to continue to exercise its public health
mission is dependent on continued compliance with regulations.
Implications:
The department’s architecture and information technology
processes must be designed to comply with applicable laws,
statutes and policies. Changes in these mandates could drive
changes in information technology processes and applications.
Principle 8: Ownership Value Driven: Decisions on information
technology investments will balance the total cost of ownership
(costs of development or purchase, support, disaster recover,
and retirement) against added value, reduced risk, ease of use,
reusability, interoperability, current investments, and compliance with
the department’s architecture.
Rationale:
When viewed over the whole department, choosing systems based
on these criteria will lead to maximum value, and provide superior
solutions over the lifecycle of the systems.
Implications:
Up front costs for some items might be higher, but that will be
balanced by reduced long-term costs. Products that can be reused
and shared should be strongly considered because they can grow in
value over time.
Principle 9: Mainstream Technology Use: Architecture will be

based on industry-proven, mainstream technologies except in those
areas where advanced higher-risk solutions provide substantial
benefit.

31
Rationale:
The state does not want to be on the leading edge for its core
services. Risk will be controlled.
Implications:
We will not usually be early adopters of new technology. However,
we will want to retire obsolete technology to reduce risk, too.
Principle 10: Department Security Focus: The department’s

systems and information will be secure from unauthorized access,
modification, or destruction, and that security will be coordinated at
the department level.
Rationale:
In order to comply with the law and accomplish the department’s
mission, information must be safeguarded against inadvertent or
unauthorized alteration, sabotage, disaster or disclosure. Policies
and processes are best implemented at the department level to
provide adequate management and assurance of appropriate
security.
Implications:
The architecture must support the department’s security policies
and processes. Any systems that are implemented within it must
also comply. Security must be designed into systems to begin with,
not added later.
Principle 11: Open Standards and Open Source Software: The

department will give preference to open standards and strongly
consider open source solutions.
Rationale:
Non-proprietary systems based on international, national and state
standards will provide the department with greater ability to create
adaptable, flexible and interoperable designs. An architecture
based on standard formats, protocols, and computing languages
that are not controlled by one vendor will provide more flexibility
and choice in the selection of products. It will also insulate the
department from unexpected changes in vendor strategies and
capabilities. In addition, open source solutions offer dramatic cost
savings for license fees and ongoing maintenance. Many open
source products are well supported, based on open standards and
full featured.

32
Implications:
Open standards do not exist for all parts of the architecture. They
should be given preference when they do exist, but it is understood
that we will have a blend of judiciously selected proprietary
solutions and open standards. Product decisions should consider
open source alternatives in light of the ownership value principle.
Free software can be very expensive to implement and support, but
it can also produce cost savings.
Proposed High Level Architecture

Based on the department’s strategic direction to improve
interoperability and integration, the business drivers that we
must respond to, and the architectural principles that express the
values we should follow in designing our information technology
infrastructure, we propose that the department should move toward
an architecture based on component services. This will allow the
flexibility and adaptability that is needed to adjust quickly to the
changes in health related technology. By designing or purchasing
services for reuse, we can reduce the heavy cost of duplication; and
by selecting our services based on standards; we can improve the
interoperability of our systems.
Service oriented architecture, or SOA, is a term that is

currently the focus of considerable hyperbole and posturing
among IT vendors. It is also being used quite effectively by many
organizations. SOA is often associated with a thorough business
process analysis of an organization, development of services
to support those process based on certain technologies, and an
underlying infrastructure that allows discovery and coordination
of those services into applications. The complete SOA approach
incorporates a sea of new technologies and acronyms such as
enterprise service bus (ESB), business process execution language
(BPEL), web services description language (WSDL), universal
description discovery and integration (UDDI), security assertion
markup language (SAML) and mechanisms to govern the use
of components. It would involve a complete overhaul of our
application development approach, major investments in new
technology, establishment of new policies, and considerable
training. This is probably in our future, but we are not advocating
immediate implementation of this full-blown approach.

33
A more practical service-oriented approach to choosing and
developing systems will provide the Department of Health with
considerable benefit. It will establish a unifying concept for
the direction in which we want to move, and that will guide
our selection of products in the future. It will also improve the
opportunities for integration, and reduce unplanned redundancy.
In a practical service oriented approach, MDH will need to evolve

into the adoption of new technology. We should identify, deploy,
and support common services. A few new applications should
be developed using SOA techniques. Application development
teams need to become familiar with SOA and test its capabilities.
We should look for opportunities and coordinate how we adopt
service orientation. The infrastructure building blocks should be
prioritized, and implemented as needed with new applications.
As the need arises, we can enhance our infrastructure with special
tools that will allow us to better develop, support and maintain
services and applications.
Our over-all architectural vision is one where we become very “Service is government’s only
efficient at the foundational operations of information technology business. SOA should be its
architecture. “
such as server administration and help desk, reduce our risk of
service failure with appropriate redundancy and back-up, and – Paul W. Taylor, Chief Strategy
flexibly develop and deploy component services to help our Officer, Center for Digital
programs meet the needs of the department. Government, (reference 2, page 2)
We are not alone in moving toward a service oriented

architecture. Other state health departments, state governments
and federal agencies are also moving in this direction.
• The State of Minnesota’s Office of Enterprise Technology
published a whitepaper (reference 8) which advocates that the
state move toward a service oriented architecture.
• The states of California and Massachusetts have published
architectures which focus of service orientation (reference 6).
• Public health departments in Arizona and Massachusetts are
adopting SOA.
• Federal agencies like CDC and CMS (Centers for Medicaid and
Medicare Services) are moving toward SOA. In fact, one of the
best primers on SOA is “MITA Service Oriented Architecture –
A Primer” (reference 3). The Medicaid Information Technology
Architecture (MITA) is the new direction that CMS is moving
toward.

34
High Level Architecture Diagram
In order to organize all of the building blocks that go into an
architecture, we have chosen to follow the categories of technology
that are provided in the Federal Enterprise Architecture (FEA) that
was discussed above. We have made a few modifications to its
structure.
The diagram on the right provides a very high level picture of what
Application & Component Framework

we are proposing.
Service Interface and Integration

MDH Customers and Employees
Services Access and Delivery

It depicts the high level structure of the department’s proposed
Data Service Area

architecture. Each dark pillar and row represents a service area that
contains the building blocks of the architecture. Later, we will drill
down into each service area to identify the detailed building blocks
within it.
In this diagram, MDH Customers, partners and employees connect

to services and applications with a variety of service access and
delivery mechanisms. Those services and applications interoperate
with each other and databases through protocols and other services
that are part of the “Service Interface and Integration” service area.
Service Platform and
Security is an over-riding consideration that is part of each of the Infastructure
service areas. The “Service Platform and Infrastructure” service Security
area supports all of the services, databases and access mechanisms.

35
Expanded High Level Model
The Technical Reference Model from the FEA framework consists

of a hierarchy of service areas, service categories and service
standards. In the diagram on the next page, which we based on a
diagram of California Enterprise Architecture (7), we expand the
service area boxes to show some of the categories within them.
Boxes on this diagram represent service areas and the elements
within them are service categories. In a following section, the
service categories are discussed in detail.
This is a conceptual diagram, and it does not designate where the

pieces of this architecture will actually be located. It describes
how users of department resources will connect to applications
and services (in the component framework) through certain access
channels. Those components run on servers and networks (Service
Platform & Infrastructure). The services connect to each other
and to databases using middleware and data transformation tools.
Security is an inherent concern of the whole diagram.
In the scope statement for this project, we were to develop a high

level application, technical and data architecture. In this document,
the application architecture will be covered in the Component
Services Service Area, and the data architecture will be included
within the Data Services Service Area.

36
37
M D H C u s to m e rs
L o c a l P u b lic H e a lt h
F e d e ra l A g e n c ie s &
an d G r a n t ee s C it iz e n s & V is it o r s M D H E m p l o ye es
G ra n to rs
D ata
Fax
N etw o rks
Tran sfer
M a il
b
Phone
& F ilin g s
W e b P o rta l
T ra n s fe rs
In P e rs o n
P a ym e n ts &
O n -lin e F o rm s
O n -lin e S ta tus
S e r v i c e A cc es s & D e l i v e r y
S to rag e
A u th e n ti c a ti o n / S i n g le S i g n -O n In t e r n e t /In t r a n e t /E x t r a n e t A cce ss C h an n e l s
Id e n t i t y P r iv a c y a n d D i se ase S u r vei l l an ce
S erv e rs / C o m p u ters
A u th e n ti c a ti o n
D i r e ct o r y S er vi c e s O u t b r eak an d C o m p l ai n t
I n vest i g a t i o n
E -F o r m s L a b o r a t o r y T e s t in g
P aym en t P r o ce sse s E m e rg e n c y P re p a re d n e s s
P r o v i d e s er vi ce s f o r
A n al ysi s , S t a t i st i c s, G I S
U n d e r s e r v e d P o p u la t io n
D eliv ery S e rv ers

P r e s e n t a t io n
L ic e n s in g
R e co r d s M an ag em en t
(W eb , A p p , D atab a se, F ile , etc.)

V i t a l R eco r d s
S ecurity
M e s s a g e T r a n s la t io n
C o m m o n S e rv ice C o m p o n en ts
A d d re s s D i sea se P r even t i o n
H ealth P ro g ra m S erv ice C o m p o n en ts
st an d a r d i z at i o n G u i d an ce
(E xam p les o f co m m o n s erv ice co m p o n en ts)
In clu d es S e cu rity, P resen tatio n , an d B u sin e ss L o g ic

(E xam ples of potentia l ap plications an d services)
S a fe ty M o n i to ri n g
S e rvic e P la tfo rm & Infra s tru c tu re

A p p lic a tio n a n d C o m p o n e n t F ra m ew o rk
O th e rs ( W a t e r , F o o d , F a c il it ie s )
A p p licatio n D ev elo p m en t
M innesota D epartm ent o f H ealth A rchitecture
S e r v ic e In t e r f a c e & In t e g r a t io n
D a t a T r an sf o r m a t i o n M id d le w a r e A p p l i cat i o n I n t eg r a t i o n
D ata
D ata
D ata
D a ta
A re a
D eskto p H a rd w are/S o ftw are

S h arin g
C o n text
S e rvic e
D esc rip tio n

SOA Example - Licensing
Consider the development of an application P ro g ra m m in g M o d u le s fo r a
used for professional licensing (Mortician, L ic e n s in g A p p lic a tio n (s o u rc e c o d e )
Nurse, etc.). That application would require L o g -in

several different modules. In our current
A d m in iste r U se rs
development approach, the programmers
would have to develop and test each C h e ck o n cu rre n t lice n se
one, and then they would compile the
C o m p iled in to a s in g le file
V io la tio n s ch e ck w ith
application into one file to be deployed D e p a rtm e n t o f P u b lic S a fe ty
on an application server. This would T ra n sla te a n d L o a d D a ta fro m
P u b lic S a fe ty
require the developer to create parts of the
C re d it C a rd p ro ce ssin g lic e n s e .e a r
application that would allow the person
to log-in, to administer the users, to check Issu e N e w lice n se
for current license status, to check with
L ice n sin g R e p o rts
the Department of Public Safety (DPS)
for certain violations, to process credit S e n d p re -e xp ira tio n n o tice
card transactions, to check on continuing S e n d e xp ira tio n n o tice
education, and other processing.
O th e r lice n se p ro ce ssin g
The accompanying illustration depicts some

of the possible modules that would need to be developed and their
subsequent compilation into a file called “license.ear” (assuming
we are programming in a language called Java). That file would
be deployed on an application server as shown in the following
diagram. In order to check with the Department of Public Safety,
we may need to periodically transfer a file to our database. We
also need to keep user log-in information in our database for the
application.
In te rn e t
A p p lic a tio n
Example: Professional
C re d it C a rd
P ro c e s s o r S e rv e r
T he com piled file is deployed
on an application server. Licensing Application
lic e n s e .e a r
Current Application
Deployment Approach (not
showing firewalls)
S ta te o f M in n e s o ta N e tw o rk
D a ta b a s e S e rv e r
D e p t o f P u b lic
S a fe ty L ic e n s e d a ta b a s e
DPS
U s e rs
D a ta
D P S data m ight be
loaded from a regular
file transfer.

38
In a SOA environment, the application developer would use
several existing services or create services that could be used
by this application as well as others. The application might look
like the following. The program would use (“run”) independent
modules called “web services” intermixed with some code that was
specific to the application.
The resulting application would be deployed E xam p le: P ro fessio n al L icen sin g A p p licatio n
to the application server, but there would be S O A A p p licatio n D evelo p m en t A p p ro ach
several modules external to that application. (W S = W eb S ervice)
They would be available for other department C o d e fo r L icen sin g
applications, too. A p p licatio n
Now, the credit card module will be a web

service created and deployed by the Office of R un Log -in W eb S ervice
Enterprise Technology for use by any state R un U ser W S
agency. The log-in web service will be a
R un License C heck W S
module that any application in the department
C o m p ile d in to a s in g le file
can use. It could rely on directory services R un D P S C heck W S
that are hosted at the Department of Human
Services. The check with the Department of R un T ranslate and Load W S
Public Safety could be a web service that they licen se .ear
R un C redit C ard W S
provide. This would eliminate the need for
periodic file transfers. Sending pre-expiration Issue N ew license
notices and final expiration notices would R un R eporting service
be done by a web service created for that
purpose. It would also be available to other R un N otice W S
department programs. The following diagram R un N otice W S

shows how this might look.
O ther license processing

39
E x a m p le : P ro fe s s io n a l L ic e n s in g A p p lic a tio n
S O A D e p lo y m e n t A p p ro a c h
(n o t s h o w in g fire w a lls )
A p p lic a tio n
S e rv e r
In te rn e t lic e n s e .e a r
R e p o rtin g S e rv e r T ra n s la te a n d L o g in W S
C re d it C a rd
P ro c e s s o r L o a d S e rv e r
User W S
T ra n s la te a n d
R e p o rtin g W S Load W S L ic e n s e C h e c k
WS
N o tic e W S
S ta te o f M in n e s o ta N e tw o rk
D e p t o f P u b lic D e p a rtm e n t o f OET D a ta b a s e S e rv e r

S a fe ty H u m a n S e rv ic e s
L ic e n s e d a ta b a s e
D ire c to ry
DPS Check w s C re d it C a rd w s
S e rv e r
DPS
U se rs
D a ta
T hese are not needed

in this database because
they are handled at the D P S
and the directory server
Another example: Immunization system data transfer across state

boundaries is shown below.
Component Services Example

Immunization Data Exchange Between
Neighboring States
The Minnesota Immunization Information

Connection (MIIC) is Minnesota’s
centralized repository for immunization data. Immunization
providers throughout the state use this system to see what shots
have been given to their patients from any clinic where they have
previously received shots.
Minnesota residents living in cities close to the borders commonly

go across state lines to receive health care. When shots are given
in clinics across the border, it is important for this shot record to
be updated in the patient’s home state so that clinics that they visit

40
in the future will have access to the shot record to know what the
patient is due for next. Also, public health follow up occurs at
the home county level and access to the shot record may show a
child who is up-to-date for vaccinations and save the county from
needless follow up activities and save the parents from receiving
unneeded letters and phone call reminders.
A potential use of web services deals with background

communication of data between applications. If an immunization
is entered into MIIC for a patient who lives in North Dakota,
a process would be triggered that would call a web service to
package a message into HL7 messaging format perhaps using
a mapping product such as “Rhapsody”. The resulting message
that contains the patient’s demographic information and shot
information is then sent to another web service, such as PHIN
MS, that encrypts the data and sends it off to the North Dakota
application. Sending of data from the North Dakota application to
MIIC about Minnesota residents would happen in reverse.
N orth D akota
D epartm ent of H ealth
Im m unization S ystem
D ata
T ransform ation
H L 7 T ranslator
M essaging S ervice S ervice
(P H IN -M S ) (D atabase to H L 7)
M essaging S ystem
Internet M D H N etw ork
Im m unization
A pplication (M IIC )
Detailed Architecture
The following framework, based on the federal enterprise

architecture, is one way to categorize all of the important building
blocks associated with information technology. If one asks, where
does Microsoft Word or the Java programming language fit in the
framework, we should be able to tell you. There is a table for each

41
service area, and examples of the kinds of standards within the
service categories. Each service area table has a description and
discussion following it.
Service Access and Delivery Service Area

Description: The Service Access and Delivery Service Area defines
the mechanisms for accessing and delivering department services
to its employees, partners, and the public. The standards in this
area define how users will connect to department applications and
how the department will deliver services to our partners.
Service Access and Delivery Service Area

Service Category Service Standard Examples of Standards
Access Channels Web Browser MS Internet Explorer,
FireFox
Wireless/PDA Blackberry
Collaboration/Communications E-mail, FAX
Other Electronic Channels
Internet/Intranet/Extranet Internet HTTP, HTTPS
Intranet HTTP, HTTPS
Virtual Private Network Juniper, Cisco
Legislative/Compliance Section 508, Accessibility
systems
Supporting Network Services SMTP, MIME, IMAP, DNS
Authentication/Single Sign-On Identity Management Oracle Access Manager
Certificates SAML, PKI
Related Issues:
• Separation of content from the way that it is presented will
facilitate the delivery of information in multiple formats to fit
different devices (cell phone, PDA, tablet PC).
Current Situation:
• Department applications use different user interfaces.
• There is little support for alternate devices.
• Department applications have their own log-in procedure,
usernames and passwords.
Future State:
• Users can access department systems and complete transactions
using a variety of devices based on standard protocols and
formats.

42
• Department services are available at a time convenient to them.
• Department applications are Web enabled, even if they are
internal applications.
• The department supports computer-to-computer connections
and transactions.
• A common authentication service will be used by MDH
applications. Users will have one username and password.
• MDH will support a single-sign-on capability that will allow
users to log-in to an MDH application and start a second
application without logging in again, assuming that they have
the authorization to run that application.
• The department will support certificates (PKI or SAML).
Associated Service Categories:

• Access Channels
The devices that users will use to connect to the department are
access channels in this framework.
• Internet/Intranet/Extranet
Provides the connection between access devices and department

services based on the level of access that the user has been
granted.
• Authentication/Single Sign-On
Authentication is the process of verifying that a user is

who they say they are. This usually involves a log-in with a
username and password. In single-sign-on, a user only needs
to log in once to a network or portal, and they are able to
run applications without logging in again. This assumes that
they are authorized to run those applications and have been
assigned with appropriate roles/rules/privileges to access
various systems. Some applications may require additional
authentication information. This may be a second password,
an electronic key, or some physical attribute (retinal scan,
fingerprint, etc.).
Service Platform and Infrastructure Service Area

Description: The Service Platform and Infrastructure Service Area
provides the underlying framework for applications and service
components to operate. It also describes the basic configuration of
desktop systems.

43
Service Platform and Infrastructure Service Area
Networks Wide Area Network
Local Area Network
Video Conferencing
Storage Storage Area Network (SAN) HP EVA
Back-up and Recovery CommVault, HP Tape Library
Server/Computers Operating Systems Solaris, MS Windows, Linux,
Novell
Hardware Sun Sparc, Intel based
Peripherals Printers, Scanners
Delivery Servers Web Server Apache
Database Server Oracle
Application Server Oracle Application Server,
Cold Fusion
File Server Novell
Print Server Novell
Other Servers Oracle Portal
Application Languages Java, Cold Fusion, SQL, PERL
Development Integrated Development Environment JDeveloper, IntelliJ, Adobe
(IDE) Studio MX
Software Configuration Management Concurrent Versioning Sys
(Managing versions, issues, change, tem (CVS), Change Manage
deployment, and requirements) ment Application, Bugzilla
Test Management JUnit, Stress testing, Security
testing, Failover testing
(Includes functional, usability, perfor
mance, stress, security, reliability, and
configuration testing)
Modeling MS Visio
Desktop Hardware/ Operating System MS Windows, Linux, Solaris,
Software Mac OS X
Desktop Computer Hardware Laptop, Workstation, Tablet
Desktop Software MS Office
Desktop Administration Novell’s Zen
Current Situation:
• There is considerable standardization on department-level
Internet and intranet systems. However, many MDH programs
are using diverse operating systems, languages and databases.

44
• The department is moving rapidly toward effective local
reliability – clustered servers, fail-over databases, and virtual
storage (SANs and RAID disks). However, separate servers are
still used for many functions, and most of them have low CPU
utilization rates.
• Application development: Developers across the department
uses a wide variety of languages, frameworks, development
environments, methodologies, and management tools. There
is little knowledge of constructing applications based on
component services.
• Application developers operate in isolated groups. There is
little real sharing of information between them. Some of the
groups are too small to adequately support all of the necessary
application development functions, such as business analysis,
modeling, use cases, programming, testing, application
architecture, application security, quality control, and database
design.
Future State:
• The department needs to continue to move toward standard
languages, operating systems and databases. This will provide a
basis for more efficiency in support and maintenance, and make
a disaster recovery site economically feasible.
• The department will move toward significant use of server
virtualization, a method for running several virtual servers on
one hardware server. This would reduce the numbers of servers
that we need to support. It also allows virtual servers to be
easily moved to different hardware for failure recovery.
• Developing, supporting and maintaining applications
throughout their life cycle require several separate skills.
Application development teams need to be large enough to
allow some specialization and coverage. In addition, with many
of our application being deployed on the Internet, we cannot
risk having an application developer with too little security
skill developing a flawed application. Application development
should be performed at division or bureau level.
• Communications between application development teams must
be substantially improved in order to make use of common
services and provide adequate security.

• Networks
Networks provide the connections, protocols, routers and

45
switches that allow data, voice, and video to be transferred
from place to place. Networks also constrain traffic to
appropriate channels.
Network performance and security are key parts of a service-

oriented architecture. If applications are constructed that rely
on services that are available over a network, the network speed
and reliability is critical to the performance of the application.
• Storage
Storage refers to the disks and tape systems that store
information that is used by our users and applications.
Most of our systems provide redundancy to protect data if a

disk crashes. Some systems have data that is stored at both the
Golden Rule Building and the Orville L. Freeman Building
so that if a data center at one of the buildings failed, the data
would be available at the other building.
• Server/Computers
Server/Computers refers to the computers that we use to run

our applications and services.
This is a category where real efficiencies are possible. The

department should move toward more standardization and
manageability. This also makes a remote recovery site more
feasible.
MDH should be exploring server virtualization technology.

This would allow the department to run multiple functions
on the same hardware, and obtain much better use of our
computing resources.
• Delivery Servers
Delivery servers are software that provide special services

to support applications or user interfaces. They include Web
servers, application servers, database servers, file servers and
print servers.
These servers constitute a considerable investment in license

fees and continuing support costs. It would be desirable to

46
consider using open source software for some of this need.
• Application Development
Application development refers to the processes of 1)

determining requirements, 2) designing the application,
3) designing the database, 4) building the application
(programming), 5) building the database, 6) testing the
application, 7) deploying the application, and 8) maintaining it.
A service-oriented architecture will have a major impact

on application development. Constructing applications by
orchestrating services is a huge change from our current
approaches. Each of the processes listed above can be
significantly affected by a service-oriented architecture
approach. As a result, we are advocating an incremental
implementation of SOA.
We should focus first on a few common services and train our

developers how to use them. Also, developing clear security
approaches and policies for those services will provide an
important foundation for later service adoptions.
One key will be enhancing communication mechanisms

between developing teams. We want to prevent the
development of similar components if they already exist.
We should consider a component registry that will store
information about available services and allow automatic
discovery and connection. We may also need to find ways
to reward programmers for developing using services when
it is appropriate. Moving toward standard methodologies
and development environments will also contribute to better
communication between developers.
A statement of direction regarding our architecture needs to

be included in RFPs sent out for any outsourced application
development.
• Desktop Hardware/Software
Desktop Hardware/Software refers to the physical device, its

operating system, and the applications that are available to a
user.

47
We need tools to efficiently support and administer the
department’s desktops.
Application and Component Framework Service Area

Description: The component framework provides the foundation
for the integration and deployment of applications and services
in the department. This is the heart of how we should construct
applications – our application architecture. The design of future
services and applications should incorporate interfaces that allow
interacting with other programs. Components can be large or small,
written in different languages, and may run on different servers.
Application and Component Framework Service Area

Presentation Interface Static Display HTML
Dynamic Server-side Display JSP
Content Rendering CSS, XHTML
Wireless/Mobile/Voice
Business Logic Business Rules Rules4J
Security Identity Management Oracle Access Manager
Authorization Oracle Access Manager
Certificates SAML, PKI (X.509)
Related Issues:
• The department needs to commit to the adequate support and
governance of our common services.
Current Situation:
• Department applications have become silos of information.
They use different data formats for the same elements, use
different user interfaces, and have limited capability to integrate
with other systems.
• There is little support for alternate devices such as cell phones
or PDAs.
Future State:
The department’s applications will fall on a continuum from
completely stand-alone to completely component based. Gradually,
we will move toward more component-based applications. If
we can build an application using existing components or create
components that can be re-used by future applications, we should
do that.

48
The component framework will consist of two different types What are Web Services?
of components, although there will be some overlap. Some
Web services are independent
components will be very health program specific. For instance, components that have a
some laboratory components may not have any use in other particular web address (URL). The
department programs. In the diagram, these are referred to as architecture of web services is the
“Line of Business Service Components”. Other components scope of the W3C Web Services
Architecture Working Group. It
may be usable by any department programs. A common log-in is possible to construct service-
component could be used in many applications. In the diagram, oriented architectures without
these are referred to as “Common Service Components”. using web services, but their
popularity makes it essential that
the department becomes fluent in
Service components support reusability, flexibility, and their use. They are basically a web
interoperability. To obtain a benefit from reusability, two kinds of application that follows certain
rules. Those rules are based on
analysis need to be performed: 1) an identification of the common several international standards
service components that can be used by many applications, and such as:
2) a functional analysis of the department’s programs needs to
1. Extensible Markup Language
be performed to identify those functions that could be served by (XML):
a particular component (line of business service component).
2. Hyper Text Transport Protocol
The Federal Enterprise Architecture’s Service Reference Model (HTTP):
can help with the first analysis. That model identifies common
crosscutting functions in any governmental organization. The 3. Web Services Description
Language (WSDL – often
second analysis could be performed as part of the business analysis pronounced “wiz-del”):
stage of any new application.
4. Simple Object Application
Protocol (SOAP):
Common service components from the first analysis will be usable
by many department programs. These components need sufficient 5. Universal Discovery,
Description and Integration
support so that MDH developers are aware of them, can easily use (UDDI):
them, and can get expert help, when needed. Here is a partial list of
suggested common service components: Web services are computer
programs that can be written in
1. Identity management services languages like Java or Cold Fusion.
2. Directory services Because they communicate via
3. Electronic Forms the international standards, an
application written in Java could
4. Reporting tool use a web service written in Cold
5. Statistical analysis service Fusion or some other language.
6. Geographical Information Systems (GIS) service Because they use standard web
addresses and HTTP, they do not
7. Records management service usually require special firewall
rules for access and use.
Some examples of line of business components are provided
below:
1. Licensing
2. Disease Case Management
3. Lab Result for Disease Case
Sometimes, an application should be constructed with components

to improve flexibility and interoperability, even if it is not likely

49
to be reusable. When changes in the business process occur, Composite applications:
a component can be replaced without affecting the rest of the
application. Most components should be constructed using Service components based on
web services standards can be
web services standards. This will provide opportunities for combined to produce complete
interoperability. composite applications. A
programming language called
the business process execution
Security: language (BPEL – pronounced
In a typical application, a user is identified (authentication) and bee-pel) provides the glue to
given appropriate access to the parts of the application that they combine several web services
have permission to run (authorization). Applications based on into a single application. That
composite application could have
web services or other service components must have mechanisms an end user interface or it could be
for authenticating and authorizing access to the individual another web service. This process
components, but the user should not have to log in again. There of combining several services
together into an application is
are several standards that are available to accomplish this, but they called orchestration.
are not currently being used in the department. We will have to
deploy these new technologies in order to control access to service
components and interoperate with our partners in a secure way.
Most of the standards involve using an electronic certificate that is

obtained when a user initially logs into an application. This could
be a certificate for public key infrastructure (PKI – sometimes
referred to as X.509 from the International Telecommunications
Union standards) or a certificate based on the security assertion
markup language (SAML – pronounced sam-el). These certificates
would be issued and controlled by the department, or we could
agree to accept certificate from trusted partners. This whole
infrastructure is part of digital identity management.
Component Services Guidelines:

• Where appropriate, applications and services should be built to
deliver and consume web services.
• Standalone or legacy applications may have web services
interfaces which will allow them to interoperate with other
systems.
• Services and applications are constructed to closely match the
department’s processes – ideally, after the processes have been
improved.
• Application development will be less building from scratch
and more orchestrating component services to build composite
applications.
• Key common services such as identity management, generating
reports, and geographical information systems would be
deployed and adequately supported department-wide.
• Department Web applications would have a common interface

50
• Security of our applications and services would be coordinated
and directed from a department perspective.
• Some applications may not be good candidates for a component
approach.
Service Interface and Integration Service Area

Description: The Service Interface and Integration Service
Area defines how services and applications will interact and
communicate with each other. It provides the protocols that allow
services to be discovered, connect to those services, and transform
data to achieve integration. This is the glue that allows systems to
interoperate.
Service Interface and Integration Service Area

Middleware Messaging PHIN MS (ebXML), SOAP
Adapters
Enterprise Service Bus Cape Clear, Mule
Data Transformation Data Format/ Classification HL7, XML
Data Types/Validation XML Schema, DTD
Data Transformation XSLT
Application Integration Service Discover UDDI
Service Description/Interface WSDL
Integration/Orchestration BPEL
Current Situation:
• Most interoperability is by ad hoc agreement on the protocols
between two systems that we want to share data.
Future State:
• A common service will provide data translation and mapping of
one set of codes to another.
• A common service will provide messaging services
• An orchestration engine will be available to combine service
components into complete applications.
• A component registry will store information about available
services and allow automatic discovery and connection.

• Middleware
Middleware provides the connections and transport of

51
information between applications or services.
• Data Transformation
Data Transformation Tools format data and translate between

different formats
• Application Integration
Application Integration tools allow applications to find services

that have been published, determine what the service does,
use the published service, and to create new applications as
composites of several services.
Data Service Area

Description: The Data Service Area pertains to the structure of the
department’s data assets. This includes where data is located and
how it is grouped, and how it is defined and described.
Data Service Area

Data Description Data Inventory ISO/IEC 11179 Metadata
Registries
Data Dictionary ISO/IEC 11179 Metadata
Registries
Data Context Taxonomy XML topic maps, Web On
tology Languarge (OWL)
Data Sharing Content Management Stellant, Vignette
Document Management Vignette
Database Connectivity JDBC, ODBC
Related Issues:
• Some department datasets do not have data stewards, nor do
they have clear policies about monitoring, auditing, accessing
and granting permissions.
Current Situation:
• The department has a data inventory and a data dictionary
application, but there is no current process for keeping the
information up to date.
• There are numerous codes for the same entity within the
department. For instance, a particular clinic might be stored in
several systems with a different identifying number.

52
Future State:
• Tables of common information like clinics or counties
should be stored in a common area with clear ownership and
administration.
• The department’s important datasets are thoroughly described.
• In some cases, the department should move toward separating
public and private data.
• We should begin planning to encrypt all private data as it is
stored in the database.
• We should develop standards and a review process for the
creation of databases.

• Data Description
Data Description tools describe the structure and format of the

department’s data.
• Data Context
Data Context refers to the where data resides in a subject

hierarchy or taxonomy.
• Data Sharing
The Data Sharing category refers to servers that organize

and make data available and to protocols for connecting to
databases.
Architecture Implications
It is outside the scope of this project to develop a complete

implementation plan for this architecture. However, this section
focuses on what changes would be needed at MDH as part of its
implementation. We also provide a rough timeline of architectural
changes that might be followed.
Application development changes

Moving toward a service oriented architecture at MDH would
require significant changes is how we develop applications. At a
minimum, it would necessitate the following:
1. Training for application developers in constructing and using
services.

53
2. Creation of application development guidelines to provide
direction about how we will do service orientation in the
department.
3. Increased coordination between development teams so that

each is aware of available services and is using them properly.
4. Establishing development teams of sufficient size, division

level or greater, to provide the capacity for specialization and
coverage. Managing the life cycle of an application has become
more complicated. We need to develop skills for business
analysis, modeling, database design, database construction,
programming, and testing in an environment where we are
cognizant of the department’s goals and other programs’ goals.
We also need to assure the security of our applications. It is
unrealistic for small programming teams to be skillful in all of
these areas.
5. Establish an Application Developers User’s Group that meets

monthly with complete Division representation, similar to
Networkers.
Continuity of Operations Plan (COOP)

Although the department has not yet fully identified its continuity
of operations requirements, if we are to set up a redundant site
to be used in a disaster, we need to work toward using standard
platforms. It is evident from our inventory that we have a several
systems running on different platforms. The cost of supporting
redundant systems for all of our servers and operating systems will
be prohibitive. We will need to restrict what can be supported in an
emergency, and any systems that need to be up and running should
all use the same platform.
Operational efficiency
One of the requirements of this architecture, derived from strategic
plans and funding constraints is to be efficient in our use of
information technology resources. Efficiency gains are feasible
in many of the operational areas of IT. Gains in these areas will
allow increased resources to be invested in improving public health
applications and integration with our partners.
We have numerous servers that are idling most of the time – we

are not making use of their processing capability. Technologies,
such as server virtualization, which allows several virtual servers

54
to run on one physical server, can substantially improve our server
processing usage. It will reduce the number of physical servers that
we need to purchase and support.
In order to gain efficiency, we need to continue to pursue standards

in our platforms and operational tools. This will allow further
automation of common tasks like desktop configuration; help desk
tickets; and file and print services.
SOA Governance
Although this project will not develop a complete implementation
plan for this architecture, adopting service orientation has some
significant implications. We have proposed an incremental
approach to service orientation, and the following provides a broad
plan for moving toward it.
Over-all SOA Guidelines

• Over-all SOA Guidelines: Criteria for when to use component
services will be important. Service orientation is more trouble
– for stable, well-understood processes SOA is not needed. Use
SOA where flexibility and agility are needed. For information
or processes that are used by many other systems, make it into
a service.
• Reuse is tough to accomplish – focus on use first, and then

comes reuse.
• Change management will be very important with SOA.

Controlling versions of services is critical to correct operation
of our applications.
• The department needs to direct its energies to minimize risks

associated with SOA, enable learning in a controlled manner,
and maximize the value of the early learning. To that end, we
should:
1. Aim at establishing some useful common components,
perhaps identity management and data translation.
2. Establish our security approach for dealing with services
and an associated security policy.
3. Develop other needed SOA policies (see below).
4. Train our developers in creating and consuming services,
and go ahead and construct some.
5. As we progress, evaluate our need for other tools. These
could include monitoring and debugging tools, service

55
registry servers (UDDI), security certificate management
tools, or an enterprise service bus.
• There are new complexities associated with managing

applications that use services. The department should establish
a testing group and a test bed to work out the details of service
oriented architecture.
• Management of the department’s processes will lead to the

most gain from SOA – important thing is how our organizations
are run through technology, not how the application is
developed. The department should consider a thorough analysis
of its business processes based on its goals and objectives.
This would identify areas of redundant data collection, and
improvements to our processes that would improve the delivery
of public health. Some process analysis efforts are already on
going (Children’s Health Information System Project, Common
Ground, Disease Surveillance Modernization Project), and we
could build on those to develop a more complete picture.
SOA Policies
There are several policies and guidelines that should be adopted
to successfully implement service oriented architectures. These
include:
• Security policies: Building applications that are composed

of service components leads to certain security issues
that must be addressed. How is access to a particular
component controlled? Who determines that access? How
do we monitor use of components? The department will
need to develop policies and processes to maintain the
security of our applications.
Also, there are many new security standards that are

associated with the use of web service components. These
include standards like WS-Security, Security Assertion
Markup Language (SAML), and WS-Trust. The department
has little or no experience with them, and we will need to
carefully implement them as the need arises.
We have an existing Application Security Policy with an

associated standards document. Although this policy is new

56
and in the process of being implemented, it could serve as
the basis for new development standards and processes for
future applications.
• Reuse and quality of service policies: The concept of reuse of
services raises issues that must be managed. When a service is
published for use and incorporated it into an application, what
responsibilities do the publisher and consumer have regarding
that service component?
On the one hand, we do not want to publish too many service

components that do the same thing, or almost the same thing.
This defeats some of the efficiencies gained from reuse, and
creates management problems of its own.
On the other hand, we do not want to place an unfair burden

on the original publisher to make their service so generic that
it will accommodate all later uses for the component. This will
be a strong discouragement to building reusable components
– exactly the opposite direction that we want to embrace.
What is needed are some criteria that specify when to create

a new component, mechanisms for dealing with different
versions of components, training for designing generic loosely
coupled components, and incentives for building reusable
service components.
In addition, if the service is being provided remotely (perhaps,

CDC provides a service component that we use), we would
need to have some agreement on the service level and
performance expected from it.
• Service consumption policies: Some guidelines are needed

for applications that consume others’ component services.
Those guidelines should specify what is appropriate use, how
to obtain access, monitoring requirements and communication
with the component publisher. For instance, if you have
published a worthwhile service, you would certainly like to
know if an application is going to come on-line that uses your
service, especially if it will involve heavy use.
• Application Development Guidelines: Provide guidance on

how to develop services and how to develop applications using
services at MDH.

57
Timeline for SOA
The following time line provides some very approximate dates for
possible implementation of certain SOA components. This is a high
level view. An architecture implementation project (initiative?)
should be established to develop a more detailed plan.
2007 2008 - 2009

S e rvice B a se d 2007 - 2008 T ra in
A rch ite ctu re E sta b lish W e b D e ve lo p e rs
D o cu m e n t S e rvice s in U sin g
S e cu rity P o licy SOA
2008 2009 2010 2011
2008 - 2009 2009 - 2011

2007 2007 D e ve lo p S O A
2008 2008 E va lu a te
D e ve lo p E sta b lish P o licie s O th e r S O A
P H IN M S Id e n tity D e ve lo p D e ve lo p
R e p o rt S o m e W eb T o o ls
M e ssa g in g M anagem ent
S e rvice S e rvice G e n e ra tio n S e rvice s
S e rvice

58
Part 4: Maintaining the Architecture
Maintaining the Architecture
To move the department in the direction of the adopted

architecture, we must identify the resources and manage the
policies to ensure that the department’s information technology
choices are consistent with it. In addition, without some process
to maintain and renew it, an architecture will become out of date.
It will no longer be responsive to the goals of the department, nor
will it address the “drivers” that the department must respond to.
In order to keep it current, we need to establish some processes to
periodically review and update the architecture. In short, we need a
governance structure to administer the architecture.
Proposed Governance Framework
The following diagram illustrates the major entities that are part
of the governance of the department’s architecture. Proposed new
positions or groups are represented with shaded boxes.
M D H A rc h ite c tu re G o v e rn a n c e
IT In fo rm atio n S ystem s & T ech n o lo g y M an ag em en t

E xecutive
S teering C hief Inform ation O fficer
C om m ittee
(E S C )
4.
2.
T esting C IS O
M D H A rchitect
G roup
1.
A rchitecture P lanning
IS T M M anagem ent
R eview text S ervices
B oard
W eb S ervices D evelopers
5.
E nterprise U ser S upport
A d H oc
Inform ation N etw orking S ervices
D om ain 3.
T echnology T eam s N ovell
C oordinating A dvanced
S ervices B usiness
C om m ittee
(IT C C ) S ervices

59
1. Architectural Review Board (ARB): The ARB will be
composed of representatives from each division/bureau in
the department. It will be responsible for developing and
maintaining architectural policies and reviewing and updating
the architecture. The MDH Architect will chair it, and it
will report to the Executive Steering Committee (ESC). The
development of policies and procedures will be accomplished
in coordination with ITCC.
2. MDH Architect: This position will be a full-time position

within IS&TM. The MDH Architect will chair the Architecture
Review Board, be the main spokesperson for the architecture,
work to implement the architecture, coordinate the creation of
policies, coordinate the testing of new services, and work with
department projects.
3. Advanced Business Services: This team (starting with about

four persons) will support and promote the use of common
department services. They will teach users how to use the
common services, and help solve problems related to them.
Some of the common services include identity management,
Rhapsody software (HL7 translation), PHIN MS (CDC
messaging service), SAS DataFlux software (data cleaning,
postal service addresses, GIS coordinates), Perseus Survey
software, and a reporting tool. They will work closely with
the IS&TM Developers team and Web Services to support and
maintain these common services.
4. Testing Group: This group will coordinate the testing of new

software and hardware on MDH systems. They will establish a
test bed, (network, hardware and software), and they will work
toward the use of automated testing tools.
5. Ad Hoc Domain Teams: These are project teams to address

standards in specific areas or for particular services. They
will be created by the ARB, ITCC, or ESC, and they will
coordinate with the MDH Architect.
Architecture Processes
The processes to sustain and incorporate the architecture into
the MDH information technology operations are represented by
the circles in the following diagram. The person or group that is
responsible for a process is below the circle in parentheses. Policies
related to architecture are shown in the shaded boxes on the left.

60
Drivers and requirements for the architecture are in the boxes
on the right. The arrows represent flows of data or information.
Process models (flow charts or swim lane diagrams) should be
developed for each of these processes.
M D H A rc h ite c tu re P ro c e s s e s
N eeds and
R equests A rc h ite c tu ra l
R equirem ents
F or P urchases
D IV IS IO N S
D riv e rs
P o lic ie s P roposed N ew A pplications S tra te g ic
P la n s
O ver-all R equests
A rchitecture P olicy F or E xceptions
– P urchasing and P a rtn e rs
E xceptions 4. 3. a n d C itize n
A p p ro ve IT P ro ce ss 6.
R e vie w N e w D riv e rs
P u rch a se s R e q u e st fo r
E xce p tio n s A p p lica tio n s
S ervice
C onsum ption A rchitecture F e d e ra l
P olicies (IS & T M A rchitecture Info
(IT C C ) (M D H A rchitect) D riv e rs
M anagem ent) Info
P olicies and A rchitecture
P olicy updates Info
R euse and A rchitecture R eview S ta te
Info A nnually 2.
Q uality of S ervice D riv e rs
P olicies R e vie w a n d
1. APPROVED u p d a te
A R C H IT E C T U R E a rch ite ctu re
D e ve lo p a n d
A pplication M a in ta in T e c h n o lo g y
P olicies and
D evelopm ent A rch ite ctu re A rchitecture (A rchitecture R eview D riv e rs
P olicy updates
G uidelines P o licie s B oard)
Info C urrent
7. Infrastructure
(A rchitecture R eview
B oard) 5. C h o o se A p p lic a tio n a n d
S O A S ecurity T e st N e w T e ch n ica l In fra s tru c tu re
P olicies T e ch n o lo g y S ta n d a rd s In v e n to ry
(A d H oc D om ain
(T esting G roup ) T eam )
1. Develop and Maintain Architecture Policies: The architecture

review board would be responsible for developing and updating
policies and procedures related to architecture. Some of the
policies already exist, and could use updating. Others are be
new, and they will require development and implementation.
2. Review and Update Architecture: The architecture review

board will annually review the architecture to determine how
well it is aligned with department needs and goals. Some years
this will be a cursory evaluation. Every three to five years, the
architecture should have a full review.
3. Exception Process: The department has always maintained

that we would allow exceptions to technical standards and
architectural decisions for legitimate business needs. Requests
for exceptions will be handled by the ITCC. Some requests may
have to go to ESC for approval, and some requests may require

61
technical evaluation by the ARB or other technical teams.
4. Approve IT Purchases: This is an on-going process, but we

need to make sure that the approvers (IS&TM Management)
are aware of the architectural guidelines.
5. Test New Technology: We need a process for testing and
certifying new technology for use in our infrastructure and
architecture. A process should be developed to manage this.
6. Review New Applications: This process will involve the

review of plans for new applications to see if they need to be
compliant with the MDH architecture and if so, to help plan
them for compliance.
7. Choose Technical Standards: This is the process to be used

to select particular software or hardware as a standard for
the department. It will be performed by ad hoc teams, but a
standard process should be developed.

62
Appendices
Appendix A: MDH Architectural Team Members

Appendix B: MDH Architectural Drivers and Requirements
Appendix C: Current Infrastructure
Appendix D: Response to Comments on Draft Version
Appendix A: MDH Architectural Team Members
Richard Fong Communications
John Nieland Infectious Disease Epidemiology
Prevention & Control
Karen White Infectious Disease Epidemiology
Prevention & Control
Christina Tamondong Public Health Labs
Jason Tillman Policy, Quality and Compliance Bureau
Don Brabeck Community & Family Health
Promotion Bureau
Shelly Siems Environmental Health Division
Steven Ring Information Systems & Technology
Management
Michelle Aguilar Communications (document formatting

and production)

63
Appendix B: MDH Architectural Drivers and Requirements
P ro ject o r R eq u irem ent D etails Im plicatio n s
In itiative
C D C
P u b lic H e alth M e ssa g in g C o n structio n , a u tom a tic ro u ting , M D H n e e d s an e ffe ctive m e a ns to
In fo rm a tio n e n cryp tio n , d igita l sig n a tu re s, su p po rt su p po rt this ca pa b ility
N e tw o rk (P H IN ) e b X M L p ro to cols, S S L co m pa tib le ,
co m p lia n t w ith P H IN M e ssa ging S e rvice
D ire cto ry S e rvice s C o n ta ct in fo a nd role s, a ccess co n tro l M D H w ill n e e d to e xp a n d its use o f
d ire cto ry se rvice s
O b je ct Id e ntifie r S u pp o rt O ID s -- g lob a lly u n iq u e id e ntifie rs to A system to tra ck O ID s w ill b e
id e n tify o rg an iza tio n s, cod e sets, e tc. n e e d ed
A u d it tra il M u st su p p o rt a u dit tra il o f da ta re co rd s M D H m u st e xp a n d its use o f au d it
a n d acce ss a tte m pts to system s tra ils. T h a t m a y m ea n m o re /b ig g e r
se rve rs a n d m o re sto ra g e space to
a cco m m o d ate th e in crea sed loa d o f
h a n d lin g a u dit tra ils.
V o ca bu la ry S tan d a rds S u p p o rt system to m ain ta in a nd u p da te M D H n e e d s po licie s an d system s to
F co d in g co o rdin a te w ith C D C co de s a nd
m a n ag e co d e cha n ge s th ro ugh
E d iffe re n t ve rsio ns.
D a ta M o d e lin g S u p p o rt P H IN L o gical d ata m od e l In o rd er to sh a re info rm a tion , M D H
D m a p pin g m u st d e ve lo p da ta ba ses th a t ca n b e
m a p pe d to C D C d a ta e lem en ts.
O p e ra tion a l b e st C le a r p ro cesse s a n d d o cu m enta tion , M D H n e e d s to co m ple te o u r C O O
E p ra ctices C o n tin uity o f O p e ra tio n s (C O O ) P la n n in g w h ich includ e
d o cum e nta tio n of its p rocesses
R A u th e n tica tion su p po rt tw o fa cto rs, X .5 0 9 W e m ust b e ab le to use tw o
p a ssw o rd s o r a p assw o rd a nd
A a n o the r ide n tifyin g m e ch a nism to
co n tro l lo g gin g in to system s an d
L d a ta ba ses
A u th o riza tio n ro le ba sed a uth o riza tio n A p p lica tio ns n ee d to b e co nstru cted
th a t g ra n t p e rm ission s to role s.
P e o p le a re th e n g ive n p e rm issio n s b y
b e in g a ss ig n e d to a ro le .
D a ta Tra n sla tion H L 7 fo rm a t su pp o rt M D H m u st ha ve a syste m th a t ca n
tra n sla te d a ta in to H L 7 fo rm a t a n d
re a d H L 7 file s
O ffice o f th e N atio n al C o o rd in ato r fo r H ealth In fo rm atio n T ech n o lo g y (O N C H IT )
N a tio n al H e alth L a b da ta fo rm at p asse d , p re scrip tion s, Im p o rta n t lo ng -te rm im p act on
In fo rm a tio n m e d ical reco rds co m in g sta nd a rds a nd m e ssa g in g .
N e tw o rk (N H IN )
H H S
H e a lth A u d it tra il M o st o f M D H is n o t re q uire d to m e e t
In su ra n ce H IP P A g u ide lin e s, b u t it m igh t b e
P o rta b ility a nd sm a rt fo r u s to m o ve in th a t d ire ctio n
A ccou n tab ility so tha t w e ca n fu lly p a rticipa te in E -
A ct (H IP A A ) h e a lth
U SD A
D e p a rtm e n t o f U S D A 's a rch ite ctu ra l p lan s a re n o t
A g ricultu re – cle a r, b u t th e y co u ld h a ve a n im p act
W IC p ro g ra m o n o ne o f o u r im po rta n t p ro gram s
EP A
E n viro n m en tal Th e E P A se em s to b e focu se d o n
P ro te ctio n d a ta sta nd a rds. T h is m a y h a ve a n
A g e n cy – im p act o n E H syste m s.
E n viro n m en tal
H e a lth D ivision
FE M A
M o b ile M o rg u e N e e d to com p ly w ith F ed e ra l
R e q u irem e nts
C M S
ASPEN N e e d to c om p ly w ith F ed e ra l
R e q u irem e nts

64
In itiative
O ET
O E T E n te rp rise S e rvice O rien te d P ro m o te w e b se rvice s A lth o ug h th is p ro je ct is p ro g ressin g
A rch ite ctu re A rch ite ctu re ve ry slo w ly, it co uld ha ve a m ajo r
P ro je ct im p act o n M D H syste m s a n d
in frastructu re .
M in n e so ta ’s T e ch n ica l S ta n d a rd s W orkin g on ve rsio n 3 w ith b u sin e ss, IT d e ve lo p m e n t an d system s w ith in
E n te rp rise -w id e a p p lica tio n, in fra stru ctu re , d a ta a n d le g islative initia tive s m ust co m p ly
T e ch n ica l se cu rity d om a in s w ith th e EW T A in o rd e r to o b ta in
S A rch ite ctu re fu n d in g . M o st o f th e m ajo r M D H
(EW TA ) syste m s alre ad y com p ly.
T D H S
D H S ’s M e d ica id P H n e e ds to in te ro p e ra te D H S is w o rkin g o n m a jo r ch a ng e s to the ir M D H sh o u ld b e de sig nin g syste m s
A In fo rm a tio n w ith m a in syste m s b ase d o n th e M ITA th a t ca n in te ro p e ra te w ith D H S 's
T e ch n o log y a rch ite ctu re . T h e y w o u ld like to h a ve a rch ite ctu re in so fa r a s w e can
T A rch ite ctu re m u ch im p ro ve d in teg ra tio n w ith th e p u blic d e te rm in e it.
(M ITA ) p ro je ct h e a lth syste m .
E C o o rd ina tion o f N e e d to coo rd ina te th e a ssig nm e n t
N P I # 's a n d us e o f N P I's (N a tio na l P rovid e r
In d e x)
C ounty/C ity
D a ta E xch a n g e C a p a b ility to secu rely a n d e ffective ly A so lu tion w o u ld g re a tly in crease the
e xch a n g e vita l re co rds/b irth & d e a th d a ta se cu rity a nd d ecre ase th e a m o u n t of
b e tw e e n M D H a n d citie s/co un tie s. w o rk re q u ired to o b tain th e da ta
w e re a re re q uire d to co lle ct
M H A (H ospitals)
D a ta E xch a n g e C a p a b ility to secu rely a n d e ffective ly A so lu tion w o u ld g re a tly in crease the
e xch a n g e d ata be tw e e n M D H a n d M H A se cu rity a nd d ecre ase th e a m o u n t of
a n d the H osp ita ls w o rk re q u ired to o b tain th e da ta
w e re a re re q uire d to co lle ct
C om m erce
E le ctro n ic A b ility fo r M D H to e a sily acce pt p a ym e nts W ould e ase th e co lle ctio n o f fee s fo
P a ym e n ts e le ctro n ically m a n y se ctio ns in M D H
S e rvice O rien te d C a p a b ility o f d e ve lop ing a pp lica tio ns w ith S o m e p u rch a se d ap p licatio ns w ill b e
A rch ite ctu re (S O A ) re u sab le m od u les. m o vin g to w a rd S O A so M D H m a y
n e e d to su p po rt the u nd e rlying
in frastructu re . C o uld he lp M D H
T b u ild a pp lica tio ns m o re e fficien tly.
E V irtu a liza tion C o u ld red uce the n um be r o f ph ysical
C se rve rs a n d e a se d isaste r re co ve ry.
H O p e n S o u rce P o te n tia l to re du ce e xp e n sive
N licen se fe es o r p ro p rie ta ry h a rd w a re .
O M o re m o b ile w o rk S e cu re con n ection to M D H , w ire le ss E n h a nce d V P N a n d w ire less
L ca p ab ility co n ne ctio ns w ill n ee d to b e
O su p po rte d. A lso ne e d to p la n fo r field
sta ff w h o m a y n e ed to co nn e ct
G
th ro u gh a p a rtne r's n etw o rk.
Y G e o g ra p hica l Info rm a tio n M o re M D H d a ta sh o u ld be a nalyze d a n d N e e d a w a y to e asily cre a te an d
S yste m s (G IS ) d ispla ye d o n m a ps. w o rk w ith m a p s o n ou r w e b site
P o rta l N e e d to im p ro ve inte g ra tion an d U sin g p o rtal so ftw a re a n d m ana g in g
m a n ag e m e n t o f M D H a p p lica tio n s a n d o u r w e b site as a po rtal w o u ld le a d
in fo rm a tio n po stin gs. to m o re e ffe ctive m a n a ge m en t o f its
co n te n t an d a p p lication s. It cou ld
le a d to sin gle -sig n -o n fo r use rs o f
M D H a p p lica tion s.
V id e o M o re n e e d fo r th e use o f vid eo is P ro vid in g n e tw o rking b an d w id th a n d
e xp e cte d . q u a lity o f se rvice is crucial.
E n h a nce d w e b use r In crea sed e xp e cta tio n th a t W eb S u p p o rt o f ad d itio na l p ro g ram m in g
in te rfa ce a p p lica tio ns w ill in co rp o rate m o re im a g es e n viro nm e n ts (F la sh , A JA X ) w ill
a n d p ro vid e be tte r p e rfo rm an ce in clu d e secu rity issu es.

65
T In itiative
E In te rn ation a liza tio n A b ility to crea te a p plica tion s tha t can
C C a p a b ility e a sily w o rk w ith o th e r la n gu a ge s
H XML N e e d to e fficie n tly cre a te, p roce ss, a n d
N tra n sla te X M L d a ta
O D a ta M a rts/R e p o rtin g U n lo ck M D H d a ta to m a ke it ava ila b le fo r N e e d a re p o rt g e ne ra tin g to o l. M a y
a n a lysis an d re p o rtin g n e e d a d d ition a l d a ta w a re h o u se
L so ftw a re .
O S e cu re F ile T ra n sfe r N e e d to secu rely a n d e ffectively se n d a n d A so lu tion w o u ld ea se th e b u rd e n o f
G re ce ive la rge file s e lectron ica lly b e tw e e n e m a il a tta ch m en ts a n d w o u ld e n su re
Y M D H a n d o u tsid e p a rtn e rs. g re a te r secu rity a n d re lia b ility o f file
tra n sfe rs
E le ctro n ic S ign a tu re s N e e d to b e ab le to acce p t signa tu res N e e d to w o rk o u t th e le g al
e le ctro n ically o n e lectro nic fo rm s. ra m ification s of a d ig ita l sig n a tu re vs
a re a l sig n a tu re .
R F ID
S e cu rity B io m etrics In crea ses se cu rity o p tio ns.
LPH A
L In te g rate d C h ild D a ta S h a rin g P o rta l fo r inte g ra te d in fo rm a tion fro m M a ste r p a tien t in d e x n e e d e d fo r
P H e a lth R eco rd A g re e m e n ts a nd sin gle m u ltip le sou rce s a va ilab le in on e -sto p p a tien t da ta resid in g in va rio us
a u th o rita tive id en tifie r sh o p lo catio ns th ro u gh o u t M D H
H
A ccess to re p o rtin g to o l a va ilab le L a rg e co un ties ne e d to an a lyze th eir o w n
& D ise ase fro m ou tsid e fire w a ll to d a ta
re p o rtin g d a ta w a re h o use
H in fo rm a tio n
O A PIC
S S tre a m lin ed
P d isea se
re p o rtin g
syste m from
e xte rn a l
p a rtn e rs
M D H S tra te g ic In crea sed inte g ratio n, S e e "S um m a ry o f IT Im plica tion s o f A n a rch itectu re th at su p p o rts
a n d IT P la ns co lla b o ra tion , e fficie ncy D e p a rtm e n t P la ns" fo r m o re info rm a tio n. e fficie nt u se o f IT re so u rces an d
a n d rep o rtin g ca p ab ility in crea sed ca p ab ility fo r in te g ratio n
w ith in a n d w ith ou t M D H . N e e d fo r
b e tte r a n alysis a n d re p o rting
M ca p ab ility.
M N -P H IN C o lla bo ra te w ith e -H e a lth N e e d a fle xib le a rch ite ctu re tha t can
D a n d lo cal p ub lic he a lth co n ne ct to se ve ra l d iffe re n t kind s o f
syste m s an d tra n sla te d iffe re nt kind s
o f d a ta
H
C h ild ren ’s In te g ration a nd d a ta N e e d a d a ta a rch itectu re th at ca n
H e a lth sh a rin g su p po rt da ta sh a rin g a n d p rivacy.
In fo rm a tio n
S yste m p ro ject
L o w e r S ta te b ud g e ts
L o w e r F e d e ral g ran t
a m o un ts
C o n tin uity o f R e lia bility a n d a vailab ility M D H p ro je ct is m o ving fo rw a rd N e e d to sup p o rt re d un d a ncy
O p e ra tion s
P la n n in g
(C O O P )
M C SS
C a n ce r M o d e rn syste m A rch ite ctu re m u st b e a b le to su p p o rt
S u rve illan ce th e n ee ds o f a n e w ca nce r
S yste m su rve illa nce system
M C H S
V ita l R eco rds W eb ba sed syste m M u st b e a b le to su pp o rt b a n d w id th
S yste m a n d da ta ne e ds o f a ne w vita l
re co rds system

66
In itiative
W IC
W IC S yste m M o re w e b b a se d
M ID E P & C
D ise ase In te g rate d P H IN N e e d to sup p o rt P H IN re q uirem e n ts
D S u rve illan ce co m p lia n t system
C o m m O ffice
H C o n te n t C o n te n t M a n a g em e nt C o u ld be rela ted to a p o rta l syste m .
Managem ent S yste m Th is w o u ld h a ve a m ajo r im pact o n
o u r w e b in frastructu re
PHL
E n te rp rise W eb ba sed syste m th a t N e e d to sup p o rt P H IN re q uirem e n ts
L a b o rato ry is P H IN co m p lian t, a n d a n d a rch ite ctu re m ust su p po rt a d h oc
In fo rm a tio n a d h oc re po rting re p o rtin g ne e ds
S yste m (E LIS ) ca p ab ilities
F e d e ral O M B
F e d e ral H ig h le ve l g uid in g a rch ite ctu re fo r C D C F e d e ral g ran tin g ag e ncies w ill b e
E n te rp rise a n d o th e r fe d e ra l ag e ncies. E m p h asis o n m o vin g to w a rd com p lia nce . It m a y
A rch ite ctu re a n a lysis of b usine ss p ro cesses a nd m e a n m o re focus o n com m o n
L (F E A ) co m m o n se rvice s. se rvices an d p ro cesse s.
CDC
O C D C ’s vie w o f C o n ce ptu al w h o le It w ill b e d ifficult an d e xp e n sive if
sta te h e alth e ve ry p ro g ra m in vo lve d in P H IN
N a g e ncies d e ve lo ps the ir o w n a pp ro ach to
m e e tin g th e re q u ire m e n ts.
S tate
G
E -H e a lth Im p o rta n t lo ng -te rm im p act on
sta nd a rds a nd m e ssa g in g . H as th e
p o te n tia l to ch an g e o u r rela tion sh ip
T w ith so m e o f ou r d ata p ro vid e rs
S tate – D O E R
E D e a l w ith "g ra yin g P o ssib le sm a lle r IT sta te w o rkfo rce
w o rkfo rce " in the fu tu re . S yste m a dm in istra tio n
R n e e ds to b e m o re e fficien t.
C itizen s
M E -G o ve rn m e n t M e e t p a rtn e r a nd citize n E xp e cta tio n th a t m ost fo rm s an d d a ta N e e d re lia ble an d acce ssible
e xp e cta tio ns tra n sfe rs ca n b e p e rfo rm e d e lectro nically in frastructu re .
a t a n y tim e o f d a y o r ye a r.
E le ctro n ic F o rm A b ility to sub m it fo rm s e lectronica lly N e e d to b e ab le to ea sily g e nera te
S u b m issio ns a n d co lle ct fo rm d a ta w ith o u t th e
n e e d to rely o n de ve lo p ers to
in d ividu a lly d e ve lop e ach fo rm .
D a ta Tra n sfe r A b ility to e asily tra n sfe r da ta ele ctron ica lly F u lfill da ta re q u ests e le ctro n ica lly
a n d au tom a tica lly
O n D e m a nd R e p o rts A b ility fo r citize ns to q u e ry fo r in fo rm a tion
o n th eir o w n
M o re R e p o rts a n d o the r N e e d re po rt ge n e ra to r se rvice th a t
in fo rm a tio n on in fo rm a tio n a vaila ble ca n e a sily crea te w e b p ag es
th e w e b e le ctro n ically
T a xe s/b u d g e t B e m o re e fficie n t "D o m o re w ith less" N e e d to sim p lify in fra stru ctu re .
p re ssu re N e e d to b eco m e ve ry e fficien t a t
m a n ag ing co m m o d ities so tha t
sca rce re sou rces ca n b e de vo te d to
p ro g ram n ee ds. N e ed to in ve st in
a d m in istra tive to ols th a t p ro vide
lo n g -te rm re tu rn o n in ve stm e nt.

67
Appendix C: Current Infrastructure
The project team compiled an inventory of desktop hardware and

software, servers, and MDH applications. There was no intent
to make this inventory thoroughly complete. We wanted to get
a general picture of the numbers of computers, where they were
located and what was running on them. Accurate numbers were not
important.
Obtaining this information was extremely difficult. Every support

area keeps the information in a different way. The names differ,
software vendors are bought out, versions are tracked differently,
and some divisions have no way of easily obtaining these numbers.
The following table provides a key to the organization (ORG)
acronyms.
ORG Org Description

EO Executive Office, Communications Office, Legal Unit,
Library,
Minority and Multicultural Health
MMH Minority and Multicultural Health
CM Compliance Monitoring
HP Health Policy
EH Environmental Health
IDEPC Infectious Disease Epidemiology Prevention and
Control
PHL Public Health Laboratory

OEP Office of Emergency Preparedness
CFH Community and Family Health
HPCD Health Promotion and Chronic Disease
PQC Policy Quality and Compliance Bureau Operations
CFHP Community and Family Health Promotion Bureau
ISTM Information Systems and Technology Management
FFM Finance and Facilities Management
HRM Human Resource Management

68
Desktop Hardware
ORG Number of Desktops Number of Laptops

EO 25 17
ISTM 15 24
OEP 1 32
FFM 87 17
HRM 41 4
PHL 239 33
CFHP 229 107
EH 203 193
PQC 200 140
IDEPC 188 70
Total 1228 637
Desktop Software (Ordered by department totals, descending)
Software Name
Internet Explorer (IE)
Network Associates Virus Scan (McAfee)
GroupWise
Microsoft Excel
Microsoft Word
Microsoft PowerPoint
Adobe Acrobat Reader
Realplayer
FireFox
Novell Client
Microsoft Office Pro (Word, Excel, Powerpoint, Access, et.al.)
Microsoft Access
Adobe Reader
ScreenPass
Belarc Client
Netscape Browser
iPrint

69
Software Name
QuickTime, Real & Windows Media Players
Microsoft Standard:
FoxPro 2.6
EpiInfo 2002
Power Archiver
Microsoft Visio
Adobe Acrobat Pro
Java Run-time environment
Microsoft Office Standard (Word, Excel Powerpoint)
Print Screen Deluxe
Oracle Client
Macromedia Dreamweaver
CutePDF
Metaframe (Citrix Client)
Micorosft Publisher
Microsoft Project
CD and DVD burning software
Crystal Reports
Publisher
Abby Scan to Office
Information Access
Commvault Client
Helptrac 8
BlueZone
MAPS
Cisco Systems VPN Client
SAS Enterprise Guide
SAS ver 9
Adobe Font Reserve
PL/SQL Developer
Oracle Discoverer

70
Software Name
PGP Freeware Version 6.5.
Reference Manager
Adobe Photoshop / Illustrator
Document Direct
Infomaker 6.5 & 10
Abbey Fine Reader
Adobe Contribute
Adobe PageMaker
Dymo Lable Writer
ImageNow
PGP
Corel WordPefect
End Note
Password Safe
Java 2 SDK, SE v1.4.2_04
Microsoft Visual Foxpro
Perseus Survey Solutions
PuTTY
Adobe Indesign
ArcView GIS
JDeveloper
Macromedia Studio 8
Microsoft Live meeting
SEAL - CDC
AccessGold
Beyond Compare
Budget Information Systems
Dataflux dfPowerStudio
MapInfo
Quark Xpress
Adobe Creative Suite

71
Software Name
Adobe Font Folio
DataVis Conversions Plus
Map Marker
Oracle SQL Plus
PGP (licensed version)
5 Click
CASA/CO-CASA
Oracle Forms/Reports Developer
PDA Connect
RealVNC
B’s clip and B’s recorder gold
Eclipse IDE
ESRI (ArcView)
FormsDOCS
Inno Setup
Intercooled Stata 8.0
JCreator LE
Microsoft Remote Desktop
Oracle Enterprise Manager
PWSafe
Adobe Photoshop
Audacity
DBArtisan (for Sybase)
Partition Magic
PC SAS
Project Clock
Readsoft
Adobe Audition
Bugzilla
CommVault Console
DB Designer

72
Software Name
DB Visualizer
Ethereal
FileZilla
JasperAssistant
JasperReports
Logitech
MapViewer
OC4J
Open Reports
PowerBuilder
Solar Winds TFTP
2nd Nature
Adobe Illustrator
Adonis Mgt Console
Atlas.ti
CASTOR
Checkpoint
Checkpoint SmartConsole software
Cisco TFTP server
ColdFusion
Crayon software (CDC)
cygwin
Digital Voive Editor
Fiery
IntelliJ
iTunes
JRB Utilities
Macromedia Flash
Microsoft Defender
MS Office Premium (for development)
MWSnap

73
Software Name
NetDrive
Norton Ghost Professional
PitStop
ProComm Plus
QA “Quick Address”
Quite Imposing
Adobe After Effects
Adobe Encore
Adobe Premier Pro
Adobe Premiere
BBC News alerts
BlueCat Adonis software
CheckPoint Integrity Client
Cisco test and study software.
Citrix Client
CommVault Qinetix
ConsoleOne
Crimson Editor
cryptbox
Data Junction
dBase 5 for Windows
DBMS/Copy
DNS/DHCP
DNScommander
DS Expert
DVD Buring software
GIMP
Gratis
HP PSC 2100 Series Printer
IMC console
Incpgnito DNS Commander

74
Software Name
Inkscape
Macromedia Extension Manager
Microsoft Front Page
Modem Helper
nessus client
Netshield for Netware
OpenCube Nav Studio & Visual Infinite menus
Opera
Oracle Express Database
PC Inspector File Recovery
Power and Precision
Quark
Rapid Deploy
RconJ
SAS Server (Citrix)
SC3P
SCMT
Secure FTP
SmartDeviceMonitor
SnagIt8
Sony Clie programs

75
Number of Servers at MDH by Organization, OS and Server Purpose
(OS = Operating System)
O rg an izatio n (D iv isio n o r B u reau )
G ran d
S erv e r p u rp o se OS CFHP EH FFM ID E P C IS T M PHL PQC T o tal
A P P LIC A T IO N U N IX 9 5 1 3 18
W IN 2 3 2 7
C O M M V A U LT W IN 1 5 1 7
DATABASE N O V E LL 1 1
U N IX 1 3 3 6 8 21
W IN 1 1
DHCP (blank ) 7 7
D IR E C T O R Y N O V E LL 2 2
DNS W IN 1 1
(blank ) 2 2
E N V IR M O N IT O R (blank ) 4 4
E Q U IP M O N IT O R (blank ) 2 2
FAX W IN 2 2
F ILE /P R IN T N O V E LL 16 16
W IN 1 2 3
F IR EW A LL (blank ) 4 4
FTP U N IX 1 1
G IS NT 1 1
W IN 3 3
G R O U PW IS E N O V E LL 2 2
N E T M O N IT O R (blank ) 1 1
OTHER LIN U X 1 1
U N IX 1 1
W IN 2 1 3 6
(blank ) 2 2
P H IN M S W IN 2 2
SANMANAG E W IN 2 2
SAS U N IX 1 1 2
TEST LIN U X 1 1
V IS IO N S H A R E LIN U X 2 1 3
VPN (blank ) 3 3
W EB LIN U X 1 1
U N IX 3 5 8
W IN 1 1 1 3
W EBTRENDS U N IX 1 1
ZENW O RKS N O V E LL 2 2
C IT R IX W IN 3 3
IM A G IN G W IN 1 1
S A N A p plia nce W IN 2 2
SPSS U N IX 1 1
W IN 1 1
V in gette S erver W IN 5 5
V oice A pp S erver W IN 1 1
G rand T otal 5 7 2 26 76 12 30 158

76
MDH Applications
ORG A p p licatio n N a m e A p p L an g u ag e D atab as e

CFH M C S H N S ervices D irectory C old F usio n O racle
HPCD T rack ing and F o llo w U p VB SQL
EH A ccredita tio n, C om pliance, and E nforcem ent S ystem P o w erB u ilder O racle
EH M in nesota D rink ing W ater Inform ation S ystem P o w erB u ilder O racle
EH C ounty W ell Ind ex 5 P o w erB u ilder O racle
EH B lo od Lea d Inform ation S ystem P o w erB u ilder O racle
EH W ell Inform ation S ystem P o w erB u ilder O racle
P ub lic W ater S upp ly (P W S ) D rink ing W ater R evolving
EH F und (D W R F ) F oxP ro D O S F oxP ro
EH D W R F Library F oxP ro D O S F oxP ro
EH W ater O perators C ertifica tion F oxP ro D O S F oxP ro
EH N e w sletter L ists F oxP ro D O S F oxP ro
EH P la n R e vie w Log (D W P /E H S S ) F oxP ro D O S F oxP ro
EH E n viro nm ental H e alth S ervices S ystem (E H S S ) F oxP ro D O S F oxP ro
EH E H S R ap id Inspection V isua l F ox F oxP ro
EH E H S F orce T rack er V isua l F ox F oxP ro
EH D rink ing W ater - W ater C hem istry A ccess A ccess
EH D rink ing W ater - A quifer T esting A ccess A ccess
EH C ounty A ccessible A ccess A ccess
EH C ounty W ell Ind ex 4 A ccess A ccess
EH LA R S U tility – Lab Inform ation A ccess A ccess
EH H ealth R isk Lim its (H R L ) A ccess A ccess
EH A sbestos S urve y A ccess A ccess
EH N itrate S tud y A ccess A ccess
EH Indo or A ir Q ua lity D atab ase A ccess A ccess
EH N E X IR S tud y A ccess A ccess
EH IW M Z P C S I W eb A pplication O racle
EH S ource W ater A ssessm ent W eb A pplication O racle
EH C ounty W ell Ind ex O nline W eb A pplication O racle
EH W ater W ell M aps W eb A pplication O racle
EH R O V E R – A sbestos a nd Le ad T raining C ourses C old F usio n O racle
EH C ertified F ood M a nag ers C old F usio n O racle
EH R egistered S an itarians C old F usio n O racle
EH G round w a ter H R Ls C old F usio n O racle
EH W ell D isclosures C old F usio n O racle
EO MDH Calendar C old F usio n O racle
EO WeeklyBreifing Submission Form C old F usio n O racle
Communications Strategy and Project
EO Planning C old F usio n O racle
EO Employee Recog. Form C old F usio n O racle
EO Carpool Request Form C old F usio n O racle
EO State Fair Sign-up Form C old F usio n O racle
EO T rack C ontested C ases C old F usio n O racle
EO M ed ia C ontact C old F usio n O racle
EO F it C ity C old F usio n O racle
EO F it S ch oo l C old F usio n O racle
Interne t E m ail form (W ebm aster, C om m isioner,
EO G eneral info) C old F usio n O racle
EO R .N . B arr Literature requ est form C old F usio n O racle

77
EO H elp line sche du ler C old F usio n O racle
EO M D H L ocations (uses G oo gle M aps A P I) C old F usio n O racle
P urchasing, R e ceiving, In ventory, S hipp ing
FFM M ana gem ent Java O racle
FFM C ell P hon e T rack ing C old F usio n O racle
FFM R egu lar P ho ne T rack ing C old F usio n O racle
FFM P R IS M R eporting C old F usio n O racle
FFM C entra l S tores O rdering C old F usio n O racle
FFM F edera l R e porting C a te gories C old F usio n O racle
FFM O ut of S tate T ravel C old F usio n O racle
FFM F edera l G rants C old F usio n O racle
FFM D esk top Inve ntory C old F usio n O racle
FFM O R G B ud gets C old F usio n O racle
HPCD e-C hron icle Java O racle
HRM M D H B ad ges C old F usio n O racle
HRM P erform ance M an agem ent for S upervisors C old F usio n O racle
HRM H R M V acanc y T rack ing C old F usio n O racle
HRM H R M T raining C old F usio n O racle
HRM H R M S en iority R osters C old F usio n O racle
HRM P erson M a inte nance C old F usio n O racle
HRM N otify C old F usio n O racle
HRM S tud ent W ork er C old F usio n O racle
HRM E m ail A dm in C old F usio n O racle
HRM A nn ounce R S S F e eds C old F usio n O racle
HRM H R M H e lp desk C old F usio n O racle
HRM S E M A 4 ID T rack ing C old F usio n O racle
HRM H R M S urve y C old F usio n O racle
ID E P C Lab A utom ated R ep ortin g S ystem Java, P E R L O racle
ID E P C Isolation an d Q uara ntine A C C E S S , Ja va A C E S S /O racle
ID E P C B lu e/Y ello w C ard Java, P E R L O racle
ID E P C E lectro nic D eath C ertificate Java O racle
ID E P C A nn ua l Im m unization S cho ol R eport Java O racle
ID E P C P ertussis d isease surve illa nce Java O racle
ID E P C R efugee hea lth inform ation Java O racle
ID E P C F lu S urveillance Java O racle
ID E P C Im m unizatio n P ractices Im provem ent Java O racle
ID E P C F lu C lin ic S ch edu ling Java O racle
ID E P C H epatitis V isua l F ox P ro V isua l F ox P ro
ID E P C V accine P re ve nta ble D ise a ses (V P D ) T rack ing V isua l F ox P ro V isua l F ox P ro
ID E P C A nn ua l C h ild C are R ep ort V isua l F ox P ro V isua l F ox P ro
ID E P C P erinata l H epatitis B V isua l F ox P ro V isua l F ox P ro
ID E P C M ail L ist V isua l F ox P ro V isua l F ox P ro
ID E P C M in nesota Im m unization Inform ation C on nection Java O racle
ID E P C N e w born P ack ets V isua l F ox P ro V isua l F ox P ro
ID E P C T B M eds V isua l F ox P ro V isua l F ox P ro
ID E P C T B C ontact Investig ation a nd track ing F oxP ro F oxP ro
ID E P C T B C ase S urve illance F oxP ro F oxP ro
ID E P C T B S uspect A rchive F oxP ro F oxP ro
ID E P C T B S uspect F oxP ro F oxP ro
ID E P C T B G enotyp ing M S A ccess M S A ccess
ID E P C T B Lab R esu lts M S A ccess M S A ccess

78
ID E P C S T D Inform ation N e t S yb ase D W B , C + S yb ase
ID E P C M N Infertility P re ventio n P rogram M S A ccess M S A ccess
ID E P C C ounse ling T esting an d R e ferral M S A ccess M S A ccess
ID E P C H IV C lient Le ve l R e port S ystem M S A ccess M S A ccess
ID E P C H IV /A ID S R e porting S yste m
ID E P C S T D M ana gem ent Inform ation S ystem
ID E P C S ection M ailing List D ata ba se M S A ccess M S A ccess
ID E P C H ealth T hreat Investig ation D atab ase M S A ccess M S A ccess
ID E P C Infected L icensed H ea lth C are W ork er M S A ccess M S A ccess
ID E P C E lectro nic D ata M an agem ent S ystem (E D M S )
IS T M H elp D esk C old F usio n O racle
IS T M A pp licatio n M ain ten ance C old F u sio n O racle
IS T M E xterna l P arty C old F usio n O racle
IS T M P olicies and S tatutes C old F usio n O racle
IS T M D ata Inventory C old F usio n O racle
IS T M M D H F acilities C old F usio n O racle
IS T M A pp licatio n R e gistry C old F usio n O racle
OEP O E P S urve y Java O racle
OEP S ecure Java O racle
OEP xbservice Java O racle
OEP sam Java O racle
PHL Laboratory Inform ation M a nagem ent S ystem O racle F orm s & R eports O racle
PHL E nterprise L abora tory Inform ation S ystem Java O racle
PHL P roject S tatus a pp lication M S A ccess A ccess
PHL B ottle R equ ests Java O racle
PHL Lab C ertification Java O racle
PHL Lab R esults Java O racle
PQC IQ Java O racle
PQC M C S C ontracts O racle F orm s 6i O racle
PQC M C S C om plain t F ilin gs O racle F orm s 6i O racle
PQC M C S Infolo g O racle F orm s 6i O racle
PQC MCS CAP O racle F orm s 6i O racle
PQC M C S E xtern al R evie w O racle F orm s 6i O racle
PQC Im proved C ustom er S ervice D e livery Java O racle
PQC P A R A D IS E O racle F orm s 6i O racle
PQC C aseM ix T ransition O racle F orm s 6i O racle
PQC R ecords M a nag em ent O racle F orm s 6i O racle
PQC N A R e gistry S em iA nnu al Java O racle
PQC C asem ix C m rF acO pt Java O racle
PQC M ortS ci Lice nsin g O racle F orm s 6i O racle
PQC HOP O racle F orm s 9i O racle
PQC D ata S ecurity Q uiz Java O racle
PQC A bortion C onse nt P o w er B u ilder O racle
PQC V R V 200 0 Java O racle
PQC V R V 200 0 C lie nt/S erver P o w er B u ilder O racle
PQC M in nesota F ath er's A d optio n R eg istry Java O racle
PQC C learing H ouse C ata lo g O racle F orm s 6i O racle
PQC H E D IS P rintform s M S E xcel O racle
PQC H C C IS P rintform s M S E xcel O racle

79
H C C IS M a intena nce (D a ta Load / A ud its /
PQC P relim 2P rod) O racle F orm s 6i O racle
PQC H C C IS M etada ta O racle F orm s 6i O racle
PQC H C C IS C losed H ospital M e dical R ecords L ocator Java O racle
PQC C D I P rintform s M S E xcel O racle
PQC C D I A udits (D ata Loa d / A u dits / P relim 2P rod) O racle F orm s 6i O racle
PQC C D I M e tad ata O racle F orm s 6i O racle
PQC H E P M E R C (M edica l E duc atio n R ese arch C ost) m od_plsql, H T M L O racle
Definitions
Cold Fusion An application development environment based on special tags that are similar
to HTML tags. When the web server reads a Cold Fusion tag, processing is
passed to the Cold Fusion application server. The Cold Fusion server completes
its processing and sends the results back to the web server as HTML that can be
transmitted to a web browser. Cold Fusion is owned by Adobe (they purchased
Macromedia).
Composite The term composite application expresses a perspective of software engineering
Applications that defines an application built by combining multiple services. A composite
application consists of functionality drawn from several different sources within
a service oriented architecture (SOA). The components may be individual web
services, selected functions from within other applications, or entire systems
whose outputs have been packaged as web services (often legacy systems).
Content Web Content management systems are used for storing, controlling, versioning,
Management and publishing information on the Web. It usually operates by storing content
System in a database and formatting it for the web as it is extracted from the database.
Data Context Data Context is a service category in the Data Service Area in our architectural
model. It is information that provides added meaning to data. Data context
usually places data in a taxonomy within a particular discipline. There are tools
that help capture and manage, and share data context information.
Data Description Data description is a service category in the Data Service Area in our
architectural model. It consists of the detailed information (metadata) that
describes the format, domain, and meaning of data elements.
Data Mart A data mart is a special database of data gathered from operational data and
other sources that is designed to facilitate analysis, decision making and
reporting for a particular program or area of interest.
Data Sharing Data Sharing is a service category in the Data Service Area in our architectural
model. It relies on data context and data description to provide standards for
access and exchange. These could include specific access protocols and XML
languages.
DNS Domain Name System

80
ESC Executive Steering Committee for Information Technology: It is chaired by the
Chief Financial Officer and contains three selected managers and the CIO.
FEA Federal Enterprise Architecture
GIS Geographical Information System
HL7 HL7 refers to data interchange standards that have been developed by an
organization called Health Level Seven, Inc. They have been designated by the
American National Standards Institute (ANSI) as the organization to develop
health care related standards.
Identity Identity Management pertains to the creation, modification and removal of
Management digital identities. It covers the assignment of usernames, passwords and the
authorization to access certain resources. There are several systems that are
available from commercial vendors to manage digital identities.
IMAP Internet Message Access Protocol
Interoperability The ability of two or more systems or components to exchange information and
to use the information that has been exchanged [IEEE 90].
ITCC Information Technology Coordinating Committee: An IT steering committee
at the Minnesota Department of Health. It includes representatives from five
division/bureaus and the CIO.
MIME Multipurpose Internet Mail Extensions
NPI National Provider Identifier
OET Office of Enterprise Technology (State Office)
OMB Federal Office of Management and Budget
Open Source Open source is a form of licensing software that involves free redistribution of
the software, access to the source code, and several other criteria. It usually
refers to software that is developed and maintained by a group of users over the
Internet.
PERL Perl is a dynamic programming language that borrows features from a variety
of other languages and has been widely adopted for its strengths in string
processing, and lack of the arbitrary limitations of many scripting languages.
PHIN CDC’s Public Health Information Network
PHP PHP is a widely-used general-purpose scripting language that is especially
suited for Web development and can be embedded into HTML.
PKI Public Key Infrastructure
Portal A web portal refers to a site which serves as a gateway to information, services
and applications. It also refers to the software that supports easily managing
such a web site.

81
Python Python is a high-level programming language first released by Guido van
Rossum in 1991. Python is designed around a philosophy which emphasizes
the importance of programmer effort over computer effort, and it rejects more
arcane language features, prioritizing readability over speed or expressiveness.
Python is often characterized as minimalist, although this only applies to
the core language’s syntax and semantics; the standard library provides the
language with a large number of additional libraries and extensions.
SAML Security Assertion Markup Language, an XML-based framework for ensuring
that transmitted communications are secure. SAML defines mechanisms
to exchange authentication, authorization and nonrepudiation information,
allowing single signon capabilities for Web services. It is an OASIS
(Organization for the Advancement of Structured Information Standards)
standard. From WebopediaSecurity Assertion Markup Language, an XML-
based framework for ensuring that transmitted communications are secure.
SAML defines mechanisms to exchange authentication, authorization and
nonrepudiation information, allowing single signon capabilities for Web
services. It is an OASIS (Organization for the Advancement of Structured
Information Standards) standard. From Webopedia
SAN Storage Area Network
Service Oriented An approach to designing applications based on independent modules (services)
Architecture which closely mirror business processes. It is usually associated with building
an application as a collection of web services.
Single Sign On A system of software components which allow a user to log-in once and be able
to start-up additional applications (provided they have the authority to do so)
without further log-ins.
SMTP Simple Mail Transport Protocol
Storage Area A SAN ( storage area network) is an architecture to attach remote computer
Network (SAN) storage devices such as disk array controllers, tape libraries and CD arrays to
servers in such a way that to the operating system the devices appear as locally
attached devices. Although cost and complexity is dropping, as of 2007, SANs
are still uncommon outside larger enterprises.
Virtualization Creation of non-physical versions of something that acts like a physical entity.
This could mean splitting a disk drive into three virtual drives that act like
separate physical drives. With servers, virtualization refers the capability to
run several virtual servers on one physical server. The virtual servers act like
independent physical servers. Virtualization can improve scalability, work
loads, disaster recovery and administration time.
Web Services Independent modules which are associated with a particular web address
(URL). They use an XML based language called Web Services Description
Language (WSDL) that describes the service.

82
References
1. Chappell, David A., “Enterprise Service Bus”, 2004, O’Reilly

Press
2. Service-Oriented Architecture: Making Collaborative Gov
ernment Work, Center for Digital Government: http://www.
centerdigitalgov.com/story.php?id=98218
3. MITA Service Oriented Architecture – A Primer, Centers for
Medicaid and Medicare Services (CMS), http://www.cms.hhs.
gov/MedicaidInfoTechArch/Downloads/mitasoa.pdf
4. Federal Enterprise Architecture, Office of Management and
Budget, http://www.whitehouse.gov/omb/egov/a-1-fea.html
5. Proposal for Fulfilling Strategic Objectives of the U.S. Road-
map for National Action on Decision Support through a
Service-oriented Architecture Leveraging HL7 Services,
K. Kawamoto, D. Lobach, J Am Med Inform Assoc. 2007;
14:146-155.
6. California Service Oriented Architecture (SOA) Master
Guide, http://www.cio.ca.gov/caIT/pdf/SOA_Master_Guide.
pdf
7. California Enterprise Architecture Framework, Release 1.0
Final, July 15, 2005, page 20, http://www.cio.ca.gov/stateIT/
pdf/California_EA_Framework_Final.pdf
8. State of Minnesota Enterprise Architecture Whitepaper,
December, 2005, http://www.state.mn.us/portal/mn/jsp/con
tent.do?subchannel=-536891918&programid=536911144&id=
536891917&agency=OETweb

83
84
Minnesota Department of Health
625 Robert St. N.
PO Box 64975
St. Paul, MN 55164-0975 October 2007

A Practical Service of Oriented Architecture - 87p

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Practical Service of Oriented Architecture - 87p

Uploaded by

Copyright:

Available Formats

A Practical Service

A Vision for the use of

A Vision for the use of Information

For more information, contact:

MDH Architecture Project Team

Information Technology Coordinating Committee (ITCC)

Produced by MDH Architecture Project Team: Version 1.0, October, 2007

Approved by the Executive Steering Committee for IT (ESC)

About this document

Version 0.9 Draft for Reveiw and Comment 05/18/07 ...........................................4

Version 0.95 Draft for Approval....................................................................................4

Version 1.0 Department Approved October 24, 2007 ...........................................4

What do we mean when we talk about an architecture for MDH?....................11

“Accidental Architecture” ...............................................................................................12

Federal and State Architectures ........................................................................................13

Federal Enterprise Architecture (FEA) .........................................................................13

State of Minnesota Architectures .................................................................................14

MDH Architectural Background.........................................................................................14

Scope of this Project .............................................................................................................15

Process to Develop this Architecture...............................................................................16

Diagram of the Process of Developing this Architecture ......................................17

Part 2: Analysis and Requirements ..............................................................18

Summary of Strategic Plan Analysis: ...........................................................................22

External and Internal Drivers ..............................................................................................22

Discovery and Analysis of our Current Architecture ...................................................24

Description of Current Architecture ...........................................................................24

A Practical Service Oriented Architecture

Architectural Principles ........................................................................................................28

Proposed High Level Architecture....................................................................................33

High Level Architecture Diagram .................................................................................35

Expanded High Level Model .........................................................................................36

SOA Example - Licensing .....................................................................................................38

Detailed Architecture ...........................................................................................................41

Service Access and Delivery Service Area .................................................................42

Service Platform and Infrastructure Service Area............................................................... 43

Application and Component Framework Service Area..................................................... 48

Service Interface and Integration Service Area ................................................................... 51

Data Service Area.......................................................................................................................... 52

Architecture Implications ................................................................................................................ 53

Application development changes ......................................................................................... 53

Continuity of Operations Plan (COOP) ................................................................................... 54

Operational efficiency ................................................................................................................. 54

SOA Governance ........................................................................................................................... 55

Part 4: Maintaining the Architecture ...........................................................59

Maintaining the Architecture ......................................................................................................... 59

Proposed Governance Framework .......................................................................................... 59

Architecture Processes ................................................................................................................ 60

Appendix A: MDH Architectural Team Members ................................................................ 63

Appendix B: MDH Architectural Drivers and Requirements ............................................ 64

Appendix C: Current Infrastructure ......................................................................................... 68

A Practical Service Oriented Architecture

Version 0.9 Draft for Review and Comment 05/18/2007

Version 0.95 Draft for Approval

Added: Maintaining the Architecture section

Added: Appendix D: Response to Comments on the Draft Version

Added: Illustrations and discussion of an example SOA application

Numerous changes have been made throughout the text to correct

Version 1.0 Department Approved October 24, 2007

There were minor changes and corrections including:

The Architecture Review Board now reports directly to the

The document will be formatted and posted on the Internet.

A Practical Service Oriented Architecture