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
11
Introduction
Introduction
22
High-Level
High-Level Analysis
Analysis and
and Design
Design
33
Architecture
Architecture Blueprinting
Blueprinting
44
Sample
Sample Architecture
Architecture Blueprints
Blueprints
55
Architectural
Architectural Mapping
Mapping Process
Process Illustrated
Illustrated
66
Reference
Reference Architecture
Architecture Cataloguing
Cataloguing Framework
Framework
77
Summary
Summary and
and Conclusion
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/spring10/G22.2440-001/
ƒ Textbooks:
» Software Engineering: A Practitioner’s Approach
Roger S. Pressman
McGraw-Hill Higher International
ISBN-10: 0-0712-6782-4, ISBN-13: 978-00711267823, 7th Edition (04/09)
» http://highered.mcgraw-hill.com/sites/0073375977/information_center_view0/
» http://highered.mcgrawhill.com/sites/0073375977/information_center_view0/table_of_contents.html
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
11
Introduction
Introduction
22
High-Level
High-Level Analysis
Analysis and
and Design
Design
33
Architecture
Architecture Blueprinting
Blueprinting
44
Sample
Sample Architecture
Architecture Blueprints
Blueprints
55
Architectural
Architectural Mapping
Mapping Process
Process Illustrated
Illustrated
66
Reference
Reference Architecture
Architecture Cataloguing
Cataloguing Framework
Framework
77
Summary
Summary and
and Conclusion
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
based. It includes a set of architectural
terms as well as numerous principles,
policies, and guidelines for governing
the architecture.
Reference Architecture
Principles
Principles
Framework
Framework
Method
Method
Plan
Business
Information
Process
People
Application
Technical
Deliver
Operate
Governance
Governance
• 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
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
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
Portfolio /
Domain
Conceptual
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
Implementation Analysis/Design
Product
Deployment
Architecture and Solution Engineering Views
ƒ In this context, relevant views are those that match the phases of an
solution development life cycle
15
Conceptual business architecture framework
Value Chain
Sales and
Marketing
Product
Development
Underwriting
Finance and Accounting
Servicing
Claim
Processing
Business
Capabilities
Business
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
Capabilities
Fulfillment
New Business
Business
Users
Business
Events
Business
Channels
Product
Selection
Submission
Product browser UI
Submission UI
BPM
Processes
Rate Quote*
Agent Portal
Bind
Bill and Issue
Bind UI
eDoc delivery UI
Underwriting via agent self service and Straight Through Processing
Process
metrics
# 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
11
Introduction
Introduction
22
High-Level
High-Level Analysis
Analysis and
and Design
Design
33
Architecture
Architecture Blueprinting
Blueprinting
44
Sample
Sample Architecture
Architecture Blueprints
Blueprints
55
Architectural
Architectural Mapping
Mapping Process
Process Illustrated
Illustrated
66
Reference
Reference Architecture
Architecture Cataloguing
Cataloguing Framework
Framework
77
Summary
Summary and
and Conclusion
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
ƒ 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
Application Architecture
Map Analogy
App Portfolio B
Scope =
Enterprise
App Portfolio C
As-Is Application Architecture for App Port “C”
App A
App D
Daily
Extract
Tran
DB
App B
XYZ
Comp
Scope =
Portfolio
As-is Application Architecture for “App D”
Daily
Extract
Pgm 1
Scope =
System/Project
Degree of Generalization / information hiding
App Portfolio A
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
11
Introduction
Introduction
22
High-Level
High-Level Analysis
Analysis and
and Design
Design
33
Architecture
Architecture Blueprinting
Blueprinting
44
Sample
Sample Architecture
Architecture Blueprints
Blueprints
55
Architectural
Architectural Mapping
Mapping Process
Process Illustrated
Illustrated
66
Reference
Reference Architecture
Architecture Cataloguing
Cataloguing Framework
Framework
77
Summary
Summary and
and Conclusion
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
Interaction
Contract Holder
Financial Professional
Employee
Firm
Clearinghouse
Sourcing
Middleware
Medium
Forms
View
Browser
Contract
Holder
Email
Financial
Professional
Phone PDA
Service
Electronic
Business
Gateway
Text Message
Sales
Other
Interaction
Services
Process
Services
Transaction
Services
Information
Services
Processes
IT
Software
Vendors
Integration
Services
New Business
Form Based
Services
Process
Services
Functional
Components
Spousal
Continuance
Death
Programmed
Reallocation
Remittance
Get Book
Get Last Touch
Check Appoint
Get FP Detail
Contract Setup
Move Money
Valuation
Security Services
Atomic Services
Application
Software
Providers
Management Services
Composite Services
Virtualization Services
Technical Services
Business
Process
Outsource
Rules
Party
Product
Contract
Activities
Commissions
Other
Build
Navigation
Test
Prod
Process
Support
Components
Data
Knowledge
Document
General
Ledger
Reporting
Product
Human
Resources
Transactional
Hardware
Authorization
Other
Operational
Party
Party
Product
Product
Contract
Contract
L&A
L&A
Data Warehouse
Activities
Activities
Commission
Commission
Documents
Documents
Other
Other
Data Marts
Reporting
and
Analysis
Client
Server
Network
33
Sample Detailed Level Business Architecture Blueprint
Client and
Channel Mgmt
Risk and
Financial Mgmt
Product
Product Portfolio
Planning
Market
Research
Product
Conceptualization
Product Performance
and Pricing
Market
Segmentation
Product Definition
and Design
Regulatory
Filing
Channel
Management
Product
Deployment
Risk
Management
Investment
Management
Regulatory and
Compliance
Sales
Promotion and
Brand Mgmt
Contractholder
Relationship Mgmt
Sales Generation
and Enablement
Sales
Compensation
Firm
Relationship Mgmt
Legal
Licensing and
Appointments
Commissions
FP
Relationship Mgmt
Campaign
Management
Financial Risk
Management
Suitability
Financial
Management
Financial Reporting
and Metrics
Service
Client
Profile
Contract
Setup
Money-In
Contact NonFinancial Servicing
Contract
Financial Servicing
Reallocations
Mergers and
Acquisitions
Asset
Retention
Annuitization
Payments
Valuation
Correspondence
Management
Value Added
Services
Business
Continuity
Business Management and Support
Communications
and Public Relations
Security and
Privacy
Human
Resources
Information
Technology
Accounting
Training and
Knowledge Mgmt
Auditing
Procurement and
Vendor Mgmt
Analytics and
Reporting
Document and
Content Mgmt
Facilities
Management
34
(Client and Channel Mgmt)
Sample High-Level Business Architecture Blueprint
Risk and
Financial Mgmt
Client Focus
Product
Sales
Service
Business Management and Support
(Information Technology, etc.)
35
Conceptual Technology Architecture Blueprint
Bond Business
Event Types
BU
Business
User Event
What is the method
used to digitize
recognized business
events?
How are business events
digitally managed during their
life cycle?
Bond Business
Operations
Mail
Start
Scanner
Service 1
PE
Partner
Event
CE
$
Email Server
Email
Customers
$
Customer
Event
B2B
Desktop
(Intranet /
Internet)
PDA
Public User
PE
Public
Event
Analysis of
Business
Events
Instant
Messaging
Service
Desk
Digitized
Event
Routing
Service
Web Server
Request
Status
Tracking
Service
VOIP
Understand and
Model Processes
Business
Process
Analyst
* Relative Event
Service 2
Manual
Function 2
(BPA Tools)
Manage Bus
Process
Behavior
Bus
Priority
Reporting /
Business * Push/Pull
Analysis
* Process Params
Unit
Mgmt
Process
Metrics
Fax Server
Fax
Manage Enterprise
Process Workers
Advisors
End
Business Process
Management
(BPM)
STP Path
Human Actor Path
Processing
Exception
IM Server
EDMDB
Agent Event
Channel Integration
AE
Manual
Function 1
IVR Server
SRDB
Agents/Partners
Phone
What automation,
organizations, and processes
are needed to support digital
business event management ?
BEPB
-DB
What channels
are provided to
initiate the
business event?
Marketing
Specialists
Business
Architecture
design (BOM,
Business
Rules)
* Work Collaboration
* Work Hierarchy
* Skills BasedRouting
* Work loadBalancing
EPW
-DB
Business Users
What is the
classification of the
business event
type?
Business
Reporting
DB
Who is initiating
the business
event?
IT Solution Services
* Services Orientation
* Human Driven
Applications
* Web Services
* Business Rules
Bond Enterprise
Business Architect
36
Sample Application Architecture Blueprint
Contract
Holder
New Business –
Form based
Financial
Professional
Death
Browser
Contract Holder
Components
Business
Services
Process
Services
Get Contract
Email
Get Last Touch
Service
Spousal
Continuance
Phone PDA
Party
Party
Contract
Contract
Product
Contract Setup
Check Appoint.
Sales
Data
Product
Product
Party
Get FP Detail
Financial
Professional
Custom
Forms
Services
Package
Prospect
Processes
Views
External
Interaction
Media
Existing Assets
Participants
Remittance
Contract
Activities
Activities
Other Services
Employee
Activities
Text
Message
Other
Views
Programmed
Reallocation
Electronic
ElectronicBusiness
Business
Gateway
Gateway
Clearinghouse
Valuation
Commissions
Commissions
Atomic
Services
Commissions
Composite
Services
Other
Components
Firm
Other
Other
Stores
Stores
Rules
Integration (Application Bus)
Navigation
Process
Session
Management
Security
Services
Vendor / Partner
Systems
Technical
Services
Event
Management
Connection
Management
Product
Security
37
Sample Information Systems Architecture Blueprint
Transactional
Data Stores
Operational
Data Store
Data
Warehouse
Data
Marts
Reporting
and Analysis
Actuarial
Actuarial
Operational
Reports
Business
BusinessUnit
UnitData
DataStores
Stores
Accounting
Accounting
Activities
Activities
Commissions
Commissions
Contract
Contract
Activities
Activities
Commissions
Commissions
Correspond
Correspond
Documents
Documents
Fund
Fund
Trades
Trades
Hedging
Hedging
Contract
Contract
Fund
Fund
Trades
Trades
HR
HR
Illustrations
Illustrations
Investments
Investments
Knowledge
Knowledge
Licensing
Licensing
& Appt
& Appt
Marketing
Marketing
Party
Party
Payment
Payment
Plan
Plan
Product
Product
Product
Product
Performance
Performance
Reserve
Reserve
Sales
Sales
Comp
Comp
Sales
Sales
Planning
Planning
Security
Security
Slippage
Slippage
Suspense
Suspense
Valuations
Valuations
Value Add
Value Add
Services
Services
Tax
Tax
General
General
Ledger
Ledger
Product
Product
Call
Call
Statistics
Statistics
BU
BU
Warehouse
Warehouse
Party
Party
Sales by
Sales by
Territory
Territory
Service
Service
Sales
Sales
Penetration
Penetration
Mgmt
Reports
Analytic
Reports
eCommerce &
Interface Files
eCommerce &
eCommerce &
Interfaces
Interfaces
Valuations
Valuations
Extract
Services
Transport
Services
Scheduler
Services
Cleansing
Services
Integration
(Data Bus)
Transform
Services
Load
Services
Enterprise
Enterprise
Contract
Contract
Holder
Holder
General
General
Ledger
Ledger
Technical Services
Tax
Tax
Security
Services
Enrichment
Services
MetaData
Services
38
Sample Infrastructure Architecture Blueprint
Browser
Browser
Client
Client
Thick
Thick
Client
Client
IVR
IVR
Process
Process
Business
Business
Rules
Rules
Intranet
Intranet
Web
Web
Server
Server
Browser
Browser
Client
Client
Internet
Internet
Web
Web
Server
Server
Party
Party
Product
Product
Interaction
Interaction
Contract
Contract
Integration
Integration
Pervasive
Pervasive
Client
Client
Security
Security
Application
Application
&
&
Data
Data Bus
Bus
Activities
Activities
Gateway
Gateway
Registry
Registry
Partner
Partner
Services
Services
Commissions
Commissions
Event
Event
Mgmt
Mgmt
Other
Other
Components
Components
Document
Document
Mgmt
Mgmt
Content
Content
Mgmt
Mgmt
Information
Information
Mgmt
Mgmt
Reporting
Reporting
39
Agenda
11
Introduction
Introduction
22
High-Level
High-Level Analysis
Analysis and
and Design
Design
33
Architecture
Architecture Blueprinting
Blueprinting
44
Sample
Sample Architecture
Architecture Blueprints
Blueprints
55
Architectural
Architectural Mapping
Mapping Process
Process Illustrated
Illustrated
66
Reference
Reference Architecture
Architecture Cataloguing
Cataloguing Framework
Framework
77
Summary
Summary and
and Conclusion
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)
Separation of
concerns through
layering enables
high cohesion and
low coupling
across the
application
components
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
$
Access Control
Presentation
Citrix Server
Components
Fax Server
Digitization Services
Authentication
Server
(LDAP or SSO)
Email Server
IM Server
IP PBX
Web Server
Thick Client
B2B
Intranet
Intranet
B2B Bridge
CAMS
CSAMS
Express
Polaris
Translation
Services
Agent HQ Website
Protocol Handlers
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
Bond
Desktop
BPM Administration I/F
Collaboration Manager
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
Finance & Accounting
shared across Bond/Travelers)
Underwriting
Dowstream
Applications
Portal Server
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)
BPM Supporting Processes
BPMS Runtime Environment
Rule Engine Cache
Rule Engine
XML
Transform.
Exception
Handling
COTS
Services
Logging Service
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
Rule Engine Update Service
Business Service Rules
Req. Status
Tracking Svc.
Reporting
System
3rd
Party
Services
Security
Scanning
System
Investment Mgmt.
DMS
Business Partner
Mgmt.
External/
Corporate
Applications
Translation Services
Policy
Objects
Shared Services
Interface
Dependent
Protocols
COMPASS
Lotus Notes
Systems
DNA
Other Core Systems
Supporting Systems
SVoC
Information Bus
(Object-Relational Mapping from BOM to EDM)
RDBMS
Note: See Information Management
Architecture Diagram for more Details
DM/DW/BI/KM
External Feeds
Translation
Services
Data
Data
ECM
EDM
Dictionary Archival
Repository
Reporting
Data Integration
IM Capabilities
ChoicePoint
Advisen
Moodys
CheckFree
DNB
AON
SurePath
etc.
Information Mgmt
Information Mgmt
Actuarial
(shared across Bond)
Legal Compliance
(shared across Travelers)
Product Maintenance
Business Applications and Services Mgmt
Role-Based Security, Monitoring, Auditing and other Management Services
Process Manager
Prod/Ext
Reporting
Portal DB
Content Repository
Remote Servers
BPM Orchestration & Choreography Workflow/STP Engine
Acturial
Workbench
Image Service
Portal Activity Services
Portlets
Configurable Framework Interaction Workbenches
Process Mgmt
Citrix Client
Redirect Link
Product
Workbench
Product
Configuration
Applications
Business Applications and Services Mgmt
Thin Client
Internet
Interaction Mgmt
Scanner
IVR Server
Instant Messaging
VOIP
Email
Firewall (Secure Gateway & Web I/F)
USPS/Phone Networks
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
Public Users Clients Agents/Partners Business Users
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
IP PBX
Citrix Client
B2B
IM Server
Web Server
Intranet
B2B Bridge
Agent HQ Website
UW
Workbench
UW Rules
Configuration
Applications
Billing
Workbench
Rating
Workbench
Rating
Configuration
Applications
Claims
Workbench
Validation Rules
User Interface
Translation
Services
Search
Content Store
Integration Services
Claims
Configuration
Applications
Billing
Configuration
Applications
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
Dowstream
Applications
Portal Server
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
Collaboration Manager
Bond
Desktop
Prod/Ext
Reporting
Portal DB
Content Repository
Remote Servers
BPM Orchestration & Choreography Workflow/STP Engine
Process Manager
Image Service
Portal Activity Services
CAMS
CSAMS
Express
Polaris
Acturial
Workbench
Translation
Services
Product
Workbench
Thick Client
Intranet
Protocol Handlers
Portlets
Process Mgmt
Thin Client
Collaboration
Configurable Framework Interaction Workbenches
Business Applications and Services Mgmt
Instant Messaging
Internet
Redirect Link
Product
Configuration
Applications
Information Mgmt
VOIP
Portal UI
Framework
Phone
Interaction Mgmt
» JEE Standard
» IBM
WebSphere
Product Family
» Various Third
Party Products
(as indicated)
Business
Event
Mail
Users & Channels
ƒ Sample Product
Mapping:
Users & Channels
(OMA/SOA Hybrid)
44
Agenda
11
Introduction
Introduction
22
High-Level
High-Level Analysis
Analysis and
and Design
Design
33
Architecture
Architecture Blueprinting
Blueprinting
44
Sample
Sample Architecture
Architecture Blueprints
Blueprints
55
Architectural
Architectural Mapping
Mapping Process
Process Illustrated
Illustrated
66
Reference
Reference Architecture
Architecture Cataloguing
Cataloguing Framework
Framework
77
Summary
Summary and
and Conclusion
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->…)
ch
Ar
ite
u
ct
re
ns
ai
m
Do
F
(A o c u A r
s s ch
Ar on ite
ch O ct
ite n u r
ct e A e D
ur s o
es pe m
G ct ain
et a s
C ta
om ti
pl me
ex
)
Bu
sin
es
s
In
fo
rm
at
io
n
Ap
pl
ic
at
io
n
Te
ch
no
lo
g
y
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
11
Introduction
Introduction
22
High-Level
High-Level Analysis
Analysis and
and Design
Design
33
Architecture
Architecture Blueprinting
Blueprinting
44
Sample
Sample Architecture
Architecture Blueprints
Blueprints
55
Architectural
Architectural Mapping
Mapping Process
Process Illustrated
Illustrated
66
Summary
Summary and
and Conclusion
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)
ƒ
Project Frameworks Setup (ongoing)
ƒ Presentation topic proposal (format TBD in class)
ƒ As per reference provided on the course Web site
59
Any Questions?
60
Next Session: Detailed-Level Analysis and Design
61