Your SlideShare is downloading. ×
A Practical Service Oriented Architecture
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

A Practical Service Oriented Architecture

1,463
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,463
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. A Practical Service Oriented Architecture A Vision for the use of Information Technology at MDH MDH Architecture Project Team: 2007
  • 2. 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)
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. It is future directed and asks, where do we want to be with regard to information technology in three years? Or five years? The MDH Architecture Project To address this problem, the Information Technology Coordinating Committee (ITCC) determined that the development of an architecture was its top priority project. This project is focused on the development of a high level architecture for the department’s technology, applications and data. It will establish an over- all approach, but not specify detailed standards and products. There were three major parts to the project: 1) analysis of the department’s needs and requirements, 2) assessment of ability of the current architecture to meet those needs, and 3) design of a high level architecture to meet those needs. Analysis Phase The project team looked at the department’s strategic plans and recent initiatives for technology implications. We also examined internal and external pressures and requirements that we compiled into a list of “drivers”. MDH strategic plans and projects focus on the need for efficiency in the use of our information technology resources, better communication with our partners, and improved integration of the programs within the department. The drivers are diverse, from specific CDC requirements to general pressure to deal with the aging work force. There is a movement toward increased system-to-system electronic communication. More information will be extracted from an existing system (e.g. hospital, electronic medical record) and transferred automatically to MDH systems. MDH must be able to support that communication. There is an increased need for flexibility and adaptability. As our partners (local, state, and federal) implement systems, we need to adapt to handle the formats and protocols with which we receive and send the information. The project team completed an inventory and an evaluation of MDH applications, servers, and desktops. MDH is moving toward more coordinated and standardized systems. However, there are many opportunities for improved efficiencies and, we still have many individual programs that have purchased the same or similar expensive software components that have already been purchased for department-wide availability. In the area of applications, we A Practical Service Oriented Architecture 6
  • 8. have developed many independent systems with their associated databases. It is challenging to integrate systems that were not designed for a broader perspective. Design Phase The project team developed a list of design principles for the proposed architecture. These principles guide the design of the architecture and the selection of technology building blocks. Principle 1: Customer-Centric Service Delivery Principle 2: Department Focus Principle 3: Department Data Focus Principle 4: Interoperability and Reusability Principle 5: Resilience Principle 6: Follow State and Department Standards Principle 7: Comply with State and Federal Statutes Principle 8: Ownership Value Driven Principle 9: Mainstream Technology Use Principle 10: Department Security Focus Principle 11: Open Standards and Open Source Software Proposed Architecture Based on an assessment of the drivers that are pushing the “Our over-all architectural vision is department, an analysis of its strategic goals, and an evaluation of one where we become very efficient its current architecture, we are proposing that the department move at the foundational operations of information technology such as toward a service oriented architecture (SOA). server administration and help desk, reduce our risk of service failure A service-oriented architecture is an approach to developing with appropriate redundancy and back-up, and flexibly develop and applications using independent reusable modules called services. deploy component services to help These may be purchased software that provides services such as our programs meet the needs of the creating maps or creating reports. It may also be modules that department.” Page 34 are developed by MDH developers. When these services are constructed to be available in an intranet or on the Internet, and they are constructed using a specified set of standards, they are called “web services”. As an example, consider applications that require a log-in. In most cases, an application developer had to design and construct the security structure, a module to administer the users and a log-in module to capture the username and password. If a well tested secure log-in module were constructed and deployed as a common A Practical Service Oriented Architecture 7
  • 9. service, then the department’s application developers could connect to that module. They would not have to develop their own. Similarly, other common and program specific services could be developed. In an SOA, many of these services would already be available, or would be created for future reuse. Thus, developing applications in this environment becomes a process of creating and using services. As more services are built, applications become a collection of services. In a full-blown service oriented architecture, whole applications and new services can be constructed as composites of individual services. Why SOA? The advantage of reusing or sharing component services is considerable. It would reduce the purchase and development of redundant systems. Currently, each application development group in the department must figure out the security and develop a log-in system for their applications. Instead, they could use a well-tested service. If a business process changes, applications in an SOA can adapt quickly by just changing the component services that are affected. For instance, if the state chooses a different vendor for credit card transactions, all that needs to be changed is the credit card service. Moving toward a service-oriented architecture will allow MDH to share expensive software components, reduce the redundant development of many common components, and become more flexible and adaptable to meet the expected changes in health related information technology. We are not alone in moving in this direction. The project team used the Federal Enterprise Architecture (reference 4) framework as our model for the MDH architecture. Several federal agencies are also adopting service-oriented architectures. The Office of Enterprise Technology released a white paper in November, 2005 advocating that the state of Minnesota move toward service- oriented architecture. Other state health departments such as Arizona and Massachusetts have stated their intent to deploy a SOA. Many of the systems that we will need to connect with in the A Practical Service Oriented Architecture 8
  • 10. future will expect that we can consume and deliver web services. It is important that MDH begin the measured adoption of service- oriented architecture. A View of the Proposed MDH Architecture A view of the proposed architecture is provided on the diagram on page 37. Each dark (blue, in color) rectangular block represents a service area that contains the building blocks of the architecture. The Technical Reference Model from the Federal Enterprise Architecture framework consists of a hierarchy of service areas, service categories and service standards. In the diagram, service area boxes show some of the categories within them. In this diagram, moving from left to right, MDH customers, partners and employees connect to component services and applications with a variety of service access and delivery mechanisms. Those services and applications interoperate with each other and databases through protocols and other services that are part of the “Service Interface and Integration” service area. The interface and integration services provide the “glue” that makes that communications and integration work. Security is an over-riding consideration that is part of each of the service areas. The “Service Platform and Infrastructure” service area supports all of the services, databases and access mechanisms. This is a conceptual diagram, and it does not designate where the pieces of this architecture will actually be located. It describes how users of department resources will connect to applications and services (in the component framework) through certain access channels. Those components run on servers and networks (Service Platform & Infrastructure). The services connect to each other and to databases using networking protocols and data transformation tools. Security is an inherent concern of whole diagram. Implementing the Architecture: Although a complete implementation plan was out of scope for this project, the following lists some implications of this proposal: • Application Development: Big changes will be needed in methods, coordination, organization, and training of MDH application developers. A thorough analysis of MDH business A Practical Service Oriented Architecture 9
  • 11. 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
  • 12. Part 1: Introduction What is Architecture? Architecture in Antiquity ARCHITECTURE: (ANSI / IEEE Std 1471-2000) Seshat was the “the fundamental organization of a system, embodied in its Ancient Egyptian goddess credited components, their relationships to each other and the environment, with inventing and the principles governing its design and evolution” writing. She had dominion Architecture is about design. Based on certain principles, it over accounting, answers, how will we build and structure our applications, mathematics, databases and computer systems? Will there be a few large historical record keeping applications or lots of small ones, integrated databases or separate, and architecture. She was large servers or small? We need a plan that answers these design known as ‘Mistress of decisions based on agreed upon principles. That plan will lead to the House of Books’ and our architecture. We want to develop an architecture that answers ‘Mistress of the House of these questions in a coherent way so that we use our resources Architects’. Her symbol was efficiently, and our systems work well together to accomplish a star. public health goals. http://www.touregypt.net/ featurestories/seshat.htm What do we mean when we talk about an architecture for MDH? An enterprise architecture provides a systematic approach to aligning information technology with the department’s goals and priorities. An architecture describes the framework of applications, databases, hardware and software that the department should move toward to efficiently support its programs and goals. It is future directed. Implementing enterprise architecture and the processes to sustain it will provide the department with a comprehensive approach to management and development of our IT environments. An architecture is a design plan for future applications and infrastructure. Except in special circumstances, it will be too expensive to go back and change existing applications to comply with the new architecture. When a system or application is being changed for business reasons or maintenance costs, then we should consider a redesign of the system to comply with our architectural plans. This project is aimed at a high-level architecture. It will provide the basic approach to the structure of the department’s information technology. When the department considers technology purchases, the architecture can guide the selection of products. A Practical Service Oriented Architecture 11
  • 13. 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
  • 14. 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
  • 15. State of Minnesota Architectures In 2002, the Information Policy Office (now incorporated into OET) released version 1.0 the Minnesota Enterprise Technical Architecture. It has been updated several times since the initial release. Legislative initiatives and development projects within state government must comply with this architecture to receive state funding. In December 2005, OET released a whitepaper from an on-going enterprise architecture project called the State of Minnesota Enterprise Architecture Whitepaper. This paper advocated moving the state toward a service oriented architecture (SOA). An SOA is an architecture based on reusable components. That architecture project is still in progress. MDH Architectural Background The following timeline depicts the approximate dates of some important state and department standards and architectures. Also, it brackets the time span for different eras of computing at the department. The bracketed dates are very loose and not exclusive. There are some client-server applications being developed at the present time, and proposed service oriented architecture usually uses Web applications. The “service orientation” refers to the structure of the application and the standards that it uses. 2000 M DH W eb B ased A rc h ite c tu re 2002 1999 2000 M N E n te rp ris e W i d e D a ta b a s e S e rv e r D e sk to p T e c h n ic a l S ta n d a rd H a rd w a re A rc h ite c tu re 1999 S ta n d a rd 2002 W e b B ro w s e r 2000 W e b A p p lic a tio n D e sk to p 2007 - 2010 1996 S ta n d a rd D e v e lo p m e n t P o lic y S o ftw a re S e rvic e O rie n te d E m a il S ta n d a rd A rc h ite c tu re S u ite (P e g a s u s ) (P ro p o s e d ) 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 1999 - 2008 1994 - 1999 W e b B a s e d A p p lic a tio n s C lie n t S e rv e r C o m p u t in g (C o ld F u sio n , J a v a ) (D B A S E , F o x P ro , O ra cle F o rm s P o w e rB u ild e r ) A Practical Service Oriented Architecture 14
  • 16. 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
  • 17. B usiness P rocesses A pp licatio ns Access or Capture Run on Info rm a tion/D ata P la tfo rm /Infra stru ctu re Support The purpose of this project is to develop a high-level conceptual architecture for the department. We will not be identifying the vendor nor model of parts of the infrastructure, but we will describe what infrastructure services must be available. INSIDE the scope of this project: • High-level technical, application and data architecture for the Department. • A policy that incorporates the use of the architecture in Department IT decision making. • Recommendations for maintenance of the architecture. OUTSIDE the scope of this project: • Detailed architecture decisions (product and vendor) except where there are strong existing current standards. • Detailed analysis of the Department’s applications. • Thorough business process analysis of the Department. This project will not aim at changing the basic processes. • Detailed data analysis to identify common entities and data elements. • Thorough analysis of information in the Department. Process to Develop this Architecture In thinking about architecture we might ask, how well are our applications structured to support our goals and objectives? Does the structure and choice of our infrastructure support our A Practical Service Oriented Architecture 16
  • 18. applications and other goals? Is our data organized and deployed to effectively support the department’s programs and goals. The major process steps are outlined below. A diagram of the process is also included. • In order to evaluate how our architecture is meeting our goals we need to analyze MDH strategic plans and major new initiatives and determine their information technology implications. • There are many pressures and requirements that the department needs to meet or respond to. In this step we will analyze external and internal requirements and drivers. • We need to assess the current MDH infrastructure in light of our strategic goals and requirements to determine how well it is meeting our needs. • Develop requirements and design principles which will be used in the development of the proposed architecture. • Draft a high level architecture that meets our design principles and requirements. This project has established a team with staff from each division or bureau to perform these steps and communicate with the department. Diagram of the Process of Developing this Architecture Strategic Plan Architectural info Im plications of Plans S trateg ic An a lyze MD H Plans MD H A rch ite cture Strate g ic Docum ent Pla ns MD H Pa rt 3: R equirem ents A rch ite cture D e sig n an d N ew Technologies Docum ent A rch ite cture Te ch n o lo gy D rivers List Pa rts 2: D eve lo p H ig h D riv e rs R equirem ents Analy sis an d R equirem ents L eve l And Plans R eq u ire m ents And Assessm ent Architecture A rch itecture D ecisions and Plan Fede ral An a lyze D riv e rs R equirem ents P ressures And Plans Strategic Assessm ent of a n d Drivers D rivers Plan D eve lo p C urrent Infrastructure Im plications A rch itectura l Legend S tate D esig n D esign D riv e rs P rincip les Principles N eeds and P rocess An a lyze Pa rtne rs Pressures C urre nt an d Citizen Infrastructure D esign D riv e rs Principles D ata Flow N eeds and Plans So urc e or R e c eiv e r of D ata Inventory D ata MD H D e sig n Divisio ns D eve lo p Princip les H ard w are Current Infra structure D ata S tore a n d Softw are Spre adshe et Inve ntory Inventory Inform ation Inventory D ata A Practical Service Oriented Architecture 17
  • 19. Part 2: Analysis and Requirements Strategic Planning An enterprise architecture should be designed to help MDH meet its strategic and tactical goals. Therefore, one of the important activities in the development of this architecture is to review our strategic plans for any information technology implications. The department’s most recent strategic planning produced a “Strategic Map and Strategic Profile” in November of 2005 (http:// fyi.health.state.mn.us/fadmin/hrm/workforce/materials/MDH_ strat_plan.pdf). That was followed by an “IT Strategic Map: 2006- 2008” (http://fyi.health.state.mn.us/comm/esc/stratmap.pdf). Few divisions have produced strategic plans, but the Policy Quality and Compliance Bureau produced an “IT Strategic Plan 2005 – 2007”. Although the department regularly develops high-level strategic plans, it often makes decisions about major initiatives and projects. These projects are usually based on the strategic plans, and they are an implicit expression of strategic direction. For that reason, we are including an analysis of the architectural implications of some of the recent major projects within the department. The following table lists items from these strategic plans that have architectural implications. A Practical Service Oriented Architecture 18
  • 20. Strategic Goal Objective or Description Architectural Implications Document or Project MDH Focus on Clear This goal focuses Requires systems that can Strategic Map Priorities for on department- share information that can and Strategic Improving Health wide coordination in be consolidated across the Profile Outcomes establishing priorities and department outcomes. Increase Policy One object of this goal One aspect of this objective is Impact is to “Provide Credible to collect quality information Information to Internal and provide the IT tools to and External Policy analyze the data and report Makers.” the findings. Align Resources with This goal “recognizes Need to keep abreast of department Priorities the need for state-of-the- technological changes. art systems – such as information technology and laboratory equipment and facilities – to provide essential support to the department.” Secure balanced and Maintaining and supporting sustainable funding effective IT resources requires sources continuing funding. Leverage Resources Need effective Through Partnerships communication tools to maintain partnerships. Strengthen the This goal calls for Need information systems department’s measuring performance on that are designed to capture Organizational a department-wide basis. the right data and to deliver it Effectiveness to the right people at the right time. A Practical Service Oriented Architecture 19
  • 21. MDH IT Define and establish Need an effective Strategic Map application and architectural plan. infrastructure architecture. Improve Our Ability Objectives point to Need an architectural plan to Electronically integration, coordination, for securing and handling our Exchange Data exchange and security of data. data. Strengthen IT Need an architectural plan to Governance & mesh with IT governance. Organization Capacity. Minnesota Create the • Respond to • Need an MDH Public Health infrastructure and community health architecture that can Information policies that enable threats. communicate with LPH. Network (MN- statewide exchange • Protect the public In fact, this project is PHIN) of public health from serious but about developing an information. preventable diseases architecture for public or injury. health communication in • Make Minnesota Minnesota. communities healthier • Need data standards for places to live. public health information. • Enable consumers to access public health and prevention information. e-Health Accelerate the use of Person focused • Need an architecture that Health Information (information across can work with electronic Technology in all facilities) health records. It needs to areas of the state Public- Private be flexible and adaptable using an Electronic collaboration to accommodate record Health Record (EHR) and communications changes. • Need an architecture which can support effective security measures A Practical Service Oriented Architecture 20
  • 22. Child Health Improved … health • Enable rapid access to • Need to support a Information services statewide child health data common identifier, yet System (CHIS) for Minnesota’s • Standardize collection, maintain data practices children, through management, and policies. the enhanced use secure exchange of • Need to support better and interoperability public health data computer-to-computer of child health • Implement routine communication within information systems data quality assurance MDH applications. in Minnesota. procedures • Need to develop child- • Foster program focused tracking and evaluation and evaluation. assessment Disease Implement an • Interoperate with • Need better integration Surveillance integrated disease nation-wide health of disease surveillance Modernization surveillance system infrastructure applications. • Early detection of • Need flexible disease events communications with • Electronic disease clinics and hospitals. reporting • Architecture needs to • Electronic laboratory support secure electronic reporting messaging. • Rapid dissemination • Need data translation and of information to formatting services health community and • Need to support rapid public development of reports and maps. Environmental Improve the • Integrate information • Need data translation and Health (EH) environmental to support and formatting services. Knowledge health services that improve EH practice • Need data standards. Management Minnesotans receive in all state and local • Need flexible electronic through strategic agencies communications. application and • Interconnect local, management of tribal, state, federal environmental health and other key data on a statewide partners to support basis electronic exchange of environmental health information. • Inform consumers about EH information Table 1: Strategic Plans, New Projects and Architectural Implications A Practical Service Oriented Architecture 21
  • 23. 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
  • 24. • 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
  • 25. 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
  • 26. 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
  • 27. Table: MDH Web Servers, Application Servers and Database Servers Computing Environment Development Test Stage Production Web/ColdFusion Servers Intranet/Internet Intranet/Internet Intranet/Internet Intranet Internet Java Web Applications Intranet/Internet Intranet/Internet Intranet/Internet Intranet Internet Oracle Database Servers MIIC PHL and MIIC PHL and MIIC PHL and MIIC PHL and Others MDH MDH MDH Other Servers FTP SAS/Dataflux Web Trends (Note: MIIC is the Minnesota Immunization Information Connection; PHL is the Public Health Lab; MDH represents other databases that are associated with web applications; FTP is the file transfer protocol; SAS provides statistical and reporting capabilities; DataFlux is a data quality tool that provides GIS coordinates and US Post Office addresses; WebTrends provides analysis about web user activities.) There are other web servers in the department. Some divisions have their own intranet server, and there are many internal web servers that run division specific applications. There are some Internet facing servers that are managed by divisions. Databases Because most of our data structures (tables, files, datasets) are tied to particular applications, we have many special purpose datasets. Although the department has developed data standards, these have been rarely used in department databases because, 1) the database was created before the standards were developed, 2) the developers did not know about the standard, and 3) meeting federal standards was the priority. The department has data in databases on which we would like to report, but we do not have the tools, staff resources or training to extract it. Databases tend to be created for each application system. Most of A Practical Service Oriented Architecture 26
  • 28. 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
  • 29. 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
  • 30. 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
  • 31. 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
  • 32. 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
  • 33. 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
  • 34. 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
  • 35. A more practical service-oriented approach to choosing and developing systems will provide the Department of Health with considerable benefit. It will establish a unifying concept for the direction in which we want to move, and that will guide our selection of products in the future. It will also improve the opportunities for integration, and reduce unplanned redundancy. In a practical service oriented approach, MDH will need to evolve into the adoption of new technology. We should identify, deploy, and support common services. A few new applications should be developed using SOA techniques. Application development teams need to become familiar with SOA and test its capabilities. We should look for opportunities and coordinate how we adopt service orientation. The infrastructure building blocks should be prioritized, and implemented as needed with new applications. As the need arises, we can enhance our infrastructure with special tools that will allow us to better develop, support and maintain services and applications. Our over-all architectural vision is one where we become very “Service is government’s only efficient at the foundational operations of information technology business. SOA should be its architecture. “ such as server administration and help desk, reduce our risk of service failure with appropriate redundancy and back-up, and – Paul W. Taylor, Chief Strategy flexibly develop and deploy component services to help our Officer, Center for Digital programs meet the needs of the department. Government, (reference 2, page 2) We are not alone in moving toward a service oriented architecture. Other state health departments, state governments and federal agencies are also moving in this direction. • The State of Minnesota’s Office of Enterprise Technology published a whitepaper (reference 8) which advocates that the state move toward a service oriented architecture. • The states of California and Massachusetts have published architectures which focus of service orientation (reference 6). • Public health departments in Arizona and Massachusetts are adopting SOA. • Federal agencies like CDC and CMS (Centers for Medicaid and Medicare Services) are moving toward SOA. In fact, one of the best primers on SOA is “MITA Service Oriented Architecture – A Primer” (reference 3). The Medicaid Information Technology Architecture (MITA) is the new direction that CMS is moving toward. A Practical Service Oriented Architecture 34
  • 36. High Level Architecture Diagram In order to organize all of the building blocks that go into an architecture, we have chosen to follow the categories of technology that are provided in the Federal Enterprise Architecture (FEA) that was discussed above. We have made a few modifications to its structure. The diagram on the right provides a very high level picture of what Application & Component Framework we are proposing. Service Interface and Integration MDH Customers and Employees Services Access and Delivery It depicts the high level structure of the department’s proposed Data Service Area architecture. Each dark pillar and row represents a service area that contains the building blocks of the architecture. Later, we will drill down into each service area to identify the detailed building blocks within it. In this diagram, MDH Customers, partners and employees connect to services and applications with a variety of service access and delivery mechanisms. Those services and applications interoperate with each other and databases through protocols and other services that are part of the “Service Interface and Integration” service area. Service Platform and Security is an over-riding consideration that is part of each of the Infastructure service areas. The “Service Platform and Infrastructure” service Security area supports all of the services, databases and access mechanisms. A Practical Service Oriented Architecture 35
  • 37. 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
  • 38. 37 A Practical Service Oriented Architecture M D H C u s to m e rs L o c a l P u b lic H e a lt h F e d e ra l A g e n c ie s & an d G r a n t ee s C it iz e n s & V is it o r s M D H E m p l o ye es G ra n to rs D ata Fax N etw o rks Tran sfer M a il b Phone & F ilin g s W e b P o rta l T ra n s fe rs In P e rs o n P a ym e n ts & O n -lin e F o rm s O n -lin e S ta tus S e r v i c e A cc es s & D e l i v e r y S to rag e A u th e n ti c a ti o n / S i n g le S i g n -O n In t e r n e t /In t r a n e t /E x t r a n e t A cce ss C h an n e l s Id e n t i t y P r iv a c y a n d D i se ase S u r vei l l an ce S erv e rs / C o m p u ters A u th e n ti c a ti o n D i r e ct o r y S er vi c e s O u t b r eak an d C o m p l ai n t I n vest i g a t i o n E -F o r m s L a b o r a t o r y T e s t in g P aym en t P r o ce sse s E m e rg e n c y P re p a re d n e s s P r o v i d e s er vi ce s f o r A n al ysi s , S t a t i st i c s, G I S U n d e r s e r v e d P o p u la t io n D eliv ery S e rv ers P r e s e n t a t io n L ic e n s in g R e co r d s M an ag em en t (W eb , A p p , D atab a se, F ile , etc.) V i t a l R eco r d s S ecurity M e s s a g e T r a n s la t io n C o m m o n S e rv ice C o m p o n en ts A d d re s s D i sea se P r even t i o n H ealth P ro g ra m S erv ice C o m p o n en ts st an d a r d i z at i o n G u i d an ce (E xam p les o f co m m o n s erv ice co m p o n en ts) In clu d es S e cu rity, P resen tatio n , an d B u sin e ss L o g ic (E xam ples of potentia l ap plications an d services) S a fe ty M o n i to ri n g S e rvic e P la tfo rm & Infra s tru c tu re A p p lic a tio n a n d C o m p o n e n t F ra m ew o rk O th e rs ( W a t e r , F o o d , F a c il it ie s ) A p p licatio n D ev elo p m en t M innesota D epartm ent o f H ealth A rchitecture S e r v ic e In t e r f a c e & In t e g r a t io n D a t a T r an sf o r m a t i o n M id d le w a r e A p p l i cat i o n I n t eg r a t i o n D ata D ata D ata D a ta A re a D eskto p H a rd w are/S o ftw are S h arin g C o n text S e rvic e D esc rip tio n
  • 39. SOA Example - Licensing Consider the development of an application P ro g ra m m in g M o d u le s fo r a used for professional licensing (Mortician, L ic e n s in g A p p lic a tio n (s o u rc e c o d e ) Nurse, etc.). That application would require L o g -in several different modules. In our current A d m in iste r U se rs development approach, the programmers would have to develop and test each C h e ck o n cu rre n t lice n se one, and then they would compile the C o m p iled in to a s in g le file V io la tio n s ch e ck w ith application into one file to be deployed D e p a rtm e n t o f P u b lic S a fe ty on an application server. This would T ra n sla te a n d L o a d D a ta fro m P u b lic S a fe ty require the developer to create parts of the C re d it C a rd p ro ce ssin g lic e n s e .e a r application that would allow the person to log-in, to administer the users, to check Issu e N e w lice n se for current license status, to check with L ice n sin g R e p o rts the Department of Public Safety (DPS) for certain violations, to process credit S e n d p re -e xp ira tio n n o tice card transactions, to check on continuing S e n d e xp ira tio n n o tice education, and other processing. O th e r lice n se p ro ce ssin g The accompanying illustration depicts some of the possible modules that would need to be developed and their subsequent compilation into a file called “license.ear” (assuming we are programming in a language called Java). That file would be deployed on an application server as shown in the following diagram. In order to check with the Department of Public Safety, we may need to periodically transfer a file to our database. We also need to keep user log-in information in our database for the application. In te rn e t A p p lic a tio n Example: Professional C re d it C a rd P ro c e s s o r S e rv e r T he com piled file is deployed on an application server. Licensing Application lic e n s e .e a r Current Application Deployment Approach (not showing firewalls) S ta te o f M in n e s o ta N e tw o rk D a ta b a s e S e rv e r D e p t o f P u b lic S a fe ty L ic e n s e d a ta b a s e DPS U s e rs D a ta D P S data m ight be loaded from a regular file transfer. A Practical Service Oriented Architecture 38
  • 40. In a SOA environment, the application developer would use several existing services or create services that could be used by this application as well as others. The application might look like the following. The program would use (“run”) independent modules called “web services” intermixed with some code that was specific to the application. The resulting application would be deployed E xam p le: P ro fessio n al L icen sin g A p p licatio n to the application server, but there would be S O A A p p licatio n D evelo p m en t A p p ro ach several modules external to that application. (W S = W eb S ervice) They would be available for other department C o d e fo r L icen sin g applications, too. A p p licatio n Now, the credit card module will be a web service created and deployed by the Office of R un Log -in W eb S ervice Enterprise Technology for use by any state R un U ser W S agency. The log-in web service will be a R un License C heck W S module that any application in the department C o m p ile d in to a s in g le file can use. It could rely on directory services R un D P S C heck W S that are hosted at the Department of Human Services. The check with the Department of R un T ranslate and Load W S Public Safety could be a web service that they licen se .ear R un C redit C ard W S provide. This would eliminate the need for periodic file transfers. Sending pre-expiration Issue N ew license notices and final expiration notices would R un R eporting service be done by a web service created for that purpose. It would also be available to other R un N otice W S department programs. The following diagram R un N otice W S shows how this might look. O ther license processing A Practical Service Oriented Architecture 39
  • 41. E x a m p le : P ro fe s s io n a l L ic e n s in g A p p lic a tio n S O A D e p lo y m e n t A p p ro a c h (n o t s h o w in g fire w a lls ) A p p lic a tio n S e rv e r In te rn e t lic e n s e .e a r R e p o rtin g S e rv e r T ra n s la te a n d L o g in W S C re d it C a rd P ro c e s s o r L o a d S e rv e r User W S T ra n s la te a n d R e p o rtin g W S Load W S L ic e n s e C h e c k WS N o tic e W S S ta te o f M in n e s o ta N e tw o rk D e p t o f P u b lic D e p a rtm e n t o f OET D a ta b a s e S e rv e r S a fe ty H u m a n S e rv ic e s L ic e n s e d a ta b a s e D ire c to ry DPS Check w s C re d it C a rd w s S e rv e r DPS U se rs D a ta T hese are not needed in this database because they are handled at the D P S and the directory server Another example: Immunization system data transfer across state boundaries is shown below. Component Services Example Immunization Data Exchange Between Neighboring States The Minnesota Immunization Information Connection (MIIC) is Minnesota’s centralized repository for immunization data. Immunization providers throughout the state use this system to see what shots have been given to their patients from any clinic where they have previously received shots. Minnesota residents living in cities close to the borders commonly go across state lines to receive health care. When shots are given in clinics across the border, it is important for this shot record to be updated in the patient’s home state so that clinics that they visit A Practical Service Oriented Architecture 40
  • 42. in the future will have access to the shot record to know what the patient is due for next. Also, public health follow up occurs at the home county level and access to the shot record may show a child who is up-to-date for vaccinations and save the county from needless follow up activities and save the parents from receiving unneeded letters and phone call reminders. A potential use of web services deals with background communication of data between applications. If an immunization is entered into MIIC for a patient who lives in North Dakota, a process would be triggered that would call a web service to package a message into HL7 messaging format perhaps using a mapping product such as “Rhapsody”. The resulting message that contains the patient’s demographic information and shot information is then sent to another web service, such as PHIN- MS, that encrypts the data and sends it off to the North Dakota application. Sending of data from the North Dakota application to MIIC about Minnesota residents would happen in reverse. N orth D akota D epartm ent of H ealth Im m unization S ystem D ata T ransform ation H L 7 T ranslator M essaging S ervice S ervice (P H IN -M S ) (D atabase to H L 7) M essaging S ystem Internet M D H N etw ork Im m unization A pplication (M IIC ) Detailed Architecture The following framework, based on the federal enterprise architecture, is one way to categorize all of the important building blocks associated with information technology. If one asks, where does Microsoft Word or the Java programming language fit in the framework, we should be able to tell you. There is a table for each A Practical Service Oriented Architecture 41
  • 43. service area, and examples of the kinds of standards within the service categories. Each service area table has a description and discussion following it. Service Access and Delivery Service Area Description: The Service Access and Delivery Service Area defines the mechanisms for accessing and delivering department services to its employees, partners, and the public. The standards in this area define how users will connect to department applications and how the department will deliver services to our partners. Service Access and Delivery Service Area Service Category Service Standard Examples of Standards Access Channels Web Browser MS Internet Explorer, FireFox Wireless/PDA Blackberry Collaboration/Communications E-mail, FAX Other Electronic Channels Internet/Intranet/Extranet Internet HTTP, HTTPS Intranet HTTP, HTTPS Virtual Private Network Juniper, Cisco Legislative/Compliance Section 508, Accessibility systems Supporting Network Services SMTP, MIME, IMAP, DNS Authentication/Single Sign-On Identity Management Oracle Access Manager Certificates SAML, PKI Related Issues: • Separation of content from the way that it is presented will facilitate the delivery of information in multiple formats to fit different devices (cell phone, PDA, tablet PC). Current Situation: • Department applications use different user interfaces. • There is little support for alternate devices. • Department applications have their own log-in procedure, usernames and passwords. Future State: • Users can access department systems and complete transactions using a variety of devices based on standard protocols and formats. A Practical Service Oriented Architecture 42
  • 44. • 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
  • 45. Service Platform and Infrastructure Service Area Service Category Service Standard Examples of Standards Networks Wide Area Network Local Area Network Video Conferencing Storage Storage Area Network (SAN) HP EVA Back-up and Recovery CommVault, HP Tape Library Server/Computers Operating Systems Solaris, MS Windows, Linux, Novell Hardware Sun Sparc, Intel based Peripherals Printers, Scanners Delivery Servers Web Server Apache Database Server Oracle Application Server Oracle Application Server, Cold Fusion File Server Novell Print Server Novell Other Servers Oracle Portal Application Languages Java, Cold Fusion, SQL, PERL Development Integrated Development Environment JDeveloper, IntelliJ, Adobe (IDE) Studio MX Software Configuration Management Concurrent Versioning Sys­ (Managing versions, issues, change, tem (CVS), Change Manage­ deployment, and requirements) ment Application, Bugzilla Test Management JUnit, Stress testing, Security testing, Failover testing (Includes functional, usability, perfor­ mance, stress, security, reliability, and configuration testing) Modeling MS Visio Desktop Hardware/ Operating System MS Windows, Linux, Solaris, Software Mac OS X Desktop Computer Hardware Laptop, Workstation, Tablet Desktop Software MS Office Desktop Administration Novell’s Zen Current Situation: • There is considerable standardization on department-level Internet and intranet systems. However, many MDH programs are using diverse operating systems, languages and databases. A Practical Service Oriented Architecture 44
  • 46. • 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
  • 47. switches that allow data, voice, and video to be transferred from place to place. Networks also constrain traffic to appropriate channels. Network performance and security are key parts of a service- oriented architecture. If applications are constructed that rely on services that are available over a network, the network speed and reliability is critical to the performance of the application. • Storage Storage refers to the disks and tape systems that store information that is used by our users and applications. Most of our systems provide redundancy to protect data if a disk crashes. Some systems have data that is stored at both the Golden Rule Building and the Orville L. Freeman Building so that if a data center at one of the buildings failed, the data would be available at the other building. • Server/Computers Server/Computers refers to the computers that we use to run our applications and services. This is a category where real efficiencies are possible. The department should move toward more standardization and manageability. This also makes a remote recovery site more feasible. MDH should be exploring server virtualization technology. This would allow the department to run multiple functions on the same hardware, and obtain much better use of our computing resources. • Delivery Servers Delivery servers are software that provide special services to support applications or user interfaces. They include Web servers, application servers, database servers, file servers and print servers. These servers constitute a considerable investment in license fees and continuing support costs. It would be desirable to A Practical Service Oriented Architecture 46
  • 48. 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
  • 49. 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
  • 50. The component framework will consist of two different types What are Web Services? of components, although there will be some overlap. Some Web services are independent components will be very health program specific. For instance, components that have a some laboratory components may not have any use in other particular web address (URL). The department programs. In the diagram, these are referred to as architecture of web services is the “Line of Business Service Components”. Other components scope of the W3C Web Services Architecture Working Group. It may be usable by any department programs. A common log-in is possible to construct service- component could be used in many applications. In the diagram, oriented architectures without these are referred to as “Common Service Components”. using web services, but their popularity makes it essential that the department becomes fluent in Service components support reusability, flexibility, and their use. They are basically a web interoperability. To obtain a benefit from reusability, two kinds of application that follows certain rules. Those rules are based on analysis need to be performed: 1) an identification of the common several international standards service components that can be used by many applications, and such as: 2) a functional analysis of the department’s programs needs to 1. Extensible Markup Language be performed to identify those functions that could be served by (XML): a particular component (line of business service component). 2. Hyper Text Transport Protocol The Federal Enterprise Architecture’s Service Reference Model (HTTP): can help with the first analysis. That model identifies common crosscutting functions in any governmental organization. The 3. Web Services Description Language (WSDL – often second analysis could be performed as part of the business analysis pronounced “wiz-del”): stage of any new application. 4. Simple Object Application Protocol (SOAP): Common service components from the first analysis will be usable by many department programs. These components need sufficient 5. Universal Discovery, Description and Integration support so that MDH developers are aware of them, can easily use (UDDI): them, and can get expert help, when needed. Here is a partial list of suggested common service components: Web services are computer programs that can be written in 1. Identity management services languages like Java or Cold Fusion. 2. Directory services Because they communicate via 3. Electronic Forms the international standards, an application written in Java could 4. Reporting tool use a web service written in Cold 5. Statistical analysis service Fusion or some other language. 6. Geographical Information Systems (GIS) service Because they use standard web addresses and HTTP, they do not 7. Records management service usually require special firewall rules for access and use. Some examples of line of business components are provided below: 1. Licensing 2. Disease Case Management 3. Lab Result for Disease Case Sometimes, an application should be constructed with components to improve flexibility and interoperability, even if it is not likely A Practical Service Oriented Architecture 49
  • 51. to be reusable. When changes in the business process occur, Composite applications: a component can be replaced without affecting the rest of the application. Most components should be constructed using Service components based on web services standards can be web services standards. This will provide opportunities for combined to produce complete interoperability. composite applications. A programming language called the business process execution Security: language (BPEL – pronounced In a typical application, a user is identified (authentication) and bee-pel) provides the glue to given appropriate access to the parts of the application that they combine several web services have permission to run (authorization). Applications based on into a single application. That composite application could have web services or other service components must have mechanisms an end user interface or it could be for authenticating and authorizing access to the individual another web service. This process components, but the user should not have to log in again. There of combining several services together into an application is are several standards that are available to accomplish this, but they called orchestration. are not currently being used in the department. We will have to deploy these new technologies in order to control access to service components and interoperate with our partners in a secure way. Most of the standards involve using an electronic certificate that is obtained when a user initially logs into an application. This could be a certificate for public key infrastructure (PKI – sometimes referred to as X.509 from the International Telecommunications Union standards) or a certificate based on the security assertion markup language (SAML – pronounced sam-el). These certificates would be issued and controlled by the department, or we could agree to accept certificate from trusted partners. This whole infrastructure is part of digital identity management. Component Services Guidelines: • Where appropriate, applications and services should be built to deliver and consume web services. • Standalone or legacy applications may have web services interfaces which will allow them to interoperate with other systems. • Services and applications are constructed to closely match the department’s processes – ideally, after the processes have been improved. • Application development will be less building from scratch and more orchestrating component services to build composite applications. • Key common services such as identity management, generating reports, and geographical information systems would be deployed and adequately supported department-wide. • Department Web applications would have a common interface A Practical Service Oriented Architecture 50
  • 52. • 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
  • 53. 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 Category Service Standard Examples of Standards Data Description Data Inventory ISO/IEC 11179 Metadata Registries Data Dictionary ISO/IEC 11179 Metadata Registries Data Context Taxonomy XML topic maps, Web On­ tology Languarge (OWL) Data Sharing Content Management Stellant, Vignette Document Management Vignette Database Connectivity JDBC, ODBC Related Issues: • Some department datasets do not have data stewards, nor do they have clear policies about monitoring, auditing, accessing and granting permissions. Current Situation: • The department has a data inventory and a data dictionary application, but there is no current process for keeping the information up to date. • There are numerous codes for the same entity within the department. For instance, a particular clinic might be stored in several systems with a different identifying number. A Practical Service Oriented Architecture 52
  • 54. 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
  • 55. 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
  • 56. 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
  • 57. registry servers (UDDI), security certificate management tools, or an enterprise service bus. • There are new complexities associated with managing applications that use services. The department should establish a testing group and a test bed to work out the details of service oriented architecture. • Management of the department’s processes will lead to the most gain from SOA – important thing is how our organizations are run through technology, not how the application is developed. The department should consider a thorough analysis of its business processes based on its goals and objectives. This would identify areas of redundant data collection, and improvements to our processes that would improve the delivery of public health. Some process analysis efforts are already on- going (Children’s Health Information System Project, Common Ground, Disease Surveillance Modernization Project), and we could build on those to develop a more complete picture. SOA Policies There are several policies and guidelines that should be adopted to successfully implement service oriented architectures. These include: • Security policies: Building applications that are composed of service components leads to certain security issues that must be addressed. How is access to a particular component controlled? Who determines that access? How do we monitor use of components? The department will need to develop policies and processes to maintain the security of our applications. Also, there are many new security standards that are associated with the use of web service components. These include standards like WS-Security, Security Assertion Markup Language (SAML), and WS-Trust. The department has little or no experience with them, and we will need to carefully implement them as the need arises. We have an existing Application Security Policy with an associated standards document. Although this policy is new A Practical Service Oriented Architecture 56
  • 58. 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
  • 59. Timeline for SOA The following time line provides some very approximate dates for possible implementation of certain SOA components. This is a high level view. An architecture implementation project (initiative?) should be established to develop a more detailed plan. 2007 2008 - 2009 S e rvice B a se d 2007 - 2008 T ra in A rch ite ctu re E sta b lish W e b D e ve lo p e rs D o cu m e n t S e rvice s in U sin g S e cu rity P o licy SOA 2008 2009 2010 2011 2008 - 2009 2009 - 2011 2007 2007 D e ve lo p S O A 2008 2008 E va lu a te D e ve lo p E sta b lish P o licie s O th e r S O A P H IN M S Id e n tity D e ve lo p D e ve lo p T o o ls M e ssa g in g M a n a g e m e n t R e p o rt Som e W eb S e rvice S e rvice G e n e ra tio n S e rvice s S e rvice A Practical Service Oriented Architecture 58
  • 60. Part 4: Maintaining the Architecture Maintaining the Architecture To move the department in the direction of the adopted architecture, we must identify the resources and manage the policies to ensure that the department’s information technology choices are consistent with it. In addition, without some process to maintain and renew it, an architecture will become out of date. It will no longer be responsive to the goals of the department, nor will it address the “drivers” that the department must respond to. In order to keep it current, we need to establish some processes to periodically review and update the architecture. In short, we need a governance structure to administer the architecture. Proposed Governance Framework The following diagram illustrates the major entities that are part of the governance of the department’s architecture. Proposed new positions or groups are represented with shaded boxes. M D H A rc h ite c tu re G o v e rn a n c e IT In fo rm atio n S ystem s & T ech n o lo g y M an ag em en t E xecutive S teering C hief Inform ation O fficer C om m ittee (E S C ) 4. 2. T esting C IS O M D H A rchitect G roup 1. A rchitecture P lanning IS T M M anagem ent R eview text S ervices B oard W eb S ervices D evelopers 5. E nterprise U ser S upport A d H oc Inform ation N etw orking S ervices D om ain 3. T echnology T eam s N ovell C oordinating A dvanced S ervices B usiness C om m ittee (IT C C ) S ervices A Practical Service Oriented Architecture 59
  • 61. 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
  • 62. Drivers and requirements for the architecture are in the boxes on the right. The arrows represent flows of data or information. Process models (flow charts or swim lane diagrams) should be developed for each of these processes. M D H A rc h ite c tu re P ro c e s s e s N eeds and R equests A rc h ite c tu ra l R equirem ents F or P urchases D IV IS IO N S D riv e rs P o lic ie s P roposed N ew A pplications S tra te g ic P la n s O ver-all R equests A rchitecture P olicy F or E xceptions – P urchasing and P a rtn e rs E xceptions 4. 3. a n d C itize n A p p ro ve IT P ro ce ss 6. R e vie w N e w D riv e rs P u rch a se s R e q u e st fo r E xce p tio n s A p p lica tio n s S ervice C onsum ption A rchitecture F e d e ra l P olicies (IS & T M A rchitecture Info (IT C C ) (M D H A rchitect) D riv e rs M anagem ent) Info P olicies and A rchitecture P olicy updates Info R euse and A rchitecture R eview S ta te Info A nnually 2. Q uality of S ervice D riv e rs P olicies R e vie w a n d 1. APPROVED u p d a te A R C H IT E C T U R E a rch ite ctu re D e ve lo p a n d A pplication M a in ta in T e c h n o lo g y P olicies and D evelopm ent A rch ite ctu re A rchitecture (A rchitecture R eview D riv e rs P olicy updates G uidelines P o licie s B oard) Info C urrent 7. Infrastructure (A rchitecture R eview B oard) 5. C h o o se A p p lic a tio n a n d S O A S ecurity T e st N e w T e ch n ica l In fra s tru c tu re P olicies T e ch n o lo g y S ta n d a rd s In v e n to ry (A d H oc D om ain (T esting G roup ) T eam ) 1. Develop and Maintain Architecture Policies: The architecture review board would be responsible for developing and updating policies and procedures related to architecture. Some of the policies already exist, and could use updating. Others are be new, and they will require development and implementation. 2. Review and Update Architecture: The architecture review board will annually review the architecture to determine how well it is aligned with department needs and goals. Some years this will be a cursory evaluation. Every three to five years, the architecture should have a full review. 3. Exception Process: The department has always maintained that we would allow exceptions to technical standards and architectural decisions for legitimate business needs. Requests for exceptions will be handled by the ITCC. Some requests may have to go to ESC for approval, and some requests may require A Practical Service Oriented Architecture 61
  • 63. 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
  • 64. Appendices Appendix A: MDH Architectural Team Members Appendix B: MDH Architectural Drivers and Requirements Appendix C: Current Infrastructure Appendix D: Response to Comments on Draft Version Appendix A: MDH Architectural Team Members Richard Fong Communications John Nieland Infectious Disease Epidemiology Prevention & Control Karen White Infectious Disease Epidemiology Prevention & Control Christina Tamondong Public Health Labs Jason Tillman Policy, Quality and Compliance Bureau Don Brabeck Community & Family Health Promotion Bureau Shelly Siems Environmental Health Division Steven Ring Information Systems & Technology Management Michelle Aguilar Communications (document formatting and production) A Practical Service Oriented Architecture 63
  • 65. Appendix B: MDH Architectural Drivers and Requirements P ro ject o r R eq u irem ent D etails Im plicatio n s In itiative C D C P u b lic H e alth M e ssa g in g C o n structio n , a u tom a tic ro u ting , M D H n e e d s an e ffe ctive m e a ns to In fo rm a tio n e n cryp tio n , d igita l sig n a tu re s, su p po rt su p po rt this ca pa b ility N e tw o rk (P H IN ) e b X M L p ro to cols, S S L co m pa tib le , co m p lia n t w ith P H IN M e ssa ging S e rvice D ire cto ry S e rvice s C o n ta ct in fo a nd role s, a ccess co n tro l M D H w ill n e e d to e xp a n d its use o f d ire cto ry se rvice s O b je ct Id e ntifie r S u pp o rt O ID s -- g lob a lly u n iq u e id e ntifie rs to A system to tra ck O ID s w ill b e id e n tify o rg an iza tio n s, cod e sets, e tc. n e e d ed A u d it tra il M u st su p p o rt a u dit tra il o f da ta re co rd s M D H m u st e xp a n d its use o f au d it a n d acce ss a tte m pts to system s tra ils. T h a t m a y m ea n m o re /b ig g e r se rve rs a n d m o re sto ra g e space to a cco m m o d ate th e in crea sed loa d o f h a n d lin g a u dit tra ils. V o ca bu la ry S tan d a rds S u p p o rt system to m ain ta in a nd u p da te M D H n e e d s po licie s an d system s to F co d in g co o rdin a te w ith C D C co de s a nd m a n ag e co d e cha n ge s th ro ugh E d iffe re n t ve rsio ns. D a ta M o d e lin g S u p p o rt P H IN L o gical d ata m od e l In o rd er to sh a re info rm a tion , M D H D m a p pin g m u st d e ve lo p da ta ba ses th a t ca n b e m a p pe d to C D C d a ta e lem en ts. O p e ra tion a l b e st C le a r p ro cesse s a n d d o cu m enta tion , M D H n e e d s to co m ple te o u r C O O E p ra ctices C o n tin uity o f O p e ra tio n s (C O O ) P la n n in g w h ich includ e d o cum e nta tio n of its p rocesses R A u th e n tica tion su p po rt tw o fa cto rs, X .5 0 9 W e m ust b e ab le to use tw o p a ssw o rd s o r a p assw o rd a nd A a n o the r ide n tifyin g m e ch a nism to co n tro l lo g gin g in to system s an d L d a ta ba ses A u th o riza tio n ro le ba sed a uth o riza tio n A p p lica tio ns n ee d to b e co nstru cted th a t g ra n t p e rm ission s to role s. P e o p le a re th e n g ive n p e rm issio n s b y b e in g a ss ig n e d to a ro le . D a ta Tra n sla tion H L 7 fo rm a t su pp o rt M D H m u st ha ve a syste m th a t ca n tra n sla te d a ta in to H L 7 fo rm a t a n d re a d H L 7 file s O ffice o f th e N atio n al C o o rd in ato r fo r H ealth In fo rm atio n T ech n o lo g y (O N C H IT ) N a tio n al H e alth L a b da ta fo rm at p asse d , p re scrip tion s, Im p o rta n t lo ng -te rm im p act on In fo rm a tio n m e d ical reco rds co m in g sta nd a rds a nd m e ssa g in g . N e tw o rk (N H IN ) H H S H e a lth A u d it tra il M o st o f M D H is n o t re q uire d to m e e t In su ra n ce H IP P A g u ide lin e s, b u t it m igh t b e P o rta b ility a nd sm a rt fo r u s to m o ve in th a t d ire ctio n A ccou n tab ility so tha t w e ca n fu lly p a rticipa te in E - A ct (H IP A A ) h e a lth U SD A D e p a rtm e n t o f U S D A 's a rch ite ctu ra l p lan s a re n o t A g ricultu re – cle a r, b u t th e y co u ld h a ve a n im p act W IC p ro g ra m o n o ne o f o u r im po rta n t p ro gram s EP A E n viro n m en tal Th e E P A se em s to b e focu se d o n P ro te ctio n d a ta sta nd a rds. T h is m a y h a ve a n A g e n cy – im p act o n E H syste m s. E n viro n m en tal H e a lth D ivision FE M A M o b ile M o rg u e N e e d to com p ly w ith F ed e ra l R e q u irem e nts C M S ASPEN N e e d to c om p ly w ith F ed e ra l R e q u irem e nts A Practical Service Oriented Architecture 64
  • 66. P ro ject o r R eq u irem ent D etails Im plicatio n s In itiative O ET O E T E n te rp rise S e rvice O rien te d P ro m o te w e b se rvice s A lth o ug h th is p ro je ct is p ro g ressin g A rch ite ctu re A rch ite ctu re ve ry slo w ly, it co uld ha ve a m ajo r P ro je ct im p act o n M D H syste m s a n d in frastructu re . M in n e so ta ’s T e ch n ica l S ta n d a rd s W orkin g on ve rsio n 3 w ith b u sin e ss, IT d e ve lo p m e n t an d system s w ith in E n te rp rise -w id e a p p lica tio n, in fra stru ctu re , d a ta a n d le g islative initia tive s m ust co m p ly T e ch n ica l se cu rity d om a in s w ith th e EW T A in o rd e r to o b ta in S A rch ite ctu re fu n d in g . M o st o f th e m ajo r M D H (EW TA ) syste m s alre ad y com p ly. T D H S D H S ’s M e d ica id P H n e e ds to in te ro p e ra te D H S is w o rkin g o n m a jo r ch a ng e s to the ir M D H sh o u ld b e de sig nin g syste m s A In fo rm a tio n w ith m a in syste m s b ase d o n th e M ITA th a t ca n in te ro p e ra te w ith D H S 's T e ch n o log y a rch ite ctu re . T h e y w o u ld like to h a ve a rch ite ctu re in so fa r a s w e can T A rch ite ctu re m u ch im p ro ve d in teg ra tio n w ith th e p u blic d e te rm in e it. (M ITA ) p ro je ct h e a lth syste m . E C o o rd ina tion o f N e e d to coo rd ina te th e a ssig nm e n t N P I # 's a n d us e o f N P I's (N a tio na l P rovid e r In d e x) C ounty/C ity D a ta E xch a n g e C a p a b ility to secu rely a n d e ffective ly A so lu tion w o u ld g re a tly in crease the e xch a n g e vita l re co rds/b irth & d e a th d a ta se cu rity a nd d ecre ase th e a m o u n t of b e tw e e n M D H a n d citie s/co un tie s. w o rk re q u ired to o b tain th e da ta w e re a re re q uire d to co lle ct M H A (H ospitals) D a ta E xch a n g e C a p a b ility to secu rely a n d e ffective ly A so lu tion w o u ld g re a tly in crease the e xch a n g e d ata be tw e e n M D H a n d M H A se cu rity a nd d ecre ase th e a m o u n t of a n d the H osp ita ls w o rk re q u ired to o b tain th e da ta w e re a re re q uire d to co lle ct C om m erce E le ctro n ic A b ility fo r M D H to e a sily acce pt p a ym e nts W ould e ase th e co lle ctio n o f fee s fo P a ym e n ts e le ctro n ically m a n y se ctio ns in M D H S e rvice O rien te d C a p a b ility o f d e ve lop ing a pp lica tio ns w ith S o m e p u rch a se d ap p licatio ns w ill b e A rch ite ctu re (S O A ) re u sab le m od u les. m o vin g to w a rd S O A so M D H m a y n e e d to su p po rt the u nd e rlying in frastructu re . C o uld he lp M D H T b u ild a pp lica tio ns m o re e fficien tly. E V irtu a liza tion C o u ld red uce the n um be r o f ph ysical C se rve rs a n d e a se d isaste r re co ve ry. H O p e n S o u rce P o te n tia l to re du ce e xp e n sive N licen se fe es o r p ro p rie ta ry h a rd w a re . O M o re m o b ile w o rk S e cu re con n ection to M D H , w ire le ss E n h a nce d V P N a n d w ire less L ca p ab ility co n ne ctio ns w ill n ee d to b e O su p po rte d. A lso ne e d to p la n fo r field sta ff w h o m a y n e ed to co nn e ct G th ro u gh a p a rtne r's n etw o rk. Y G e o g ra p hica l Info rm a tio n M o re M D H d a ta sh o u ld be a nalyze d a n d N e e d a w a y to e asily cre a te an d S yste m s (G IS ) d ispla ye d o n m a ps. w o rk w ith m a p s o n ou r w e b site P o rta l N e e d to im p ro ve inte g ra tion an d U sin g p o rtal so ftw a re a n d m ana g in g m a n ag e m e n t o f M D H a p p lica tio n s a n d o u r w e b site as a po rtal w o u ld le a d in fo rm a tio n po stin gs. to m o re e ffe ctive m a n a ge m en t o f its co n te n t an d a p p lication s. It cou ld le a d to sin gle -sig n -o n fo r use rs o f M D H a p p lica tion s. V id e o M o re n e e d fo r th e use o f vid eo is P ro vid in g n e tw o rking b an d w id th a n d e xp e cte d . q u a lity o f se rvice is crucial. E n h a nce d w e b use r In crea sed e xp e cta tio n th a t W eb S u p p o rt o f ad d itio na l p ro g ram m in g in te rfa ce a p p lica tio ns w ill in co rp o rate m o re im a g es e n viro nm e n ts (F la sh , A JA X ) w ill a n d p ro vid e be tte r p e rfo rm an ce in clu d e secu rity issu es. A Practical Service Oriented Architecture 65
  • 67. P ro ject o r R eq u irem ent D etails Im plicatio n s T In itiative E In te rn ation a liza tio n A b ility to crea te a p plica tion s tha t can C C a p a b ility e a sily w o rk w ith o th e r la n gu a ge s H XML N e e d to e fficie n tly cre a te, p roce ss, a n d N tra n sla te X M L d a ta O D a ta M a rts/R e p o rtin g U n lo ck M D H d a ta to m a ke it ava ila b le fo r N e e d a re p o rt g e ne ra tin g to o l. M a y a n a lysis an d re p o rtin g n e e d a d d ition a l d a ta w a re h o u se L so ftw a re . O S e cu re F ile T ra n sfe r N e e d to secu rely a n d e ffectively se n d a n d A so lu tion w o u ld ea se th e b u rd e n o f G re ce ive la rge file s e lectron ica lly b e tw e e n e m a il a tta ch m en ts a n d w o u ld e n su re Y M D H a n d o u tsid e p a rtn e rs. g re a te r secu rity a n d re lia b ility o f file tra n sfe rs E le ctro n ic S ign a tu re s N e e d to b e ab le to acce p t signa tu res N e e d to w o rk o u t th e le g al e le ctro n ically o n e lectro nic fo rm s. ra m ification s of a d ig ita l sig n a tu re vs a re a l sig n a tu re . R F ID S e cu rity B io m etrics In crea ses se cu rity o p tio ns. LPH A L In te g rate d C h ild D a ta S h a rin g P o rta l fo r inte g ra te d in fo rm a tion fro m M a ste r p a tien t in d e x n e e d e d fo r P H e a lth R eco rd A g re e m e n ts a nd sin gle m u ltip le sou rce s a va ilab le in on e -sto p p a tien t da ta resid in g in va rio us a u th o rita tive id en tifie r sh o p lo catio ns th ro u gh o u t M D H H A ccess to re p o rtin g to o l a va ilab le L a rg e co un ties ne e d to an a lyze th eir o w n & D ise ase fro m ou tsid e fire w a ll to d a ta re p o rtin g d a ta w a re h o use H in fo rm a tio n O A PIC S S tre a m lin ed P d isea se re p o rtin g syste m from e xte rn a l p a rtn e rs M D H S tra te g ic In crea sed inte g ratio n, S e e "S um m a ry o f IT Im plica tion s o f A n a rch itectu re th at su p p o rts a n d IT P la ns co lla b o ra tion , e fficie ncy D e p a rtm e n t P la ns" fo r m o re info rm a tio n. e fficie nt u se o f IT re so u rces an d a n d rep o rtin g ca p ab ility in crea sed ca p ab ility fo r in te g ratio n w ith in a n d w ith ou t M D H . N e e d fo r b e tte r a n alysis a n d re p o rting M ca p ab ility. M N -P H IN C o lla bo ra te w ith e -H e a lth N e e d a fle xib le a rch ite ctu re tha t can D a n d lo cal p ub lic he a lth co n ne ct to se ve ra l d iffe re n t kind s o f syste m s an d tra n sla te d iffe re nt kind s o f d a ta H C h ild ren ’s In te g ration a nd d a ta N e e d a d a ta a rch itectu re th at ca n H e a lth sh a rin g su p po rt da ta sh a rin g a n d p rivacy. In fo rm a tio n S yste m p ro ject L o w e r S ta te b ud g e ts L o w e r F e d e ral g ran t a m o un ts C o n tin uity o f R e lia bility a n d a vailab ility M D H p ro je ct is m o ving fo rw a rd N e e d to sup p o rt re d un d a ncy O p e ra tion s P la n n in g (C O O P ) M C SS C a n ce r M o d e rn syste m A rch ite ctu re m u st b e a b le to su p p o rt S u rve illan ce th e n ee ds o f a n e w ca nce r S yste m su rve illa nce system M C H S V ita l R eco rds W eb ba sed syste m M u st b e a b le to su pp o rt b a n d w id th S yste m a n d da ta ne e ds o f a ne w vita l re co rds system A Practical Service Oriented Architecture 66
  • 68. P ro ject o r R eq u irem ent D etails Im plicatio n s In itiative W IC W IC S yste m M o re w e b b a se d M ID E P & C D ise ase In te g rate d P H IN N e e d to sup p o rt P H IN re q uirem e n ts D S u rve illan ce co m p lia n t system C o m m O ffice H C o n te n t C o n te n t M a n a g em e nt C o u ld be rela ted to a p o rta l syste m . Managem ent S yste m Th is w o u ld h a ve a m ajo r im pact o n o u r w e b in frastructu re PHL E n te rp rise W eb ba sed syste m th a t N e e d to sup p o rt P H IN re q uirem e n ts L a b o rato ry is P H IN co m p lian t, a n d a n d a rch ite ctu re m ust su p po rt a d h oc In fo rm a tio n a d h oc re po rting re p o rtin g ne e ds S yste m (E LIS ) ca p ab ilities F e d e ral O M B F e d e ral H ig h le ve l g uid in g a rch ite ctu re fo r C D C F e d e ral g ran tin g ag e ncies w ill b e E n te rp rise a n d o th e r fe d e ra l ag e ncies. E m p h asis o n m o vin g to w a rd com p lia nce . It m a y A rch ite ctu re a n a lysis of b usine ss p ro cesses a nd m e a n m o re focus o n com m o n L (F E A ) co m m o n se rvice s. se rvices an d p ro cesse s. CDC O C D C ’s vie w o f C o n ce ptu al w h o le It w ill b e d ifficult an d e xp e n sive if sta te h e alth e ve ry p ro g ra m in vo lve d in P H IN N a g e ncies d e ve lo ps the ir o w n a pp ro ach to m e e tin g th e re q u ire m e n ts. S tate G E -H e a lth Im p o rta n t lo ng -te rm im p act on sta nd a rds a nd m e ssa g in g . H as th e p o te n tia l to ch an g e o u r rela tion sh ip T w ith so m e o f ou r d ata p ro vid e rs S tate – D O E R E D e a l w ith "g ra yin g P o ssib le sm a lle r IT sta te w o rkfo rce w o rkfo rce " in the fu tu re . S yste m a dm in istra tio n R n e e ds to b e m o re e fficien t. C itizen s M E -G o ve rn m e n t M e e t p a rtn e r a nd citize n E xp e cta tio n th a t m ost fo rm s an d d a ta N e e d re lia ble an d acce ssible e xp e cta tio ns tra n sfe rs ca n b e p e rfo rm e d e lectro nically in frastructu re . a t a n y tim e o f d a y o r ye a r. E le ctro n ic F o rm A b ility to sub m it fo rm s e lectronica lly N e e d to b e ab le to ea sily g e nera te S u b m issio ns a n d co lle ct fo rm d a ta w ith o u t th e n e e d to rely o n de ve lo p ers to in d ividu a lly d e ve lop e ach fo rm . D a ta Tra n sfe r A b ility to e asily tra n sfe r da ta ele ctron ica lly F u lfill da ta re q u ests e le ctro n ica lly a n d au tom a tica lly O n D e m a nd R e p o rts A b ility fo r citize ns to q u e ry fo r in fo rm a tion o n th eir o w n M o re R e p o rts a n d o the r N e e d re po rt ge n e ra to r se rvice th a t in fo rm a tio n on in fo rm a tio n a vaila ble ca n e a sily crea te w e b p ag es th e w e b e le ctro n ically T a xe s/b u d g e t B e m o re e fficie n t "D o m o re w ith less" N e e d to sim p lify in fra stru ctu re . p re ssu re N e e d to b eco m e ve ry e fficien t a t m a n ag ing co m m o d ities so tha t sca rce re sou rces ca n b e de vo te d to p ro g ram n ee ds. N e ed to in ve st in a d m in istra tive to ols th a t p ro vide lo n g -te rm re tu rn o n in ve stm e nt. A Practical Service Oriented Architecture 67
  • 69. Appendix C: Current Infrastructure The project team compiled an inventory of desktop hardware and software, servers, and MDH applications. There was no intent to make this inventory thoroughly complete. We wanted to get a general picture of the numbers of computers, where they were located and what was running on them. Accurate numbers were not important. Obtaining this information was extremely difficult. Every support area keeps the information in a different way. The names differ, software vendors are bought out, versions are tracked differently, and some divisions have no way of easily obtaining these numbers. The following table provides a key to the organization (ORG) acronyms. ORG Org Description EO Executive Office, Communications Office, Legal Unit, Library, Minority and Multicultural Health MMH Minority and Multicultural Health CM Compliance Monitoring HP Health Policy EH Environmental Health IDEPC Infectious Disease Epidemiology Prevention and Control PHL Public Health Laboratory OEP Office of Emergency Preparedness CFH Community and Family Health HPCD Health Promotion and Chronic Disease PQC Policy Quality and Compliance Bureau Operations CFHP Community and Family Health Promotion Bureau ISTM Information Systems and Technology Management FFM Finance and Facilities Management HRM Human Resource Management A Practical Service Oriented Architecture 68
  • 70. Desktop Hardware ORG Number of Desktops Number of Laptops EO 25 17 ISTM 15 24 OEP 1 32 FFM 87 17 HRM 41 4 PHL 239 33 CFHP 229 107 EH 203 193 PQC 200 140 IDEPC 188 70 Total 1228 637 Desktop Software (Ordered by department totals, descending) Software Name Internet Explorer (IE) Network Associates Virus Scan (McAfee) GroupWise Microsoft Excel Microsoft Word Microsoft PowerPoint Adobe Acrobat Reader Realplayer FireFox Novell Client Microsoft Office Pro (Word, Excel, Powerpoint, Access, et.al.) Microsoft Access Adobe Reader ScreenPass Belarc Client Netscape Browser iPrint A Practical Service Oriented Architecture 69
  • 71. 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
  • 72. 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
  • 73. 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
  • 74. 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
  • 75. 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
  • 76. 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
  • 77. Number of Servers at MDH by Organization, OS and Server Purpose (OS = Operating System) O rg an izatio n (D iv isio n o r B u reau ) G ran d S erv e r p u rp o se OS CFHP EH FFM ID E P C IS T M PHL PQC T o tal A P P LIC A T IO N U N IX 9 5 1 3 18 W IN 2 3 2 7 C O M M V A U LT W IN 1 5 1 7 DATABASE N O V E LL 1 1 U N IX 1 3 3 6 8 21 W IN 1 1 DHCP (blank ) 7 7 D IR E C T O R Y N O V E LL 2 2 DNS W IN 1 1 (blank ) 2 2 E N V IR M O N IT O R (blank ) 4 4 E Q U IP M O N IT O R (blank ) 2 2 FAX W IN 2 2 F ILE /P R IN T N O V E LL 16 16 W IN 1 2 3 F IR EW A LL (blank ) 4 4 FTP U N IX 1 1 G IS NT 1 1 W IN 3 3 G R O U PW IS E N O V E LL 2 2 N E T M O N IT O R (blank ) 1 1 OTHER LIN U X 1 1 U N IX 1 1 W IN 2 1 3 6 (blank ) 2 2 P H IN M S W IN 2 2 SANMANAG E W IN 2 2 SAS U N IX 1 1 2 TEST LIN U X 1 1 V IS IO N S H A R E LIN U X 2 1 3 VPN (blank ) 3 3 W EB LIN U X 1 1 U N IX 3 5 8 W IN 1 1 1 3 W EBTRENDS U N IX 1 1 ZENW O RKS N O V E LL 2 2 C IT R IX W IN 3 3 IM A G IN G W IN 1 1 S A N A p plia nce W IN 2 2 SPSS U N IX 1 1 W IN 1 1 V in gette S erver W IN 5 5 V oice A pp S erver W IN 1 1 G rand T otal 5 7 2 26 76 12 30 158 A Practical Service Oriented Architecture 76
  • 78. MDH Applications ORG A p p licatio n N a m e A p p L an g u ag e D atab as e CFH M C S H N S ervices D irectory C old F usio n O racle HPCD T rack ing and F o llo w U p VB SQL EH A ccredita tio n, C om pliance, and E nforcem ent S ystem P o w erB u ilder O racle EH M in nesota D rink ing W ater Inform ation S ystem P o w erB u ilder O racle EH C ounty W ell Ind ex 5 P o w erB u ilder O racle EH B lo od Lea d Inform ation S ystem P o w erB u ilder O racle EH W ell Inform ation S ystem P o w erB u ilder O racle P ub lic W ater S upp ly (P W S ) D rink ing W ater R evolving EH F und (D W R F ) F oxP ro D O S F oxP ro EH D W R F Library F oxP ro D O S F oxP ro EH W ater O perators C ertifica tion F oxP ro D O S F oxP ro EH N e w sletter L ists F oxP ro D O S F oxP ro EH P la n R e vie w Log (D W P /E H S S ) F oxP ro D O S F oxP ro EH E n viro nm ental H e alth S ervices S ystem (E H S S ) F oxP ro D O S F oxP ro EH E H S R ap id Inspection V isua l F ox F oxP ro EH E H S F orce T rack er V isua l F ox F oxP ro EH D rink ing W ater - W ater C hem istry A ccess A ccess EH D rink ing W ater - A quifer T esting A ccess A ccess EH C ounty A ccessible A ccess A ccess EH C ounty W ell Ind ex 4 A ccess A ccess EH LA R S U tility – Lab Inform ation A ccess A ccess EH H ealth R isk Lim its (H R L ) A ccess A ccess EH A sbestos S urve y A ccess A ccess EH N itrate S tud y A ccess A ccess EH Indo or A ir Q ua lity D atab ase A ccess A ccess EH N E X IR S tud y A ccess A ccess EH IW M Z P C S I W eb A pplication O racle EH S ource W ater A ssessm ent W eb A pplication O racle EH C ounty W ell Ind ex O nline W eb A pplication O racle EH W ater W ell M aps W eb A pplication O racle EH R O V E R – A sbestos a nd Le ad T raining C ourses C old F usio n O racle EH C ertified F ood M a nag ers C old F usio n O racle EH R egistered S an itarians C old F usio n O racle EH G round w a ter H R Ls C old F usio n O racle EH W ell D isclosures C old F usio n O racle EO MDH Calendar C old F usio n O racle EO WeeklyBreifing Submission Form C old F usio n O racle Communications Strategy and Project EO Planning C old F usio n O racle EO Employee Recog. Form C old F usio n O racle EO Carpool Request Form C old F usio n O racle EO State Fair Sign-up Form C old F usio n O racle EO T rack C ontested C ases C old F usio n O racle EO M ed ia C ontact C old F usio n O racle EO F it C ity C old F usio n O racle EO F it S ch oo l C old F usio n O racle Interne t E m ail form (W ebm aster, C om m isioner, EO G eneral info) C old F usio n O racle EO R .N . B arr Literature requ est form C old F usio n O racle A Practical Service Oriented Architecture 77
  • 79. ORG A p p licatio n N a m e A p p L an g u ag e D atab as e EO H elp line sche du ler C old F usio n O racle EO M D H L ocations (uses G oo gle M aps A P I) C old F usio n O racle P urchasing, R e ceiving, In ventory, S hipp ing FFM M ana gem ent Java O racle FFM C ell P hon e T rack ing C old F usio n O racle FFM R egu lar P ho ne T rack ing C old F usio n O racle FFM P R IS M R eporting C old F usio n O racle FFM C entra l S tores O rdering C old F usio n O racle FFM F edera l R e porting C a te gories C old F usio n O racle FFM O ut of S tate T ravel C old F usio n O racle FFM F edera l G rants C old F usio n O racle FFM D esk top Inve ntory C old F usio n O racle FFM O R G B ud gets C old F usio n O racle HPCD e-C hron icle Java O racle HRM M D H B ad ges C old F usio n O racle HRM P erform ance M an agem ent for S upervisors C old F usio n O racle HRM H R M V acanc y T rack ing C old F usio n O racle HRM H R M T raining C old F usio n O racle HRM H R M S en iority R osters C old F usio n O racle HRM P erson M a inte nance C old F usio n O racle HRM N otify C old F usio n O racle HRM S tud ent W ork er C old F usio n O racle HRM E m ail A dm in C old F usio n O racle HRM A nn ounce R S S F e eds C old F usio n O racle HRM H R M H e lp desk C old F usio n O racle HRM S E M A 4 ID T rack ing C old F usio n O racle HRM H R M S urve y C old F usio n O racle ID E P C Lab A utom ated R ep ortin g S ystem Java, P E R L O racle ID E P C Isolation an d Q uara ntine A C C E S S , Ja va A C E S S /O racle ID E P C B lu e/Y ello w C ard Java, P E R L O racle ID E P C E lectro nic D eath C ertificate Java O racle ID E P C A nn ua l Im m unization S cho ol R eport Java O racle ID E P C P ertussis d isease surve illa nce Java O racle ID E P C R efugee hea lth inform ation Java O racle ID E P C F lu S urveillance Java O racle ID E P C Im m unizatio n P ractices Im provem ent Java O racle ID E P C F lu C lin ic S ch edu ling Java O racle ID E P C H epatitis V isua l F ox P ro V isua l F ox P ro ID E P C V accine P re ve nta ble D ise a ses (V P D ) T rack ing V isua l F ox P ro V isua l F ox P ro ID E P C A nn ua l C h ild C are R ep ort V isua l F ox P ro V isua l F ox P ro ID E P C P erinata l H epatitis B V isua l F ox P ro V isua l F ox P ro ID E P C M ail L ist V isua l F ox P ro V isua l F ox P ro ID E P C M in nesota Im m unization Inform ation C on nection Java O racle ID E P C N e w born P ack ets V isua l F ox P ro V isua l F ox P ro ID E P C T B M eds V isua l F ox P ro V isua l F ox P ro ID E P C T B C ontact Investig ation a nd track ing F oxP ro F oxP ro ID E P C T B C ase S urve illance F oxP ro F oxP ro ID E P C T B S uspect A rchive F oxP ro F oxP ro ID E P C T B S uspect F oxP ro F oxP ro ID E P C T B G enotyp ing M S A ccess M S A ccess ID E P C T B Lab R esu lts M S A ccess M S A ccess A Practical Service Oriented Architecture 78
  • 80. ORG A p p licatio n N a m e A p p L an g u ag e D atab as e ID E P C S T D Inform ation N e t S yb ase D W B , C + S yb ase ID E P C M N Infertility P re ventio n P rogram M S A ccess M S A ccess ID E P C C ounse ling T esting an d R e ferral M S A ccess M S A ccess ID E P C H IV C lient Le ve l R e port S ystem M S A ccess M S A ccess ID E P C H IV /A ID S R e porting S yste m ID E P C S T D M ana gem ent Inform ation S ystem ID E P C S ection M ailing List D ata ba se M S A ccess M S A ccess ID E P C H ealth T hreat Investig ation D atab ase M S A ccess M S A ccess ID E P C Infected L icensed H ea lth C are W ork er M S A ccess M S A ccess ID E P C E lectro nic D ata M an agem ent S ystem (E D M S ) IS T M H elp D esk C old F usio n O racle IS T M A pp licatio n M ain ten ance C old F u sio n O racle IS T M E xterna l P arty C old F usio n O racle IS T M P olicies and S tatutes C old F usio n O racle IS T M D ata Inventory C old F usio n O racle IS T M M D H F acilities C old F usio n O racle IS T M A pp licatio n R e gistry C old F usio n O racle OEP O E P S urve y Java O racle OEP S ecure Java O racle OEP xbservice Java O racle OEP sam Java O racle PHL Laboratory Inform ation M a nagem ent S ystem O racle F orm s & R eports O racle PHL E nterprise L abora tory Inform ation S ystem Java O racle PHL P roject S tatus a pp lication M S A ccess A ccess PHL B ottle R equ ests Java O racle PHL Lab C ertification Java O racle PHL Lab R esults Java O racle PQC IQ Java O racle PQC M C S C ontracts O racle F orm s 6i O racle PQC M C S C om plain t F ilin gs O racle F orm s 6i O racle PQC M C S Infolo g O racle F orm s 6i O racle PQC MCS CAP O racle F orm s 6i O racle PQC M C S E xtern al R evie w O racle F orm s 6i O racle PQC Im proved C ustom er S ervice D e livery Java O racle PQC P A R A D IS E O racle F orm s 6i O racle PQC C aseM ix T ransition O racle F orm s 6i O racle PQC R ecords M a nag em ent O racle F orm s 6i O racle PQC N A R e gistry S em iA nnu al Java O racle PQC C asem ix C m rF acO pt Java O racle PQC M ortS ci Lice nsin g O racle F orm s 6i O racle PQC HOP O racle F orm s 9i O racle PQC D ata S ecurity Q uiz Java O racle PQC A bortion C onse nt P o w er B u ilder O racle PQC V R V 200 0 Java O racle PQC V R V 200 0 C lie nt/S erver P o w er B u ilder O racle PQC M in nesota F ath er's A d optio n R eg istry Java O racle PQC C learing H ouse C ata lo g O racle F orm s 6i O racle PQC H E D IS P rintform s M S E xcel O racle PQC H C C IS P rintform s M S E xcel O racle A Practical Service Oriented Architecture 79
  • 81. ORG A p p licatio n N a m e A p p L an g u ag e D atab as e H C C IS M a intena nce (D a ta Load / A ud its / PQC P relim 2P rod) O racle F orm s 6i O racle PQC H C C IS M etada ta O racle F orm s 6i O racle PQC H C C IS C losed H ospital M e dical R ecords L ocator Java O racle PQC C D I P rintform s M S E xcel O racle PQC C D I A udits (D ata Loa d / A u dits / P relim 2P rod) O racle F orm s 6i O racle PQC C D I M e tad ata O racle F orm s 6i O racle PQC H E P M E R C (M edica l E duc atio n R ese arch C ost) m od_plsql, H T M L O racle Definitions Cold Fusion An application development environment based on special tags that are similar to HTML tags. When the web server reads a Cold Fusion tag, processing is passed to the Cold Fusion application server. The Cold Fusion server completes its processing and sends the results back to the web server as HTML that can be transmitted to a web browser. Cold Fusion is owned by Adobe (they purchased Macromedia). Composite The term composite application expresses a perspective of software engineering Applications that defines an application built by combining multiple services. A composite application consists of functionality drawn from several different sources within a service oriented architecture (SOA). The components may be individual web services, selected functions from within other applications, or entire systems whose outputs have been packaged as web services (often legacy systems). Content Web Content management systems are used for storing, controlling, versioning, Management and publishing information on the Web. It usually operates by storing content System in a database and formatting it for the web as it is extracted from the database. Data Context Data Context is a service category in the Data Service Area in our architectural model. It is information that provides added meaning to data. Data context usually places data in a taxonomy within a particular discipline. There are tools that help capture and manage, and share data context information. Data Description Data description is a service category in the Data Service Area in our architectural model. It consists of the detailed information (metadata) that describes the format, domain, and meaning of data elements. Data Mart A data mart is a special database of data gathered from operational data and other sources that is designed to facilitate analysis, decision making and reporting for a particular program or area of interest. Data Sharing Data Sharing is a service category in the Data Service Area in our architectural model. It relies on data context and data description to provide standards for access and exchange. These could include specific access protocols and XML languages. DNS Domain Name System A Practical Service Oriented Architecture 80
  • 82. ESC Executive Steering Committee for Information Technology: It is chaired by the Chief Financial Officer and contains three selected managers and the CIO. FEA Federal Enterprise Architecture GIS Geographical Information System HL7 HL7 refers to data interchange standards that have been developed by an organization called Health Level Seven, Inc. They have been designated by the American National Standards Institute (ANSI) as the organization to develop health care related standards. Identity Identity Management pertains to the creation, modification and removal of Management digital identities. It covers the assignment of usernames, passwords and the authorization to access certain resources. There are several systems that are available from commercial vendors to manage digital identities. IMAP Internet Message Access Protocol Interoperability The ability of two or more systems or components to exchange information and to use the information that has been exchanged [IEEE 90]. ITCC Information Technology Coordinating Committee: An IT steering committee at the Minnesota Department of Health. It includes representatives from five division/bureaus and the CIO. MIME Multipurpose Internet Mail Extensions NPI National Provider Identifier OET Office of Enterprise Technology (State Office) OMB Federal Office of Management and Budget Open Source Open source is a form of licensing software that involves free redistribution of the software, access to the source code, and several other criteria. It usually refers to software that is developed and maintained by a group of users over the Internet. PERL Perl is a dynamic programming language that borrows features from a variety of other languages and has been widely adopted for its strengths in string processing, and lack of the arbitrary limitations of many scripting languages. PHIN CDC’s Public Health Information Network PHP PHP is a widely-used general-purpose scripting language that is especially suited for Web development and can be embedded into HTML. PKI Public Key Infrastructure Portal A web portal refers to a site which serves as a gateway to information, services and applications. It also refers to the software that supports easily managing such a web site. A Practical Service Oriented Architecture 81
  • 83. Python Python is a high-level programming language first released by Guido van Rossum in 1991. Python is designed around a philosophy which emphasizes the importance of programmer effort over computer effort, and it rejects more arcane language features, prioritizing readability over speed or expressiveness. Python is often characterized as minimalist, although this only applies to the core language’s syntax and semantics; the standard library provides the language with a large number of additional libraries and extensions. SAML Security Assertion Markup Language, an XML-based framework for ensuring that transmitted communications are secure. SAML defines mechanisms to exchange authentication, authorization and nonrepudiation information, allowing single signon capabilities for Web services. It is an OASIS (Organization for the Advancement of Structured Information Standards) standard. From WebopediaSecurity Assertion Markup Language, an XML- based framework for ensuring that transmitted communications are secure. SAML defines mechanisms to exchange authentication, authorization and nonrepudiation information, allowing single signon capabilities for Web services. It is an OASIS (Organization for the Advancement of Structured Information Standards) standard. From Webopedia SAN Storage Area Network Service Oriented An approach to designing applications based on independent modules (services) Architecture which closely mirror business processes. It is usually associated with building an application as a collection of web services. Single Sign On A system of software components which allow a user to log-in once and be able to start-up additional applications (provided they have the authority to do so) without further log-ins. SMTP Simple Mail Transport Protocol Storage Area A SAN ( storage area network) is an architecture to attach remote computer Network (SAN) storage devices such as disk array controllers, tape libraries and CD arrays to servers in such a way that to the operating system the devices appear as locally attached devices. Although cost and complexity is dropping, as of 2007, SANs are still uncommon outside larger enterprises. Virtualization Creation of non-physical versions of something that acts like a physical entity. This could mean splitting a disk drive into three virtual drives that act like separate physical drives. With servers, virtualization refers the capability to run several virtual servers on one physical server. The virtual servers act like independent physical servers. Virtualization can improve scalability, work loads, disaster recovery and administration time. Web Services Independent modules which are associated with a particular web address (URL). They use an XML based language called Web Services Description Language (WSDL) that describes the service. A Practical Service Oriented Architecture 82
  • 84. References 1. Chappell, David A., “Enterprise Service Bus”, 2004, O’Reilly Press 2. Service-Oriented Architecture: Making Collaborative Gov- ernment Work, Center for Digital Government: http://www. centerdigitalgov.com/story.php?id=98218 3. MITA Service Oriented Architecture – A Primer, Centers for Medicaid and Medicare Services (CMS), http://www.cms.hhs. gov/MedicaidInfoTechArch/Downloads/mitasoa.pdf 4. Federal Enterprise Architecture, Office of Management and Budget, http://www.whitehouse.gov/omb/egov/a-1-fea.html 5. Proposal for Fulfilling Strategic Objectives of the U.S. Road- map for National Action on Decision Support through a Service-oriented Architecture Leveraging HL7 Services, K. Kawamoto, D. Lobach, J Am Med Inform Assoc. 2007; 14:146-155. 6. California Service Oriented Architecture (SOA) Master Guide, http://www.cio.ca.gov/caIT/pdf/SOA_Master_Guide. pdf 7. California Enterprise Architecture Framework, Release 1.0 Final, July 15, 2005, page 20, http://www.cio.ca.gov/stateIT/ pdf/California_EA_Framework_Final.pdf 8. State of Minnesota Enterprise Architecture Whitepaper, December, 2005, http://www.state.mn.us/portal/mn/jsp/con- tent.do?subchannel=-536891918&programid=536911144&id=- 536891917&agency=OETweb A Practical Service Oriented Architecture 83
  • 85. A Practical Service Oriented Architecture 84
  • 86. Minnesota Department of Health 625 Robert St. N. PO Box 64975 St. Paul, MN 55164-0975 October 2007