wicsa5 - ontology-based architecture

Capital One confidential / proprietary

WICSA5 - Ontology-Based Architecture

Art Akerman & Jeff Tyree

November 9, 2005

2 Capital One Confidential/ProprietaryMarch 17, 2005

Key Realizations (Based on Capital One experience with software architecture)

• Architecture decisions are the primary representation of architecture

• Architecture results from effective decision making, not from architectural view construction*

• Architecting is primarily concerned with architecture assets, the business-driven decisions that transform these assets, and the roadmap that implements these decisions.

*J. Tyree and A. Akerman, "Architecture Decisions: Demystifying Architecture," IEEE Software, vol. 22, pp. 19-27, March. 2005


Problems with our current architecture development method & descriptions

• Lack of Focus on What’s Important• Lack of Precision and Clarity• Lack of Repository Support• Lack of Support for Impact Analysis (Decisions to Concerns,

Decisions to Decisions, and Decisions to Architecture Assets)• Difficulty in Linking with the Views• Lack of Support for Temporal Mapping


Solution

• Architecture meta-model• Focus on “information about architecture that an organization

cares about” instead of diagrams and views. Architecture is captured as an ontology.

• Tool support to enable effective decision making and “on-demand” view creation


Conceptual Architecture Meta-Model

transforms

RoadmapConcern

Architecture Decision

implemented byaddressed by

Architecture Asset


Architecture Meta-Model (Details)

• Concerns• Decisions• Roadmap• Assets

Change Case

Concern Relationship Type

Risk Quality Capability Business Need

Zone

Location

borders

0..n+consists of

0..n

Node

composed of

+located atData

1..n

+deployed on

1..n

Architecture Pattern

Component

composed of

+deployed onuses

0..n

+participates

0..n

Mission

Environment

Subsystem

contains

1..n1..n

aggregates

Roadmap

System

+fulfills

+inhabits

+influences

1..*

1

1..*

1

consists of

Alternative Element Relationship Type

Stakeholder

1..n+has

1..n

Decision Relationship Type

Initiative

1..n

+organized by

1..n

Concern1..n1..n

+has

1..n

+is important to

1..n

contains

Implication

Project

1..n1..n

Alternative1..n

1..n

1..n

+addresses as soft goals

1..n

1..n1..n

has

Architecture Asset

Architecture Decision1

+implemented by

1

1

1..n

1

+has

1..n

transforms0..n0..n

is related to

Business Control

Business Process

validates

Interface (alias Service)

1..n

+offers

1..n

0..n+uses

0..n

composed of


Ontology Tool – Protégé

• Open source• Easy to use interface• Plug-ins and scripting – can use to extend functionality and to

import / export data


Simple Process Utilizing Ontology to Develop Architecture

•Populate model with Key Concerns•Populate model with existing architecture assets•Define placeholders for architecture decisions•Create appropriate diagrams (As-Is and Target) to help visualize aspects of architecture•Define architecture decisions•Assign implications to initiatives or projects•Generate architecture documentation


Step 1 – Populate model with Key Concerns

•Identify key concerns to be addressed by architecture– Impacted business processes (AKA capabilities)– Key business (functional) requirements– System qualities (AKA non-functional requirements)


Step 2 – Populate model with existing architecture assets

•Existing systems in scope•Existing interfaces between systems•Physical nodes and systems allocated to them•Major data elements and systems which manage them


Step 3 – Define placeholders for architecture decisions

•Create a list of decision placeholders by making sure that each concern is addressed by at least one decision. Decision status – “Under Construction”•Determine decision impact (based on urgency to make a decision, its impact on ongoing planning activities, etc.)•Each placeholder can be assigned to a member of architecture team.


Step 4 – Create appropriate diagrams (As-Is and Target) to help visualize aspects of architecture

•Business process flows (ARIS)•IT System View (Visio)•Operational View (Visio)

Browser(Consumers/Providers)

Convergys

Protocol

InternetARGO DB

Capstone

ALS

CommServer

DataTransfer117

XTA119

023

118

ARGO

GeniFax

CIT

Bridger

ZipInfo

114

113

111

110

112

020

ClientServices

PresentationServices

Application Services

ExtendedEnterprise

Services

EnterpriseServices

AWS 015

AnalyticalDesktop

DWLOAN

SAS/ SQL

IVR

107

VoiceNetwork

Consumer/ Provider

Phone

LAN /WANDesktop

Fax

108

ACH Client

CASH

028

101

102

PrintingVendor

SSO

103

Organizational elements & Application system .

Carries out &

Supports

Carries out &

Supports

Carries out &

...C

arries out & S

upportsC

arries out & S

...C

arries out & S

upportsC

arries out & S

upportsC

arries out & ...

CC

Case createdChordiant(ORION)

Identify casetype

Recoverycase identified

Non-Recoverycase identified

Call TS2 API

TS2

Visa

Update OptionsSet to flag as

RCL

Transmit recordto Domestic RCL

Fraud DA

CDW

Populaterecord in

CDW

GenerateInternationalRCL report

FraudRecovery

Key InternationalRCL submissions

TS2

Mastercard

Initiate requestfor affidavit

CasperGenerateaffidavit

Initiate request todelete tradeline

Update OptionsSet to delete

tradeline

Case Ready

Receive andprocess RCL

request

Will Lowrey7/25/05 8:35:05 AM

CONTACT CENTER (CC)

Reviewers: Chris MastroManage Fraud and Dispute Case

Provide Customer ServiceManage Specialty Ops

Administer Case: COF .1202

ProphITFraud

Reported

Manage Fraud andDispute Case -Main


Step 5 – Define architecture decisions

•Start with “High” impact placeholder decisions and populate them with data in the model (assumptions, alternatives, etc)•After you select an alternative to become your final decision write the implications. •Create new decision placeholders for implications which require additional decisions. Determine impact level of new decisions.•Define how implications impact architecture assets (create, modify, retire, use). Create new assets as required (systems, interfaces)•When done with all “High” impact decisions, move to “Medium” and then “Low”


Step 6 – Assign implications to initiatives or projects

•Create list of initiatives, assign projects to them•Each decision implication, which is not addressed by another decision, should be assigned to an initiative or project to be implemented*

*For agile projects associate implications with project backlog items. Backlog items then get associated with sprints


Step 7 – Generate architecture documentation*

• Architecture Decisions document– Generate architecture decision using template format

• Architecture Overview document– Generate list of systems and interfaces – Generate list of business processes (capabilities) and decisions addressing

them– Data entities to systems mapping– NFRs to decisions mapping

• Operational Model– Logical to physical nodes mapping

*First export Protégé data into SQL database and the use VBA / SQL Queries to generate documentation

wicsa5 - ontology-based architecture

Documents