0% found this document useful (0 votes)
11 views

High Level Analysis and Design

Uploaded by

ayanokojik843
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views

High Level Analysis and Design

Uploaded by

ayanokojik843
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 31

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

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.mcgraw-
hill.com/sites/0073375977/information_center_view0/table_of_contents.html

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

disciplines that enable separation of


Process
People

Application Deliver
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
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

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

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
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
New Business Fulfillment
Capabilities
Business
Users
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
Underwriting via agent self service and Straight Through Processing
Processes
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


Rating Billing,
Related product validation Binding Delivery routing
Rules 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

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

ƒ 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”


Tran
App A DB App B Scope =
Daily
Extract XYZ
State of
App D Comp Scope = Minnesota
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

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 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
Party Product
Product Contract
Contract L&A
L&A Data Warehouse and
Analysis Client Server Network
Activities
Activities Commission
Commission Documents
Documents Other
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

What is the What channels What is the method What automation,


Who is initiating How are business events
classification of the are provided to used to digitize organizations, and processes
the business digitally managed during their
business event initiate the recognized business are needed to support digital
event? life cycle?
type? business event? events? business event management ?
Understand and
Business Users Bond Business Bond Business Model Processes
Reporting
Business

(BPA Tools)
Event Types Operations Business
Start
DB

Process Manage Bus


Business Analyst Process
BU
User Event Mail Scanner Behavior
Service 1 * Relative Event
Bus Priority
Reporting /
Phone IVR Server Manual Business * Push/Pull
Analysis * Process Params
Agents/Partners Function 1 Unit
AE Agent Event Process Mgmt
Metrics
BEPB
-DB

Fax Server
Fax Service 2
Service Manual
Partner
Channel Integration

PE Desk Function 2
Event Manage Enterprise
Email Server Process Workers
Email Digitized
Customers Advisors * Work Collaboration
Event * Work Hierarchy
Routing End * Skills BasedRouting
Customer Service * Work loadBalancing
CE B2B
Event Business Process
$ $ Desktop Marketing
(Intranet / PDA Web Server Management
Specialists
EPW
-DB

Internet) Request (BPM)


VOIP Status STP Path
Public User Tracking
Human Actor Path IT Solution Services
Service Business
Public Processing * Services Orientation
PE Architecture
Event Exception * Human Driven
Instant IM Server design (BOM, Applications
Business * Web Services
Messaging
Rules) * Business Rules

Analysis of
EDM-
SR-
DB

DB

Business Bond Enterprise


Events Business Architect

36
Sample Application Architecture Blueprint

Participants Interaction Processes Services Components Data


Media Views Business

Existing Assets
Services

Package

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

Financial Get Contract Product


Browser Death Product
Professional Party
Contract Holder
Get FP Detail

Get Last Touch


Email Service Product Contract
Contract
Spousal
Financial Continuance Contract Setup
Professional

Check Appoint. Contract


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

Electronic
ElectronicBusiness
Business Composite Other
Other
Other
Gateway
Gateway Valuation Services Stores
Stores
Components
Clearinghouse

Rules
Integration (Application Bus) Navigation

Process

Vendor / Partner Security Session Technical Event Connection Product


Services Management Management Management
Systems Services Security

37

Sample Information Systems Architecture Blueprint

Transactional Operational Data Data Reporting


Data Stores Data Store Warehouse Marts and Analysis

Business
BusinessUnit
UnitData
DataStores
Stores

Accounting Activities Commissions Contract Activities Commissions Actuarial Operational


Accounting Activities Commissions Contract Activities Commissions Actuarial
Reports

Fund Fund Call


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

Sales Sales
Sales Sales Security Slippage
Comp Planning Security Slippage
Comp Planning

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

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

38
Sample Infrastructure Architecture Blueprint

Browser
Browser Thick
Thick Business
Business
IVR
IVR Process
Process
Client
Client Client
Client Rules
Rules

Intranet
Intranet Party
Web Party
Web
Browser Server
Server
Browser
Client
Client

Internet Product
Product
Internet
Web
Web Interaction
Interaction
Server
Server

Contract
Contract
Integration
Integration
Pervasive
Pervasive
Client
Client Security
Security
Application
Application
&
& Activities
Activities
Data
Data Bus
Bus
Gateway
Gateway
Registry
Registry Commissions
Commissions

Partner
Partner
Services
Services
Event
Event Other
Mgmt Other
Mgmt Components
Components

Document
Document Reporting
Reporting
Mgmt
Mgmt Content Information
Content Information
Mgmt
Mgmt Mgmt
Mgmt

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 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 3rdParty 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 ECM External Feeds

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

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

» 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
Image Service

WebSphere
Configuration Configuration Configuration Configuration Configuration Portal Activity Services Prod/Ext
Applications Applications Applications Applications Applications
Portal DB Reporting
Portlets Content Repository Dowstream
Configurable Framework Interaction Workbenches Remote Servers Portal Server 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

Party Products
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)

(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 Transformation, External/
Routing, Corporate
Custom Business Services to Support Applications
Rules-Based Services Framework Notification,
BPM Core and Supporting Processes
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 ECM External Feeds


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

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

ƒ 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->…)

F Bu
(A o c u A r sin
s s ch es
Ar on ite s
ch O ct In
Ar

ite n u r fo
ch

ct e A e D rm
at
ite

ur s o io
es pe m
ct

n
G ct ain
u re

Ap
et a s pl
Do

C ta ic
at
om ti
m

io
pl me
ai

n
ns

ex 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., 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

You might also like