Agile Architecture, Design, and Modeling

Traditionally, architecture is concerned with:

System Structure

• Tangible solution elements and their visible properties

• Relationships between these elements

• Interactions and behaviour of these elements

Design Decisions

• Supporting an explicit set of desired qualities

• Solving for both functional and non-functional requirements

• Meeting needs of broad range of stake-holders, from developers to operations

• Provides a common foundation for development, support, and maintenance

Agile Development is typically concerned with creating solutions in the face of constant change, new markets, and optimal user

experience. Software products designed to thrive in this context have been designed using an agile architecture (e.g. Amazon,

Google, Dropbox, Netflix, AirBnB, etc). This agile architecture uses the following architectural principles.

• Enabled Emergence Design decisions are made in such a way as to maximize decision reversibility, new design decision can be

made as learning occurs

• Rigorous Simplicity constant reduction of development complexity that naturally occur over time

• Modularized Control deliberate selection of which aspects of the system can be freely changed, and which need control and

planning

• Business Embodies a significant subset of the solution is expressed in such a way that it can be understood by business experts,

with technical concerns hidden away

• Beyond Stability increased robustness in the face of constant stress (Anti-fragility)

• Social Coupling modules and systems structures are designed around an explicit, and highly collaborative, team–component

ownership model

• Inherently Measurable built in validation as to whether the system is meeting business objectives, operational performance,

and other requirements in production

• Relentlessly Automated components are selected and designed in a way to foster complete automation of the build, test,

deploy and operate/monitor lifecycle

• Single-Purpose Assembly components are designed and selected to be fine-grained, single-purpose modules that can

interoperate with each other in unanticipated ways

An Agile Architecture creates a solution that can adapt to constant change, deploy market-leading innovation, and provide the highest quality customer experience

3

The discipline of Agile Architecture is integrated across the entire delivery lifecycle

4

The discipline of Agile Architecture is integrated across the entire delivery lifecycle

5

Agile architecture is an iterative process that works in parallel with Story Exploration

Opportunity Definition

Opportunity Planning

Release Planning

Backlog Grooming and Sprint Execution

MMF1

Agile Architecture

Assets Examples

6

Architecture Models

7

System Context

8

• System Context Diagrams are diagrams used to define the system boundaries (i.e. system under discussion) and

represent interactions between the system under discussion and external systems/interfaces

• These diagrams usually picture the system at the center, with no details of its interior structure, surrounded by all of its

interacting systems, environments and activities.

• Often, the System Context Diagram can be supplemented with Domain Driven Design interaction patterns (e.g. Anti-

corruption layer). Below is an example of a system context diagram:

Purpose

Sample System Context Diagram

9

Course Registration

System

Online Book Store

Degree and Course

Management System

University Document

Management System

Room Booking System

LDAP

Authenticate

Authenticate

Schedule Classrooms

Purchase Books

Stores / Uploads Course

Content

View / Download Course Content

Update Course and Degrees

Key Mechanism Overview

• Key mechanisms are solutions to a common recurring problem within the system

• Explicitly call out aspects of the solution mechanics that are common across the system. This helps you plan.

• Put down markers for the developers to build those aspects of the system once and then re-use them. This reduces the workload.

• Promote the development of a consistent set of services. This makes the system

easier to maintain.

An initial cut at the mechanisms that will form the

backbone of the architecture of the system

Key Mechanism Sample

Corporate Data Warehouse

Description: One of the requirements as part of this project is the desire to have

management reports on how long it takes to process registrations as well as the number of

successful, unsuccessful and declined registrations.

Key Participants: Versions of the registrations persisted into the Course db2 database will

be extracted and persisted into the corporate data warehouse on a regular basis to meet

reporting requirements. Reports can be written and run from this data when required using

Cognos or Sas.

Google Web Toolkit:

Description: One of the architecture principles that we are implementing in this project is “to enable ease of extendibility” of the functionalities provided within the application.

Key Participants: GWT will act as View layer in our Spring Model View Controller framework. So it will work with our Controllers as well as our Spring configuration mechanism.

12

Technical Solution Architecture Document

• The Solution Architecture Document communicates the overall architecture of the solution to guide and inform delivery by

identifying the key architecture risks, constraints, platform architecture, layered architecture, and key mechanisms for the

solution

• The intent is to provide just enough documentation to inform delivery and identify technical assumptions that may need to

be proven through an architectural baseline/executable architecture

• This document will be iteratively built throughout the Architecture Definition phase with input from the information defined in

the Story Exploration phase.

Purpose

Contents

Platform

Architecture

Layered

Architecture

Non-Functional

RequirementsKey Mechanisms

Architecture

Reference

Business Domain

Diagram

Overview System ContextArchitecture Risks

Architecture

Constraints /

Decisions

Architecture

principles

Architecture

Framework

13

Infrastructure Requirements Document

Description

The Infrastructure Requirements Documents is used to gather the information required to setup

infrastructure prior to beginning of Delivery. It includes a summary of the deployment diagram,

environments required, and IT infrastructure configurations, This document is completed iteratively

and in parallel with the Solution Architecture Document.

A document that details:

1. UML Deployment Diagram

2. Environment Requirements

3. IT Infrastructure Configuration Summary

Sample

Domain Models Using Class Responsibility Cards

14

15

Class Responsibility Collaboration (CRC) Modeling

• A CRC model is a collection of CRC cards that

represent whole or part of an application or

problem domain

• The most common use for CRC models, is to

gather and define the user requirements for an

object-oriented application

• Cards that collaborate with one another are close

to each other, cards that don’t collaborate are not

near each other

• CRC models are created by groups of business

domain experts, led by a CRC facilitator who is

assisted by one or two scribes. The CRC

facilitator is responsible for planning and running

the CRC modeling session

What is CRC Modeling?

• CRC modeling relies on natural language to describe concepts and their relationship to each other

making it much easier for users and business subject matter experts to participate

• With business actively involved, buy-in for the potential solution is greatly increased

• People who understand the problem and business domain are the ones who create the model and this

ensures the right model is developed

Benefits

16

CRC Modeling

• A CRC card is a standard index card that has been divided into three sections

• A class represents a collection of similar objects. An object is a person, place, thing, event, concept,

screen, or report that is relevant to the system at hand. The name of the class appears across the top

of the card.

• A responsibility is anything that a class knows or does. For example, customers have names,

customer numbers, and phone numbers. These are the things that a customer knows. Customers also

order products, cancel orders, and make payments. These are the things that a customer does. The

things that a class knows and does constitute its responsibilities. Responsibilities are shown on the left

hand column of a CRC card.

• Sometimes a class will have a responsibility to fulfill, but will not have enough information to do it.

When this happens it has to collaborate with other classes to get the job done. The collaborators of a

class are shown in the right-hand column of a CRC card.

CRC Card

Perform The Iterative Steps of CRC Modeling’

• Look for anything that interacts with the system, or is part of the system

• Potentially prototype interface and / or classes

• Create a new card for a class immediately

• Use one or two words to describe the class

• Class names are singular

Find classes

• Ask yourself what the class knows

• Ask yourself what the class does

• If you’ve identified a responsibility, ask yourself what class it "belongs" to

• Classes will collaborate to fulfill many of their responsibilities

Find

responsibilities

DescriptionSteps

• Collaboration occurs when a class needs information that it doesn’t have

• Collaboration occurs when a class needs to modify information that it doesn’t have

• There will always be at least one initiator of any given collaboration

• Sometimes the collaborator does the bulk of the work

• New responsibilities may be created to fulfill the collaboration

Define

collaborators

• Transcribe the scenarios onto cardsDefine user

stories

• Cards that collaborate with each other should be close to one another on the table

• The more that two cards collaborate, the closer that they should be on the table

• Expect to be moving the cards around a lot at the beginning

• Put "busy" cards towards the center of the table

• People will identify relationships/associations between classes as they move them around

Arrange the

cards on the

table

17

CRC Sample

18

CRC Sample – Visualizing how to model interactions within the domain (i.e. University Course Registration)

19

Collaborates

Domain Models Using Domain Driven Design

20

21

Introduction to Domain Driven Design

An architectural methodology for evolving a software system that closely aligns

to business requirements

Domain Driven Design IS

Domain Driven Design IS NOT

• A silver bullet

• A panacea for all your troubles

• An easy path to follow

• Always the best solution

And most importantly, it is not focused on the How, but the What and Why

22

A quick example of implementing domain driven design principles

public bool CanBook(Cargo cargo, Voyage voyage)

{

if (!overbookingPolicy.IsAllowed(cargo, voyage))

return false;

...

}

public bool CanBook(Cargo cargo, Voyage voyage)

{

double maxBooking = voyage.Capacity * 1.1;

if (voyage.BookedCargoSize + cargo.Size > maxBooking)

return false;

...

}

DDD is about making concepts explicit

23

Introduction to Domain Driven Design

The Domain Vision Statement

• A shared understanding of what it is you are actually trying to create

• Should be brief, written in clear English and understood by business and tech people alike

• Should be factual, realistic, honest

• Should avoid superlatives and marketing speak

• Should avoid technical and implementation details

• Closely designing the system according to the knowledge of business domain experts ensures that

future business changes have a predictable and manageable impact in terms of necessary system

changes

What is the Business Domain Model?

• The business domain model is responsible for representing business concepts, information about

business situations, business state, and business rules

• Must be created in a form that is understood by business domain experts

• Represented by the a language understood by business domain experts (also called the Ubiquitous

Language)

• Intimately linked with implementation code and/or services, and a complicated mapping exercise

should not be required to translate from the business domain model to the part of the application code

used to represent business concerns.

24

Introduction to Domain Driven Design

• A major reason for failure of software projects is a failure of people, the failure to communicate (i.e.

Quite often there is a language wall between clients and developers)

• The Ubiquitous Language is a shared language between the business and the development teams

• The UL comes from the business, and is enriched by the development teams

• Although the UL is drawn in the language of the business, it can also include things that might seem

like technical terms.

Ubiquitous Language

25

The Domain Expert

• Domain Experts are the primary point of contact the development teams have with the business

• They are the Experts on their part of the business, not just users of the system

• They should have deep knowledge of the subject Domain

• Someone you talk to when you’re figuring all this stuff out

• If you’re doing Agile he/she might join team

• Not necessarily technical

• Can explain not only how, but WHY

• BAs not best, just proxy

Domain Expert

26

Manage additional business complexity through Domain Driven Design

• Structure the business problem into business entities, business services, specifications, aggregates

and repositories

• Build a summary model before the project starts, and provide details to the team on iterative, just-

in-time basis

Funding Instrument

ApplicationEducational Institution Third Party Audit

Eligibility

Entitlement and

DistributionReview

Business Modules Common Modules

Data Definition

Life Cycle

Permission

Override

Process

CommunicationSupporting Document

Event

Restriction

Business Domain Model

Story Realization

27

The building blocks of Domain Driven Design

28

Business Domain Model – Components

• Defined primarily by an inherent identity

• Have an identity that remains the same regardless of changes to specific data

• Examples include: Application, Student, EducationalInstitutionProgram

Entities

• Attributes of something else

• Value objects do not have any inherent identity, and are often shared by many different entities

• Examples include: DateSession, ParticipantAssetDefinition

Value Objects

DescriptionComponent

• A cluster of closely associated objects that should be treated as a single unit for the purpose of data

access and changes

• Described in terms of roots; directly accessible, and boundaries which define the cluster of objects

• Example: an application would be the root of its own aggregate which would contain (among other

participants) an ApplicationStatusHistory, and ApplicationSpecificStudentIncome

Aggregates

• Gatekeeper to all business logic for a particular domain

• Control/encapsulate business rules, business logic and business validation for a particular domain

• Examples include: ApplicationService, StudentService, ApplicationGroupService

Services

• Any object available through a direct persistence layer searching/access will rely on a data

repository to provide that access

• Represents a simple and business specific interface to stored data

Data

Repositories

Image

• Modules are used to group related concepts from the model

• Primary purpose of modules is to reduce cognitive load

• Example All classes containing User related logic

• Module names should make sense in terms of the ubiquitous language

Modules

Customer

• Factories is to encapsulate the details of aggregate creation

• Factories are constructs that while added to the business domain model, do not strictly correspond

to any specific business concept

Factories

29

Business Domain Model – Relationships

• Used to represent relationships where one element within the model has a

form of ownership, control, or some other responsibility of another element

within the model

• Used when the more explicit relationships (i.e., Association or

Generalization) do not easily apply

• Often used to represent the relationship between elements and any

Services that manage them, the Factory/Repositories that create them,

and Specifications that validate them

• Example: a Student is "managed by" a StudentService, an Application is

validated by a "ApplicationSpecification"

Dependency

• Used to describe an ownership relationship

• Used to describe when one object/class has knowledge of another

object/class

• Describes the "has a" relationship.

• Each end of the relationship is described in terms of role and cardinality

• Example: an Application "is funded by" one ApplicationGroup, an

ApplicationGroup "provides funding to" zero or more Applications for any

given year.

Composition

Association

DescriptionRelationship

• Used to describe situations where a more specialized business concept

can be partially represented by a base or more generic business concept

• Use to organize business entities and concepts that have common

behavior and structure

• Describes the "is a" relationship

• Example: a Student "is a" specialized type of ApplicationParticipant. It

shares all the structure and behavior of an application participant but is

extended to support eligibility and assessment based information and

processing.

Generalization

Image

30

Fitting Domain Driven Design into Layered Architecture

31

Business Domain Overview - Example

• Page The owner of the URL.

Responsible for selecting a

template to render the content

• Template A layout for a page

• Section A very broad

categorization of pages.

Examples of sections are

News, Travel, and Business.

• Keyword A way of describing a

subject that exists within a

section. Used to categorize

articles, keywords drives

automatic navigation.

• Content A piece of textual

content or article that we can

deliver to a user.

Business Concepts Examples

32

Ubiquitous Language Example

• A DistributionCenter represents a physical site

that distributes various items

• A DistributionCenter can either be a

SatelliteDistributionCenter or a

NonSatelliteDistributionCenter

• A SatelliteDistributionCenter is used to handle

situations where a PrimaryDistributionCenter is

unable to handle all of the inventory that it is

responsible for housing and shipping

• A nearby SatelliteDistributionCenter is created,

and associated with the

PrimaryDistributionCenter

• The PrimaryDistributionCenter is represented as

a NonSatelliteDistributionCenter

Domain Model Ubiquitous Language

Given

The fulfillment order exists for the order

AND A successful standard response from fulfillment vendor indicator flag exist

When

Fulfillment vendor sends a fulfillment order response to mobile service vendor

Then

Fulfillment order status is updated

ID

Description

Receive Acceptance

I want to update the fulfillment order status, once vendor accepts or rejects the

fulfillment order

Sc

en

ari

o

Agile Requirements and Design – Cheat SheetBehaviour Driven

Development

Class Responsibility

Collaborator Cards

Purpose: Method to gather and define the user requirements for an object-

oriented application

Input: Story Map, High Level Business Requirements / Features, Project Analysis

Form, Business Case

Required Participants: Solution Designer, Developer, Business Analyst, Project

Manager (optional)

Output: CRC Model

Responsibility Collaborator

Class

Identifies a person,

place, thing, event,

concept, screen, or

report that is relevant

to the system at hand

Another class that a

class interacts with to

fulfill its responsibilities

Anything that a class

knows or does

Approach: Take a feature or MMF and

Identify Classes – Determine the building blocks of the system

Define Responsibilities – identify what a class does and what

information it holds

Identify Collaborators – Does the class have the ability to fulfill

its responsibilities? If not identify the class(es) that have the

ability to fulfill the missing functionality or the class which should

fulfill it

Move Cards Around – Place the cards in an intelligent order

with classes collaborating extensively being placed close

together

• Example:

Responsibility

• EnrollsInCourses

• IsPartOrFullTime

• IsTakingADegree

• PurchaseTextBooks

Collaborator

• Course,

CourseEnrollment

Class: Student

Responsibility

• HasACode

• HasEnrollment

Collaborator

• Course,

CourseEnrollment

Class: Course

Responsibility

• ByAStudent

• ForACourse

Collaborator

• Student

• Course

Class: CourseEnrollment

Purpose: Combines requirements and testing into one integrated approach with

the goal to build requirement scenarios using a series of examples

Input: Story Map, High Level Business Requirements / Features, Project Analysis

Form

Required Participants: Business Analyst, Solution Designer, Developer, Tester,

Project Manager (optional)

Output: BDD by feature

Feature

Feature Description

Scenario

Acceptance Criteria with Data

A Feature is a something that is

meaningful to the customer, has

business value and is small enough to

be testable

A brief description of the Feature written

in a way that is meaningful to the

customer. May leverage “As a …I

can…so that”

Scenarios provide a narrative to describe

the sequencing of events necessary to

complete the feature

Explicit requirement that includes:

• Various ranges and data values

• Different business rules resulting in changes in

data

• Positive and negative conditions

Approach: For each feature

Build Feature Description

Define One or More Scenarios

Identify Acceptance Criteria and Data for Development &

Test

• Example:

Given

When

Then

The fulfillment order exists for the order

With a FulfillmentOrderID F1001 And has a FulfillmentOrderStatus SENT_FOR_FULFILLMENT

For OrderID 1001 On SentDate 3/1/2011 And is fulfilled by FulfillmentVendorID 1

With a FulfillmentOrderItemID 151 And a ShipmentTrackingNumber 9876543210

With a FulfillmentOrderItemStatus NEW And has OrderItemID 10Cri

teri

a W

ith

Da

ta

Agile Requirements and Design – Cheat SheetDomain Driven Design

Terminology

Business Domain Model: Business domain model is a rigorously organized and selective

abstraction of business domain knowledge

Ubiquitous Language: A language structured around the domain model, has meaning for

both business & technical teams and is used to connect all the activities of the team with the

software

Association: Represents a relationship between two business concepts in the model. To add

meaning to the relationship, constrain it by imposing a traversal direction and adding a qualifier

Entity: Object within the business domain model that can be uniquely identified and

meaningfully distinguished (e.g. VIP Admission vs. General Admission)

Value Object: An object that contains attributes but has no conceptual/unique identity (e.g.

dollar bill in the hands of a consumer or vendor)

Service: An operation offered as an interface that stands alone in the model and is defined in

terms of what it can do for a client

Modules (or Packages): Method of organizing the model which can help in decoupling major

components and represent different major business concepts A module is a collection of

classes, relationships, story realizations, diagrams, and other modules. It is used to structure

the business domain model by dividing it into smaller parts

Aggregates: Abstraction used to represent a cluster of associated objects that should be

treated as a single unit for the purpose of data changes. Each aggregate has a root and a

boundary

Factory: Methods for creating domain objects should delegate to a specialized Factory object

such that alternative implementations may be easily interchanged

Repositories: Abstraction over the persistence store, returning entities (or more precisely

aggregate roots) meeting some criteria

Purpose:

o DDD includes a set of patterns for building enterprise applications from the

domain model out. It places the attention on the heart of the application,

focusing on the complexity that is intrinsic to the business domain itself

o A business domain model that is understood by business SMEs and is

clearly reflected/mapped to the implementation code will result in a system

that reflects the way the business domain SMEs actually thinks

Input: Business Domain Knowledge, Story Map, High Level Business

Requirements / Features, Project Analysis Form, CRC Model

Required Participants: Solution Designer, Developer, Tester, Business Analyst,

Business SME, Project Manager (optional)

Output: Business Domain Model, Lifecycle Domain Model

Approach

Initial business domain modeling / scenario walkthrough – CRC Cards

can be leveraged to complete this

Refine business aspects of the domain model – CRC Cards can be

leveraged to complete this. For larger/complex projects the domain model

can include identifying: Entities, Value Objects, Modules, Association

Extend the model to include lifecycle concerns – Model how domain

objects are created, saved, retrieved, and modified. Model components

include Aggregates, Factories, Repositories, Services

Review Business Domain Model – Leverage the domain model to

walkthrough scenarios identified through Behaviour Driven Development

Implement Business Domain Model – Work should start as soon as

possible to "prove the model" with code. It is vital to • Ensure that the mapping between the model and implementation code is

straightforward

• Develop code using the same language as the model

• Are responsible for the model, or else the model will have nothing to do

with the software

• Model and implement, in a collaborative fashion

• Ensure that changing code must have a corresponding change in the

model

Update Business Domain Model with Implementation Constraints – As

required the model should be updated with any discovered implementation

constraints and regular scenario walkthrough should occur

Conduct Stakeholder Review – As changes are made to the model or

code it should be reviewed with the business

Association

Value Object

Service

Factory

Repository

Entity

Story Realizations Using UML

35

36

Story Realizations – Overview

• An interface between the system, users and/or any other systems

• Typically represents abstractions of one or more graphical user interface elements but can also be

used to represent connections to different systems

Boundaries

• Responsible for the coordination, sequencing, transaction management and/or control of a class,

usually specific to a particular business area

• Contains and manages business logic, business rules, business validation and act as the

gatekeeper/façade to particular business areas

Services

DescriptionComponent

• Represents long-lived or persistent information that can be both in memory as well as a persistent

version of particular piece of business information

• Also represented in the Business Domain Model, where they are further elaborated in terms of

responsibility and structure

Entities

• Messages are annotated with technology enablers known as Key Mechanisms

• Key Mechanisms represent technology components that enable the solution. (e.g., Client

Rendering, Process Orchestration, etc.)

Technology

Enablers

Image

• Illustrate how components of the Business Domain Model interact with each other within the context of a specific story or

scenario within a story

• Interaction diagrams are used to break up steps within a story into components shown below

Story Realizations

37

Story Realization Example“Apply for Financial Assistance”

1. A student logs in for financial

assistance

Detailed Story

Main ScenarioStory Realization

2. A student selects their application

group, academic year and accepts their

terms and conditions

3. A student enters their education

information

4. A student answers their initial

eligibility questions

5. A student submits their completed

application

38

The Road to Code – Sequence Diagrams

Sequence diagrams are used to show the run-time behavior of the system

• Describe interactions among objects in terms of an exchange of messages over time

• Often used to model OO software, but can be used to model many other types of items, such as business processes

Real Life Example

Simple Sequence Diagram Example

Interaction Diagram for a Single Story

Sequence Diagram

• The flow of time is shown from top to bottom,

that is messages higher on the diagram

happen before those lower down

• The blue boxes are instances of the

represented classes, and the vertical bars

below are timelines

• The arrows (links) are messages - operation

calls and returns from operations

• The hide and show messages use guards to

determine which to call. Guards are always

shown in square braces [ ] and represent

constraints on the message (the message is

sent only if the constraint is satisfied)

39

40

The Road to Code – Sequence Diagrams

AnObject : MyClass

Lifeline

Focus ofControl

Time

Object Notation

Has 3 major components:

• Object – indicates both the name and type of

the instance <name>:<type>

• Lifeline – represents the existence of the

object over a period of time

• Focus of Control – indicates the period of

time in which the object is performing an

action

Time progresses downward along the vertical

axis.

41

The Road to Code – Sequence Diagrams

AnotherObject : AnotherClass

<<create>>

doSomething(foo, bar)

MyObject : MyClass

Messages

• Objects interact with one another through sequenced messages. These can be constructor or

method calls

42

The Road to Code – Sequence Diagrams

: AbstractDAO MyDAOClient

PreparedStatement

: SQLHelper

add(DomainObject theObject): voidgetInsertStatement(theObject)

getInsertParameters(theObject)

execute(DomainObject theObject,String sql, List parameters): void

bindParameters(Connection theConnection, Strng sql, String parameters): Statement

canBind(String sql, List parameters)

Connection.prepareStatement(String sql)

<<create>>

*[for each parameter] : handleStatementBinds(Prepared Statement theStatement, Object param, int position): void

setXXXX()

executeUpdate()

Agile Modeling Method

43

Test-driven

Development

Acceptance Test

Driven

Development

Iteration

Model

Storming

Model

Envisioning

Backlog

Emergent

Design

Multiple Models

Class

Responsibility

Collaborator

Domain Driven

Design Model

Agile Class &

Sequence

Diagrams

Other Models

Wiki Project

Repository

Single Source of Information

Do

cu

ment L

ate

Mu

ltip

le M

od

els

in

Pa

ralle

l

Document continuously

Model a Bit Ahead

Architecture

Key

Mechanism

4 + 1 views

System

Context

Software

Architecture

Description

The Agile Modeling Method provides a framework to enable best in class

system modeling using an iterative, evolutionary, and emergent approach

1. Initial model envisioning is conducted for the overall set of requirements in the backlog by defining a

high-level system context with other light-weight architecture design artifacts

2. Iteration modeling is conducted during each iteration to model just good enough to give good

estimates and inform iteration planning

3. Additional design through model storming occurs just-in-time and the architecture model is captured

through multiple models such as Agile Class and Sequence Diagrams and Domain Driven Design

4. Technical practices such

as test-driven

development and

acceptance-test driven

development is applied

during coding, models are

proved with code and

any changes are fed back

into the models

5. Models are displayed

publicly and collaboration

platforms such as a Wiki

Project Repository is

used to capture models

6. The team models a bit

ahead as needed to

reduce overall risk as the

team moves forward

• Determine availability of foundational artifacts at a level that

can drive discussion between multiple groups of

stakeholders

• Facilitate joint modeling sessions with key business and

technology SMEs and stakeholders using structured, but

simple, collaborative tools

• Refine outputs of modeling sessions “breadth before depth”

into a holistic view that can be understood by business and

technology

Story map

Provide Interac Payment Services

Apply Transaction

FeesReport MIS AnalyticsPerform Fraud Services

Analyze Consortium

DataReal-time Scoring

Analyze Consortium

Data

Real-time ScoringAnalyze Consortium

Data

Analyze Consortium

Data

Real-time Scoring

System/Integration ModelR

e

t

r

i

e

v

e

C

o

n

s

o

r

t

i

u

m

D

a

t

a

R

e

t

r

i

e

v

e

B

u

s

i

n

e

s

s

R

u

l

e

A

p

p

l

y

B

u

s

i

n

e

s

s

R

u

l

e

t

o

D

a

t

a

E

x

t

r

a

c

t

R

e

l

e

v

a

n

t

T

r

a

n

s

a

c

t

i

o

n

D

a

t

a

R

e

t

u

r

n

F

r

a

u

d

S

c

o

r

e

G

e

n

e

r

a

t

e

R

e

p

o

r

t

s

P

r

o

v

i

d

e

R

e

p

o

r

t

s

A

g

g

r

e

g

a

t

e

M

e

m

b

e

r

D

a

t

a

G

e

n

e

r

a

t

e

R

e

p

o

r

t

s

P

r

o

v

i

d

e

R

e

p

o

r

t

s

A

g

g

r

e

g

a

t

e

M

e

m

b

e

r

D

a

t

a

EMT Gateway

Information Model

Architecture Model

Level 1 Effort

Estimation

Scheduling (High Level

Release Plan)

Model Storming (High Level Requirements and

Architecture Overview)

• Break solution models into

separate work items that can

be designed, developed,

tested, and potentially

deployed as an atomic unit

• Estimate work items using

collaborative planning

sessions to determine the “T-

shirt” size (S, M, L, XL)

• Further elaborate on model

storming artifacts as

necessary to improve

granularity and confidence of

estimates

Effort Estimate

• Prioritize completion of work

items according to

dependencies, technical risk

and business value

• Determine the velocity of the

team’s ability to complete

work per iteration

• Determine team size

appropriate to complete work

in the order dictated by

critical path

• Add supplemental delivery

effort required such as

project management,

training, UAT, etc.

Schedule

Model Storming will allow team members to acquire “just enough” knowledge to begin delivery using an agile approach at a larger scale

Model Storming fast-tracks development by doing just enough analysis to facilitate reasonably fine-grained estimation

– Active and engaged SME involvement throughout delivery

– Embedded coaching of agile practices

– Executive commitment to just-in-time approach

– Alignment with an organization’s delivery model (CMMI)

S

M

L

XL

M

S

S

S

Model Storming Estimates

Bond Futures

Interest Rate Short

Cleared Basis Swaps

American Options

Credit Default Swaps

Execution

Collaboration

Validation

Feedback

S

M

S

L

Completed

Delivery with a “just-in-time” approach requires several success factors

Backlog

Model storming uses simple, low fidelity tools to maximize collaboration and inclusiveness, allowing stakeholders to swarm as necessary to gather information

Agile Documentation Principles

• Document…

• When the Business Asks you to

• For Clarity Across Teams working in different locations

• To establish appropriate business and technical Context for the solution

• To define Interfaces across systems

• To Enable your Next Effort

• Informally

• To Understand

• To Communicate

• Don’t Document (formally)…

• To Specify

• Because your Process Says So

• Unproven ideas (prototype it first)

• Without obtaining the structure from your Intended Audience

• Without Considering Maintenance and cost of ownership

• Implementation and Design Details that can be just as easily expressed in the solution itself

• Essential Documents

• Operations and Support

• Developer Setup & Manuals

• User Manuals

• Delivery Plan

Software Architecture (RUP)

• According to IBM, using RUP: A Software Architecture of a program or computing system is the

structure or structures of the system, which comprise software elements, the externally visible

properties of those elements, and the relationships among them. The software architecture of a

system or a collection of systems consists of all the important design decisions about the software

structures and the interactions between those structures that comprise the systems. Decisions made

about software architecture support a desired set of qualities that the system should support to be

successful, providing a conceptual basis for system development, support, and maintenance.

For more information: http://www.ibm.com/developerworks/rational/library/feb06/eeles/

Architecture Key Mechanism (RUP)

• Architecture Mechanism represents common concrete solutions to frequently encountered

problems. They may be patterns of structure, patterns of behavior, or both. 3 categories of

architecture mechanisms include:

1. Analysis Mechanism (eg. Communication)

2. Design Mechanism (eg. Message queue)

3. Implementation Mechanisms (eg. Oracle)

For more information: http://www.ibm.com/developerworks/rational/library/4706.html

4 + 1 Views (RUP)

• The 4+1 View Model of Software Architecture organizes a description of a software architecture

using five concurrent views, each of which addresses a specific set of concerns Developers capture

their design decisions in four views and use the fifth view to illustrate and validate them. This use of

multiple views allows one to address the concerns of the various “stakeholders” of the architecture

seperately and to handle separately the functional and nonfunctional requirements. The 4 + 1 views

are as follows:

– Logical View – functionality

– Implementation View – software management

– Process View – performance, scalability, throughput

– Deployment View – system topology, delivery, installation communication

– User-Case View 0- the final view, overlaps each one of these standalone and independent views

For more information: http://www.pld.ttu.ee/~kruus/db_is02.pdf

Emerging Design (Code Craftsmanship)

• Emerging design is a principle in Agile for which a team starts delivering functionality and lets the

design emerge. Development will take a functionality and implement it using best practices and

proper test coverage, then then move on to delivering another functionality. When the second

functionality is being or have finished being built, the team will assess what has been done and

refactor out the commonality, allowing the design to emerge. This continuous process eventually

produces the smallest set of the design needed. The end result is a smaller code base, which

naturally has less room for defects and a lower cost of maintenance.

For more information: http://www.softwarereality.com/design/early_prototyping.jsp

Model Storming

• Model storming is just in time (JIT) modeling: when an issue needs to be resolved, the team gets

together, explores the issue, identifies what needs to be done and then proceeds to resolve it. Model

storming is an Agile implementation of JAD (Joint Application Design) and the team should be

cross-functional and may involve business SMEs. Common artifacts generated from a model

storming session are:

– Agile class and sequence diagrams

– CRC

– Agile architecture

– Domain model

For more information: http://www.agilemodeling.com/essays/modelStorming.htm

Agile Class and Sequence Diagrams

• Agile sequence and class diagrams are artifacts commonly produced using UML during Model

Storming sessions for design communicating as opposed to design specification. They can use non-

normative UML notation because they are lightweight and not intended to define all cases that need

to be considered, but rather serve as accelerators to design discussions with just enough detail to

start development. Creating and using these artifacts encourages emergent design.

• Sequence diagrams model the flow of logic horizontally across different interacting entities, and

models the flow of time vertically. They are a visual way to capture system behavior and is useful for

both analysis and design purposes. Agile class diagrams show the classes of the system, their

interrelationships (including inheritance, aggregation, and association), and the operations and

attributes of the classes. Class diagrams are often used in both conceptual/domain modeling and

detailed design modeling.

For more information:

http://www.agilemodeling.com/artifacts/sequenceDiagram.htm

http://www.agilemodeling.com/artifacts/classDiagram.htm

System Metaphor

• A System metaphor used in Extreme Programming in place of a formal architecture to tell a simple

shared story of how the system works, a metaphor. This story typically involves a handful of classes

and patterns that shape the core flow of the system being built. It's a naming concept for classes

and methods that should make it easy for a team member to guess the functionality of a particular

class/method, from its name only. An ubiquitous language (common, rigorous language between

developers and users) is used such that confusion in wording of things are minimized. It is XP’s

approach to domain driven design, with naming of classes and their responsibilities to reflect the

business meaning, and an intention to create intuitive code.

For more information: http://www.extremeprogramming.org/rules/metaphor.html

Spike

• A spike (from Extreme Programming) is a story that cannot be estimated until a development team

runs a timeboxed investigation. The output of a spike story is an estimate for the original story. It is a

minimal prototype implementation of some system functionality that encompasses the entire range

of system operability.

A Spike Solution Is:

1. Very simple experiment to explore potential solutions

2. Necessarily time-boxed

3. Likely intended to be thrown away

Spikes are very useful to figure out what teams do not know to understand the complexity of

something so that it can be properly estimated, quoted, or analyzed for feasibility.

For more information: http://www.extremeprogramming.org/rules/spike.html

Class Responsibility Collaboration (CRC)

• A Class Responsibility Collaborator model (from Extreme Programming) is a collection of standard

index cards, often used to facilitate Model Storming, that have been divided into three sections:

1. Class Name

2. Responsibilities

3. Collaborators

A class represents the entity that’s part of the system, a responsibility is something that the class

knows or does, as in its attributes and functionalities, and a collaborator is another class that a class

interacts with to fulfill its responsibilities. Creating CRC cards is typically done with a cross-functional

team with the intent to collaborate and identify the primary classes and associated responsibilities.

For more information: http://www.agilemodeling.com/artifacts/crcModel.htm

Non-functional Requirements

• Unlike functional requirements, which define specific behavior or functions, non-functional

requirements describe qualities of a system (what it is), and are requirements that specify criteria

that can be used to judge the operation of a system, rather than specific behaviors. For example, a

non-functional requirement of a system may be to have “sufficient network bandwidth”. Technical

tests are often written to verify non-functional requirements.

For more information: http://www.infoq.com/news/2008/11/nonfunctional-requirements

System Context Diagrams

• System Context Diagrams are diagrams used to represent important external factors that interact

with the system at hand in order to focus attention on external factors and events that should be

considered in developing a complete set of system requirements and constraints. These diagrams

usually pictures the system at the center, with no details of its interior structure, surrounded by all its

interacting systems, environment and activities.

For more information: http://en.wikipedia.org/wiki/System_context_diagram

Low Fidelity UI Mockup (Agile Modeling)

• Low fidelity UI Mockups are prototype or models of the UI that has the most essential features

without the exact details. It should be technology independent and illustrates the interaction

behaviors allowed by modeling user interface requirements. They are sketchy, low-fidelity

wireframes that let you focus design conversations on functionality.

For more information: http://www.agilemodeling.com/artifacts/essentialUI.htm

Features (Agile Modeling)

• A feature is a client-valued function that can be implemented in two weeks or less, named using this

template:

– <action> the <result> <by|for|of|to> a(n) <object>

An object is a person, place, or thing (including roles, moments in time or intervals of time, or

catalog-entry-like descriptions)

For example,

– Calculate the total of a sale

– Assess the fulfillment timeliness of a sale

– Calculate the total purchases by a customer

For more information: http://www.petercoad.com/download/bookpdfs/jmcuch06.pdf

Minimum Marketable Feature Set (Agile Modeling)

• A minimum marketable feature set is the set of the smallest increments of functionality that has

value to the end users on its own. There isn’t much reason to release anything smaller than the

MMF, when thinking about MMFs, keep in mind of the following:

– Minimum: If a split would result in a story so small that it couldn’t be marketed to your customers, then the split

shouldn’t be made

– Marketable: If the feature isn’t marketable, there is little reason to keep it

– Feature: A feature is demonstrable behavior of the product, avoid confusing them with items that are necessary

to implement a feature

For more information: http://www.upstarthq.com/2010/04/introduction-to-minimum-marketable-

features-mmf/

Product Lifecycle (RUP)

• A Product Lifecycle from RUP’s perspective consists of the following phases in order:

1. Inception

2. Elaboration

3. Construction

4. Transition

• Different workflows falls under one or more of the above phases more often than others. For

example, throughout a product’s lifecycle, Business Modeling happens mostly in the Inception

phase, and dies off towards the transition stage.

For more information: http://www.ibm.com/developerworks/rational/library/sep05/rose/index.html

Architectural Baseline

• The architecture baseline is a subset of the entire system. The baseline has versions of all the

models that the full-fledged system has at the end of the project, including the same skeleton of

subsystems, components, and nodes, but not all the musculature. However, they do have behavior,

and they are executable code. The architecture baseline evolves to become the full-fledged system,

perhaps with some minor changes to the structure and behavior but the changes are minor because,

at the end of the elaboration or architectural iterations, we have by definition a stable architecture.

The architectural baseline should be designed and built early to mitigate technical risk and prove the

architecture.

For more information: http://www.informit.com/articles/article.aspx?p=375542&seqNum=3

Test-Driven Development (TDD)

• TDD is a development methodology that practices writing test cases before development, which

would then drive the development of a class or piece of code. Tests are written first by the developer

before any system code and the developers follows a red, green, refactor based development

process. TDD is a different mind-set. It is the ‘tests’ that ‘drive’ the ‘development’, not the other way

around. By writing a test case for a scenario, your test either dictates your implementation or gives

you some good pointers. TDD uses small, fine-grained steps to gradually increase developer

confidence, which results in larger steps downstream.

For more information: http://www.methodsandtools.com/archive/archive.php?id=20

Acceptance Test Driven Plans

• Acceptance Test-Driven Planning is an extension of Extreme Programming Planning. During

planning, the team defines acceptance tests for every work item in each iteration to drive the work

that developers must develop. The planning process is supposed to take up about 10% of the time

while the development effort takes 90%. It involves the following steps:

1. Getting the story straight

2. Show and tell

3. Retrospective

4. (optional) Technical Retrospective

5. Iteration Planning Workshop

6. (optional) Big, up-front thinking

7. Cutting the iteration

For more information: http://www.vietnamesetestingboard.org/zbxe/?document_srl=276643

Acceptance Test Driven Development

• Acceptance Test Driven Development (ATDD) is a practice in which the entire team collaboratively

discusses acceptance criteria and uses real world examples to formulate a set of concrete acceptance

tests before development begins. By doing ATDD, the team is able to gain a shared understanding

of what is being developed and when it would be considered as done.

For more information: http://en.wikipedia.org/wiki/Test-driven_development

Stubbing Dependencies

• Stubbing dependencies is a practice of developing stubs of external systems to support continued

development and enable automated builds independent of external systems. Stubs are fast to

develop, ensuring that what’s needed can be completed with having to get the exact details correct

before completion of a task, such as a successful build for example.

For more information: http://blog.springsource.com/2007/01/15/unit-testing-with-stubs-and-mocks/

Architectural POC

• Architectural proof-of-concepts are development efforts based on design that is created to learn by

doing and test the feasibility of uncertain architectural options.

For more information: http://msdn.microsoft.com/en-us/library/cc168618.aspx