ServiceTechMag.com > Issue LI: June 2011 > Mapping Service-Orientation to TOGAF 9 - Part I.V: Methodology, Processes, Steps, Principles
Fillipos Santas

Filippos Santas

Biography

Filippos is an IT Architect for Credit Suisse Private Banking in Switzerland and a SOASchool.com Certified SOA Trainer, Analyst, Architect, Consultant, and Security Specialist. Additionally, he is certified by The Open Group on TOGAF 9 and by IBM on the Rational Unified Process V7.0. In the last 10 years, Filippos has been the lead for the analysis and architecture of a number of successful SOA projects and for transforming legacy architectures to service-oriented architectures, primarily in the financial sector. His achievements include the conceptual and physical design of the international insurance claims service network that connects insurance policies, customer companies and state authorities in 44 countries across the globe, combining legislation, business processes, business rules, business objects, knowledge bases and different platforms.

Filippos recent work with Credit Suisse has been as an SOA Architect, combining the profitable and established functionality of legacy systems with centralized business process services, decentralized business rule services, domain specific BOMs and entity services and end-to-end traceability to business requirements and processes.

Contributions

rss  subscribe to this author

Bookmarks



Mapping Service-Orientation to TOGAF 9 - Part II:
Architecture Adoption, Service Inventories and Hierarchies

Published: June 17, 2011 • Service Technology Magazine Issue LI PDF
 

This is second part in a multi-part article series. The first part is published at Mapping Service-Orientation to TOGAF 9 - Part I: Methodology, Processes, Steps, Principles.


Abstract

In this series of articles we examine the correspondence and synergies of Service Orientation and The Open Group Architecture Framework. In part I of this article (http://www.soamag.com/I50/0511-1.php) we went through the phases related to architecture definition and service design and implementation. In this article we examine the mapping for stages related to architecture adoption and vision, the main roles, and the implementation of multiple service inventories using hierarchies of the TOGAF ADM. We conclude the second article with the synergies between the two methodologies. In this article when we refer to SOA we mean Service-Orientated Architecture.


Architecture Adoption and Project Establishment

Activities and factors related to the SOA Adoption Planning are typically examined during the Project Establishment iteration in TOGAF. This iteration consists of the Preliminary Phase and Phase A: Architecture Vision (Table 1). The architectural inputs and objectives of these phases fit well with the objectives of the SOA Adoption Planning (Figure 1). For example, the inputs of the Preliminary Phase include:

  • scope of organizations impacted
  • maturity assessment, gaps, and resolution approach
  • roles and responsibilities for architecture team(s)
  • budget requirements
  • governance and support strategy
  • existing Architecture Framework, if any, including:
    • architecture method
    • architecture content (deliverables and artifacts)
    • configured and deployed tools
  • Architecture Principles
  • Architecture Repository

The above correspond to the inputs of the SOA projects. SOA provides explicit definitions and models for each of the above elements.

Notice that the architecture principles are defined in the Preliminary Phase in TOGAF and in the SOA Adoption Planning in SOA. That is, all principles of service-orientation have to be included in the framework during the Preliminary Phase.




Figure 1 – Correspondence of Service Adoption Planning and TOGAF Preliminary and Architecture Vision



Figure 2 – Additional input to TOGAF Preliminary and Architecture Vision Phases for SOA



Figure 3 – Additional input to SOA Service Adoption Planning from TOGAF.


Project Establishment
The Preliminary Phase describes the preparation and initiation activities required to prepare to meet the business directive for new enterprise architecture, including the definition of an Organization-Specific Architecture framework and the definition of principles.
Phase A: Architecture Vision describes the initial phase of an architecture development cycle. It includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals.


Table 1 – ADM Phases and Iterations in TOGAF


Gaps and suggestions from the two methodologies are provided in figures 2 and 3. In particular,

  • TOGAF supports SOA better if:
    • all the SOA principles are included before the architecture cycle starts
    • the SOA maturity models are examined
    • the elements of the SOA Governance are adopted
    • SOA Training is offered and is mandatory in the organization
  • SOA benefits from TOGAF if it adopts:
    • the concept of Architecture Vision,
    • the technique of Stakeholder Map for identifying and managing stakeholder needs
    • the SMART business scenarios identified in the previous section

Iteration in SOA and ADM

The ADM supports the concept of iteration at three levels:

  • cycling around the ADM
  • iterating between related phases
  • cycling around a single phase

Common iterations in SOA involve:

  • the Service Inventory Analysis and
  • the application of service-orientation iteratively for each Process examined during Service Analysis. Notice that these iterations can be performed within one single service delivery project.

The Service Inventory Analysis Iteration corresponds to the TOGAF Architecture Definition Iteration as we have shown earlier. The Iterative application of Service Orientation during individual service analysis and design corresponds to Transition Planning and Architecture Governance iterations in TOGAF.

Once all the phases of SOA have been completed, it is possible to start a new SOA project: this corresponds to the start of a new ADM cycle. Notice that SOA allows for Service Inventory Analysis to be performed in parallel to Service Delivery.


SOA Pillar
Description
Teamwork Cross-project and cross-functional teams and cooperation are required.
Education Team members must communicate and cooperate based on common knowledge (common vocabulary, definitions, concepts, methods) and understanding of the target state the team is collectively working to attain.

The role Educator is crucial in transferring knowledge of SOA Principles.
Discipline Consistent application of common knowledge by teams and their members
Balanced Scope Establish teamwork, education, and discipline within a meaningful and manageable scope.

Table 2 – The four SOA Pillars


SOA Pillar
TOGAF Support
Teamwork Principle 3: Information Management is Everybody's Business: All organizations in the enterprise participate in information management decisions needed to accomplish business objectives.

Rationale: [...] The business experts from across the enterprise and the technical staff [...] need to come together as a team to jointly define the goals and objectives of IT.

Implications: (a) To operate as a team, every stakeholder, or customer, will need to accept responsibility for developing the information environment. (b) Commitment of resources will be required
Education
(role: Educator)
(a)Worldwide forum for Architecture practitioners (b) Network with peers and industry experts (c) Help further development of Enterprise Architecture as a discipline and a profession (d) A growing number of vendors support TOGAF with methods, tools, education and certification
Discipline Principle 1: Primacy of Principles: The principles of information management apply to all organizations within the enterprise.

Rationale: The only way we can provide a consistent and measurable level of quality information to decision-makers is if all organizations abide by the principles.

Implications: (a) Without this principle, exclusions, favoritism, and inconsistency would rapidly undermine the management of information. (b) Information management initiatives will not begin until they are examined for compliance with the principles. (c) A conflict with a principle will be resolved by changing the framework of the initiative.
Balanced Scope Core: TOGAF is tailorable

Principle 7: IT Responsibility: The IT organization is responsible for owning and implementing IT processes and infrastructure that enable solutions to meet user-defined requirements for functionality, service levels, cost, and delivery timing.

Table 3 – How TOGAF supports the four pillars of service-orientation.


The Pillars of Service-Orientation and the TOGAF Principles

The four pillars of service-orientation (introduced in Chapter 4 of SOA Governance) are summarized in Table 2. These, as the name suggests, are crucial for the success of any SOA project. TOGAF supports the pillars of service-orientation with a set of recommended Principles (Table 3). TOGAF can be extended by additional educational material for architecture with:

  • the eight service-orientation principles (see appendix for the SOA principles not supported by TOGAF),
  • patterns that address service analysis and service design, and
  • precepts and processes specific to shared service governance.

Service Inventory Analysis
Service-Orientation Role
Recommended TOGAF Skill / Expert
Primary TOGAF Artifacts
Define Enterprise Business Models Business Analyst EA Application
EA Business
EA Manager
Baseline / Target Business Architecture
Define Technology Architecture Service Architect EA Technology
EA Manager
Baseline / Target Technology Architecture
Define Service Inventory Blueprint Service Analyst EA Data
EA Application
EA Technology
EA Business
EA Manager
Baseline / Target Application, Data, Technology
Architecture
Perform Service-Oriented Analysis Service Analyst EA Application
EA Technology
EA Manager
 

Table 4 – Mapping Service Inventory Analysis processes and responsible roles to Architecture Definition expertise levels and artifacts.


Enterprise Roles

Parallel to the traditional service delivery roles, Service-Orientation introduces:

  • Four enterprise or domain level custodian roles: Schema Custodian, Policy Custodian, Service Registry Custodian, Enterprise Design Standards Custodian (and Auditor). These roles are active mainly during the Service-Oriented Design, Service Logic Design, Service Deployment and Maintenance, and Service Versioning and Retirement stages. These correspond mainly to the TOGAF Phases G and H.
  • One generic enterprise architecture role Enterprise Architect. This role is present in just about all stages of an SOA delivery project, but the only project-specific artifact directly produced is the inventory blueprint. Similarly, TOGAF places the EA role present in all phases, but essential in the phases B, C and D when the Architecture is developed.
  • Two service management roles: Service Custodian, Service Administrator
  • One general governance role: SOA Governance Specialist
  • One general Service Security Specialist.

The responsibility of the above roles includes the definition of standards and participation in reviews.

The Enterprise Architect and the Security Architect (Service Security Specialist) are present in both SOA and TOGAF. TOGAF's support for SOA benefits from the introduction of the other roles.

For the definition of the Service Inventory, SOA assumes three main roles (Business Analyst, Service Analyst, and Service Architect). TOGAF does not define explicit roles responsible for the Architecture Definition, but recommends a set of competencies and skills for the responsible architects and analysts (Table 4).

To conclude with the roles overview, SOA introduces the concept of the SOA Governance Program Office (SGPO), which has a scope well beyond that of the Architecture Board established in TOGAF. We will examine this in more detail in this series, related to Governance in SOA and TOGAF.


Service Inventory Analysis and Implementation of Services

In a previous work [REF-5] we presented an approach where the Service Inventory Analysis Phase is part of a Service Delivery Project. Assuming that the Rational Unified Process (RUP) is employed for the service delivery, we put the Service Inventory Analysis in the Inception Phase (Table 5), performed by the roles of:

  • The Business Architecture, developed in Phase B: Business Architecture, defines the business strategy, governance, organization, and key business processes.
  • Business Process Analyst,
  • The Application Architecture, developed also in Phase C: Information Systems Architectures, provides a blueprint for the application systems to be deployed, their interactions, and their relationships to the organization's core business processes.
  • System Analyst, and
  • Software Architect

Furthermore we argued that main deliverables of the RUP Inception Phase (Use Case Model, Vision, and Object Model) correspond to the modeling of service candidates in the Service Inventory Blueprint.

In the current presentation we argued that the Service Inventory Blueprint is delivered before the start of the service delivery projects and we demonstrated this by mapping:

a) the service inventory analysis to the architecture definition phases B, C and D
b) the service delivery phases to the phases F and G

Which mapping is correct? The mapping to RUP, or the mapping to TOGAF? Both mappings are correct but they model two different process areas.

For (a) see previous sections.

Concerning (b), we note that the analysis of each individual service belongs to the project delivery phases. However, Service-Orientation allows for each iteration of the Service-Oriented Analysis to contribute to the Service Inventory Blueprint. That is, we allow for service inventory analysis and modification of the blueprint to be performed within each service delivery project. Notice that during service analysis we may analyze and model services across all SOA service models (utility, entity, task, process), corresponding to the four TOGAF architecture domains.

TOGAF defines an explicit Phase where governance of such architecture changes occurs: Phase H: Architecture Change Management.

Table 6 shows how Service Inventory Analysis is performed iteratively in the Inception Phase of a RUP project.


Iteration 1
 
 
Iteration 2
 
Business Modeling (1)

Analysis and Design (1)

Requirement (1)
 
Business Modeling (2)

Analysis and Design (2)

Requirement (2)

Table 5 – Service Inventory Analysis in RUP Inception Iterations


Multiple Service Inventories

SOA specifies that in order to reduce the complexity of one inventory for the whole organization and reduce the risks of transition to SOA, the enterprise can be divided in a small set of business or geographic domains, each one with its own service inventory. Then service-orientation can be applied to services within each inventory, but not across. SOA itself does not provide an explicit architecture cycle to establish these domains.

TOGAF's ADM can be employed to do exactly this. TOGAF allows for hierarchies of ADM cycles, The Implementation and Governance of one cycle at one level within an enterprise may initiate a set of other cycles in lower levels of the enterprise.

The order of hierarchies and the mapping to SOA is shown in the figures 4 to 8




Figure 4 – Definition of Business/Geographic/Organizational Domains in ADM



Figure 5 – Implementation & Governance of Business/Geographic/Organizational Domains in ADM



Figure 6 – Analysis of each Service Inventory in a second layer in ADM



Figure 7 – Analysis and Design of Services in each Service Inventory



Figure 8 – Application of service-orientation in each Process or Service.

Service-Orientation and TOGAF: Gaps

As a result of the mapping described in the previous sections, some notable gaps have been identified:


Phase E: Transition Planning

SOA Governance relates the service inventory blueprint to:

  • the project delivery effort and
  • the corresponding SOA governance effort.

However it does not define any specific process or process step on how to achieve this. That is, service-orientation does not provide explicit phases for Planning the Migration of the architecture and does not define explicit roadmaps to deliver the defined service inventory.

TOGAF provides such phase: Phase E: Opportunities and Solutions. In this phase an Architecture Roadmap is defined for implementing the defined architecture via increments. Phase E in TOGAF follows immediately after the Architecture Definition phases B, C and D and is part of the Architecture Definition iteration.

In the previous sections we mapped the TOGAF Architecture Definition Iteration to the SOA Service Inventory Analysis. It is therefore intuitive to extend the SOA Inventory Analysis with one additional step that corresponds to Phase E. In this way, the definition of the Inventory will provide the definition of an Inventory Roadmap.


Phase H: Architecture Change Management

TOGAF establishes procedures for managing change in the architecture in Phase H: Architecture Change Management. These changes can be the result of

  • the implementation of the architecture in previous phases, or
  • monitoring or
  • other change requests.

Architecture change requests result in a new cycle of the ADM.

A service implementation in SOA may

  • result in changes to existing service logic or
  • increase the functional scope of the service.

Changes can happen also in technology or business processes due to reasons external to the organization. The above may result in changes and change requests in the inventory blueprint or even in the architecture standards. All these are changes in the architecture.

SOA Governance deals very well with changes and change requests in the SLAs and services themselves (e.g. in Service Versioning and Retirement and also in Service Discovery) by prescribing principles and patterns that allow for loose coupling or coupling via service contracts. Furthermore, SOA allows for changes in the service inventory to occur during a service delivery project, in particular during the meet in the middle approach (Figure 9).

The extension of SOA with Architecture Governance in the sense of TOGAF can be done in several ways, such as:

1)  Introduce an explicit Governance Phase in SOA as part of the service delivery phases, or
2)  Include Governance Steps in each service delivery phase, or
3)  Introduce an explicit Governance for SOA which impacts all phases [REF-4]


We will examine this issue with alternatives in more detail in the 2nd article of this mapping that is related to Governance.



Figure 9 – The meet in the middle approach in service-orientation


TOGAF Phases
SOA Phase to be Extended
Transition Planning
 
Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases

Who: Enterprise Architects
Business Modeling (1)
Architecture Governance  
Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.

Who: Architecture Board
Recommendation: New Phase in Service Delivery

Recommendation: Activity in every Phase

Who:

SOA Governance Program Office

Service Administrator

Enterprise Design Standards Custodian

Schema Custodian

Policy Custodian

SOA Governance Specialist


Table 6 – Possible extensions in SOA to support Steps of TOGAF


Service Delivery Phases

As we mentioned in a previous section, TOGAF does not define any specific steps for the projects implementing the architecture, it only defines two generic phases F and G. In this area there is tremendous potential in using directly the processes, principles and patterns as defined for:

  • Service-Oriented Analysis (Service Modeling)
  • Service-Oriented Design (Service Contract)
  • Service Logic Design
  • Service Development
  • Service Testing
  • Service Deployment and Maintenance
  • Service Usage and Monitoring

Mapping of Service-Orientation Design Principles to the 21 TOGAF Recommended
Architecture Principles


TOGAF borrows many principles from work done by the US Air Force (Headquarters Air Force Principles for Information Management, June 29, 1998). These are classified in three kinds: Enterprise Principles, IT Principles and Architecture Principles.

Service-Orientation provides a standard set of eight design principles all of which contribute to the seven strategic goals of service-orientation. All eight principles are applied in each step of Service Inventory Analysis, Service Analysis and Service Design.

All SOA principles govern the implementation of the architecture into services.


SOA Principle
TOGAF Recommended Principles
Standardized Service Contract  
Service Loose Coupling  
Service Abstraction  
Service Reusability Business 2: Maximize Benefit to the Enterprise. Implication: Sharing of Applications across the enterprise.

Business: 5: Common Use Applications: Development of applications used across the enterprise is preferred over the development of similar or duplicative applications which are only provided to a particular organization.

Data: 11: Data is Shared

Data: 12: Data is Accessible: Data is accessible for users to perform their functions.
Service Autonomy Business: 4: Business Continuity. Redundancy or Alternative Capabilities are some of the Implications considered at Design Time.
Service Statelessness  
Service Discoverability  
Service Composability Business: 5: Common Use Applications. Implication is the standardization of enterprise-wide capabilities

Business: 6: Service-Orientation. Implications: Service Orchestration, Interoperability, Location Transparency


Table 7 – Mapping SOA Principles to TOGAF Principles



SOA Strategic Goals
TOGAF Recommended Principles
Increased Intrinsic Interoperability

corresponds to Information and Technical Interoperability in TOGAF. Business Interoperability is not a concern

Corresponds to Degree 3B: Common Data Exchange
Business 6: Service-Orientation

Technology: 21: Interoperability

Business Information Interoperability Matrix
•  Business Interoperability: how business processes are to be shared.
•  Information Interoperability: how information is to be shared.
•  Technical Interoperability: how technical services are to be shared or connect to one another
Increased Federation Data: 8: IT Responsibility

Data: 10: Data is an Asset: Data is an asset that has value to the enterprise and is managed accordingly.

Data: 11: Data is Shared: Users have access to the data necessary to perform their duties; therefore, data is shared across enterprise functions and organizations.
Increased Vendor Diversification Options Application: 16: Technology Independence

Technology: 20: Control Technical Diversity
Increased Business and Technology Domain Alignment Technology: 18: Requirements-Based Change: Only in response to business needs are changes to applications and technology made.
Increased ROI Business 2: Maximize Benefit to the Enterprise
Increased Organizational Agility Technology: 19: Responsive Change Management
Reduced IT Burden Data: 8: IT Responsibility

Application: 16: Ease-of-Use: Applications are easy to use


Table 8 – Mapping SOA Strategic Goals to TOGAF Principles and Artifacts



SOA Pillars & Roles
TOGAF Recommended Principles
Pillars of Service-Orientation Business: 1: Primacy of Principles
Pillars of Service-Orientation Business: 3: Information Management is Everybody's Business
Pillars of Service-Orientation

Role: Business Analyst
Data: 14: Common Vocabulary and Data Definitions
Role: SOA Security Specialist

Governance: Security Control Precepts

Design: Security Patterns
Data: 15: Data Security
Role: Service Custodian Data: 13: Data Trustee: Each data element has a trustee accountable for data quality.


Table 9 – Mapping SOA Pillars & Roles to TOGAF Principles (whenever applicable)



SOA (not mapped)
TOGAF Recommended Principles
  Business: 9: Protection of Intellectual Property: The enterprise's Intellectual Property (IP) must be protected. This protection must be reflected in the IT architecture, implementation, and governance processes.
  Business: 7: Compliance with Law


Table 10 – Unmapped TOGAF Principles



Description of TOGAF Phases and Iterations in ADM (see [REF-6])


Project Establishment
The The Preliminary Phase describes the preparation and initiation activities required to prepare to meet the business directive for new enterprise architecture, including the definition of an Organization-Specific Architecture framework and the definition of principles.
Phase A: Architecture Vision describes the initial phase of an architecture development cycle. It includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals.
Architecture Definition
Phase B: Business Architecture describes the development of a Business Architecture to support an agreed Architecture Vision.
Phase C: Information Systems Architectures describes the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures.
Phase D: Technology Architecture describes the development of the Technology Architecture for an architecture project.
Transition Planning
Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases
Phase F: Migration Planning addresses the formulation of a set of detailed sequence of transition architectures with a supporting Implementation and Migration Plan.
Architecture Governance
Phase G: Implementation Governance provides an architectural oversight of the implementation.
Phase H: Architecture Change Management establishes procedures for managing change to the new architecture.
Requirements Management examines the process of managing architecture requirements throughout the ADM.


Table 11 – ADM Phases and Iterations in TOGAF



Extended Mapping of SOA Phases to TOGAF ADM Phases


SOA Phases
TOGAF ADM Phases
SOA Adoption Planning Project Establishment:

Preliminary

A: Architecture Vision
Service Inventory Analysis

Business Modeling

Technology Architecture

Inventory Blueprint

Service-Oriented Analysis
Architecture Definition:

B: Business Architecture

C: Information Systems Architectures

•   Data Architecture

•   Application Architecture

D: Technology Architecture

Transition Planning

E: Opportunities & Solutions
Service Delivery and Governance

Service-Oriented Analysis (Service Modeling)

Service-Oriented Design (Service Contract)

Service Logic Design

Service Development

Service Testing

Service Deployment and Maintenance

Service Usage and Monitoring

Service Discovery

Service Versioning and Retirement
Transition Planning

F: Migration Planning

Governance

G: Implementation Governance
  Governance

H: Architecture Change Management

Requirements Management


Table 12 – Mapping SOA Phases and ADM Phases & Iterations in TOGAF



Degree 1
Unstructured Data Exchange: e.g. free text
Degree 2
Structured Data Exchange: structured data for manual or automated handling; manual compilation, receipt, and/or message dispatch.
Degree 3
Seamless Sharing of Data; automated sharing of data amongst systems based on a common exchange model.
Degree 4
Seamless Sharing of Information: universal interpretation of information; data processing based on co-operating applications.


Table 13 – Degrees of Interoperability defined by TOGAF


Conclusion

In parts I and II of this article we defined a mapping that corresponds to several core and mandated elements of TOGAF and SOA. This mapping is an extension of the mapping defined within TOGAF to define SOA. We believe that this mapping provides a good insight on the nature of both methodologies and how they can be combined. A summary of the main ways in which the two methodologies complement each other follows in Tables 7 and 8. We will examine additional areas during the elaboration of Governance features in both SOA and TOGAF in the next article of this series.


Elements of TOGAF not in SOA:
Core: Business Architecture in terms of Business Monitoring, Business Optimization, Business Interoperability, SMART Business Scenario (recommended)

Core: Architecture Change Management

Core: Requirements Management

Recommended: Gap Analysis

Recommended: Stakeholder Map

Recommended: Skills for EA in each Phase

Recommended: Additional Tasks for Security Architect

Recommended: Transformation Readiness Factors for Business Transformation Raadiness Assessment

Recommended: Capability-Based Planning


Table 14 – Main Methodology Gaps between TOGAF and SOA


Elements of SOA not in TOGAF:
Core: SOA Principles

Core: Architecture Layers

Core: Service Delivery Phases

Recommended/Pattern: Domain Inventory

Governance: SOA Maturity Models

Governance: SOA Roles


Table 15 – Main Methodology Gaps between SOA and TOGAF


Related Reading

It is worth acknowledging other work that has been done in the area of mapping SOA and TOGAF into other processes and frameworks, in particular to RUP. For example:

  • A RUP for SOA plug-in was made available in 2005 to help extend the RUP analysis and design approach with workflows and artifacts required for service-oriented analysis and design.
  • A mapping of high level service design stages to RUP phases was published in "Mapping of SOA and RUP" [REF-5], but this work did not cover service-oriented analysis.
  • A combination of RUP and the MSOAM appeared in the March 2008 issue of the SOA Magazine [REF-3]. This article uses RUP to elaborate service inventories and it focuses on processes related to top-down Service-Oriented Analysis stages in relation to the RUP activities related to Business Modeling.
  • A mapping of service-orientation to RUP [REF-5] appeared in 2011 in the appendix of the SOA Governance book. Comparison of this approach and the mapping to TOGAF is provided earlier in this document.
  • A mapping of TOGAF to RUP is provided in [REF-6]. Our mapping of SOA to TOGAF and the previous mapping of [REF-5] comply well with the results of the TOGAF to RUP mapping.
  • Extension of software delivery processes such as RUP to accommodate a complete enterprise scope is provided in [REF-1]. This work corresponds to the second part of the work in [REF-6], but also to our work in this document.


References

[REF-1] Enterprise Unified Process: Extending the Rational Unified Process, Scott W. Ambler, John Nalbone, and Michael Vizdos, Prentice Hall www.enterpriseunifiedprocess.com

[REF-2] MSOAM, The Mainstream SOA Methodology, Thomas Erl www.soamethodology.com

[REF-3] Working with SOA and RUP, Solmaz Boroumand, SOA Magazine Issue XVI, March 2008

[REF-4] SOA Governance. T. Erl et al. April 2011.
www.soabooks.com/governance

[REF-5] Mapping of SOA to RUP. Filippos Santas, April 2011, in [SOA-GOV]

[REF-6] TOGAF Version 9. The Open Group, 2009.
http://www.togaf.info/togaf9/index.html

[REF-6] TOGAF V9 an IBM view. http://www.gsebelux.com/system/files/TOGAF 9,an IBM View - Eric Michiels - 26-Mar-2010.pdf

[REF-6] Mapping the Unfamiliar to the Familiar With TOGAF and RUP. Tarak Modi, 2008. http://www.ebizq.net/topics/soa_management/features/9869.html

[REF-6] Delivering SOA with TOGAF. A. Dico, January 2008. https://www.opengroup.org/projects/soa-togaf/uploads/40/15844/dico.pdf