city of chicago integration strategy

Business Drivers Proprietary and Confidential 1 City of Chicago, Copyright 2005

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

2 Strategy document

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


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

4 Strategy document

Enterprise Integration Business Drivers

Section 1

Eric Peebles 1.0

6/21/2005


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

6 Strategy document

• 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


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 Management tool

$140,000 SOA management tool for managing multiple services. BEA Aqualogic service system

Software - Services and User Security environment

$325,000 A service-based security front-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

8 Strategy document

Services - Project management

$275,500 This is the cost of a project manager for overall management of the integration projects.

Services - Architect for Development

$210,000 <Description>

Services - Java Tech Lead for Development


Services - Java Developer for Development


Services - Java Developer for Development


Services - Data Tech Lead for Development


Services - Data Analyst for Development


Services - Business Analyst for Development


Training - Java $12,000 <Description>

Training - System 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 head count Need to calculate

Reduce training costs Need to calculate

Reduce customer support costs Need to calculate

Reduce personnel costs

Other Need to calculate

Reduce error rates Need to calculate

Reduce cost of fixing errors Need to calculate

Eliminate re-keying of information

Need to calculate

Reduce IT costs

Reduce system support costs through integration

Need to calculate

Reduce the cost of implementing change

Need to calculate Reduce business costs

Reduce cost by providing more online automated services

Need to calculate


Reduce costs through optimized business processes

Need to calculate

Reduce cost through more accurate data

Need to calculate

Use of new data sources to identify possible revenue streams through use of County, State, and Federal data.

For example through the use of the Secretary of State data we could potentially identify up to 500,000 unregistered vehicles generating $37,500,000 in new City Sticker Sales

Provide new services by being able to utilize emerging technologies to provide greater opportunities

Provide immediate and instant update to vendors in the City of opportunities or changes in process.

Increase revenue

Create new opportunities through integration with partners and suppliers

Better data allows the City to bring together landowners, building contractors, and developers to collaborate on opportunities online.

• Metrics

Business Goal Metric Name Metric Value How to Collect Frequency Owner Decrease time between request for a City service and delivery

Service delivery time

Days Business activity monitoring solution

On request of each service

Business manager

Decrease transaction errors

Transaction errors

Number of errors Exception handling log

Weekly Operational manager

Decrease delivery time of projects

Projects delivery rates

Estimated vs. actual

Executive dashboard

Daily Executive team

Increase accuracy of City mailings

Returned mail Returned mail Post office reports

Weekly Operational manager

• Risks

Significant Unknown <Issue> <Description> <Mitigation> <Owner>

Organizational Issues Elimination of silo's System and

departmental silos will be eliminated, changing the core of the City culture

Begin to introduce and acknowledge the change

City executive team

Cultural Issues Hasty project decisions Different drivers within

and outside of the City of Chicago allow for the opportunity to make hasty and imprudent decision for technology projects. This often leads to an inadequate

Every technology project within the City should go through the same or similar business process and a good representation of business and City technologist should

BIS executive team

10 Strategy document

result ultimately costing the City more resources and creating additional business problems.

recommend a proper strategy to achieve realistic outcomes.

Technical Issues Newer more advanced technology

Without proper training the City could build an environment that it cannot support because of improper skill set

Constant mentoring and training of a small group of employees working in a "Center of Excellence" type of structure

Development and Support Program manager

Management Issues Administration of Environment

A larger more prominent technical environment demands better administration capabilities

Built systems administration concurrently with initiative progress

BIS

Ability to Achieve Results Increase overall city capabilities

More automated data and processes available

Train employees on how to utilize new technology

Department heads


Enterprise Integration Strategy Specification

Section 2

Eric Peebles 1.0

7/31/2005


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.


Maximize enterprise tools. Learn what enterprise tools the City

of Chicago currently owns, where holes exist the City will procure appropriate tools set to fill the void.

By maximizing the use of our current toolset we can reduce or eliminate the desire to continually use competing tools based on preference

Constantly mentor, train, and cross-train

Allow as many technical BIS employees as possible to become part of a Center of excellence

With an increase in the number of employees with the proper skillset, it 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 leveraged in the next project.

Initially cost may increase, but 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 lifecycle

strategy rationale

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.


Priority Business Strategy/Initiative

Scope Integration Strategy

Budget

1 Migration of City Sticker Application

Creation of new City clerk Business process, identification of new forms of data, and creation of multiple types of reporting

Application integration

$1.2 million

2 Identification of Unique registered vehicles in the City of Chicago

Information integration

$175,000

3 City Clerk vehicle sticker application mainframe migration and enhancement

Create a real-time online Sticker purchasing system

Service based application, using information integration, and application integration.

$600,000

4 City sticker admin application

Create a new administration module to manage the Sticker customers and data previously this was done by a developer

Process integration and management

$250,000

5 Create message bus for ECM project

Project to reduce time to cleanse and load data to the ECM system

Application integration ESB

$200,000

6 Provide ECM id matching

Project to facilitate clean data

Process driven rules and rules engine

$100,000

7 Provide ECM CRN data integration

Project to allow multiple systems within the City to access a database outside the City firewalls

Information integration of structured data using EII

$70,000

8 Create Web intake for for DOP

Allow individuals anyplace in the world to apply online for City of Chicago positions

Enterprise Content Management

$740,000

9 Create data repository for DOP online job application

Create a searchable database of job applicants for DOP to score and manage

Information integration

$217,000

10 Create online job search functionality for DOP

N/A


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 Protocols

Web site for JCA or Web service interface 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 Strategy

Metric Name Metric Value

How to Collect Frequency Owner

Goal Metric Value

Increase reuse Component reuse Number of times component is reused

Number of business processes or composite apps component is used in, alternatively # of times it’s checked out from reuse repository

Monthly Repository owner, central architecture group, or competency center (note different types of components may have different owners

2.9 Risks

Significant Unknown Issue Description Mitigation

Organizational Issues Lack of governance organization Currently we have no

organization to review design documents and establish standards

Creation of a governance organization is under review and planned


Small City staff The City has a very small pool of skilled technologist

Recruit skilled resources from multiple consulting organizations to assist in the process

Cultural Issues Multiple groups working together

With the current set of integration, many groups that have been more soled in the past will need to work within a larger team in order to make the initiative successful

Continue to keep the program managers and business owners involved and updated.

Technical Issues Infrastructure All needed parts of the

infrastructure are not in place, such as LDAP, Kerberos, etc.

Continue to move infrastructure components into the environment project by project

Management Issues Lack of Executive Oversight Integration must be a key

focus at the executive level within the City

Continue to demonstrate success in current direction

Ability to Achieve Results Project dependant Results will be based on how

well we architect a project within the integration strategy. Some projects have funding and are moving forward, others do not.

Continue to keep the program managers and business owners involved and updated and assisting them with their budget request.


Application Integration Implementation Specification

Section 3

Eric Peebles 1.0

7/31/2005


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



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.


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

Java platform compliant

Security BEA Enterprise Security Server implementing LDAP, tokens, and PKI.

Security will use the COC Novel e-directory LDAP server as a 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 WLI adapters

Java platform compliant

Security BEA Enterprise Security Server implementing LDAP, tokens, and PKI.

Security will use the COC Novel e-directory LDAP server as a foundation, coupled with Kerberos security tokens, and Verisign PKI infrastructure

3.4.3 Legacy Integration


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 interface

TBD TBD

Legacy integration - screen/report interface

TBD TBD

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.


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 bus

BEA Java

Application server BEA Java

EII BEA Liquid data



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


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



A2A security TBD TBD

Other Services

3.5 Transactional

3.6 Persistence

3.7 Business rules.

3.8 Conclusion


Information Integration Architecture Specification

Section 4

Eric Peebles 1.0

6/19/2005


This page intentionally left blank.


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.


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 Name

Business Owner

Description of Information Application

Aggregation or Publishing

Data Sources Involved

Outcome of the Flow of Information

Management dashboard

City Executive team

Daily work order volumes on a citywide basis

Aggregation CSR, CityWorks, DataStream, Suntrack

Graphical display of work orders: daily, weekly, monthly, and quarterly

CSR call center

CSR Commissioner

Single view of a relationship of a

Aggregation All systems containing

Single screen unifying all


customer support system

Mayors Office

customer for the call center. Not just the CSR information, but information on how that person relates to the City.

customer information AR, IRIS, Hansen

customer information

Online customer change of address

CIO Update all addresses for a employee or customer using self service change of address

Publishing All systems containing customer or employee addresses

Update to all systems with customer address

<Application name>

<Owner> <Description> <Information pattern>

<Source> <Outcome>

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.

ARCity-widePaymentProcessor

Order Info

CSR

CustomerInfo

CustomerInfo

Order Info

Person info

Payment infoPayment info

id

Secretary ofState Systems

EII CDB

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.


Data element name <Source system data name>

Data source <Source>

Description <Description>

Format and data type <Source system format and type>

Canonical name <Enterprise canonical name>

Canonical format <XML or other—name format>

Transformation rules <From source to canonical format>

Basic metadata

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>

Location of the system <Directory>

Service information <Web services directory>

Message schema information <Message repository>

Communication protocol <SOAP, HTTP, TCP/IP, VAN>

Added management

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 name

<Target data element name>

Target system or service <Service or system name>

Integrity rules <Rollback and compensation rules>

Security requirements <Encryption, nonrepudiation, and access rules>


Process Integration Implementation Specification

Section 5

Eric Peebles 1.0

7/19/2005


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.


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


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


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, WLI, and FileNet

Many workflow management engines 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


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>

city of chicago integration strategy

Documents

enterprise integration

integration cost

integration strategies

government integration

process integration

integration project

legacy integration

mobile integration