Initial Readiness and Risks Assessment

Iowa Department ofAdministrative Services

IT Enterprise Service-OrientedArchitecture

Initial Readiness and Risks Assessment Version 0.8

This document was prepared by Integrated Software Specialists, Inc. (“ISS”) and is to be considered confidential and proprietary to ISS and Iowa Department of Administrative Services.

IT ENTERPRISE SERVICE-ORIENTED ARCHITECTUREINITIAL READINESS AND RISKS ASSESSMENT

4/18/2006VERSION 0.8

Document Control

DOCUMENT INFORMATION

©

InformationDocument IdDocument Owner Guillermo TantachucoIssue Date 6/05/2006Last Saved Date 6/14/2006File Name IowaSOA_IRRA_Results.doc

DOCUMENT HISTORY

Version Issue Date Changes0.8 6/05/2006 “Draft” Internal Review 0.81 6/09/2006 Initial Review

DOCUMENT APPROVALS

Role Name Signature DateProject Sponsor

Project Review Group

Project Manager

ISS Project Manager

ISS Quality Assurance

CONFIDENTIAL 2023 INTEGRATED SOFTWARE SPECIALISTS, INC. PAGE 2 OF 35


4/18/2006VERSION 0.8

Table of Contents

1 INTRODUCTION..........................................................................................................................7

1.1 Purpose........................................................................................................................................7

1.2 Scope...........................................................................................................................................7

1.3 Definitions, Acronyms and Abbreviations.................................................................................7

1.4 References...................................................................................................................................7

2 READINESS ASSESSMENT........................................................................................................8

2.1 iowa department of revenue........................................................................................................8

2.1.1 Summary................................................................................................................................8

2.1.2 Results details........................................................................................................................8

2.2 iowa workforce development....................................................................................................10

2.2.1 Summary..............................................................................................................................10

2.2.2 Results details......................................................................................................................10

2.3 department of human services..................................................................................................12

2.3.1 Summary..............................................................................................................................12

2.3.2 Results details......................................................................................................................12

2.4 department of transportation.....................................................................................................14

2.4.1 Summary..............................................................................................................................14

2.4.2 Results details......................................................................................................................14

2.5 Iowa veterans home..................................................................................................................16

2.5.1 Summary..............................................................................................................................16

2.5.2 Results details......................................................................................................................16

2.6 iowa vocational rehabilitation services.....................................................................................18

2.6.1 Summary..............................................................................................................................18

2.6.2 Results details......................................................................................................................18

2.7 department of natural resources................................................................................................20

2.7.1 Summary..............................................................................................................................20

2.7.2 Results details......................................................................................................................20



4/18/2006VERSION 0.8

2.8 Department of public health......................................................................................................22

2.8.1 Summary..............................................................................................................................22

2.8.2 Results details......................................................................................................................22

2.9 Department of administrative services......................................................................................24

2.9.1 Summary..............................................................................................................................24

2.9.2 Results details......................................................................................................................24

3 RISKS ASSESSMENT................................................................................................................26

3.1 Risk Perspective: Organization.................................................................................................26

3.1.1 Lack of business involvement..............................................................................................263.1.1.1 Risk Magnitude...............................................................................................................263.1.1.2 Impact..............................................................................................................................263.1.1.3 Mitigation strategy..........................................................................................................263.1.1.4 Contingency plan.............................................................................................................26

3.1.2 SOA is still evolving.............................................................................................................263.1.2.1 Risk Magnitude...............................................................................................................263.1.2.2 Impact..............................................................................................................................273.1.2.3 Mitigation strategy..........................................................................................................273.1.2.4 Contingency plan.............................................................................................................27

3.1.3 Initial overhead....................................................................................................................273.1.3.1 Risk Magnitude...............................................................................................................273.1.3.2 Impact..............................................................................................................................273.1.3.3 Mitigation strategy..........................................................................................................273.1.3.4 Contingency plan.............................................................................................................27

3.1.4 Reducing Business Challenges to Technology Solutions....................................................273.1.4.1 Risk Magnitude...............................................................................................................283.1.4.2 Impact..............................................................................................................................283.1.4.3 Mitigation strategy..........................................................................................................283.1.4.4 Contingency plan.............................................................................................................28

3.2 Risk Perspective: Governance..................................................................................................28

3.2.1 Lack of a formal governance model....................................................................................283.2.1.1 Risk Magnitude...............................................................................................................283.2.1.2 Impact..............................................................................................................................283.2.1.3 Mitigation strategy..........................................................................................................283.2.1.4 Contingency plan.............................................................................................................29

3.2.2 Software Development Life Cycle (SDLC) methodology remains unchanged....................293.2.2.1 Risk Magnitude...............................................................................................................293.2.2.2 Impact..............................................................................................................................293.2.2.3 Mitigation strategy..........................................................................................................29



4/18/2006VERSION 0.8

3.2.2.4 Contingency plan.............................................................................................................29

3.2.3 Unclear SOA Governance responsibilities..........................................................................293.2.3.1 Risk Magnitude...............................................................................................................293.2.3.2 Impact..............................................................................................................................303.2.3.3 Mitigation strategy..........................................................................................................303.2.3.4 Contingency plan.............................................................................................................30

3.2.4 Avoid organizational evolution...........................................................................................303.2.4.1 Risk Magnitude...............................................................................................................303.2.4.2 Impact..............................................................................................................................303.2.4.3 Mitigation strategy..........................................................................................................303.2.4.4 Contingency plan.............................................................................................................31

3.3 Risk Perspective: Architecture..................................................................................................31

3.3.1 Lack of SOA Reference Architecture...................................................................................313.3.1.1 Risk Magnitude...............................................................................................................313.3.1.2 Impact..............................................................................................................................313.3.1.3 Mitigation strategy..........................................................................................................313.3.1.4 Contingency plan.............................................................................................................31

3.3.2 Limited SOA Experience......................................................................................................313.3.2.1 Risk Magnitude...............................................................................................................313.3.2.2 Impact..............................................................................................................................313.3.2.3 Mitigation strategy..........................................................................................................323.3.2.4 Contingency plan.............................................................................................................32

3.3.3 No Common Domain Model................................................................................................323.3.3.1 Risk Magnitude...............................................................................................................323.3.3.2 Impact..............................................................................................................................323.3.3.3 Mitigation strategy..........................................................................................................323.3.3.4 Contingency plan.............................................................................................................32

3.4 Risk Perspective: Technology...................................................................................................32

3.4.1 Inadequate toolset to support SDLC...................................................................................323.4.1.1 Risk Magnitude...............................................................................................................323.4.1.2 Impact..............................................................................................................................333.4.1.3 Mitigation strategy..........................................................................................................333.4.1.4 Contingency plan.............................................................................................................33

3.4.2 Use of immature or competing Web services specifications...............................................333.4.2.1 Risk Magnitude...............................................................................................................333.4.2.2 Impact..............................................................................................................................333.4.2.3 Mitigation strategy..........................................................................................................333.4.2.4 Contingency plan.............................................................................................................33

3.4.3 Inadequate Support for End-to-End Message Security.......................................................343.4.3.1 Risk Magnitude...............................................................................................................34



4/18/2006VERSION 0.8

3.4.3.2 Impact..............................................................................................................................343.4.3.3 Mitigation strategy..........................................................................................................343.4.3.4 Contingency plan.............................................................................................................34

3.4.4 Inadequate SOA infrastructure............................................................................................343.4.4.1 Risk Magnitude...............................................................................................................343.4.4.2 Impact..............................................................................................................................353.4.4.3 Mitigation strategy..........................................................................................................353.4.4.4 Contingency plan.............................................................................................................35



4/18/2006VERSION 0.8

1 INTRODUCTION

1.1 PURPOSE

The purpose of this document is to present the findings of the “Initial Readiness and Risks Assessment” workshop; which allowed ISS to assess several key organizational and technology aspects that are essential to both mitigate risks and maximize opportunities for business benefits from a service-oriented architecture (SOA).

As a result, the assessment will help provide a better understanding of the current situation and, consequently, it will establish the basis for the development of a phased SOA adoption plan that delivers early, measurable, and incremental business benefits while avoiding major disruptions.

1.2 SCOPE

This document is associated with the VIEW™ (Vision Engineering Workshop) phase of the EBSOA project.

1.3 DEFINITIONS, ACRONYMS AND ABBREVIATIONS

SOA: Service-Oriented Architecture

ViEW™: Vision Engineering Workshop

SDLC: Software Development Life Cycle

1.4 REFERENCES

SOA Readiness Assessment Checklist

SOA Readiness Assessment – Scoring Instructions

SOA Maturity Model

SOA Adoption Roadmap



4/18/2006VERSION 0.8

2 READINESS ASSESSMENT

Please refer to “SOA Maturity Model” and “SOA Adoption Roadmap” documents to learn how to get to the next level of SOA maturity.

2.1 IOWA DEPARTMENT OF REVENUE

2.1.1 Summary

IDR - Current Level of Maturity

0

1

2

3

4

5

Subject Areas

Lev

el

Org. Governance

Tech. Governance

Organization

IT - Architecture

IT - Technology

2.1.2 Results details

Subject Areas

Related Questions Points No. of questions

Final Score

Organizational Governance

3.4 Strategy 02.2 SOA Governance 02.9 Organizational Alignment 0

2.10 Metrics 02.11 Cost 0



4/18/2006VERSION 0.8

0 5 0Technology Governance

2.3.1 Methodology 02.3.2 Software Development Processes

1

2.3.3 Modeling Techniques 01 3 0.33

Organization3.1 Benefits 03.2 Business Sponsorship 03.3 Business Processes 03.5 SOA Awareness 03.6 Large- Scale Business Initiatives

0

2.12 Large- Scale IT Initiatives 00 2 0

IT - Architecture

2.1 Benefits 02.4 Architecture

2.4.1 General 02.4.2 SOA Reference

Architecture0

2.6 Application Portfolio 12.7 Skills

2.7.1 Understanding Of SOA

0

2.7.2 SOA Experience 02.8 Common Domain Model (Data)

1

2 6 0.33IT - Technology

2.3.4 Tool Usage 02.4 Architecture

2.4.3 Security 02.4.4 Quality Of Service 0

2.5 Infrastructure Services 22 4 0.5



4/18/2006VERSION 0.8

2.2 IOWA WORKFORCE DEVELOPMENT

2.2.1 Summary

IWD - Current Level of Maturity

0

1

2

3

4

5

Subject Areas

Lev

el

Org. Governance

Tech. Governance

Organization

IT - Architecture

IT - Technology


Subject Areas


Final Score






0

2.3.3 Modeling Techniques 0



4/18/2006VERSION 0.8

1 3 0.33Organization

3.1 Benefits 03.2 Business Sponsorship 03.3 Business Processes 03.5 SOA Awareness 03.6 Large- Scale Business Initiatives

0


IT - Architecture



Architecture0



0


0







4/18/2006VERSION 0.8

2.3 DEPARTMENT OF HUMAN SERVICES

2.3.1 Summary

DHS - Current Level of Maturity

0

1

2

3

4

5

Subject Areas

Lev

el

Org. Governance

Tech. Governance

Organization

IT - Architecture

IT - Technology


Subject Areas


Final Score






2




4/18/2006VERSION 0.8



0

2.12 Large- Scale IT Initiatives 01 2 0.5

IT - Architecture



Architecture0



0


0

0 6 0IT - Technology






4/18/2006VERSION 0.8

2.4 DEPARTMENT OF TRANSPORTATION

2.4.1 Summary

DOT - Current Level of Maturity

0

1

2

3

4

5

Subject Areas

Lev

el

Org. Governance

Tech. Governance

Organization

IT - Architecture

IT - Technology


Subject Areas


Final Score




2 5 0.4Technology Governance


2




4/18/2006VERSION 0.8



0

2.12 Large- Scale IT Initiatives1 2 0.5

IT - Architecture



Architecture0



1


0




2.5 Infrastructure Services 14 4 1



4/18/2006VERSION 0.8

2.5 IOWA VETERANS HOME

2.5.1 Summary

IVH - Current Level of Maturity

0

1

2

3

4

5

Subject Areas

Lev

el

Org. Governance

Tech. Governance

Organization

IT - Architecture

IT - Technology


Subject Areas


Final Score






0




4/18/2006VERSION 0.8

0 3 0Organization


0


IT - Architecture



Architecture1



0


0







4/18/2006VERSION 0.8

2.6 IOWA VOCATIONAL REHABILITATION SERVICES

2.6.1 Summary

IVRS - Current Level of Maturity

0

1

2

3

4

5

Subject Areas

Lev

el

Org. Governance

Tech. Governance

Organization

IT - Architecture

IT - Technology


Subject Areas


Final Score






2



4/18/2006VERSION 0.8

2.3.3 Modeling Techniques 02 3 0.66

Organization3.1 Benefits 03.2 Business Sponsorship 03.3 Business Processes 03.5 SOA Awareness 13.6 Large- Scale Business Initiatives

0


IT - Architecture



Architecture0



1


1







4/18/2006VERSION 0.8

2.7 DEPARTMENT OF NATURAL RESOURCES

2.7.1 Summary

DNR - Current Level of Maturity

0

1

2

3

4

5

Subject Areas

Lev

el

Org. Governance

Tech. Governance

Organization

IT - Architecture

IT - Technology


Subject Areas


Final Score






0




4/18/2006VERSION 0.8

0 3 0Organization


0


IT - Architecture



Architecture0



1


1







4/18/2006VERSION 0.8

2.8 DEPARTMENT OF PUBLIC HEALTH

2.8.1 Summary

IDPH - Current Level of Maturity

0

1

2

3

4

5

Subject Areas

Lev

el

Org. Governance

Tech. Governance

Organization

IT - Architecture

IT - Technology


Subject Areas


Final Score






3




4/18/2006VERSION 0.8

3 3 1Organization


0


IT - Architecture



Architecture0



2


3




2.5 Infrastructure Services 14 4 1



4/18/2006VERSION 0.8

2.9 DEPARTMENT OF ADMINISTRATIVE SERVICES

2.9.1 Summary

DAS - Current Level of Maturity

0

1

2

3

4

5

Subject Areas

Lev

el

Org. Governance

Tech. Governance

Organization

IT - Architecture

IT - Technology


Subject Areas


Final Score




3 5Technology Governance


1

2.3.3 Modeling Techniques



4/18/2006VERSION 0.8

1 3Organization


0

2.12 Large- Scale IT Initiatives 01 2

IT - Architecture



Architecture0



1


0

4 6IT - Technology



2.5 Infrastructure Services 00 4



4/18/2006VERSION 0.8

3 RISKS ASSESSMENT

3.1 RISK PERSPECTIVE: ORGANIZATION

3.1.1 Lack of business involvement

SOA is not primarily about technology; therefore, ensuring business involvement is crucial from the very beginning. Projects should be driven by business needs and should yield measurable business benefits.

3.1.1.1 Risk Magnitude

Likelihood that the risk will occur: High

Impact of the risk should it occur: High

3.1.1.2 Impact

The organization may need to cope with open or concealed opposition due to the fact that not every employee might welcome the introduction of SOA.

3.1.1.3 Mitigation strategy

Develop a formal SOA Program Charter with strong executive sponsorship and objectives in business terms

Create a target Return on Investment (ROI) because the SOA benefits need to be quantified

Transition to SOA iteratively adding services based on business value and utility of function building the services library over time

3.1.1.4 Contingency plan

Proper coaching and evangelization are good ways to overcome the lack of business involvement. If the key problem is the fear of losing influence and/or control, it could be helpful to integrate people into the SOA processes and give them appropriate responsibility to contribute to the SOA success.

3.1.2 SOA is still evolving

SOA is still evolving with the continuing maturation of standards, new software offerings and software vendor merger and acquisitions






4/18/2006VERSION 0.8

3.1.2.2 Impact

Early adopters might not get the right balance between near-term business impact and long-term architectural direction


Develop an SOA strategy and roadmap based on business value, risk, business process effectiveness, and IT assets to be leveraged

Start small; choose a pilot project that represents low-risk and is highly visible

Get buy-in from the right people in your organization


If needed, the organization may need to amend and change its SOA strategy.

3.1.3 Initial overhead

In its initial phase, the introduction of an SOA creates overheads caused by different factors such as efforts required to increase reusability and employees will need to familiarize with new processes.


Likelihood that the risk will occur: Medium


3.1.3.2 Impact

Some departments might have problems providing the resources needed to account for the reusability overhead.


Start small; choose a pilot project that represents low-risk and is highly visible

Allocate sufficient budget to compensate for initial overheads


It is important to communicate to people that the initial overhead in creating reusable services can be recouped as soon as other applications are assembled out of reusable services.

3.1.4 Reducing Business Challenges to Technology Solutions

Some organizations attempt to solve business or organizational problems with some technological silver bullet.



4/18/2006VERSION 0.8




3.1.4.2 Impact

By reducing a business challenge to a technology solution, often the real challenge remains left behind, and the organization is saddled with yet another layer of technology.


Conduct SOA business modeling, which is the process by which an SOA initiative is pursued within the business and strategic context of an organization


To ensure success, find a clear business context for SOA projects and factor it into the project planning stages.

3.2 RISK PERSPECTIVE: GOVERNANCE

3.2.1 Lack of a formal governance model

SOA Governance is an evolution of the ideas of IT governance, introducing a greater business involvement in supporting IT service components.




3.2.1.2 Impact

There can be potential issues associated with engaging on an SOA initiative without a corresponding governance model such as process disruptions, lack of reuse, non-compliance, information access failures, security breeches, escalations in help desk and rise of field supports costs.


Develop an SOA strategy and roadmap based on business value, risk, business process effectiveness, and IT assets to be leveraged

Define the SOA governance model (organization, roles and responsibilities, processes, policies and metrics) in an iterative manner



4/18/2006VERSION 0.8

Establish an enforcement mechanism that allows management to ensure that services comply with business policies, technology and application standards

Create an SOA Core Team that can assume multiple responsibilities until a formalized SOA organizational model is established


Governance is the mechanism by which an organization makes and enforces decisions. Therefore, the basis for a governance model exists but it needs to be further developed, formalized, communicated and enforced

3.2.2 Software Development Life Cycle (SDLC) methodology remains unchanged

The SDLC methodology requires changes due to complex system dependencies, SOA specific design patterns, and the change impact to the infrastructure and users




3.2.2.2 Impact

Only new labels are used to deliver new business solutions without taking into accounts important SOA constructs such as service reuse, categorization, composition, brokering and policies.


Examine the current methodology in use and adjust for SOA by building upon OOAD (Object-Oriented Analysis and Design), EA (Enterprise Architecture) and BPM (Business Process Management) foundations and enriching them with SOA workflows, patterns and deliverables


Make the improvement of the current SDLC a high priority; and, assign experienced resources to help deliver the solution and realize its benefits.

3.2.3 Unclear SOA Governance responsibilities

Common enterprise services must have defined owners with established governance responsibilities.






4/18/2006VERSION 0.8

3.2.3.2 Impact

Failure of SOA initiatives as there is no common understanding of who sets the SOA strategy, manages risks, allocates resources, ensures delivery of value, and measures performance.


Formalize an SOA governance organizational structure

Identify roles, responsibilities, skills, owners and other members

Ensure strong support of senior executives and proper empowerment of the SOA governance body


Create an SOA Core Team that can assume multiple responsibilities until a formalized SOA organizational model is established.

3.2.4 Avoid organizational evolution

To move to SOA requires organizational changes across business units and IT. Often, employees have to work with people they may not have worked with much before.




3.2.4.2 Impact

Silos are counterproductive to implementing SOA. Services must be designed to support the enterprise in order to achieve the stated benefits, which will only work if the entire organization reaches a consensus on the functionality offered by each service. Organizational silos have a difficult time reaching a consensus and the single-use nature of the software they design is contrary to the paradigm of SOA.


Incrementally define domains, which are managed sets of services sharing some common business context. In many cases these sets of services are business services, such as customer information, order processing, etc

Assign domain owners, who manage the direction of the domain and the business relationships between the domain and business units, as well as other domains. Domain owners also help business process owners in other business units understand the business application of the services within the domain



4/18/2006VERSION 0.8


Start small: choose a well-scoped and focused SOA project that has a modest plan for organizational evolution.

3.3 RISK PERSPECTIVE: ARCHITECTURE

3.3.1 Lack of SOA Reference Architecture

The SOA Reference Architecture is an architectural design pattern that identifies critical components and how their relationships realize a predetermined set of requirements.




3.3.1.2 Impact

Without an SOA Reference Architecture, organizations will find it hard to build services that are consistent, reusable, high-quality, and interoperable.


Developing an SOA Reference Architecture is one of the first steps in adopting SOA


Get expert guidance to formalize an SOA Reference Architecture and revise existing services, if possible.

3.3.2 Limited SOA Experience

SOA is the latest paradigm impacting people, processes and technologies and is still evolving. Resources with the desired experience might be in short supply.




3.3.2.2 Impact

Embarking on SOA initiatives without the proper knowledge may jeopardize the success of the solution as well as its quality, deadline, and cost; due to the limited ability to estimate and execute projects of this nature.



4/18/2006VERSION 0.8


Provide a comprehensive training program for business and technology professionals

Ensure access to SOA mentors that have worked on SOA initiatives before


Get expert guidance to make successful your SOA initiatives currently underway.

3.3.3 No Common Domain Model

A challenge for enterprise-wide SOA is establishing the enterprise common format for business objects that will be exchanged among services.




3.3.3.2 Impact

The lack of a Common Domain Model can result in the proliferation of business objects that are likely to change as more services are included.


Develop a Common Domain Model and iteratively add business objects as more services are added to the enterprise SOA


Service providers and consumers will need to determine, on a “case by case” basis, whether or not it makes sense to change the information model of services created when no Common Domain Model existed.

3.4 RISK PERSPECTIVE: TECHNOLOGY

3.4.1 Inadequate toolset to support SDLC

Due to the fact that SOA incorporates new disciplines and spans system boundaries, current SDLC tools are not enough to address the new challenges that SOA initiatives pose to the IT organization.






4/18/2006VERSION 0.8

3.4.1.2 Impact

SDLC workflows such as service analysis, design, development, quality assurance, packaging and deployment become more difficult since services are distributed, have many interfaces, require new testing environments, and message-based testing tools.


Utilize extensible tools that enable modeling, development, testing, configuration, and deployment of software designed around SOA


SOA is supposed to bring flexibility and agility to the business; the same should be expected from its supporting method. Therefore, it is important to identify SDLC automation requirements and acquire tools (commercial or free-of-charge) that will increase productivity and ensure quality.

3.4.2 Use of immature or competing Web services specifications

The number of Web Services specifications and the mixed signals coming from industry due to immature or competing specifications in similar areas can leave organizations with an impression that there is no single clear vision for Web Services technologies.




3.4.2.2 Impact

An unplanned, broad adoption of Web services opens companies to uncertainty and even potential anarchy.


SOA Governance Model needs to describe policies and enforcement mechanisms relative to the use of Web Services specifications


It is necessary to correct this situation as soon as possible because there could be serious consequences. If a specification is chosen too early in its lifecycle, then SOA teams may suffer from lack of tool support as well as instability due to changes incurred as the specification evolves through a standardization process. In the worst case, a specification may never be widely adopted, and so will over time become obsolete, adversely impacting any services that chose to adopt it.



4/18/2006VERSION 0.8

3.4.3 Inadequate Support for End-to-End Message Security

End-to-end message security entails: origin authentication, integrity and confidentiality. Origin authentication is about identifying a service consumer securely. Integrity means prevents a message from being altered. Confidentiality consists of ensuring that only the intended consumer of information is able to view it.




3.4.3.2 Impact

Inadequate message security makes any solution more vulnerable to security attacks including but not limited to altering messages or attachments, sending fake messages, downgrading the level of cryptography used to secure the message and starting a denial-of-service attack.

Security problems such as those described above may lead to non-compliance sanctions.


Adopt mature security specifications that allow for authentication, authorization, message integrity and confidentiality; and incorporate them into the SOA Technology Governance policies

SOA team must have adequate training in security

Conduct extensive testing

Audit periodically systems and procedures to operate them


Make the service unavailable as soon as this risk materializes and analyze the potential security threat. Then, make sure that the network is configured properly and that operating systems and middleware have the latest security patches and are free of viruses. Revisit the security requirements of the service and implement them following the agency’s security standards and policies

3.4.4 Inadequate SOA infrastructure

Current IT architecture is the result of years of business decisions and technology choices, which resulted in a highly heterogeneous environment including legacy systems, commercial applications, and custom-built applications on diverse platforms and operating systems.






4/18/2006VERSION 0.8

3.4.4.2 Impact

An inadequate SOA platform might present the following disadvantages: unreliable, inability to meet service level agreements (SLAs) and scalability requirements, difficult to manage and monitor, expensive to maintain due to multiple point-to-point solutions, infrastructure code is embedded into services, among others.


Plan and incrementally implement an SOA platform that provides infrastructure services including but not limited to:

o Standard-based transport (SOAP, HTTP/S, .NET, JMS, JCA, among others)

o Mediation (loosely-coupling, intelligent routing, transformation, validation, logging, policy management)

o Quality of service (availability, reliability, performance, security and regulatory capabilities)

Extend SOA Governance Model with procedures, policies and best practices relative to SOA infrastructure

Involve operations support early and deploy monitoring and management tools for the SOA infrastructure

Funding for the infrastructure that will support shared services should come from across the organization


Getting to a suitable SOA infrastructure may seem like a daunting task. Adopting an SOA is not an all-or-nothing, rip-and-replace approach. Rather, an organization can adopt it incrementally while still continuing to leverage existing assets. Bridging to existing middleware can occur in several ways, for instance: by using a Web Service interface, or by binding together the underlying messaging channels.


Documents

Initial Readiness and Risks Assessment