Service Oriented Architecture 10 0

Solution Design

how to design software solutions for business transformation …..

Solution Architecture Topics

6. Software Product Line Development6.1. Carnegie Mellon University Software Engineering Institute Architecture Framework6.2. Agile Model Driven Design6.3. Model Driven Testing

7. Serviced-oriented Architecture Frameworks7.1 Enterprise Services7.2 Enterprise Service Bus7.3 Enterprise Application Integration

8. Solution Architecture8.1. Service-oriented Architecture Frameworks and the Enterprise Service Bus8.2. COTS Package Implementation 8.3. EAI, Collaboration and Process Orchestration

9. Solution Design and Systems Integration9.1. Solution Seeking – COTS Package evaluation and selection9.2. Solution Definition, – Package Module / Function / Service / Process Mapping9.3. Process Integration – Process Orchestration, Workflow, Collaboration9.4. Messaging – Domain Independent Message Design, Formatting, Queuing, Transport, Persistence

10. Business Continuity10.1. Business Continuity Planning – Transition, Capacity. Performance, Resilience, Reliability, Scalability.

11. Service Management Framework11.1. Service Planning & ICT Demand / Supply Model11.2. Service Virtualisation, Integration and Automation11.3. Service Design-Build-Operate11.4. On-demand Service Model

12. System Management Framework

EAEA--envision:envision: The Enterprise Framework for Business TransformationThe 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 ofthe 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: -

– Performance - Runtime Efficiency– Reliability - High Availability– Security - Data Asset Protection– 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– Performance - Runtime Efficiency– Reliability - High Availability– Security - Data Asset Protection– 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)


1. Performance Requirements (PR)

• 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


1. Performance Requirements (PR)

• 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

2. Security Requirements (SR)

• 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


2. Security Requirements (SR)

• 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

3. Maintenance and Support Requirements (MS)

• 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.)


3. Maintenance and Support Requirements (MS)

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


4. Operational Requirements (OR)

• 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


4. Operational Requirements (OR)

• 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 Identityrequirements 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…..

Agile Model Driven DesignSolution Architecture – Part 8Service-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 modelsare 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.


http://www.agilemodeling.com/essays/amddApproaches.htm

http://www.agilemodeling.com/essays/amddApproaches.htm#Manual

http://www.agilemodeling.com/essays/simpleTools.htm

http://www.agilemodeling.com/essays/whiteBoardModeling.htm

http://www.agilemodeling.com/essays/inclusiveModels.htm

http://www.agilemodeling.com/essays/amddApproaches.htm#DesignTool

http://www.agilemodeling.com/essays/inclusiveModels.htm

http://www.agilemodeling.com/essays/amddApproaches.htm#AgileMDA

http://www.agilemodeling.com/essays/mda.htm

Agile Model Driven Design

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

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.

Agile Sprint Activities

Figure 2. AMDD Through the Agile Development Lifecycle.

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.

Agile Work Management

Figure 3. Agile requirements change management process.

Why Does AMDD Work?

• AMDD works for several reasons: -• We meet our "project planning needs". 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 "middle of the road" 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.


http://www.ambysoft.com/essays/comparingEstimatingApproaches.html#MiddleOfTheRoad

http://www.agilemodeling.com/essays/examiningBRUF.htm#SignificantWastage

http://www.agilemodeling.com/values.htm#Feedback

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

Il faut le voir pour le croire…..

System Design models v. Test Design models

Test Design model development

Model Transformation

Test Component Transformation

SoA Frameworks

how to design Enterprise Services…..

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 Framework

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 WebLogicAdaptors, 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 BiztalkMSMQ, 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 betweenservice 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

Organisation Process Data Function Application InfrastructureEnterprise Vision & Mission StatementsBusiness Strategy

Business Transition Strategy

Data Management Strategy

Business Agility Strategy

Information Systems Strategy

Information Technology Strategy

Strategic EA Framework Business Process Re-engineering

Data Architecture Framework

SoA Framework Systems Framework Technology Framework

Enterprise Performance Management Framework

Data Principles, Policies Methods & Procedures

Agile Methods Application Blueprint Infrastructure Blueprint

Application Roadmap Infrastructure RoadmapOperational Strategies & Desired Outcomes,

Process Architecture Data Architecture Service-oriented Architecture

Information Systems Architecture

Information Technology Architecture

Organisation Hierarchy, Establishment Model

Process Model Conceptual Data Model Application Inventory Technology Portfolio

Enterprise Performance Management Strategy

Process Catalogue Data Catalogue Function Catalogue System Regimes Infrastructure Regimes

Data Management Functions

Service Library Asset Hierachy

Process Hierarchy Logical Data Model Function System Asset Meta Data Repository, Business Glossary

Service Module Device

Process Descriptions Data Management Services

Collaborations and Contracts

Unit

Organisation Locations, Posts & Post Holders,

Elementary Business Process

Physical Data ModelData Storage Strategy

Components

KPI’s and Metrics Data Placement Strategy ObjectsPerformance Targets Process Step Data Management

Modules Sites and Addresses, Data PlacementJobs and Employees, Training and Education, Competancies and Skills, Qualities and Capabilities

Database Instances DDL, Tables, Indices, Table Space, Storage Groups

Planned Objectives & Actual Achievements

Data Audit, Data Profiling, Data Quality Reporting

Resources Procedures Information Services Systems Facilities

ComponentACTUAL Procedure Instantiated Objects (Classes)

Executables, Applets

Assembly

Enterprise Architecture Context

STRATEGIC

CONCEPTUAL

Goals, Objectives CSF’s, Organisation Units,Roles & Responsibilities, Performance Plans

PHYSICAL Component

LOGICAL

Service Categories

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 "single version of the truth"

• 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

UPSTREAMProcesses

AREA IN SCOPE

DOWNSTREAMProcesses

EXTERNAL Entities

INTERNALOrganisation

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

Systems Integrators

Software Companies

Development Partners

Architecture Team Project

IT Governance

Responsible For

Systems DevelopmentBusiness Analysis

Support, Operations & Decommissioning

SOA Governance

Service Usage

Business Service Discovery

Business Analyst INBOUND - Collection Processes

OUTBOUND - Presentational Processes

Business Analysis Collateral Signed-Off

Analysis Approved

Gather Initial Collateral

Capture Business Requirements

Another Iteration required

Specify 'To Be' Business Solution

Present ProductsXOR

Business Analysis Activity Triggered through Business Case

Enterprise Model Usage

All Business Analysis should involve close interaction with the Enterprise Model - this is facilitated by the Business Architect.

Guiding Principle:6Ps: Proper Planning and Preparation Prevents Poor Performance

SOA Service Usage

Insert Short Description Here. This should be the first couple of sentences of the diagram description property

Project

Potential for Service Identified

Consult Enterprise Model to identify appropriate candidate Services

XOR

Need to Develop New Service

No Candidate Services Identified

Examine UDDI to identify operational parameters of candidate services

XOR

Need to Modify Existing Service

Candidate Service Requires Modification

Use Existing Service

Service Re-Used

Enterprise Service Design

SOA Governance Process - Service Development

Insert Short Description Here. This should be the first couple of sentences of the diagram description property

Architecture Team

Business Design Team

Project

Need to Develop New Service

Need to Modify Existing Service

OR

Consult with BDT to understand current Service Environment

Produce Initial Design of Service

Provide Relevant Collateral from Enterprise Model

Discuss Proposed Design with Architecture Team

Evaluate Design

Modifications to Design Required

Build and Test Service Subject Service to Automated Certification

Modifications Required

Sign-Off Service

Modifications Required

Service Ready for Roll-Out

Service Signed-Off

Model Security Threat and Identify Appropriate Countermeasures

Design Approved

Enterprise Service Development


how to implement Enterprise Services…..

Enterprise Services Derivation

ProcessGroup

BusinessProcess 1


BusinessProcess 2

Process Step 1

ProcessGroup

BusinessProcess 1


BusinessProcess 2

Process Step 1

Enterprise ServiceCustomer

Identification Service

Data Model

Subject Area 1

Domain Independent Messages

Subject Area 2

Message Format 1

Data Model

Subject Area 1

Domain Independent Messages

Subject Area 2

Message Format 1

ApplicationGroup

BusinessApplication 1

Application Module 1

ApplicationObject 1

ApplicationComponent 1

ApplicationGroup



ApplicationObject 1


ApplicationGroup



ApplicationObject 1


Technology Portfolio

Unit 1

Device 1

Component 1

Assembly 1


Unit 1

Device 1

Component 1

Assembly 1


Unit 1

Device 1

Component 1

Assembly 1

Process Model Data Model

Function Catalogue

Infrastructure Portfolio

Enterprise Services

Enterprise Services Composition

Enterprise Service

Business Service

Presentation Services

Process Orchestration Services

Application Services

Utility Services

Integration Services

Data Services

Infrastructure Services

Channel Access Services




Utility Services


Data Services



Enterprise Services

Technology Services

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


Segment Architecture Layers

Channel Access

Presentation

Collaboration

Resources

Services

BPMS

Segment Architecture Mapping to Service Layers

Channel Access

Presentation

Collaboration

EnterpriseResources

CommonServices

BPMS




Utility Services


Data Services


Channel Access ServicesTechnology Service LayersSegment

Architecture

Service Groups Mapping to Service Layers




Utility Services


Data Services



APPLICATION

BUSINESS PROCESS

COARSE-GRAINED SERVICES

FINE-GRAINED SERVICES

ENTERPRISE COMPUTING ASSETS

Technology Service Layers

Service Groups




ApplicationServices

Utility Services


Data Services


Planning / Forecast

Purchase / Procure

Provision / Replenish

Merchandising / Retail / POS

Analysis / Insight

Marketing / Advertise

Planning / Forecast

Purchase / Procure

Provision / Replenish

Merchandising / Retail / POS

Analysis / Insight

Marketing / Advertise

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

PO

PIMS EPS

PortalPortal PortalPortalPortal

P/R

MDMMDM MDMMDMMDM

EPM

D/W

Analytics ERP MIS

SCM

POPOPOPO

M /R Space

POS

Site

CRM

F/C

Portal

MDM

EAIEAI EAIEAIEAI EAI EAIEAI EAIEAIEAI EAI

D/W

Analytics

PO

F/C

ERP MIS

CRM

EPM

Analytics

EPMEPM ERP

P/R


CCCC CCCCCC CC CCCC CCCCCC CC

PP PPP P PP PPP P

Service Architecture Mapping to SoA Framework Layers

Channel Access Layer

Presentation Layer

Collaboration Layer

Resources Layer

Services Layer

Business Process Management Layer




Utility Services


Data Services


Channel Access ServicesService-oriented Architecture Layers

Technology Service Layers

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 Sprints

CRM Work Streams

CRM Sprint Profile

Product ID Deliverable

Linked to TRM Phase Stream Sprint Benefit to the Project

Target Start Date

Target Delivery Date

No. of System Engineers

Estimate Effort (days)

Acceptance Criteria

Sign Off Responsibility

1 BEGEN Transfer - 1st Iteration - Happy Day Use Case (Simulators)

Phase 2 -Strategic

Stream 1 - Application

Stream

Sprint 1BEGEN Happy Day Scenario

(with Stubs)

Used to prototype and build 1st Iteration core BEGEN Transfer components with simulators / stubs 3.0 30

2 BEGEN Transfer - 2nd Iteration - enhanced Use Case with Reference Data

Phase 2Strategic


Stream

Sprint 2PMF Project

Reference Data

Used to prototype and build 2nd Iteration BEGEN Transfer components with Reference Data Connectors 3.5 33

4 BEGEN Transfer - 3rd Iteration - enhanced Use Case with Business Rules

Phase 2Strategic


Stream

Sprint 3PMF Project

Business Rules

Used to prototype and build BEGEN Transfer Framework Business Rules components

2.5 253 BEGEN Transfer -

Data Integration Components - 4th Iteration

Phase 2Strategic

Stream 2 - Integration

Stream

Sprint 41 - PMF Project Data Integration

Used to prototype and build BEGEN Transfer Framework Data Mapping components to replace simulators and stubs

2.5 245 BEGEN Transfer -

Data Integration Components - 5th Iteration

Phase 2Strategic

Stream 2 - Integration

Stream

Sprint 52 - PMF Project Data Integration

Used to extract and load external bulk data to BEGEN Transfer Framework in Canonical Data Format 3.0 30

6 PMF Generic Services / Generic Components - 6th Iteration

Phase 2Strategic

Stream 3 - Utility /

Reporting

Sprint 6PMF Generic

Services

Used to prototype and build BEGEN Transfer Framework Message Format and Queue Connector components 6.0 61

7 PMF Generic Services Components - 7th Iteration

Phase 2Strategic


Reporting

Sprint 7PMF Strategic

Reporting

Used to prototype and build BEGEN Transfer Framework Generic Services components

5.0 488 PMF Utility / Reporting

Components - 8th Iteration

Phase 3Tactical


Reporting

Sprint 8PMF Generic & Data Services Enhancements

Used to extend and package BEGEN Transfer Framework generic components

2.0 19TOTAL 3.5 270

ANALYSIS Manpower Profile PMF Project 2 Months 4126 PMF Component Effort DA Team 1143 Common Component Effort BA Team 1

N.B. - Estimate based on strategic development environment - Microsoft C#, ASP.NET, BizTalk, SQL/Server

CRM Project – Framework Services

CRM Project – Framework Components


how to manage Enterprise Services…..

ESB Principles

• ESB Principles– Pragmatic to enable service

design, create, maintain and use– Scaleable, efficient and portable– Serviceable and resilient– Useable and supportable– Auditable and recoverable– Cross Platform (Wintel – Solaris –

UNIX – Linux)– Extensible and adaptable– Supports the following: -

• Agile Methods• Canonical Data Model• Domain Independent Message

Formats• SoA Design Patterns• Service Re-use

• Centralised Logging Service– Public Message Queues on

logging machine– Can create queues to suit

reliability and security requirements

– BizTalk MSMQ runtime required on senders / connectors

– Need to consider clustering– Writes to SQL database– ESB Consumer and Server log to

CLS– SOAP Extension for XML Web

Services (ASMX)



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

Web Client Software Factory

Logical ESB Architecture

Service Registry

Consumer

Service

Message Queuing

Contract & Policy

Repository

Message Format

Repository

Audit & Logging

Message Formatting

Message Persistence

Network Deployment

Logical Service Registry Structure

Contract: Guid -> Contract WSDL

Binding: Binding WSDL (Policy)Address



Centralised Logging Service

Enterprise Library (out of the box)

ESB Consumer

Service Registry

Contract Model Cache

Binding Model Cache

Service Cache

Uddi

Interface

ESB Channel Factory

Channel

Factory Builder

Contract & Policy

Repository

Instance ListFactory &

ProxyCache

Create Channel

Abort

CloseWSDLCache

Persistence

Queuing

FormattingMessages

Message Stack

Persistence

Queuing

FormattingMessages

Message Stack

Transport

Encoding

ProtocolsChannels

Channel Stack

Transport

Encoding

ProtocolsChannels

Channel Stack

Service Oriented Architecture 10 0

Documents

Transcript of Service Oriented Architecture 10 0