Architecture for Reuse

software reuse processes 1

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


Overall solution constituents of BIGCAR Direct concept and BIGCON`s focus areas

Vision;Concept & Strategy

Rollout plan

Processes

Capabilities

Technologies

Infrastructure

Bu

sin

es

s S

ys

tem

sA

rch

ite

ctu

re

Te

ch

no

log

y S

ys

tem

sA

rch

ite

ctu

re (

TS

A)

BIGCON focus -enablement

BIGCON -peripheral attention

for alignment

BIGCON focus -translation

& congruence

BIG

CO

N p

rim

ary

focu

s

So

luti

on

Arc

hit

ec

ture

BIGCON has been tasked with the design of the Technology Solution Architecture (TSA) for the BIGCAR Direct retailing concept in Eastern Europe.


TSA Design& Roadmapformulation

TSA Design& Roadmapformulation

Today`s session heralds the end of the second phase of an three-phased engagement.

Overview of BIGCON approach - major focus areas or activities

Review &Consolidation

Review &Consolidation

Solution portfolioanalysis &

alternative selection

Solution portfolioanalysis &

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)

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

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

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 BIGCARDirect concept/processesDeliverable: Review of BIGCARDirect concept/processes

Deliverable: Macro Design;validation and selection of feasible solution portfolio(s)

Deliverable: Macro Design;validation and selection of feasible solution portfolio(s)

Deliverable: BIGCAR Direct TSA design (as defined by set constraints)

Deliverable: BIGCAR Direct TSA design (as defined by set constraints)


Challenges in developing TSA for BIGCAR Direct

Challenges in developing TSA for BIGCAR Direct Questions relating to challengesQuestions relating to challenges

Apparent paradox between the diverging objectives of “right-sized” investment as opposed to scalability

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?

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

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?

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

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?

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

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?

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

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?

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

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?

How does one incorporate both elements (whole selling and retailing) within one integrated solution?

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.


BIG

CA

R D

irec

t co

nce

pt

BIG

CA

R D

irec

t co

nce

pt

Operational (IT)

perspective of solution

Operational (IT)

perspective of solution

Mobile clientMobile client

Local environmentLocal environment

Integration nodeIntegration node

Functional perspective of

solution

Functional perspective of

solution

Hyp

othe

sis

Eva

luat

ion

Rec

omm

enda

tion

Ope

ratio

nal

solu

tion

Functio

nal

Solutio

n

1.) Analysis 2.) Modular solution

design

3.) Solutionintegration

4.) Solution“rightsizing”

Step 1

Step 2

Step 3

Inte

grate

d

solu

tion

Diagrammatic representation of four-stepped solution approach - step 1

Step 4

Step 1 -In presenting our solution a structured four-stepped approach has been adopted.

Hi-l

evel

Ent

erpr

ise

Pro

cess

Mod

el

Use

cas

es

Fun

ctio

nal

Req

uire

men

ts

Product relatedProduct related

Customer-centricCustomer-centric

Administration/Governance

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

BusinessSystems

Middleware

SystemSoftware

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 systemsTCP/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 layerSee Figure 7.3 pg 175 in text

ApplicationSystem A

Application system B

Applicationsystem C

Component1

Component 2

Component 3

Component 4

System Dependencies

System interaction


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

Implementation View

Use Case View

Analysts/DesignersStructure

performancescalability

throughput

behavior

system assemblyconfiguration mgmt.

system topologydistributiondeliveryinstallation

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

System ASystem C

System C

<<imports>>

<<system of interoperating systems>>S


Use cases are allocated to design subsystems

<<Superordinate system>>

<<subsystem a>>

CBA

<<subsystem b>> <<subsystem c>>

x

y

z

XaYa

XbYbZa Zb

Yc

Actor 3

Actor 2

Actor 1

Actor 2

Actor 1

Actor 3

<<trace>>


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

BusinessSystems

Middleware

SystemSoftware

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

Application

Application Enablement

Infrastructure


Five high level (level 0) Architecture Building Blocks have been defined and tailored to the specific systems needs of each business group logical location.

System Management services and functions are incorporated within these ABBs

Applications

Logical groupings of business activities for automation. (e.g., Accounting-SEI.)

Data

Logical groupings of data elements that support business applications.

Systems Services

Network

Operational

Commonly used enabling functions required by applications, often provided by the operating system. (e.g., Security Services, File Management Services.)

Logical components that provide connectivity between computing environments. (e.g., Transport Services, Routing Services)

Logical computer processing elements needed to support the execution of business applications and the storage, processing, outputting, and retrieval of information. (e.g., DB Server)

Architecture Building Blocks (ABB's)

Tailored to the systems needs of each business logical location

Define full set of needed I/T components

May come "bundled" with applications or systems (e.g., operating system) software or hardware

May already be available or deployed as part of the company infrastructure

Timing of building block deployment will need to be considered as part of systems development life cycle

May serve as a framework to help in evaluation of package solutions for completeness

Simple Conceptual Model, showing the main, high level ABBs:


- the same Conceptual Model, exploded down to the next level of detail

The level 0 ABBs can be broken down into a larger number of more detailed ABBs. These will be required to satisfy all company computing needs, including support for system construction, operations and maintenance.

ApplicationsSales/Supt. Rel Mgt. Trade Order Entry Management ReportingProduct Def./Customization Trust Accounting Office Automation

Clearing/Settlement Research/Analytics DisbursementsTransaction Mgt.. Tax ProcessingCustomer Assimilation EB Recordkeeping

PeriodicTax Status

Mortgage Custody Fund Accounting EB Recordkeeping dailyConsolidated Positions and Balance

Advantage 401K Recordkeeping

Pension Payments Processing

Serv icing Stock Transfer Customer InquirySplit Payroll Prof itability Analysis Mobile MessagingEB Plan status Tracking Fund Perf . Analysis IT Client Mgt.. SystemConsolidated CIS Statements Model Block Trading

Portf olio Management 440 Corp. Recordkeeping

Bond Tracking

Bond Account Control ECDA

DataExternal Data Performance data Asset DetailFund Banking Relationships Asset SummaryEquity Projection Mortgage Loan EB Plan StatusInvestment Styles EB Accts / Daily / Periodic Trades

Bond Information EB Periodic records Payments / DisbursementsBond Accounts EB Daily records Trust Tax TransactionsInvestment Model Portfolios Advantage 401K Records Cons. Pos. Balances

Bond Payment Funds Bond Status Cons. CustomerStock (CSSII) 440 Corp. records Tax FilingLeads Payroll Documents & FormsProduct Sales Templates Income E-MailFee Schedules Customer Profile Custom Prod. TemplatesApproved List Scheduled Ticklers Proposal / AgreementResearch Notes Trust Accounts Receipts for AssetsBond (Loan) Shells Statements Tax Return Status

System ServicesFile Manager Batch Upload Workflow Manager Real Time Upload GUI Interface Fax ServicesGroupware Print Svcs Electronic Forms Security Services RDBMSE-mail Services Image Services EDI Services Bulletin Board Middleware End User Dev. ToolsS/W Distribution Svcs Transaction Routing Svc Folder Management Voice Date (CTI) Ad-Hoc Reporting Emulation ServicesEvent logging OCR / ICR / Scanning Transaction Processing Backup/ Recovery Svcs Directory Services RDBMS Client(s)

NetworkTransport Services Communications Svcs Dedicated Access Services EN/Access Node Network Protocols Firewall ServicesRouting Services Switched Access I nteractive Voice Response Gateway Svcs Remote Lan Svcs Commercial ServicesNetwork O. S. Front End Processor Network Adapter Wireless Branch Nodal Processor

OperationalTrust Acct. Server FAX Server Perf. Management Svcs Specialized App. Server DB Server DB GatewayRemote LAN server Shared Delivery Env. Voice Response (VRU) Change Management Svcs High Speed Print Environ Mass StorageLAN Print Environment Personal Environ. Config Management

ServicesPersonal Print Environ. Ops. Management Svcs Problem Management Svcss


- sample ABB definition

AC-06 Interface Services

FunctionInterface Services supports the transmission and receipt of transactions to and from the Presentation Services AC and systems external to xxxx. This is done in conformance with agreed protocols. Interface Services has two components; one resides with the shared delivery environment, the other with the individual delivery environment.

Interface Services will not: - understand the individual packet definitions beyond the level of being able to deliver to clients or server; i.e., the data packet received is a black box, and Interface Services will not be capable of any decisions based on the data packet’s format - perform any translations of data to suit the target environment (e.g. ASCII to EBCDIC) as this will be done by the platform-specific layers - assume any specific communication protocols or tool sets - recover transactions by itself, it only invokes the appropriate server subprograms

Relationship with other arcchitecture building blocks

(ABBs that depend on this ABB or upon which this ABB depends)AC_02 Common Business ObjectsAC-03 Common Data ServicesAC-04 Common Application ServicesAC-05 Common System ServicesAC-08 Presentation ServicesAC-10 Technology Interface Protocols

Principles These are in addition to the general architectural principles previously defined.

All defined interface services will support system management functionsData encryption will be implemented where appropriate No data specific operations are performed Platform specific considerations are not included within interface services

Characteristics Description

Key Services - Manage the receipt of transactions sent by other systems, either from within or external to the company; transactions may arrive singularly or in batches (files) via an appropriate network mechanism which must be completely customisable- Manage the sending of transactions to other systems- Support a flexible and efficient means of exchanging data with Presentation Services, existing elements of xxxx, and systems external to xxxx- Support immediate and deferred processing of transactions- Provide initial points of recovery

Users - Application functions- Solution Providers- Design & Build users

Data Characteristics

Must support the data types exchanged between applications and external systems, e.g. text, file transfer, image, voice

Interfaces - Should not impose any restriction on the data exchanged- The Interface Services AC only supports a defined set of protocols

Current Implementation

Current xxxx Service Elements

Planned Implementation

xxxx Service Objects and extension to current xxxx service elements

Transition Considerations

- Need for definition of the Interface Service- Need to re-engineer current Service Elements

AC-06

Architecture Component


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

Hi-level Enterprise model of


Describe how enterprise works Establish different process

priorities and types Serve as functional framework

Describe how enterprise works Establish different process

priorities and types Serve as functional framework

Use Cases (business scenarios)of


Use Cases (business scenarios)of


Functional Requirementsof


Functional Requirementsof


Describe detailed interactions with customers

Describe the distribution of roles and responsibilities

Identify functional needs

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

Translate functional needs into functional modules

Establish business value of functional modules

Identify available functionality

Fu

nct

ion

al p

ersp

ecti

ve o

f so

luti

on


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

CustomerAsks for and PAYS for new

systems

End userWill use the system

Application System Engineering

Component System Engineering

ManufacturerCustomizes 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 ReengineeringProcess ReengineeringOrganizationOrganization

IT OrganizationIT Organization

Fu

nctio

nF

un

ction

Fu

nctio

nF

un

ction

Fu

nctio

nF

un

ction

Fu

nctio

nF

un

ction

TechnicalTechnicalServices OrganizationServices Organization

Process and Process and Technology Group Technology Group (PTG (Application Family) )(PTG (Application Family) )

Solutions Delivery Solutions Delivery GroupGroup

Component SystemsComponent Systems

Component EngineeringComponent Engineering

Present State Future Model

TechnicalTechnicalServices OrganizationServices Organization

PTGPTG


Process LeadershipProcess Leadership



Principles - PTG (Application Family)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)


TS

O

• 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


PTG (Application Family) Integrated Process Model - Level 0PTG (Application Family) Integrated Process Model - Level 0S

olution

s Delivery G

roup

AM

C (A

pp

lication S

ystem) C

omp

onen

t E

ngin

eering A

IC

Leadership and Management

EXTERNAL ENVIRONMENT

Bus

ines

s P

artn

ers


4.0 Manage Business Partner Relationships

9.0 Provide Leadership

Business Partners

Requests BP Plans Proposals Agreement Request forChanges

Business Requirements Disposition

New Needs

Agreement

Solutions

Solutions

Results

Performance Measurements

Proposal

Internal Environment

ExternalEnvironment

Automotive

Industry

StrategicAlliances

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 Sys16.0 Manage Processes17.0 Manage Resources

20.0 Enterprise Management10.0 Manage Human Resources11.0 Manage Finances12.0 Manage Communications13.0 Manage Admin Support

Status Reporting

Industry Trends& Benchmarks

RealizedBenefits

Monitor Progress

AxC

TSO


PTG (Application Family) Integrated Process PTG (Application Family) Integrated Process Model - Level 1Model - Level 1

8.0 Deliver /MaintainSolutions

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 forChanges

Business Requirements Disposition

New Needs

Agreement

Solutions

Solutions

Results

Performance Measurements

Proposal

Internal Environment

ExternalEnvironment

Automotive

Industry

StrategicAlliances

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 Sys16.0 Manage Processes17.0 Manage Resources

20.0 Enterprise Management20.1 Develop/Maintain Enterprise Model

10.0 Manage Human Resources11.0 Manage Finances12.0 Manage Communications13.0 Manage Admin Support

Status Reporting

Industry Trends& Benchmarks

RealizedBenefits

Monitor Progress

AxC

TSO


PTG (Application Family) Integrated Process Model PTG (Application Family) Integrated Process Model - Level 2- 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 Solutions7.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 planStrategic 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-16Eval Ops

Eval

Ops7

20

Cycle

Plan T

ools

& Tec

h.

Define

Solu

tions

Design & Develop Solutions

Define Solutions

Cycle Plan Tools & Tech.

18

9-16

20

7

7 Design & Develop Solutions 9 Provide Leadership10 Manage Human Resources11 Manage Finances12 Manage Communications13 Manage Administrative Support14 Manage Strategic Relationships15 Manage Internal Information Systems16 Manage Processes18 Manage Programs19 Develop Cycle plan and manage App. Arch.20 Enterprise Management

7 9-1619 20

Supp. Arch. Stds


Strategic Planning & PrioritizationStrategic 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.

EscalationProcedure

Defined in AxC Interactions


Business Partner InteractionBusiness 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

CharteringParticipation

Progress,Performance

CapacityPlan

CharteringParticipation/Facilitation

SchedulingProject Submission

Staff Projects

Progress, Performance

PTG (Application Family) and Business Partner Project Resources



Component Engineering Interaction - New ProjectsComponent 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

ProjectResources AsRequired

Progress,Performance

Annual Budget

Chartering/RequirementParticipation

PrioritizedBusiness Functional

Requirements

Release Schedule

Timing,Releases

BusinessSupport Questions/Answers


AMC (Application System) InteractionAMC (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 ALLLAUNCH 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 ProcessReengineering

Pilot /Launch

Project toImplement


Scheduling and Planning

Project Turnover & Feedback


AIC InteractionsAIC Interactions

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


TSO InteractionTSO Interaction

Perf. Metrics

•Application registration •Architecture review•Application certification

•Production readiness•Service Level Agreements

ArchitecturePlanning

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

InfrastructurePlanning

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 conceptHi-level Enterprise model of BIGCAR Direct concept

Governing Processes Governing ProcessesA

Core Processes

Core Processes

B Support Processes

Support ProcessesC

A.1 Strategic Planning

A.2 Customer experience management

A.3 Value chain optimisation

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

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

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 forTSA design and

areas of Use Cases


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

The BIGCAR Direct concept consists of a number of constituent roles, responsibilities and processes that jointly support the intended customer-centric business model.

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

MarketConsultant

Customer

Contactcenter

Distributioncenter

TechnicalcenterProspector Ownership

Consultant

Call back customerAnswer

Request Not available

Routingto Contact

Centre

Voice Mail

Gatherdata

Confirmreservation

Confirmdelivery

DeliveryReservation

Notavailable

Request

ConfirmreservationInfo

BIGCARSystemsOther

Functional requirements of

specific activity

Functional requirements of

specific activity Retrieve customer data Change customer data Assess customer requirements Manage/control customer request

Retrieve customer data Change customer data Assess customer requirements Manage/control customer request

WorkshopReservation

Customer Data

WorkshopMgmt

FleetMgmt

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

Product-relatedmodules

Customer-centricmodules

Customer-centricmodules

Administration &Governance 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 requirementsFunctional 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 modulesProduct-related modules

Functional

module

Functional

module

Description

of functionalities

Description

of functionalities

Business

value*

Business

value*

1 Order Management1 Order Management Place, change and cancel order Monitor order status

Place, change and cancel order Monitor order status

2 Fleet Management2 Fleet Management Place, change and cancel order Monitor order status

Place, change and cancel order Monitor order status

3 Car Configuration3 Car Configuration Customised Car Configuration Store and retrieve standard configurations

Customised Car Configuration Store and retrieve standard configurations

4 Finance and Leasing4 Finance and Leasing Calculate Finance and Leasing options Store and retrieve calculation models

Calculate Finance and Leasing options Store and retrieve calculation models

5 Warranty5 Warranty Enter or modify warranty information Retrieve warranty information

Enter or modify warranty information Retrieve warranty information

6 Workshop Management

6 Workshop Management

Place, change and cancel workshop capacities Plan, control and forecast operations

Place, change and cancel workshop capacities Plan, control and forecast operations

7 Parts Management7 Parts Management Retrieve part information Order parts

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 modulesCustomer-centric modules

Functional

Module

Functional

Module

Description

of functionalities

Description

of functionalities

Business

Value*

Business

Value*

1 Customer Data Management

1 Customer Data Management

Add, change and retrieve customer data Qualify and assign customer leads

Add, change and retrieve customer data Qualify and assign customer leads

2 Campaign Management

2 Campaign Management

Plan and manage campaigns Create statistics and reports

Plan and manage campaigns Create statistics and reports

3 Contact/Request Management

3 Contact/Request Management

Create, delegate and assign requests Manage and control request status

Create, delegate and assign requests Manage and control request status

4 Proposal Management

4 Proposal Management

Create and prepare hard/soft offers Monitor proposals

Create and prepare hard/soft offers Monitor proposals

Description of the customer-centric module category



The accounting/billing module is the key functional module within the “Administration and governance” category.

Administration and governance modulesAdministration and governance modules

Functional

Module

Functional

Module

Description

of functionalities

Description

of functionalities

Business

Value*

Business

Value*

1 Accounting/Billing1 Accounting/Billing Prepare and manage invoices Manage and control financial operations

Prepare and manage invoices Manage and control financial operations

2 Event/Calendar Management

2 Event/Calendar Management

Manage calendar and event operations Add, change and retrieve information

Manage calendar and event operations Add, change and retrieve information


Description of the administration and governance module category


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

Fleet ManagementFleet Management

Car ConfigurationCar Configuration

Finance and LeasingFinance and Leasing

WarrantyWarranty

Workshop ManagementWorkshop Management

Parts ManagementParts Management

Customer Data ManagementCustomer Data Management

Campaign ManagementCampaign Management

Contact/Request ManagementContact/Request Management

Proposal ManagementProposal Management

Accounting/BillingAccounting/Billing

Event/Calendar ManagementEvent/Calendar Management

GeneralAvailability

within BIGCAR

GeneralAvailability

within BIGCARCommentsComments

CISCIS -- --

-- -- --

Online VersionOnline Version -- --

-- -- --

QW 90QW 90 -- --

-- -- --

VIPS, PRICEVIPS, PRICE -- --

-- MediaMedia --

-- MediaMedia --

-- (Media)(Media) --

-- MediaMedia --

VEGAVEGA -- --

-- -- --

ModulesModules

Poland: Mapping of functional modules against available IT solution components

CISCIS

--

--

--

QW 90QW 90

--

VIPS, PRICEVIPS, PRICE

--

--

--

--

VEGAVEGA

--

Country specific useCountry specific use

OtherOtherBIGCAR systemBIGCAR system


List of IT principles used

Modularity andLayering

Modularity andLayering

Extendibility and scalability

Extendibility and scalability

Allowing for flexibility and a reduction of complexity through the loose coupling of modules and independent layersAllowing 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)Ability to be adapt to new requirements and increases in volume (users and data)

ReliabilityReliability Provision of guaranteed availability at all timesProvision of guaranteed availability at all times

Standardisation andinternationalisation

Standardisation andinternationalisation

Use of Internet-based products and protocols, while at the same time fulfilling country-specific requirements and needs (language, legal, users, etc.)Use of Internet-based products and protocols, while at the same time fulfilling country-specific requirements and needs (language, legal, users, etc.)

Legacy integrationLegacy integration

Ease of use andefficiency

Ease of use andefficiency

Re-use and protection of investments by making use of existing proven and reliable systemsRe-use and protection of investments by making use of existing proven and reliable systems

Providing for user friendliness and efficiency (Graphical user interface, consistentlook and feel, minimised re-typing of data, etc.)Providing for user friendliness and efficiency (Graphical user interface, consistentlook and feel, minimised re-typing of data, etc.)

A number of basic IT principles have been applied in the design of the Technical Solution Architecture for the BIGCAR Direct concept.

Maximum ReuseMaximum Reuse Reducing lead time, by reusing components as components as building blocksReducing 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


CustomerAsks for and PAYS for

new systems

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

ApplicationSystem

ComponentSystem

Managing the resuse business


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


1

3

Inte

gratio

n

node to

backe

nd

syst

ems

2

Local

envi

ron-

men

t

1M

obile

clie

nts

Communication Layer

IT solution

The BIGCAR direct solutions can be divided into three “IT solution layers” or major areas of complexity.

OS/390 AS/400 other

Multi-layered view of the IT solution for the BIGCAR Direct concept


22

11

33

Local autonomy Local consistency Transparency of location Distributed order processing Adhoc-analysis System reliability Resource constraints

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

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

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: Client side data

replication Thin Client Fat Client

Issue: Server-side application Batch interface (batch

window) “Online” access to

batch interfaces

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

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

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

The interdependence of IT solution layers has significant implications on the Technical Solution Architecture design and increases the complexity of solution design.

Impact on TSA design due to the interdependence of IT solution layers

IT layer:


onlineonline offlineoffline

22

11

33

OS/390

AS/400

HTML client (Thin Client) Wireless access (GSM) Wire access (Phone)

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)

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

Standard message interface (middleware)

Need of access to “online” batch interface

Fat Client Data replication (client)

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)

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)

Standard message interface Batch interface (batch window)

Backup

An online versus offline mobile computing scenario illustrates the close interrelationships and interdependencies of IT solutions made up of multiple solution layers.

Illustration of interdependencies of multiple IT solution layers


ProfProf CustomerData

CustomerDataCust.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)Client (Prospector)

Acquisition(profile)


Client (Prospector)Client (Prospector) Client (Prospector)Client (Prospector)

CustomerContractsCustomerContracts

CarHistory

CarHistory

CustomerData

CustomerData




CarHistory

CarHistory

CustomerData

CustomerData




CarHistory

CarHistory

CustomerData

CustomerData




CarHistory

CarHistory

CustomerData

CustomerData

ServerServer ServerServer

Data partly stored locally

Data is stored only locally

Data is stored centrally

AA CCBB

3

2

1

LAN

Mobile client

BIGCON Hypothesis:Three major solution alternatives exist to overcome the challenges posed by mobile computing.

ServerServer

asynchronous flow of data Real-time flow of data * (Exemplary for car industry based on insurance industry benchmark)asynchronous flow of data Real-time flow of data * (Exemplary for car industry based on insurance industry benchmark)

Hypothesis relating to the alternatives possible for layer 1


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 informationthrough 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)Functional Modules (1) Operational component (2)Operational component (2)

Communication sub-component (3)Communication sub-component (3)

Systemmanagementsub-component (4)

Systemmanagementsub-component (4)

Business rulemanagementsub-component (5)

Business rulemanagementsub-component (5)

Genericinfrastructuresub-component (6)

Genericinfrastructuresub-component (6)

Data replication* Mailing Message handling

Data replication* Mailing Message handling

System management tools Software distribution tools


Workflow Content management


Integration nodeIntegration node

DB-System WWW-Server Office LDAP


Workgroup Security Print / fax


Product relatedProduct related

Customer centricCustomer centric

Administration&

Governance

Administration&

Governance

BIGCON recommendation on local environment layer


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 AOption A Characteristics of option ACharacteristics of option A

Logical function architecture based on terminal emulation

(Refer to backup for further information)

Logical function architecture based on terminal emulation


Lower investments due to existing infrastructure

(+) Constraints between front-

and backend systems

(-) maintenance problems domino effect

Cumbersome and time-intensive user interaction with systems

(-)

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 BOption B Characteristics of option BCharacteristics of option B

Logical function architecture supported by an integration node


Logical function architecture supported by an integration node


New functionality or pre-configuration (backends)

(+) Proper layering

(+) IT Best Practices, ito

(+) scalability extendibility and expansion

possibilities to other channels

New functionality or pre-configuration (backends)

(+) Proper layering

(+) IT Best Practices, ito

(+) scalability extendibility and expansion

possibilities to other channels

Eva

luat

ion

RecommendationRecommendation

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.

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.

3

2

1

Hypothesis and recommendation related to the design of the integration node to the backend environment


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

Customer

End user

Manufacture

Application systems EngineeringApplication 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 Componen

t use case engineer

Component sub

system engineer

Component systems Engineering


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.

LANLAN

Terminal emulation

Contact Centre Application

Distribution Centre

Application

Technical Centre

Application

Mobile Selling Unit

(stationary)

CASCAS

QW90 Price DSP CDB

GPSS VIPS VR CIS Sales & Target

Mobile Selling Unit (mobile)


Logical functional architecture based on terminal emulation

EvaluationEvaluation

+ Lower investments due to existing infrastructure

- Constraints between front- and backend systems

maintenance problems domino effect

- Cumbersome and time-intensive user interaction with systems

+ Lower investments due to existing infrastructure

- Constraints between front- and backend systems

maintenance problems domino effect

- Cumbersome and time-intensive user interaction with systems

Backup

3

2

1

replication


The recommended middleware layer based on DMS would build on an existing infrastructures and organisational foundation with a number of longer term strategic benefits.

LANLAN

Communication layer

Contact Centre Application

Distribution Centre

Application

Technical Centre

Application

Mobile Selling Unit

(stationary)

CASCAS

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



EvaluationEvaluation

+ New functionality or pre- configuration + Prope, extendable layering+ IT Best Practices, ito

scalability extendibility and expansion

possibilities to other channels- Higher initial investments

+ 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



Car ConfiguratorCar Configurator


WarrantyWarranty


Parts ManagementParts Management







Layer 1Layer 1

XX

--

XX

XX

XX

--

--

XX

--

XX

XX

XX

XX

Layer 2Layer 2

XX

XX

--

--

XX

XX

XX

XX

XX

XX

XX

XX

XX

Layer 3Layer 3

XX

--

XX

--

XX

--

XX

--

--

--

--

--

--

Prospector, Ownership Consultant*Prospector, Ownership Consultant*Market Consultant, Ownership Consultant**, Contact Centre, Distribution Centre, Technical Centre

Market Consultant, Ownership Consultant**, Contact Centre, Distribution Centre, Technical Centre

Middleware to existingBIGCAR Backend SystemsMiddleware to existingBIGCAR Backend Systems

ModulesModules

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

MarketConsultant

MarketConsultant

ContactCentre

ContactCentre

DistributionCentre

DistributionCentre

TechnicalCentre

TechnicalCentre

BusinessUnit Mgr.BusinessUnit Mgr.ProspectorProspector Ownership

ConsultantOwnershipConsultant



-- -- -- -- ---- XX

-- -- XX -- ---- --

Car ConfiguratorCar Configurator


-- -- -- -- --XX --

-- -- -- -- --XX --

WarrantyWarranty


-- -- -- XX ---- XX

-- -- -- XX ---- --

Parts ManagementParts Management -- -- -- XX ---- --



XX XX -- -- XXXX XX

XX -- -- -- XXXX XX



XX XX XX XX XXXX XX

-- -- -- -- XXXX XX



-- -- XX XX XX-- XX

XX XX XX XX XXXX XX

ModulesModulesModulesModules

Mapping of functional modules against defined BIGCAR Direct roles

Other roles

Other roles

--

--

--

--

--

--

--

--

--

XX

--

X*X*

XX

* 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 NodeIntegration Node

DMS available componentsDMS available components New componentsNew components

Communication layerCommunication layer


Functional ModulesFunctional Modules Operational componentOperational component

Order ManagementOrder Management Fleet ManagementFleet Management

Car ConfiguratorCar Configurator Finance and LeasingFinance and Leasing

WarrantyWarranty Workshop ManagementWorkshop Management

Parts ManagementParts Management Customer Data ManagementCustomer Data Management



Contact/Request Management


CommunicationCommunication

System managementSystem management

Business rule managementBusiness rule management

Generic infrastructureGeneric infrastructure

Data replication Mailing Message handling






Backend systemsBackend systems




Workgroup Security Print / Fax

Accounting/BillingAccounting/Billing Event/Calendar ManagementEvent/Calendar Management

Idealised logical architectural high level solution design


BIGCON Hypothesis:The interdependencies between functional components of the idealised solution.

OrderManagement

OrderManagement

Fleet Management

Fleet Management

Car Configuration

Car Configuration

Financeand

Leasing

Financeand

LeasingWarrantyWarranty Workshop

ManagementWorkshop

Management

PartsManagement

PartsManagement

CampaignManagement

CampaignManagement

Contact/Request

Management

Contact/Request

Management

ProposalManagement

ProposalManagement

Event/Calendar

Management

Event/Calendar

Management

CustomerData

Management

CustomerData

Management

Accounting/Billing

Accounting/Billing


Order Management

Fleet Management

Car Configurator

Finance and Leasing

WarrantyWorkshop

ManagementParts

Management

Customer Data

Management

Campaign Management

Contact/ Request

Management

Proposal Management

Accounting/ Billing

Event Calendar

Management

Order Management X X X

Fleet Management X X X

Car Configurator X X X

Finance and Leasing X X X X

Warranty

Workshop Management

X

Parts Management

Customer Data Management

X X X X X X X X X

Campaign Management

X


X X

Proposal Management

X X X X

Accounting/Billing X X X X X

Event Calendar Management

X

Order Management

Fleet Management

Car Configurator

Finance and Leasing

WarrantyWorkshop

ManagementParts

Management

Customer Data

Management

Campaign Management

Contact/ Request

Management

Proposal Management

Accounting/ Billing

Event Calendar

Management

Order Management X X X

Fleet Management X X X

Car Configurator X X X

Finance and Leasing X X X X

Warranty

Workshop Management

X

Parts Management

Customer Data Management

X X X X X X X X X

Campaign Management

X


X X

Proposal Management

X X X X

Accounting/Billing X X X X X

Event Calendar Management

X

BackupInterfaces between functional modules in TSA

The required interfaces between the functional modules within the envisaged BIGCAR Direct 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.

MarketConsultant

Customer

Contactcenter

Distributioncenter

TechnicalcenterProspector Ownership

Consultant Other

Call back to customerAnswer

RequestNot

available

Routingto Contact

Centre

Voice Mail

GatherData

WorkshopReservation

Confirmreservation

Confirmdelivery

DeliveryReservation

NoAvailability

Request

ConfirmreservationInfo

Use Case

example*

Example of an use case “workshop appointment”


A Layered Design

Integration NodeIntegration Node

DMS available componentsDMS available components New componentsNew components

Communication layerCommunication layer


Functional ModulesFunctional Modules Operational componentOperational component

Order ManagementOrder Management Fleet ManagementFleet Management

Car ConfiguratorCar Configurator Finance and LeasingFinance and Leasing

WarrantyWarranty Workshop ManagementWorkshop Management

Parts ManagementParts Management Customer Data ManagementCustomer Data Management





CommunicationCommunication

System managementSystem management

Business rule managementBusiness rule management

Generic infrastructureGeneric infrastructure







Backend systemsBackend systems




Workgroup Security Print / Fax

Accounting/BillingAccounting/Billing Event/Calendar ManagementEvent/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.

Architecture for Reuse

Business

Transcript of Architecture for Reuse