City of Chicago Integration Strategy

The purpose of this document is to describe the City of Chicago's IT integration str...
CITY OF CHICAGO INTEGRATION STRATEGY.......................................................................... 1
1.     IN...
4.2 INFORMATION INTEGRATION BUSINESS SCENARIOS ................................................... 30
4.3 INFORMATION INTE...
Enterprise Integration Business Drivers




                    Section 1




                                          Er...
1. Introduction

     Enterprise integration focuses on improving the efficiency and effectiveness of the processes
that r...
•    Enterprise Case Management

    •    City Database

    •    IRIS

    •    ARMS

    •    RECAPPS

    •    City Ent...
Enable real-time tracking of key performance indicators
        Provide the capability to explore process simulation and a...
Services - Project                   $275,500                      This is the cost of a project
         management      ...
Reduce costs through optimized          Need to calculate
                            business processes
                 ...
result ultimately costing   recommend a proper
                                  the City more resources     strategy to a...
Business Drivers     Proprietary and Confidential    11
                   City of Chicago, Copyright 2005
Enterprise Integration Strategy
              Specification




                 Section 2




                           ...
2.1 Introduction
Enterprise integration focuses on improving the efficiency and effectiveness of the processes
that run th...
Maximize enterprise tools.             Learn what enterprise tools the City      By maximizing the use of our current
    ...
Priority       Business                     Scope               Integration          Budget
                   Strategy/In...
2.6 Strategic Sourcing
The City of Chicago's outsourcing approach is to work with a small set of 3 - 5 approved
vendors wh...
Small City staff                 The City has a very small          Recruit skilled resources from
                       ...
18   Strategy document
Application Integration Implementation
               Specification




                          Section 3




          ...
3.1 Introduction
This specification provides implementation guidance for the development of an application
integration bas...
There are several groups of key participants. The first group is the stakeholders. BIS is the
primary stakeholder and tech...
The message broker implementation involves an integration hub that provides transformation
services to convert the message...
The goal is to integrate with the legacy data, application, or process noninvasively, without
changing the legacy applicat...
Integration Service                 Vendor/Product                   Implementation Notes
B2B connectivity                ...
systems and flexibly format it for different target devices. Mobile integration reliability and
security are key issues to...
26   Strategy document
Information Integration Architecture
                Specification




                          Section 4




           ...
This page intentionally left blank.




28                                    Strategy document
Introduction
This specification provides the design guidance for applying an information-driven approach to
integration fo...
EII combined with our existing ETL capabilities form a part of our information integration
strategy, with the inclusion of...
customer                           customer for the call                        customer           customer
support system...
Data element name                  <Source system data name>
                                Data source                  ...
Business Drivers     Proprietary and Confidential    33
                   City of Chicago, Copyright 2005
Process Integration Implementation
                Specification




                   Section 5




                    ...
Business Drivers     Proprietary and Confidential    35
                   City of Chicago, Copyright 2005
Introduction
     Process integration represents a specific style of integration. It manages the integration from
an end-t...
•   Process activity monitoring
•   Process collaboration
    In this section define the particular pattern that is being ...
Integration Service               Vendor/Product                       Implementation Notes
Process modeling              ...
collaboration platform, or may integrate with a content management solution. Version control
with check-in and check-out f...
Upcoming SlideShare
Loading in...5
×

City of Chicago Integration Strategy

2,167

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
2,167
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
36
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "City of Chicago Integration Strategy"

  1. 1. City of Chicago Integration Strategy The purpose of this document is to describe the City of Chicago's IT integration strategy. The City of Chicago follows a Service Oriented Architecture (SOA) for enterprise integration. Our definition of SOA: Service-Oriented Architecture is an IT strategy that organizes the discrete functions contained in enterprise applications into interoperable, standards-based services that can be combined and reused quickly to meet business needs. This is an ongoing strategy starting in January of 2006. The City of Chicago's strategic direction will encompass application, information, and process integration in concurrent implementation threads. This is an effort to reduce integration cost and expand technical capabilities to respond to business drivers in a quick and efficient manner. This document will be continually revised and used as a template for directing each integration project within the City of Chicago. This document can be used by • City Executives • City Business Analyst • City Domain Experts • City Technologist Business Drivers Proprietary and Confidential 1 City of Chicago, Copyright 2005
  2. 2. CITY OF CHICAGO INTEGRATION STRATEGY.......................................................................... 1 1. INTRODUCTION ..................................................................................................................... 5 • SCOPE .................................................................................................................................... 5 • KEY PARTICIPANTS.............................................................................................................. 6 • STATEMENT OF PURPOSE .................................................................................................. 6 • COST ESTIMATES ................................................................................................................. 7 • ROI .......................................................................................................................................... 8 • METRICS................................................................................................................................. 9 • RISKS...................................................................................................................................... 9 2.1 INTRODUCTION ........................................................................................................... 13 2.2 SCOPE .......................................................................................................................... 13 2.3 KEY PARTICIPANTS.................................................................................................... 13 2.4 INTEGRATION STRATEGIES...................................................................................... 13 2.5 MAPPING TO BUSINESS STRATEGIES AND INITIATIVES...................................... 14 2.6 STRATEGIC SOURCING.............................................................................................. 16 2.7 STANDARDS ................................................................................................................ 16 2.8 METRICS....................................................................................................................... 16 2.9 RISKS............................................................................................................................ 16 3.1 INTRODUCTION ........................................................................................................... 20 3.2 SCOPE .......................................................................................................................... 20 3.3 KEY PARTICIPANTS.................................................................................................... 20 3.4 APPLICATION INTEGRATION IMPLEMENTATION PATTERNS AND SERVICES .. 21 3.4.1 MESSAGE BROKERS.................................................................................................. 21 3.4.2 ESB................................................................................................................................ 22 3.4.3 LEGACY INTEGRATION .............................................................................................. 22 3.4.4 GOVERNMENT 2 GOVERNMENT INTEGRATION ..................................................... 23 3.4.5 PORTALS...................................................................................................................... 24 3.4.6 MOBILE INTEGRATION ............................................................................................... 24 OTHER SERVICES ....................................................................................................................... 25 3.5 TRANSACTIONAL.................................................................................................................. 25 3.6 PERSISTENCE ....................................................................................................................... 25 3.7 BUSINESS RULES. ................................................................................................................ 25 3.8 CONCLUSION......................................................................................................................... 25 4.1 SCOPE .................................................................................................................................... 29 2 Strategy document
  3. 3. 4.2 INFORMATION INTEGRATION BUSINESS SCENARIOS ................................................... 30 4.3 INFORMATION INTEGRATION ENTERPRISE LIBRARY .................................................... 30 4.4 ENTERPRISE DATA FLOW DIAGRAM................................................................................. 31 4.5 METADATA MODEL .............................................................................................................. 31 4.6 RELATIONSHIP MODEL........................................................................................................ 32 5.1 SCOPE .......................................................................................................................... 36 5.2 KEY PARTICIPANTS.................................................................................................... 36 5.3 PROCESS INTEGRATION PATTERNS AND SERVICES........................................... 36 5.4 PROCESS AUTOMATION............................................................................................ 37 5.5 PROCESS MONITORING............................................................................................. 38 5.6 COLLABORATIVE PROCESS INTEGRATION ........................................................... 38 Business Drivers Proprietary and Confidential 3 City of Chicago, Copyright 2005
  4. 4. Enterprise Integration Business Drivers Section 1 Eric Peebles 1.0 6/21/2005 4 Strategy document
  5. 5. 1. Introduction Enterprise integration focuses on improving the efficiency and effectiveness of the processes that run the City of Chicago. It includes improving the quality and timeliness of information and providing information on demand where it is needed, regardless of the source system. This level of business agility cannot be achieved by only implementing an integration strategy on a project- by-project basis, but an overall strategy for how all aspects of an enterprise Integrate together. Rapid implementation of business strategy requires an enterprise-level integration strategy. The enterprise integration strategy ultimately reduces the time and cost of managing information and City resources. Tactical vs. Strategic -- There are two methods available to the City of Chicago to pursue our integration strategy. Tactical and Strategic. Tactical is how the City of Chicago will eventually get to enterprise integration, but it will follow a strategic plan. Each technology project the City starts, each new application, each new database, and each new integration must fit into the overall strategy to bring systems and processes together. If not valuable resources will be lost. All enterprise systems and departments with large amounts of shared data will need to participate in the overall integration strategy. That being said, each project will be evaluated against a predetermined set of standards to determine the type of integration strategy appropriate for the giving need and system. The Department of Business Information Systems has begun a multi-year enterprise integration project. The project will allow mission critical systems and data stores to accurately exchange information and processes in a cost effective and proficient manner. The multi year time frame is not in place to determine an endpoint to the project, but simply to allow some measurability of the initial implementation of infrastructure and core process. The implementation strategy itself is an ongoing process that should continually be evaluated and improved as needs, technology, skills, and capabilities change. • Scope The scope of the integration project is the entire City of Chicago Enterprise infrastructure. The key systems under consideration are: • the Oracle ERP suite of modules: o FMPS o CHIPPS o AR o Payroll • CSR system • Hansen system Business Drivers Proprietary and Confidential 5 City of Chicago, Copyright 2005
  6. 6. • Enterprise Case Management • City Database • IRIS • ARMS • RECAPPS • City Enterprise Portal • and structured and unstructured data repositories across multiple departments and agencies. • Key Participants The key stakeholders in this initiative are the BIS department guided by the CIO of the City of Chicago, Chris O'Brien, the Mayors executive team, and the program managers and business owners for each of the functional systems listed above. • Statement of Purpose The purpose of the integration initiative is to allow for seamless integration of data and processes between systems, departments, and agencies to enable the City of Chicago to respond to the needs of the public in a fast, cost-effective, and efficient manner. The completion of this project will allow one complete view of the City's data and process to the departmental heads and executive teams of the City of Chicago. Business Initiative City of Chicago enterprise integration Business Drivers Enable systems to seamlessly exchange data in a cost-effective and efficient manner. To improve the timeliness and quality of data from City systems. To enable just-in-time change or creation of any process across any group or department within the City. To drive down the cost of integration between enterprise systems within the City and provide multiple universal views of data stores and processes to the City's management team. Business Strategy Automate business processes enabling faster and more responsive changes to a business process Reduce operational redundancies Reduce system design and engineering cost through re-use of technology artifacts and processes, reducing overall IT cost by 20% Reduce Overall enterprise-wide support cost by 25% Reduce the overall dependency on manual data processing increase the data accuracy and allow for City employees to focus on services to the Citizens. Make richer data indicators available, speeding the decision making process 6 Strategy document
  7. 7. Enable real-time tracking of key performance indicators Provide the capability to explore process simulation and analytics to provide feedback to help the City's executive team optimize business processes Allow for greater visibility into City business process Provide multiple views of cross departmental process Functional Scope Proper middleware focused integration will allow real-time communication of business process and data between our core systems, which will give the City of Chicago the ability to create virtual master data stores of a citizen, business, or other entities. By integrating through a service-based middleware, the City of Chicago will be able to reuse the multiple data and business process services resulting from proper design and engineering projects. This re-use will drive down technology cost. Flexible and dynamic executive dashboards can be supplied with up-to-the-minute real-time data from enterprise source systems through the service based middleware layer. Business Goals The City of Chicago will benefit through decrease business cycle times, decrease errors, faster deliver of services, more accurate information, and better access to information. Organizational Impact The completion of this initiative will eliminate the current silos of data and processes. The organization will have seamless integration across functional departments allowing for better collaboration and exchange of information. The City's technology organizational structure will morph into one larger group focused more on data, process, and integration. Their primary focus will move to managing the processes that drive data. There will remain smaller groups focusing on the functional applications themselves and department driven internet applications. • Cost Estimates This section lists high-level costs and an estimated time frame. Costs at this point are rough and only intended for budgeting purposes. These will be refined. Costs Total Description Hardware $110,000 Hardware to support the additional software infrastructure needs. Software - LDAP $65,000 Lightweight Directory Access protocol system to administer authorization and authentication. Software - Services $140,000 SOA management tool for Management tool managing multiple services. BEA Aqualogic service system Software - Services and User $325,000 A service-based security front- Security environment end tool to front LDAP, Verisign, and Kerberos. Nothing selected BEA Security and Netegrity under consideration. Software - EII tool $225,000 BEA liquid data for Enterprise Information Integration Business Drivers Proprietary and Confidential 7 City of Chicago, Copyright 2005
  8. 8. Services - Project $275,500 This is the cost of a project management manager for overall management of the integration projects. Services - Architect for $210,000 <Description> Development Services - Java Tech Lead for $200,000 <Description> Development Services - Java Developer for $175,000 <Description> Development Services - Java Developer for $175,000 <Description> Development Services - Data Tech Lead for $200,000 <Description> Development Services - Data Analyst for $175,000 <Description> Development Services - Business Analyst $185,000 <Description> for Development Training - Java $12,000 <Description> Training - System $12,000 <Description> Administration Training - ECM $25,000 Business Process management in ECM, Business rules in ILOG, Content used in Enterprise Content Management System Training - BEA $35,000 Weblogic Training, Weblogic Integration, BEA Enterprise Service Bus, BEA workshop (eclipse) Security Services $75,000 Setup and administration of an Enterprise Security Environment • ROI Reduce personnel costs Reduce head count Need to calculate Reduce training costs Need to calculate Reduce customer support costs Need to calculate Other Need to calculate Reduce IT costs Reduce error rates Need to calculate Reduce cost of fixing errors Need to calculate Eliminate re-keying of Need to calculate information Reduce system support costs Need to calculate through integration Reduce business costs Reduce the cost of implementing Need to calculate change Reduce cost by providing more Need to calculate online automated services 8 Strategy document
  9. 9. Reduce costs through optimized Need to calculate business processes Reduce cost through more Need to calculate accurate data Increase revenue Use of new data sources to For example through the use of the Secretary of identify possible revenue streams State data we could potentially identify up to through use of County, State, and 500,000 unregistered vehicles generating Federal data. $37,500,000 in new City Sticker Sales Provide new services by being Provide immediate and instant update to vendors in able to utilize emerging the City of opportunities or changes in process. technologies to provide greater opportunities Create new opportunities through Better data allows the City to bring together integration with partners and landowners, building contractors, and developers to suppliers collaborate on opportunities online. • Metrics Business Goal Metric Name Metric Value How to Collect Frequency Owner Decrease time Service delivery Days Business activity On request of Business between request time monitoring each service manager for a City service solution and delivery Decrease Transaction Number of errors Exception Weekly Operational transaction errors errors handling log manager Decrease Projects delivery Estimated vs. Executive Daily Executive team delivery time of rates actual dashboard projects Increase Returned mail Returned mail Post office Weekly Operational accuracy of City reports manager mailings • Risks Significant Unknown <Issue> <Description> <Mitigation> <Owner> Organizational Issues Elimination of silo's System and Begin to introduce and City executive departmental silos will acknowledge the team be eliminated, changing change the core of the City culture Cultural Issues Hasty project decisions Different drivers within Every technology BIS executive and outside of the City project within the City team of Chicago allow for should go through the the opportunity to make same or similar hasty and imprudent business process and a decision for technology good representation of projects. This often business and City leads to an inadequate technologist should Business Drivers Proprietary and Confidential 9 City of Chicago, Copyright 2005
  10. 10. result ultimately costing recommend a proper the City more resources strategy to achieve and creating additional realistic outcomes. business problems. Technical Issues Newer more advanced Without proper training Constant mentoring Development technology the City could build an and training of a small and Support environment that it group of employees Program cannot support because working in a "Center of manager of improper skill set Excellence" type of structure Management Issues Administration of A larger more Built systems BIS Environment prominent technical administration environment demands concurrently with better administration initiative progress capabilities Ability to Achieve Results Increase overall city More automated data Train employees on Department capabilities and processes available how to utilize new heads technology 10 Strategy document
  11. 11. Business Drivers Proprietary and Confidential 11 City of Chicago, Copyright 2005
  12. 12. Enterprise Integration Strategy Specification Section 2 Eric Peebles 1.0 7/31/2005 12 Strategy document
  13. 13. 2.1 Introduction Enterprise integration focuses on improving the efficiency and effectiveness of the processes that run the City of Chicago. It includes improving the quality and timeliness of information and providing information on demand where it is needed, regardless of the source system. The initiative will allow mission critical systems and data stores to accurately exchange information and processes in a cost effective and proficient manner. The initiative will focus on three types of integration: • Application integration to facilitate the automation of the exchange of business logic from system-to-system in an easy to manage, extend and administer environment. • Information integration to provide an enterprise view of information contained in disparate systems. The value, accuracy, and meaning of the data across systems will increase exponentially through the maintenance of the metadata and exchange of information through canonical formats. • Business process integration, which will model a business process as it cuts across the City of Chicago's organizational structure. The business process integration will maximize the City of Chicago's agility by enabling changes to business process to be implemented quickly. An important milestone in achieving our enterprise integration goal is to implement an enterprise-wide security infrastructure to support and secure the exchange of data and processes between systems within and external to the City of Chicago. 2.2 Scope The scope of the integration project is the entire City of Chicago Enterprise infrastructure. The key systems under consideration are the Oracle ERP suite systems, CSR system, Hansen system, Enterprise Case Management, City Enterprise Portal, and structured and unstructured data repositories. 2.3 Key Participants • The key participants in this initiative are the BIS department's Development and Support team, which will provide the creation and guidance of the City's integration strategy, as well as any ongoing improvements or changes in the initial strategy. • Vendors will be the primary groups that are used to implement the City's integration strategy. • The City of Chicago's technology architecture team led by Steve Philbrick will provide the approval of the strategy and priority setting of types of projects and their order. 2.4 Integration Strategies The City of Chicago must identify the strategies by which the enterprise can use technology to maximize the integration initiative. Key integration strategies include service-oriented and process-driven architectures. The matrix below also includes best practices in integration strategies. Business Drivers Proprietary and Confidential 13 City of Chicago, Copyright 2005
  14. 14. Maximize enterprise tools. Learn what enterprise tools the City By maximizing the use of our current of Chicago currently owns, where toolset we can reduce or eliminate the holes exist the City will procure desire to continually use competing appropriate tools set to fill the void. tools based on preference Constantly mentor, train, and cross- Allow as many technical BIS With an increase in the number of train employees as possible to become part employees with the proper skillset, it of a Center of excellence will be a smoother transition for the City of Chicago to migrate to an integrated environment because of the shared knowledge. Invest in reuse Create reusable interfaces that can be Initially cost may increase, but leveraged in the next project. overtime it will decrease implementation time and cost on future projects. Continuous process improvement strategy rationale Real-time management dashboards strategy rationale SOA strategies strategy rationale Implementation strategy strategy rationale Business integration strategy strategy rationale lifecycle 2.5 Mapping to Business Strategies and Initiatives As mentioned in the previous section the City's overall integration strategy will follow a strategic plan with a tactical project-to-project approach. With our tactical approach it is important to maintain a mapping of how a particular business need met by an initiative or project maps to an integration strategy. 14 Strategy document
  15. 15. Priority Business Scope Integration Budget Strategy/Initiative Strategy 1 Migration of City Creation of new Application $1.2 million Sticker Application City clerk integration Business process, identification of new forms of data, and creation of multiple types of reporting 2 Identification of Unique Information $175,000 registered vehicles in the integration City of Chicago 3 City Clerk vehicle Create a real- Service based $600,000 sticker application time online application, using mainframe migration Sticker information and enhancement purchasing integration, and system application integration. 4 City sticker admin Create a new Process $250,000 application administration integration and module to management manage the Sticker customers and data previously this was done by a developer 5 Create message bus for Project to reduce Application $200,000 ECM project time to cleanse integration ESB and load data to the ECM system 6 Provide ECM id Project to Process driven $100,000 matching facilitate clean rules and rules data engine 7 Provide ECM CRN data Project to allow Information $70,000 integration multiple systems integration of within the City structured data to access a using EII database outside the City firewalls 8 Create Web intake for Allow Enterprise $740,000 for DOP individuals Content anyplace in the Management world to apply online for City of Chicago positions 9 Create data repository Create a Information $217,000 for DOP online job searchable integration application database of job applicants for DOP to score and manage 10 Create online job search N/A functionality for DOP Business Drivers Proprietary and Confidential 15 City of Chicago, Copyright 2005
  16. 16. 2.6 Strategic Sourcing The City of Chicago's outsourcing approach is to work with a small set of 3 - 5 approved vendors who can specialize in each of the needed areas of integration; application, data, and process. The combination of these three areas form our enterprise integration strategy. A combination of individuals from all approved City technology vendors will participate on a team to manage and implement the integration strategy. Projects that fall outside of the integration strategy will go out for bid to the approved BIS technology vendors. The City's technology procurement process is undergoing multiple changes, reference RFQ 1348 for details on how vendors will be selected and granted an approved status to conduct business with the City. 2.7 Standards Proposed Usage References Communication Web site for JCA or Web service interface Protocols specification Application interfaces Packaged application. Interfaces Web site for JCA or Web service interface specification Message formats Internal messages, external messages Links to City appropriate standards Web sites Process models FileNet business process manager Metadata Metadata about interfaces, Web services, data transformation 2.8 Metrics Integration Metric Name Metric How to Collect Frequency Owner Strategy Value Goal Metric Value Increase reuse Component reuse Number of Number of Monthly Repository times business processes owner, central component is or composite apps architecture reused component is used group, or in, alternatively # competency of times it’s center (note checked out from different types of reuse repository components may have different owners 2.9 Risks Significant Unknown Issue Description Mitigation Organizational Issues Lack of governance organization Currently we have no Creation of a governance organization to review design organization is under review documents and establish and planned standards 16 Strategy document
  17. 17. Small City staff The City has a very small Recruit skilled resources from pool of skilled technologist multiple consulting organizations to assist in the process Cultural Issues Multiple groups working With the current set of Continue to keep the program together integration, many groups that managers and business have been more soled in the owners involved and updated. past will need to work within a larger team in order to make the initiative successful Technical Issues Infrastructure All needed parts of the Continue to move infrastructure are not in place, infrastructure components such as LDAP, Kerberos, etc. into the environment project by project Management Issues Lack of Executive Oversight Integration must be a key Continue to demonstrate focus at the executive level success in current direction within the City Ability to Achieve Results Project dependant Results will be based on how Continue to keep the program well we architect a project managers and business within the integration owners involved and updated strategy. Some projects have and assisting them with their funding and are moving budget request. forward, others do not. Business Drivers Proprietary and Confidential 17 City of Chicago, Copyright 2005
  18. 18. 18 Strategy document
  19. 19. Application Integration Implementation Specification Section 3 Eric Peebles 1.0 7/31/2005 Business Drivers Proprietary and Confidential 19 City of Chicago, Copyright 2005
  20. 20. 3.1 Introduction This specification provides implementation guidance for the development of an application integration based solution. Application integration represents a specific style of integration. This style is to solve problems where two or more applications communicate together to accomplish a given task. Types of problems that are well suited to application integration are • Coordinating actions and replicating transactions across multiple applications • Opening up legacy systems and extending them to the Web • Creating new user interfaces • Government-to-government transactions • Government-to-business transactions • Government-to-people transactions • Deploying applications to multiple mobile and hand-held devices This section describes the specific technical problems that are being addressed in the implementation, and provides context for the specific City of Chicago implementation. 3.2 Scope The scope of an application integration specification is limited to the specifics of the applications that are being integrated. Application integration is an ongoing effort. This document should serve as a basis for all integration projects. The City of Chicago's integration strategy is an ongoing effort. As City capabilities change and grow this document will be updated to reflect any changes. The early phases of integration will only include the primary enterprise systems under BIS management. After the primary enterprise systems integration is completed, secondary enterprise systems and primary departmental systems will follow. The BIS Development and Support team will be the principal architects, administrators, and managers of the initial integration efforts. The key systems involved in the initial Enterprise Integration effort are: • CSR • Enterprise Case Management • Hansen • Oracle ERP suite: o FMPS o Payroll o CHIPPS • GIS • CRM Systems • Enterprise Portal 3.3 Key Participants 20 Strategy document
  21. 21. There are several groups of key participants. The first group is the stakeholders. BIS is the primary stakeholder and technology owner of the systems listed above. The business owners of those systems are also stakeholders, that group includes: • 311 City Services • The Human infrastructure departments (Human Services, Children and Youth services, Aging, Health and Housing Department • All inspection and permitting departments using the Hansen system (Buildings, DCAP, Health, and DPD) • Procurement Department • Finance Department • Personnel Department The technical oversight team overseeing the architecture and priority list of the integration effort is the BIS technical architect team. The implementation is being done by the BIS Development and Support team along with three system integration companies; Sofbang, CityTech, and EKI. The primary software company assisting with the integration effort is BEA and the BEA technical team. 3.4 Application Integration Implementation Patterns and Services There are several basic implementation patterns for an application integration solution. Application integration is not a single technology or solution. It is very important to choosing the right set of technologies or integration services to meet a specific integration requirement and fit within the organization structure of the City of Chicago. After careful review of the City of Chicago requirements and organizational structure the following integration patterns were chosen. These patterns are: • Message broker • Enterprise Service Bus (ESB) • Legacy integration • Portals • Mobile integration 3.4.1 Message Brokers Message brokers are well suited to coordinating and replicating multiple transactions across applications, as well as providing back-end integration to legacy systems. When needing to integrate with multiple systems or do complex data translations and transformations a message broker is required. The message broker will have limited use in the City of Chicago's application environment, only where specific requirements require its use. Most integration efforts will use the ESB pattern. Business Drivers Proprietary and Confidential 21 City of Chicago, Copyright 2005
  22. 22. The message broker implementation involves an integration hub that provides transformation services to convert the messages into the correct format for the receiving application. The broker provides intelligent routing to manage the complexity of moving the messages between applications, and translation and transformation, generally through proprietary graphical-mapping tools. Adapters provide interfaces into applications and are the points where applications can send or receive messages. The implementation table defines the services identified in the implementation architecture. Integration Service Vendor/Product Implementation Notes Message broker BEA Weblogic Integration Server Java platform Messaging Sun JMS Java platform Application interface Web services, Sun JCA, and BEA Java platform compliant WLI adapters. Security BEA Enterprise Security Server Security will use the COC Novel e- implementing LDAP, tokens, and directory LDAP server as a PKI. foundation, coupled with Kerberos security tokens, and Verisign PKI infrastructure 3.4.2 ESB The ESB is more flexible and scalable than the message broker, but also more complex to implement. Until recently, there were no widely accepted standards in the industry. Web services make the service bus a more viable commercial approach to application integration. Essentially, the ESB solves the same set of business problems that a message broker does, but it has a different architecture. The ESB provides connectivity services, including transport protocol, message protocol, message routing, and guaranteed delivery. ESB's also usually provide some basic data transformation, such as XML translation via XSLT style sheets, but additional translation and transformation tools may be necessary for complex data transformation requirements. The ESB has adapters or connecters into applications that provide interfaces into the application as the method of communication. These interfaces represent services that are provided. The services can be registered into a directory. Requests can be sent to specific locations or routed based upon rules. The Enterprise Service Bus Implementation Table defines the services identified in the ESB reference architecture. Integration Service Vendor/Product Implementation Notes Enterprise Service Bus (ESB) BEA ESB Server Aqualogic Java Translation and transformation BEA WLI and ESB server Java Application interface Web services, Sun JCA, and BEA Java platform compliant WLI adapters Security BEA Enterprise Security Server Security will use the COC Novel e- implementing LDAP, tokens, and directory LDAP server as a PKI. foundation, coupled with Kerberos security tokens, and Verisign PKI infrastructure 3.4.3 Legacy Integration 22 Strategy document
  23. 23. The goal is to integrate with the legacy data, application, or process noninvasively, without changing the legacy application. This can be done by creating a new interface to the legacy system. This section defines what type of interfaces will be used. • Database interfaces. Database-level adapters that allow front-end applications access mainframe data through database calls native to the requesting application, including JDBC, ODBC, and ADO. • Messaging interfaces. If the integration includes transaction processing, a message interface can be used. This includes connectors for JCA and SOAP messaging. The City of Chicago's messaging interface will be JMS based Soap messages and Web services. • Screen/report interface. Sometimes, the only way to access mainframe data is through the screen or report interface, also called screen and report scraping. They both work the same way. The 3270 screen or report provides a defined interface to legacy systems for extracting information to the screen or report. The interface technology captures those data bits, and redirects them to a Web browser. If this type of interface is needed the City of Chicago will use a product call Kapow. • Service interface. The service-level interface, also called legacy wrapping, enables mainframe processes and functions to be wrapped with a Web service, .Net, Java or CORBA interface. Web service interfaces to mainframe processes and services provide the most adaptable and reusable method of legacy integration, but also the highest initial investment. Currently there are no plans to interface to via this method. The Legacy Integration Implementation Table defines the services identified in the Legacy Integration Reference Architecture. Integration Service Vendor/Product Implementation Notes Legacy integration - data interface TBD TBD Legacy integration - message TBD TBD interface Legacy integration - screen/report TBD TBD interface Legacy integration - service interface TBD TBD 3.4.4 Government 2 Government Integration G2G integration usually includes application integration services, but also adds additional services required when integrating with applications external to the organization, including • G2G Connectivity through either a G2G server or an external exchange • Multiple connectivity options for partners including EDI, HTML, XML, and FTP • Additional G2G security for encrypting transactions, authenticating the sender, and ensuring nonrepudiation of the transaction. • Partner management, including processes, business rules, and service-level management. The G2G Implementation Table specifies all components of the G2G architecture, including how back-end integration will be accomplished. Business Drivers Proprietary and Confidential 23 City of Chicago, Copyright 2005
  24. 24. Integration Service Vendor/Product Implementation Notes B2B connectivity TBD TBD Partner connectivity TBD TBD Partner management TBD TBD B2B security TBD TBD Back-End Application Integration TBD Broker/enterprise service bus WLI SOAP BEA java Translation and transformation TBD TBD Routing WLI Application interface TBD TBD Legacy integration TBD TBD G2G security TBD TBD 3.4.5 Portals Portals provide integration at the glass. They are used to extend legacy application functionality to the Web, and provide customer-facing applications. Portals require extensive integration services. There are a number of different ways to provide portal integration. The portal can have point-to-point connections to each of the applications it integrates with. APIs, database interfaces, Web services, or adapters can be used. Portals can also be part of an application server solution, and the application server can provide the integration services. Message brokers and ESB's can also provide integration services to the portal. Lastly, when the portal requires real-time access to aggregated enterprise data, enterprise information integration (EII) can be used. Moreover, if the portal supports business transactions as well as data aggregation, a combination of technologies can be used. The Portal Integration Reference Architecture depicts the alternative integration services that can be used in a portal implementation. Each of the services in the dotted box can be implemented as the sole portal integration solution. Alternatively, EII can be combined with a message broker or ESB or application server. Multiple types of interfaces may be used in a single implementation. The Portal Integration Implementation Table defines all the technologies and services that will be implemented as part of the portal solution Integration Service Vendor/Product Implementation Notes Portal BEA Weblogic Portal Part of the BEA java Platform Back-End Application Integration Message broker/enterprise service BEA Java bus Application server BEA Java EII BEA Liquid data Application interface TBD TBD Legacy integration TBD TBD 3.4.6 Mobile Integration The mobile integration pattern is similar to G2G integration. It includes back-end application integration, and a mobile integration server can take the same information from multiple source 24 Strategy document
  25. 25. systems and flexibly format it for different target devices. Mobile integration reliability and security are key issues to pay attention to, because the mobile network is inherently unreliable and insecure. The Mobile Integration Specification Table, like G2G integration, specifies how integration to back end systems will be implemented. Integration Service Vendor/Product Implementation Notes Mobile integration server MobileAware Mobile security TBD TBD Back-End Application Integration Broker/enterprise service bus BEA Java Translation and transformation BEA Routing BEA Application interface TBD TBD Legacy integration TBD TBD A2A security TBD TBD Other Services 3.5 Transactional 3.6 Persistence 3.7 Business rules. 3.8 Conclusion Business Drivers Proprietary and Confidential 25 City of Chicago, Copyright 2005
  26. 26. 26 Strategy document
  27. 27. Information Integration Architecture Specification Section 4 Eric Peebles 1.0 6/19/2005 Business Drivers Proprietary and Confidential 27 City of Chicago, Copyright 2005
  28. 28. This page intentionally left blank. 28 Strategy document
  29. 29. Introduction This specification provides the design guidance for applying an information-driven approach to integration for the City of Chicago. Data integration has matured dramatically in the last few years. In the past it was a point-to-point solution, such as a dblink. A point-to-point approach was strictly focused on moving blocks of information from one system to another. With a stronger desire from business owners to have closer to real time information available, a focus on the importance of metadata and the need to integrate all forms of content, we find that data integration has become subset of the larger area of information integration. For the sake of clarity, we define data integration to mean structured data managed by databases. Information integration includes both the structured data and unstructured information such as documents, images, videos, graphics, and streaming media. Currently the City of Chicago's primary means of information integration is through our portal. Our portal aggregates data from multiple databases and presents other types of unstructured data, such as documents, graphics, videos and audio. Because web and portal applications are becoming more robust and integral to the City's technology, information integration is likely to become extremely important. 4.1 Scope The scope of this section of the document will give an overview of some of the tools used in the information integration space. ETL tools were created to extract information, transform it into a consolidated view, and then load it into another system or repository via batch mode. Data volumes are typically large and load cycles long. ETL data is typically a day to a week old. Enterprise application integration (EAI) is another type of data tool to achieve the similar outcomes as ETL. EAI resolved latency problems by synchronizing changes across systems in real time, but doesn't aggregate and consolidate data in an acceptable manner. EAI maps source data to a canonical data format and enable exchanging data among systems, but does not define an aggregated view of the data objects or business entities. EII is both an old and new idea. It provides the data aggregation of the ETL tools, but also provides real-time access to accurate information, much like EAI. It also provides an infrastructure for integrated enterprise data management. The other pressing need is to integrate and manage unstructured information, such as documents, e-mail, graphics, streaming media, and other types of electronic data. Enterprise content management (ECM) provides these capabilities. Business Drivers Proprietary and Confidential 29 City of Chicago, Copyright 2005
  30. 30. EII combined with our existing ETL capabilities form a part of our information integration strategy, with the inclusion of ECM we have all the components of an information integration strategy. All of these components can be services on the enterprise service bus. 4.2 Information Integration Business Scenarios Information integration can be used to deploy the following kinds of applications: • Creating a single view of a person (customer) or other business entity • Enterprise data inventory and management • Real time reporting and analysis, and creating management dashboards • Creating a virtual data warehouse • Updating common information across information sources • Creating portal applications containing both structured and unstructured data from disparate systems • Integrating unstructured data, including documents, audio, video and other electronic media, into applications • Providing an infrastructure for enterprise information management, including all forms of digital media Information integration simplifies the creation of all these applications by enabling the information so that it can be managed and accessed as if it came from a single data source. For information to be correctly managed, secured, tracked, and accessed an information integration enterprise metadata library is needed. The library will contain important information about the City of Chicago's data stores. 4.3 Information Integration Enterprise Library This section contains examples or information needed within the City of Chicago data library to facilitate data integrations, transformation, and application development. This section only contains samples; actual documents need to be created. Application Business Description of Aggregation Data Sources Outcome of the Name Owner Information or Publishing Involved Flow of Application Information Management City Executive Daily work order Aggregation CSR, Graphical display dashboard team volumes on a citywide CityWorks, of work orders: basis DataStream, daily, weekly, Suntrack monthly, and quarterly CSR call CSR Single view of a Aggregation All systems Single screen center Commissioner relationship of a containing unifying all 30 Strategy document
  31. 31. customer customer for the call customer customer support system Mayors Office center. Not just the CSR information information information, but AR, IRIS, information on how that Hansen person relates to the City. Online CIO Update all addresses for Publishing All systems Update to all customer a employee or customer containing systems with change of using self service change customer or customer address address of address employee addresses <Application <Owner> <Description> <Information <Source> <Outcome> name> pattern> 4.4 Enterprise Data Flow Diagram The Enterprise Data Flow Diagram depicts the flow of information across the enterprise. The purpose of the enterprise data flow diagram is to determine which systems are involved in enterprise data exchange, and to later determine the integrity rules across systems (done in the Relationship Model, section 7). The following diagram is an adaptation of a possible City enterprise data flow model in order to focus on the flow of information across systems. Here external systems (depicted as shaded boxes) are systems outside of the enterprise. It is important to note that this should represent the flow of information between systems, not the flow of information for one particular system or process. id CSR Secretary of State Systems Customer Info Customer EII CDB Info Person info Order Info Order Info Payment info Payment info City-wide Payment AR Processor 4.5 Metadata Model Each data store will require a metadata model of each of the data sources in the enterprise. The Metadata Model is used to define access and transformation rules. It establishes data lineage and enables impact analysis. Metadata for existing data sources must be captured for each element. The information model can be extended as needed to support the enterprise. Business Drivers Proprietary and Confidential 31 City of Chicago, Copyright 2005
  32. 32. Data element name <Source system data name> Data source <Source> Description <Description> Format and data type <Source system format and type> Basic metadata Canonical name <Enterprise canonical name> Canonical format <XML or other—name format> Transformation rules <From source to canonical format> Interface <Web service, adapter, JMS, API, SQL> Semantic metadata Integrity rules <Relationships across applications> Added security Security parameters <Access control lists, directory> Platform <Hardware platform> OS <Operating system and version> DBMS <Database> Application platform <Application server, other> Owner of the system <Company, department, manager> Added management Location of the system <Directory> Service information <Web services directory> Message schema information <Message repository> Communication protocol <SOAP, HTTP, TCP/IP, VAN> Access mechanism <Enterprise message bus, message broker, JMS call, EDI VAN> 4.6 Relationship Model The Relationship Table defines the mapping of the data between the new applications and the existing systems as well as the integrity rules across data objects and systems. Note that the system/service and source data element name are added here to provide lineage. The target system/service is included to enable impact analysis. The business rules can include aggregation and parsing rules particular to that data flow. Canonical name <Canonical name> Source system/service data element name <Data element name> Source system/service <System/service name> Business rules <Aggregation and parsing rules> Target system or service data element <Target data element name> name Target system or service <Service or system name> Integrity rules <Rollback and compensation rules> Security requirements <Encryption, nonrepudiation, and access rules> 32 Strategy document
  33. 33. Business Drivers Proprietary and Confidential 33 City of Chicago, Copyright 2005
  34. 34. Process Integration Implementation Specification Section 5 Eric Peebles 1.0 7/19/2005 34 Strategy document
  35. 35. Business Drivers Proprietary and Confidential 35 City of Chicago, Copyright 2005
  36. 36. Introduction Process integration represents a specific style of integration. It manages the integration from an end-to-end business process level. It is appropriate for business process-improvement initiatives, automating iterations between departments, near real-time activity monitoring, and implementing compliance solutions. This section describes the context of the specific implementation described by this specification. The purpose of integration is almost always to support improving a business process to increase business efficiency. Process-level integration defines the interactions among systems through business workflow definitions. The instructions for the integration are defined at the business process level rather than the technical-interface level. Although a technical integration infrastructure is still a necessity to implement process integration, the processes themselves are technology independent. This enables change to be made quickly and easily, increasing business agility. The role of process integration architecture is to create process models and definitions as managed entities that can be easily viewed and changed in response to changes in a department, City, State, or Federal policy. The process integration architecture defines end-to-end business processes, which are then automated across existing system on disparate platforms. The key benefit of the process integration architecture is the business level view it provides of the end-to-end business process. Process integration technology includes dashboards that enable City managers to track key performance indicators in near real time. Process simulation and analytics provide feedback to help the City optimize our governing processes, reduce cost, and make predictive assumption of proposed system changes. The process integration architecture also improves alignment between City managers and BIS. It starts with the City process models that City domain experts can understand and review. These models depict the shared understanding between the departments and BIS. The process can then be automated directly from the model. This significantly reduces the chance of misinterpreting the business requirement or getting the process wrong. As the process can span multiple departments and managers, there may not be one department or manager who owns or even understands the complete end-to-end process. The process models represent a shared understanding of how activities are conducted across the City and should be managed as valuable assets. 5.1 Scope The scope of a process integration specification is limited to the business processes that are being automated and integrated. It can include processes within departments, between departments, external agencies, or businesses. 5.2 Key Participants Because there may be multiple mangers responsible for parts of a process, continuous process improvement and process optimization will be difficult to achieve without a process owner or manager who is responsible for the end-to-end process. 5.3 Process Integration Patterns and Services Reference architectures are provided for the following patterns: • Process automation 36 Strategy document
  37. 37. • Process activity monitoring • Process collaboration In this section define the particular pattern that is being used and provide details on the configuration of the specific components of the implementation. 5.4 Process Automation Process automation requires underlying application integration services. The solution may provide integration services such as adapters, or may provide integration with an SOA solution. Many BPM tools do both in order to provide implementation flexibility. The services included in process automation include process modeling, process simulation, process management including support for long-lived processes and transactions, business rules management, transaction support including compensating transactions, as well as all necessary application integration services. The Implementation Table specifies all the integration services provided in the Process Automation integration solution, along with relevant implementation details. Business Drivers Proprietary and Confidential 37 City of Chicago, Copyright 2005
  38. 38. Integration Service Vendor/Product Implementation Notes Process modeling FileNet Use of BPEL standard model supported Process simulation FileNet Integrated component Process management FileNet Rules management ILOG Rules management may replace process management or may augment it. Workflow management Multiple products; legacy systems, Many workflow management engines WLI, and FileNet work within architecture Application interface BEA SOA based infrastructure Web service; data interface (ODBC, JDBC). Process repository FileNet Part of enterprise repository BAM Nothing selected yet 5.5 Process Monitoring Process monitoring, also called business activity monitoring (BAM), provides real-time visibility into business processes. BAM can be part of a business process management solution or it can be a stand-alone solution. The services provided by BAM include a management dashboard with key performance indicators relevant to particular roles in the organization, real-time analytics to populate the dashboard, and the underlying agents or event managers to recognize relevant events. It has some information integration capabilities to pull information from analytical data stores in real time. A BAM solution may also contain modeling or development capabilities to define the BAM solution, as each one is likely to be unique. Initially the City will use a lightweight BAM solution, FileNet. As more need is recognized and analyzed in this space a more robust permanent solution will be recommended. The Implementation Table specifies all the integration services provided in our BAM solution, along with relevant implementation details. Integration Service Vendor/Product Implementation Notes BAM solution <Vendor name/product name> <Users of the solution> Management dashboard <Vendor name/product name> <Key performance indicators included for each type of user> Business intelligence <Vendor name/product name> <Define integration technology and analytical data sources.> Event manager <Vendor name/product name> <Event server, process engine event logs> Application interface <Vendor name/product name> <BAM agents, process or part of BPM solution> Development/modeling <Vendor name/product name> <Graphical development to generate BAM solution> 5.6 Collaborative Process Integration Collaborative process integration provides a platform for integrating work from different team members in different locations. Collaborative solutions include a collaboration portal that provides access to all project artifacts including deliverables, meeting notes, discussions, etc. A project repository is important for managing project artifacts. The repository can be part of the 38 Strategy document
  39. 39. collaboration platform, or may integrate with a content management solution. Version control with check-in and check-out facilities can either be part of the platform or provided through integration with a content management system or a version control system (especially important for software development as the code is often managed by an existing version control system). The solution can also be a combination of both. Project management may also be provided by the platform, or it can integrate with a project management system. Workflow is often included as part of the platform to manage the collaborative process. Project coordination is provided with electronic calendar and meeting scheduling. A facility to support threaded discussions and negotiations, and document decisions is also helpful. Because much project communication is done through e-mail, which is particularly difficult to manage and archive, e-mail integration is becoming more important. The collaboration platform should include role-based security with granular levels of authorization, so access rights can be defined artifact. As process collaboration integration becomes more firmly entrenched in the organizations the architecture is likely to evolve. The Implementation Table specifies all the integration services provided in the collaborative integration solution, along with relevant implementation details. Modify the following table to specify your implementation. Integration Service Vendor/Product Implementation Notes Collaborative platform <Vendor name/product name> <Hosted within organization or by vendor> Collaboration portal <Vendor name/product name> <Key features provided> Project repository <Vendor name/product name> <Part of platform or integration with ECM> Version control <Vendor name/product name> <Part of platform, part of ECM, third party, combination for different types of information> Project management <Vendor name/product name> <Part of platform and/or integration with project management tool> Workflow <Vendor name/product name> <Part of platform or integration with workflow tool> Calendar and scheduling <Vendor name/product name> <Part of platform or integration with calendaring and scheduling tool> Discussion management <Vendor name/product name> <Tool for threaded discussions that are part of project history> E-Mail integration <Vendor name/product name> <E-mail integration with project repository> Security <Vendor name/product name> <Role-based security> Business Drivers Proprietary and Confidential 39 City of Chicago, Copyright 2005

×