Value Management Techniques

*Value Governance

- Govern and Assure (Direct)

- Strategise and Plan (Direct)

- Operate and Optimise (Execute)

- Change and Transform (Execute)



The Val IT Framework (IT Governance Institute - ITGI)

COBIT Framweork for the management and delivery of high-quality IT-enabled services



Val IT / COBIT IT Governance Approach

Val IT

- Strategy (Are we doing the right things?)

- Value (Are we getting the benefits?)



COBIT

- Architecture (Are we doing them the right way?)

- Delivery (Are we executing them well?)



Value Governance Maturity

0 - Non-existent

1 - Initial

2 - Repeatable

3 - Defined

4 - Managed

5 - Optimised



*Business Case Best Practices

• Justification for an investment


• Communication on assumptions about costs and benefits


• Method to inform decision making on allocating scarce resources and capital

Business Case Key Issues

• Developing the Business Case


• Reasons for Project


• Options - Scenario Planning


• Benefit expected


• Risk


• Cost - Financial ROI, DCF NPV


• Timescale


• Investment Appraisal - Cost Benefit Analysis


• Evaluation

Templates

Approval Process and Gates

Acceptance Criteria

• Alignment with Strategy


• Rank, Priority and Opportunity Cost


• Feasibility, Causality, Risk Aversion

Delivery of Benefits



Questions to ask about a Business Case

Is this busine?

Is it the best business case if we were to rank them?

Can we measure the changes?

Is there really a cause/effect link between this business case and the value?

What is the business case doesn't go forward - what are the real consequences?



*Continuous Decision Improvement

Use the outcomes of previous decision-making experiences to improve future decisions and apply techniques to optimize those decisions.



Disciplines

• Predictive Analytics & EDM


• Decision Support


• Optimisation


• Knowledge Mangement

The CDI Cycle

• Communicate improved strategy and policy for decision-making


• Apply policty: make decisions


• Monitor and collect data for analysis


• Analyse & Develop: Learn from earlier decisions and outcomes

*Value Engineering

1. Outcome Planning

2. Function Modeling

3. Speculation & invertion

4. Idea Development

5. Idea Portfolio Building

6. Decision Approval

7. Implementation

Functionality Models

Produce New Procedure

Determine Procedural Options

Establish Procedure Scope (Allocate SME Resource)

Identify Required Technical Outcome

Benefits Definition

Identifying benefit types

Determing benefit certainty

Clear Benefit definition makes functional silo behaviour less easy, exposes negative competition, makes it harder for people to simply be self-interested

Two key elements:

• Defining benefits
• Mapping benefits
  

What is the investment rationale (How hard is the Benefit Definition)?

• Renewal (Easy)
• Process IOmprovement (Moderate)
• Experiments (Hard)
• Transformation (Hard)
  

Defining Benefit Types

• Profit
• Revenue
• Growth
• Share
• Costs
• Time
• Productivity
• Risks
• Customer Experience
• Image & Reputation
• People's Morale
  

Benefit Certainty

• Securable
• Committed
• Anticipated
• Noticeable

Write a benefit definition

• Start the sentence with an active verb that identifies the change (two words)
• Add any subject and conditions

More/Less, Increse/Reduced, Deliver/Eliminate, Greater/Fewer, Faster/Slower, Maximise/Minimise

Benefit Definition Checklist

• Beneficiary
• Description
• Dependencies and CSFs (Critical Success Factor)
• Direct/Indirect - SCAN
• Timing
• Type
• Measurement
• Responsibility

*Benefit Mapping

Benefit Management - Critical Success Factors

1. Framing
2. People
3. Analysis
4. Measurement
5. Governance

A benefits map connects:

1. what is done (ie invested in or consumes resources)
2. Tangible changes in the business (that result form those activities)
3. The end benefits it delivers (meaningful to the business as ROI)

Engaging Business Stake Holders

Benefits Mapping: Planning the Investment

Business Objectives

• Improve Cost Structure
• Increase Asset Utilization
• Enhance Customer Value
• Expand Revenue Opportunities
• Reduce Product Proce
• Improve Product Capability
• Reduce Time to Market
• Reduce Product Lead Time
• Improve Product Quality

Business Transformation (Change) Initiatives

• Concurrent Product Introduction Processes
• Increase Re-use of Legacy Product Info
• Increase use of Lessons Learned

IT Enablement Programmes

• Product Lifecycle Management (PLM)
• Knowledge Management System
• PLM for Engineering

Benefits Mapping: Planning Benefit Delivery

• Identify business change activities (Benefits Map)
• Validate for each BU
• Link to Programme Mgt controls (Milestones)
• Monitor as lead indicators of benefit erosion
• Apply corrective action

Benefits Mapping: Implementing Benefit Realization

Benefits Mapping: Delivering Benefit Certainty

Projects->Initiative/Enabler->Value Driver->Objective/Benefit->Strategic Objective

Process Steps

• Executive sponsorship and briefing
• Access to documentation / information on initiatives
• Access to objectives
• Develop logical structure - strategic objectives through to project
• Share a strawman
• Agree focus with Executive Sponsor: business results nore important than purity of mapping
• Ensure building a map that can be developed with quantification
• Stop when your client has achieved what they needed

Benefits Map: Tracking Benefit Realization

• Activities
• Results
• Enabling Outcomes
• Managed Benefits

SOA Maturity Level

Level 1 - Explored
An organization is aware of SOA and may be studying the potential impact or doing some proof of concept developemnt.
Level 2 - Applied
Top management is committed to SOA, the organization has developed a basic capability to design and implement services, and selected shared services have been deplotede. (bottom-up)
Level 3 - Adopted
The organization has a SOA infrastructure in place and is committed to standards. They have a system of governance to plan and manage transformation of the organizeation and to manage the definituion and implementatiuon of services. (top-down).
Level 4 - Measured
Services are monitored and measured for cost, performance, and quality and refined for enterprise optimizatuion. The contribution of services to the value chain can be reported and analyzed. (value chain driven).
Level 5 - Agile
The organization has a continuous change culture, and business processes to adapt the enterprise are driven by disruptive events. The enterprise adapts by reconfiguring existing services with minimal capability enhancement or development of new services. (sense and respond).

Technical Maturity Levels
Technology
Explored
Heterogeneous, application focused uses of web services technologies
Applied
Initial use of SOA technologies such as ESB, Registry, Repository, etc
Adopted
Full deployment of SOA technologies, inculding business process automation
Measured
Event-driven monitoring and response services
Agile
Ecosystem scope, model-driven business with complex event processing

Architecture
Explored
Limited scope with no enterprise service-oruiented architecture discipline
Applied
Initial standardization of infrastructure and applications across lines of business
Adopted
Enterprise level service integration infrastructure
Measured
Business aligned event driven architecture
Agile
Dynamically reconfigurable servies architecture

Data
Explored
Application specific
Applied
Initial use of subject area data model
Adopted
Data within services conforms to an enterprise data model
Meausred
Industry-based, conceptual data model
Agile
Sense and respond with analytics driven business process

Governance
Explored
Project-based
Applied
Program-based (multiple cross lines of business projects) governance
Adopted
Enterprise level Governance addressing the lifecycle of services and processes
Meausred
Serviec SLAs and qualities are defined using industry standards
Agile
SOA governance is an integral part of driving continuous business transformation

Organization
Explored
Limited prior knowledge
Applied
Project key individuals have prior experience
Adopted
Enterprise wide SOA knowledge based on roles and responsibilities
Measured
SOA drives application development and is supported by on-giing tringing
Agile
Fully SOA based organizational structure

Operation
Explored
Application-based operational Model
Applied
Service-based operational Model
Adopted
Performance monitoring of service operation and policies
Measured
Metrics-based optimization of virtualized and shared service environment
Agile
Dynamic performance optimization

Security
Explored
Security infrastructure in place is geared towards providing security for applications only
Applied
Protecting a service is a responsibility that mostly falls on the developer, using proprietary agreements between requesters and consumers
Adopted
Adoption of WS-Security, WSM introduced
Measured
Centralized management of security policies. Adoption of SAML for federated identity
Agile
Adoption of new technology standards and regulatory requirements are pro-actively planned

Business Maturity Levels
Business Process
Explored
Undocumented bgusiness processes often embedded in applications
Applied
Business processes are documented and controlled, and business processes driven shared services
Adopted
Enterprise business process models drive definition of services, reduce variance and support continuous improvement
Measured
Metrics based process improvement with defined processes for resolution of disruptive events
Agile
Rapid, proactive response to disruptive events with what-if analysis

Organization
Explored
Departmental silos of control, often with duplicated capabilities
Applied
Shared services are owned by business units and managed in compliance with defined interfaces and service levels
Adopted
Service business units manage assets and resources of shared services, and service improvements are driven by enterprise wide initiatives and collaboration
Measured
Organization reflects enterprise alignment of capabilities, performance measures and incentives for service optimization
Agile
Service units optimize services and adapt to world events in the context of the enterprise strategic plan

Governance
Explored
Departmental ownership and funding of business improvements
Applied
Cross-LOB selection, management, and funding of service developemnt projects
Adopted
Enterprise governance board sets priorities, policies and standards for services, infrastructure optimization and regulatory compliance
Measured
Focus of top management on performance of services and adaptation to new business needs
Agile
Culture of continuous and responsive change with services as building blocks that support agilty and creative sourcing (e.g., outsourcing)

Portfolio
Explored
No coordinated, enterprise-wide consolidation of sharable business functions
Applied
Enterprise portfolio establshed for visibility and management of applications and services
Adopted
Service lifecycles are managed in the context of an enterprise portfolio with explicit service contracts
Measured
Services portfolio support includes performance metrics and process path performance analysis. Support to configure new business models
Agile
Active business model of service interactions and e vent resolution extending to business partners, customers and outsourced services

Finance
Explored
Departmental funding for technology applications and business change
Applied
Enterprise-level funding of SOA infrastructyuure with policies for services costing
Adopted
Enterprise funding of investment in services with chargeback allocation fo true costs
Measured
Visibility of the contribution of each service to value chain cost, quality and responsiveness
Agile
Financial models support business planning and pricing for new products and expected ROI for transformation

Secirity
Explored
No security controls exist to consistently protect information that flows through the service fabric. Security is performed ad-hoc
Applied
Services are secured; however, most of the security implimentation is embedded within the serviees logic
Adopted
Consistent approach to security for all new applications/services. This enables secured interoperability across the enterprise
Measured
The Enterprise has a consolidated security administration service with distributed (service level) policy management.Security metrics are collected and analyzed. Actions are taken to resolves potential vulnerabilities
Agile
Organization proactively plans and addresses everging standards and technologies. Regulatory compliance is institutionalized

View Points of SOA

Rule of Thumb
1. SOA Benefits (respond quickly and effectively to business change and leverage that change to gain a competitive advantage)
2. IT and Business as Peers (forge peer working relationships between IT and business)
3. Incremental Business Services (mirror business process steps)
4. Business-Smart IT Architects (Business-aware)
5. Opportunities for Services (each business process interaction with an IT asset is a potential location for a service)
6. Measuring Services (allocate IT costs and provide IT justification by correlating the IT costs with business process results
7. service-Oriented Means in the Core (business processes and services at the center of both business design and IT delivery)
8. Proving Business Value of SOA (through business results measurements)
9. Competitive Business Agility (change in business process no longer requires a change to application programming logic)

Characteristics address the degrees of flexibility that will affect architecture decisions (does it relevant to consumers?)
1. Platform
2. Location
3. Protocols
4. Programming Language
5. Invocation Patterns
6. Security
7. Service Versioning
8. Service Model
9. Information Model
10. Data Format

Infrastructure Services
1. Resource Virtualization Services
2. Service-Level Automation and Orchestration
3. Utility Business Services

Enterprise Service Bus (ESB)
1. Transport
2. Quality-of-Service-Based Routing
3. Mediation
4. Web Service Gateway

SOA Enterprise Software Models
1. Industry Models (ebXML, OAGIS, NGOSS, IFX, IFW)
2. Platform-Independent Qealization (XML, XSD, HTTP, SOAP, WSDL, WS-Policy, WS-Resource, WS-Security)
3. Platform-Specific Realization
4. J2EE Realization (EJB, JAX-RPC, WSDL, DOM, SAX, JCA, J2C)
5. Service Integration on WebSphere Application Server

The Information Management Domain
1. Information Management
2. Information Management Services
3. Reengineering Information Management into Services
4. Meta-Data Management
5. Meta-Data Integration

SOA Program Methodology

Program Management Methodology

Framework of Governance
Alignment of processes and services with business strategy and results in evolution to a service-oriented enterprise (SOE) (service catelog, registry of services and descriptions)
Framework of Communications
Ensures collaboration of business and technical staff in a continued plan on the endeavor in the firm (dashboar, balanced scorecard, portal)
Framework of Product Realization
Core of established project management methodology.
Framework of Project Management
Ensures the changes in business strategy are applied as appropriate on a project of SOA. Ensures that processes and services are functioning and implemented as planned in the strategy.
Framework of Architect
Ensures evolution from conversion of functions into services, creation of component services and integration into composite servicves, integration of internal applications, internal services and external services, to on-demand servicers in a gradual SOE
Framework of Data Management
Enables implementation of the services, based on access, availability, breadth, and accuracy of data already inthe databases of the applications
Framework of Service Management
Ensures reusability of service. Feasibility of processes and services, and impact on the firm, are evaluated in service management
Framework of Human Resource Management
Enables identification of new and revised responsibilities and roles of business and technical staff on SOA.
Framework of Post Implementation
Enables service and process life-cycle tasks following product realization.

Factors for Enabling Frameworks of Methodology


Factors- Description of Factors
***Business Factors***
Agility, efficiency, and flexibility benefits
- Extent to which benefits of adjusting to business environments drive the program

Financial benefits
- Extent to which benefits of increased revenues or decreased expenses drive the program

Business client participation
- Extent to which business departments consent, contribute, and furnish content and guidance to the program

Competitive, market, and regulatory differentials
- Extent to which competitive, market, and regulatory first-mover edge for the firm drives the program

Customer demand
- Extent to which customer demand for enhanced service from technology drives the program

Culture of innovation
- Extent to which innovation in business and technical practices is encouraged and facilitates the program

Organizational change management
- Extent to which cultural change management is evident in helping business and technical staff embrace the program

Executive sponsorship
- Extent to which senior managers in the firm articulate and evangelize the business criticality of SOA as a strategy and fund the program

Executive business leadership
- Extent to which senior managers in the business units evangelize business criticality of SOA as a strategy

Executive technology leadership
- Extent to which senior managers in the technology departments evangelize the technical and business criticality of SOA as a strategy

Strategic planning
- Extent to which business strategy of SOA is articulated in the firm and is accepted by program staff

Enterprise architecture
- Extent to which formal enterprise architecture contributes to initiation of the program and evolves with processes to an SOA

Focus on improvement of process
- Extent to which improvement of business processes, process integration, and service choreography are the goals of the program

Service orientation
- Extent to which technical and business staff is receptive to principles of service orientation and SOA

Reusability of assets
- Extent to which multiple services using software technologies is a goal of the program

***Procedural Factors***
Control of program
- Extent to which a formal function is evident for guiding and helping the firm in evolution to SOA

SOA center of competency
- Extent to which a centralized team is evident for furnishing SOA expertise help to program staff

Responsibilities and roles
- Extent to which responsibilities and roles of staff on the program are clearly defined for completing project tasks

Education and training
- Extent to which formal skill training on services and SOA is evident for program staff

Knowledge exchange
- Extent to which processes and procedures are evident for informing business and technical staff of progress of the program

Change management
- Extent to which procedures are evident for ensuring optimal resolution of requests for changes in existing processes or services or of requests for new processes or services

Information management
- Extent to which procedures are evident for ensuring data integrity and quality for technical and business functions

Common reference
- Extent to which business and technical terminology is applied consistently by program staff

Naming conventions
- Extent to which naming standards and service versioning are used by program staff

Procurement of technology
- Extent to which a formal function is evident for furnishing quality hardware and software technology to the program in a cost-effective and expeditious manner

Technology firm knowledge capture
- Extent to which program staff captures knowledge from hardware and software technology firms to become independent of the firms

Risk management
- Extent to which procedures are evident for mitigating failure or loss caused by SOA

Standards management
- Extent to which program staff is cognizant of official standards, scope of implementation of the standards by technology firms and standard gap resolution techniques

Infrastructure architecture
- Extent to which procedures are evident for guiding the evolution of technology in a strategy of SOA

Process and service deployment environment
- Extent to which procedures are evident for furnishing software and tools to the development staff on the program

Process and service deployment techniques
- Extent to which procedures are evident in order to ensure the highest quality of deployed technology throughout the program

Service catalog management
- Extent to which procedures for managing a registry or a repository of processes and services are evident on the program

Service management and support
- Extent to which procedures are evident for ensuring service availability and reusability and furnishing metrics on service support Security management- Extent to which procedures are evident for safeguarding access to services

Continuous process improvement
- Extent to which procedures are evident for iterative improvement of existing and new processes

Costing techniques
- Extent to which techniques are evident for costing existing and future SOA product realization and support

Strategy management
- Extent to which procedures are evident for evaluating and improving program strategy of SOA as required

***Technical Factors***
Internal Web services on project
- Extent to which Web services as simple projects contribute to the evolution of SOA

Internal process domain on project
- Extent to which complex Web services applications contribute to the evolution of SOA

Internal SOA domain on project
- Extent to which standards-compliant, internal, and loosely coupled projects contribute to the evolution of SOA

External process domain on project
- Extent to which external tightly coupled and security-sensitive and trusted projects contribute to the evolution of SOA

External SOA domain on project
- Extent to which external standards-compliant, loosely coupled, and security-sensitive and trusted projects contribute to the evolution of SOA

Business process management software
- Extent to which Web Services-Business Process Execution Language (WS-BPEL) software is included in the program

Data tools
- Extent to which data tools supporting eXtensible Markup Language (XML) are included in the program

Middleware
- Extent to which an enterprise service bus (ESB) or traditional middleware technology is included on the program

Platform of key technology firms
- Extent to which the platforms from key technology firms (e.g., BEA, IBM, and Microsoft) are included in the program

Platform specialty tools from platform technology firm
- Extent to which specialty tools of the platform technology firms are included in the program

Proprietary technologies
- Extent to which proprietary software is included in the program

Best-of-class tools
- Extent to which specialty tools from pure-play or third-party technology firms are included in the program XML standard- Extent to which XML is included in
the program

Messaging standards
- Extent to which technology supporting Simple Object Access Protocol (SOAP), SOAP Message Transmission Optimization Mechanism (MTOM), and SOAP with Attachments (SwA) or similar standards is included in the program

Service description and discovery standards
- Extent to which technology supporting Universal Description, Discovery and Integration (UDDI), Web Services Description Language (WSDL), and Web Services-Policy (WS-P) or similar standards is included in the program

Transaction standards
- Extent to which technology supporting Web Services-Composite Application Framework (WS-CAF), Web Services-Choreography Description Language (WS-CDL), and Web Services-Transaction (WS-TX) or similar standards is included in the program

Security standards
- Extent to which technology supporting XML Encryption, XML Signature, Web Services-Federation (WS-F), Web Services-Security (WS-S), and WS-Security Policy (WS-SP) or similar standards is included in the program

User interface standards
- Extent to which user interface tools or Web Services-Remote Portlets (WS-RP) are included in the program Web services best practices- Extent to which Web Services-Interoperability (WS-I) is included in the program

Web services management standards
- Extent to which Service Provisioning Markup Language (SPML) and Web Services-Distributed Management (WS-DM) are included in the program

Responsibilities and Roles of Program Staff for Fulfilling Methodology


Definition

The LEGO Model of SOA (ZapThink)

Advantages of Lego Blocks
1. Interoperable
2. Unbreakable
3. Composable
4. Reusable

Downside of Lego Blocks
1. Lego blocks' strengths pose business challenges for their manufacturer (sale waned over time)
2. Structures built from Lego blocks are only so strong
3. Lego blocks are interoperable with each other, but not with other kinds of toys
4. Lego blocks are for children, but children couldn't build Legoland (architecture is needed)

Lego Blocks and Service Granularity
- Fine-grained Services aren't particularly valuable to the business
- But Services can also be so coarse-grained that ther're too inflexible to meet the needs of the business either
- The optimal granularity for Services generally falls somewhere in the middle
- It makes sense for organizations to build a mix of Services at different levels of granularity

SOA Governance

The main objective of Service governance is to achieve the benefits of a Service Oriented Architecture by fostering the creation of reusable, enterprise class services. As a cross functional organization, service governamce ensures the timely resolution of issues and conflicts due to the necessary tradeoffs that are made when shared requirements are defined.

Simply put, governance sets policies in place, and provides the mechanism to enforce them.

SOA governance life cycle
- Design-Time Governance (defining and controlling of enterprise services to be created in the enterprise, and the creation of policies used to direct and control the implementatin of the enterprise service life cycle)
- Deploy-Time Governance (process of testing and controlling compliance to enterprise policies in order for servics to be deployed in an SOA)
- Run-Time Governance (process of enforcing the adherence to run-time service policies at run time)
- Change-Time Governance (managing services through the cycle of change)

Types of policies used in SOA governance
- Messaging Security
- Access Control Policy
- Conformance to Enterprise Vocabulary and Schema
- Conformance to Technical Standards (WS-I, WSDL, WS-Security, WS-ReliableMessaging)
- Deployment Process
- Versioning Policies
- Discovery Policy
- Privacy Regulations
- Quality of Service (QoS)
- Reliability
- Auditing and Reporting Requirements
- Service Level Agreements (SLAs)

Separate Policy Logic from Business Logic

SOA Governance and Service Life Cycle


Differentiating Service Policies and Business Processes
Most business processes are based on business rules and workflow, where most run-time governance policies for services are sets of constraints and capabilities that describe how a service and a client interact.

The Service Identifrication Process
Process



Stakeholders


Service Design and Specification Process
Process



Stakeholders


The Service Implementation Process
Process



Stakeholders



Deploy-Time Governance
Process



Stakeholders



Run-Time Governance
Process



Stakeholders



Developing Enterprise Policy
- Standards compliance
- Common vocabulary
- Naming conventions
- Error handling and suditing
- Run-time service policy authoring
- Genral best practices and blueprints
- Service versioning

SOA governance model (process)
- Requirement Management
(Who collects the requirements? Who tracks changes in requirements? how are new requirements incorporated into the architecture strategy?)

Key procedures
* Requirements definition
* Requirements modification
* Requirements implementation

Mitigating the risks
* Identify valid sources
* Given the reuse levels and complexity within an sOA environment, SOA requirements must be managed on a life-cycle basis
* Requirements tracability

- Architecture Planning
(Who defines SOA architecture? who enforces the use of the sOa architecture? what are the criteria for reusability? who determines the business impact of projects and what metrics do they use? Can you demonstrate the causality between the SOA efforts and business improvements? who pays for a service and support? How much? How do they pay? Per service call, as a percentage of development cost or total cost recovery?)
Key procedures
* SOA architecture design
* SOA service planning
* SOA financial planning

Mitigations
* Increase potential risk areas(highlight closed-loop interactions)
* Interactions are not addressed in terms of timing, who performs them, and how they are performed
* Service performance metrics

- Competency Center Management
(Who owns support? The developers who built the services? A dedicated support team? Should you create an sOa competency center? What resource skills are required? How should it be staffed? How do center personnel work with application teams?)

Key procedures
* Define SOA development support services
* SOA project consulting

Mitigations
* provide necessary people skills

- Business Process Management
(who defines the scope of a business process? How should business process tasks be associated to a web service? who collects business process activity metrics?)

Key procedures
* Business Process Design
* Business Process Development
* Business Process Monitoring

Mitigations
*must be driven by business processes
*leverages client's enterprise business architecture
* Work with enterprise governance

- Service Life Cycle (Who defines naming standards? Who writes services? who tracks the metrics? who publishes the services? who is responsible for assigning service policies?)

Key procedures
* Service Identification and Design
* Service Development, Testing, and Deployment

Mitigations
* Identify proper stakeholders
* HP SOA Governance Tools

- Security Management
(Who builds the security framework for your integration implementation? Who integrates web service security with the rest of the organization's security infrastructure?)

Key procedures
* Security design
* Security implementation

Mitigations
* Align security policies with security design reviews

- Registry / Repository Management
(Which tools are used to build the repository? What will be stored in it and who controls access? How do you enforce maintenance of repository content?)

Key procedures
* Evaluate and select the SOA registry and repository
* Develop SOA registory and repository usage guidelines

Mitigations
* follow usage guidelines
*Review HP SOA Center governance software platform

- Configuration Management
(Who manages the dependencies between services and applications? what are the criteria for creating releases? who builds, manages, and runs the test environment? who determines the timing and cordination of release promotion?)

Key procedures
* SOA environment configuration
* Release management
* Change control

Mitigations
* Identify stakeholdes and coordination methods early
* clear communication plans for configuration management
* Establish standards, methods, and automated tools

- Operations Management
(Who monitors the services? who monitors performance? How should error notification be addressed? who manages issues raised by the use of services across multiple environments?)

Key procedures
* Service monitoring
* Performance management
* Problem management

Mitigations
* leverage coordinator roles
* Identify stakeholders early
Metrics


Closed-loop SOA governance model
- Planning
- Design
- Development
- Testing
- Deployment
- Management

SOA governance model content (within model / process)
- SOA governannce procedures
- Oraanizational structures, roles, & responsibilities
- SOA Policy Compliance Tool
- Supporting Templates

HP SOA Governance Software Tools
Business Technology Optimization for SOA
SOA Governance (SOA Center, HP SOA Solution) (GIF - Governance Interoperability Framework)
- HP SOA Systinet
- HP SOA Policy Enforcer
- HP SOA Registry

SOA Quality (Applications)
- Quality Center with STM (Service Test Management, 70% market share)
- HP Unified Functional Test and Service Test (func testing)

SOA Management (IT operations)
- HP Business Availability Center (BAC) (Enterprise management)
- HP Diagnostics for SOA (Project focus)

SOA Security

Authentication

Authorization and Access Control

- Logically separating duties into Policy Decision Points (PDPs) and Policy Enforcement Points (PEPs)

Two types of Access Control

- Discretionary Access Control (DAC) (based on permissions, roles, attributes, and groups)

- Mandtory Access Control (MAC) (restricts access based on the security clearances and formal accesses of subjects and the security labels on the resources)

WS-Security SOAP Messaging

- Security Assertion Markup Language (SAML) Token

- WS-Security X.509 Certicate Token

- WS-Security Kerberos Token

- WS-Security Username Token

WS-Truse

- Security Token Servie (STS)

WS-Federation

WS-SecureConversation

WS-Policy

WS-SecurityPolicy

SAML

XACML (expressive) (data flow diagram)

XML Signature (XML-SIG or XML-DSIG)

XML Encryption

Separation of Security into Components and Services

Authentication and Identity Blueprints

- Identity Propagation for SSO Solutions (direct truse, transitive truse (service Provider trusts the identity of user based on an assertion of another party))

- Identity Propagation within an Application Server or ESB
- Assigtning Attesting Trust to a Limited Number of Entities

- Using a Trusted Token Service

- Identity Propagation with REST Using Browser SSO

Decision Diagram for Propagation and Trust - How Do You Decide?

Access Control Blueprints

- Controlling Access to Data, Not Just Services

Access Control Policy Enforcement Approaches

- The Purely Centralized PDP Model with Global Policy

- The Purely Decentralized PDP/PEP Model with Attribute Propagation

- Decentralized PDP/PEP with Identity Propagation

- Combining Local and Global Enterprise Policy

- Predetermined Authorization Decision-Based Models (PADBAC) (digital ly signed)

Decision Flow Chart for Access Control - How Do You Decide?

Designing SOA

Business Architecture

- Enterprise Business Architecture

- Project Business Architecture

- Value Chain (supporting activities, primary activities)

- Business Context

Open Group Business Architecture Views: (strategy, organization, process)

- People

- Process

- Function

- Business Information

- Usability

- Performance

The business architecture view is derived from business scenarios, where each scenario is defined by describing the problem, environment, objective, human actors, system actors,a nd roles and responsibilities.

Business architecture focuses on aligning business strategy with IT implementation, by:

- Identifying goals and strategy

- Identifying organizational structures and governance and their impact on strategy

- Applying the strategy across the entire enterprise

- Aligning with external entities

- Identifying quantifiable outcomes tomeasure the strategy

- Identifying the processes, rules, and information necessary to support the outcomes

- Managing and synchronizing the process model, business rules model, and information models

EterpriseBusiness Architecture

- Formalizing b usiness strategy into goals and outcomes

- Identifying common enterprise business semantics- Identifying common enterprise processes and rules

- Identifying enterprise opportunities and value

- Developing strategic roadmaps

- Providing alignment and innovation

- Considering competitive forces and competitive strategies

- Aligning with external organizations (the virtual enterprise)

Project Business Architecture

- Context diagrams

- Process models

- Information models

- Integration of enterprise semantics into project models

- Integration of enterprise semantics, common processes, and services into the project design

Areas of Business Motivation Model (BRG & OMG)

- The Ends and Means of businessplans

- The Influencers

Means->**->Ends

Mission->operationalize->Vision

Strategy->support->Goal

Tactic->achieve->Objective

Policy

Rule

Create Business Process Models

- Use Cases (Multiple Scenarios)

- Documents (information passed between steps in a process)

Organizing Services

- Keep the models focused on the business

- by business competencies and responsibilities

- along subject matter domains

The Service Inventory

- Enterprise Business Processes

- Business Services

- Domain Services

- Utility Services

- Foundation Services

Three levels of interoperability maturity

1. Project-specific interoperability

2. Business domain-specific interoperability

3. Business domain-independent interoperability

Service Context and Common Semantics

- Core Information Modeling (Objects, Attributes, Instances)

- Defining Types

- Identifiers and Uniqueness Constraints

- Specializations

- Derived Attributes

Structuring Information Models

- split into clusters of closely related objects (package)

- Documents can be thought of as hierarchical data structures with a main part and several, often nested, repeating parts.

Best Practices

- Using Abstraction to Avoid "SOA Stovepipes"

- Reuse Standards to Avoid Reinventing the Wheel (using enterprise semantics, using business-domain semantics)

- Develop Information Models Based on Use Cases

Designing Service Interfaces

Aspects of a service

- Interface (Service Operations, Common Business Semantic)

- Implementation ( Internal Functionality, Internal Data)

Service Characteristics

- Granularity

- Scope

- Visibility (range of users that are allowed to see the existence of a service)

- Interaction Styles (how information is passed into and out of the service, also called MEP) (Parameter Passing, Document Passing, Data Passing (data access), Request/Reply, Event, Mixed, )

Design Guidelines

- Isolating Responsibilities

- Understanding Overall Context

- Identifying Granularity

- Stateless Interfaces (Execution State vs. Invocation State)

- Exceptions (application exceptions, system exceptions)

- Designing Documents

Interface Design

Describing the business model can start with either the business process scenario or the information model (or both).

*Process-(or behavior-) centered aproach is more goal-oriented, providing a better link to the business requirements and processes.

Formal Versus Informal Specifications

- Informal specifications that are meant to communicate to a nontechnical audience

- formal specifications for complete and procise

Solution Model

- Refines the business concepts (processes, activities, entities, and documents) into SOA technology concepts of services, interfaces, operations, documents, and information)

The basic process is to work through each of the detailed business scenarios and evaluate every activity in the scenario as being implemented by servcie.

Three possible options:

- Define it as a manual task

- Assign it to a service operation. This is done either by creating a new service for it, or assigning it to an existing service

- Defer it as an internal task of another service. This often respresents a lower-level service that is part of the composition of the business service

Service Definition Diagrams

- Operations

- Documents

- Data Types

- Exceptions

- Associations

Basic Service Architecture (3 layers)

1. Service Interface Layer (Invocation, Syntactic validation, Data Transformation, Response)

2. Service Busness Layer (Semantic validation, Business Logic)

3. Resource Access Layer (Data Transformation, Resource Access)

Implementing the Interface Layer

- Implement the service contract

- Support interactios with the business layer responsible for the execution of the service functionality

- Perform syntactic data validation

Implementing the Business Layer

- Semantic validation of incoming parameters

- Sequence calls to other business logic, data access logic, other services or existing enterprise applications

- Conditional logic and business rule implementation

Service Composition

- Orchestration (Executable Business Process / Process Flow Focused)

- Choreography (Messaging and Rules / Conversational State Focused)

Hierarchical and Conversational Composition

- "Black Box" Composite Service

- Conversational Composite Service (Mediator)

Conductor-Based and Peer-to-Peer Composition

Service Component Architecture Composition

- Specifies how to create components, combine them, and expose the component assembly as a service

Event-Based Composition

Orchestration Engine-Based Composition

service Composition and Transactions

- The requirements of the Two-Phase Commit (2PC) conflict with the loosely coupled nature services

- An alternative to 2PC, supported by the majority of BPM engines, is compensation - invocation of business logic that can be called in case of a failure.

Enterprise Service Bus - Unified Infrastructure for Enterprise Soutions

ESB imnplementation

- Stand-alone ESB

- ESB as a service container

- ESB as a framework

Designing and Using Integration in SOA Solutions

*Treat integration as a specialized type of service - an integration service

*An additional element (business component) is introduced to the overall business service implementation

*Business components are not only building blocks for the business service but also a layer of abstractions for integration access.

Additional layers for Integration:
- Enterprise Resources and Operational Systems (existing systems)
- Integration Access (access to an existing application's functionality)
- Business components (deployable units of software that provide the (integration) functionality required by the business services

Integration Access Implementations
- Enterprise maturity in the EAI/integration space (existing middleware (messaging infrastructure) can be levferaged)
- Composition of the existing application portfolio (use packaged applications' Web Services)
- Business service implementation platform (e.g. J2EE server prepackage adapters (JCA/J2C)
- Integrated application implementation (Web Service wrappers)
- Type of integration(e.g. JDBC)

Data Mapping in Integration

- Implementing data mapping as part of the integration access implementation

- Implementing data mapping as part of the message delivery

Security Support for Integration

- Accommodate heterogeneity (i.e., multiple application platforms)

- Provide security management and identity propagation/management across multiple security domains (internal, external, and business unit silo)

- Support multiple security credentials that can identify subjects (and optionally, their authorization credentials (kerberos, SAML, etc))

- Support multiple transport protocols (HTTPS, JMS, MQ)

- Provide a mechanism for maintaining the "thread of identity" across the integration services invocations

Implementation of security support for integration

- Propagating the user identity as a part of the invocation of integration services

- Converting the user identity into a form required by a specific legacy application

Transactional Support in Integration (ACID)

- Atomic

- Consistent

- Isolated

- Durable

Dealing with Large Messages - Message Storage Area

Data Virtualization and Enterprise Data Bus

The additional layer - data virtualization - provides access to the enterprise data contained in either enterprise applications or their subordinated databasees. Business components are composed only of the components that implement service functionality based on existing application functionality, and data that is accessible through the Enterprise Data Bus.

Approaches to EDB implementation:

- Specialized server (e.g. IBM Information Server)

- Providing support for both direct database access and integration, and distributed data caching (e.g. IBM's Object Grid)

SOA Design Strategies

Architectural Principles and Practices
- Separation of corcerns
- Architectural views
- Accommodation of change (flexibility)
- Abstraction
- Consistency
- Business derivation
- Facilitation
- Communications

Important Parts of Architecture
- Processes (high-level business functions, often spanning applications or LOBs)
- Services (Modular units of business functionality)
- Integration (Connection to and exposure of existing applications and/or data as services
- Existing systems ( Existing legacy systems, commercial COTS applications, and data that the enterprise wants to leverage
- Documents (high-l.evel units of business information, such as a purchase order, or an EDI document
- Semantics (the underlying meaning of information that is exchanged in processes)
- Transformation (the conversion of information from one format or semantic to another)
- Communications (the ability of services to communicate with each other)

Layered SOA architecture
- Business Process (Enterprise Data [Documents])
- Business Services (Consolidated Data [Semantic Objects])
- Integration Services (Integration Data [Transformation])
- Enterprise Resources (Operational Data [SOR])

SOA aspects of services within an enterprise
- Defining a Service (domain, business, enterprise business process etc.)
- Defining How Services Are Built and Used (Granularity, Type or style of interface, Configuration mechanisms, Other artifacts, Associated information, Dependency management and other patterns)
- Integrating Packaged and Legacy Systems into the Service Environment
- Combining Services into Enterprise Processes
- Specifying the Technology Infrastructure (Communications mechanism, Failover mechanisms, Discovery and location transparency)
- Defining Common Semantics and Data
- Aligning Services with the Business
- Determining How to Use the Architecture

EA and SOA Compared
Business Architecture <-> Business Model
Information Architecture <-> Common Semantics and Data
Technology Architecture <->Service Bus (infrastructure, distributrion, binding, security, performance, etc)
Application Architecture <-> Service, Data, Integration Service, Enterprise Business Process

Software Architecture (4+1 Views)
- Logical View (abstract, platfor, and technology-independent)
- Component View (organized arougn services or service groups)
- Process View (how artifacts assigned to executable processes)
- Physical View (machines, programs, network nodes, hosts, etc)
- Use Cases (in the middle) (capabilities of the system envisioned by end consumer)

Service Contract Includes:
- Service interface
- Interface documents
- Service policies
- Quality of service (QoS)
- Performance

Good Service Characteristics
- Modularity and granularity
- Encapsulation
- Loose coupling
- Isolation of responsibilities
- Autonomy
- Reuse
- Dynamic discovery and binding
- Stateless
- Self-describing
- Composable
- Governed by policy
- Independent of location, language, and protocol

Levels of Granularity
- Enterprise business processes
- Business services
- Domain services
- Utility services (lower-level services that provide common functionality across the enterprise)
- Integration services (expose existing applications as services)
- External services
- Foundation services (fine-grained capabilities used in higher-level services)

Service Dimensions
- Scope
- Ownership
- Granularity
- Construction

Service Types
- Task services
- Entity services
- Decision services

SOA Reference Architecture


SOA Implementation Methodology




*Business Processes
- A group of logically related (and typical sequenced) activities that use the resources of the organization ot provide defined results.

*Information Design
- The semantic data is not the same as the domain data. It defines the information that must be common between processes.
- The semantic information model defines the messages exchanged by services.
- It is possible to introduce the notion of passing the service execution context around as part of the service invocation "thread". In this case, the service interface operations are massively polymorphic and expressed as:

Service.method (XML context in, XML context out)
*Service Identification
- Instead of attempting to decompose applications, it decomposes entire enterprise IT functionality
- A better decomposition approach is based on the decomposition of the enterprise-wide business model

*Service Specification
Business users need to understand what a service does in business terms, which requires answers to the following questions:
- What does the service provide for prospective clients? This includes a description of what is accomplished by the service, limitations on service applicability and quality of service (QoS), and requirements that the service requester must satisfy to use the service succssfully
- How is the service used? This includes a detailed definition of the content of service requests and responses, the conditions under which particular outcomes occur, and, when necessary, a step-by-step description of processes leaing to those outcomes

Technical users need to know how to implement service operations that require answering the following questions:
- How the interact with services? This specifies a communication protocol, message formats, including serialization techniques and service locations
- What are the service invocation policies? This defines specific requirements for service invocation, (security, SOAP headers, etc)
- What are service QoS guarantees? This specifies the quality-of-service characteristics that the service provides, including response time, throughput, availability, planned maintenance, etc

Service Expectations
Interaction Model
- Information model
- Process (behavioral) model
- Service execution model

Service Constraints
- Business-oriented policies (hours of operation, return policies, etc)
- Infrastructure-oriented policies (security, privacy, manageability, performance, etc)

Service Location
*Service Realization
- Buy
- Outsource (rent)
- Build

Buying Services
- Functional alignment with the overall business model, service decomposition, and service inventory
- usage of the enterprise semantic information model for service interface definitions
- Support for the enterprise service infrastructure, including security, logging, exception handling, and so on

Outsourcing Services
- Designed foruse by customers through the Internet
- Hosted off-premises, not on the customer's premises
- Governed by a service contract

Two common approaches to incorporating SaaS into an overall SOA


Building Services
- Service Component Architecture (SCA)
- SCA specifies how to create components, combine them, and expose the component assembly as a service
- SCA defines a common assembly mechanism to specify how those components are combined and exposed as a set of services


Service implementation concerns


Service Life Cycle
1. Service identification
2. Service design and specification
3. Service implementation
4. Service deployment
5. Service usage and enhancement
6. Service retirement

SOA Governance includes
- Policies regulating service definition and enhancements, including ownership, roles, criteria, review guidelines, etc
- Identification of roles, responsibilities, and owners
- Policy enforcement that is integrated directly into the service repository (where appropriate)
- Guidelines, templates, checklists, and examples that make it easy to conform to governance requirements
- Review of service interface definitions fornew services and enhancements to existing services
- Architectural review of applications and services to ensure that they conform to the SOA and EA

*The Service Design Process
Top-Down Approaches
- Enterprise System Analysis
- Business Process Model

Bottom-Up Approaches
- Utility Services
- Service Enabling

Middle-Out
- Business Summary (Activities, Artifacts, Repositories, Governance)
- Process Phases (Architectural Context, Business, Desing, Implementation, Test)

CMMI-Dev Process Areas

Basic Project Management
- Requirements Management (REQM)
* Specific Goal 1: Requirements are managed and inconsistencies with project plans and work products are identified

- Project Planning (PP)
* SG1: Establish Estimate
* SG2: Develop a Project Plan
* SG3: Obtain Commitment to the Plan

- Project Monitoring and Control (PMC)
* SG1: Monitor Project Against Plan
* SG2: Manage Corrective Action to Closure

- Supplier Agreement Management (SAM)
* SG1: Establish Supplier Agreements
* SG2: Satisfy Supplier Agreements

Support
Basic Support Process Areas
- Configuration Management (CM)
* SG1: Establish Baselines
* SG2: Track and Control Changes
* SG3: Establish Integrity

- Measurement and Analysis (MA)
* SG1: Align Measurement and Analysis Activities
* SG2: Provide Measurement Results

- Process and Product Quality Assurance (PPQA) (L2)
* SG1: Objectively Evaluate Processes and Work Products
* SG2: Provide Objective Insight

Advanced Support Process Areas
- Decision Analysis and Resolution (DAR) (L3)
* SG1: Evaluate Alternatives

- Causal Analysis and Resolution (CAR) (L5)

Process Management
Basic Process Areas
- Organizational Process Focus (OPF) (L3)
* SG1: Determine Process Improvement Opportunities
* SG2: Plan and Implement Process Imporvements
* SG3: Deploy Organizational Process Assets and Incorporate Lessons Learned

- Organizational Process Definition (OPD) (L3)
* SG1: Establish Organizational Process Assets

- Organizational Training (OT) (L3)
* SG1: Establish an Organizational Training Capability
* SG2: Provide Necessary Training

Advanced Process Areas
- Organizational Process Performance (OPP) (L4)
- Organizational Innovation and Deployment (OID) (L5)

Advanced Project Management
- Risk Management (RSKM) (L3)
* SG1: Prepare for Risk Management
* SG2: Identify and Analyze Risks
* SG3: Mitigate Risks

- Integrated Project Management (IPM) (L3)
* SG1: Use the Project's Defined Process (tailored from standard processes)
* SG2: Coordinate and Collaborate with Relevant Stakeholders

- Quantitative Project Management (QPM) (L4)

Engineering
Process Areas
- Requirements Development (RD) (L3)
* SG1: Develop Customer Requirements
* SG2: Develop Product Requirements
* SG3: Analyze and Validate Requirements

- Technical Solution (TS) (L3)
* SG1: Select Product Component Solutions
* SG2: Develop the Design
* SG3: Implement the Product Design

- Product Integration (PI) (L3)
* SG1: Prepare for Product Integration
* SG2: Ensure Interface Compatibility
* SG3: Assemble Product Components and Deliver the Product

- Verification (VER) (L3)
* SG1: Prepare for Verification
* SG2: Perform Peer Reviews
* SG3: Verify Selected Work Products

- Validation (VAL) (L3)
* SG1: Prepare for Validation
* SG2: Validate Product or Product Components

CMMI

Software Capability Matureity Model (SW CMM)

Three Critical Dimensions

- People

- Procedures and methods

- Tools and equipment

Processes hold them all tegether

CMMI framework is the structure that organizes that components used in generating models, training materials, and appraisal methods

CMMI product suite is the full collection of models, training materials, and appraisal methods generated from the CMMI framework

CMMI Structure

At the heart of CMMI are Process Areas (PAs). They are a cluster of practices in an area that when implemented collectively satisfy a goal that is considered important in making improvement in an area

A Comstellation (combination of PAs) may be viewed in 2 different representations

- Staged Represntation (Predefined set of PAs at each level)

- Continuous Representation (Single PA)

Three Complementary Constellations

- CMMI-DEV

- CMMI-SVC

- CMMI-ACQ

16 Core Process Areas used in all

Level 1 - Initial

- NONE

Level 2 -Managed

- Requirements Mnagement (Project Mgmt)

- Project Planning (Project Mgmt)

- Project Monitoring and Control (Project Mgmt)

- Measurement and Analysis (Support)

- Process and Product Quality Assurance (Support)

- Configuration Management (Support)

Level 3 - Defined

- Orgtanizational Process Focus (Process Mgmt)

- Organizational Process Definition (Process Mgmt)

- Organizational Training (Process Mgmt)

- Integrated Project Management (Process Mgmt)

- Risk Management (Project Mgmt)

- Decision Analysis and Resolution (Support)

Level 4 - Quantitatively Managed

- Quantitative Project Management (Project Mgmt)

- Organizational Process Performance (Process Mgmt)

Level 5 - Optimized

- Casual Analysis and Resolution (Support)

- Organizational Innovation and Deployment (Process Mgmt)

6 Additional CMMI-Dev Process Area

Level 2 - Managed

- Supplier Agreement Management

Level 3 - Defined

- Requirements Development

- Technical Solution

- Product Integration

- Verification

- Validation

General Practices Goals (Level 2)

- GP2.1: Establish an organizational policy

- GP2.2: Plan the Process

- GP2.3: Provide Resources (People, Facilities, and Tools)

- GP2.4: Assign Responsibility (for all tasks)

- GP2.5: Train People

- GP2.6: Manage Configurations (Version and Change Control)

- GP2.7: Identify and Involve Relevant Stakeholders

- GP2.8: Monitor and Control the Process

- GP2.9: Objectively Evaluate Adherence (Audits of the processes followed)

- GP2.10: Review Status with Higher Level Management

General Practices Goals (Level 3)

- Includes all Level 2 Generic Goals

- GP3.1: Establish a Defined Process

- GP3.2: Collect Improvement Information

In the Continuous Representation view, Capability Levels are used instead of Maturity Levels

With the Continuous representation the PAs are grouped ito Categories

- Process Management

- Project Management

- Support

Withing each Constellation, fourth category focused on that domain

- Engineering (CMMI-Dev)

- Acquisition (CMMI-ACQ)

-Service Establishment and Delivery (CMMI-SVC)

Capability Level 3 Must Satisfy:

Specific Goals:

And Generic Goal:

- GP2.1 to 2.10

- GP3.1 to 3.2

Capability Level 4 Must Satisfy:

- All Goals in Level 3

And

Capability Level 5 Must Satisfy:
- All Goals in Level 4
And

WebSphere AS Architecture

Three-tier architecture

- Presentation Layer (Client)

- Application Logic Layer

- Network Resources

Packages

WAS-XD improves system availability, maintaining multiple instances of key components so that services can be switched from one server to another.

WAS-EE improve many different aspects of the network's operation. For example, the APIs included in Extended Messaging Support make it easier to deal with incoming asynchronous messages. Other extensions allow you to process query statements at runtime, support interruptible and compensated workflows, and manage transactions better.

WebSphere components

- EJB Container

- Web Container

- Application Client Container

- Applet Container

- Embedded HTTP Server

- Virtual Host (Fence off data, only makeing it accessible to resources installed on the same virtual host)

Support for EJB

- Local, remote, and message-driven beans

- Container-managed relationships and association relationships

- Portable finder query language

- Programming model

- Abstract and Concrete entity beans

- Local Home and Local Entity Interfaces

- EJB query language

Enhancement Features

- Changing semantic behavior

- Entity bean inheritance

- Optimistic concurrency control

- Read-ahead (minimize the number of database roundtrips by retrieving a working set of container-managed persistence (CMP) beans for the transaction within one query)

- Intent mechanism support

- Backend access support

- SQLJ

- Data caching

Enhance CMP performance

- bean data caching

- long lifetime caching

- optimistic currency control

- read-ahead

Activity Session (enables the user to group transactions into work units. You can associate various properties and configurations with an activity session)

Web Services Functionality

- Application lifecycle events

- autoRequestEncoding and autoResponseEncoding

- Classes and servlets

- Filters

- HTTP session support (in-memory, persistent-to-database, memory-to-memory)

Common Object Request Broker Architecture (CORBA) clients can access WebSphere Application Server CORBA C++ servers and WebSphere Application Server EJB servers. WebSphere also provides a basic CORBA environment that can bootstrap into the J2EE name space and invoke J2EE transactions. New support features include SSL security for CORBA C++ clients.

Web Service Support

- XML

- UDDI

- SOAP

- WSDL

Naming Support

- Instead of binding an object, it is bound to the server root context, or a context specific to the server associated with the object.

-Name Server runs in its own process instead of the administrative server's process

Changes to dynamic caching

- caching support (servlet and JSP results caching, command caching, pattern caching, and web services caching)

- dynamic caching engine (disk overflow, Least Recently Used (LRU), mgmt, XML cache policy mgmt, invalidation mgmt, and external cache support for IBM WebSphere Edge and IBM HTP Server Fast Response Cashe Accelerator)

- dynamic network caching (caching is performed within the context of J2EE and caching behavior is described in XML cache policy files)

- dynamic servlet caching (by configuring caching through the cachespec.xml file format)

I18N

- Change Currency

- Change character sets

Application and Service choreography

WebSphere Platform Infrastructure

- node

- configuration repository

- virtual hosts (is not linked to a specific node, it can be created, but cannot be started or stopped)

- admin service

- session database (for multiserver environment)

- scripting client

Network Deployment platform components

- Support multiple nodes. Each node has a node agent component and a number of application servers. These are all run within an administrative unit called a cell, which resides within the Deployment Manager. You can use a Network Deployment cell to configure clusters of load-balanced application servers.

- The Deployment Manager administers the configuration and application binaries of the components in a cell. They are divided out to local copies on each node.

Edge Components offer an efficient and economic means of hosting web-accessible content and providing Internet access. The software typically runs on machines that are in proximity to the boundary between an enterprise intranet and the Internet.

Edge Components include the caching proxy and load balancer, which help administrators to provide improved levels of service to internal and external users with access to documents on enterprise server machines.

A cluster is a logical arrangement of application server processes designed for workload balancing. Application servers that are part of a cluster are "members" of that cluster and must have identical application components deployed on them. Cluster members are not required to share any configuration data.

Cluster members can be situated on a single node (vertical cluster), over a number of nodes (horizontal cluster), or a mixture of the two.

Managed Servers or Processes

- Deployment Manager (Network Deployment Only)

- Node Agent (Network Deployment Only)

- Application Server (Base and Network Deployment)

- JMS Server (Network Deployment Only)

Network Deplyment

- Multiple WAS instances

1. Application Servers (multiple instances from a single installation of WAS)

2. Deployment Manager (multiple instances from a single installation of Network Deployment)

- Multiple server instances using a single installation (It is possible to configure multiple Deployment Managers for a single Network Deployment installation but these Deployment Managers are incapable of providing mutual failover or clustering support)

- Coexistence of WAS and ND

- Disadvantage: if something happens to either the WebSphere Application Server or Deployment Manager that results in the reconstruction of the node, the other component needs to be relocated

- A Single web server for coexisting, multiversion application servers on one machine

- A Single web server for multiple instances of WAS

- Standalone web servers for each application server instance when running multiple instances of WAS

Topology Considerations

- Availability (Horizontal scaling, Vertical Scaling, IP sprayer)

1. Hardware and process redundancy

2. Process Isolation

3. Load balancing

4. Failover support

5. Hardware-based high availability

- Maintainability (Inherent considerations for updating system hardware and software. Maintainability can clash with other topology considerations and can lead to shortcomings in throughput, performance, and availability)

- Performance

1. Vertical scaling: provision of software/application server failover as well as load balancing over a number of JVM application server processes. It enables an administrator to examine an existing application server for performance holdups.

2. Horizontal scaling: Creation of extra application server processes on multiple physical machines, harnesses additional processing power from each machine. This provides hardware failover support, and an administrator can apportion implementation costs among multiple physical machines.

- Security (A recommended security configuration is to use two firewalls to create a demilitarized zone (DMZ). Information in the DMZ is somewhat protected due to protocol filtering between the Internet and the DMZ. A web server can intercept requests and direct them through the next firewall. The vulnerable application and business data elements exist intthe space behind the second firewall, which filters by IP address or domain)

- Session Management

1. Database persistance

2. Memory-to-Memory Replication (replication of session data between the memories of individual application server JVMs. WebSphere internal Messaging is a JMS publish/subscribe mechanism that provides assured session replication between the JVM processes. It does this by leveraging the internal JMS provider provided with WebSphere Application Server and so a database product is not essential for persistence.

- Scalability (Configure multiple machines to boost processing power, enhance security, maximize availability, and balance workloads)

1. WebSphere Application Server cluster support

2. WebSphere workload management (WLM) (in front of clustering)

3. IP sprayer (Redirects incoming HTTP requests transparently from web clients to a group of web servers. Intercepts all requests and disseminates them to the full range of web servers in the group. IP sprayers such as Cisco Local Director provide scalability, load balancing, and failover for web servers)

Topology Terminology

1. Web Presentation Server Node

2. Database Server Node

3. Domain and Protocol Firewall Nodes

4. Directory and Security Services Node

5. Web Application Server Node

6. Web Server Redirector node and application server Node

7. Load Balancer Node

8. Deployment Manager

Supported Network Topologies

1. Vertical Scaling (multiple app server instances on a single machine)

2. HTTP server separation

2.1 Supporting Network Address Translation (NAT) firewalls

2.2 Preventing data access from DMZ

2.3 Underpinning load balancing and failover

2.4 Simplifying administration

2.5 Alleviating congestion

2.6 Supporting Secure Sockets Layer (SSL) encryption

3. Reverse Proxy (resides in DMZ and forwards traffic to and from a web server, which now resides on the same machine as the application server)

4. Multi-Tiered (Divides the application server processes into servlet application servers (close to HTTP server) and EJB application servers (close to application data). This is beneficial from security and performance perspectives)

5. Horizontal Scaling with Clusters

6. Horizontal Scaling with IP Sprayer

Simple IP Sprayer

Complex IP Sprayer

7. Multiple WebSphere cells

Advantages

1. Isolates hardware and software failure

2. Prevents outages

3. Improves Performance

8. Multiple Clusters on a node

Advantages

1. Enhanced throughput

2. Improved performance

3. Hardware failover

4. Application software failover

5. Process isolation

9. Combined

- Two WebSphere cells

- Two load balancer nodes

- Two HTTP servers for each cell with the web server plug-in

- Four application server machines for each cell

- The use of application server clusters for both vertical and horizontal scaling

- Two database servers for each cell, which host mirrored copies of the application database