Service Oriented Architecture 10 0

Solution Design

how to design software solutions for
business transformation …..

Solution Architecture Topics
6. Software Product Line Development
6.1. Carnegie Mellon University Software Engineering Institute Architecture Framework
6.2. Agile Model Driven Design
6.3. Model Driven Testing
7. Serviced-oriented Architecture Frameworks
7.1 Enterprise Services
7.2 Enterprise Service Bus
7.3 Enterprise Application Integration
8. Solution Architecture
8.1. Service-oriented Architecture Frameworks and the Enterprise Service Bus
8.2. COTS Package Implementation
8.3. EAI, Collaboration and Process Orchestration
9. Solution Design and Systems Integration
9.1. Solution Seeking – COTS Package evaluation and selection
9.2. Solution Definition, – Package Module / Function / Service / Process Mapping
9.3. Process Integration – Process Orchestration, Workflow, Collaboration
9.4. Messaging – Domain Independent Message Design, Formatting, Queuing, Transport, Persistence
10. Business Continuity
10.1. Business Continuity Planning – Transition, Capacity. Performance, Resilience, Reliability, Scalability.
11. Service Management Framework
11.1. Service Planning & ICT Demand / Supply Model
11.2. Service Virtualisation, Integration and Automation
11.3. Service Design-Build-Operate
11.4. On-demand Service Model
12. System Management Framework

EA-envision: The Enterprise Framework for Business Transformation

Software Product Line Development

how to architect Enterprise Business
Services…..

Software Product Line Development

• Carnegie Mellon University Software Engineering Institute

– Architecture Framework
– Objectives
– Approach
– Scoping
– Understand the relevant Application Domains
– Process Definition
– Architecture Definition
– COTS Utilisation
– Model Driven Development
– Marketing
– Customer Interface Management
– Operation
– Data Collection, Metrics and Tracking
– Structuring the Organisation


Enterprise / Solution Architecture Framework
• In order for our Enterprise / Solution Architecture Framework to deliver
tangible results on a daily basis - we need an Architecture Framework and IS/IT
Management Structure acting as a common, shared vision of what we are
collectively aspiring to, seeking out and driving towards. Key aspects include: -

– Strategic Enterprise Management (SEM) Framework
– IS/IT Strategy and Architecture
– Enterprise Architecture Framework
• Carnegie Mellon SEI, TOGAF, Zachman
– Development Methods
• Agile, Scrum, RUP, DSDM, Prince, PMP
– Enterprise Repository
• Adaptive, ARIS, Computas Metis, PlanningIT, Promise, Provision, System Architect
– Visualisation Tools
• Magic Draw, PlanView, Rational Suite, VersionOne, Visual Paradigm, Visual Studio
– E2E Requirements Traceability Model
– Business Operating Model (BOM)
– Technology Operations Model (TOM)
– Service-oriented Architecture Framework (SoA / ESB)
– Enterprise Service Catalogue / Service Registry


Architecture Principles

• Understand and capture the rationale behind every Design Decision

• Opt for simple heuristics where a complex generic solution is inappropriate

• Capture important information and experience in a structured Repository

• Provide saleability and promote simplicity through the use of Configuration
Management

• The Architecture is stateless; the system can always recover irrespective
of when an abnormal termination occurs

• There is no single point of failure; redundancy is supported across the
network, database and infrastructure layers

• COTS software components are deployed wherever possible


Architecture Standards
• Front-end Tier (OAG BOM)
– OAG Business Objects Model
– Presentation Layer
– Process Orchestration Layer

• Core Asset Tier (J2EE, EJB’s, CORBA , JNDI, XML)
– Business Application Layer – ERP / CRM / DWH / BI
– Collaboration Layer - Workflow, Office, Enterprise Content Management
– Enterprise Services (Business Services)
– Integration Layer – Messaging, Enterprise Service Bus

• Persistence Tier (JDBC, SQL)
– Data Layer
– Enterprise Document Management

• Infrastructure Tier
– Security Framework (Security Model)
– Utilities and Technology Services
– System and Application Monitoring, Intelligent Agents and Alerts


Architecture Diagrams

• Context View – which states the high-level context and scope of the system

• Logical View – which shows the logical description of the system, functional
decomposition and functional mapping of the system to process and data

• Use Case View – which presents all the Use Cases, Scenarios, Actors, Objects and
Messages supported by the System

• Process View – which captures the concurrency, synchronisation, process
orchestration and process execution aspects of the system

• Object View – which models the object attributes / methods / collaboration /
messages / interaction / sequence characteristics of the system

• Application View – which describes the physical modules / components / services of
the system

• System View – which outlines the actual distribution and deployment of software
across the Development, Test and Production environments


Business Operating Model (BOM)

• Requirements are often too ambiguous to accurately develop complex
systems - so we use Functional Requirements to design the Business
Operating Model, get this signed off by users, and use the BOM as a
Design Template for the High Level Design (HLD).

The High Level Design (Business Architecture or Business Operating
•
Model - BOM) demonstrates our Functional Requirements and consists
of the following object types: -

– Organisation Units
– Processes
– Functions
– Business Services
– Data Stores
– Documents
– Messages

• The Enterprise Architecture Framework guides us through Business Model
design and specification, helping us to confirm our understanding of the
functional requirements - and optimise design pattern re-use.

Technology Operations Model (TOM)

• The Low Level Design (Technical Architecture or Technology Model) consists
of defining and aggregating together various Technical Services in order to
execute our high-level Business Services as described in the BOM - and also
meet our Non-functional Requirements: -

– Presentation Services (GUI, Graphics Engine)
– Process Orchestration Services (Process Execution)
– Collaboration Services (Workflow, E-mail, MS Office)
– Application Services
– Integration Services (Messaging)
– Data Services (Persistence)
– Utility Services
– Infrastructure Services

• Our IS/IT Architecture, Service-oriented Architecture Framework and Enterprise
Service Catalogue guides us through this complex, iterative architecture design
and development activity - helping us to maximise Technical Service re-use.


Software Product Line Objectives
• Development of Core Assets
– Software Product Line Architecture
• Business Operating Model - BOM
– Core Asset Components Development
• Technology Operations Model - TOM

• Development of Software Products
– Identify Front-end Tier and Core Asset Tier Components
– Perform Component Variation and Extension

• Management of the Software Product Line
– Enterprise Level Product Management
• Enterprise Repository
– Technology Level Product Management
• Enterprise Service Catalogue / Service Registry


Proactive Software Product Approach

• Proactive Approach

– Development of Core Assets
• Product Line Scope / Product Set / Product Space
• Product Line Architecture
• Core Asset Components

– Development of Products
• Identify Core Asset Components
• Perform Component Variation and Extension
– Generic Configuration of Core Asset Tier Components
– Specific Customisation of Front-end Tier Components
– Source or Build New Components
• Assembly and Test
• Package and Deliver


Reactive Software Product Approach

• Reactive Approach

– Initial Stage
• Find a Customer / Sponsor / Identify a Template
• Build a Prototype / Proof-of-concept System
• Harvest Re-useable Components

– New Customer
• Identify Common Components
• Identify New Components
• Perform Component Variation
– Configuration of Harvested Components
– Customisation of Harvested Components
– Build New Components
• Assembly and Test
• Package and Deliver


Scoping

• A Product Line Scope is a statement of which systems are in and out-of-
scope for the Product Line’s declared Business Area
– Proactive – Product Line System Set / Space v. Core Assets
– Reactive – Product Line Component Variation v. Harvested Assets

• Product Line Component Variation Objects
– Workflow
– Forms and Screens
– Reports and Data Extracts
– Bulk Data Load Requirements

• Perform Component Variation
– Configuration of Harvested / Core Asset Components
– Customisation of Harvested / Core Asset Components
– Build New Components


Understanding Application Domains
• Application Domain Model - develop a rich set of well-documented
Business Use Cases and Scenarios

• Data Domain Model – develop stable core schemas

• Customer Business Object Model - develop a Domain Repository
containing the following objects: -

– Business Processes Model
– Business Services Catalogue
– Technology Services Registry
– Canonical Data Models / Schemas / Documents / Message Formats
– Forms and Screens
– Report Formats and Data Extract and Transformation Definitions
– Components / Objects / Attributes
– Infrastructure Asset Register

• Embrace any appropriate Domain Reference Models


Process Definition

• RUP – Rational Unified Process

• VRAPS –
– Vision
– Rhythm
– Anticipation
– Partnering
– Simplification

• Variation – Façade Design Pattern
– Configuration
– Customisation
– Localisation
– Personalisation

• Extreme Agile Programming – twice daily builds


Architecture Definition

• Stakeholder Drivers
– Performance - Runtime Efficiency
– Reliability - High Availability
– Security - Data Asset Protection
– Scalability - Core Asset Exploitation
– Configuration Management (CVS)

• Architecture Tiers
– Front-end Tier (Customer-specific Business Process Layers)
• Presentation Layer, Process Orchestration Layer
– Core Services Tier (Application Layers – ERP / CRM / DWH / BI)
• Application Layer, Integration Layer
– Persistence Tier (Storage Layers)
• Database Layer, Content Layer
– Infrastructure Tier (Technology Layers)
• Security Framework, Utilities, Technology Services

COTS Utilisation

• COTS Utilisation is about commitment to simplicity without compromising
quality: -

– Scaleability - Core Asset Exploitation

• Where any COTS functionality is in doubt and there is no obvious work-
around, then do not hesitate to build the required components in-house: -

– If generic functionality will be sufficient – use a COTS product
– If a COTS product meets the de-facto standard – use COTS
– Otherwise, build the necessary components in-house


Model Driven Development

• Model Driven Development (MDD) is an area where we can be both
innovative and agile - particularly in the areas of: -

– Application Portfolio Management
– Redundancy Scanning and Cloning Detection
– Configuration Management

• The advantages of the Model Driven Development approach are: -

– Simplifies code
– Simplifies build process
– Associates all related artefacts
– Enforces single Software Product Line


Stakeholder Management

• Stakeholder Drivers
– Scalability - Core Asset Utilisation / Exploitation

• Performance – responsiveness of system

• Security – capability of system to resist security threats

• Availability – the time system is functionally available v. SLA’s

• Usability – support for personalisation / customisation features and functions

• Modifiability – extent to which functionality can be modified or extended by
standard configuration features

• Testability – extent to which system supports testing requirements

The Non-functional Requirements

1. Performance Requirements (PR)
2. Security Requirements (SR)
3. Maintenance and Support Requirements (MS)
4. Operational Requirements (OR)
5. Usability Requirements (UR)
6. Common Look and Feel Requirements (CLAF)
7. Environment Requirements (ER)
8. Cultural and Political Requirements (CP)
9. Compliance Requirements (CR)


• Performance – the responsiveness of the system under different workload
patterns / transaction volumes

• Performance Targets / SLA’s
– Target v. Actual Average (Normal Operations) Transaction Volume / Response Time
– Target v. Actual Maximum (Peak Operations) Transaction Volume / Response Time
– Client / Server - Processor Utilisation - average / maximum
– Client / Server - Memory Utilisation - average / maximum
– NAS / SAN Storage I/O - average / maximum
– Database Read / Write - average / maximum
– Network Utilisation - average / maximum
– Application Throughput – Concurrent Users / Transaction Throughput

• Performance Model – Response Time
– Client / Server - Processor Component
– NAS / SAN Storage Component
– Database Component
– Network Component
– Application Components


• Performance – the responsiveness of the system under different workload
patterns / transaction volumes

• Performance Monitoring and Diagnostics
– Response Time / Resource Utilisation
– Client / Server - Processor Component – no. nodes / processors / utilisation
– NAS / SAN Storage Component – Mirroring / RAID Strategy / I/O Waits
– NAS / SAN Storage Component – Extents / Working Storage
– Database Component - paging & buffers hotspots & contention / parallelism
– Database Component – indices & access paths / threads (processes)
– Network Component – bandwidth / contention
– Application Components – concurrent users / throughput
– Dynamic Resource Allocation / Intelligent Agents / System Alerts

• Capacity Model
– Resource Sizing / Allocation
– Client / Server - Processor Component
– NAS / SAN Storage Component
– Database Component
– Network Component
– Application Components


• Security - the capability of a system to resist unauthorised access attempts
and enforce denial of service access to intruders - whilst still providing a full
services portfolio to identified, authenticated, authorised and entitled users

• Security Model
– Security Policy
– Security Principles
– Security Standards
– Security Process Model
– Security Function Model
– Security Data Model

• Information Security
– Systems and Services
– User Security
– Resources Security
– Security Monitoring and Reporting



• Security - the capability of a system to resist unauthorised access attempts
and enforce denial of service access to intruders - whilst still providing a full
services portfolio to identified, authenticated, authorised and entitled users

• User Administration
– User Identity Management and multi-factor authentication
– User (Single) Sign-on and authorisation - LDAP
– User Accounts and permissions
– User Groups / Roles
– User Access Control
– User Activity Logging

• Global Asset Conservation and Protection
– Enterprise Asset Management
– Data Asset Management

• External Threat Management
– Threat Identification and Assessment
– Threat Avoidance and Mitigation


• Scalability – how scaleable is the system (Current volume / demand
v. Future anticipated growth)

• Extensibility – can the application logic be extended without the
need to re-write code / use of industry standard development tools

• Serviceability – can the system operate in a Modular / Component-
based / Service Oriented Architecture (SOA) Environment

• Compatibility – does the system support industry standard
synchronous / asynchronous transport standards and protocols (JMS,
MQ etc.)



• Flexibility – to what extent is the system configurable using standard
features and functions / is the code-base available / accessible /
understandable / transparent

• Comprehensibility – how consistent / complete / comprehensive is the
system documentation

• Upgradeability – ease of application of fixes, patches, upgrades and new
releases, configuration management / change management

• Inter-operability – compatibility with industry / open standards, data
exchange formats and third-party component versions: -

– Front-end Tier (J2EE, EJB’s, CORBA)
– Core Asset Tier (JNDI, XML, OAG BOM)
– Persistence Tier (JDBC, SQL)



• Availability – the time that the system is functionally available (Actual v.
Target SLA’s)

• Operability – ease of service design and service delivery / system
monitoring and diagnostics, intelligent agents and system alerts

• Supportability – ease of global support, help desk / trouble ticket / support
integration (issue / problem register, support knowledge base, known issues
bulletin board, global support forum)

• Maintainability – ease of planned and unplanned maintenance, concurrent
development (application repository, check-out / check-in / merge / update)

• Upgradeability – ease of implementation of scheduled application upgrades,
versions and releases

• Application and System Monitoring – Intelligent Agents and Alerts



• Configurability – ease of maintenance of “Gold Standard” Configuration
Packages / Documentation

• Robustness – error management - error trapping, handling and reporting
features and functions

• Reliability – defect management - error incident identification, recording
and reporting, causal analysis and rectification features and functions

• Restorability – archive, backup and housekeeping routines, failover and
recovery procedures, multi-phase transaction commits / rollback, checkpoint
/ restart capabilities

• Business Continuity – standby and disaster recovery features and
functions


5. Usability Requirements (UR)

• Usability – support for personalisation / localisation / customisation application features
and functions

• Personalisation - support for personalisation so that users can personalise screens and
applications pertinent to their needs (e.g. colours) and be presented with relevant data

• Localisation – support for standard country requirements / languages / character sets

• Customisation – support for features / functions to customise the application to meet the
specific needs of different workgroups (e.g. only display those menu functions which are
available to that User Group). Accessibility - support for disadvantaged / disabled users.

• Guidance – provide on-line guidance and context-sensitive help and full error messages
along with context-relevant process execution and procedure information

• Relevance – system should recognise human cognitive capabilities and limitations, re-
present and reinforce key identification / user input data. Filter bulk data for presentation
in logical / ergonomic segments and blocks for intuitive recognition and assimilation

• Consistency – support of common standards for GUI look-and-feel to give a consistent
user experience within and across applications and / multi-media channels with intuitive
(natural, logical, cognitive) mapping and predictability of navigation paths and operations

6. Common Look and Feel Requirements (CLAF)

• Branding, Corporate Image and Group / Company Identity
requirements should be fully supported via muti-media features - the
Graphical User Interface (GUI) and Print Output (PO)

• Portability – the User Interface should run on a variety of Web
Browsers (Web Browsers, PDA, Mobile Phone etc.)

• The User Experience and Journey must be of a constantly high
quality irrespective of how or where the application is accessed (Web
Browsers, PDA, Mobile Phone etc.)

• Application Navigation should be simple, logical, seamless and
intuitive

• The User Interface should be simple, elegant, informative and intuitive

• Multi-language User Interface support should be provided


7. Environment Requirements (ER)

• Environment Management
– Are Development, Testing, Integration, Acceptance, Pre-production, Model Office
(Gold Standard / Regression) and Production Environments supported from a
software licensing perspective

• Configuration Management
– Are Development, Testing, Integration, Acceptance, Pre-production, Model Office
(Gold Standard / Regression) and Production Environments supported from a
versioning and control perspective

• Testing Environments
– Can the Testing Environments be configured to replicate / mirror the Model office or
Production Environment with minimal effort?

• Test Data
– How easily can Test Data be restored / refreshed using standard Application /
Database features and functions?

• Fire Walls
– Is the Test Environment completely isolated from the Production Environment to
prevent Transaction Leakage (e.g. external connectivity) from Testing into
Production?

8. Cultural and Political Requirements (CP)

• Configuration
– Can the System be configured / varied to support the Global Template or “Gold
Standard” Configuration Variation Requirements with minimal effort?

• Customisation
– Can the System be configured to support further Division, Segment, Business Unit,
Workgroup and User Customisation Variation Requirements with minimal effort?

• Localisation
– Can the System be configured to support Localisation Variation Requirements
(national currency, language, date/time format, double byte characters) with
minimal effort?

• Personalisation
– Can the System be personalized to support further Division, Segment, Business
Unit, Workgroup and User Personalisation Variation Requirements with minimal
effort?


9. Compliance Requirements (CR)

• Statutory Compliance
– Does the system support federal / state Statutory Requirements?

• Regulatory Compliance
– Does the system support federal / state Regulatory Requirements?

• Enterprise Governance
– Does the system support Enterprise Governance, Control, Risk and
Financial Reporting Requirements?

• Architecture Governance
– Does the system support Enterprise Architecture Strategy, Policy,
Principles and Standards Requirements?


Agile Model Driven Design

how to design Enterprise Business
Services…..

Solution Architecture – Part 8
Service-oriented Architecture Methodology and Standards V10.0

Qui ne risque rien n'a rien…..

Approaches to AMDD

• There are three basic approaches to applying AMDD on an agile project: -
:

– Manual. Simple tools, such as whiteboards and paper, and inclusive models
are used for modelling. This is likely to represent 70-80% of all business
application modelling efforts.

– Design Tool. Inclusive models are used to explore requirements with
stakeholders, and to analyze those requirements. Developers then use
sophisticated modelling tool for detailed design, generating source code from the
models. This is likely to be 20-30% of all business application modelling efforts.

– Agile MDA. Very sophisticated, MDA-based modelling tools used to create
extensive models from which working software is generated. At best this
approach will be used for only 5-10% of business application modelling efforts.



Guideline 1 Through initial, high-level modelling you can gain the knowledge that you need to guide the project but choose to wait to act on it.

Figure 1. The AMDD lifecycle: Modelling activities throughout the lifecycle of a project.

Agile Sprint Activities

Guideline 2 With initial iteration modelling you explore what you need to build so that you can estimate and plan the work for the iteration effectively.

Figure 2. AMDD Through the Agile Development Lifecycle.

Agile Work Management

Figure 3. Agile requirements change management process.

Why Does AMDD Work?

• AMDD works for several reasons: -
• We meet our quot;project planning needsquot;. By identifying the high-level requirements
early, and by identifying a potential architecture early, you have enough information to
produce an initial cost estimate and schedule.
• We manage technical risk. Your initial architecture modelling efforts enable you to
identify the major areas of technical risk early in the project without taking on the risk of
over modelling your system. It's a practical quot;middle of the roadquot; approach to
architectural modelling.
• We minimize wastage. A JIT approach to modelling enables you to focus on just the
aspects of the system that you're actually going to build. With a serial approach, you
often model aspects of the system which nobody actually wants.
• We ask better informed questions. The longer we wait to model storm a requirement,
the more knowledge we'll have regarding the domain and therefore we'll be able to ask
more pertinent questions and elicit better informed, more relevant answers.
• Stakeholders give better answers. Similarly, our stakeholders will have a better
understanding of the system that we're building because we'll have delivered working
software on a regular basis and thereby provided them with concrete feedback.


Model Driven Testing
Solution Architecture – Part 9
Service-oriented Architecture Methodology and Standards V10.0

Il faut le voir pour le croire…..

System Design models v. Test Design models

SoA Frameworks

how to design Enterprise Services…..

Service-oriented Architecture Framework

The Service-oriented Architecture describes the Solution as a set of Services and populates the
Topology and Landscape of the Enterprise Architecture with major features and landmarks

Service-oriented Architecture Frameworks

• Service Oriented Architecture (SoA) Frameworks. Leading companies
are tackling the complexity of their application and IT environments with
Service-oriented Architecture (SoA) Frameworks – which facilitates the
development of modular business services that can be easily integrated and
reused – thus creating a truly flexible, adaptable IT infrastructure. Within an
SoA framework, the IT organization will focus more resources and budget
on business innovation and on delivering new business services to
support the newly transformed, streamlined and enhanced Business
Process Stack.

• Service Oriented Architecture (SoA) is a solution architecture
implementation for creating, maintaining and using business processes,
packaged as business services. SoA also defines and provisions the IT
infrastructure to allow different applications to exchange data and
participate in business processes. These functions are loosely coupled with
the operating systems and programming languages underlying the
applications. Enterprise SoA is a framework for an adaptable, flexible, and
open IT architecture for developing services-based, enterprise-scale
business solutions.


Types of SoA Framework

• SoA Lite is the Service-oriented Architecture (SoA) Framework for
organisations that are primarily deploying simple Web Services - which do
not therefore require mission-critical capabilities such as high-volume
scalability, high availability, business continuity and fail-over, nor Enterprise
Service management, governance, or security.

• SoA ERP is the SoA Framework used by organisations that are choosing to
deploy a SoA Framework surrounding their ERP and CRM application
software (Microsoft, SAP, Oracle e-Business Suite, PeopleSoft, JDE etc.).

• Enterprise SoA is the Service-oriented Architecture (SoA) Framework for
those organisations that require full mission-critical global Enterprise
Service deployment capabilities - featuring performance such as high-
volume scalability, high availability, business continuity and fail-over,
Enterprise Service management, governance, and security, all delivered via
a SoA middleware suite - the Enterprise Service Bus.


SoA Lite

• SoA Lite is the Service-oriented Architecture (SoA) Framework for
organisations that are primarily deploying simple Web Services: -


SoA ERP
• SoA ERP is the SoA Framework used by organisations that are choosing to deploy a SoA
Framework with Connectors and Adaptors surrounding their ERP and CRM application software: -

• Integrators, Connectors and Adaptors: - SAP Business API and NetWeaver Adaptors, Oracle e-
Business Suite, PeopleSoft ETP, JDE Master Business Function, ATG Dynamo and BEA WebLogic
Adaptors, Microsoft MSMQ Adaptor, IBM MQSI Adaptor, Sun JMS, JCA and SeeBeyond Adaptors

Enterprise SoA
• Enterprise SoA is a SoA framework for an adaptable, flexible, and open IT architecture designed for
developing and supporting services-based, enterprise-scale business solutions which is implemented
via a strategic SoA middleware suite - the Enterprise Service Bus: -

ESB Adapter Types

• ESB Adapter types include: -
– Database access including relational (e.g. SQL, Oracle, DB2, MySQL etc.),
hierarchical (e.g. IMS), network (e.g. IDMS) and file based (e.g. FTP, SFTP,
ADABAS, VSAM, etc.) data sources
– COTS Application Package adapters - using native low level APIs to connect
most efficiently (e.g. SAP Business API and NetWeaver Xi, Oracle e-Business
Suite, PeopleSoft ETP Adaptor, JDE Master Business Function, etc.)
– Object oriented technology adapters (e.g. CORBA, Enterprise JavaBeans™,
COM etc.)
– Web and SoA Protocols (e.g. SOAP 1.2, WSDL 1.2, UDDI 2.0, BPEL4WS /
WSBPEL, BPMN, HTTP, CGI, XML, JMS, ADO.NET, RNI, JDBC, EJB, ESB etc.)
– Messaging (e.g. IBM MQSI, JMS, JCA, Sun SeeBeyond eGate, Microsoft Biztalk
MSMQ, Information Builders iWay etc.)
– Enterprise Services (e.g. ATG Dynamo, BEA Weblogic, IBM WebSphere,
WebMethods, Encina etc.)
– Communication adapters (e.g. SNA, TCP/IP, etc) and Email (e.g. SMTP, POP3,
IMAP etc.)
– Screen based integration and HLAPI (e.g. 3270, 5250, VT100, Wise, etc.)


Enterprise Services
• Enterprise Services. Business Services support the execution of
Business Processes. Common function Business Services that are re-
useable across the whole enterprise, and are not restricted to one business
area or domain, are Enterprise Services. For example, in using “customer”
data, the context of “customer” will vary, depending on the role of the
consumer of that data. An implementer may manipulate low-level services to
support a customer service application that provides call centre agents with a
total view of customers’ relationships with the business. The same
implementer will manipulate services differently to support a product shipping
and tracking application. Common business services inclusive to both of
these applications are “Identify Customer” and “Get Customer Details”.

• Technology Services. Business Services are constructed from multiple,
elementary Technology Services that may be deployed across multiple
computer platforms and environments. The way that these services
communicate across enterprises is critical. Each of these services provide a
message that is required by some other service. This would mean that these
messages have to be transported to these services asynchronously as well
as provide a high level of fault tolerance. Moreover any new service should
be able to subscribe or be able to publish using the existing Enterprise
Service Bus without creating the need for any new transport mechanism.

Enterprise Service Bus

• Service Aggregation. It is rare that one low-level service, such as an SAP
Business API or JDE Master Business Function, will produce enough data,
in a rich enough context to be useful by itself. At the same time, using too
many low-level services directly requires additional interactions between
service providers and consumers, which will have a negative effect on
application performance. Aggregating low-level services to higher levels
helps developers and implementers avoid overly complex, difficult-to-use
systems. An implementer will aggregate multiple individual services in ways
that vary depending on how the application or process must support the
organization.

• Enterprise Service Bus. An ESB generally provides an abstraction layer
on top of an implementation of an Enterprise Messaging System, which
allows integration architects to exploit the value of enterprise services. This
construct is typically implemented by technologies found in a category of
Middleware, the Enterprise Application Integration product family, which is
based on recognized standards, that provide foundation services for more
complex architectures via an event-driven and standards-based messaging
engine (the bus).



An Enterprise Service Bus (ESB) should provide a standard routing mechanism for a loosely coupled
asynchronous Service-oriented Architecture (SoA). It would also allow complex transformation of the
messages as needed, as well as provide an interface to integrate across different non standard interfaces.

Figure 1: Diagram showing an ESB with different services connected in a message flow.

Services and Adapters for SOA

ESB

SoA Integrators, Connectors and Adaptors
• Legacy applications
– written in a variety of procedural languages that typically do not have well-defined Application Program
Interfaces (API’s) for collaborative processing, but functions may be “wrappered” as Remote Procedure Calls
• Object-oriented applications
– many different applets developed as components for other applications, such as Enterprise JavaBeans™, COM
Application Servers or CORBA objects etc.
• Transaction processing systems
– applications that run under the control of transaction processing monitors such as distributed customer
information control system (CICS), IMS Transaction Manager (IMS/TM), BEA Tuxedo, and other TPMS software
whose transactions are well suited for incorporation into collaborative business processes
• Packaged application systems
– Vendor-supplied, proprietary systems with well-defined, often completely proprietary, collaborative interfaces
such as SAP Business API / NetWeaver Xi Adaptors, Oracle e-Business Suite Adaptor, PeopleSoft ETP
Adaptor, JDE Master Business Function Adaptor, etc.
• Databases and file systems
– Vendor-supplied, proprietary relational database management systems (RDBMSs), legacy database
management systems (DBMSs), and file systems with varying degrees of standard and proprietary interfaces
including relational (e.g. SQL, Oracle, DB2, MySQL etc.), hierarchical (e.g. IMS), network (e.g. IDMS) and file
based (e.g. FTP, SFTP, ADABAS, VSAM, etc.) data sources
• Communication transport protocols and message formats
– Industry-standard transports such as hypertext transport protocol (HTTP), file transfer protocol (FTP), and
simple mail transfer protocol (SMTP), Sun Enterprise Java Suite Adaptor, SoA Protocols such as XML, SOAP,
WSDL, JMS, ADO.NET, RNI, JDBC, EJB, ESB etc.
– Vendor proprietary messaging and queuing systems in a variety of formats for exchanging data between
applications, such as IBM WebSphere MQSI, Sun JMS, JCA and SeeBeyond eGate, Microsoft BizTalk MSMQ,
BEA e-link (Tuxedo) adaptors
• e-Business exchanges
– Proprietary and standards-based public and private exchanges through which businesses collaborate
– Proprietary data interchange systems in a variety of formats for exchanging data between collaborating
enterprises, such as Electronic data interchange (EDI), Society for the Worldwide Inter-bank Financial
Telecommunication (SWIFT),.
• Application server platforms
– application and integration servers that host all manner of Application Service Provider (ASP) applications and
On-demand Services that facilitate collaboration within and between enterprises

Service-oriented Architecture

how to deliver Enterprise Services…..

Enterprise Architecture Context
Enterprise Architecture Context
Organisation Process Data Function Application Infrastructure
Enterprise Vision & Business Transition Data Management Information Systems Information Technology
Business Agility
STRATEGIC
Mission Statements Strategy Strategy Strategy Strategy
Strategy
Business Strategy
Strategic EA Framework Business Process Re- Data Architecture Systems Framework Technology Framework
SoA Framework
engineering Framework
Enterprise Performance Data Principles, Policies Application Blueprint Infrastructure Blueprint
Agile Methods
Management Framework Methods & Procedures
Application Roadmap Infrastructure Roadmap
CONCEPTUAL Operational Strategies & Process Architecture Data Architecture Information Systems Information Technology
Service-oriented
Desired Outcomes, Architecture Architecture
Architecture

Organisation Hierarchy, Process Model Conceptual Data Model Application Inventory Technology Portfolio
Establishment Model
Enterprise Performance Process Catalogue Data Catalogue Function Catalogue System Regimes Infrastructure Regimes
Management Strategy
Data Management Asset Hierachy
Service Library
Functions
Goals, Objectives CSF’s, Process Hierarchy Logical Data Model System Asset
Function
LOGICAL
Organisation Units, Meta Data Repository, Module Device
Service
Roles & Responsibilities, Business Glossary
Performance Plans Process Descriptions Data Management Unit
Collaborations and
Services Contracts
Organisation Locations, Elementary Business Physical Data Model Component Assembly
Components
PHYSICAL
Posts & Post Holders, Process Data Storage Strategy
KPI’s and Metrics Data Placement Strategy Objects
Performance Targets Process Step Data Management
Modules
Sites and Addresses, Procedure Data Placement Instantiated Objects Executables, Applets Component
ACTUAL
Database Instances DDL, (Classes)
Jobs and Employees,
Training and Education, Tables, Indices, Table
Competancies and Skills, Space, Storage Groups
Qualities and Capabilities
Planned Objectives & Data Audit, Data Profiling,
Actual Achievements Data Quality Reporting

Resources Procedures Information Services Systems Facilities

Service-oriented Architecture Framework

Enterprise Service Principles

• Enterprise Services are : -
– Pragmatic to design, create, maintain and use
– Serviceable, resilient and robust
– Useable and supportable
– Traceable, auditable, and recoverable
– Scaleable, performant and portable
– Cross Platform (Wintel – Solaris – UNIX – Linux)
– Extensible and adaptable
– Agile, efficient and productive

• Enterprise Services support: -
– Business Process Model / Use Case Model / Business Scenarios
– Canonical Data Model / Domain Independent Message Formats
– Service-oriented Architecture Framework
– Application Inventory / Function Library / Service Catalogue
– Model Driven Design / Re-useable Design Patterns / Service Re-use
– Infrastructure Portfolio

Business Benefits of SoA Framework

• Integrated business systems: -
– reduced cycle times / time-to-market, improved customer service
– reduced TCO – development, maintenance and operating costs
– easier and more accurate decision-making based on up-to-date business
information for quot;single version of the truthquot;

• IT cost reduction and control
– through standardization of reusable business components (Business Services)

• Improved responsiveness to provide support for new and changed
business processes - quickly and effectively

• The ability to respond to special business circumstances and conditions
as they occur: -
– Statutory and Regulatory Compliance
– Mergers and Acquisitions
– Business Transformation
– New Product Launch


Technology Benefits of SoA Framework
• Reduces time and effort to integrate new and existing applications
– Supports new business processes through the reuse of existing channel access,
collaboration and orchestration services
– Creates new business services through the reuse of existing service catalogue –
presentation, application and data services
– Provides Message Management via Messaging Services
– Provides Service Management via the Enterprise Service Bus
• Increases flexibility to change complex system behaviour by minimizing
the hidden dependencies among applications, services and middleware in a
distributed environment
• Reduced Total Cost of Ownership (TCO) and greater flexibility to
accommodate future needs through use of industry-standard interfaces and
protocols
• Reliably delivers messages across the Enterprise Service Bus, even after
software, network or hardware failure – “the message always gets through”
• Provides a service hosting & management infrastructure that is highly
distributed, yet centrally managed
• Enables rapid Platform Replacement and Technology Refreshment


SoA Strategy, Goals, Principles

SOA Governance Context
The purpose of SOA Governance is to balance the goals of Security, Manageability, Maintainability, and Reuse against those of Simplicity, Ease of
Use, and Cost Reduction

UPSTREAM EXTERNAL Entities DOWNSTREAM
Processes Processes
Systems Software Development
Integrators Companies Partners

AREA IN SCOPE

IT Governance
SOA Governance

Systems Development
Business Support,
Service Usage
Analysis Operations &
Decommissioning

INTERNAL Responsible For
Organisation Architecture Team Project

Business Service Discovery

Guiding Principle:
6Ps: Proper Planning
Business and Preparation
Analysis Activity Prevents Poor
Triggered through Performance
Business Case

Business
Analyst INBOUND - Collection Processes
Another
Iteration
required
Gather Initial Capture Business
Collateral Requirements

OUTBOUND - Presentational Processes

Specify 'To Be' Present Products
Business Solution
XOR

Analysis Approved
All Business Analysis should Enterprise Model
involve close interaction with Business Analysis
Usage
the Enterprise Model - this is Collateral Signed-
facilitated by the Business Off
Architect.

Enterprise Service Design
SOA Service Usage
Insert Short Description Here. This should be the first couple of sentences of the diagram description property

Potential for Service
Identified

Project
Consult Enterprise Examine UDDI to Use Existing Service
Model to identify identify operational
XOR XOR
appropriate candidate parameters of
Services candidate services

Candidate Service
No Candidate
Requires
Services Identified
Modification
Need to Develop Need to Modify Service Re-Used
New Service Existing Service

Enterprise Service Development
SOA Governance Process - Service Development
Insert Short Description Here. This should be the first couple of sentences of the diagram description property

Need to Develop Need to Modify
New Service Existing Service

OR

Project

Consult with BDT to Produce Initial Design Discuss Proposed Model Security Threat Build and Test Service Subject Service to
understand current of Service Design with and Identify Automated
Service Environment Architecture Team Appropriate Certification
Countermeasures

Modifications Required

Business Design
Team Provide Relevant
Collateral from
Enterprise Model

Design
Approved

Architecture
Team
Evaluate Design Sign-Off Service

Modifications to Modifications Required
Design Required
Service Signed-Off

Service Ready for
Roll-Out


how to implement Enterprise Services…..

Enterprise Services Derivation
Process Model Data Model
Process Data
Group Model

Business Business Subject Subject
Process 1 Process 2 Area 2 Area 1

Elementary Domain
Business Independent
Function Infrastructure
Process Messages
Catalogue Portfolio
Process Message
Application Technology
Group Portfolio
Step 1 Format 1
Enterprise
Services
Business Unit 1
Application 1
Enterprise
Service
Application Device 1
Customer
Module 1
Identification Service

Application Assembly
Component 1
1

Application Component
Object 1 1

Enterprise Services Composition
Technology Channel Access Services
Services

Presentation Services

Process Orchestration Services
Enterprise
Services
Application Services
Enterprise
Service
Business Service
Utility Services

Integration Services

Data Services

Infrastructure Services

Segment Architecture Layers
Channel Access

Presentation

BPMS

Collaboration

Services

Resources

Segment Architecture Mapping to Service Layers
Technology Channel Access Services
Segment Service Layers
Architecture
Channel Access Presentation Services

Presentation
BPMS

Collaboration

Common
Services
Utility Services

Enterprise
Resources

Data Services


Service Groups Mapping to Service Layers
Technology Service Layers

Service Groups Channel Access Services

APPLICATION

BUSINESS PROCESS


COARSE-GRAINED SERVICES

Utility Services

FINE-GRAINED SERVICES

ENTERPRISE COMPUTING ASSETS Data Services


Provision /
Planning / Purchase / Merchandising Analysis /
Marketing /
Replenish
Forecast Procure / Retail / POS Insight
Advertise

Channel
Access CC CC
CC CC CC CC
Services

Presentation Portal Portal
Portal Portal Portal Portal
Services

Process
Orchestration PO
PO PO PO PO PO
Services
POS
F/C
F/C
Application M /R Space EPS
D/W P/R PIMS P/R SCM D/W
Services
Site
EPM
CRM
CRM
Utility
Analytics ERP MIS
ERP MIS EPM
Services EPM ERP EPM
Analytics
Analytics
Integration
EAI EAI
EAI EAI EAI EAI
Services

Data Services
MDM
MDM MDM MDM MDM MDM

Infrastructure
P P
P P P P
Services

‘Buy’ ‘Move’
‘Plan’ ‘Promote’ ‘Sell’ ‘Report’

Service Architecture Mapping to SoA Framework Layers
Technology Service Layers
Service-oriented Architecture Layers
Channel Access Services

Channel Access Layer

Presentation Layer

Business Process Management Layer

Utility Services

Collaboration Layer


Services Layer
Data Services

Resources Layer

Enterprise Services

how to implement strategic change…..

Estimating - CRM v. ERP

• Estimating Method 1: Number of Services Delivered x Complexity = 320 man days Effort
– 111 Services – 18 Business Services unique to CRM, 93 Common Services shared with ERP
– 320 Man Days Effort – CRM Business Services 96 days + Common Services = 224 days
• Presentation, Business Rules and Application Services are unique to the CRM Project
(30% of total development effort = 96 man days)
• Data, Integration, Generic and Utility Services are shared with ERP Bespoke Phase 2
(70% of development effort = 224 man days)

• Estimating Method 2: Number of Agile Sprints x Sprint Duration = 4 months Elapsed Time
– 8 Sprints x 2 weeks (10 working days) = 4 months, average 3.5 Resources Deployed
– 320 Man Days Effort – CRM Effort 107 days + Common Services Effort =163 days, P&P = 50
days
• GUI, Business Rules, Application and Reporting Sprints are unique to the CRM Project
(40% of total development effort = 127 man days)
• Data, Integration, Generic and Utility Sprints are common with ERP Bespoke Phase 2
(60% of development effort = 193 man days)

Planning is the management of uncertainty…..

• Variable Estimating Factors
– Scope – there is some uncertainty surrounding the exact complexity and scope of CRM functions
– Development Productivity – the greater the utilisation of BizTalk, the greater the productivity
– Shared Services Split – the greater the re-use of Common Services with ERP, the lower CRM
effort
– Issues, Risks, Internal Constraints – Business Requirements, Architecture, Design Clarifications
– Impact of External Constraints – Availability of Resources, Environments, System Dependencies
• High Estimate – 320 man days
– Scope - High, Development Productivity – Low , Shared Services - Low, Constraints - High
• Mid Estimate – 270 man days
– Scope - Mid, Development Productivity – Mid , Shared Services - Low, Constraints - High
• Low Estimate – 256 man days
– Scope - Low, Development Productivity – Mid , Shared Services -High, Constraints - Low
• Target Estimate – 192 man days
– Scope - High, Development Productivity – High, Shared Services - High, Constraints - Low

CRM Sprint Profile
Target No. of Estimate
Linked
Delivery System Effort Acceptance Sign Off
Product to TRM Target
Engineers (days) Criteria Responsibility
Start Date Date
ID Deliverable Phase Stream Sprint Benefit to the Project

BEGEN Transfer - 1st Phase 2 - Stream 1 - Used to prototype and build
1 Sprint 1
Iteration - Happy Day Strategic Application BEGEN Happy 1st Iteration core BEGEN
Use Case (Simulators) Stream Day Scenario Transfer components with
3.0 30
(with Stubs) simulators / stubs
BEGEN Transfer - 2nd Phase 2 Stream 1 - Used to prototype and build
2 Sprint 2
Iteration - enhanced Strategic Application PMF Project 2nd Iteration BEGEN Transfer
Use Case with Stream Reference Data components with Reference
3.5 33
Reference Data Data Connectors
BEGEN Transfer - 3rd Phase 2 Stream 1 - Used to prototype and build
Sprint 3
4
BEGEN Transfer Framework
Iteration - enhanced Strategic Application PMF Project
Business Rules components
Use Case with Stream Business Rules
2.5 25
Business Rules
BEGEN Transfer - Phase 2 Stream 2 - Used to prototype and build
Sprint 4
3
Data Integration Strategic Integration 1 - PMF Project BEGEN Transfer Framework
Components - 4th Stream Data Integration Data Mapping components to
replace simulators and stubs
Iteration
2.5 24
Used to extract and load
BEGEN Transfer - Phase 2 Stream 2 - Sprint 5
5
2 - PMF Project external bulk data to BEGEN
Data Integration Strategic Integration
Data Integration Transfer Framework in
Components - 5th Stream
3.0 30
Canonical Data Format
Iteration
PMF Generic Services Phase 2 Stream 3 - Used to prototype and build
6 Sprint 6
/ Generic Components Strategic Utility / PMF Generic BEGEN Transfer Framework
- 6th Iteration Reporting Services Message Format and Queue
6.0 61
Connector components
PMF Generic Services Phase 2 Stream 3 - Used to prototype and build
7 Sprint 7
Components Strategic Utility / PMF Strategic BEGEN Transfer Framework
- 7th Iteration Reporting Reporting Generic Services components
5.0 48
PMF Utility / Reporting Phase 3 Stream 3 - Used to extend and package
Sprint 8
8
Components Tactical Utility / PMF Generic & BEGEN Transfer Framework
- 8th Iteration Reporting Data Services generic components
2.0 19
Enhancements
TOTAL 3.5 270
N.B. - Estimate based on strategic development
environment - Microsoft C#, ASP.NET, BizTalk, ANALYSIS Manpower Profile PMF Project 2 Months 4
126 PMF Component Effort
SQL/Server DA Team 1
143 Common Component Effort BA Team 1

CRM Project – Framework Services

CRM Project – Framework Components


how to manage Enterprise Services…..

ESB Principles

• ESB Principles • Centralised Logging Service
– Pragmatic to enable service – Public Message Queues on
design, create, maintain and use logging machine
– Scaleable, efficient and portable – Can create queues to suit
reliability and security
– Serviceable and resilient
requirements
– Useable and supportable
– BizTalk MSMQ runtime required
– Auditable and recoverable
on senders / connectors
– Cross Platform (Wintel – Solaris –
– Need to consider clustering
UNIX – Linux)
– Writes to SQL database
– Extensible and adaptable
– ESB Consumer and Server log to
– Supports the following: -
CLS
• Agile Methods
– SOAP Extension for XML Web
• Canonical Data Model
Services (ASMX)
• Domain Independent Message
Formats
• SoA Design Patterns
• Service Re-use


SoA Integrators, Connectors and Adaptors
• Legacy applications
– written in a variety of procedural languages that typically do not have well-defined Application Program Interfaces (API’s)
for collaborative processing, but functions may be “wrappered” as Remote Procedure Calls
• Object-oriented applications
– many different applets developed as components for other applications, such as Enterprise JavaBeans™, COM
Application Servers or CORBA objects etc.
• Transaction processing systems
– –applications that run under the control of transaction processing monitors such as distributed customer information
control system (CICS), IMS Transaction Manager (IMS/TM), BEA Tuxedo, and other TPMS software whose transactions
are well suited for incorporation into collaborative business processes
• Packaged application systems
– Vendor-supplied, proprietary systems with well-defined, often completely proprietary, collaborative interfaces such as SAP
Business API / NetWeaver Xi Adaptors, Oracle e-Business Suite Adaptor, PeopleSoft ETP Adaptor, JDE Master Business
Function Adaptor, etc.
• Databases and file systems
– Vendor-supplied, proprietary relational database management systems (RDBMSs), legacy database management
systems (DBMSs), and file systems with varying degrees of standard and proprietary interfaces including relational (e.g.
SQL, Oracle, DB2, MySQL etc.), hierarchical (e.g. IMS), network (e.g. IDMS) and file based (e.g. FTP, SFTP, ADABAS,
VSAM, etc.) data sources
• Communication transport protocols and message formats
– Industry-standard transports such as hypertext transport protocol (HTTP), file transfer protocol (FTP), and simple mail
transfer protocol (SMTP), Sun Enterprise Java Suite Adaptor, SoA Protocols such as XML, SOAP, WSDL, JMS,
ADO.NET, RNI, JDBC, EJB, ESB etc.
– Vendor proprietary messaging and queuing systems in a variety of formats for exchanging data between applications,
such as IBM WebSphere MQSI, Sun JMS, JCA and SeeBeyond eGate, Microsoft BizTalk MSMQ, BEA e-link (Tuxedo)
adaptors
• e-Business exchanges
– Proprietary and standards-based public and private exchanges through which businesses collaborate with other
businesses
– Proprietary data interchange systems in a variety of formats for exchanging data between collaborating enterprises, such
as Electronic data interchange (EDI), Society for the Worldwide Inter-bank Financial Telecommunication (SWIFT),.
• Application server platforms
– application and integration servers that host all manner of Application Service Provider (ASP) applications and On-
demand Services that facilitate collaboration within and between enterprises

Logical ESB Architecture

Contract & Message
Policy Persistence
Repository Service
Registry

Audit & Message
Consumer
Logging Queuing

Message
Format
Repository Message
Service
Formatting

Logical Service Registry Structure

Contract: Guid -> Contract WSDL

Binding: Binding WSDL (Policy)
Address

Address

Address

Centralised Logging Service

Enterprise Library (out of the box)

ESB Consumer
Service Registry

Contract
ESB Channel Factory Model
Cache

Factory Builder
Create Channel Instance Binding

Interface
Channel
List
Factory & Model

Uddi
Abort Proxy Cache
Cache WSDL
Service
Cache
Close
Cache

Channel Stack Message Stack
Contract &
Policy
Repository
Protocols Formatting

Messages
Messages
Channels
Channels

Encoding Queuing

Transport Persistence

Service Oriented Architecture 10 0

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Service Oriented Architecture 10 0

Semelhante a Service Oriented Architecture 10 0 (20)

Mais de Nigel Tebbutt

Mais de Nigel Tebbutt (9)

Service Oriented Architecture 10 0