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