• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Architecture for Reuse
 

Architecture for Reuse

on

  • 1,185 views

 

Statistics

Views

Total Views
1,185
Views on SlideShare
1,185
Embed Views
0

Actions

Likes
0
Downloads
18
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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
  • A Layered architecture organizes software according to generality Dimensions of a layered architecture Horizontal – for systems interacting within the same layer Vertical – for static dependencies across layers Reuse is restricted to only horizontal layers Reuse within vertical layers would lead to static dependencies of components
  • A Layered architecture organizes software according to generality Dimensions of a layered architecture Horizontal – for systems interacting within the same layer Vertical – for static dependencies across layers Reuse is restricted to only horizontal layers Reuse within vertical layers would lead to static dependencies of components

Architecture for Reuse Architecture for Reuse Presentation Transcript

  • CS 6356 Reuse Designing the Process and Organization for Reuse
  • Chapter 9
    • Applying Business Engineering To Define Processes And Organization
      • Processes and Organization of the Reuse Business match architecture
        • Critical Challenges with the reuse business -Reuse requires significant S/W engineering organization and process change
      • How can such a change be sustained and improved?
        • Leverage a well-defined process and provide organizational support
      • As we explore how, we will walk through the process at BIGCAR company as it reorganizes its business and IT support to meet new challenges and improve the capability to respond to a changing environment
  • BIGCON has been tasked with the design of the Technology Solution Architecture (TSA) for the BIGCAR Direct retailing concept in Eastern Europe. Overall solution constituents of BIGCAR Direct concept and BIGCON`s focus areas Vision; Concept & Strategy Rollout plan Processes Capabilities Technologies Infrastructure Business Systems Architecture Technology Systems Architecture (TSA) BIGCON focus - enablement BIGCON - peripheral attention for alignment BIGCON focus - translation & congruence BIGCON primary focus Solution Architecture
  • Today`s session heralds the end of the second phase of an three-phased engagement. TSA Design & Roadmap formulation Overview of BIGCON approach - major focus areas or activities Review & Consolidation Solution portfolio analysis & alternative selection
      • Identify and catalogue applicable and available information
      • Develop integrated view of BIGCAR designs
      • Provide feedback on strategy, business model and processes
      • Address process gaps and under-specification as necessary
      • Understand current ITA
      • Identify key TSA issues
      • Identify region-specific factors for consideration and Moments-of-Truths (MOTs)
    • Build Macro TSA solution portfolios:
      • Functional requirements
      • Operational requirements
      • Best mix
    • Ensure optimal fit with overall solutions architecture
    • Incorporate Best-Practice expertise
    • Recommend most feasible alternative and obtain decision
    Today`s session
    • Build on and design in greater detail the selected solution portfolio(s)
    • Verify findings on country basis
    • Make recommendations relating to TSA requirements
    • Modify Business Systems Architecture - where applicable
    • Detail investment and other requirements ito constraints
    • Define scope and broad requirements for prototyping - if applicable
    • Make recommendations on ongoing technical support and application acquisition
    • Advise on possible implementation roadmap scenarios
    Deliverable: Review of BIGCAR Direct concept/processes Deliverable: Macro Design; validation and selection of feasible solution portfolio(s) Deliverable: BIGCAR Direct TSA design (as defined by set constraints)
  • One of many challenges relating to the BIGCAR Direct concept is the creation of a fresh customer-centric business model - without falling back to old habits in the process. Challenges in developing TSA for BIGCAR Direct Questions relating to challenges
    • Apparent paradox between the diverging objectives of “right-sized” investment as opposed to scalability
    • To what extent does one invest today for the possibility of expansion at a later stage?
    • Which parts of the BIGCAR Direct solution are to be made scalable?
    • Conformity to BIGCAR systems and standards despite relative insignificance of market size and volumes
    • Should one re-use or integrate with existing BIGCAR systems even though this right be unsuitable from a market-size perspective?
    • The applicability or re-usability of the BIGCAR Direct concept for other - even significantly larger - markets
    • Is it possible to draw any valid conclusions on the applicability of the BIGCAR Direct concept for other large marketplaces?
    • Are there additional complications relating to scale and the size of investments which makes the argument for applicability in other market circumstances tenuous?
    • Ensuring that customer-centric business operations are adequately supported and maintainable
    • Is it possible to ensure smooth customer pleasing processes and interactions in small markets without the support of sophisticated (and therefore expensive) technologies?
    • Investing in "differentiators" which will bring the highest returns for BIGCAR
    • Which investments promise to lead to greatest returns in the new customer-centric business model?
    Listing of major challenges in developing a TSA for BIGCAR Direct concept
    • Providing for both a wholesaling (traditional) and retailing (new) component within one combined solution
    • How does one incorporate both elements (whole selling and retailing) within one integrated solution?
  • Step 1 - In presenting our solution a structured four-stepped approach has been adopted. BIGCAR Direct concept Operational (IT) perspective of solution Mobile client Local environment Integration node Functional perspective of solution Hypothesis Evaluation Recommendation Operational solution Functional Solution 1.) Analysis 2.) Modular solution design 3.) Solution integration 4.) Solution “right sizing” Step 1 Step 2 Step 3 Integrated solution Diagrammatic representation of four-stepped solution approach - step 1 Step 4 Hi-level Enterprise Process Model Use cases Functional Requirements Product related Customer-centric Administration/ Governance
  • Chapter 7
    • Layered Architecture
      • Architecture defines system structure, interfaces, and interaction patterns
        • Structure defines the static organization of software into sub-systems
        • Interfaces provide the ‘glue’ between subsystems
        • Interaction patterns refers to how nodes interact with each other
  • Chapter 7
    • Layered Architecture
      • A good architecture is crucial to maintain system integrity
        • Amenable to change and easily maintainable – i.e. Changes or updates become less expensive
        • Manageable parallel development- reduces time to market
        • Well defined interfaces and predictable functionality – Promotes reuse
      • What is the best architecture, and how can it be achieved ?
  • Chapter 7
    • Layered Architecture
      • A Layered architecture organizes software according to generality
        • Applications consist of components and components may consist of other components-A composition of a layered architecture
        • Definition - A Layered architecture is a software architecture that organizes software in layers, where each layer is built on top of another more general layer
        • A typical layered architecture may have the following four layers
          • Application system layer – Topmost layer
          • Business-specific layer – Next layer
          • Middleware layer(Utility classes and platform-independent services)
          • System software layer – bottom layer (computing and network infrastructure )
  • Layered Pattern Architecture Example Application systems Business Systems Middleware System Software Enables communication between different processes ORB’s Java ODBC RPC’s spreadshets GUI builders etc Component systems specific to the business Type Example Inventory control/ Money Management Applications which provide services and coherent uses cases direct contact with the users Example ATM/web shopping Interfaces to the hardware; computing and networking infrastructure; operating systems TCP/IP Windows NT Application Application Enablement Infrastructure
  • Chapter 7
    • Layered Architecture
      • A Layered architecture organizes software according to generality
        • Dimensions of a layered architecture
          • Horizontal – for systems interacting within the same layer
          • Vertical – for static dependencies across layers
          • Reuse is restricted to only horizontal layers
          • Reuse within vertical layers would lead to static dependencies of components
  • Systems in one layer may not depend on systems in a higher layer See Figure 7.3 pg 175 in text System Dependencies System interaction Application System A Application system B Application system C Component 1 Component 2 Component 3 Component 4
  • Chapter 7
    • Layered Architecture
      • A layered architecture reduces software dependencies
        • Organizing software into layers according application specificity
          • Components become more general further down the layer
        • Layered architecture is intuitive and understandable
        • May be defined in detail in terms of interfaces and facades
        • Reduce dependencies on lower layers by allowing dependencies only on components explicitly exported from the facades of lower layers
  • Chapter 7
    • Layered Architecture
      • The middleware layer supports distributed object computing
        • CORBA/OpenDoc Layered Architecture
          • Allows interoperability between components regardless of the platform
          • ORB – Marshals and forwards messages to objects distributed in heterogeneous environments
        • COM/OLE and ActiveX - Microsoft way of sharing parts of documents, such as embedded spreadsheets in documents
        • OLE is based on underlying COM model
  • Chapter 7
    • Layered Architecture
      • The Business-Specific later supports rapid application development
  • Chapter 7
    • Layered Architecture
      • Using multiple models when working with layered system architecture
  • Architecture & Views Deployment View Process View Implementation View Use Case View Analysts/Designers Structure performance scalability throughput behavior system assembly configuration mgmt. system topology distribution delivery installation Logical View
  • Chapter 7
    • Layered Architecture
      • Representing a layered system as a superordinate system
      • A second level of abstraction that represent the static and dynamic aspects of the system as a whole
      • Allows
        • Manage architecturally significant parts as a product
        • Coordinate the different views as a whole
        • Use similar tools to work with the overall system
        • Training
  • A system of interoperating systems the superordinate system <<imports>> <<system of interoperating systems>> S System A System C System C
  • Use cases are allocated to design subsystems <<Superordinate system>> << subsystem a>> C B A << subsystem b>> << subsystem c>> x y z Xa Ya Xb Yb Za Zb Yc <<trace>> Actor 3 Actor 2 Actor 1 Actor 2 Actor 1 Actor 3
  • Chapter 7
    • Layered Architecture
      • Wrapping legacy systems to fit the architecture
  • Chapter 7
    • Layered Architecture
      • Distributed processes and nodes for a layered system
      • Complicate the Architecture
      • Delay decision as long as possible
  • The Enterprise Technology Framework
    • Key component part of an enterprise-wide business and IT architecture (normally referred to as an Enterprise Architecture).
    • This work product is used as a repository for all information about the IT capabilities and enablers required to implement the desired business objectives and capabilities
    • . An Enterprise Technology Framework defines the technology services and functions (IT capabilities) required to support the business applications and data, including
      • Common Application Services,
      • Common Data Services,
      • Common System Services,
      • Network Services, Security Services,
      • Platform Services,
      • As well as the management tools used to support the delivery of IT service.
    • The Enterprise Technology Framework must be totally aligned with the business applications and data, if the business goals, objectives and benefits are to be realized.
  • Conceptual model (Superordinate)
    • Conceptual model
      • This base Conceptual Model identifies and defines all the technology functions required by the enterprise and develops a single graphical representation at a high level, showing relationships and interdependencies. This model becomes a &quot;repository&quot; of information about technology across the enterprise.
      • Describes the IT functionality needed to support each of the desired IT services
      • Documents the characteristics that the future IT environment(s) must have
      • Documents the measurable performance targets (at an overall level) the future IT environment(s) must be able to support
      • Rates the functionality requirements for each desired IT service in terms of their importance and contribution to achieving the desired strategic position
      • Identifies candidate technologies that may be implemented, along with the feasibility of deploying those technologies and the potential impact they will have on the ability to deliver the required services
  • The Enterprise Technology Framework is used to:
    • provide a total repository of information about the technology (IT enablers and capabilities) required to support both the various parts of the business, and the achievement of the overall business goals and objectives – provides a framework for making IT investment decisions
    • provide a repository of agreed technology principles, standards, products and components that can be selected at system design time and implemented
    • reduce the amount of time spent by individual development projects in the evaluation and selection of products and components
    • provide pre-defined combinations of implement able components, standards and interfaces
    • ensure individual systems can be integrated effectively, including the sharing of common services, functions, 'middleware' and data
    • provide a known technology base for service delivery planning (capacity, performance, availability) and measurement, to meet future business requirements
    • provide the basis for the specification of the required (‘to be’) IT systems
    • t helps to identify opportunities to enhance the current or new information technologies that can be adopted with beneficial impact on the desired IT environment
  • Layered Pattern Architecture Example Application systems Business Systems Middleware System Software Application Application Enablement Infrastructure Enables communication between different processes ORB’s ODBC RPC’s spreadshets GUI builders etc Component systems specific to the business Type Applications which provide services and coherent uses cases direct contact with the users Interfaces to the hardware; computing and networking infrastructure; operating systems
  • Simple Conceptual Model, showing the main, high level ABBs:
  • - the same Conceptual Model, exploded down to the next level of detail
  • - sample ABB definition
  • Chapter 9
    • Applying Business Engineering To Define Processes And Organization
      • Software engineering processes in the Reuse Business
        • The Reuse business adds value to its customer by establishing and using business use cases (processes)
        • Some of the most important actors are as follows:
          • Customers, End User, and Manufacturer
          • Customers are key stakeholders and usually involved in may aspects of the system development process and deliverables. (I.e deciding features, priorities, roll-out plans and new versions) They request application systems, place requirements, and usually finance the systems
  • The definition of BIGCAR Direct functional requirements is achieved through the establishment of a Hi-level enterprise model and “Use Cases”. Steps followed in the definition of functional requirements Hi-level Enterprise model of BIGCAR Direct concept
    • Describe how enterprise works
    • Establish different process priorities and types
    • Serve as functional framework
    Use Cases (business scenarios) of BIGCAR Direct concept Functional Requirements of BIGCAR Direct concept
    • Describe detailed interactions with customers
    • Describe the distribution of roles and responsibilities
    • Identify functional needs
    • Translate functional needs into functional modules
    • Establish business value of functional modules
    • Identify available functionality
    Functional perspective of solution
  • Chapter 9
    • Applying Business Engineering TO Define Processes And Organization
      • Software engineering processes in the Reuse Business
        • An End User is someone who will use the application system when it is installed in the target organization
          • Key contributors by providing requirements and new features in the engineering of the system; Usually Subject Matter Experts(SME)
        • A Manufacturer receives a new version of an application system, then customizes, configures, produces, and delivers complete applications to Customers
  • Business model of the Reuse Business ( Roles in Reuse ) Application Family Engineering Customer Asks for and PAYS for new systems End user Will use the system Application System Engineering Component System Engineering Manufacturer Customizes and installs (Develops overall layered system architecture) (Develops new versions with components) (Develops components for use)
  • Chapter 9
    • Applying Business Engineering TO Define Processes And Organization
      • Software engineering processes in the Reuse Business ( figure 9.2)
        • The business use case Application System Engineering develops new versions of application systems as requested by a Customer
        • The business use case Component System Engineering develops component system to be used by Application Engineers
        • The business use case Application family Engineering develops the product plan and engineers the layered system
  • Process Reengineering Organization IT Organization Function Function Function Function Technical Services Organization Process and Technology Group (PTG (Application Family) ) Solutions Delivery Group Component Systems Component Engineering Present State Future Model Technical Services Organization PTG Application Family Engineering Process Leadership
  • Application Family Engineering Principles - PTG (Application Family)
    • PTG (Application Family) owns Business Partner Relationships
    • PTG (Application Family) drives Process Reengineering
    • PTG (Application Family) responsible for providing Value Proposition
    • PTG (Application Family) ensures appropriate balance between strategic initiatives and the “right” tactical initiatives
    • PTG (Application Family) manages the Enterprise Model with the AOG
    • PTG (Application Family) owns the Applications and the Value provided to the Business
    • PTG (Application Family) owns Total Solution Delivery - People, Process, and Technology
    • PTG (Application Family) owns the Make - Buy Decision and Leads the Package Selection Process
    • PTG (Application Family) owns IT Planning and Funding Process
    • PTG (Application Family) is accountable for Total Cost Management and Business
    • Performance Metrics
    • PTG (Application Family) owns Application and Data Architecture (SDG and TSO own technical implementation and operation of the architecture)
  • TSO
    • Strategic Partnerships
    • Benchmarking
    • New Technology Ideas
    • Functional strategies
    • Business Plans
    • Prioritization
    • Funding
    • IT Performance Metrics
    • New business opportunities
    • Reengineering programs
    • Business process changes
    • Program / Project status
    • Program/Project Charter
    • Program Management
    • Prioritization
    • Funding
    • Status/progress of programs
    • Application Family Engineering
    • Business Partner Relationship
    • Process Reengineering
    • Business Benchmarking / Metrics
    • Program Management
    • Enterprise Model Management
    • Total Solution Management
    • Application and Data Architecture
    Automotive Industry IBM Netscape PeopleSoft Microsoft Application Family Engineering PTG (Application Family) Integrated Process Model - Level 0 Solutions Delivery Group AMC (Application System) Component Engineering AIC Leadership and Management EXTERNAL ENVIRONMENT Business Partners
  • 4.0 Manage Business Partner Relationships 9.0 Provide Leadership Business Partners Requests BP Plans Proposals Agreement Request for Changes Business Requirements Disposition New Needs Agreement Solutions Solutions Results Performance Measurements Proposal Internal Environment External Environment Automotive Industry Strategic Alliances C3P IBM Microsoft Netscape PeopleSoft MSO SCS M&S PD HR/OGC Enterprise 2.0 Identify Opportunities 1.0 Drive Business Process Transformation 14.0 Manage Strategic Relationships 19.0 Develop Cycle Plan and Manage Application Architecture 18.0 Program Management PTG (Application Family) Leadership and Management Finance 5.0 Manage Solution Portfolio 3.0 Evaluate Opportunities with Business Partners 6.0 Define Solution PL 15.0 Manage Internal Info Sys 16.0 Manage Processes 17.0 Manage Resources 20.0 Enterprise Management 10.0 Manage Human Resources 11.0 Manage Finances 12.0 Manage Communications 13.0 Manage Admin Support Status Reporting Industry Trends& Benchmarks Realized Benefits Monitor Progress AxC TSO Application Family Engineering PTG (Application Family) Integrated Process Model - Level 1 8.0 Deliver / Maintain Solutions 7.0 Design/ Develop/ Enhance Solutions
  • 4.0 Manage Business Partner Relationships 4.1 Build/Maintain BP Relationships 4.2 Communicate Capabilities 4.3 Realize expected benefits 4.4 Review progress with senior management 4.5 Deliver Charters / Proposals 4.6 Interface with AxCs on behalf of Bus Partners 4.7 Manage Agreements 4.8 Evaluate Customer Satisfaction 4.9 Total Cost Management 9.0 Provide Leadership 9.1 Develop Vision 9.2 Develop Process/ IT Strategy 9.3 Develop PTG (Application Family) Bus Plan Business Partners Requests BP Plans Proposals Agreement Request for Changes Business Requirements Disposition New Needs Agreement Solutions Solutions Results Performance Measurements Proposal Internal Environment External Environment Automotive Industry Strategic Alliances C3P IBM Microsoft Netscape PeopleSoft MSO SCS M&S PD HR/OGC Enterprise 2.0 Identify Opportunities 2.1 Identify Current Needs 2.2 Identify Future Needs 2.3 Document Requirements 2.4 Assess Present Solution Competitiveness 2.5 Breakdown Needs into Pgms. 14.0 Manage Strategic Relationships 19.0 Develop Cycle Plan and Manage Application Architecture 18.0 Program Management PTG (Application Family) Leadership and Management Finance 5.0 Manage Solution Portfolio 5.1 Assess Solution Performance 5.2 Manage Solution Families 5.3 Retire Obsolete Solutions 5.4 Review/Update Cycle Plan 3.0 Evaluate Opportunities with Bus. Partner 3.1 Establish BP priorities 3.2 Match Needs with Solutions 3.3 Cost vs. Benefit 3.4 Determine Fit 6.0 Define Solution 6.1 Develop Solution Concept 6.2 Assess Sol’n Competitiveness 6.3 Develop Solution Charter 6.4 Develop “Sales” Strategy 6.5 Make - Buy Decision PL 15.0 Manage Internal Info Sys 16.0 Manage Processes 17.0 Manage Resources 20.0 Enterprise Management 20.1 Develop/Maintain Enterprise Model 10.0 Manage Human Resources 11.0 Manage Finances 12.0 Manage Communications 13.0 Manage Admin Support Status Reporting Industry Trends& Benchmarks Realized Benefits Monitor Progress AxC TSO Application Family Engineering PTG (Application Family) Integrated Process Model - Level 2 8.0 Deliver / Maintain Solutions 8.1 Develop Delivery Schedule 8.2 Develop Training Solution 8.3 Deploy Solution 8.4 Support Solution 8.5 Measure Solution Performance 7.0 Design/Develop/ Enhance Solutions 7.1 Reengineer Processes (PTG (Application Family) (Application Family) ) 7.2 Design/develop/ configure New Solutions (Component Engineering) 7.3 Design/ Develop/En- hance Solutions (AMC (Application System)) 1.0 Drive Business Process Transformation 1.1 Expand From Existing Initiatives 1.2 Identify New Opportunities 1.3 Support Corp. Reengineering
    • Relationship Management
    • Manage Business Partner Relationship
    • Manage Application Solution Portfolio
    • Identifies reengineering & IT opportunities
    • Establish competitive benchmarks & value proposition for solutions
    • Participates in prioritization process
    • Manage delivery of IT solutions with SDG & TSO
    • Enterprise Process Reengineering
    • Drive business process transformation through Enterprise Reengineering initiatives
    • Identifies reengineering & IT opportunities
    • Establishes competitive benchmarks
    • Participates in prioritization process
    • Manage delivery of reengineering solutions
    • Manages enterprise cycle plan
    • Strategic Planning
    • Operates prioritization process
    • Establish agreed-upon cycle plan
    • Develop PL strategy & business plan
    • Administers management processes (e.g HR, Finance
    • Manage shared resources
    • Manage the transition plan
    • Enterprise Applications and Application Arch
    • Establish & maintain application development methodology
    • Manages the application cycle plan
    • Manages Enterprise application portfolios
    • Establishes & maintains application & data architecture
    • Researches & identifies emerging technology opportunities
    • Establishes application & infrastructure standards (ATAD)
    • Maintains the Enterprise Model
    Drive Business Process Transformation & Identify Opportunities Define Solutions Design, Develop Solutions Deliver & Maintain solutions 18 9-16 Eval Ops Eval Ops 7 20 Cycle Plan Tools & Tech. Define Solutions Design & Develop Solutions Define Solutions Cycle Plan Tools & Tech. 18 9-16 20 7 7 Design & Develop Solutions 9 Provide Leadership 10 Manage Human Resources 11 Manage Finances 12 Manage Communications 13 Manage Administrative Support 14 Manage Strategic Relationships 15 Manage Internal Information Systems 16 Manage Processes 18 Manage Programs 19 Develop Cycle plan and manage App. Arch. 20 Enterprise Management 7 9-16 19 20 Supp. Arch. Stds Application Family Engineering Strategic Planning & Prioritization
    • PTG (Application Family) (Application Family)
    • Drive current and future opportunities (2.0)
    • Forecast future work (2, 3)
    • Reengineer process as required (1, 7.1)
    • Define Solution concept, Pre-Charter & Charter (6)
    • Identify funding alternatives and gain customer
    • agreement for work (6)
    • Resource Component Engineering project team (PTG (Application Family) (Application Family) , Business, AMC (Application System)) (7.2)
    • Provide business process expertise to project (7.2)
    • Monitor and report program performance (4, 18, 19)
    • Manage Service Level Agreements and gain concurrence
    • from Business Partner (4.7)
    • Manages Help Desk process and escalation procedure (8.4)
    • Prioritize Change Requests (3.1, 4.6)
    • Identify funding alternatives and gain agreement for work
    • not containable within the annual funding agreement (3, 4.6)
    • Create business functional requirements (6)
    • AxC’s
    • Component Engineering Core and Project Teams
    • AMC (Application System)
    • AIC
    • BUSINESS PARTNERS
    • Validate Current and Future Opportunities (2.1, 2.2)
    • Participate in Chartering (6.3)
    • Fund project (6)
    • Provide project team w/ resources (specs, acceptance
    • testing, end user documentation) (7.2)
    • Monitor project performance (4)
    • Fund incremental projects (6)
    • Concur with Service Level Agreement (4.7)
    • Support deployment of solutions
    Build Relationships Opportunities Program Mgmt. Escalation Procedure Defined in AxC Interactions Application Family Engineering Business Partner Interaction Business Reeng. Value Proposition Perf. Metrics Corporate Help Desk Business Help Desk
    • PTG (Application Family) (Application Family)
    • Drive current and future opportunities (2.0)
    • Forecast future work (2, 3)
    • Reengineer process as required (1, 7.1)
    • Define Solution concept, Pre-Charter & Charter (6)
    • Identify funding alternatives and gain customer
    • agreement for work (6)
    • Schedule projects at Component Engineering (6)
    • Submit project (w/ charter) to Component Engineering (6)
    • Resource Component Engineering project team (PTG (Application Family) (Application Family) , Business, AMC (Application System)) (7.2)
    • Provide business process expertise to project (7.2)
    • Monitor and report project performance (4, 18, 19)
    • Perform/oversee integration testing (7.2)
    • Oversee & Signoff of completed acceptance test (7.2)
    • Develop launch priorities (8.1)
    • Provide application and data architecture
    • Component Engineering CORE
    • Facilitize resources per PTG (Application Family) Planning
    • Participate / Facilitate solution concept in Pre-Chartering
    • and Chartering (6)
    • Schedules projects within Component Engineering (7.2)
    • Validates project submissions (7.2)
    • Staff projects with developers (7.2)
    • Provide Component Engineering Methodology experts (7.2)
    • Provide technology specialists (7.2)
    • Manage Component Engineering delivery of project (7.2)
    • BUSINESS PARTNERS
    • Validate Current and Future Opportunities (2.1, 2.2)
    • Participate in Chartering (6.3)
    • Fund project (6)
    • Provide project team w/ resources (specs, acceptance
    • testing, end user documentation) (7.2)
    • Monitor project performance (4)
    • Signoff of completed acceptance test (7.2)
    • Component Engineering PROJECT TEAM
    • Plan, prototype, develop, test (7.2)
    • Provide feedback (7.2)
    • Perform acceptance testing (7.2)
    • Perform integration testing (7.2)
    • Provide deliverables (code, doc) (7.2)
    • Turnover to AMC (Application System) (7.2)
    • Create training materials (7.2)
    • First site implementation (up to 3 sites) (7.2)
    • Turnover to AIC if more than 3 sites (7.2)
    Opportunities Chartering Participation Progress, Performance Capacity Plan Chartering Participation/ Facilitation Scheduling Project Submission Staff Projects Progress, Performance PTG (Application Family) and Business Partner Project Resources Progress, Performance Application Family Engineering Component Engineering Interaction - New Projects
    • PTG (Application Family)
    • Drive current and future opportunities (2.0)
    • Forecast future work (2, 3)
    • Reengineer process as required (1, 7.1)
    • Program management oversight and review of scheduled
    • releases (18)
    • Prioritize Change Requests (3.1, 4.6)
    • Identify funding alternatives and gain agreement for work
    • not containable within the annual funding agreement (3, 4.6)
    • Create business functional requirements (6)
    • Create charter as required (6)
    • Manage Service Level Agreements and gain concurrence
    • from Business Partner (4.7)
    • Resource AMC (Application System) project team (7.3)
    • Oversee integration and acceptance testing (7.3)
    • Collect application metrics from AMC (Application System) (5.2)
    • Manages Help Desk process and escalation procedure (8.4)
    • AMC (Application System)
    • Production Operation and Support (8.4)
    • Design, construct, launch of scheduled release work (7.3)
    • Assist PTG (Application Family) in providing customer support for question,
    • investigating problems (8.4)
    • Assist PTG (Application Family) in preliminary analysis and cost estimates
    • for new change requests (3)
    • Measure solution performance against the SLA (8.5)
    • Work with PTG (Application Family) to define release content (7.3)
    • Work with PTG (Application Family) to coordinate emergency releases (8.4)
    • Perform Integration Testing (7.2)
    • Launch (up to 3 sites) (7.2)
    • Turnover to AIC if more than 3 sites (7.2)
    • BUSINESS PARTNERS
    • Validate Current and Future Opportunities (2.1, 2.2)
    • Provide Current and Future Needs
    • Provide project team w/ resources (specs, end
    • user documentation) as required (7.3)
    • Perform acceptance testing (7.3)
    • Monitor project performance (4)
    • Fund incremental projects (6)
    • Concur with Service Level Agreement (4.7)
    • Signoff of completed acceptance test (7.2)
    Opportunities Project Resources As Required Progress, Performance Annual Budget Chartering/ Requirement Participation Prioritized Business Functional Requirements Release Schedule Timing, Releases Business Support Questions/ Answers Application Family Engineering AMC (Application System) Interaction
    • PTG (Application Family)
    • Overall implementation planning and management
    • Application launch planning
    • Secures implementation funding
    • Business process reengineering and training
    • AMC (Application System) / Component Engineering
    • Application design and development
    • Application integration testing
    • Pilot as required
    • Develop generic implementation documentation
    • Develop generic site implementation plan (technical)
    • Develop application training materials
    • BUSINESS PARTNERS and ALL
    • LAUNCH SITES
    • Provide current and future opportunities
    • Fund projects
    • Implement reengineered processes
    • Site implementation preparation
    • Implementation support (eg. data conversion)
    • Train balance of users
    • Complete in-site implementation continuation
    • AIC
    • Scheduling and planning
    • Pilot assistance
    • AIC entry gateway
    • Implementation of initial application area:
      • Phase 1: Site Prep
      • Phase 2: Project startup and management
      • Phase 3: Technical installation
      • Phase 4: Training (train-the-trainer)
      • Phase 5: Launch support
      • Phase 6: Signoff
    • Turnover
      • Site application support to AMC (Application System)
      • In-site implementation continuation to site personnel
    Initiatives & Priorities Funding Business Process Reengineering Pilot / Launch Project to Implement Progress, Performance Scheduling and Planning Project Turnover & Feedback Application Family Engineering AIC Interactions Project Planning Application Train-the-Trainer Application Improvement & Management Pilot / Launch Implementation Continuation Turnover
    • PTG (Application Family)
    • Drive current and future opportunities (2.0)
    • Forecast future needs (including PD & Mfg. Cycle Plan) (2, 3)
    • Establish Application and Data Architecture (19)
    • Identify funding alternatives and gain customer
    • agreement for work (6)
    • Drive cost reduction opportunities in TSO
    • Manage customer interface for TSO projects (e.g. pc
    • renewal) (4, 18)
    • Ensure new applications/enhancements adhere to
    • infrastructure standards (7.2, 7.3)
    • Manage Service Level Agreements and gain concurrence
    • from Business Partner (4.7)
    • Oversee Help Desk process and escalation procedure (8.4)
    • TSO
    • Maintain infrastructure master plan
    • Provide cost support for proposals
    • Manage ATAD process to establish standards in support of
    • Application, Development and Data Architectures
    • Maintain infrastructure standards
    • Manage, support and operate computing infrastructure from
    • a total cost basis
      • Networks (LAN/WAN)
      • Servers
      • Corporate helpdesk
    • Manage the installation of infrastructure improvements
      • (including hardware and software upgrades)
    • Ensure new applications adhere to infrastructure standards
    • (gate review process) (7.2, 7.3)
    • BUSINESS PARTNERS
    • Validate Current and Future Opportunities (2.1, 2.2)
    • Fund projects (6)
    • Monitor project performance (4)
    • Concur with Service Level Agreement (4.7)
    Opportunities Program Mgmt. SLA Mgt Application Family Engineering TSO Interaction Perf. Metrics
      • Application registration
      • Architecture review
      • Application certification
      • Production readiness
      • Service Level Agreements
    Architecture Planning Application Registration
    • Component Engineering/AMC (Application System)
    • Design, construct, launch of solutions (7.2, 7.3)
    • Provide 2nd and 3rd level customer support for applications (8.4)
    End user support, Infrastructure Services Funding Infrastructure Planning Architecture Review Application Certification Infrastructure Production Readiness User Application Support
      • Desktops
      • Voice & video
  • The Hi-level Enterprise model divides all BIGCAR Direct processes into three major categories: governing, core and support. Hi-level Enterprise model of BIGCAR Direct concept Hi-level Enterprise model of BIGCAR Direct concept Governing Processes A Core Processes B Support Processes C A.1 Strategic Planning A.2 Customer experience management A.3 Value chain optimisation B.1 Suspecting B.2 Prospecting B.3 Sales/owning B.4 Showcasing B.5 Technical care C.1 People management C.2 Support service C.3 Sourcing & partner management C.4 Business Control B.6 Distribution B.7 Database/ Information management B.8 Interface management Primary focus areas for TSA design and areas of Use Cases
  • The BIGCAR Direct concept consists of a number of constituent roles, responsibilities and processes that jointly support the intended customer-centric business model. Showcase Technical Centre Distribution Centre Customer Suspecting Prospecting Buying Owning East Central Europe Regional Team Mobile Selling Unit Prospector Ownership Consultant other Units Customer Processes Used Car Specialist Market Consultant Contact Centre Diagrammatic overview of BIGCAR Direct concept Backup
  • Use Cases represent important customer-related business scenarios, as they would occur within the BIGCAR Direct concept . Overview of Use Cases defined by BIGCON and verified by BIGCAR Overview of defined BIGCAR Direct Use Cases 1. Provide information on products and services 2. Plan and communicate showcase events 3. Provide leads generated from showcase 4. Plan customer visit 5. Prepare customer visit 6. Provide information to customer 7. Request test drive 8. Cancel test drive 9. Deliver test drive 10. Check availability of new cars 11. Check availiability of used cars 12. Check warranty 13. Prepare non-binding offer 14. Prepare binding offer 15. Trade in used car 16. Place order 17. Monitor oder status 18. Change order 19. Deliver car to customer 20. Request for workshop appointment 21. Cancel workshop appointment 22. Fulfill workshop appointment 23. Arrange emergency repairs (pending) 24. Enquiries relating to „short activity“ 25. Enquiries relating to „normal/extended activity“
  • Most activities within the Use Cases established allude to a specific set of “functional requirements”, that may or may not need to be supported by IT solutions. Establishment of functional requirements from activities in Use Cases Market Consultant Customer Contact center Distribution center Technical center Prospector Ownership Consultant Call back customer Answer Request Not available Routing to Contact Centre Voice Mail Gather data Confirm reservation Confirm delivery Delivery Reservation Not available Request Confirm reservation Info BIGCAR Systems Other Functional requirements of specific activity
    • Retrieve customer data
    • Change customer data
    • Assess customer requirements
    • Manage/control customer request
    Workshop Reservation Customer Data Workshop Mgmt Fleet Mgmt Use Case example* * Refers to one of more than 20+ Use Cases developed
  • Architecture Overview Diagram
    • The Architecture Overview Diagram work product is a schematic diagram that represents the governing ideas and candidate building blocks of an IT system or enterprise architecture. It provides an overview of the main conceptual elements and relationships in an architecture, which frequently include candidate subsystems, components, nodes, connections, data stores, users and external systems.
    • As communication is its main purpose, it is more important for the Architecture Overview Diagram to be simple, brief, clear, and understandable than comprehensive or accurate in all details. Consequently the diagram uses an informal rich picture notation. It typically includes supporting text that explains the main concepts of the architecture.
    • This type of diagram can be produced at differing levels:
      • at the IT system level.
      • at the enterprise-wide level
    • Where alternative architectural solutions are being explored, an Architecture Overview Diagram may be produced for each option to enable various stakeholders to discuss the tradeoffs between the options.
    • At an IT system level, the Architecture Overview Diagram is produced very early in a project (possibly pre-proposal) and influences the initial component model and operational model. It is not intended that design commitments be based on this overview until the (more formal) component model and operational model have been developed and validated.
    • Subsequently, the component model and operational model are the primary models, and the Architecture Overview Diagram is a derivable view, which is revised if there are changes to the main concepts and relationships (though it is not intended to reflect detailed design decisions).
    • At an enterprise level, an Architecture Overview Diagram is often produced as part of an overall IT Strategy. In this instance it is used to describe the vision of the business and IT capabilities required by an organization. It provides an overview of the main conceptual elements and relationships including candidate subsystems, components, nodes, connections, data stores, users, external systems and a definition of the key characteristics and requirements.
    • The Architecture Overview Diagram work product is used to:
      • Communicate to the sponsor and external stakeholders a conceptual understanding of the intended IT system
      • Provide a high-level shared vision of the architecture and scope of the proposed IT system for the development teams
      • Explore and evaluate alternative architectural options
      • Enable early recognition and validation of the implications of the architectural approach
      • Facilitate effective communication between different communities of stakeholders and developers
      • Facilitate orientation for new people who join the project
      • At the enterprise level the diagram additionally helps communicate to the sponsor and all stakeholders an understanding of the overall future directions for the IT environment. This understanding will help management decision making about major strategic IT investment, acquisitions and sourcing.
      • It provides a high-level shared vision of the architecture and scopes of potential future IT systems.
  • . Architecture Overview Diagram of a Banking Call Center
  • In analysing the BIGCAR Direct Use Cases three major functional module categories have been identified, each representing areas of potential IT enablement. Product-related modules Customer-centric modules Administration & Governance modules
    • Order Management
    • Fleet Management
    • Car Configurator
    • Finance and Leasing
    • Warranty
    • Workshop Management
    • Parts Management
    • Customer Data Management
    • Campaign Management
    • Contact/Request Management
    • Proposal Management*
    • Accounting/Billing
    • Event/Calendar Management
    • Management Enterprise System
    Functional requirements Functional module categories in support of BIGCAR Business objectives * includes functionalities for preparing hard/soft offer
  • Chapter 9
    • Applying Business Engineering TO Define Processes And Organization
      • Software engineering processes in the Reuse Business
        • Each of the business use cases is a Software Engineering Process(SEP) and should be supported by tools integrated into a complete software engineering process support environment (SEPSE)
        • ASE - An OOSE S/W engineering process, customized to assemble application systems quickly from component systems – Possible use of JAVA for distributed environment to support portability and flexibility
          • Involves workers such as requirements analysts, architects, designers, and testers
  • The product-related module category covers functionalities pertaining to the vehicle and service components of the BIGCAR Direct concept - of varying business value. Description of the product-related module category Product-related modules Functional module Description of functionalities Business value* 1 Order Management
    • Place, change and cancel order
    • Monitor order status
    2 Fleet Management
    • Place, change and cancel order
    • Monitor order status
    3 Car Configuration
    • Customised Car Configuration
    • Store and retrieve standard configurations
    4 Finance and Leasing
    • Calculate Finance and Leasing options
    • Store and retrieve calculation models
    5 Warranty
    • Enter or modify warranty information
    • Retrieve warranty information
    6 Workshop Management
    • Place, change and cancel workshop capacities
    • Plan, control and forecast operations
    7 Parts Management
    • Retrieve part information
    • Order parts
    * Business Value Contribution, Workshop Brussels 29.10.1999 low high
  • The customer-centric module category covers the generally important CRM functionalities. Customer-centric modules Functional Module Description of functionalities Business Value* 1 Customer Data Management
    • Add, change and retrieve customer data
    • Qualify and assign customer leads
    2 Campaign Management
    • Plan and manage campaigns
    • Create statistics and reports
    3 Contact/Request Management
    • Create, delegate and assign requests
    • Manage and control request status
    4 Proposal Management
    • Create and prepare hard/soft offers
    • Monitor proposals
    Description of the customer-centric module category * Business Value Contribution, Workshop Brussels 29.10.1999 low high
  • The accounting/billing module is the key functional module within the “Administration and governance” category. Administration and governance modules Functional Module Description of functionalities Business Value* 1 Accounting/Billing
    • Prepare and manage invoices
    • Manage and control financial operations
    2 Event/Calendar Management
    • Manage calendar and event operations
    • Add, change and retrieve information
    * Business Value Contribution, Workshop Brussels 29.10.1999 Description of the administration and governance module category low high
  • By mapping what is required versus what is available at present, one finds that a number of IT functionality gaps still exist in the case of Poland. Order Management Fleet Management Car Configuration Finance and Leasing Warranty Workshop Management Parts Management Customer Data Management Campaign Management Contact/Request Management Proposal Management Accounting/Billing Event/Calendar Management General Availability within BIGCAR Comments CIS - - - - - Online Version - - - - - QW 90 - - - - - VIPS, PRICE - - - Media - - Media - - (Media) - - Media - VEGA - - - - - Modules Poland: Mapping of functional modules against available IT solution components CIS - - - QW 90 - VIPS, PRICE - - - - VEGA - Country specific use Other BIGCAR system
  • A number of basic IT principles have been applied in the design of the Technical Solution Architecture for the BIGCAR Direct concept. List of IT principles used Modularity and Layering Extendibility and scalability Allowing for flexibility and a reduction of complexity through the loose coupling of modules and independent layers Ability to be adapt to new requirements and increases in volume (users and data) Reliability Provision of guaranteed availability at all times Standardisation and internationalisation Use of Internet-based products and protocols, while at the same time fulfilling country-specific requirements and needs (language, legal, users, etc.) Legacy integration Ease of use and efficiency Re-use and protection of investments by making use of existing proven and reliable systems Providing for user friendliness and efficiency (Graphical user interface, consistent look and feel, minimised re-typing of data, etc.) Maximum Reuse Reducing lead time, by reusing components as components as building blocks
  • Business model of the Reuse Business ( Roles in Reuse ) a revision of slide 35 this series Application Family Engineering Customer Asks for and PAYS for new systems End user Will use the system Component System Engineering Manufacturer Customizes and installs (Develops overall layered system architecture) (Develops new versions with components) (Develops components for use) Application System Engineering Managing the resuse business Application System Component System
  • Chapter 9 Software engineering processes in the Reuse Business
        • AFE - An OSSE S/W engineering process, customized to develop a layered architecture in terms of a superordinate system, superordinate use cases, interfaces, subsystems, and facades
          • Process captures the requirements from a range of Customers and create a suite of applications
        • CSE - An OOSE S/W process customized to design for variability.
          • Process designs, constructs, and packages components into a component system.
          • Component interface specification implemented mostly using OMG IDL
  • The BIGCAR direct solutions can be divided into three “IT solution layers” or major areas of complexity. 1 3 Integration node to backend systems 2 Local environ- ment 1 Mobile clients Communication Layer IT solution OS/390 AS/400 other Multi-layered view of the IT solution for the BIGCAR Direct concept
  • The interdependence of IT solution layers has significant implications on the Technical Solution Architecture design and increases the complexity of solution design. 2 1 3
    • Local autonomy
    • Local consistency
    • Transparency of location
    • Distributed order processing
    • Adhoc-analysis
    • System reliability
    • Resource constraints
    • Need for the same functionality as mobile client
    • LAN-only application should use same server-side infrastructure as mobile client applications
    • Extendibility of LAN to a WAN environment
    • Standard interfaces
    • Interfaces should be available from wide range of platforms and systems (OS, programming languages.)
    • Minimum degree of new implementations or number of modifications
    • Issue:
    • Client side data replication
    • Thin Client
    • Fat Client
    • Issue:
    • Server-side application
    • Batch interface (batch window)
    • “ Online” access to batch interfaces
    • Biggest challenge lies is in realisation of layer 2:
      • potential bottleneck
      • most interfaces
      • most complex
    • Interfaces and integration platform have impact on business and IT effectiveness as well as efficiency
    • Iterative and modular design approach is advisable
    Major challenges Issues and implications as a result of interdependency Conclusion
    • Implications:
    • Corresponding server side data replication
    • Application-server to serve Thin Client business logic
    • Reduced need for application-server capacity
    • Implications:
    • Implementation of specific Operating System (e.g. NT)
    • Need for “copy” of Database within batch-window mode of processing
    • Online-Connection to backend systems
    Impact on TSA design due to the interdependence of IT solution layers IT layer:
  • An online versus offline mobile computing scenario illustrates the close interrelationships and interdependencies of IT solutions made up of multiple solution layers. online offline 2 1 3
    • HTML client (Thin Client)
    • Wireless access (GSM)
    • Wire access (Phone)
    • Application server for Thin Client applications
    • Web-Server for HTML client
    • Dial-in platform (e.g. CompuServe)
    • Standard message interface (middleware)
    • Need of access to “online” batch interface
    • Fat Client
    • Data replication (client)
    • Data replication (server)
    • Detection of replication conflicts
    • Mobile client should work in LAN without replication
    • Need for a “copy” of Database through batch-window way of operating (in 3)
    • Standard message interface
    • Batch interface (batch window)
    Illustration of interdependencies of multiple IT solution layers OS/ 390 AS/ 400 Backup
  • BIGCON Hypothesis: Three major solution alternatives exist to overcome the challenges posed by mobile computing. Prof Customer Data Cust.
    • Offline access to data
    • Periodic replication or on demand
    • Advantage
      • proven architecture
    • Disadvantage
      • technical complexity
    • Selective storage of data and access to applications
    • Local access in offline mode
    • Access to centrally stored data or applications in online mode
    • Advantage
      • Flexibility
    • Disadvantage
      • Technical risk from online access
    • Central data storage
    • Online access only
    • Uninterrupted access for „thin client“ approach
    • Advantage
      • easy to build
    • Disadvantage
      • high technical risk
      • high business risk
    Client (Prospector) Acquisition (profile) Client (Prospector) Client (Prospector) Customer Contracts Car History Customer Data Acquisition (profile) Customer Contracts Car History Customer Data Acquisition (profile) Customer Contracts Car History Customer Data Acquisition (profile) Customer Contracts Car History Customer Data Server Server Data partly stored locally Data is stored only locally Data is stored centrally A C B 3 2 1 Server Hypothesis relating to the alternatives possible for layer 1 LAN Mobile client asynchronous flow of data Real-time flow of data * (Exemplary for car industry based on insurance industry benchmark)
  • BIGCON Recommendation: The local environment solution needs to cater to both functional and operational IT components - and ensure that the necessary sub-components can be provided for. 3 2 1 Objective to be fulfilled: (1) Support of direct business requirements (2) Provide technical basis for operations (3) Ensure the flow of information through out organisations (4) Distribute and manage software across systems (5) Support for evolution of dynamic information-intensive processes (6) Provide basic IT-infrastructure * Data replication is one of the key infrastructure in feeding and retrieving select information to and from the mobile client. Functional Modules (1) Operational component (2) Communication sub-component (3) System management sub-component (4) Business rule management sub-component (5) Generic infrastructure sub-component (6)
    • Data replication*
    • Mailing
    • Message handling
    • System management tools
    • Software distribution tools
    • Workflow
    • Content management
    • DB-System
    • WWW-Server
    • Office
    • LDAP
    • Workgroup
    • Security
    • Print / fax
    Mobile client Product related Customer centric Administration & Governance BIGCON recommendation on local environment layer Integration node
  • BIGCON Hypothesis and recommendation: There are two basic options relating to the basic integration with backend systems; BIGCAR should opt for a logical function architecture supported by an integration node. Option A Characteristics of option A Logical function architecture based on terminal emulation (Refer to backup for further information)
    • Lower investments due to existing infrastructure (+)
    • Constraints between front- and backend systems (-)
      • maintenance problems
      • domino effect
    • Cumbersome and time-intensive user interaction with systems (-)
    Option B Characteristics of option B Logical function architecture supported by an integration node (Refer to backup for further information)
    • New functionality or pre-configuration (backends) (+)
    • Proper layering (+)
    • IT Best Practices, ito (+)
      • scalability
      • extendibility and expansion possibilities to other channels
    Evaluation 3 2 1 Hypothesis and recommendation related to the design of the integration node to the backend environment Recommendation
    • BIGCAR Direct solution requires a middleware layer
    • DMS should be investigated for potential re-use possibilities:
      • modular
      • complete solution
    • If DMS is not re-used in any way, a system with similar middleware capabilities will need to be created - with high investment costs.
  • Chapter 9
    • Applying Business Engineering TO Define Processes And Organization
      • The Application Family Engineering process controls the facades between the layers, thus fixing the points of interaction between the processes for Application System Engineering
      • The Façade exports component use cases, classes, subsystems, etc.
  • The interaction of workers and entities in the software engineering process of an RSEB See figure 9.3 on page 236 Application systems Engineering Application use case engineer Application sub system engineer Application test engineer Lead architect layered design model facade Application family Engineering Application design model Application use case model Application system Component design model component use case model Component system Component use case engineer Component sub system engineer Component systems Engineering Customer End user Manufacture
  • A middleware layer based on terminal emulation might require less investments in the short term, yet lead to a variety of operational and extendibility handicaps. LAN Terminal emulation Contact Centre Application Distribution Centre Application Technical Centre Application Mobile Selling Unit (stationary) CAS QW90 Price DSP CDB GPSS VIPS VR CIS Sales & Target Mobile Selling Unit (mobile) Logical functional architecture based on terminal emulation Evaluation
    • + Lower investments due to existing infrastructure
    • - Constraints between front- and backend systems
      • maintenance problems
      • domino effect
    • - Cumbersome and time-intensive user interaction with systems
    3 2 1 replication Backup
  • The recommended middleware layer based on DMS would build on an existing infrastructures and organisational foundation with a number of longer term strategic benefits . LAN Communication layer Contact Centre Application Distribution Centre Application Technical Centre Application Mobile Selling Unit (stationary) CAS QW90 Price DSP CDB GPSS VIPS VR CIS Sales & Target replication DMS available components new components Integration Node Logical functional architecture based on DMS or other middleware layers Mobile Selling Unit (mobile) Evaluation
    • + New functionality or pre-
    • configuration
    • + Prope, extendable layering
    • + IT Best Practices, ito
      • scalability
      • extendibility and expansion possibilities to other channels
    • - Higher initial investments
    3 2 1 Backup
  • BIGCON Hypothesis: An “idealized” TSA solution exists that makes provision for functional modules in the respective IT solution layers - as defined by BIGCAR Direct business requirements. * Remote Ownership Consultant ** HQ Ownership Consultant Order Management Fleet Management Car Configurator Finance and Leasing Warranty Workshop Management Parts Management Customer Data Management Campaign Management Contact/Request Management Proposal Management Accounting/Billing Event/Calendar Management Layer 1 X - X X X - - X - X X X X Layer 2 X X - - X X X X X X X X X Layer 3 X - X - X - X - - - - - - Prospector, Ownership Consultant* Market Consultant, Ownership Consultant**, Contact Centre, Distribution Centre, Technical Centre Middleware to existing BIGCAR Backend Systems Modules “ Idealised” TSA solution linking functional modules to IT layers
  • Mapping the functional modules against the defined roles is important for the determination of which functionality needs to be provided for by the respective IT solution layers. Market Consultant Contact Centre Distribution Centre Technical Centre Business Unit Mgr. Prospector Ownership Consultant Order Management Fleet Management - - - - - - X - - X - - - - Car Configurator Finance and Leasing - - - - - X - - - - - - X - Warranty Workshop Management - - - X - - X - - - X - - - Parts Management - - - X - - - Customer Data Management Campaign Management X X - - X X X X - - - X X X Contact/Request Management Proposal Management X X X X X X X - - - - X X X Accounting/Billing Event/Calendar Management - - X X X - X X X X X X X X Modules Modules Mapping of functional modules against defined BIGCAR Direct roles Other roles - - - - - - - - - X - X* X * Accounting and Billing only for other roles concerning business operations Backup
  • BIGCON Hypothesis: The idealised logical architectural high level solution design makes provision for all functional modules and operational components. Integration Node DMS available components New components Communication layer Functional Modules Operational component Order Management Fleet Management Car Configurator Finance and Leasing Warranty Workshop Management Parts Management Customer Data Management Campaign Management Proposal Management Contact/Request Management Communication System management Business rule management Generic infrastructure
    • Data replication
    • Mailing
    • Message handling
    • System management tools
    • Software distribution tools
    • Workflow
    • Content management
    Backend systems Idealised logical architectural high level solution design Mobile client
    • Workgroup
    • Security
    • Print / fax
    • DB-System
    • WWW-Server
    • Office
    • LDAP
    • Workgroup
    • Security
    • Print / Fax
    Accounting/Billing Event/Calendar Management
  • BIGCON Hypothesis: The interdependencies between functional components of the idealised solution. Order Management Fleet Management Car Configuration Finance and Leasing Warranty Workshop Management Parts Management Campaign Management Contact/ Request Management Proposal Management Event/ Calendar Management Customer Data Management Accounting/ Billing
  • The required interfaces between the functional modules within the envisaged BIGCAR Direct TSA. Interfaces between functional modules in TSA Backup
  • Recommendation: The number of potential handovers and “worst case” scenarios need to be analysed closely and the modifications (if any) included in the final process design. Market Consultant Contact center Distribution center Technical center Prospector Ownership Consultant Other Call back to customer Answer Request Not available Routing to Contact Centre Voice Mail Gather Data Workshop Reservation Confirm reservation Confirm delivery Delivery Reservation No Availability Request Confirm reservation Info Use Case example* Example of an use case “workshop appointment” Backup Customer
  • A Layered Design Integration Node DMS available components New components Communication layer Functional Modules Operational component Order Management Fleet Management Car Configurator Finance and Leasing Warranty Workshop Management Parts Management Customer Data Management Campaign Management Proposal Management Contact/Request Management Communication System management Business rule management Generic infrastructure
    • Data replication
    • Mailing
    • Message handling
    • System management tools
    • Software distribution tools
    • Workflow
    • Content management
    Backend systems Mobile client
    • Workgroup
    • Security
    • Print / fax
    • DB-System
    • WWW-Server
    • Office
    • LDAP
    • Workgroup
    • Security
    • Print / Fax
    Accounting/Billing Event/Calendar Management
  • Chapter 9 Applying Business Engineering TO Define Processes And Organization
      • Software engineering processes in the Reuse Business
        • Application Engineers: Assemble and customize into applications, Capture individual Customer demands; etc.
        • Component Engineers: Generalize for reuse and work on architecture, systems, and domain issues; captures requirements from several Customers; Coordinate well with other domain experts; etc.
  • Chapter 9
      • Separate business use cases to allow software engineers to focus on key value added
        • Each S/W engineering team must contain people that together have both sufficient domain and software engineering expertise – Particularly true for AFE where sufficient domain knowledge overlap is highly important
        • The Application Family Engineering use case is responsible for building and improving the layered system
          • AFE business use case separated from CSE business use case – An approach to reuse the overall system architecting, domain analysis, and component engineering combine into one process for the AFE business process.
  • Chapter 9
    • Separate business use cases to allow software engineers to focus on key value added
        • Use of the incremental, iterative approaches to system design and implementation reduce the risk by producing operating designs early and focusing resources on the key features and structure of the evolving system
        • Some reasons for incremental, iterative development
          • Allows some useful subset of functionality to be deployed sooner
          • Reduces risk or makes changes less expensive
          • Improves rapid learning by the workers of the reuse business
          • Etc.
  • Chapter 9
      • Organizing worker into competence units
        • Competence unit consist of worker types
          • Each competence unit has a resource owner staffed by people acting as different types of worker
          • A Resource Owner is responsible for staffing and finding, for training individuals as reuse workers and for solving problems in resource allocation
            • E.g. A Software Engineering Business Manager who is responsible for the reuse business
          • A Process Owner is responsible for the design, improvement, and appropriate configurations of the business process description
  • Chapter 9
    • Applying Business Engineering TO Define Processes And Organization
      • Organizing worker into competence units
        • A Process leader reports toe the Process Owner and is responsible for supervising the execution of an instance of a process . E.g. a Project leader or Project manager
      • Each of these competence units represent a type of skill required in a reuse business
      • Skills include – Requirements engineers, architects, designers, and testers
  • Chapter 9
    • Organizing worker into competence units
        • Workers in each of the competence units
          • Requirements capture unit – Workers required when capturing requirements for the layered system, application, or component system
            • A Use Case Engineer - Specifies the use case and associated user interfaces
            • A GUI Coordinator – Evaluates and suggests the GUI component libraries to use
  • Chapter 9
      • Organizing worker into competence units
        • Design Unit – Workers required when doing robustness analysis, design, and also implementing the layered system, and application, or component system
          • A Subsystem Engineer- Defines he types or classes within an analysis or design subsystem; implements and unit tests interfaces to the design subsystem and also the software inside it
          • A Use Case Designer – Defines a collaboration for a use case; I.e. allocating a use case to analysis and design objects, and to subsystems
  • Chapter 9
      • Organizing worker into competence units
        • Testing Unit – Workers required when testing the layered system, an application, or a component system
          • A Tester – Performs tests above the level of unit testing which includes the testing of use cases, subsystems, the whole system, and selected configurations
        • Component Engineering Unit – Defines additional workers required when developing a component system such as
          • A Reuse Process Engineer
          • A Reuse Support Environment Engineer,
          • A Façade engineer
  • Chapter 9
    • Organizing worker into competence units
        • Architecture Unit- Workers required when defining the architect of the layered system, an application, or a component system such as
          • Architect and Distribution Engineer
        • Component Support Unit- Worker required for packaging and facilitating the reuse of component systems in ways such as maintaining the facades and the distributing the component systems so that the reusers can access the desired component . This units consists of the following workers:
          • Component System Trainer, Component System Supporter, and Component System Librarian
  • Chapter 9
    • Interplay between Reuse Business processes
        • Generally, you develop the application and component systems after the AFE process has developed the superordinate design model
        • The superordinate design model defines the layers, the facades, and the interfaces between application and component systems
        • A simplistic procedure for developing an application or component system follows:
          • Create an application or component for each super ordinate subsystem
          • Capture the requirements for the application or component system
          • Perform robustness analysis and design, implement, and test the system by reusing components
            • See figure 9.12 on page 254. Slide 22 this presentation
  • Monkeys and Corporate Processes
    • Start with a cage containing five monkeys. Inside the cage, hang a banana on a  string and place a set of stairs under it. Before long, a monkey will go to  the  stairs and start to climb towards the banana. As soon as he touches the  stairs, spray all of the other monkeys with cold water. After a while, another monkey makes an attempt with the same result - all the  other monkeys are sprayed with cold water. Pretty soon, when another monkey  tries to climb the stairs, the other monkeys will try to prevent it.
    • Now, put away the cold water. Remove one monkey from the cage and replace it  with a new one.
    • The new monkey sees the banana and wants to climb the stairs.  To his surprise and horror, all of the other monkeys attack him.
    • After another  attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted.
    • Next, remove another of the original five monkeys and replace it with a new  one. The newcomer goes to the stairs and is attacked.
    • The previous newcomer takes part in the punishment with enthusiasm! Likewise, replace a third original monkey with a new one, then a fourth, then  the fifth. Every time the newest monkey takes to the stairs, he is attacked. Most of the monkeys that are beating him have no idea why they were not permitted to climb the stairs or why they are participating in the beating of the newest monkey. After replacing all the original monkeys, none of the remaining monkeys have ever been sprayed with cold water.  Nevertheless, no monkey ever again approaches the stairs to try for the banana.
    • Why not? Because as far as they know that's the way it's always been done around here. And that, my friends, is how company policy begins.