64
© 2014 Hans-Peter Hoidn & Kai Schwidder Enterprise IT Architectures Technology Architecture, Information Systems Architecture and SOA (Service Oriented Architecture) Dr. Hans-Peter Hoidn Distinguished IT Architect (Open Group certified)

Enterprise IT Architectures - UZH IfI00000000-27f1-cdaa... · Enterprise IT Architectures Reference Architectures – Overview ! ... SOA Reference Architecture ... Web, e-business

  • Upload
    dophuc

  • View
    233

  • Download
    0

Embed Size (px)

Citation preview

© 2014 Hans-Peter Hoidn & Kai Schwidder

Enterprise IT Architectures Technology Architecture, Information Systems Architecture and SOA (Service Oriented Architecture)

Dr. Hans-Peter Hoidn Distinguished IT Architect (Open Group certified)

© 2014 Hans-Peter Hoidn & Kai Schwidder 2

Enterprise IT Architectures

Technology Architecture

© 2014 Hans-Peter Hoidn & Kai Schwidder 3

Enterprise IT Architectures

Technology Architecture – Purpose

§ provides the information for the physical implementation – Mapping from logical to physical – Dealing with the distribution of components to nodes

§ Is heavily influenced by Technology Development – Defines a Technology “Platform” –  Provides the basis for the implementation of the solutions

§ Patterns and Reference Architectures play a major role: – Reference Architectures are seen as Patterns –  E.g. SOA Reference Architecture –  E.g. Cloud Reference Architecture

© 2014 Hans-Peter Hoidn & Kai Schwidder 4

Enterprise IT Architectures

First Step for “Technology Architecture” (some key words highlighted)

§ Review and validate the set of technology principles. These will normally form part of an overarching set of architecture principles

§ Select relevant Technology Architecture resources (reference models, patterns, etc.)

§ Select relevant Technology Architecture viewpoints that will enable the architect to demonstrate how the stakeholder concerns are being addressed in the Technology Architecture

§ Identify appropriate tools and techniques to be used for capture, modeling, and analysis, in association with the selected viewpoints

© 2014 Hans-Peter Hoidn & Kai Schwidder 5

Enterprise IT Architectures

§  Defines the essential guidance (rules) for selecting, building and maintaining a technical infrastructure composed of a set of hardware and software environments and platforms with defined interfaces, standards & services

§  Defines the nodes, components, connections, collaborations and locations required

§  Is based largely on proven architectural patterns, reference models or templates for the domains

§  Provides design guidance, where appropriate, for developers

§  Provides a framework for setting technology and product standards

TECHNOLOGY ARCHITECTURE

encapsulates

PRODUCTS

aggregatesaggregates

is implemented by

located on

implements

*

**

*is part of

*NODES

OPERATIONAL STRUCTURE

FUNCTIONAL STRUCTURE

DOMAINS

COMPONENTS

*

*

**

TECHNOLOGY ARCHITECTURE

encapsulates

PRODUCTS

aggregatesaggregates

is implemented by

located on

implements

*

**

*is part of

*NODES

OPERATIONAL STRUCTURE

FUNCTIONAL STRUCTURE

DOMAINS

COMPONENTS

*

*

**

Technology Architecture – Overview

Source: IBM Architectural Thinking

© 2014 Hans-Peter Hoidn & Kai Schwidder 6

Enterprise IT Architectures

Components Technology “ Building blocks ” – often “ standards ”

Nodes Operational Model Assemblies of nodes required for common solutions

Band 1 Band 2 Band 3

Firewalls Web

Server Web

Portal Web App Server

Session State Mgmt

Content Mgmt Integration

Server ID &

Authentication Coarse

grained Auth Audit Data

Collection & Storage Public

Credential Repository

Corporate Apps &

components Corporate Operational

DB Dept 3

Operatonal DB Dept 3

Unique/ Legacy Apps

Dept 3 Unique/Legacy Operatonal DB Dept 3

Apps & Components

Dept 2 Operatonal

DB Dept 2 Unique/

Legacy Apps Dept 2

Unique/Legacy Operatonal DB

Dept 2 Apps &

Components Dept 1

Operatonal DB Dept 1

Unique/ Legacy Apps

Dept 1 Unique/Legacy Operatonal DB Dept 1

Apps & Components

Placement : Implementation guidance

E.g. RDBMS ANSI SQL 92

E.g. Operational Database E.g. Data Warehouse E.g. B2P Pattern E.g. B2P Placement

Standards Criteria

Logical Servers Logical Clients

Source: IBM Architectural Thinking

Technology Architecture – Guidance described in accordance with four key aspects

© 2014 Hans-Peter Hoidn & Kai Schwidder 7

Enterprise IT Architectures

Serv

ice &

Sys

tem

s Man

agem

ent T

echn

olog

ies

Integration Services

Deve

lopm

ent

User & Interaction Services

Application & Information Services

Client Applications Common Client Services Interaction Services

Application & Process Integration Infrastructure Integration

Enterprise Applications Details will be handled in Application

Functional Model

Common Application Svcs Information services

Infrastructure

Facilities & Environment

Network & Communication

Physical Infrastructure Platform Services

Service Planing

Service Testing

Service Development

Service Deployment

BPM

Methods / Project

Development Platform

Service Delivery

Security Services

IT Service Management

Sample Technology Framework: Level 1

© 2014 Hans-Peter Hoidn & Kai Schwidder 8

Enterprise IT Architectures

Serv

ice &

Sys

tem

s Man

agem

ent T

echn

olog

ies

Integration Services

Deve

lopm

ent

User & Interaction Services

Application & Information Services

Client Applications Common Client Services Interaction Services

Spreadsheet

Presentation

Drawing

Word Processing Client Utility/IES Portlet

Client Connectivity Web Browser

Application & Process Integration Infrastructure Integration Messaging

Mediation

Process Orchestration

Workflow

Connetivity/Broker/ESB

File Transfer

Data Access/Data Integration

Directory

Enterprise Applications Details will be handled in Application Functional Model

Common Application Svcs Information services

ERP

SCM

CRM

PLM

HR

Finance

In/Out Passing Operatioinal Data

Data Watrehouse

Analytical Data

MasterData

Portal

Publishing

Collaboration

Mail

Data Mgmt

Document Mgmt

Content Mgmt

Infrastructure

Facilities & Environment RACK Power

Network & Communication WAN LAN Router Firewall Voice o IP Gateway

Physical Infrastructure Platform Services Client

Storage

Peripherals

Server

Service Planing

Service Testing

Service Development

Service Deployment

BPM

Methods/Project

Project Mgmt

Development Platform

Service Delivery

Security Services

Authentication Security Mgmt

Authorization Idenity Mgmt Access Mgmt

Virus Protection SSO

Encryption

Info Sec Mgmt

IT Service Management

Incident Mgmt Change Mgmt Config Mgmt

Problem Mgmt Release Mgmt

Backup/Restore

System Mgmt Tool

Service Catalog

Network Mgmt IT Service Mgmt

Storage Mgmt

Deployment

Archive SW Distribution

Automation

Capacity Mgmt Availability Mgmt Financial Mgmt

SLM

Directory

OS

Virtualisation

High Availability

Job Scheduler

Load Balancing

DBMS

Application Server

Transaction Server

Web Server

Sample Technology Framework: Level 2

© 2014 Hans-Peter Hoidn & Kai Schwidder 9

Enterprise IT Architectures

Serv

ice &

Sys

tem

s Man

agem

ent T

echn

olog

ies

Integration Services

Deve

lopm

ent

User & Interaction Services

Application & Information Services

Client Applications Common Client Services Interaction Services

Spreadsheet

Presentation

Drawing

Word Processing Client Utility/IES Portlet

Client Connectivity Web Browser

Application & Process Integration Infrastructure Integration Messaging

Mediation

Process Orchestration

Workflow

Connetivity/Broker/ESB

File Transfer

Data Access/data Integration

Directory

Enterprise Applications Details will be handled in Application Functional Model

Common Application Svcs Information services

ERP

SCM

CRM

PLM

HR

Finance

In/Out Passing Operatioinal Data

Data Watrehouse

Analytical Data

MasterData

Portal

Publishing

Collaboration

Mail

Data Mgmt

Document Mgmt

Content Mgmt

Chat Video Conf

Blogg Inst Messaging

Infrastructure

Facilities & Environment RACK Power

Network & Communication WAN LAN Router Firewall Voice o IP Gateway

Physical Infrastructure Platform Services Client

Storage

Peripherals Thin Client

Phone Mobile

Server

Desktop PDA

Laptop Shipfloor

Tape Local SAN

Mainframe Midrange X86

Printer 3G

OS

Virtualisation

High Availability

Job Scheduler

Load Balancing

Service Planing

Service Testing

Service Development

Service Deployment

BPM

Methods/Project

Project Mgmt

Development Platform

Inventory

Service Delivery

Security Services

IT Service Management

Incident Mgmt Change Mgmt Config Mgmt

Problem Mgmt Release Mgmt

Capacity Mgmt Availability Mgmt

Backup/Restore

System Mgmt Tool

Financial Mgmt

Service Catalog

SLM

Authentication Security Mgmt

Authorization Idenity Mgmt Access Mgmt

Virus Protection SSO

Encryption

Info Sec Mgmt

Network Mgmt IT Service Mgmt

Storage Mgmt

Deployment

Archive SW Distribution

Automation

Directory

DBMS

Application Server

Transaction Server

Web Server

DB Engine

Sample Technology Framework: Level 3

© 2014 Hans-Peter Hoidn & Kai Schwidder 10

Enterprise IT Architectures

§  The fundamental organization of an IT system, embodied in

–  its hardware, software and communications technology

–  their relationships to each other and the environment,

–  and the principles governing its design and evolution

Technology Architecture – Content according to TOGAF

© 2014 Hans-Peter Hoidn & Kai Schwidder 11

Enterprise IT Architectures

Technology Architecture – Objectives (TOGAF 12.1)

§ Develop the Target Technology Architecture that enables the logical and physical application and data components and the Architecture Vision, addressing the Request for Architecture Work and stakeholder concerns

§ Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures

© 2014 Hans-Peter Hoidn & Kai Schwidder 12

Enterprise IT Architectures

§ Select reference models, viewpoints, and tools § Develop Baseline Technology Architecture Description § Develop Target Technology Architecture Description § Perform gap analysis § Define candidate roadmap components § Resolve impacts across the Architecture Landscape § Conduct for mal stakeholder review § Finalize the Technology Architecture § Create Architecture Definition Document

Technology Architecture – Steps (TOGAF 12.4)

© 2014 Hans-Peter Hoidn & Kai Schwidder 13

Enterprise IT Architectures

Technology Architecture – Topics (TOGAF Pocket Guide)

§ Baseline Technology Architecture, if appropriate Target Technology Architecture, including:

–  Technology components and their relationships to information systems

–  Technology platforms and their decomposition, showing the combinations of

§ Technology required to realize a particular technology “stack” –  Environments and locations – a grouping of the required

technology into computing environments (e.g., development, production)

–  Expected processing load and distribution of load across technology components ⎯ Physical(network)communications

– Hardware and network specifications –  Views corresponding to the selected viewpoints addressing key

stakeholder concerns

© 2014 Hans-Peter Hoidn & Kai Schwidder 14

Enterprise IT Architectures

Reference Architectures – Overview

§ TOGAF –  Is providing two reference architectures, one of those is the TRM

(TOGAF Technical Reference Model) –  TRM specifies various technical services, the details showing

service categories, see TOGAF Chapter 43, pp. 491 – 521 –  If not a huge project, this taxonomy is too much !

§ SOA Reference Architecture (as provided by IBM) –  Provides appropriate basis for an Integration Platform, firstly

logically but can be augmented by products – Much better suitable for “normal” usage and consulting

§ Cloud Reference Architecture

© 2014 Hans-Peter Hoidn & Kai Schwidder 15

Enterprise IT Architectures

In Addition: Constantly shifts in Technology impact Technology Reference Architectures

1960-1980s 1990-2000s 2010s Time

Platforms

Transaction Systems

Web, e-business and SOA

Cloud Computing

Web Services, SCA, BPEL, SAML, XACML …

BPMN, SBVR, RIF, …

Java, Java EE, XML, XML Schema, SOAP, WSDL, UML, Web2.0, ...

HTTP, HTML, WSFL, XLANG, REST…

SOA Governance Framework, SOA Reference Architecture, … Open Social,

HTML 5, CMIS, OpenAjax, OAuth, …

Open Virtualization Format, Cloud Management, Cloud Audit, Reference Architecture, Cloud Standards Customer Council…

Cloud builds on and leverages the standards which preceded this market cycle

© 2014 Hans-Peter Hoidn & Kai Schwidder 16

Enterprise IT Architectures

TOGAF® Reference Models

§ The TOGAF Technical Reference Model (TRM) – A Foundation Architecture – A model and a taxonomy of generic platform services

§ The Integrated Information Infrastructure Model (III-RM). – A model for business applications and infrastructure applications –  Specifically aimed to support the vision of Boundaryless

Information Flow™

© 2014 Hans-Peter Hoidn & Kai Schwidder 17

Enterprise IT Architectures

TRM (TOGAF Technical Reference Model) High-Level View

© 2014 Hans-Peter Hoidn & Kai Schwidder 18

Enterprise IT Architectures

TRM (TOGAF Technical Reference Model) Detailed View

© 2014 Hans-Peter Hoidn & Kai Schwidder 19

Enterprise IT Architectures

Governance

Security, Resiliency, Performance & Consumability

Cloud ServiceCreator

Cloud ServiceConsumer

Cloud Service Provider

Common CloudManagement Platform (CCMP)

Operational Support Services

(OSS)

Cloud Services

Inf rastructure-as-a-Service

Platform-as-a-Service

Sof tware-as-a-Service

Business-Process-as-a-Service

Business Support Services

(BSS)

Hybrid Cloud

Integration

ConsumerIn-house IT

Service Creation

Tools

Inf rastructure

Existing & 3rd party services, Partner

Ecosystems

Cloud Computing Reference Architecture (CCRA) Version 3.0 The CCRA provides a common, coherent architectural structure

© 2014 Hans-Peter Hoidn & Kai Schwidder 20

Enterprise IT Architectures

Information Systems (IS) Architecture

© 2014 Hans-Peter Hoidn & Kai Schwidder 21

Enterprise IT Architectures

Information Systems (IS) Architecture – Overview

§ The Information Systems Architecture provides the information about the buildings blocks to support the business

– Objectives general addressing “application systems” and “data” – Capture “Baseline” and “Target”, different views

§ Definition: An IS architecture describes aspects of business that are to be automated – known as the “business dependent IT architecture”. The IS Architecture manages

–  Functional Architecture – User Groups – Application Groups – Data Stores – Application Components –  IS Services

© 2014 Hans-Peter Hoidn & Kai Schwidder 22

Enterprise IT Architectures

Enterprise Architecture

User Architecture

Application Architecture

Data Architecture

POLICY Producer Compensation Claimant Claim Business Partners Producer Service Providers Policy Financials Insured Objects Insurance Product Policy

Training, Education, Advice Third Parties Inquiries Legal & Recovery Actions External Agencies Claim Sponsoring Organization Market Prospects Insured Party Business Plans

Info Objects

User Architecture

Application Architecture

Data Architecture

POLICY Producer Compensation Claimant Claim Business Partners Producer Service Providers Policy Financials Insured Objects Insurance Product Policy

Training, Education, Advice Third Parties Inquiries Legal & Recovery Actions External Agencies Claim Sponsoring Organization Market Prospects Insured Party Business Plans

Info Objects

Business Architecture

Corporate Strategy Finance & Planning Human Resources Information Systems Purchasing & Supply Marketing & Sales Technical

Operations Flying Operations Customer

Service Manage Cargo Develop

Products Develop Schedules Distribute

Products Manage Agency Sales Manage

Alliances Manage

Aeroplane Manage Aircraft Seat

Inventory Perform Base Maintenance (A/C) Perform Line Maintenance Maintain

Engines Maintain Components Manage

Materials & Service

Plan Crews Schedule

Crews Manage

In - flight Service Manage

Day - of - flight Operations Service

Reservations Process PAX at Airports

Process Baggage Manage Airport Systems Operations

Perform Base Maintenance (contract)

Financial Planning & Reporting

Manage Labour Contracts

IT Architecture

Architecture Technology

“This is the landscape of all the applications we envisage for the enterprise

“Application

Function Model”

“This is the set of user types

you are allowed to use in your

Solution Architecture” “User Groups”

“This is the set of Data Groups you are allowed to use in your

Solution Architecture”

Information Systems (IS) Architecture – Illustration

© 2014 Hans-Peter Hoidn & Kai Schwidder 23

Enterprise IT Architectures

In more detail: There are two steps to defining IS Architecture: Step1: Select what functionality and information to automate…

§  Understand currently automated business activities; §  Assess users groups, their roles and information requirements; §  Understand strategic decisions already made and being implemented;

–  Package selection decisions –  Sourcing decisions –  Programs, projects in flight

§  Evaluate current portfolio against Business Architecture; §  Understand essential non functional requirements. §  Use Reference Architectures and Patterns as accelerators; §  Assess and prioritize gaps and challenges;

© 2014 Hans-Peter Hoidn & Kai Schwidder 24

Enterprise IT Architectures

In more detail: Step 2: Decide how to package and structure this automation to deliver measurable business value. §  “Upstream EA” (Enterprise Level)

–  Enterprise-wide picture of all automated functionality and information (”on-a-page”) –  Coarse grained components (e.g Account Management) –  Minimal redundancy of functionality - potential for high levels of replaceability –  Constraints for more granular (solution) level components –  Loose coupling between components –  Minimize technology dependencies

§  “Downstream EA” (Solution level) –  Set of building blocks (ABBs) at a level Solution Architects can use. –  Finer grained components (e.g. create account, assess credit score, check background, etc) –  No redundancy of functionality - potential for high levels of reusability –  Loose coupling between components –  High cohesion within components

Function Analysis Users/Roles Data Architecture Placement

© 2014 Hans-Peter Hoidn & Kai Schwidder 25

Enterprise IT Architectures

Function analysis describes how business information, business activities and user roles will be grouped & partitioned into functionality (e.g. application groups or services) Functionality is optimal when: § Business functions are closely

related; § Scope and boundaries of each

functions are clearly defined and do not overlap;

§  Interface and interactions between functions are well-defined;

§ Functions are able to access and share common data, rather than ‘owning’ data;

§ Functions represent “reasonable” pieces of work that can be tackled by projects.

Product Management: consists of all the information and business processing relating to the definition of the Bank's products. This includes: the definition and maintenance of the Product structure, the definition and maintenance of the rules which will govern agreements taken out for these products, the definition and maintenance of the charge and interest structure for the products and the creation, withdrawal and suspension of the products.

PartyProduct Management

Payment Account

Funding (Treasury)

Risk

Financial Management

Sales

Mark

etin

g

Agreement Management

Product Management: consists of all the information and business processing relating to the definition of the Bank's products. This includes: the definition and maintenance of the Product structure, the definition and maintenance of the rules which will govern agreements taken out for these products, the definition and maintenance of the charge and interest structure for the products and the creation, withdrawal and suspension of the products.

PartyProduct Management

Payment Account

Funding (Treasury)

Risk

Financial Management

Sales

Mark

etin

g

Agreement Management

© 2014 Hans-Peter Hoidn & Kai Schwidder 26

Enterprise IT Architectures

Example of a IS Function Map

Marketing ManagementMarketing Management

Customer Relationship ManagementCustomer Relationship Management

SalesSales

MTR Website and Club

Signage InformationSystem

Sales System forMTR Travele-Instant Bonus

MTR Websiteand Club

Corporate ManagementCorporate Management

Corporate RelationsCorporate Relations

Souvenir ControlSystem

MTR HotlineSystem

Engineering ManagementEngineering Management

Maintenance ManagementMaintenance Management

Engineering SupportEngineering Support

Check SheetData Capturing System

Civil StructureCalculation Enquiry

System

DrawingManagement System

Statutory IS

Inspection RegistrySystem

Maintenance CostManagement

Enterprise Asset Management System

Financial ManagementFinancial Management

Cost ControlCost ControlTreasury ManagementTreasury Management Accounts PayableAccounts Payable

Signature CardSystem Treasury Management

Information System

Fund ControlSystem

Activity BasedCosting

Management

Financial Management System

Accounts ReceivableAccounts Receivable

Financial Management System

Fixed AssetsFixed Assets

Financial Management System

General LedgerGeneral Ledger

Financial Management System

Cash ManagementCash Management

Financial Management System

Investors RelationshipInformation System

Corporate BudgetingCorporate Budgeting

CorporateBudgeting System

Human Resources ManagementHuman Resources Management

Administration & Security

Administration & SecurityTraining & Development ManagementTraining & Development Management

Staff Benefits & WelfareStaff Benefits & Welfare

Human CapitalAdministration

Human CapitalAdministration

Human ResourcesManagement System

PayrollPayroll

Human ResourcesManagement System

Staff BusBooking System

Security RiskManagement System

CorporateTravel System

e-LearningManagement System

Human ResourcesManagement System

Corporate QualificationAdministration System

Library System

Training AttendanceRecording System

Metro Credit UnionSystem

Human ResourcesManagement System

Metro RecreationClub System

Staff HousingLoan System

Staff Performance & Succession Planning

Staff Performance & Succession Planning

Human ResourcesManagement System

Project ManagementProject Management

Project ManagementProject Management

DrawingManagement System

Project MaterialInformation System

Multi-project Form CSystem

Electronics DocumentManagement SystemFor TKE/QBR/LAR2

Project

Project Cost andControl System

Planning & Programming IS

Project RecordsRegistration Inventory

Control System

System IntegrationFunctions for

Construction Projects

Electronic ProjectManagement System

(SharePoint)

Property ManagementProperty Management

Property ManagementProperty Management

Insurance ClaimSystem

Property JobManagement System

PropertyManagement System

Lease ManagementSystem – Shopping Mall

Lease ManagementSystem – Car Park

Lease ManagementSystem – Station Kiosk

Revenue ManagementRevenue Management

Passenger Flow & Fare CollectionPassenger Flow & Fare Collection

Customer Service ManagementCustomer Service Management

Surcharge MonitoringSystem

Canteen Point-of-SalesTerminal

Personalized OctopusCard Information System

Equipment OperatingData Generator

Automatic FareCollection OperationsInformation System

Staff TicketingControl System

Office CSC Processor

Supply ManagementSupply Management

StoresStores

Procurement & ContractsProcurement & ContractsebXML based Goods

Receiving System e-Tendering

System

Oracle Inventory

Contract AdministrationSystem

Oracle Purchasing/ iProcurement

Purchase Card CostAllocation System

Transportation ManagementTransportation Management

Operations ManagementOperations Management

Customer OpinionSystem

Safety & RegulatorySafety & Regulatory

Lost PropertyOffice System

Operations InformationDissemination System

Operations PublicationsDistribution System

Train Service System

Electricity ReportingSystem

Station ControllerAdministration

Automation System

Engineering Works& Traffic InformationManagement System

Hazard RegistrationSystem

Operations DataManagement System

Term LaborPlanning System

PCG Paper TrackingSystem

Corporate ManagementCorporate Management

Corporate TimesheetSystem

Electronic PaymentSystem

Electronic ProjectManagement System

(Meridian)

Fare Modeling & AnalysisSystem

Balanced Scorecard Reporting

Balanced Scorecard Reporting

Operations Balanced Scorecard Reporting

SystemOracle Projects

© 2014 Hans-Peter Hoidn & Kai Schwidder 27

Enterprise IT Architectures

Business application vendors have pre-built Functional/Process maps that can be used to accelerate the definition process.

© 2014 Hans-Peter Hoidn & Kai Schwidder 28

Enterprise IT Architectures

§  The fundamental organization of an IT system, embodied in

–  relationships to each other and the environment, and the principles governing its design and evolution

§  Shows how the IT systems meets the business goals of the enterprise

IS Architecture Content according to TOGAF

© 2014 Hans-Peter Hoidn & Kai Schwidder 29

Enterprise IT Architectures

Information Systems Architecture – Objectives (TOGAF 11.1)

§ Develop the Target Application Architecture that enables the Business Architecture and the Architecture Vision, while addressing the Request for Architecture Work and stakeholder concerns

§ Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Application Architectures

© 2014 Hans-Peter Hoidn & Kai Schwidder 30

Enterprise IT Architectures

§ Select reference models, viewpoints, and tools – Determine Overall Modeling Process –  Identify Required Catalogs of Application Building Blocks –  Identify Required Matrices –  Identify Required Diagrams

§ Develop Baseline Application Architecture Description § Develop Target Application Architecture Description § Perform gap analysis (see Section 11.4.4) § Define candidate roadmap components § Resolve impacts across the Architecture Landscape § Conduct formal stakeholder review § Finalize the Application Architecture § Create Architecture Definition Document

Information Systems Architecture – Steps (TOGAF 11.4)

© 2014 Hans-Peter Hoidn & Kai Schwidder 31

Enterprise IT Architectures

© 2014 Hans-Peter Hoidn & Kai Schwidder 32

Enterprise IT Architectures

SOA (Service Oriented Architecture)

© 2014 Hans-Peter Hoidn & Kai Schwidder 33

Enterprise IT Architectures

§  SOA is an architectural style or approach whose goal is to achieve loose coupling among interacting software agents

§  All functions (that need to be used by more than one system) are defined as "services“

§  Service providers agree to a defined, implementation-independent interface with service clients

§  Services oriented architecture is the policies, practices and frameworks –  that enable application functionality and IT services to be –  provided and requested as a set of services –  using a standards based form of interface.

What is SOA

© 2014 Hans-Peter Hoidn & Kai Schwidder 34

Enterprise IT Architectures

Observation of Common Shift

© 2014 Hans-Peter Hoidn & Kai Schwidder 35

Enterprise IT Architectures

Services defined as units of business logic separated from… §  Flow of control and routing §  Data transformation and protocol transformation

Inventory

Sales Orders

Shipments

Customers Information Factory

Web Orders

Service Oriented Architecture (SOA) Moves IT Logic Out of Services

© 2014 Hans-Peter Hoidn & Kai Schwidder 36

Enterprise IT Architectures

Business

Architecture

Implementation

A set of services that a business wants to expose to customers and clients

an architectural style which requires a service provider, requestor and a service description. a set of architectural principles and patterns which address characteristics such as modularity, encapsulation, loose coupling, separation of concerns, reuse, composable and single implementation.

A programming model complete with standards, tools, methods and technologies such as web services.

Roles

SOA is different things to different people

© 2014 Hans-Peter Hoidn & Kai Schwidder 37

Enterprise IT Architectures

SOA Lifecycle

Interaction Services

Information Services

Partner Services

Business App Services

Access Services

Dev

elop

men

t Ser

vice

s

Man

agem

ent S

ervi

ces

Infrastructure Services

App

s &

In

fo A

sset

s

Process Services

Business Services

Enterprise Service Bus

SOA Reference Architecture

The SOMA Method: Service-Oriented Modeling and

Architecture The SOA Solution Stack:

Layered solution view

Realization Decisions, Solution Templates &

Patterns, Architecture, Technology Feasibility

Specification of Services, Components, and Flows

Identification of Candidate Services and Flows

Startup / Adoption << Input from: Business Analysis & Existing Assets>>

Implementation Build/Assembly, Testing

consumers

business processes process choreography

services atomic and composite

service components

operational systems

Service Consum

er Service Provider

JService Portlet WSRP B2B Other

OO Application

Custom Application

Packaged Application

Composite Service Atomic Service Registry Deployment

Packaging and Provisioning

Data A

rchitecture and Business Intelligence

Integration (Enterprise Service Bus A

pproach)

QoS Layer( Security, M

anagement, and

Monitoring Infrastructure Service)

Governance

Key Models and Methods for SOA – Enabling greater flexibility in Enterprise IT Architectures

© 2014 Hans-Peter Hoidn & Kai Schwidder 38

Enterprise IT Architectures

§ Gather & Model Requirements

§ Model & Simulate § Model SW Architecture

§ Discover Services § Construct & Test Services / UIs

§ Compose Services § Orchestrate Processes

§ Integrate People § Integrate Processes § Manage and integrate Information

§ Manage Applications & Services

§ Manage Identity & Compliance

§ Monitor Business Metrics

§ Financial Transparency § Business/IT Alignment § Process Control

The SOA Lifecycle (to be addressed in detail in Governance)

© 2014 Hans-Peter Hoidn & Kai Schwidder 39

Enterprise IT Architectures

Service Model

© 2014 Hans-Peter Hoidn & Kai Schwidder 40

Enterprise IT Architectures

Service Model – Overview

§ The Service Model is in the center of the work products of an SOA based architecture

§ There are several specifications about SOA and Services around – will need some more investigation

§ Note: –  Service Model is a result of SOMA (see SOA part) –  Portfolio of services is replacing the application landscape

§ Relevant for Short Term Engagement: –  Identification of services – Realization options

© 2014 Hans-Peter Hoidn & Kai Schwidder 41

Enterprise IT Architectures

OMG’s SoaML Specification (according to ad-08-09-12) Goals

§ Intuitive and complete support for modeling services in UML § Support for bi-directional asynchronous services between multiple

parties § Support for Services Architectures where parties provide and use

multiple services. § Support for services defined to contain other services § Easily mapped to and made part of a business process specification § Compatibility with UML, BPDM and BPMN for business processes § Direct mapping to web services § Top-down, bottom up or meet-in-the-middle modeling § Design by contract or dynamic adaptation of services § To specify and relate the service capability and its contract § No changes to UML

© 2014 Hans-Peter Hoidn & Kai Schwidder 42

Enterprise IT Architectures

Service Specification

Service Context Awareness

Service Operation

Event

Rules and Policies

Service Context Diagram

Service Messages

Non-Functional Requirements

State Management Decisions

Service Allocation to Components

Service Dependencies

Service Composition and Flow

Service Specification – Services are exposed by Components

© 2014 Hans-Peter Hoidn & Kai Schwidder 43

Enterprise IT Architectures

Composite Service Atomic Service Registry

Data A

rchitecture and Business Intelligence

QoS

, Security, M

anagement, and

Monitoring Infrastructure S

ervice

Integration (Enterprise S

ervice Bus A

pproach) consumers

business processes process choreography

services atomic and composite

service components

operational systems

Service C

onsumer

Service P

rovider

JService Portlet WSRP B2B Other

OO Application

Custom Application

Packaged Application

SOA Layered View (Solution Stack)

© 2014 Hans-Peter Hoidn & Kai Schwidder 44

Enterprise IT Architectures

SOA Technology

© 2014 Hans-Peter Hoidn & Kai Schwidder 45

Enterprise IT Architectures

Definition “Service”

§ Business Perspective: A Service –  is a well- defined, encapsulated, reusable, business-aligned

capability. –  is fully defined by a service description, a published document or

artifact that outlines the overall objective of the service and its inputs, purpose, outputs, scope, responsibility, governance, sustainability (provision period, maintenance, and repair), and qualities of service provisioning

§ IT Perspective: A Service –  is a discoverable, invokable software resource that has a service

description and interface and is configurable using policies. –  implementation is realized through a service provider that

delivers quality of service (QoS) requirements for the service consumer

© 2014 Hans-Peter Hoidn & Kai Schwidder 46

Enterprise IT Architectures

SOAP

§ SOAP is a protocol specification for exchanging structured information in the implementation of web services

§ Its XML-based protocol consists of three parts: –  an envelope, which defines the message structure –  a set of encoding rules –  a convention for representing procedure calls and responses

§ SOAP has three major characteristics: –  extensibility (security and WS-routing are among the extensions

under development) –  neutrality (SOAP can operate over any transport protocol such as

HTTP, SMTP, TCP, UDP, or JMS) –  independence (SOAP allows for any programming model)

© 2014 Hans-Peter Hoidn & Kai Schwidder 47

Enterprise IT Architectures

REST (Representational State Transfer)

§ REST is providing a generic interface, such that with REST an application is treated as a web application

§ HTTP is the transport protocol. URIs access resources, a resource becomes a web resource by simply making the information associated with it accessible to the web

§ The basic functions on the resources (entities as well as other “things” like a process) are GET, POST, PUT and DELETE

– GET, PUT, DELETE are idempotent (no harm when called twice) –  POST has side effects (may also on other resources)

§ The advantage is that the lean data format JSON can be used

Source: Roy Fielding defined REST in the year 2000 in his thesis

© 2014 Hans-Peter Hoidn & Kai Schwidder 48

Enterprise IT Architectures

Example RESTful Services

GET and PUT are idempotent (calling twice

has the same result)

POST has side effects

© 2014 Hans-Peter Hoidn & Kai Schwidder 49

Enterprise IT Architectures

ESB (Enterprise Service Bus) – Definition and Purpose

§ An Enterprise Service Bus (ESB) is an architectural pattern defining a flexible connectivity infrastructure for integrating applications and services.

§ The architecture pattern is a guiding principle to enable the integration and federation of multiple service bus instantiations.

§ An ESB performs: –  Routing messages between services –  Converting transport protocols between requestor and service – managing

multiple protocols –  Transforming message content between requestor and service –  Handling business events from disparate sources

© 2014 Hans-Peter Hoidn & Kai Schwidder 50

Enterprise IT Architectures

ESB (Enterprise Service Bus) – Service Virtualization Decoupling of Service Requester and Provider

§  ESB acts as an intermediary (proxy) between requestor and provider

§  ESB provides service virtualization of –  Location and identity –  Interaction protocol –  Interface

§  Interactions are decoupled, supporting separation of concerns

© 2014 Hans-Peter Hoidn & Kai Schwidder 51

Enterprise IT Architectures

Interaction, Process, Information, Partner, Business App, Access Services

IT Management Services

Expanded View of the Enterprise Service Bus

Business Logic

Security Management

Message Models

Message Flows

Transport Protocols

Enterprise Service Bus

Interaction Patterns Mediation Patterns

Registry

© 2014 Hans-Peter Hoidn & Kai Schwidder 52

Enterprise IT Architectures

IBM SOA Foundation Reference Model (Key Concepts)

Business Application

Services

Strategy and Planning Services

Enterprise Service Bus

Access Services

Partner Services

Process Services

Information Services

Interaction Services

Business Services and Events

Lifecycle Services

Asset and Registry Services

Dev

elop

men

t Se

rvic

es

Man

agem

ent

Serv

ices

Infrastructure Services

Enables collaboration between people, processes & information

Business-driven Enterprise Architecture and Standards

Manages diverse data and content in a unified manner

Integrated environment for

design and creation of

solution assets

Connect with trading partners Build on a robust, scaleable, and secure services environment

Facilitate interactions with existing information and

application assets Manage and secure services, applications &

resources

Optimizes throughput, availability and utilization

Orchestrate and automate business processes

Supports the specification of enterprise business solutions through business architecture

© 2014 Hans-Peter Hoidn & Kai Schwidder 53

Enterprise IT Architectures

Request/Response Coarse Grained Request Fine Grained Request/Response Fine Grained Request/Response Coarse Grained

Service A

WMQ

Service B

SOAP/HTTP Service C

SOAP/JMS

Service D

HTTPS

1 2 3 4

• Portlets can be • A Service Consumer (1) • A Service Provider (3)

• Portlets can •  Initiate processes (1) • Act as a Participant in a process (3) • Communicate with each other

UI Portlets

Enterprise Service Bus

13

The Portal Framework Provides Service Aggregation

What is an Interaction Service?

© 2014 Hans-Peter Hoidn & Kai Schwidder 54

Enterprise IT Architectures

Content Management

Integrated information

services

4 2 Information

Service Enablement

1

Customer Master

Account Data

Lookup Customer

Account Documents

Request Documentation Store/Retrieve

Application

Account Application Database

XML

Account Open

Process

Account Open

Process

Account Open

Process

Master Data

Management

3

Store/Update Customer

MDM

Account Open

Process

Information Services: Several Patterns

© 2014 Hans-Peter Hoidn & Kai Schwidder 55

Enterprise IT Architectures

account data

Data Virtualization Through Data Federation Server

Federated Data Service

(Reporting) Application

traditional context SOA context

§  Solution Characteristics – On demand integration instead of

redundant data – Transparent & optimized access to

distributed, heterogeneous sources

§  Results – Real-time access to distributed

information, fast response time – Scalable approach for adding more

data sources

§  As-Is Environment – Data resides in disparate sources – Manual & redundant integration of

data by multiple consumers results in high costs and inconsistent/inaccurate data

– Slow response time due to inefficient real-time access

Metadata

… Legacy Database

Legacy Database

Review current

accounts

Information Services: Pattern – Deliver Your Data Virtualized Through Services

© 2014 Hans-Peter Hoidn & Kai Schwidder 56

Enterprise IT Architectures

SOA Layered View Details

© 2014 Hans-Peter Hoidn & Kai Schwidder 57

Enterprise IT Architectures

Services atomic and composite

Operational Systems (Applications & Data)

Service Components

Consumers

Business Process Composition; choreography; business state machines

SCA

Billing (CICS 3.1)

Address Verification

Account Activatio

n

Account Inquiry Determine

Eligibility Create

Account

EJB

Determine Applicant Eligibility

Open Account

Account Activation

Account Verification

EJB

GL (SAP)

Sales Application Central Office

Sales Application Regional Office

Address Verification

create from scratch

indirect exposure

third-party reuse

Account Setup

AR Setup

direct exposure

indirect exposure

Message Flow

Customer (CICS 2.x)

Example JK Enterprise – a virtual company with an „Open Account Process“

© 2014 Hans-Peter Hoidn & Kai Schwidder 58

Enterprise IT Architectures

§  Recognizes the value of existing IT investment –  Use of existing “legacy” applications (e.g. COBOL application) and / or

packages (e.g. SAP)

§  Some SOA Related Activities: –  Asset Inventory –  Refactor existing applications to unlock business value

SAP Custom Application

OO Application ISV

Custom Apps

Supporting Middleware

MQ DB2

Outlook

Operational Systems (Applications & Data) ‏

Examples for illustration: specifics are not in the scope

of the reference model.

Layer 1: Operational Systems (Leverage Existing Investment)‏

© 2014 Hans-Peter Hoidn & Kai Schwidder 59

Enterprise IT Architectures

Service Components

§  The Service Component Layer: –  Enables IT flexibility by strengthening the decoupling in the system.

Decoupling is achieved by hiding volatile implementation details from consumers.

–  Often employs container based technologies like EJBs

§  Each Service Component: –  Provides an enforcement point for service realization –  Offers a facade behind which IT is free to do what they want/need to do

ApplicationY

ServiceComponent

A

PackageX

Service A

Application B

XML via HTTP.

WSClient

Layer 2: Service Components

© 2014 Hans-Peter Hoidn & Kai Schwidder 60

Enterprise IT Architectures

§  The Services Layer forms the basis for the decoupling of Business and IT. –  Captures the functional contract (incl. QoS – Quality of Service) for each

standalone business function or each task in a business process

§  The assumption is that (within an SOA) IT responsibility is to realize/manage service implementations that faithfully conform to the set of services in the service model.

§  This layer contains all the exposed services in the SOA

§  Each service is a contract between the consumer(s) and the provider(s)

Services atomic and composite

Layer 3: Services (Decouple Business and IT)‏

© 2014 Hans-Peter Hoidn & Kai Schwidder 61

Enterprise IT Architectures

§  This layer contains operational IT artifacts that implement business processes as a choreography of services

§  The set of services that are composed is restricted to those services that are defined in Layer 3

§  The choice of technology depends on a set of realization decisions that must be made when establishing a physical Reference Model for a given SOA

Business Process Composition; choreography; business state machines

Layer 4: Business Processes (Business process alignment of IT) ‏

© 2014 Hans-Peter Hoidn & Kai Schwidder 62

Enterprise IT Architectures

§  This layer exists to recognize that the technology chosen to expose Business Processes/Services must permit access from a wide set of interaction channels.

§  It is important to populate this layer with the set of channels types that are required in a solution.

Consumers Portal Ajax B2B WSRP <other>

Layer 5: The Consumer Layer (Channel independent access to business processes )‏

© 2014 Hans-Peter Hoidn & Kai Schwidder 63

Enterprise IT Architectures

Cross-cutting concerns/capabilities

§  Several concerns are not restricted to a single layer in the Reference Model, these concerns are captured in ‘Layers’ 6-9

§  These are not really layers but treating them as such gives us the ability focus discussions/decisions, for example “What is found where Governance intersects Services? i.e. what are the Governance concerns specific to Services?”

§  Clearly there is interaction among these ‘layers’ also. For example, it is likely that most data architectures will be subject to governance

Integration (Enterprise Service Bus)‏

Quality of Service (Security, M

anagement &

M

onitoring Infrastructure Services)‏

Data A

rchitecture (meta-data &

services) &

Business Intelligence

Governance

1

2

3

4

5 6 7 8 9

for illustration: this is not saying that SOA requires an

ESB.

© 2014 Hans-Peter Hoidn & Kai Schwidder 64

Enterprise IT Architectures