A Practical Service Oriented Architecture

1,716 views

Published on

  • Be the first to comment

  • Be the first to like this

A Practical Service Oriented Architecture

  1. 1. A Practical Service Oriented Architecture A Vision for the use of Information Technology at MDH MDH Architecture Project Team: 2007
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×