Service Oriented Architecture 10 0
Upcoming SlideShare
Loading in...5
×
 

Service Oriented Architecture 10 0

on

  • 1,782 views

Design Methodology for delivering Enterprise Services

Design Methodology for delivering Enterprise Services

Statistics

Views

Total Views
1,782
Views on SlideShare
1,759
Embed Views
23

Actions

Likes
1
Downloads
102
Comments
0

5 Embeds 23

http://www.linkedin.com 9
https://www.linkedin.com 7
https://twitter.com 4
http://www.slideshare.net 2
http://www.lmodules.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Service Oriented Architecture 10 0 Service Oriented Architecture 10 0 Presentation Transcript

  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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. EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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) EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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.) EA-envision: The Enterprise Framework for Business Transformation
  • 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) EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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? EA-envision: The Enterprise Framework for Business Transformation
  • 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? EA-envision: The Enterprise Framework for Business Transformation
  • Agile Model Driven Design how to design Enterprise Business Services…..
  • Agile Model Driven Design 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. EA-envision: The Enterprise Framework for Business Transformation
  • Agile Model Driven Design 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. EA-envision: The Enterprise Framework for Business Transformation
  • 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
  • Test Design model development
  • Model Transformation
  • Test Component Transformation
  • 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. EA-envision: The Enterprise Framework for Business Transformation
  • 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. EA-envision: The Enterprise Framework for Business Transformation
  • SoA Lite • SoA Lite is the Service-oriented Architecture (SoA) Framework for organisations that are primarily deploying simple Web Services: - EA-envision: The Enterprise Framework for Business Transformation
  • 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.) EA-envision: The Enterprise Framework for Business Transformation
  • 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). EA-envision: The Enterprise Framework for Business Transformation
  • Enterprise Service 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
  • 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 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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 EA-envision: The Enterprise Framework for Business Transformation
  • 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
  • Service-oriented Architecture 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
  • 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
  • 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 Process Orchestration Services BPMS Application Services Collaboration Common Services Utility Services Enterprise Resources Integration Services Data Services Infrastructure Services
  • Service Groups Mapping to Service Layers Technology Service Layers Service Groups Channel Access Services APPLICATION Presentation Services Process Orchestration Services BUSINESS PROCESS Application Services COARSE-GRAINED SERVICES Utility Services FINE-GRAINED SERVICES Integration Services ENTERPRISE COMPUTING ASSETS Data Services Infrastructure Services
  • Service-oriented Architecture 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 Services Presentation Layer Process Orchestration Services Application Services Business Process Management Layer Utility Services Collaboration Layer Integration Services Services Layer Data Services Resources Layer Infrastructure Services
  • 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 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
  • Enterprise Service Bus 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 EA-envision: The Enterprise Framework for Business Transformation
  • Enterprise Service 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 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 Contract & Message Policy Persistence Repository Service Registry Audit & Message Consumer Logging Queuing Message Format Repository Message Service Formatting
  • Network Deployment
  • Logical Service Registry Structure Contract: Guid -> Contract WSDL Binding: Binding WSDL (Policy) Address Binding: Binding WSDL (Policy) Address Binding: Binding WSDL (Policy) 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