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

A Practical Service Oriented Architecture
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.

A Practical Service Oriented Architecture
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.
A Practical Service Oriented Architecture
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 overall 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
A Practical Service Oriented Architecture
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 department, an analysis of its strategic goals, and an evaluation of its current architecture, we are proposing that the department move toward a service oriented architecture (SOA). A service-oriented architecture is an approach to developing applications using independent reusable modules called services. These may be purchased software that provides services such as creating maps or creating reports. It may also be modules that 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

“Our over-all architectural vision is one where we become very efficient at the foundational operations of information technology such as server administration and help desk, reduce our risk of service failure with appropriate redundancy and back-up, and flexibly develop and deploy component services to help our programs meet the needs of the department.” Page 34

A Practical Service Oriented Architecture
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 serviceoriented 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

A Practical Service Oriented Architecture
8

future will expect that we can consume and deliver web services. It is important that MDH begin the measured adoption of serviceoriented 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
A Practical Service Oriented Architecture
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.

A Practical Service Oriented Architecture
10

Part 1: Introduction

What is Architecture?
ARCHITECTURE: (ANSI / IEEE Std 1471-2000) “the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution” Architecture is about design. Based on certain principles, it answers, how will we build and structure our applications, databases and computer systems? Will there be a few large applications or lots of small ones, integrated databases or separate, large servers or small? We need a plan that answers these design decisions based on agreed upon principles. That plan will lead to our architecture. We want to develop an architecture that answers these questions in a coherent way so that we use our resources efficiently, and our systems work well together to accomplish public health goals. 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.

Architecture in Antiquity
Seshat was the Ancient Egyptian goddess credited with inventing writing. She had dominion over accounting, mathematics, historical record keeping and architecture. She was known as ‘Mistress of the House of Books’ and ‘Mistress of the House of Architects’. Her symbol was a star. http://www.touregypt.net/ featurestories/seshat.htm

A Practical Service Oriented Architecture
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.

A Practical Service Oriented Architecture
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.

A Practical Service Oriented 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
1999 D a ta b a s e S e rv e r S ta n d a rd 1999 W e b B ro w s e r S ta n d a rd 2002 2000 M N E n te rp ris e W i d e D e sk to p T e c h n ic a l H a rd w a re A rc h ite c tu re S ta n d a rd 2002 2000 W e b A p p lic a tio n D e sk to p D e v e lo p m e n t P o lic y S o ftw a re S u ite

1996 E m a il S ta n d a rd (P e g a s u s )

2007 - 2010 S e rvic e O rie n te d A rc h ite c tu re (P ro p o s e d )

1995

1996

1997

1998

1999

2000

2001

2002

2003

2004

2005

2006

2007

2008

2009

1994 - 1999 C lie n t S e rv e r C o m p u t in g (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 )

1999 - 2008 W e b B a s e d A p p lic a tio n s (C o ld F u sio n , J a v a )

A Practical Service Oriented Architecture
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.

A Practical Service Oriented Architecture
15

B usiness P rocesses

A pp licatio ns

Access or Capture

Run on

Info rm a tion/D ata

Support

P la tfo rm /Infra stru ctu re

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

A Practical Service Oriented Architecture
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 info Architectural Im plications of Plans

S trateg ic Plans

An a lyze MD H Strate g ic Pla ns
N ew Technologies D rivers List R equirem ents And Plans

Te ch n o lo gy D riv e rs Fede ral D riv e rs S tate D riv e rs Pa rtne rs an d Citizen D riv e rs

MD H A rch ite cture Docum ent Pa rts 2: Analy sis an d R eq u ire m ents

R equirem ents

MD H A rch ite cture Docum ent Pa rt 3: D e sig n an d A rch ite cture D eve lo p H ig h L eve l A rch itecture
Architecture D ecisions and Plan

R equirem ents And Assessm ent

R equirem ents And Plans

An a lyze P ressures a n d Drivers

D rivers

Strategic Assessm ent of Plan C urrent Infrastructure Im plications

D eve lo p A rch itectura l D esig n P rincip les

Legend
D esign Principles

N eeds and Pressures

An a lyze C urre nt Infrastructure

P rocess

N eeds and Plans

D esign Principles

D ata Flow

So urc e or R e c eiv e r of D ata MD H Divisio ns
Inventory D ata

Inventory Inform ation

D eve lo p H ard w are a n d Softw are Inve ntory

Current Infra structure Spre adshe et

D e sig n Princip les

D ata S tore

Inventory D ata

A Practical Service Oriented Architecture
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: 20062008” (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.

A Practical Service Oriented Architecture
18

Strategic Document or Project MDH Strategic Map and Strategic Profile

Goal

Objective or Description

Architectural Implications

This goal focuses on departmentwide coordination in establishing priorities and outcomes. Increase Policy One object of this goal Impact is to “Provide Credible Information to Internal and External Policy Makers.” Align Resources with This goal “recognizes department Priorities the need for state-of-theart systems – such as information technology and laboratory equipment and facilities – to provide essential support to the department.” Secure balanced and sustainable funding sources Leverage Resources Through Partnerships

Focus on Clear Priorities for Improving Health Outcomes

Requires systems that can share information that can be consolidated across the department One aspect of this objective is to collect quality information and provide the IT tools to analyze the data and report the findings. Need to keep abreast of technological changes.

Maintaining and supporting effective IT resources requires continuing funding. Need effective communication tools to maintain partnerships.

Strengthen the department’s Organizational Effectiveness

This goal calls for Need information systems measuring performance on that are designed to capture a department-wide basis. the right data and to deliver it to the right people at the right time.

A Practical Service Oriented Architecture
19

MDH IT Strategic Map Improve Our Ability to Electronically Exchange Data Strengthen IT Governance & Organization Capacity. Minnesota Create the Public Health infrastructure and Information policies that enable Network (MN- statewide exchange PHIN) of public health information.

Define and establish application and infrastructure architecture. Objectives point to integration, coordination, exchange and security of data.

Need an effective architectural plan. Need an architectural plan for securing and handling our data. Need an architectural plan to mesh with IT governance.

Respond to • community health threats. Protect the public from serious but preventable diseases or injury. Make Minnesota communities healthier • places to live. Enable consumers to access public health and prevention information. •

Need an MDH architecture that can communicate with LPH. In fact, this project is about developing an architecture for public health communication in Minnesota. Need data standards for public health information.

e-Health

Accelerate the use of Health Information Technology in all areas of the state using an Electronic Health Record (EHR)

Person focused (information across facilities) Public- Private collaboration

Need an architecture that can work with electronic health records. It needs to be flexible and adaptable to accommodate record and communications changes. Need an architecture which can support effective security measures

A Practical Service Oriented Architecture
20

Child Health Improved … health Information services statewide System (CHIS) for Minnesota’s children, through the enhanced use and interoperability of child health information systems in Minnesota.

• •

Disease Implement an Surveillance integrated disease Modernization surveillance system

• • • •

Enable rapid access to child health data Standardize collection, management, and secure exchange of public health data Implement routine data quality assurance procedures Foster program evaluation and assessment Interoperate with nation-wide health infrastructure Early detection of disease events Electronic disease reporting Electronic laboratory reporting Rapid dissemination of information to health community and public

Need to support a common identifier, yet maintain data practices policies. Need to support better computer-to-computer communication within MDH applications. Need to develop childfocused tracking and evaluation. Need better integration of disease surveillance applications. Need flexible communications with clinics and hospitals. Architecture needs to support secure electronic messaging. Need data translation and formatting services Need to support rapid development of reports and maps. Need data translation and formatting services. Need data standards. Need flexible electronic communications.

• •

Environmental Health (EH) Knowledge Management

Improve the • environmental health services that Minnesotans receive through strategic application and • management of environmental health data on a statewide basis

Integrate information • to support and improve EH practice • in all state and local • agencies Interconnect local, tribal, state, federal and other key partners to support electronic exchange of environmental health information. Inform consumers about EH information

Table 1: Strategic Plans, New Projects and Architectural Implications

A Practical Service Oriented Architecture
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

A Practical Service Oriented Architecture
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.

A Practical Service Oriented Architecture
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

A Practical Service Oriented Architecture
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.

A Practical Service Oriented Architecture
25

Table: MDH Web Servers, Application Servers and Database Servers Computing Environment Development Test Stage Web/ColdFusion Servers Java Web Applications

Production

Intranet/Internet

Intranet/Internet

Intranet/Internet

Intranet Internet

Intranet/Internet

Intranet/Internet

Intranet/Internet

Intranet Internet

Oracle Database Servers

MIIC PHL and MDH

MIIC PHL and MDH

MIIC PHL and MDH

MIIC

PHL and Others

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

A Practical Service Oriented Architecture
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.

A Practical Service Oriented Architecture
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.

A Practical Service Oriented Architecture
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.

A Practical Service Oriented Architecture
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.

A Practical Service Oriented Architecture
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.
A Practical Service Oriented Architecture
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.

A Practical Service Oriented Architecture
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.

A Practical Service Oriented Architecture
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 efficient at the foundational operations of information technology such as server administration and help desk, reduce our risk of service failure with appropriate redundancy and back-up, and flexibly develop and deploy component services to help our programs meet the needs of the department. 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.
“Service is government’s only business. SOA should be its architecture. “ – Paul W. Taylor, Chief Strategy Officer, Center for Digital Government, (reference 2, page 2)

A Practical Service Oriented Architecture
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.
Application & Component Framework

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

Service Platform and Infastructure Security

A Practical Service Oriented Architecture
35

Data Service Area

It depicts the high level structure of the department’s proposed 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.

Service Interface and Integration

MDH Customers and Employees

The diagram on the right provides a very high level picture of what we are proposing.

Services Access and Delivery

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.

A Practical Service Oriented Architecture
36

L o c a l P u b lic H e a lt h an d G r a n t ee s

M D H C u s to m e rs
C it iz e n s & V is it o r s F e d e ra l A g e n c ie s & M D H E m p l o ye es G ra n to rs

S to rag e S erv e rs / C o m p u ters A p p licatio n D ev elo p m en t D eliv ery S e rv ers (W eb , A p p , D atab a se, F ile , etc.) D eskto p H a rd w are/S o ftw are

S e r v i c e A cc es s & D e l i v e r y
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 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 E -F o r m s P aym en t P r o ce sse s A n al ysi s , S t a t i st i c s, G I S P r e s e n t a t io n R e co r d s M an ag em en t M e s s a g e T r a n s la t io n A d d re s s st an d a r d i z at i o n O th e rs

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

37

A Practical Service Oriented Architecture
Fax

N etw o rks

W e b P o rta l

O n -lin e F o rm s & F ilin g s

P a ym e n ts &
T ra n s fe rs

D i se ase S u r vei l l an ce 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 L a b o r a t o r y T e s t in g 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 U n d e r s e r v e d P o p u la t io n L ic e n s in g V i t a l R eco r d s D i sea se P r even t i o n G u i d an ce S a fe ty M o n i to ri n g ( W a t e r , F o o d , F a c il it ie s )

O n -lin e S ta tus

In P e rs o n

D ata Tran sfer

M a il

b

Phone

C o m m o n S e rv ice C o m p o n en ts (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

H ealth P ro g ra m S erv ice C o m p o n en ts (E xam ples of potentia l ap plications an d services)

M innesota D epartm ent o f H ealth A rchitecture

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

S e rvic e P la tfo rm & Infra s tru c tu re

S ecurity

D a ta S e rvic e A re a

D ata D esc rip tio n

D ata S h arin g

D ata C o n text

SOA Example - Licensing
Consider the development of an application used for professional licensing (Mortician, Nurse, etc.). That application would require several different modules. In our current development approach, the programmers would have to develop and test each one, and then they would compile the application into one file to be deployed on an application server. This would require the developer to create parts of the application that would allow the person to log-in, to administer the users, to check for current license status, to check with the Department of Public Safety (DPS) for certain violations, to process credit card transactions, to check on continuing education, and other processing.
P ro g ra m m in g M o d u le s fo r a
L ic e n s in g A p p lic a tio n (s o u rc e c o d e )
L o g -in A d m in iste r U se rs C h e ck o n cu rre n t lice n se V io la tio n s ch e ck w ith D e p a rtm e n t o f P u b lic S a fe ty 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 C re d it C a rd p ro ce ssin g Issu e N e w lice n se L ice n sin g R e p o rts S e n d p re -e xp ira tio n n o tice S e n d e xp ira tio n n o tice O th e r lice n se p ro ce ssin g

C o m p iled in to a s in g le file

lic e n s e .e a r

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
C re d it C a rd P ro c e s s o r

A p p lic a tio n S e rv e r
lic e n s e .e a r

T he com piled file is deployed on an application server.

Example: Professional Licensing Application 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 e p t o f P u b lic S a fe ty

D a ta b a s e S e rv e r
L ic e n s e d a ta b a s e DPS D a ta U s e rs

D P S data m ight be loaded from a regular file transfer.

A Practical Service Oriented Architecture
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 to the application server, but there would be several modules external to that application. They would be available for other department applications, too. Now, the credit card module will be a web service created and deployed by the Office of Enterprise Technology for use by any state agency. The log-in web service will be a module that any application in the department can use. It could rely on directory services that are hosted at the Department of Human Services. The check with the Department of Public Safety could be a web service that they provide. This would eliminate the need for periodic file transfers. Sending pre-expiration notices and final expiration notices would be done by a web service created for that purpose. It would also be available to other department programs. The following diagram shows how this might look.
E xam p le: P ro fessio n al L icen sin g A p p licatio n S O A A p p licatio n D evelo p m en t A p p ro ach (W S = W eb S ervice) C o d e fo r L icen sin g A p p licatio n
R un Log -in W eb S ervice R un U ser W S R un License C heck W S R un D P S C heck W S R un T ranslate and Load W S R un C redit C ard W S Issue N ew license R un R eporting service R un N otice W S R un N otice W S O ther license processing
C o m p ile d in to a s in g le file

licen se .ear

A Practical Service Oriented Architecture
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
lic e n s e .e a r

In te rn e t
C re d it C a rd P ro c e s s o r

R e p o rtin g S e rv e r

T ra n s la te a n d L o a d S e rv e r
T ra n s la te a n d Load W S

L o g in W S User W S L ic e n s e C h e c k WS N o tic e W S

R e p o rtin g 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 S a fe ty DPS Check w s

D e p a rtm e n t o f H u m a n S e rv ic e s D ire c to ry S e rv e r

OET

D a ta b a s e S e rv e r
L ic e n s e d a ta b a s e

C re d it C a rd w s

DPS D a ta

U se rs

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

A Practical Service Oriented Architecture
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 PHINMS, 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 H L 7 T ranslator M essaging S ystem M essaging S ervice (P H IN -M S )

D ata T ransform ation S ervice (D atabase to H L 7)

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

A Practical Service Oriented Architecture
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 Standard Web Browser Wireless/PDA Collaboration/Communications Other Electronic Channels Internet Intranet Virtual Private Network Legislative/Compliance Supporting Network Services Identity Management Certificates

Service Category Access Channels

Examples of Standards MS Internet Explorer, FireFox Blackberry E-mail, FAX HTTP, HTTPS HTTP, HTTPS Juniper, Cisco Section 508, Accessibility systems SMTP, MIME, IMAP, DNS Oracle Access Manager SAML, PKI

Internet/Intranet/Extranet

Authentication/Single Sign-On

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.
A Practical Service Oriented Architecture
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.
A Practical Service Oriented Architecture
43

Service Category Networks

Storage Server/Computers

Delivery Servers

Application Development

Service Platform and Infrastructure Service Area Service Standard Examples of Standards Wide Area Network Local Area Network Video Conferencing Storage Area Network (SAN) HP EVA Back-up and Recovery CommVault, HP Tape Library Operating Systems Solaris, MS Windows, Linux, Novell Hardware Sun Sparc, Intel based Peripherals Printers, Scanners Web Server Apache Database Server Oracle Application Server Oracle Application Server, Cold Fusion File Server Novell Print Server Novell Other Servers Oracle Portal Languages Java, Cold Fusion, SQL, PERL 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 Operating System Desktop Computer Hardware Desktop Software Desktop Administration MS Visio MS Windows, Linux, Solaris, Mac OS X Laptop, Workstation, Tablet MS Office Novell’s Zen

Desktop Hardware/ Software

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.
A Practical Service Oriented Architecture
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. Associated Service Categories: • Networks Networks provide the connections, protocols, routers and
A Practical Service Oriented Architecture
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 serviceoriented 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
A Practical Service Oriented Architecture
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.

A Practical Service Oriented Architecture
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 Service Category Service Standard Examples of Standards 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.

A Practical Service Oriented Architecture
48

The component framework will consist of two different types of components, although there will be some overlap. Some components will be very health program specific. For instance, some laboratory components may not have any use in other department programs. In the diagram, these are referred to as “Line of Business Service Components”. Other components may be usable by any department programs. A common log-in component could be used in many applications. In the diagram, these are referred to as “Common Service Components”. Service components support reusability, flexibility, and interoperability. To obtain a benefit from reusability, two kinds of analysis need to be performed: 1) an identification of the common service components that can be used by many applications, and 2) a functional analysis of the department’s programs needs to be performed to identify those functions that could be served by a particular component (line of business service component). The Federal Enterprise Architecture’s Service Reference Model can help with the first analysis. That model identifies common crosscutting functions in any governmental organization. The second analysis could be performed as part of the business analysis stage of any new application. Common service components from the first analysis will be usable by many department programs. These components need sufficient support so that MDH developers are aware of them, can easily use them, and can get expert help, when needed. Here is a partial list of suggested common service components: 1. Identity management services 2. Directory services 3. Electronic Forms 4. Reporting tool 5. Statistical analysis service 6. Geographical Information Systems (GIS) service 7. Records management service 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

What are Web Services?
Web services are independent components that have a particular web address (URL). The architecture of web services is the scope of the W3C Web Services Architecture Working Group. It is possible to construct serviceoriented architectures without using web services, but their popularity makes it essential that the department becomes fluent in their use. They are basically a web application that follows certain rules. Those rules are based on several international standards such as: 1. Extensible Markup Language (XML): 2. Hyper Text Transport Protocol (HTTP): 3. Web Services Description Language (WSDL – often pronounced “wiz-del”): 4. Simple Object Application Protocol (SOAP): 5. Universal Discovery, Description and Integration (UDDI): Web services are computer programs that can be written in languages like Java or Cold Fusion. Because they communicate via the international standards, an application written in Java could use a web service written in Cold Fusion or some other language. Because they use standard web addresses and HTTP, they do not usually require special firewall rules for access and use.

A Practical Service Oriented Architecture
49

to be reusable. When changes in the business process occur, a component can be replaced without affecting the rest of the application. Most components should be constructed using web services standards. This will provide opportunities for interoperability. Security: In a typical application, a user is identified (authentication) and given appropriate access to the parts of the application that they have permission to run (authorization). Applications based on web services or other service components must have mechanisms for authenticating and authorizing access to the individual components, but the user should not have to log in again. There are several standards that are available to accomplish this, but they 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

Composite applications:
Service components based on web services standards can be combined to produce complete composite applications. A programming language called the business process execution language (BPEL – pronounced bee-pel) provides the glue to combine several web services into a single application. That composite application could have an end user interface or it could be another web service. This process of combining several services together into an application is called orchestration.

A Practical Service Oriented Architecture
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 Service Category Service Standard Examples of Standards 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. Associated Service Categories: • Middleware Middleware provides the connections and transport of
A Practical Service Oriented Architecture
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 Service Standard Data Inventory Data Dictionary Data Context Data Sharing Taxonomy Content Management Document Management Database Connectivity

Service Category Data Description

Examples of Standards ISO/IEC 11179 Metadata Registries ISO/IEC 11179 Metadata Registries XML topic maps, Web On­ tology Languarge (OWL) Stellant, Vignette Vignette 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.
A Practical Service Oriented Architecture
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. Associated Service Categories: • 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.

A Practical Service Oriented Architecture
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
A Practical Service Oriented Architecture
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
A Practical Service Oriented Architecture
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 ongoing (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

A Practical Service Oriented Architecture
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.

A Practical Service Oriented Architecture
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 S e rvice B a se d A rch ite ctu re D o cu m e n t

2007 - 2008 E sta b lish W e b S e rvice s S e cu rity P o licy

2008 - 2009 T ra in D e ve lo p e rs in U sin g SOA

2008

2009

2010

2011

2007 D e ve lo p P H IN M S M e ssa g in g S e rvice

2008 - 2009 2007 D e ve lo p S O A 2008 2008 E sta b lish P o licie s D e ve lo p D e ve lo p Id e n tity Som e W eb M a n a g e m e n t R e p o rt G e n e ra tio n S e rvice s
S e rvice S e rvice

2009 - 2011 E va lu a te O th e r S O A T o o ls

A Practical Service Oriented Architecture
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 E xecutive S teering C om m ittee (E S C ) In fo rm atio n S ystem s & T ech n o lo g y M an ag em en t C hief Inform ation O fficer 4. T esting G roup

2. M D H A rchitect

C IS O

1. A rchitecture R eview B oard 5. A d H oc D om ain T eam s W eb S ervices

IS T M M anagem ent text

P lanning S ervices

D evelopers E nterprise N etw orking U ser S upport S ervices 3. A dvanced B usiness S ervices

Inform ation T echnology C oordinating C om m ittee (IT C C )

N ovell S ervices

A Practical Service Oriented Architecture
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.
A Practical Service Oriented Architecture
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
R equests F or P urchases N eeds and R equirem ents

D IV IS IO N S

A rc h ite c tu ra l D riv e rs
S tra te g ic P la n s

P o lic ie s
O ver-all A rchitecture P olicy – P urchasing and E xceptions R equests F or E xceptions

P roposed N ew A pplications

4. A p p ro ve IT P u rch a se s
(IS & T M M anagem ent) P olicies and P olicy updates A rchitecture Info A rchitecture Info

S ervice C onsum ption P olicies

3. P ro ce ss R e q u e st fo r E xce p tio n s
(IT C C ) A rchitecture Info A rchitecture Info

6. R e vie w N e w A p p lica tio n s
(M D H A rchitect)

P a rtn e rs a n d C itize n D riv e rs F e d e ra l D riv e rs

R euse and Q uality of S ervice P olicies

R eview A nnually

A pplication D evelopm ent G uidelines

P olicies and P olicy updates

1. D e ve lo p a n d M a in ta in A rch ite ctu re P o licie s
(A rchitecture R eview B oard)

APPROVED A R C H IT E C T U R E
A rchitecture Info

2. R e vie w a n d u p d a te a rch ite ctu re
(A rchitecture R eview B oard)

S ta te D riv e rs

T e c h n o lo g y D riv e rs
C urrent Infrastructure

S O A S ecurity P olicies

5. T e st N e w T e ch n o lo g y
(T esting G roup )

7. C h o o se T e ch n ica l S ta n d a rd s
(A d H oc D om ain T eam )

A p p lic a tio n a n d In fra s tru c tu re In v e n to ry

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

A Practical Service Oriented Architecture
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.

A Practical Service Oriented Architecture
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 John Nieland Karen White Christina Tamondong Jason Tillman Don Brabeck Shelly Siems Steven Ring Communications Infectious Disease Epidemiology
Prevention & Control
Infectious Disease Epidemiology
Prevention & Control
Public Health Labs Policy, Quality and Compliance Bureau Community & Family Health
Promotion Bureau
Environmental Health Division Information Systems & Technology
Management
Communications (document formatting and production)

Michelle Aguilar

A Practical Service Oriented Architecture
63

Appendix B: MDH Architectural Drivers and Requirements
P ro ject o r In itiative
P u b lic H e alth In fo rm a tio n N e tw o rk (P H IN )

R eq u irem ent
M e ssa g in g

D etails
C D C
C o n structio n , a u tom a tic ro u ting , e n cryp tio n , d igita l sig n a tu re s, su p po rt 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 C o n ta ct in fo a nd role s, a ccess co n tro l O ID s -- g lob a lly u n iq u e id e ntifie rs to id e n tify o rg an iza tio n s, cod e sets, e tc. M u st su p p o rt a u dit tra il o f da ta re co rd s a n d acce ss a tte m pts to system s

Im plicatio n s
M D H n e e d s an e ffe ctive m e a ns to su p po rt this ca pa b ility 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 A system to tra ck O ID s w ill b e n e e d ed M D H m u st e xp a n d its use o f au d it 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. M D H n e e d s po licie s an d system s to 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 d iffe re n t ve rsio ns. In o rd er to sh a re info rm a tion , M D H 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. M D H n e e d s to co m ple te o u r 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 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 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 d a ta ba ses 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 . 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 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 .

D ire cto ry S e rvice s O b je ct Id e ntifie r S u pp o rt A u d it tra il

V o ca bu la ry S tan d a rds

F E D E R A L
A u th o riza tio n O p e ra tion a l b e st p ra ctices A u th e n tica tion D a ta M o d e lin g

S u p p o rt system to m ain ta in a nd u p da te co d in g S u p p o rt P H IN L o gical d ata m od e l m a p pin g C le a r p ro cesse s a n d d o cu m enta tion , C o n tin uity o f O p e ra tio n s (C O O ) su p po rt tw o fa cto rs, X .5 0 9

ro le ba sed a uth o riza tio n

D a ta Tra n sla tion

H L 7 fo rm a t su pp o rt

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 In fo rm a tio n N e tw o rk (N H IN ) H e a lth In su ra n ce P o rta b ility a nd A ccou n tab ility A ct (H IP A A ) D e p a rtm e n t o f A g ricultu re – W IC p ro g ra m A u d it tra il L a b da ta fo rm at p asse d , p re scrip tion s, m e d ical reco rds co m in g

H H S
M o st o f M D H is n o t re q uire d to m e e t H IP P A g u ide lin e s, b u t it m igh t b e sm a rt fo r u s to m o ve in th a t d ire ctio n so tha t w e ca n fu lly p a rticipa te in E h e a lth

U SD A
U S D A 's a rch ite ctu ra l p lan s a re n o t cle a r, b u t th e y co u ld h a ve a n im p act 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 P ro te ctio n A g e n cy – E n viro n m en tal H e a lth D ivision Th e E P A se em s to b e focu se d o n d a ta sta nd a rds. T h is m a y h a ve a n im p act o n E H syste m s.

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

A Practical Service Oriented Architecture
64

P ro ject o r In itiative
O E T E n te rp rise A rch ite ctu re P ro je ct M in n e so ta ’s E n te rp rise -w id e T e ch n ica l A rch ite ctu re (EW TA ) D H S ’s M e d ica id In fo rm a tio n T e ch n o log y A rch ite ctu re (M ITA ) p ro je ct C o o rd ina tion o f N P I # 's

R eq u irem ent

D etails
O ET

Im plicatio n s

S e rvice O rien te d A rch ite ctu re T e ch n ica l S ta n d a rd s

P ro m o te w e b se rvice s

W orkin g on ve rsio n 3 w ith b u sin e ss, a p p lica tio n, in fra stru ctu re , d a ta a n d se cu rity d om a in s

S T A T E

A lth o ug h th is p ro je ct is p ro g ressin g ve ry slo w ly, it co uld ha ve a m ajo r im p act o n M D H syste m s a n d in frastructu re . IT d e ve lo p m e n t an d system s w ith in le g islative initia tive s m ust co m p ly w ith th e EW T A in o rd e r to o b ta in fu n d in g . M o st o f th e m ajo r M D H syste m s alre ad y com p ly. M D H sh o u ld b e de sig nin g syste m s th a t ca n in te ro p e ra te w ith D H S 's a rch ite ctu re in so fa r a s w e can d e te rm in e it. N e e d to coo rd ina te th e a ssig nm e n t a n d us e o f N P I's (N a tio na l P rovid e r In d e x)

D H S
P H n e e ds to in te ro p e ra te w ith D H S is w o rkin g o n m a jo r ch a ng e s to the ir m a in syste m s b ase d o n th e M ITA a rch ite ctu re . T h e y w o u ld like to h a ve m u ch im p ro ve d in teg ra tio n w ith th e p u blic h e a lth syste m .

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 e xch a n g e vita l re co rds/b irth & d e a th d a ta b e tw e e n M D H a n d citie s/co un tie s. A so lu tion w o u ld g re a tly in crease the se cu rity a nd d ecre ase th e a m o u n t of 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 A so lu tion w o u ld g re a tly in crease the se cu rity a nd d ecre ase th e a m o u n t of 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 W ould e ase th e co lle ctio n o f fee s fo m a n y se ctio ns in M D H S o m e p u rch a se d ap p licatio ns w ill b e 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 b u ild a pp lica tio ns m o re e fficien tly. C o u ld red uce the n um be r o f ph ysical se rve rs a n d e a se d isaste r re co ve ry. P o te n tia l to re du ce e xp e n sive licen se fe es o r p ro p rie ta ry h a rd w a re . E n h a nce d V P N a n d w ire less co n ne ctio ns w ill n ee d to b e 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 th ro u gh a p a rtne r's n etw o rk. N e e d a w a y to e asily cre a te an d w o rk w ith m a p s o n ou r w e b site U sin g p o rtal so ftw a re a n d m ana g in g o u r w e b site as a po rtal w o u ld le a d 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. P ro vid in g n e tw o rking b an d w id th a n d q u a lity o f se rvice is crucial. S u p p o rt o f ad d itio na l p ro g ram m in g e n viro nm e n ts (F la sh , A JA X ) w ill in clu d e secu rity issu es.

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 e xch a n g e d ata be tw e e n M D H a n d M H A a n d the H osp ita ls

C om m erce
E le ctro n ic P a ym e n ts S e rvice O rien te d A rch ite ctu re (S O A ) A b ility fo r M D H to e a sily acce pt p a ym e nts e le ctro n ically C a p a b ility o f d e ve lop ing a pp lica tio ns w ith re u sab le m od u les.

T E C H N O L O G Y

V irtu a liza tion O p e n S o u rce 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 ca p ab ility

G e o g ra p hica l Info rm a tio n S yste m s (G IS ) P o rta l

M o re M D H d a ta sh o u ld be a nalyze d a n d d ispla ye d o n m a ps. N e e d to im p ro ve inte g ra tion an d m a n ag e m e n t o f M D H a p p lica tio n s a n d in fo rm a tio n po stin gs.

V id e o E n h a nce d w e b use r in te rfa ce

M o re n e e d fo r th e use o f vid eo is e xp e cte d . In crea sed e xp e cta tio n th a t W eb a p p lica tio ns w ill in co rp o rate m o re im a g es a n d p ro vid e be tte r p e rfo rm an ce

A Practical Service Oriented Architecture
65

T E C H N O L O G Y

P ro ject o r In itiative

R eq u irem ent
In te rn ation a liza tio n C a p a b ility XML D a ta M a rts/R e p o rtin g S e cu re F ile T ra n sfe r

D etails
A b ility to crea te a p plica tion s tha t can e a sily w o rk w ith o th e r la n gu a ge s N e e d to e fficie n tly cre a te, p roce ss, a n d tra n sla te X M L d a ta U n lo ck M D H d a ta to m a ke it ava ila b le fo r a n a lysis an d re p o rtin g N e e d to secu rely a n d e ffectively se n d a n d re ce ive la rge file s e lectron ica lly b e tw e e n M D H a n d o u tsid e p a rtn e rs. N e e d to b e ab le to acce p t signa tu res e le ctro n ically o n e lectro nic fo rm s. In crea ses se cu rity o p tio ns.

Im plicatio n s

E le ctro n ic S ign a tu re s R F ID B io m etrics D a ta S h a rin g A g re e m e n ts a nd sin gle a u th o rita tive id en tifie r re p o rtin g to o l a va ilab le fro m ou tsid e fire w a ll to d a ta w a re h o use

N e e d a re p o rt g e ne ra tin g to o l. M a y n e e d a d d ition a l d a ta w a re h o u se so ftw a re . A so lu tion w o u ld ea se th e b u rd e n o f e m a il a tta ch m en ts a n d w o u ld e n su re g re a te r secu rity a n d re lia b ility o f file tra n sfe rs N e e d to w o rk o u t th e le g al 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 .

S e cu rity

LPH A L P H & H O S P
In te g rate d C h ild H e a lth R eco rd A ccess to D ise ase re p o rtin g in fo rm a tio n S tre a m lin ed 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 a n d IT P la ns In crea sed inte g ratio n, co lla b o ra tion , e fficie ncy a n d rep o rtin g ca p ab ility S e e "S um m a ry o f IT Im plica tion s o f D e p a rtm e n t P la ns" fo r m o re info rm a tio n. A n a rch itectu re th at su p p o rts e fficie nt u se o f IT re so u rces an d 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 ca p ab ility. N e e d a fle xib le a rch ite ctu re tha t can 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 N e e d a d a ta a rch itectu re th at ca n su p po rt da ta sh a rin g a n d p rivacy. P o rta l fo r inte g ra te d in fo rm a tion fro m m u ltip le sou rce s a va ilab le in on e -sto p sh o p L a rg e co un ties ne e d to an a lyze th eir o w n d a ta M a ste r p a tien t in d e x n e e d e d fo r p a tien t da ta resid in g in va rio us lo catio ns th ro u gh o u t M D H

A PIC

M D H

M N -P H IN

C o lla bo ra te w ith e -H e a lth a n d lo cal p ub lic he a lth In te g ration a nd d a ta sh a rin g 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 R e lia bility a n d a vailab ility

C h ild ren ’s H e a lth In fo rm a tio n S yste m p ro ject

C o n tin uity o f O p e ra tion s P la n n in g (C O O P ) C a n ce r S u rve illan ce S yste m V ita l R eco rds S yste m

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

M C SS
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 th e n ee ds o f a n e w ca nce r su rve illa nce system

M C H S
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 a n d da ta ne e ds o f a ne w vita l re co rds system

A Practical Service Oriented Architecture
66

P ro ject o r In itiative
W IC S yste m

R eq u irem ent
M o re w e b b a se d

D etails
W IC

Im plicatio n s

M D H
D ise ase S u rve illan ce C o n te n t Managem ent In te g rate d P H IN co m p lia n t system

ID E P & C
N e e d to sup p o rt P H IN re q uirem e n ts

C o m m O ffice
C o n te n t M a n a g em e nt S yste m C o u ld be rela ted to a p o rta l syste 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 L a b o rato ry In fo rm a tio n S yste m (E LIS ) F e d e ral O M B F e d e ral E n te rp rise A rch ite ctu re (F E A ) C D C ’s vie w o f sta te h e alth a g e ncies W eb ba sed syste m th a t is P H IN co m p lian t, a n d a d h oc re po rting ca p ab ilities H ig h le ve l g uid in g a rch ite ctu re fo r C D C a n d o th e r fe d e ra l ag e ncies. E m p h asis o n a n a lysis of b usine ss p ro cesses a nd co m m o n se rvice s. N e e d to sup p o rt P H IN re q uirem e n ts a n d a rch ite ctu re m ust su p po rt a d h oc re p o rtin g ne e ds F e d e ral g ran tin g ag e ncies w ill b e m o vin g to w a rd com p lia nce . It m a y m e a n m o re focus o n com m o n se rvices an d p ro cesse s. It w ill b e d ifficult an d e xp e n sive if e ve ry p ro g ra m in vo lve d in P H IN 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.

L O N G

CDC
C o n ce ptu al w h o le

S tate
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 w ith so m e o f ou r d ata p ro vid e rs

T E R 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 ns E le ctro n ic F o rm S u b m issio ns D a ta Tra n sfe r O n D e m a nd R e p o rts M o re in fo rm a tio n on th e w e b T a xe s/b u d g e t p re ssu re R e p o rts a n d o the r in fo rm a tio n a vaila ble e le ctro n ically B e m o re e fficie n t E xp e cta tio n th a t m ost fo rm s an d d a ta tra n sfe rs ca n b e p e rfo rm e d e lectro nically a t a n y tim e o f d a y o r ye a r. A b ility to sub m it fo rm s e lectronica lly

S tate – D O E R
D e a l w ith "g ra yin g w o rkfo rce " P o ssib le sm a lle r IT sta te w o rkfo rce in the fu tu re . S yste m a dm in istra tio n n e e ds to b e m o re e fficien t. N e e d re lia ble an d acce ssible in frastructu re . N e e d to b e ab le to ea sily g e nera te 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 . F u lfill da ta re q u ests e le ctro n ica lly a n d au tom a tica lly N e e d re po rt ge n e ra to r se rvice th a t ca n e a sily crea te w e b p ag es "D o m o re w ith less" N e e d to sim p lify in fra stru ctu 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.

A b ility to e asily tra n sfe r da ta ele ctron ica lly 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

A Practical Service Oriented Architecture
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 EO Org Description Executive Office, Communications Office, Legal Unit, Library, Minority and Multicultural Health Minority and Multicultural Health Compliance Monitoring Health Policy Environmental Health Infectious Disease Epidemiology Prevention and Control Public Health Laboratory Office of Emergency Preparedness Community and Family Health Health Promotion and Chronic Disease Policy Quality and Compliance Bureau Operations Community and Family Health Promotion Bureau Information Systems and Technology Management Finance and Facilities Management Human Resource Management

MMH CM HP EH IDEPC

PHL OEP CFH HPCD PQC CFHP ISTM FFM HRM

A Practical Service Oriented Architecture
68

Desktop Hardware ORG EO ISTM OEP FFM HRM PHL CFHP EH PQC IDEPC Total Number of Desktops 25 15 1 87 41 239 229 203 200 188 1228 Number of Laptops 17 24 32 17 4 33 107 193 140 70 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

A Practical Service Oriented Architecture
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

A Practical Service Oriented Architecture
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

A Practical Service Oriented Architecture
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

A Practical Service Oriented Architecture
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

A Practical Service Oriented Architecture
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

A Practical Service Oriented Architecture
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

A Practical Service Oriented Architecture
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 ) S erv e r p u rp o se A P P LIC A T IO N C O M M V A U LT DATABASE OS U N IX W IN W IN N O V E LL U N IX W IN (blank ) N O V E LL W IN (blank ) (blank ) (blank ) W IN N O V E LL W IN (blank ) U N IX NT W IN N O V E LL (blank ) LIN U X U N IX W IN (blank ) W IN W IN U N IX LIN U X LIN U X (blank ) LIN U X U N IX W IN U N IX N O V E LL W IN W IN W IN U N IX W IN W IN W IN CFHP 2 1 1 3 3 1 6 7 2 1 2 4 2 2 16 1 4 1 1 3 2 1 1 1 2 1 2 2 2 1 1 2 3 1 3 1 5 1 1 2 3 1 2 1 1 5 1 30 1 1 3 2 8 EH FFM ID E P C 9 3 1 IS T M 5 5 PHL 1 PQC 3 2 1 G ran d T o tal 18 7 7 1 21 1 7 2 1 2 4 2 2 16 3 4 1 1 3 2 1 1 1 6 2 2 2 2 1 3 3 1 8 3 1 2 3 1 2 1 1 5 1 158

DHCP D IR E C T O R Y DNS E N V IR M O N IT O R E Q U IP M O N IT O R FAX F ILE /P R IN T F IR EW A LL FTP G IS G R O U PW IS E N E T M O N IT O R OTHER

P H IN M S SANMANAG E SAS TEST V IS IO N S H A R E VPN W EB

1

W EBTRENDS ZENW O RKS C IT R IX IM A G IN G S A N A p plia nce SPSS V in gette S erver V oice A pp S erver G rand T otal

5

7

2

26

76

12

A Practical Service Oriented Architecture
76

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

C old F usio n C old F usio n

A Practical Service Oriented Architecture
77

ORG EO EO FFM FFM FFM FFM FFM FFM FFM FFM FFM FFM HPCD HRM HRM HRM HRM HRM HRM HRM HRM HRM HRM HRM HRM HRM ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C

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

A p p L an g u ag e C old F usio n C old F usio n Java C old F usio n C old F usio n C old F usio n C old F usio n C old F usio n C old F usio n C old F usio n C old F usio n C old F usio n Java C old F usio n C old F usio n C old F usio n C old F usio n C old F usio n C old F usio n C old F usio n C old F usio n C old F usio n C old F usio n C old F usio n C old F usio n C old F usio n Java, P E R L A C C E S S , Ja va Java, P E R L Java Java Java Java Java Java Java V isua l F ox P ro V isua l F ox P ro V isua l F ox P ro V isua l F ox P ro V isua l F ox P ro Java V isua l F ox P ro V isua l F ox P ro F oxP ro F oxP ro F oxP ro F oxP ro M S A ccess M S A ccess

D atab as e O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle A C E S S /O racle O racle O racle O racle O racle O racle O racle O racle O racle V isua l F ox P ro V isua l F ox P ro V isua l F ox P ro V isua l F ox P ro V isua l F ox P ro O racle V isua l F ox P ro V isua l F ox P ro F oxP ro F oxP ro F oxP ro F oxP ro M S A ccess M S A ccess

A Practical Service Oriented Architecture
78

ORG ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C ID E P C IS T M IS T M IS T M IS T M IS T M IS T M IS T M OEP OEP OEP OEP PHL PHL PHL PHL PHL PHL PQC PQC PQC PQC PQC PQC PQC PQC PQC PQC PQC PQC PQC PQC PQC PQC PQC PQC PQC PQC PQC PQC

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

A p p L an g u ag e S yb ase D W B , C + M S A ccess M S A ccess M S A ccess

D atab as e S yb ase M S A ccess M S A ccess M S A ccess

M S A ccess M S A ccess M S A ccess C old F usio n C old F u sio n C old F usio n C old F usio n C old F usio n C old F usio n C old F usio n Java Java Java Java

M S A ccess M S A ccess M S A ccess O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle O racle

O racle F orm s & R eports O racle Java O racle M S A ccess A ccess Java O racle Java O racle Java O racle Java O racle O racle F orm s 6i O racle O racle F orm s 6i O racle O racle F orm s 6i O racle O racle F orm s 6i O racle O racle F orm s 6i O racle Java O racle O racle F orm s 6i O racle O racle F orm s 6i O racle O racle F orm s 6i O racle Java O racle Java O racle O racle F orm s 6i O racle O racle F orm s 9i O racle Java O racle P o w er B u ilder O racle Java O racle P o w er B u ilder O racle Java O racle O racle F orm s 6i O racle M S E xcel O racle M S E xcel O racle

A Practical Service Oriented Architecture
79

ORG PQC PQC PQC PQC PQC PQC PQC

A p p licatio n N a m e H C C IS M a intena nce (D a ta Load / A ud its / P relim 2P rod) H C C IS M etada ta H C C IS C losed H ospital M e dical R ecords L ocator C D I P rintform s C D I A udits (D ata Loa d / A u dits / P relim 2P rod) C D I M e tad ata H E P M E R C (M edica l E duc atio n R ese arch C ost)

A p p L an g u ag e O racle F orm s 6i O racle F orm s 6i Java M S E xcel O racle F orm s 6i O racle F orm s 6i m od_plsql, H T M L

D atab as e O racle O racle O racle O racle O racle O racle 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
A Practical Service Oriented Architecture
80

ESC FEA GIS HL7

Identity Management

IMAP Interoperability ITCC

MIME NPI OET OMB Open Source

PERL

PHIN PHP PKI Portal

Executive Steering Committee for Information Technology: It is chaired by the Chief Financial Officer and contains three selected managers and the CIO. Federal Enterprise Architecture Geographical Information System 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 Management pertains to the creation, modification and removal of 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. Internet Message Access Protocol The ability of two or more systems or components to exchange information and to use the information that has been exchanged [IEEE 90]. Information Technology Coordinating Committee: An IT steering committee at the Minnesota Department of Health. It includes representatives from five division/bureaus and the CIO. Multipurpose Internet Mail Extensions National Provider Identifier Office of Enterprise Technology (State Office) Federal Office of Management and Budget 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 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. CDC’s Public Health Information Network PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. Public Key Infrastructure 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.

A Practical Service Oriented Architecture
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 XMLbased 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.

A Practical Service Oriented Architecture
82

References
1. Chappell, David A., “Enterprise Service Bus”, 2004, O’Reilly Press 2. Service-Oriented Architecture: Making Collaborative Government 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. Roadmap 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/content.do?subchannel=-536891918&programid=536911144&id=536891917&agency=OETweb

A Practical Service Oriented Architecture
83

A Practical Service Oriented Architecture
84

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

October 2007

Sign up to vote on this title
UsefulNot useful