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

1
Agenda

1 Introduction

2 High-Level Analysis and Design

3 Architecture Blueprinting

4 Sample Architecture Blueprints

5 Architectural Mapping Process Illustrated

6 Reference Architecture Cataloguing Framework

7 Summary and Conclusion

2
What is the class about?

 Course description and syllabus:

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

 Textbooks:
» Software Engineering: A Practitioner’s 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

3
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)

4
Icons / Metaphors

Information

Common Realization

Knowledge/Competency Pattern

Governance

Alignment

Solution Approach

55
Agenda

1 Introduction

2 High-Level Analysis and Design

3 Architecture Blueprinting

4 Sample Architecture Blueprints

5 Architectural Mapping Process Illustrated

6 Reference Architecture Cataloguing Framework

7 Summary and Conclusion

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

8
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
which the Reference Architecture is
Reference Architecture based. It includes a set of architectural
terms as well as numerous principles,
Principles policies, and guidelines for governing
the architecture.
Framework Method
• Framework is the organizing basis for
Business
Plan the Reference Architecture and defines
the architectural domains and
Information
Process
People

Application Deliver disciplines that enable separation of

concerns and IT to business alignment.
Technical Operate • Method is the comprehensive set of
defined repeatable processes that are
followed for a consistent and controlled
Governance
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

High Coordination Unification

Shared customers / products / product data /  Customers and suppliers may be local or global
suppliers Business units with similar or overlapping
Operationally autonomous and unique business operations
units Globally integrated business processes supported
 Transactions impact other business units by Enterprise systems
Business process integration

Linked and
Linking and
Shared Integrating Linked Key standard Shared
Shared data automating
customers technology processes customers (core) data
technologies
processes

Diversification Replication
 Few, if any, shared customers or suppliers  Few, if any, shared customers
 Operationally autonomous and unique business  Operationally similar business units
units Independent transactions aggregated at a higher
 Independent transactions level
Autonomous business units with limited discretion
over processes

Low Business process High

Required standardization 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
Level of
Business Data Application Technical
Architecture Architecture Architecture Architecture Architecture Abstraction
Scope
Presentation
Enterprise
Conceptual
Portfolio / Logical
Domain
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
Business Information Application Technology

Implementation Analysis/Design
Architecture and Solution Engineering Views
Product
Deployment

15
Conceptual business architecture framework

Sales and Product Claim

Value Chain Marketing Development
Underwriting Finance and Accounting Servicing
Processing

Business
Capabilities
Business Bond
$ $

Bond
$ $
$ $

Users
Agents/ Bond Bond Agents/ Agents/ Bond
Business B2B Partners Customers Public Business B2B Partners Agents/ Bond Agents/
Business Business B2B Partners Business B2B Partners Customers
Users Users Business B2B Partners Customers Public
Users Users Users 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

Value Chain Underwriting

Business
Capabiliti New Business Fulfillment
es
Business
Agents/ Agents/
Users Agents/
B2B Partners
Agents/
B2B Partners B2B Partners B2B Partners

Business Product
Events Submission Rate Quote* Bind Bill and Issue
Selection

Business Product browser UI Submission UI Agent Portal Bind UI eDoc delivery UI

Channels
BPM
Processe Underwriting via agent self service and Straight Through Processing
s
Process # of Products Submission counts Count of ratings Count of Number of policies
selected by agents by agents/products delivered successful bids issued
metrics Count of exceptions

BRM Product category, Submission Billing,

Related product validation Rating Binding
Rules Delivery routing
rules Form selection

Business Product selector, Submission data capture Rating service Binding service ePOA
Product info Questionnaire builder Quote publisher Electronic Billing configuration
Services publisher Form selector signature capture Delivery manager

Business Agent profile, Form templates, Ratable data, Rating Binding data, Policy/Bond data,
Product catalogue Form metadata, decision, Rates, Policy data Power of Attorney
Entities Submission data Quotes data, Billing data

17
Agenda

1 Introduction

2 High-Level Analysis and Design

3 Architecture Blueprinting

4 Sample Architecture Blueprints

5 Architectural Mapping Process Illustrated

6 Reference Architecture Cataloguing Framework

7 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 in-
transition 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 “city-
planning” 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 Describe or prescribe an end-to-

and modules, typically using an OO end design without delving into
approach details

Level of detail High to low-level High-level

Central Element of A system and its subsystems System of systems

Granularity
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., "building-
level" 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: Application Scope: Project
Blueprint Type: Info Flow Diagram Abstraction: Logical
State: As-Is
Revision Date: 06/14/09 Status: Working Draft
Revised By: John Doe Architect
Approved By: Jane Doe Architect

 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 company’s 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 company’s 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 company’s 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 Map Analogy

Application Architecture
App Portfolio A
App Portfolio B
Scope =
Scope =

Degree of Generalization / information hiding

App Portfolio C
Enterprise United
States

As-Is Application Architecture for App Port “C”

App Tran App
A DB B Scope =
Daily
App Extract XYZ State of
D
Com Scope = Minnesota
p
Portfolio

As-is Application Architecture for “App D”

Daily
Extract

Pgm 1
Scope = Scope = City
System/Project of
Minneapolis

As-is Application Architecture for “Pgm 1”

Scope = Little Scope =

Subsystem/ Downtown
program Minneapolis
27
Agenda

1 Introduction

2 High-Level Analysis and Design

3 Architecture Blueprinting

4 Sample Architecture Blueprints

5 Architectural Mapping Process Illustrated

6 Reference Architecture Cataloguing Framework

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

Prospect Contract Holder Financial Professional Employee Firm Clearinghouse

Middleware
Interaction Medium IT
Interaction Process
Forms Browser Email Phone PDA Text Message Electronic Services Services
Business
View Contract Financial Gateway Transaction Information
Service Sales Other
Holder Professional Services Services
Software
Vendors
Processes Integration
Services
New Business Death Spousal Remittance Programmed Valuation
Form Based Continuance Reallocation
Security Services Application
Software
Services Get Book Get Last Touch Check Appoint
Atomic Services
Management Services Providers
Process
Services Composite Services
Get FP Detail Contract Setup Move Money Virtualization Services
Technical Services
Business
Functional Rules Process
Components Party Product Contract Activities Commissions Other Build Test Prod Outsource
Navigation

Process
Support Product
General Human
Components Knowledge Document Reporting
Ledger Resources Hardware Other
Authorization

Data Transactional Operational

Reporting
Party Product Contract L&A
Data Warehouse and
Analysis Client Server Network
Activities Commission Documents Other Data Marts

33
Sample Detailed Level Business Architecture Blueprint

Client and Product Risk and

Channel Mgmt Financial Mgmt
Product Portfolio Product Product Definition Product
Market Planning Conceptualization and Design Deployment Risk
Research Management
Product Performance Regulatory Investment
Market and Pricing Filing Management Regulatory and
Segmentation Compliance

Channel
Management Sales Legal

Promotion and Sales Generation Licensing and Campaign

Contractholder Brand Mgmt and Enablement Appointments Management Financial Risk
Relationship Mgmt Management

Sales
Firm Commissions Suitability Financial
Compensation
Relationship Mgmt Management

FP Financial Reporting
Relationship Mgmt Service and Metrics

Client Contract Contact Non- Contract Mergers and

Money-In Reallocations
Profile Setup Financial Servicing Financial Servicing Acquisitions

Asset Correspondence Value Added Business

Annuitization Payments Valuation
Retention Management Services Continuity

Business Management and Support

Communications Human Information Procurement and Document and
Accounting Vendor Mgmt Content Mgmt
and Public Relations Resources Technology

Security and Training and Analytics and Facilities

Auditing
Privacy Knowledge Mgmt Reporting Management

34
Sample High-Level Business Architecture Blueprint

(Client and Channel Mgmt)

Product

Financial Mgmt
Client Focus

Risk and
Sales

Service

Business Management and Support

(Information Technology, etc.)

35
Conceptual Technology Architecture Blueprint

36
Sample Application Architecture Blueprint

Participants Interaction Processes Services Components Data

Media Views Business

Existing Assets
Services

Package

External
Custom
Contract New Business –
Party
Prospect Forms Holder Form based Process
Services

Financial Get Contract Product

Browser Death
Professional Party
Contract Holder
Get FP Detail

Get Last Touch

Email Service Product Contract
Spousal
Financial Continuance Contract Setup
Professional

Check Appoint. Contract

Phone PDA Sales Activities
Remittance
Other Services
Employee
Activities
Other
Text Views Programmed Commissions
Message Reallocation Atomic
Services Commissions
Firm

Electronic Business Composite Other

Valuation Other
Gateway Services Stores
Components
Clearinghouse

Rules
Integration (Application Bus) Navigation

Process

Vendor / Partner Security Session Technical Event Connection Product

Systems Services Management
Services Management Management
Security

37
Sample Information Systems Architecture Blueprint

Transactional Operational Data Data Reporting

Data Stores Data Store Warehouse Marts and Analysis

Business Unit Data Stores

Accounting Activities Commissions Contract Activities Commissions Actuarial Operational

Reports

Fund Fund Call

Correspond Documents Hedging Contract
Trades Trades Statistics Mgmt
Reports
BU
Warehouse
HR Illustrations Investments Knowledge General Sales by
Party
Ledger Territory
Analytic
Reports
Licensing
Marketing Party Payment
& Appt Sales
Product Service
Penetration
eCommerce &
Product Interface Files
Plan Product Reserve
Performance eCommerce &
Valuations
Interfaces

Sales Sales
Security Slippage
Comp Planning

Value Add
Suspense Valuations Tax
Services
Extract Transport Integration Transform Load
Services Services (Data Bus) Services Services

Enterprise
Technical Services
Contract General
Tax
Holder Ledger Scheduler Cleansing Security Enrichment MetaData
Services Services Services Services Services

38
Sample Infrastructure Architecture Blueprint

Browser Thick Business

IVR Process
Client Client Rules

Intranet Party
Web
Browser Server
Client

Internet Product
Internet Web Interaction
Server

Contract
Integration
Pervasive
Client Security
Application
& Activities
Public or Data Bus
Private Gateway
Network
Registry
Commissions

Partner
Services
Event Other
Mgmt Components

Document
Reporting
Mgmt Content Information
Mgmt Mgmt

39
Agenda

1 Introduction

2 High-Level Analysis and Design

3 Architecture Blueprinting

4 Sample Architecture Blueprints

5 Architectural Mapping Process Illustrated

6 Reference Architecture Cataloguing Framework

7 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 Separation of
concerns through
layering enables
Interaction Integration
Interaction Services high cohesion and
low coupling
Business Process Integration across the
Reusable Components / Services

Business Processes application

Build-Time Services
components
Management

Application Integration
Monitoring

Qualities
Security
Qualities

Application Services

Service Integration
Services

Data Integration

Data Services
Services

Infrastructure Integration
Tools and Utilities

Operating System Services

Management
Monitoring

Security

Network Services

Network
Hardware

Qualities

Interaction Bus. Process Application Service Data Infrastructure

Integration Integration Integration Integration Integration Integration

42
Sample Reference Application Architecture Implementation Blueprint
(OMA/SOA Hybrid)
Public Users Clients Agents/Partners Business Users

Users & Channels

Users & Channels

Business Business
Event Event

Mail Phone Fax

$ $

Email VOIP Instant Messaging Thin Client Citrix Client B2B Thick Client

USPS/Phone Networks Firewall (Secure Gateway & Web I/F) Internet Intranet Intranet

Scanner

Framework
Access Control B2B Bridge

Portal UI
Authentication Email Server IM Server CAMS
IVR Server Presentation Server CSAMS
IP PBX Web Server
Fax Server Citrix Server (LDAP or SSO) Express
Translation
Polaris
Interaction Mgmt

Interaction Mgmt
Digitization Services Components Protocol Handlers Agent HQ Website Services
Redirect Link Bond
Desktop
Collaboration Validation Rules User Interface
Product UW Rating Billing Claims Acturial
Workbench Workbench Search Content Store Integration Services
Workbench Workbench Workbench Workbench
Product UW Rules Rating Billing Claims
Configuration Configuration Configuration Configuration Configuration Portal Activity Services Image Service
Applications Applications Applications Applications Applications
Prod/Ext
Portal DB Reporting
Portlets Content Repository Dowstream
Configurable Framework Interaction Workbenches Remote Servers Portal Server Applications

BPM Orchestration & Choreography Workflow/STP Engine BPM Administration I/F Policy Rule Engine Cache Rule Engine
Objects Rule Engine Update Service
Process Manager Collaboration Manager Process Metric Dashboards Mgr
Business/Workflow/Routing Rules
Role-Based Security, Monitoring, Auditing and other Management Services

BPM Workspace Workflow Rules Framework

Sales & Marketing Finance & Accounting Servicing
Product Development Underwriting Claim Processing
(shared across Bond) shared across Bond/Travelers) (some shared across Bond)
Process Mgmt

Process Mgmt
Manage Work
(some shared across Bond)
BPM Core Processes
Audit Search / Look-ups Reporting Agent/Employee Maintenance Actuarial
(some shared across Bond) (some shared across Bond) (some shared across Bond) (shared across Bond) (shared across Bond)
Bond Finance Legal Compliance
Product Maintenance
(shared across Bond) (shared across Travelers)
BPM Supporting Processes
BPMS Runtime Environment

Policy Rule Engine Cache Rule Engine Service Bus

Product Selector
Business Applications and Services Mgmt

Business Applications and Services Mgmt

Objects Rule Engine Update Service Sample Services for Underwriting
Product Information
(New Business – Product Selection):
Business Service Rules Publisher External/
Transformation,
Corporate
Custom Business Services to Support Routing,
Rules-Based Services Framework Applications
BPM Core and Supporting Processes Notification,

Translation Services
Augmentation, Interface COMPASS
Dependent
Messaging XML COTS Reporting Scanning
Service Invocation/ Protocols
Logging Service Investment Mgmt. Integration Rules, Lotus Notes
Service Transform. Services System System
“Side Effect” Operations Systems
Exception Req. Status 3rd Party Business Partner
Batch Service Security DMS Mgmt. DNA
Handling Tracking Svc. Services

Shared Services Supporting Systems Other Core Systems SVoC

Information Bus
(Object-Relational Mapping from BOM to EDM)
Information Mgmt

Information Mgmt
Data Data External Feeds
ECM

Translation
EDM

Services
ChoicePoint DNB
Dictionary Archival Repository
Advisen AON
Reporting Data Integration Note: See Information Management Moodys SurePath
IM Capabilities RDBMS DM/DW/BI/KM Architecture Diagram for more Details CheckFree etc.

43
Technology Products Mapped to the Reference App. Arch. Impl. Blueprint
(OMA/SOA Hybrid)

Public Users Clients Agents/Partners Business Users

Users & Channels

Users & Channels
Business Business

 Sample Product
Event Event

Mail Phone Fax

$ $

Email VOIP Instant Messaging Thin Client Citrix Client B2B Thick Client

USPS/Phone Networks Firewall (Secure Gateway & Web I/F) Internet Intranet Intranet

Mapping: Scanner

Framework
Access Control B2B Bridge

Portal UI
Authentication Email Server IM Server CAMS

» JEE Standard
IVR Server Presentation Server CSAMS
IP PBX Web Server
Fax Server Citrix Server (LDAP or SSO) Express
Translation
Polaris

Interaction Mgmt

Interaction Mgmt
Digitization Services Components Protocol Handlers Agent HQ Website Services
Redirect Link Bond

» IBM
Desktop
Collaboration Validation Rules User Interface
Product UW Rating Billing Claims Acturial
Workbench Workbench Search Content Store Integration Services
Workbench Workbench Workbench Workbench
Product UW Rules Rating Billing Claims
Configuration Configuration Portal Activity Services Image Service
Configuration Configuration Configuration Prod/Ext

WebSphere Applications Applications Applications

Configurable Framework Interaction Workbenches

Applications Applications

Portlets Content Repository

Remote Servers
Portal DB
Portal Server
Reporting
Dowstream
Applications

Product Family BPM Orchestration & Choreography Workflow/STP Engine BPM Administration I/F Policy Rule Engine Cache Rule Engine
Objects Rule Engine Update Service

» Various Third
Process Manager Collaboration Manager Process Metric Dashboards Mgr
Business/Workflow/Routing Rules
Role-Based Security, Monitoring, Auditing and other Management Services
BPM Workspace Workflow Rules Framework
Sales & Marketing Finance & Accounting Servicing
Product Development Underwriting Claim Processing

Party Products (shared across Bond) shared across Bond/Travelers) (some shared across Bond)
Process Mgmt

Process Mgmt
Manage Work
(some shared across Bond)

(as indicated) Audit Search / Look-ups Reporting

(some shared across Bond) (some shared across Bond) (some shared across Bond)
BPM Core Processes
Agent/Employee Maintenance
(shared across Bond)
Actuarial
(shared across Bond)
Bond Finance Legal Compliance
Product Maintenance
(shared across Bond) (shared across Travelers)
BPM Supporting Processes
BPMS Runtime Environment

Policy Rule Engine Cache Rule Engine Service Bus

Product Selector
Business Applications and Services Mgmt

Business Applications and Services Mgmt

Objects Rule Engine Update Service Sample Services for Underwriting
Product Information
(New Business – Product Selection):
Business Service Rules Publisher External/
Transformation,
Corporate
Custom Business Services to Support Routing,
Rules-Based Services Framework Applications
BPM Core and Supporting Processes Notification,

Translation Services
Augmentation, Interface COMPASS
Dependent
Messaging XML COTS Reporting Scanning
Service Invocation/ Protocols
Logging Service Investment Mgmt. Integration Rules, Lotus Notes
Service Transform. Services System System
“Side Effect” Operations Systems
Exception Req. Status 3rd Party Business Partner
Batch Service Security DMS Mgmt. DNA
Handling Tracking Svc. Services

Shared Services Supporting Systems Other Core Systems SVoC

Information Bus
(Object-Relational Mapping from BOM to EDM)
Information Mgmt

Information Mgmt
Data Data External Feeds
ECM

Translation
EDM

Services
ChoicePoint DNB
Dictionary Archival Repository
Advisen AON
Reporting Data Integration Note: See Information Management Moodys SurePath
IM Capabilities RDBMS DM/DW/BI/KM Architecture Diagram for more Details CheckFree etc.

44
Agenda

1 Introduction

2 High-Level Analysis and Design

3 Architecture Blueprinting

4 Sample Architecture Blueprints

5 Architectural Mapping Process Illustrated

6 Reference Architecture Cataloguing Framework

7 Summary and Conclusion

45
Challenges of an Architecture Continuum Catalog

 Any Enterprise is likely to have many Solutions and Architectures

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

 Generic Architectures common to all industries

Specialization Hierarchy  Industry Specific Architectures
of Architectures  Reference Architecture of a particular Organization
 …

 Business Domain, Information Domain, Application Domain,

Infrastructure Domain
 A Master Architecture can cover all these domains at a high level
Domains and Views of  Each Domain can have a single comprehensive view of an
an Architecture 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 well-
understood 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

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)
(Integration Patterns, etc.)
Architectural Styles

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

2 High-Level Analysis and Design

3 Architecture Blueprinting

4 Sample Architecture Blueprints

5 Architectural Mapping Process Illustrated

6 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., web-
based 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