11

Authored by: Alexander Doré August 14, 2010

Workbook 6

Architecture Services Mobilization Introduction to SOA Highlights

Business Architecture Program Business Enterprise Architecture Governance (BEAG)

Confidential

C-MAD Group Inc Computer Science & Engineering Architecture Consulting Services

22

1

The SOA Enterprise Architecture Vision SOA Adoption SOA-Rich Stack Architecture Vision SOA Architecture Blue Print

33

Evolution from Current State to Target State: SOA Stack

Brownfield Development

•  Blueprints will describe problem spaces needing the development and deployment of new software systems in the immediate presence of existing (legacy) software applications/systems.

•  Any new software architecture must take into account and coexist with live software already in situ.

Business/Service Value-Driven Architecture

The most viable, agile architectures will be comprised of a blend of architecture strategies, including (but not limited to) Service-Oriented Architecture (SOA), Event-Driven Architecture (EDA), Process-Based Architecture (PBA), Federated information Architecture (FIA), Enterprise Architecture (EA) and open source adoption.

44

Service Managem

ent

Service Bus

Comm

on Services

Service Infrastructure Composite Applications

Presentation Services

Information and Access Services

Shared Business Services

Governance Services

Security Services

Event Services

Enterprise Applications ERP

Wireless Client

Thin Client

Private Cloud

Thick Client

Desktop as a Service

UI

Fully Integrated Client Browser

Software as a Service

Platform as a Service

Integration as a Service

Leverages

Drives

Meta-Data Services Bridge

ETL as a Service

Historical Data Service

Master Data Management Service

Data Abstraction Service

SOA Stack [3-Tier]

Enrichment Vision For The Future

SOA Fram

ework

1

2

3

CRM LEGACY

55

Service Bus

Composite Services

Presentation Services Information Access Services

Shared Business Services

Governance Services Security Services

ERP

Private Cloud Desktop as a Service

Process Portal

Operational Data Services

Software as a Service

Platform as a Service

Integration as a Service

Historical Data

SOA Blueprint 1 2

Process Analysis

Business Analysis Operational Systems

Analytics Services

Business Process Management (BPM) Business Rules Management (BRM)

Enterprise Applications CRM Legacy

Service Infrastructure

Service Management

Event Services

Common Services

ETL Services MDM

Data Abstraction

Business Activity Monitoring (BAM)

Meta-Data Services Bridge Data Warehouse Services

Data Marts

Master Data Warehouse

Business Intelligence (BI)

3

KPI Service Architecture

66

2

SOA Data and Event Integration Vision SOA Meta-Model

77

SOA Meta-Model

Secu

rity/

Com

plia

nce Monitoring/Event Management (EDA)

Process/Orchestration

Business Services

Data Services Bridge/Messaging

Data Abstraction

SOA G

overnance Integration as a Service [IaaS]

Software as a Service [SaaS] Platform as a Service [PaaS]

Desktop as a Service [SaaS]

Data New Business Services Legacy

88

Six SOA Domains SOA Organization & Governance Control Areas SOA Organization & Governance Phases SOA Architecture Group Structures Building the ”Right" SOA Services Variable Service Application Granularity Managing SOA Costs

3 SOA Vision for Alcatel-Lucent

99

Six SOA Domains

Business Strategy & Process

SOA-Enabled Business Strategies

Business Process Architecture

Architecture

Reference Architectures Manageability/Availability

Scalability Security

Service Building Blocks

Infrastructure Information & Access

Shared Business Presentation

Composite Applications

Projects & Applications

Existing Applications Key “In-Flight” Projects

Infrastructure Construction Plans

Organization & Governance

Organization Design Funding,Skill-sets

Roles & Responsibilities Standards

Operational Process & Tools

Change Management

Costs & Benefits

Construction Costs Business & IT Benefits

Key Measures

1

2

3

4

5

6 Business Process Optimization (BPO) •  Orchestrate Services into Processes •  Measure Alignment with Strategy •  Identify Opportunities for Optimization

•  Analyze Processes •  Identify Supporting Functionality

•  Harvest Functionality from Existing IT Assets •  Develop New Functionality •  Develop Contracts and Services as Packages

2

3

BPO Feedback Loop

1

1010

SOA Organization & Governance Control Areas Considerations

•  Foundational Domain Model for SOA •  Standards Compliance throughout Domain Model •  Service Roadmap: definition, development and deployment of

interoperable portfolio of payroll services on initiative-by-initiative basis

•  ALU Change Management: SOA implies changes to core systems, reduce knock-on effect to current systems, optimize reference SOA

•  Re-use Enforcement [Where required] •  Organization Structure •  Culture Change: Service delivery will require buy-in •  Skills Development and Best Practice Adoption •  Funding Model and Accountability

1111

SOA Organization & Governance Phases

Phase 1: Definition Phase 2: Management Phase 3: Support / Control

SOA Guiding Principals Service Granularity Service Validation & Traceability Service Quality Control

Wide Mentoring

SOA Architecture Service Security & Compliance Service Governance Service Distribution

Leverage Services

SOA Guidelines, Policies & Standards

Service Exception Process Monitor Processes

SOA Process & Procedures Inspection & Adaptation Process Funding, Manage Sponsor Expectations

SOA Organization Change Management Process, Risk Management

Reporting, Metrics

1212

SOA Architecture Governance Structures

Centralized Governance Team [Enterprise-Wide]

Federated Governance Team

[Region A]

Federated Governance Team

[Region n]

Governance Team

Hierarchical Governance

Team [Region A]

Hierarchical Governance

Team [Region n]

Federated Governance Team

[Region A]

Partial Federated Governance Team

[Region A.1]

Partial Federated Governance Team

[Region A.2]

Site 1 Site 2 Site 3 Site 4

Centralized Federated

Partially Federated

Loosely Bound

Hierarchal

Tightly Bound

1313

Building the ”Right" Services •  Ensure that SOA Services are built at the right level of

granularity as SOA magnifies the granularity issue by bringing it to the forefront of the design discussion.

•  a SOA service must be coarse grained, defined as business services, thus having business service granularity

•  Too fine-grained services address small units of functionality that cannot be controlled

•  SOA should take a top-down (problem to architecture to solution) approach that means that the business unit (user) drives the requirements and essentially (but, not directly) the service granularity

•  Granularity is a relative measure of how broad a required piece of functionality must be in order to address the business need at hand operating from an encapsulated business blade

1414

Variable Service App Granularity

Coarser Grained Business Services

Finer Grained Business Services Note: Business Service relationships suggested

1515

Managing SOA Costs

SOA

Traditional Approach

Cum

ulat

ive

Cos

t

Number of Capabilities Implemented 1 2 3 4 5 6 7 8 9 10 11 12 13 14

SOA Infrastructure

Investment

SOA Infrastructure

Leverage

SOA Infrastructure

Maturity

1616

4

SOA Considerations SOA-Light SOA-Blended-EDA SOA Security

1717

SOA-Light Considerations

•  The demand to build a true fully loaded SOA-stack (see slide 4) places great stress on IT-oriented development shops, as SOA, by nature is not a technology, and cannot be found in a box, rather it is a framework that exposes and leverages services as business processes utilizing measurable data through those processes

•  To adopt SOA can become a war of politics and frustration to legacy organizations as SOA is driven not by technology innovation, but by marketplace that demands quality, improvement and accountability to service value

•  Erring on the side of caution it is strongly advised to build-out SOA in simple segments before tackling the whole shebang, which is dubbed SOA-Light

1818

SOA-Light Reference Architecture

Service Managem

ent

Service Bus

Comm

on Services

Service Infrastructure

Composite Applications Presentation Services

Information and Access Services

Shared Business Services

Documents HR-CRM Finance Users

Outside Services Sponsors Legal Partners

Nonfunctional Standards Development Tools

Configuration Management

System Management

Business Patterns Directories Business

Monitoring Provisioning Network

1919

SOA Security Services SOA Security Considerations Preventing Security Hazards by Leveraging SOA MDA SOA Security Requirements Model SOA Security Operational Model SOA Security Roadmap

5

2020

SOA Security Considerations

•  SOA exposes business processes and data through processes therefore increased exposure brings a greater potential for compromise –  Each Service is a potential attack point –  Greater damage due to increased exposure of data

•  SOA is not practical without a common security infrastructure –  No common security services results in “islands of security” –  Common security services can reduce administrative and

user burden –  Common identification services enable single-sign-on (SSO)

2121

Preventing Security Hazards: Leveraging SOA MDA •  SOA security services addressed solely from a technology-

oriented view only assist in choosing data to encrypt and the encryption algorithms to use

•  SOA security requirements must be refined from a business perspective not just a technology-oriented view

•  SOA security requirements gaps can be transformed from detailed observations to planned watertight countermeasures by using best-practice operational patterns

•  SOA security pattern monitoring services allow security gaps to be measured for repetitive hazardous behavior thus becoming part of a stricter policy improvements

•  SOA security patterns can be derived from use cases

2222

SOA Security Requirements Model

Business Domain

IT Domain

SOA Requirements Security Framework 1

2

Owners

Experts

Designers

Users

Goal: Description of organizations strategic goals, business design and business objectives:

Artifacts: High-level rules consisting of legislation, business practices, corporate level rules and guidelines

Strategy Model

Operational Model Goal: compute-independent model of activities representing business process and rules

Artifacts: Business process compliant rules and constraints that can be validated at different levels of security model granularity

Execution Model

Implementation Model

Goal: Platform independent description of document flows, actor connections, applications, data sources and their relationships

Artifacts: Mandatory security requirements, application specific rules

Goal: Platform-specific model of IT infrastructure; h/w, s/w, m/w and network

Artifacts: Platform-dependent configuration, security infrastructure, security requirements metrics reporting

2323

SOA Security Operational Model

IT Domain

SOA Operational Security Bridging Framework

Client

Portfolio

Staging

Operational Pattern Bridge

SOA Model 1

SOA Model 2

SOA Model 3

SOA Model n

Security Policy Compliance Policy

Extraction

Rules Engine Web Access Point

Encryption (AES)

UDDI V 2 RSA 2010 - OASIS [XML]

Detection/Countermeasures

High-Availability

Patriot Act [Web Portal]/Enforcement

PCI DSS Data [DMZ]

Portfolio

SSO

SOX 404 Sec 302

Port 99 Certification

2424

SOA Security Roadmap •  Avoid monolithic set of security requirements

–  Legacy systems will have problems complying with all rules –  Not all systems require the same level of security –  Simple pass/fail approach gives no way to measure partial compliance

•  Define security requirements through compliance –  Tiered requirements provide stepping stones –  Provide a way to measure progress –  One-size-fits-all is neither a necessary of a practical approach

•  Direct security implementation –  Adopt convergence to common tools

•  Institute security compliance levels for access controls –  Level 0 - Does not support access control –  Level 1 - Supports access control via proprietary internal mechanism –  Level 2 - Supports access control via some tightly-coupled mechanism –  Level 3 - Provider partially uses the common security services –  Level 4 - Provider relies entirely on the common security services