Software Engineering

Session 5 Main Theme

High-Level Analysis and Design
Dr. Jean-Claude Franchitti
New York University
Computer Science Department
Courant Institute of Mathematical Sciences

Agenda
1

Introduction

High-Level Analysis and Design

Architecture Blueprinting

Sample Architecture Blueprints

Architectural Mapping Process Illustrated

Reference Architecture Cataloguing Framework

Summary and Conclusion

What is the class about?

Course description and syllabus:

http://www.nyu.edu/classes/jcf/g22.2440-001/
http://www.cs.nyu.edu/courses/spring16/G22.2440-001/

Textbooks:
Software Engineering: A Practitioners Approach
Roger S. Pressman
McGraw-Hill Higher International
ISBN-10: 0078022126, ISBN-13: 978-0078022128, 8th Edition (01/23/14)
Recommended:
Code Complete: A Practical Handbook of Software Construction, 2nd Edition
The Mythical Man-Month: Essays on Software Engineering, 2nd Edition

High-Level Analysis and Design in Brief

High-Level Analysis and Design Processes
Architecture Blueprinting
Sample Architecture Blueprints
Architectural Mapping Processes
Reference Architecture Cataloguing Framework
Summary and Conclusion
Readings
Individual Assignment #1 (due)
Individual Assignment #2 (assigned)
Team Assignment #1 (ongoing)

Course Project (ongoing)

Icons / Metaphors

Information
Common Realization

Knowledge/Competency Pattern
Governance

Alignment
Solution Approach
55

Agenda
1

Introduction

High-Level Analysis and Design

Architecture Blueprinting

Sample Architecture Blueprints

Architectural Mapping Process Illustrated

Reference Architecture Cataloguing Framework

Summary and Conclusion

High-Level Analysis and Design

The goal of high-level analysis and design is to quickly produce a
high-level model that reflects the current understanding of the
future state architecture
This high-level model is helpful in putting together high-level
program/project estimate and providing a view of the future state
that can be used as a starting point
Various architecture models may be used to represent this view and
they are typically based on blueprinting notations/process and
blueprints that have been standardized within the Enterprise
working on the high-level analysis and design
There are currently no industry standard blueprinting
notation/process and/or blueprints; the blueprinting process typically
goes top down to document the various facets of the future state
architecture starting from the Enterprise level and going through the
business, and technology architectures
Technology architecture blueprinting can be conducted in parallel at
the application, data, and technical levels
7

Architecture Models
An Architecture provides the organizing logic for
mapping business onto IT capabilities
Creating models to describe an Architecture is a complex
exercise as various levels of abstractions may need to
be considered to effectively cover all requirements in
increasing levels of detail
Architecture Models are typically based on an integration
of existing reference architecture styles
e.g., OMA and SOA, SOA and BPM, etc.

Reference Architecture
A Reference Architecture consists of foundational principles, an
organizing framework, a comprehensive and consistent method,
and a set of governing processes and structures.
Principles provide the foundation upon
Reference Architecture
Principles
Framework

Method
Plan

Business
Information

Process

People

Application

Technical

Deliver

Operate

Governance

which the Reference Architecture is

based. It includes a set of architectural
terms as well as numerous principles,
policies, and guidelines for governing
the architecture.

Framework is the organizing basis for

the Reference Architecture and defines
the architectural domains and
disciplines that enable separation of
concerns and IT to business alignment.

Method is the comprehensive set of

defined repeatable processes that are
followed for a consistent and controlled
realization of the Reference
Architecture.

Governance is the set processes and

organizational structures that ensure
conformity to the Reference
Architecture.
9

Sample Application Server Reference Architecture

10

Reference Architecture Models

A reference architecture model is an accepted
representation of the architecture that drives the
mapping of business capabilities onto IT capabilities
A reference architecture model may not represent any
specific organization needs
A reference architecture model is rarely developed using
a top-down or bottom-up approach, it is typically put
together by integrating requirements from various
architectural domains according to accepted heuristics
(e.g., reuse via unification or best practices /
standardization) and using accepted frameworks

11

Enterprise Architecture Modeling Heuristics

Business process integration

High Coordination
Shared customers / products / product data /
suppliers
Operationally autonomous and unique business
units
Transactions impact other business units

Shared
customers

Shared data

Integrating
technology

Linked
processes

Diversification
Few, if any, shared customers or suppliers
Operationally autonomous and unique business
units
Independent transactions

Low
Required

Unification
Customers and suppliers may be local or global
Business units with similar or overlapping
operations
Globally integrated business processes supported
by Enterprise systems

Key
customers

Linked and
standard
(core)
processes

Shared
data

Linking and
automating
technologies

Replication
Few, if any, shared customers
Operationally similar business units
Independent transactions aggregated at a higher
level
Autonomous business units with limited discretion
over processes

Business process
standardization

High
Optional

12

Typical Architecture Asset Catalog and Architecture Mapping Process

Architects working at the Enterprise, Portfolio, and
System levels use different models to represent their
own views of a given architecture
Architecture Domain
Architecture
Scope

Business
Architecture

Data
Architecture

Application
Architecture

Technical
Architecture

Level of
Abstraction
Presentation

Enterprise

Conceptual
Portfolio /
Domain

Logical
Physical

System
(Project)

An Architecture Asset Catalog enables the

representation of stakeholder views in matrix form to
help catalog such models
13

What is the Level of Abstraction?

The level of abstraction refers to how far a blueprint is removed from
practical considerations such as application servers, programming
languages, DBMS technology, etc
Although the levels of abstraction vary by architecture domain, four
different types levels are recognized:
> Presentation - a stylized model intended to greatly simply an architecture so that
key messages can be effectively communicated, typically to business leadership
> Presentation level diagrams are generally created by summarizing lower level
architecture diagrams.

> Conceptual - a highly generalized yet more formal depiction of an architecture

that suppresses much of the actual detail -- either because the details are not
important to the model and/or they had not been decided at the time the diagram
was created
> Logical - a detailed representation of an architecture that is generally
independent of the underlying technology that is used (or will be) used to
implement an architecture.
> Physical -A representation that is typically dependent on the underlying
technology that will be (or is) used to implement an architecture.
14

Sample Architecture and Solution Engineering Asset Catalog

In this context, relevant views are those that match the phases of an
solution development life cycle
Enterprise Perspectives
Application

Technology

Product

Implementation Analysis/Design

Information

Deployment

Architecture and Solution Engineering Views

Business

15

Conceptual business architecture framework

Value Chain

Sales and
Marketing

Product
Development

Underw riting

Finance and Accounting

Claim
Processing

Servicing

Business
Capabilities
Business
Users

Bond
Agents/
Business B2B Partners Customers Public
Users

Bond
Business
Users

Bond
Agents/
Business B2B Partners
Users

Bond
Agents/
Business B2B Partners
Users

$
$

Bond
Agents/
Business B2B Partners Customers
Users

Bond
Agents/
Business B2B Partners Customers Public
Users

Business
Events
Business
Channels
BPM
Processes
Process
metrics

BRM
Rules
Business
Services
Business
Entities

Surety

Management Liability

Enterprise

Claims

Business Unit

16

Conceptual Business Architecture Framework Illustration

Underwriting

Value Chain

Business
Capabiliti
es
Business
Users

Agents/
B2B Partners

Agents/
B2B Partners

Business
Events

Product
Selection

Submission

Rate Quote*

Bind

Bill and Issue

Submission UI

Agent Portal

Bind UI

eDoc delivery UI

Business
Channels
BPM
Processe
s
Process
metrics

Fulfillment

New Business

Product browser UI

Agents/
B2B Partners

Agents/
B2B Partners

Underwriting via agent self service and Straight Through Processing

# of Products
selected by agents

Submission counts
by agents/products

BRM
Rules

Product category,
Related product
rules

Submission
validation
Form selection

Business
Services

Product selector,
Product info
publisher

Business
Entities

Agent profile,
Product catalogue

Count of ratings
delivered
Count of exceptions

Count of
successful bids

Number of policies
issued

Rating

Binding

Billing,
Delivery routing

Submission data capture

Questionnaire builder
Form selector

Rating service
Quote publisher

Binding service
Electronic
signature capture

ePOA
Billing configuration
Delivery manager

Form templates,
Form metadata,
Submission data

Ratable data, Rating

decision, Rates,
Quotes

Binding data,
Policy data

Policy/Bond data,
Power of Attorney
data, Billing data

17

Agenda
1

Introduction

High-Level Analysis and Design

Architecture Blueprinting

Sample Architecture Blueprints

Architectural Mapping Process Illustrated

Reference Architecture Cataloguing Framework

Summary and Conclusion

18

What is Blueprinting?

Blueprinting is fundamentally concerned with the

high-level representation of intangible assets
(e.g., applications, databases, interfaces,
networks, servers, etc.) so that:
The interrelationship between the various assets can
be understood
The assets may be changed more reliably
Architectural level design decisions become
observable

19

What is a Blueprint?

A blueprint is an architectural drawing

Created using a consistent representation to
represent a high-level model of the as-it, to-be, or intransition IT environment

Unlike UML models, which are software

engineering level diagrams, blueprints are at an
architectural-level of detail and provide the
context needed to visualize the big picture
As such, blueprints are analogous to the cityplanning level in the building construction industry
They enable architects to communicate the overall
design of the city as opposed to the design of the
individual buildings that make up the city
20

What Does a Blueprint Look Like and How is it Used?

The appearance of a blueprint varies considerably

depending upon a number of factors including:
The architectural domain being modeled (e.g., application
architecture versus technical architecture)
The scope of the blueprint (e.g., Enterprise, Portfolio, Project)
The level of abstraction (e.g., Presentation, Conceptual, Logical,
Physical)
The communication objectives of the model
Blueprints are also used to document and define three different
states of technology evolution
A current state called the As-Is or POD
A future state called the To-Be or POA (typically 12 - 24 months
out)
One or more transition states, each one called a Transition or
planned landing point between the as-is and to-be state
Once implemented, a Transition represents a new As-Is state
21

Why is there a Need for a Common Way to Document Architectures?

In the absence of standardized blueprinting techniques, architectural
models would be highly individualized and would range from
artifacts that may be fairly structured to models that would be very
general and stylistic
As a result, the readers interpreting the models would be required to
ask (and assume an answer to) a number of critical questions
including:
What concepts is the model attempting to explain?
Are the concepts highly abstract or is the model depicting a precise design?
What do the symbols on the diagram represent?
What architecture domain is being modeled?
Does the design apply to the Enterprise as a whole, a LOB, a portfolio, or a
project?
Does the model represent the As-Is , To-Be, or Transition architecture?
If the model represents a Transition architecture, what changes to the IT
environment are being planned?
etc.
22

Blueprinting and UML at a Glance

Blueprinting and UML are intended to be used together on the same project
Blueprint artifacts are used to document the end-to-end high-level designs
for projects
Blueprints are analogous to the city-planning level in the building construction industry
They enable architects to communicate the overall design of a city (project) as opposed to
the design of the individual buildings (applications) that make up the city

UML artifacts are used for software engineering tasks (e.g., architecting the
buildings)
UML

Blueprinting

Focus

Software development

Application integration

Use

Analyze and design software systems

and modules, typically using an OO
approach

Describe or prescribe an end-toend design without delving into

details

Level of detail

High to low-level

High-level

Central Element of
Granularity

A system and its subsystems

System of systems

Learning Curve

Significant

Minimal
23

Lack of Blueprinting Standards

According to Research Analysts and

reports
Modeling at the Enterprise and Portfolio levels tends
to be fairly generalized
The goal at these levels is to communicate the big picture
(as opposed to application-level designs)

UML is an OO modeling system with schematics and

notations for application development (e.g., "buildinglevel" designs)
It is not well suited for modeling portfolio and Enterprise level
architectures (e.g., the "city-level" or big picture designs)

There may never be industry standards at the

Enterprise and Portfolio levels
24

Legend Box
Sample Legend Box
Architecture Domain:
Blueprint Type:
State:
Revision Date:
Revised By:
Approved By:

Application
Info Flow Diagram
As-Is
06/14/09
John Doe Architect
Jane Doe Architect

Scope: Project
Abstraction: Logical
Status: Working Draft

The Legend Box is a text box that must appear on all blueprints. It
is used to denote important information that is needed by the reader
to correctly interpret a blueprint. The following information is
included in the Legend Box:

Architecture Domain - Used to specify what aspect of the environment is the

subject of architecture artifact - One of the following domains must be specified:

Business Architecture specify this when the model depicts the companys business
capabilities, business processes, organizational structure, major locations, or relationships
with partners and customers
Application Architecture specify this when the model depicts the application assets that
support business capabilities and processes
Data Architecture specify this when the model depicts the companys business rules,
business data and/or information types, along with their interrelationships
Technical Architecture specify this when the model depicts hardware and facilities, system
software, data storage resources, networks, and other underlying technologies

Technical architecture provide the platform that supports the activities and interfaces of the other
domains
25

Legend Box (continued)

Scope - Defines the breath (or scope of authority) for a blueprint. Several different
scopes are recognized:

Enterprise - A model that generally depicts a companys environment as a whole

Portfolio - A model that depicts the architecture of a portfolio (e.g., Field Management)
Program/Project A model that depicts the architecture of a program or project
Asset - A diagram that depicts the architecture of an asset

Abstraction - Refers to how far the model is removed from practical considerations
such as application servers, programming languages, etc
Four different levels are recognized: Presentation, Conceptual, Logical and Physical

State Used to answer the question: Does this model represent the current state or
some proposed future state? Three different states are typically recognized:
As-is - the current state.
To-be - the desired future state that is to be achieved in a specified time period (typically 12
24 months). In reality, the to-be state is a moving target that generally represents an
aspiration, as opposed to a fixed target that will be achieved
Transition - a planned landing point between the current state and the to-be state

A Transition diagram shows progress towards the future state

Once implemented, a transition architecture represents the new As-Is and the previous current As-Is
becomes the As-Was

26

Importance of the Scope of a Blueprint

Specifying the scope of a diagram is critical because there is a direct correlation
between the scope and the amount of detail that can be depicted on a blueprint. The
reason is that the amount of generalization (e.g., simplification, feature selection,
grouping, etc.) must increase with the scope of the blueprint. The following
examples illustrate this key point:
Blueprints

Lots

Application Architecture
App Portfolio A
App Portfolio B

Scope =
Enterprise

App Portfolio C

As-Is Application Architecture for App Port C

App
D

Daily
Extract

App
A

Tran
DB

App
B

XYZ
Com
p

Scope =
Portfolio

As-is Application Architecture for App D

Daily
Extract

Pgm 1

Scope =
System/Project

Degree of Generalization / information hiding

Map Analogy
Scope =
United
States

Scope =
State of
Minnesota

Scope = City
of
Minneapolis

As-is Application Architecture for Pgm 1

Scope =
Subsystem/
program

Little

Scope =
Downtown
Minneapolis
27

Agenda
1

Introduction

High-Level Analysis and Design

Architecture Blueprinting

Sample Architecture Blueprints

Architectural Mapping Process Illustrated

Reference Architecture Cataloguing Framework

Summary and Conclusion

28

Sample Enterprise Architecture Blueprint for Unification Operating Model

29

Sample Enterprise Architecture Blueprint for Diversification Oper. Model

30

Sample Enterprise Architecture Blueprint for Coordination Oper. Model

31

Sample Enterprise Architecture Blueprint for Replication Operating Model

32

Sample Reference Enterprise Architecture Blueprint

Participants

Infrastructure
Prospect

Contract Holder

Financial Professional

Employ ee

Firm

Clearinghouse

Middleware

Interaction Medium
Forms

View

Browser

Contract
Holder

Email

Financial
Prof essional

Phone PDA

Serv ice

Electronic
Business
Gatew ay

Text Message

Sales

Other

Interaction
Serv ices

Process
Serv ices

Transaction
Serv ices

Inf ormation
Serv ices

Processes
Spousal
Continuance

Death

Programmed
Reallocation

Remittance

Software
Vendors

Valuation
Security Services

Functional
Components

IT

Integration
Serv ices
New Business
Form Based

Services

Sourcing

Process
Serv ices

Get Book

Get Last Touch

Atomic Services

Check Appoint

Management Serv ices

Application
Software
Providers

Composite Services
Get FP Detail

Contract Setup

Mov e Money

Technical Serv ices

Virtualization Services

Rules
Party

Product

Contract

Activ ities

Commissions

Other

Build

Test

Prod

Business
Process
Outsource

Nav igation

Process

Support
Components
Data

Knowledge

Document

General
Ledger

Reporting

Transactional
Party
Activ ities

Human
Resources

Product

Hardware

Authorization

Other

Operational
Product

Contract

Commission Documents

L&A

Data Warehouse

Other

Data Marts

Reporting
and
Analysis

Client

Serv er

Network

33

Sample Detailed Level Business Architecture Blueprint

Client and
Channel Mgmt

Risk and
Financial Mgmt

Product
Pr oduct Por tfolio
Planning

Mar ket
Resear ch

Pr oduct
Conceptualization

Pr oduct Per for mance

and Pr icing

Mar ket
Segmentation

Pr oduct Definition
and Design
Regulator y
Filing

Channel
Management

Pr oduct
Deployment

Risk
Management

Investment
Management

Regulator y and
Compliance

Sales
Pr omotion and
Br and Mgmt

Contr actholder
Relationship Mgmt

Sales Gener ation

and Enablement
Sales
Compensation

Fir m
Relationship Mgmt

Legal
Licensing and
Appointments

Commissions

FP
Relationship Mgmt

Campaign
Management

Financial Risk
Management

Suitability

Financial
Management
Financial Repor ting
and Metr ics

Service

Client
Pr ofile

Contr act
Setup

Money-In

Contact NonFinancial Ser vicing

Contr act
Financial Ser vicing

Reallocations

Mer ger s and

Acquisitions

Asset
Retention

Annuitization

Payments

V aluation

Cor r espondence
Management

V alue Added
Ser vices

Business
Continuity

Business Management and Support

Communications
and Public Relations
Secur ity and
Pr ivacy

Human
Resour ces

Infor mation
Technology

Accounting
Tr aining and
Knowledge Mgmt

Auditing

Pr ocur ement and

V endor Mgmt
Analytics and
Repor ting

Document and
Content Mgmt

Facilities
Management

34

Client Focus

Product

Sales

Risk and
Financial Mgmt

(Client and Channel Mgmt)

Sample High-Level Business Architecture Blueprint

Service

Business Management and Support

(Information Technology, etc.)

35

Conceptual Technology Architecture Blueprint

36

Sample Application Architecture Blueprint

Views

Forms

Contract
Holder

New Business
Form based

Financial
Professional

Death

Browser

Contract Holder

Business
Services
Process
Serv ices
Get Contract
Get FP Detail

Email

Spousal
Continuance

Party

Product

Product

Contract

Contract Setup
Check Appoint.

Sales

Data

Party

Get Last Touch

Service

Financial
Professional
Phone PDA

Components
External

Media

Serv ices

Custom

Processes

Existing Assets

Prospect

I nteraction

Package

Participants

Contract
Activ ities

Remittance
Other Services

Employee

Activ ities
Text
Message

Other
Views

Programmed
Reallocation

Firm

Electronic Business
Gatew ay

Valuation

Commissions

Atomic
Serv ices

Commissions

Composite
Serv ices

Other
Components

Clearinghouse

Other
Stores

Rules
I ntegration (Application Bus)

Navigation

Process

Vendor / Partner
Systems

Security
Serv ices

Session
Management

Technical
Serv ices

Ev ent
Management

Connection
Management

Product
Security

37

Sample Information Systems Architecture Blueprint

Transactional
Data Stores

Operational
Data Store

Data
W arehouse

Data
Marts

Reporting
and Analysis

Operational
Reports

Business Unit Data Stores

Accounting

Activities

Commissions

Contr act

Activities

Commissions

Actuar ial

Cor r espond

Documents

Fund
Tr ades

Hedging

Contr act

Fund
Tr ades

Call
Statistics

HR

Illustr ations

Licensing
& Appt

Plan

Investments

Knowledge

Mar keting

Par ty

Payment

Pr oduct

Pr oduct
Per for mance

Reser ve

BU
Warehouse
Gener al
Ledger

Par ty

Sales by
Ter r itory

Pr oduct

Ser vice

Sales
Penetr ation

Sales
Planning

Secur ity

Slippage

Suspense

Valuations

Value Add
Ser vices

Tax

Analytic
Reports

eCommerce &
Interface Files
eCommer ce &
Inter faces

Valuations

Sales
Comp

Mgmt
Reports

Extract
Services

Transport
Services

Integration
(Data Bus)

Transform
Services

Load
Services

Enterprise
Technical Services
Contr act
Holder

Gener al
Ledger

Tax

Scheduler
Services

Cleansing
Services

Security
Services

Enrichment
Services

MetaData
Services

38

Sample Infrastructure Architecture Blueprint

Brow ser
Client

Thick
Client

IVR

Process

Business
Rules

Intranet
Web
Serv er

Brow ser
Client

Internet

Internet
Web
Serv er

Party

Product

Interaction

Contract

I ntegration

Perv asive
Client

Security

Public or
Private
Network

Application
&
Data Bus

Activ ities

Gatew ay
Registry

Commissions

Partner
Serv ices
Ev ent
Mgmt

Other
Components

Document
Mgmt

Content
Mgmt

Information
Mgmt

Reporting

39

Agenda
1

Introduction

High-Level Analysis and Design

Architecture Blueprinting

Sample Architecture Blueprints

Architectural Mapping Process Illustrated

Reference Architecture Cataloguing Framework

Summary and Conclusion

40

Mapping Dimensions to Consider

Levels of abstraction
Breadth (i.e., architectural domain)
Depth (i.e., services/facilities needed)
Specialization (i.e., styles and related pattern)
Integration of various patterns results in
integration variants/hybrids
Mapping relies on the selection of standards and
products that implement that standard
e.g., JEE IBM WebSphere Application Server

41

Sample Reference Logical Application Architecture Blueprint

(OMA / SOA Hybrid)
Qualities
Channels

Channels

Interaction Integration
Interaction Services

Reusable Components / Services

Security

Application Integration
Application Services
Service Integration

Qualities

Services
Data Integration
Data Services
Infrastructure Integration
Operating System Services

Tools and Utilities

Security

Services

Monitoring
Management

Qualities

Business Processes
Build-Time Services

Monitoring
Management

Business Process Integration

Separation of
concerns through
layering enables
high cohesion and
low coupling
across the
application
components

Network Services
Network
Hardware
Qualities

Interaction
Integration

Bus. Process
Integration

Application
Integration

Service
Integration

Data
Integration

Infrastructure
Integration
42

Sample Reference Application Architecture Implementation Blueprint

Phone

Public Users Clients Agents/Partners Business Users

Fax

Email

Firewall (Secure Gateway & Web I/F)

USPS/Phone Networks

Access Control
Presentation
Citrix Server
Components

Authentication
Server
(LDAP or SSO)

Email Server

IM Server

IP PBX

Web Server

Citrix Client

B2B

Intranet

B2B Bridge

Agent HQ Website

Translation
Services

UW
Workbench
UW Rules
Configuration
Applications

Billing
Workbench

Rating
Workbench
Rating
Configuration
Applications

Claims
Workbench

Collaboration

Validation Rules

User Interface

Search

Content Store

Integration Services

Claims
Configuration
Applications

Billing
Configuration
Applications

BPM Orchestration & Choreography Workflow/STP Engine

Collaboration Manager

BPM Administration I/F

Rule Engine Cache Rule Engine

Policy
Objects
Rule Engine Update Service
Business/Workflow/Routing Rules
Workflow Rules Framework

Process Metric Dashboards Mgr

BPM Workspace
Sales & Marketing
(shared across Bond)

Product Development

Underwriting

Finance & Accounting

shared across Bond/Travelers)

Servicing
(some shared across Bond)

Claim Processing
Process Mgmt

Manage Work
(some shared across Bond)
BPM Core Processes
Audit
Search / Look-ups
Reporting
Agent/Employee Maintenance
(some shared across Bond) (some shared across Bond) (some shared across Bond)
(shared across Bond)
Bond Finance
(shared across Bond)

Actuarial
(shared across Bond)

Legal Compliance
(shared across Travelers)

Product Maintenance

BPM Supporting Processes

BPMS Runtime Environment

Rule Engine Cache

Rule Engine

Rule Engine Update Service

Business Service Rules

Service Bus

Product Selector
Sample Services for Underwriting
Product Information
(New Business Product Selection):
Publisher

Transformation,
Routing,
Notification,
Augmentation,
Service Invocation/
Integration Rules,
Side Effect Operations

Custom Business Services to Support

BPM Core and Supporting Processes

Rules-Based Services Framework

Messaging
Service

XML
Transform.

Logging Service

COTS
Services

Reporting
System

Scanning
System

Investment Mgmt.

Exception
Handling

Batch Service

Req. Status
Tracking Svc.

3rd Party
Services

Security

DMS

Business Partner
Mgmt.

Shared Services

Supporting Systems

Translation Services

Policy
Objects

Other Core Systems

External/
Corporate
Applications
Interface
Dependent
Protocols

COMPASS
Lotus Notes
Systems
DNA
SVoC

RDBMS

DM/DW/BI/KM

Note: See Information Management

Architecture Diagram for more Details

External Feeds
ChoicePoint
Advisen
Moodys
CheckFree

DNB
AON
SurePath
etc.

Information Mgmt

Information Bus
(Object-Relational Mapping from BOM to EDM)
Data
Data
ECM
EDM
Dictionary Archival
Repository
Reporting
Data Integration
IM Capabilities

Business Applications and Services Mgmt

Role-Based Security, Monitoring, Auditing and other Management Services

Process Manager

Dowstream
Applications

Portal Server

Remote Servers

Bond
Desktop

Prod/Ext
Reporting

Portal DB

Content Repository

CAMS
CSAMS
Express
Polaris

Acturial
Workbench

Image Service

Portal Activity Services

Translation
Services

Product
Workbench

Thick Client

Intranet

Protocol Handlers

Configurable Framework Interaction Workbenches

Process Mgmt

Thin Client

Internet

Portlets

Business Applications and Services Mgmt

Instant Messaging

Redirect Link

Product
Configuration
Applications

Information Mgmt

VOIP

Interaction Mgmt

Scanner
IVR Server
Fax Server
Digitization Services

Interaction Mgmt

Business
Event

Portal UI
Framework

Business
Event

Mail

Users & Channels

Users & Channels

(OMA/SOA Hybrid)

43

Technology Products Mapped to the Reference App. Arch. Impl. Blueprint

Phone

Fax

Email

Firewall (Secure Gateway & Web I/F)

USPS/Phone Networks

Scanner

Access Control

IVR Server

Presentation
Citrix Server
Components

Fax Server
Digitization Services

Interaction Mgmt

Business
Event

Authentication
Server
(LDAP or SSO)

Email Server

IM Server

IP PBX

Web Server

Citrix Client

B2B

Intranet

B2B Bridge

Agent HQ Website

Translation
Services

UW
Workbench
UW Rules
Configuration
Applications

Billing
Workbench

Rating
Workbench
Rating
Configuration
Applications

Claims
Workbench

Collaboration

Validation Rules

User Interface

Search

Content Store

Integration Services

Claims
Configuration
Applications

Billing
Configuration
Applications

BPM Orchestration & Choreography Workflow/STP Engine

Collaboration Manager

BPM Administration I/F

Rule Engine Cache Rule Engine

Policy
Objects
Rule Engine Update Service
Business/Workflow/Routing Rules
Workflow Rules Framework

Process Metric Dashboards Mgr

BPM Workspace
Sales & Marketing
(shared across Bond)

Product Development

Underwriting

Finance & Accounting

shared across Bond/Travelers)

Servicing
(some shared across Bond)

Claim Processing
Process Mgmt

Manage Work
(some shared across Bond)
BPM Core Processes
Audit
Search / Look-ups
Reporting
Agent/Employee Maintenance
(some shared across Bond) (some shared across Bond) (some shared across Bond)
(shared across Bond)
Bond Finance
(shared across Bond)

Actuarial
(shared across Bond)

Legal Compliance
(shared across Travelers)

Product Maintenance

BPM Supporting Processes

BPMS Runtime Environment

Rule Engine Cache

Rule Engine

Rule Engine Update Service

Business Service Rules

XML
Transform.

Exception
Handling

Batch Service

Transformation,
Routing,
Notification,
Augmentation,
Service Invocation/
Integration Rules,
Side Effect Operations

Custom Business Services to Support

BPM Core and Supporting Processes

Rules-Based Services Framework

Messaging
Service

Service Bus

Product Selector
Sample Services for Underwriting
Product Information
(New Business Product Selection):
Publisher

Logging Service

COTS
Services

Reporting
System

Scanning
System

Investment Mgmt.

Req. Status
Tracking Svc.

3rd Party
Services

Security

DMS

Business Partner
Mgmt.

Shared Services

Supporting Systems

Translation Services

Policy
Objects

Other Core Systems

External/
Corporate
Applications
Interface
Dependent
Protocols

COMPASS
Lotus Notes
Systems
DNA
SVoC

RDBMS

DM/DW/BI/KM

Note: See Information Management

Architecture Diagram for more Details

External Feeds
ChoicePoint
Advisen
Moodys
CheckFree

DNB
AON
SurePath
etc.

Information Mgmt

Information Bus
(Object-Relational Mapping from BOM to EDM)
Data
Data
ECM
EDM
Dictionary Archival
Repository
Reporting
Data Integration
IM Capabilities

Business Applications and Services Mgmt

Role-Based Security, Monitoring, Auditing and other Management Services

Process Manager

Dowstream
Applications

Portal Server

Remote Servers

Bond
Desktop

Prod/Ext
Reporting

Portal DB

Content Repository

CAMS
CSAMS
Express
Polaris

Acturial
Workbench

Image Service

Portal Activity Services

Translation
Services

Product
Workbench

Thick Client

Intranet

Protocol Handlers

Configurable Framework Interaction Workbenches

Process Mgmt

Thin Client

Internet

Portlets

Business Applications and Services Mgmt

Instant Messaging

Redirect Link

Product
Configuration
Applications

Information Mgmt

VOIP

Portal UI
Framework

Mail

Public Users Clients Agents/Partners Business Users

Interaction Mgmt

JEE Standard
IBM
WebSphere
Product Family
Various Third
Party Products
(as indicated)

Business
Event

Users & Channels

Sample Product
Mapping:

Users & Channels

(OMA/SOA Hybrid)

44

Agenda
1

Introduction

High-Level Analysis and Design

Architecture Blueprinting

Sample Architecture Blueprints

Architectural Mapping Process Illustrated

Reference Architecture Cataloguing Framework

Summary and Conclusion

45

Challenges of an Architecture Continuum Catalog

Scope and Detail of

Architectures

Any Enterprise is likely to have many Solutions and Architectures

Different Segments of the Enterprise, Product lines or Divisions
Different Levels of Detail suitable for different purpose and audience
Time horizon of an Architecture

Specialization Hierarchy
of Architectures

Generic Architectures common to all industries

Industry Specific Architectures
Reference Architecture of a particular Organization

Domains and Views of

an Architecture

Business Domain, Information Domain, Application Domain,

Infrastructure Domain
A Master Architecture can cover all these domains at a high level
Each Domain can have a single comprehensive view of an
Architecture
Each Domain can have multiple views to cover an Architecture
Specialized views for specific purposes within each domain

46

Specialization Hierarchy for Architectures (TOGAF-Centric)

47

Reference Architecture Cataloguing Framework

Objectives:
A catalog with a scope comprehensive enough to hold all
reference architectures blueprints in a meaningful and wellunderstood structure (i.e. be able to accommodate different types
of reference architectures blueprints)
A set of processes to access and maintain the catalog as well as
the reference architectures in the catalog, so the reference
architecture blueprints could be easily preserved and reused,
providing the following functions:
Retrieve a specific reference architecture at any time, given the
dimension specifications
Searchable given any dimension specifications
Allow adding variants to any existing reference architecture
Extendable in terms of new options (attributes) in each
dimensions

48

Reference Architecture Cataloguing Framework Dimensions

Architectural Styles
(Integration Patterns, etc.)

Although we show only 3 basic dimensions here, one could extend this to n dimensions
- An architecture in this catalog will have coordinates (x1, x2, x3,, xn)

Architectural Scope (Generic->Industry->Organization->)

49

Reference Architecture Cataloguing Framework Dimensions

50

Reference Architecture Catalogue Processes

Dimensions Selection

51

Reference Architecture Cataloguing Framework at Work

Sample from Joint NYU-CTS ITP Project (Fall 2009)

52

Agenda
1

Introduction

High-Level Analysis and Design

Architecture Blueprinting

Sample Architecture Blueprints

Architectural Mapping Process Illustrated

Summary and Conclusion

53

Summary Key High-Level Analysis and Design Objectives

Enable Rapid Development of Business and Technical Solutions
Quickly produce a high-level model that reflects the current
understanding of the future state architecture
Put together a high-level program/project estimate and provide a
view of the future state that can be used as a starting point
Leverage blueprinting notations/process and blueprints that have
been standardized within the Enterprise working on the high-level
analysis and design
Follow a top-down process to document the various facets of the
future state architecture starting from the Enterprise level and
going through the business and technology architectures
Conduct technology architecture blueprinting in parallel at the
application, data, and technical levels

54

Course Assignments
Individual Assignments
Reports based on case studies / class presentations

Project-Related Assignments
All assignments (other than the individual assessments) will
correspond to milestones in the team project.
As the course progresses, students will be applying various
methodologies to a project of their choice. The project and related
software system should relate to a real-world scenario chosen by each
team. The project will consist of inter-related deliverables which are
due on a (bi-) weekly basis.
There will be only one submission per team per deliverable and all

teams must demonstrate their projects to the course instructor.

A sample project description and additional details will be available
under handouts on the course Web site
55

Team Project
Project Logistics
Teams will pick their own projects, within certain constraints: for instance,
all projects should involve multiple distributed subsystems (e.g., webbased electronic services projects including client, application server, and
database tiers). Students will need to come up to speed on whatever
programming languages and/or software technologies they choose for their
projects - which will not necessarily be covered in class.
Students will be required to form themselves into "pairs" of exactly two (2)
members each; if there is an odd number of students in the class, then one
(1) team of three (3) members will be permitted. There may not be any
"pairs" of only one member! The instructor and TA(s) will then assist the
pairs in forming "teams", ideally each consisting of two (2) "pairs", possibly
three (3) pairs if necessary due to enrollment, but students are encouraged
to form their own 2-pair teams in advance. If some students drop the
course, any remaining pair or team members may be arbitrarily reassigned
to other pairs/teams at the discretion of the instructor (but are strongly
encouraged to reform pairs/teams on their own). Students will develop and
test their project code together with the other member of their programming
pair.
56

Team Project Approach - Overall

Document Transformation methodology driven
approach
Strategy Alignment Elicitation
Equivalent to strategic planning
i.e., planning at the level of a project set

Strategy Alignment Execution

Equivalent to project planning + SDLC
i.e., planning a the level of individual projects + project
implementation

Build a methodology Wiki & partially implement the

enablers
Apply transformation methodology approach to a
sample problem domain for which a business solution
must be found
Final product is a wiki/report that focuses on
Methodology / methodology implementation / sample
business-driven problem solution
57

Team Project Approach Initial Step

Document sample problem domain and

business-driven problem of interest

Problem description
High-level specification details
High-level implementation details
Proposed high-level timeline

58

Assignments & Readings

Readings
Slides and Handouts posted on the course web site
Textbook: Part Two-Chapter 5

Individual Assignment (due)

See Session 3 Handout: Assignment #1

Individual Assignment (assigned)

Sess Session 5 Handout: Assignment #2

Team Project #1 (ongoing)

Team Project proposal (format TBD in class)
See Session 2 Handout: Team Project Specification (Part 1)

Team Exercise #1 (ongoing)

Presentation topic proposal (format TBD in class)

Project Frameworks Setup (ongoing)

As per reference provided on the course Web site

59

Any Questions?

60

Next Session: Detailed-Level Analysis and Design

61