Architecture Development Methodology for Business Applications

Transcription

1 4/7/2004 Business Applications Santonu Sarkar, Riaz Kapadia, Srinivas Thonse and Ananth Chandramouli The Open Group Practitioners Conference April 2004

2 Topics Motivation Methodology Overview Language and Tool Overview Summary 2

3 4/7/2004 Motivation

4 Development Methodology is vital for enterprises running large number of application development projects Illustrative Profile (Reference Infosys 2003)! 500 concurrent projects " team size! Projects have Requirements, and Development teams " 1-5 architects / team! teams start with requirements team & handover to Development teams Goals 1. Standardizing architecture process across the organization Standard approach, vocabulary, work-products 2. Streamlining work assignments for multiple teams Avoiding information loss, enforcing traceability 3. Strengthening architecture areas QoS analysis, integration, architecture evaluation which are high-importance areas 4. Improving productivity through tools and automation 4

5 Different Aspect of TOGAF, Zachmann SEI ATAM, SAAM ISO RM-ODP IBM enterprise architecture standard C4ISR US Treasury Development process Bredemeyer architecture process Network Queuing theory, MVA Markov modeling for availability analysis Formal verification techniques Rule based system for applying architecture heuristics Engineering best practices Framework & process methods, analysis Aspects description standards Reference s Tools & Systems * C2SADL, RAPIDE, WRIGHT, DARWIN, Rational Rose, TogetherJ Ptech, Metis, System Architect (Popkin) Performance Metron, TeamQuest Availability analysis Meadep description standards ISO RM-ODP IEEE 1471, 4+1 views ISO/IEC 9126 software quality modeling UML, BON, MDA EDOC description language Behavior modeling BPML, BPELWS, Statechart, CSP, Petri-net, ASML, POSET, FSM Patterns Insurance Reference : IAA IBM e-business patterns Business Patterns Integration Patterns Composite Patterns Custom Design pattern E++ architecture pattern for B2C and B2B systems Style 5

6 Scope of Methodology Formalize Process for definition - track - Flavors of process Defining an architecture development methodology for business applications InFlux TM framework Define standard architecture representation - Viewpoints - Meta-model & language - Standard architecture doc process methods Framework description standards Reference s Tools to support the framework - Modeling tools - Automation areas such as code generation Strengthen architecture areas - Methods/techniques for various areas (availability, integration, performance, variability etc.) Define prescriptive architectures - Standard stereotypes and patterns for J2EE,.NET.. - Reference for Domain problems 6

7 4/7/2004 Methodology Overview

8 While creating the Framework certain guiding principles have been followed Adopt Industry Standards for normative set of terminologies and notations to define architecture definition as per IEEE 1471 Viewpoint definition as per RM-ODP QoS framework definition as per ISO/IEC 9126 Have Separation of Concerns to address architectural complexities Each viewpoint addresses concerns of certain stakeholders Flexible for Distributed Development Model Should have traceability of decisions Phase based approach - should define hand-offs from one phase to another Guiding Principles Should facilitate strong Upstream and Downstream integration Derisk downstream implementation should be executable for use by downstream team Formalize Representation with Meta-model and Tool creation through Views Report Generation Analysis Reasoning/Inference capability Dynamism Provide Tailorability to address various project contexts Create a generic process independent of technology Tailor the generic process to a Technology specific prescriptive one # J2EE #.NET 8

9 Process Context Consists of 3 phases- each produces a deliverable Overlaps with requirement and development process Focuses on functional, information, technical and infrastructure aspects Requirements Solution Brief System Methodologies Performance Engineering Availability Analysis Product Selection Quality of Service Requirements Strategize Define Implement Realization Design & Development Source: InFlux architecture track, Infosys 9

10 IBM HEWLETT PACKARD A Phase is a part of the architecture lifecycle. Each phase defines certain aspects of the architecture by creating the views associated with the viewpoints. Solution Brief Strategize Enterprise Viewpoint Enterprise system boundary Define Computational Viewpoint System A Internet System B Supplier Partner Customer Information Viewpoint System C Enterprise System D Environment/Context Engineering Viewpoint Realization Implement Technology Viewpoint Software Organization Viewpoint (New addition) Engineering Viewpoint Proof of Concept System Source: InFlux architecture track, Infosys 10

11 Process is driven by 3 broad factors Based On IEEE 1471 recommended architecture ISO/IEC RM-ODP recommended viewpoints ISO 9126 recommended QoS Framework System Document contains all viewpoints Cost & Benefit Risk & Feasibility Productivity Strategize Define Implement Gather Inputs Identify Patterns Gather Inputs Identify Patterns Assess Risk Define Software Organization Define Development & Build Environment Identify Services Perform Product Selection Identify Services Identify Subsystems & App Services Perform Domain Analysis Do Reference Implementation Validate QoS requirements Define Infrastructure Solution Brief Perform Product Selection Define Infrastructure Define Framework System Define Infrastructure Define Installation Configuration Can be Tailored to.net Prescriptive J2EE Prescriptive Realization Source: InFlux architecture track, Infosys 11

12 Process Development Approach Industry Survey Current experience Create Baseline Process Community Draft refers 0..* Track name {ordered} 1..* Core team Architect Community Refine Process with community Piloting Review with Community Prioritize & Layout roadmap Define Prescriptive s Public Draft Intranet SourceForge based development Define Metamodel 0..* Framework name type 0..* 0..* Methods, Templates, Reference Models, Standards, Best practices refers 1..* Activity name pre-conditions post-conditions tasks roles metrics applicabilityrules tailoringrules Phase name executed in 0..* 1..* consumes / produces 1..* Work Product name Review with Public & Refine Quality team Education team Rollout, Education & Support Public Release Develop tools Deployment Note: Community refers to Infosys architects, Public refers to Infosys users and stakeholders Source: InFlux architecture track, Infosys Source: InFlux meta-model specification Adopted concepts from SPEM, OMG Unique concepts based on Infosys experience Track (collection of activities) Building processes from disciplines Formalization of framework types Tailoring feature for project specific customization Concept of reference work-products (knowledge elements) 12

13 Process Development Learnings Community based development approach for quick adoption Involvement of key stakeholders ensures easy deployment by the practitioners Involvement of Quality department ensures faster broad-basing Lightweight process to cover most aspects of architecture and tailor it to suite the context Global development approach by introducing phase based development Strategize phase can be at the client location whereas the detailed architecture development can be performed off-shore 13

14 4/7/2004 Language and Tool Overview

15 is captured using a graphical modeling language EAML Uses IEEE 1471 Conceptual Framework as the basis. Defines notations for all the views and viewpoints. Facilitates traceability among various views Uses OMG MOF to organize the metamodel notations Introduces component-connector concepts in modeling Provides notations for design rationale 15

16 Overview of some modeling concepts Subsystem1 Maps functional subsystems to n-tier architecture Associate architecture services required by a subsystem Associate COTs products Models business processes Facilitates creation of functional architecture from business processes Allows functional decomposition Maintains traceability Subsystem1_UI Presentation tier Business tier Subsystem1_BZ Data tier Subsystem1_DB Source: InFlux architecture track, Infosys 16

17 Modeling tool allows to draw views associated with viewpoints. Each view is a diagram. Viewpoint View Elements Computational Engineering Technology Information Software Organization Context Diagram Functional Diagram Logical Diagram Application Diagram Deployment Diagram Domain Diagram Realization Diagrams Layer Diagram System, interconnection, protocol, service System, subsystem, interface, messages Subsystems, components mapped into tiers Tier with COTS product and application mapping Hardware, devices, networks for production, QA and Development environment Domain entities and Relationships Application frameworks, patterns Packages, layers, dependencies Source: InFlux architecture track, Infosys 17

18 Illustration: The Unified Billing Solution is a global effort to create a single billing solution applicable to all regions Starts with understanding Principles, IT Gaps, IT Strategy. Uses business stereotypes to characterize the application Enterprise viewpoint is captured through a set of business processes Defines Computation, Information, Technology and Engineering viewpoints Software organization viewpoints for downstream integration

19 Summary methodology is vital for enterprises running large number of application development projects To enforce standardization of work-products and process To promote reuse, automation InFlux track is based on certain guiding principles separation of concerns upstream and downstream integration using community standards development model InFlux meta-model has semantics for representing architecture combination of industry standards use of views and viewpoints 19