SlideShare a Scribd company logo
1 of 220
Download to read offline
Dependency-Oriented Thinking
Session 1 – Inculcating Dependency-Oriented
Thinking

(C) Ganesh Prasad, Eigner Pty Ltd
Agenda
●

Introduction – Presenter bio, Participants'
backgrounds

●

Prior experiences with SOA

●

Expectations from this workshop

●

Case studies (interactive)

●

Notation (UML) for inter-system dependencies

●

●

Surrogate principles and why they don't always
apply
Exercises (interactive)
(C) Ganesh Prasad, Eigner Pty Ltd
SOA is not just Technology
●

●

Technology is the implementation of business intent
A lot of analysis and design is required before business intent can be
implemented

(C) Ganesh Prasad, Eigner Pty Ltd
How did SOA get to be seen as Technology?
●

“Service” is a weasel word

(C) Ganesh Prasad, Eigner Pty Ltd
Understanding the term “dependency”
●

Not a fancy technical term; just a regular English word

●

We can represent it using a formal notation

(C) Ganesh Prasad, Eigner Pty Ltd
Why are dependencies important?
●

A system with a large number of interconnections (dependencies)

●

Some of the dependencies are not even obvious

●

Now move the orange block without disturbing any of the others

●

How confident are you?

(C) Ganesh Prasad, Eigner Pty Ltd
The impact of reducing dependencies
●

A system with far fewer interconnections (dependencies)

●

No dependencies are unknown or hidden

●

How confident are you of making changes without breaking anything?

●

How fast can you move the block?

●

How much do you need to plan for the move?

(C) Ganesh Prasad, Eigner Pty Ltd
The trap of surrogate principles
●

“Point-to-point connections considered harmful” considered harmful

(C) Ganesh Prasad, Eigner Pty Ltd
The converse trap
●

Mediated connections considered harmful

(C) Ganesh Prasad, Eigner Pty Ltd
Logical mediation
●

A “point-to-point” connection can in fact be mediated

(C) Ganesh Prasad, Eigner Pty Ltd
Dependency view
●

The dependency view of a true point-to-point connection

(C) Ganesh Prasad, Eigner Pty Ltd
Dependency view
●

The dependency view of a mediated “point-to-point” connection

(C) Ganesh Prasad, Eigner Pty Ltd
Logical tight coupling
●

A “mediated” connection may in fact be tightly coupled

(C) Ganesh Prasad, Eigner Pty Ltd
Dependency view
●

The dependency view of a tightly coupled mediated system

(C) Ganesh Prasad, Eigner Pty Ltd
Reducing dependencies – the Linux way
●

Linux uses the Unix mechanism of symbolic links to abstract changes

(C) Ganesh Prasad, Eigner Pty Ltd
Dependency-Oriented Thinking
Session 2 – Dependency-Oriented Thinking as a
Formal Approach

(C) Ganesh Prasad, Eigner Pty Ltd
Agenda
●

The BAIT Model of the enterprise

●

Entities and Relationships in the TOGAF Model

●

The core elements applicable to Analysis and
Design (Design Artifacts)

●

Dependency Principles

●

The Method

(C) Ganesh Prasad, Eigner Pty Ltd
A Few Words on BAIT

(C) Ganesh Prasad, Eigner Pty Ltd
How should an architect view “applications”?
●

●

The literal view of systems does not provide architectural insights
The Application layer of BAIT is to be viewed functionally, not
physically

(C) Ganesh Prasad, Eigner Pty Ltd
The Layered view of Applications
●

●

The correct way to see the Application layer is as logical groupings of
business capabilities
Physical systems (hardware and software) are Technology layer
entities used to implement these capabilities

(C) Ganesh Prasad, Eigner Pty Ltd
Interdependencies between BAIT layers
●

The Application and Information layers always go hand in hand

(C) Ganesh Prasad, Eigner Pty Ltd
BAIT as a “Four I” model of SOA
●

Intent – what is to be done

●

Internal Cohesion – how functions hang together

●

Interfaces and Integration – how functions interoperate

●

Implementation – what the tangible, working system looks like

(C) Ganesh Prasad, Eigner Pty Ltd
BAIT and “Operation-Oriented Architecture”
●

Operations are the fundamental building blocks of an enterprise

●

Determine operations (the steps of business processes)

●

Group related operations together (based on internals and interfaces)

●

Expose operations to external consumers

●

Execute operations, either alone or in combination with others

(C) Ganesh Prasad, Eigner Pty Ltd
BAIT versus TOGAF
●
●

●

●
●

BAIT is only a framework
It shows how to view an enterprise but doesn't
show what comprises each layer
We need a model that is based on BAIT to
define a generic set of entities at each layer
A good model to use is TOGAF
TOGAF is based on industry experience and
practice, and is comprehensive yet generic
(C) Ganesh Prasad, Eigner Pty Ltd
TOGAF as a well-known set of dependencies
●

●

TOGAF's vocabulary includes “viewpoints”, which are subsets of the
entities that make up the model of an enterprise
We can mine this rich set of data to search for dependency
relationships

(C) Ganesh Prasad, Eigner Pty Ltd
Enterprise-Level Entities and Relationships

(C) Ganesh Prasad, Eigner Pty Ltd
Business Layer Entities and Relationships

(C) Ganesh Prasad, Eigner Pty Ltd
Business Layer Design Artifacts
●

Not all Business Layer entities are important to an analyst or designer

(C) Ganesh Prasad, Eigner Pty Ltd
Application Layer Entities and Relationships

(C) Ganesh Prasad, Eigner Pty Ltd
A Detailed Look at “Applications”

(C) Ganesh Prasad, Eigner Pty Ltd
Application Layer Design Artifacts
●

Note the two types of “applications” formed by grouping Operations in
two different ways

(C) Ganesh Prasad, Eigner Pty Ltd
Information Layer Entities and Relationships

(C) Ganesh Prasad, Eigner Pty Ltd
Information Layer Design Artifacts

(C) Ganesh Prasad, Eigner Pty Ltd
Technology Layer Entities and Relationships

(C) Ganesh Prasad, Eigner Pty Ltd
Technology Layer Design Artifacts

(C) Ganesh Prasad, Eigner Pty Ltd
Design Artifacts by BAIT Layer

(C) Ganesh Prasad, Eigner Pty Ltd
Dependency Principles by BAIT Layer

(C) Ganesh Prasad, Eigner Pty Ltd
The Formal Dependency-Oriented Method
●

●

Starting at the Business layer, identify the Key Design Artifacts and
apply Dependency Principles to arrive at an optimal design
Rinse and repeat at the next lower level

(C) Ganesh Prasad, Eigner Pty Ltd
Dependency-Oriented Thinking
Session 3 – The Business Layer

(C) Ganesh Prasad, Eigner Pty Ltd
Agenda
●

Business Intent

●

The Chain from Vision to Process Step

●

Traceability and Minimalism

●

The role of Domain Insight

●

Dealing with changing requirements (intent
versus detail)

(C) Ganesh Prasad, Eigner Pty Ltd
Business Layer Design Artifacts

(C) Ganesh Prasad, Eigner Pty Ltd
Vision and Mission
●

Vision – your idea of Utopia

●

Mission – your role in bringing about that Utopia

●

Together referred to as “Goal” in TOGAF

(C) Ganesh Prasad, Eigner Pty Ltd
The hidden role of Strategy
●

Strategy shapes organisations

●

The same Mission may be accomplished in different ways

(C) Ganesh Prasad, Eigner Pty Ltd
Business Functions are largely Stable
●

●

Changes in Strategy tend to impact Business Processes, but
curiously, need not impact Business Functions once established
Changes in Business Function are known as “restructures”

(C) Ganesh Prasad, Eigner Pty Ltd
Function, Process and Process Step
●

Function is both Structure and mini-Mission

●

Processes are what Functions “do”

●

Processes are composed of Steps (which may
or may not be reusable)

(C) Ganesh Prasad, Eigner Pty Ltd
The Traceability Principle
●

Think of Traceability as a chain of “existential dependencies”

●

It's a discipline that makes a business “lean and mean”

(C) Ganesh Prasad, Eigner Pty Ltd
The Minimalism Principle
●

“The simplest way to get a job done”

●

A discipline that leads to agility

(C) Ganesh Prasad, Eigner Pty Ltd
Domain Insight
●

Helps in applying the Traceability and Minimalism
principles

●

More Art than Science

●

Think of examples from your own organisation

(C) Ganesh Prasad, Eigner Pty Ltd
Changing Requirements
●

Intent versus Detail

(C) Ganesh Prasad, Eigner Pty Ltd
Dependency-Oriented Thinking
Session 4 – Process Design

(C) Ganesh Prasad, Eigner Pty Ltd
Agenda
●
●

●
●

The generic business process
Human workflow and asynchronous process
steps
Orchestration and Choreography
"Orchestrable" and "Choreographable"
Operations

(C) Ganesh Prasad, Eigner Pty Ltd
The Crucial Design Step between Process
and Process Step
●

How should Process Steps be coordinated into a Process?

●

Design Exercise

(C) Ganesh Prasad, Eigner Pty Ltd
Top-Down Design of the Business Layer

(C) Ganesh Prasad, Eigner Pty Ltd
Orchestrated Processes
●

The dependency relationships in an orchestrated process mirror the
flow of control

(C) Ganesh Prasad, Eigner Pty Ltd
Choreographed Processes
●

The dependency relationships bear no resemblance to the flow of
control

(C) Ganesh Prasad, Eigner Pty Ltd
A Simple Business Process
●

An Event Trigger followed by one or more Process Steps

(C) Ganesh Prasad, Eigner Pty Ltd
A Generic Business Process
●

A generic process does not run to completion in one go

●

It may pause, and resume based on intermediate event triggers

(C) Ganesh Prasad, Eigner Pty Ltd
“Non-blocking” Processes and Callback
●

●

It's often efficient for a paused process to do something else instead
of idly waiting for an event trigger
This model enables the design of long-running processes

(C) Ganesh Prasad, Eigner Pty Ltd
Human workflow as a long-running process
●

●

Non-blocking process design can be used to design human workflow
Pause and Resume junctures occur wherever human interaction is
required

(C) Ganesh Prasad, Eigner Pty Ltd
Dependencies in Orchestrable and
Choreographable Operations
●

Recall the different graphs for dependency versus flow of control

●

The dependencies are similar, just in different places

(C) Ganesh Prasad, Eigner Pty Ltd
The Overhyped Notion of “Reuse”
●
●

Reuse is not a first-class benefit
It's unreasonable to expect reuse from a SOA
initiative if the process steps of a business are
not inherently reusable

(C) Ganesh Prasad, Eigner Pty Ltd
The potential for reuse is first seen at the
Business layer

(C) Ganesh Prasad, Eigner Pty Ltd
Lower layers should confirm if reuse is in
fact possible

(C) Ganesh Prasad, Eigner Pty Ltd
Dependency-Oriented Thinking
Session 5 – The Application Layer

(C) Ganesh Prasad, Eigner Pty Ltd
Agenda
●
●

●

What is an "Application"?
The principles of High Cohesion and
Decoupling of Internals from Interfaces
"Goldilocks" Signatures (Stability versus
Precision of Interfaces)

●

Variants, Versions and dealing with change

●

Shared Semantics for effective Choreography

(C) Ganesh Prasad, Eigner Pty Ltd
Application Layer Design Artifacts
●

Process Steps at the Business layer map to Operations at the
Application layer

(C) Ganesh Prasad, Eigner Pty Ltd
Application Layer vs Technology Layer
●

The Technology layer provides a detailed “street view”

●

The Application layer provides a high-level “map view”

(C) Ganesh Prasad, Eigner Pty Ltd
The Relationship between Design Artifacts
at the Application and Information Layers
●

Products are defined by a shared Internal Data Model

●

Services are defined by a shared Interface Data Model

(C) Ganesh Prasad, Eigner Pty Ltd
The Cohesion and Coupling Principles
●

At each layer, there is an internal focus (Cohesion) and an external
focus (Coupling)

(C) Ganesh Prasad, Eigner Pty Ltd
Cohesion Exercise 1

(C) Ganesh Prasad, Eigner Pty Ltd
(C) Ganesh Prasad, Eigner Pty Ltd
(C) Ganesh Prasad, Eigner Pty Ltd
Cohesion Exercise 2

(C) Ganesh Prasad, Eigner Pty Ltd
(C) Ganesh Prasad, Eigner Pty Ltd
(C) Ganesh Prasad, Eigner Pty Ltd
(C) Ganesh Prasad, Eigner Pty Ltd
Cohesion Exercise 3

(C) Ganesh Prasad, Eigner Pty Ltd
(C) Ganesh Prasad, Eigner Pty Ltd
(C) Ganesh Prasad, Eigner Pty Ltd
Simultaneous Groupings
●

It is possible to group entities in more than one way at the same time

(C) Ganesh Prasad, Eigner Pty Ltd
Simultaneous Grouping of Operations
●

A dynamic grouping of Operations is a Process

●

A static grouping of Operations is an Application (Product or Service)

(C) Ganesh Prasad, Eigner Pty Ltd
Anatomy of a Product
●

Grouping by internals is the design principle

●

External access is “canned” through a relatively rigid native interface

(C) Ganesh Prasad, Eigner Pty Ltd
Anatomy of a Service
●

Grouping by Interfaces is the design principle

●

External access is the very raison d'être!

(C) Ganesh Prasad, Eigner Pty Ltd
SOFEA – Architecture for Front-ends
●

For the best of both worlds, build user interfaces on top of services

(C) Ganesh Prasad, Eigner Pty Ltd
Demystifying Versioning
●

Variants and Versions

●

Interfaces and Internals

●

(C) Ganesh Prasad, Eigner Pty Ltd
Variants
●

A Variant is an operation “flavour” that may coexist with other flavours
without deprecating them

(C) Ganesh Prasad, Eigner Pty Ltd
Versions
●

There is always a latest Version that deprecates earlier ones

(C) Ganesh Prasad, Eigner Pty Ltd
Interfaces as Abstractions of Operations
●

An Interface represents the Business Intent of an Operation

●

Details are taken care of by implementation variants (“internals”)

(C) Ganesh Prasad, Eigner Pty Ltd
The Impact of Changing Interfaces
●

Consumers of operations have a dependency on the interface

●

Changes to operations may impact consumers to different degrees

(C) Ganesh Prasad, Eigner Pty Ltd
Impacts classified by Version Type
●

Versions can be thought of as “x.y.z”

●

The only criterion for classification is the level of impact from a change

●

A term like “bug fix version” makes no sense from a dependency perspective

(C) Ganesh Prasad, Eigner Pty Ltd
Changes to Internals
●

A change to the internal logic of an operation with no visibility at the
interface changes only the implementation version, not the minor or
major versions

(C) Ganesh Prasad, Eigner Pty Ltd
“Minor” Changes to Interfaces
●

●

●

Some kinds of changes to operations are visible at the interface, but
do not impact consumers in a practical sense
They only change the minor version number
Minor version changes are “backward compatible” (continue to
support older consumers while supporting new ones)

(C) Ganesh Prasad, Eigner Pty Ltd
Types of changes that do not break an
interface
●

Interfaces that become more lenient tend not to impact consumers

(C) Ganesh Prasad, Eigner Pty Ltd
Major Changes to Interfaces
●

A change to an operation that is not only visible at the interface but
also forces a change to the consumer is a change to the major
version number

(C) Ganesh Prasad, Eigner Pty Ltd
Types of changes that break an interface
●

An interface that becomes stricter or more restrictive tends to impact
consumers

(C) Ganesh Prasad, Eigner Pty Ltd
Version Mapping Convention
●

●

Exploit the dependency level expressed by the “x.y.z” version numbering
scheme
The minor version number should always refer to the latest
implementation version

(C) Ganesh Prasad, Eigner Pty Ltd
Version Mapping Convention, cont'd
●

The major version number should always map to the latest minor
version

(C) Ganesh Prasad, Eigner Pty Ltd
Version Routing Exercise
●

Which implementation version will be executed by this call?

(C) Ganesh Prasad, Eigner Pty Ltd
Solution
●

Thumb rule – It's always the latest version at the lower level

(C) Ganesh Prasad, Eigner Pty Ltd
(C) Ganesh Prasad, Eigner Pty Ltd
(C) Ganesh Prasad, Eigner Pty Ltd
The “Minor Version Lockstep Dependency”
●

When dealing with multiple variants, changes to the minor version
number of one variant will require corresponding changes to the
minor version numbers of all the other variants!

(C) Ganesh Prasad, Eigner Pty Ltd
The “Goldilocks Signature” Principle
●

A balance is required between the stability and the precision of an
operation's interface

(C) Ganesh Prasad, Eigner Pty Ltd
What is a “Well-Designed” Interface?
●

Well-designed interfaces are stable in the face of change

●

i.e., they do not create unnecessary dependencies

(C) Ganesh Prasad, Eigner Pty Ltd
Why the scheme works

(C) Ganesh Prasad, Eigner Pty Ltd
Managing Breaking Changes

(C) Ganesh Prasad, Eigner Pty Ltd
Managing Breaking Changes, cont'd

(C) Ganesh Prasad, Eigner Pty Ltd
Managing Non-Breaking Changes

(C) Ganesh Prasad, Eigner Pty Ltd
Dependency-Oriented Thinking
Session 6 – The Information Layer

(C) Ganesh Prasad, Eigner Pty Ltd
Agenda
●

"Data on the Outside versus Data on the
Inside"

●

Elements of Low Coupling

●

Type Hierarchy and Interface Abstraction

●

Identity Association

●

Context versus Content

(C) Ganesh Prasad, Eigner Pty Ltd
Information Layer Design Artifacts
●

●

Only two major categories – “Data on the Outside” and “Data on the
Inside”
Deceptively simple!

(C) Ganesh Prasad, Eigner Pty Ltd
Variants from a Data Perspective
●

●

A single abstract interface can map to multiple concrete
implementation variants
But the -------- ------ remains the same

(C) Ganesh Prasad, Eigner Pty Ltd
The Notion of “Context”
●

“Context” is a way of formalising aspects of an operation that are not
core to its business intent

(C) Ganesh Prasad, Eigner Pty Ltd
Low Coupling, or “Need to Know”
●

A form of minimalism applied to data

(C) Ganesh Prasad, Eigner Pty Ltd
Decoupling of Internal Data from Interface Data
●

To be decoupled, interface and internal data models cannot have
dependencies on each other

(C) Ganesh Prasad, Eigner Pty Ltd
The Domain-Specific Data Dictionary
●

Efficiencies are still possible!

●

The internal and interface data models do talk about similar entities

(C) Ganesh Prasad, Eigner Pty Ltd
What a Data Dictionary Looks Like
●

Entities and Value Objects are defined here

(C) Ganesh Prasad, Eigner Pty Ltd
Types and Instances
●

Both internal and interface data models define instances of types

●

Types common to both should be in the common data dictionary

(C) Ganesh Prasad, Eigner Pty Ltd
Data Model Example
●

Internal and interface data models have some elements in common
and some elements that are unique to each

(C) Ganesh Prasad, Eigner Pty Ltd
The Relationship between
Interface/Internals and Type Hierarchy
●

This is why Application and Information layer design is done together!

(C) Ganesh Prasad, Eigner Pty Ltd
A Problem We Glossed Over!
●

●

●

●

●

Abstract interfaces are stable and shield consumers from many
internal changes, but...
How does a consumer know which concrete data elements to send
and receive?
The answer becomes clear if we jettison a fallacy of SOA – that a
formal “interface contract” is sufficient for a consumer to begin
transacting with an operation
In practice, designers of consuming applications always discuss with
the designers of operations and negotiate data exchange
Use this knowledge to design pragmatic design processes

(C) Ganesh Prasad, Eigner Pty Ltd
Building an abstract interface to an existing
implementation

(C) Ganesh Prasad, Eigner Pty Ltd
When a new consumer is supported by an
existing variant

(C) Ganesh Prasad, Eigner Pty Ltd
When a new consumer is not supported by
an existing variant

(C) Ganesh Prasad, Eigner Pty Ltd
The Internal Data Model
●

Deals with Entities rather than Value objects

(C) Ganesh Prasad, Eigner Pty Ltd
The Interface Data Model
●

Never references Entities! (That would be tight coupling)

●

Value objects are packaged into messages that are exchanged

●

Value objects can also be called “representations”

(C) Ganesh Prasad, Eigner Pty Ltd
The Identity Association Principle
●

A common design error

(C) Ganesh Prasad, Eigner Pty Ltd
How Identity Association Works
●

Consumers must not develop dependencies on internal data entities

(C) Ganesh Prasad, Eigner Pty Ltd
Revisiting the Goldilocks Signature Principle
●

Think about stability and precision afresh from the viewpoint of data

(C) Ganesh Prasad, Eigner Pty Ltd
Message Data Model
●

The Goldilocks Signature principle is supported by this model

(C) Ganesh Prasad, Eigner Pty Ltd
A Terrible Way to Implement Extensible
Interfaces
●

Extensions gradually destroy structure and meaning

(C) Ganesh Prasad, Eigner Pty Ltd
Extensibility with Control
●

Setting up a Type Hierarchy supports change gracefully

(C) Ganesh Prasad, Eigner Pty Ltd
Isolation of Context from Content
●

Keep extraneous considerations separate from the core business
intent

(C) Ganesh Prasad, Eigner Pty Ltd
The Context Type Hierarchy
●

Context has its own hierarchy with a single, optional base type called
“Context Type”

(C) Ganesh Prasad, Eigner Pty Ltd
Supporting New Variants that Differ only in
Context
●

Building in an optional context element into every interface is
insurance against breaking change

(C) Ganesh Prasad, Eigner Pty Ltd
Context of Output Data
●

●

Context of input data is used to determine appropriate variants to
invoke
Context of output data can support choreographable operations

(C) Ganesh Prasad, Eigner Pty Ltd
Service Content and Process Context
●

When considering a single operation, some data elements may be
considered content rather than context (i.e., they follow from the
business intent)

(C) Ganesh Prasad, Eigner Pty Ltd
Modelling Service Content as Context
●

Sometimes, a process may have operations with common content

●

This content could be considered to be their common context

(C) Ganesh Prasad, Eigner Pty Ltd
Context By Reference
●

●

Operations sharing “content context” with other operations can then deal
with references to common data
These reference IDs are a form of context that is common to the process

(C) Ganesh Prasad, Eigner Pty Ltd
Context By Reference, cont'd
●

Subsequent operations refer to common content through the context
ID

(C) Ganesh Prasad, Eigner Pty Ltd
Example – Bringing Application and Data
Layer Principles Together

(C) Ganesh Prasad, Eigner Pty Ltd
The Type Hierarchy supporting Late Binding

(C) Ganesh Prasad, Eigner Pty Ltd
“Schema Validation”

(C) Ganesh Prasad, Eigner Pty Ltd
Routing/Binding from Interface to
Implementation

(C) Ganesh Prasad, Eigner Pty Ltd
Dependency-Oriented Thinking
Session 7 – The Technology Layer

(C) Ganesh Prasad, Eigner Pty Ltd
Agenda
●
●

●

●

●

Standards, Bundling and Tooling
Standards and Standards Families - SOAP and
REST
Bundling - Data, Logic, Physical Components
and their association
Tooling - the core and supporting components
of a distributed solution
Implementing a logical design
(C) Ganesh Prasad, Eigner Pty Ltd
Technology Layer – The Design of
Implementation
●

Not implementation itself, but the design of implementation

(C) Ganesh Prasad, Eigner Pty Ltd
Technology Layer Design Artifacts
●

At the most abstract level, Technology consists of three elements

●

They are Standards, Tooling and Bundling

(C) Ganesh Prasad, Eigner Pty Ltd
Bundling Decisions
●

“Where to place what” is a bundling decision

(C) Ganesh Prasad, Eigner Pty Ltd
Logic Bundling Principle
●

This is a variant of the Cohesion principle – what belongs together
must go together

(C) Ganesh Prasad, Eigner Pty Ltd
The State or “Stickiness” Principle
●

●

Placing logic on one physical component as opposed to another could
be the difference between a stateless and a stateful system
Stateless systems have significant architectural advantages on
account of their reduced bundling dependencies (scalability, failure
recovery)

(C) Ganesh Prasad, Eigner Pty Ltd
Topology “Hotspots”
●

●

The way physical components are connected or “wired” together can
create bundling dependencies of another kind
Performance bottlenecks and single points of failure are common results
of topology-related bundling decisions

(C) Ganesh Prasad, Eigner Pty Ltd
Reference Architecture of a Deployable
Application

(C) Ganesh Prasad, Eigner Pty Ltd
Determining Standards for Orchestrable
Operations

(C) Ganesh Prasad, Eigner Pty Ltd
Determining Standards for Choreographable
Operations

(C) Ganesh Prasad, Eigner Pty Ltd
Determining Tooling Components

(C) Ganesh Prasad, Eigner Pty Ltd
Determining Deployment Bundles

(C) Ganesh Prasad, Eigner Pty Ltd
Determining Description Bundles

(C) Ganesh Prasad, Eigner Pty Ltd
The Service Provider

(C) Ganesh Prasad, Eigner Pty Ltd
The Service Consumer

(C) Ganesh Prasad, Eigner Pty Ltd
Legacy Systems

(C) Ganesh Prasad, Eigner Pty Ltd
Functional Symbols for Tooling
●

From Gregor Hohpe's “Enterprise Integration Patterns”

(C) Ganesh Prasad, Eigner Pty Ltd
Additional Symbol for Tooling
●

Internal logic has no symbol in “Enterprise Integration Patterns”

●

We have to “roll our own”!

(C) Ganesh Prasad, Eigner Pty Ltd
The Core Technology Layer Components
●

Service Container

●

Broker

●

Process Coordinator

(C) Ganesh Prasad, Eigner Pty Ltd
Service Container
●

Implements Business Logic and exposes it

(C) Ganesh Prasad, Eigner Pty Ltd
How a Service Container is Used
●

The logic implemented by the Service Container and exposed as an
operation is consumed by a service consumer

(C) Ganesh Prasad, Eigner Pty Ltd
Broker
●

Mediates access to existing logic

(C) Ganesh Prasad, Eigner Pty Ltd
How a Broker is Used
●

●

●

The special protocols and interfaces of legacy systems are hidden
through “adapters”
Data formats are converted through “transformer” logic
Physical locations are hidden and variants are abstracted through
“mediator” logic

(C) Ganesh Prasad, Eigner Pty Ltd
Process Coordinator
●

Combines existing operations into business processes

●

More relevant for orchestrable operations

(C) Ganesh Prasad, Eigner Pty Ltd
How a Process Coordinator is Used
●

The Process Coordinator runs stateful process logic (orchestration)

●

It invokes operations as required

●

The operations themselves are stateless

(C) Ganesh Prasad, Eigner Pty Ltd
The Components Working Together
●

The three core technology components are designed to work together

(C) Ganesh Prasad, Eigner Pty Ltd
Broker Design Error 1
●

Topology Hotspot – the Broker is not meant to be a centralised
component

(C) Ganesh Prasad, Eigner Pty Ltd
Broker Design Error 2
●

Always use the right tool for the job

●

The Broker is a mediator

●

Do not use the Broker as a Service Container

●

Do not use the Broker as a Process Coordinator

(C) Ganesh Prasad, Eigner Pty Ltd
Dependencies introduced by SOAP
●

Static Description dependency

●

Bundling dependency

●

Synchronisation dependency

(C) Ganesh Prasad, Eigner Pty Ltd
Dependencies introduced by REST
●

Semantic dependency

●

Synchronisation dependency

(C) Ganesh Prasad, Eigner Pty Ltd
What is a “Semantic Dependency”?
●

The requirement for a system to resolve ambiguity

(C) Ganesh Prasad, Eigner Pty Ltd
The Problem with WSDL
●

WSDL is a static description of a group of operations

●

Three dependencies arise from this design

(C) Ganesh Prasad, Eigner Pty Ltd
The WSDL Dependency Multiplied
●

A popular service can have many consumers that are then dependent
on its interface contract

(C) Ganesh Prasad, Eigner Pty Ltd
Cascading Impacts of Change
●

WSDL is a dependency hotspot

(C) Ganesh Prasad, Eigner Pty Ltd
Calculating the Brittleness of WSDL
●

●

A WSDL file describes exactly 1 service consisting of 5 operations, each
with an input and an output document
If any given document has a 10% probability of changing, what is the
probability of the WSDL file changing?

(C) Ganesh Prasad, Eigner Pty Ltd
Strategies to minimise change
●

Dependency principles can be applied to minimise the effects of
change due to the WSDL dependency hotspot

(C) Ganesh Prasad, Eigner Pty Ltd
Dependencies arising from REST's
Hypermedia Constraints
●

●

There is no static description of operations in REST (WADL is not
RESTian)
There are still 3 dependencies

(C) Ganesh Prasad, Eigner Pty Ltd
Miscellaneous Technology Layer
Considerations

(C) Ganesh Prasad, Eigner Pty Ltd
The “Canonical Data Model” Fallacy
●

A Canonical Data Model could be too heavyweight and rigid

(C) Ganesh Prasad, Eigner Pty Ltd
Domain Data Models
●

Domain Data Models are more flexible and federation-friendly

(C) Ganesh Prasad, Eigner Pty Ltd
“The SOA Ecosystem”
●

The logical view of service providers and consumers

(C) Ganesh Prasad, Eigner Pty Ltd
Processes as Service Consumers
●

Processes are a special type of service consumer

(C) Ganesh Prasad, Eigner Pty Ltd
Processes as Operations
●

●

A process abstracts coarse-grained logic
This coarse-grained logic may in turn be invoked by a service
consumer

(C) Ganesh Prasad, Eigner Pty Ltd
Processes in the SOA Ecosystem
●

A process is both a service provider and a service consumer

(C) Ganesh Prasad, Eigner Pty Ltd
Operation Signatures implemented in SOAP
and REST

(C) Ganesh Prasad, Eigner Pty Ltd
Dependency-Oriented Thinking
Session 8 – Worked-Out Examples

(C) Ganesh Prasad, Eigner Pty Ltd
Agenda
●

●

Option 1: Detailed analysis of participants' own
design problems
Option 2: Canned case studies:
●

●

●

●

Conducting a post-mortem based on dependency
principles
Designing a system based on an orchestrated business
process
Designing a system based on a choreographed
business process
Designing an interface data model to cater to change
(Type Hierarchy and Goldilocks Signatures)
(C) Ganesh Prasad, Eigner Pty Ltd
Post-Mortem Example

(C) Ganesh Prasad, Eigner Pty Ltd
Exercise – Post-Mortem
●

What is wrong with this design?

(C) Ganesh Prasad, Eigner Pty Ltd
A More Flexible Design

(C) Ganesh Prasad, Eigner Pty Ltd
Synchronous Orchestrated Process

(C) Ganesh Prasad, Eigner Pty Ltd
Banking Application Sequence Diagram

(C) Ganesh Prasad, Eigner Pty Ltd
Processes, Services and Operations
●

Dynamic grouping of operations into a single process “Open Account”

●

Static grouping of operations into 3 services

(C) Ganesh Prasad, Eigner Pty Ltd
High-Level Solution Diagram – Banking

(C) Ganesh Prasad, Eigner Pty Ltd
Asynchronous Orchestrated
Process

(C) Ganesh Prasad, Eigner Pty Ltd
Insurance Application Sequence Diagram

(C) Ganesh Prasad, Eigner Pty Ltd
Processes, Services and Operations
●

Two dynamic groupings (processes): Get Quote and Purchase Policy

●

6 static groupings (services)

(C) Ganesh Prasad, Eigner Pty Ltd
High-Level Solution Diagram – Insurance

(C) Ganesh Prasad, Eigner Pty Ltd
Choreographed Process

(C) Ganesh Prasad, Eigner Pty Ltd
A Maze Game

(C) Ganesh Prasad, Eigner Pty Ltd
Allowed Movements

(C) Ganesh Prasad, Eigner Pty Ltd
Cell Identifiers – Identity Association
●

A cell's location must not be derivable from its name or vice-versa

(C) Ganesh Prasad, Eigner Pty Ltd
The Design – Hypermedia Constraints

(C) Ganesh Prasad, Eigner Pty Ltd
Interaction at the start of the game

(C) Ganesh Prasad, Eigner Pty Ltd
Interaction in the middle of the game

(C) Ganesh Prasad, Eigner Pty Ltd
Interaction at the end of the game

(C) Ganesh Prasad, Eigner Pty Ltd
Managing Change

(C) Ganesh Prasad, Eigner Pty Ltd
The 70s
●

Banking in a simpler (and more rigid) time

(C) Ganesh Prasad, Eigner Pty Ltd
Service Interfaces to Support Arbitrary
Clients

(C) Ganesh Prasad, Eigner Pty Ltd
Variants of Similar Operations

(C) Ganesh Prasad, Eigner Pty Ltd
Standardised Variants, Abstract Interfaces

(C) Ganesh Prasad, Eigner Pty Ltd
Processes as Standardised Operation Variants

(C) Ganesh Prasad, Eigner Pty Ltd
Supporting a New Variant

(C) Ganesh Prasad, Eigner Pty Ltd
Deployment of Components

(C) Ganesh Prasad, Eigner Pty Ltd
A More Likely Scenario!

(C) Ganesh Prasad, Eigner Pty Ltd

More Related Content

What's hot

Business Analyst Online training in hyderabad, India, USA, UK, Australia, sa...
Business Analyst Online training in hyderabad,  India, USA, UK, Australia, sa...Business Analyst Online training in hyderabad,  India, USA, UK, Australia, sa...
Business Analyst Online training in hyderabad, India, USA, UK, Australia, sa...United Global Soft
 
Business Analysis Knowledge Areas Big Picture
Business Analysis Knowledge Areas Big PictureBusiness Analysis Knowledge Areas Big Picture
Business Analysis Knowledge Areas Big PictureMostafa Hashkil
 
1000 BA Interview Questions FREE Edition
1000 BA Interview Questions   FREE Edition1000 BA Interview Questions   FREE Edition
1000 BA Interview Questions FREE EditionLN Mishra CBAP
 
Intro to agile business analysis
Intro to agile business analysisIntro to agile business analysis
Intro to agile business analysisSumit Mahajan
 
Project management presentation
Project management presentation Project management presentation
Project management presentation Essex James
 
How To Review Software Requirements
How To Review Software RequirementsHow To Review Software Requirements
How To Review Software RequirementsCraig Brown
 
CBAP+Master 150 Free Questions
CBAP+Master 150 Free QuestionsCBAP+Master 150 Free Questions
CBAP+Master 150 Free QuestionsCBAP Master
 
What are the Steps in an ERP Implementation ?
What are the Steps in an ERP Implementation ?What are the Steps in an ERP Implementation ?
What are the Steps in an ERP Implementation ?Raj Dhawan, CPA, MBA
 
Putting the Ready in Business Readiness
Putting the Ready in Business ReadinessPutting the Ready in Business Readiness
Putting the Ready in Business ReadinessDarren Nerland
 
MongoDB - Build, Adapt, Reduce, Improve
MongoDB - Build, Adapt, Reduce, ImproveMongoDB - Build, Adapt, Reduce, Improve
MongoDB - Build, Adapt, Reduce, ImproveDave Callaghan
 
Introduction to Business Analysis
Introduction to Business AnalysisIntroduction to Business Analysis
Introduction to Business AnalysisAMJAD SHAIKH
 
BABOK Chapter 2 - Business Analysis Planning and Monitoring
BABOK Chapter 2 - Business Analysis Planning and MonitoringBABOK Chapter 2 - Business Analysis Planning and Monitoring
BABOK Chapter 2 - Business Analysis Planning and MonitoringKathy Vezina
 
How easy it is to crack PMI-PBA with iZenBridge
How easy it is to crack PMI-PBA with iZenBridgeHow easy it is to crack PMI-PBA with iZenBridge
How easy it is to crack PMI-PBA with iZenBridgeAkanksha Ashar
 
Demystifying the Role of Product Owner
Demystifying the Role of Product OwnerDemystifying the Role of Product Owner
Demystifying the Role of Product OwnerTechWell
 
Business Analysis - Essentials
Business Analysis - EssentialsBusiness Analysis - Essentials
Business Analysis - EssentialsBarbara Bermes
 
The prince2 themes
The prince2 themesThe prince2 themes
The prince2 themesprojectingIT
 

What's hot (20)

Business Analyst Online training in hyderabad, India, USA, UK, Australia, sa...
Business Analyst Online training in hyderabad,  India, USA, UK, Australia, sa...Business Analyst Online training in hyderabad,  India, USA, UK, Australia, sa...
Business Analyst Online training in hyderabad, India, USA, UK, Australia, sa...
 
Business Analysis Knowledge Areas Big Picture
Business Analysis Knowledge Areas Big PictureBusiness Analysis Knowledge Areas Big Picture
Business Analysis Knowledge Areas Big Picture
 
1000 BA Interview Questions FREE Edition
1000 BA Interview Questions   FREE Edition1000 BA Interview Questions   FREE Edition
1000 BA Interview Questions FREE Edition
 
Intro to agile business analysis
Intro to agile business analysisIntro to agile business analysis
Intro to agile business analysis
 
Project management presentation
Project management presentation Project management presentation
Project management presentation
 
How To Review Software Requirements
How To Review Software RequirementsHow To Review Software Requirements
How To Review Software Requirements
 
Management techniques of the world by khawar nehal 4 august 2020-1
Management techniques of the world by khawar nehal   4 august 2020-1Management techniques of the world by khawar nehal   4 august 2020-1
Management techniques of the world by khawar nehal 4 august 2020-1
 
CBAP+Master 150 Free Questions
CBAP+Master 150 Free QuestionsCBAP+Master 150 Free Questions
CBAP+Master 150 Free Questions
 
What are the Steps in an ERP Implementation ?
What are the Steps in an ERP Implementation ?What are the Steps in an ERP Implementation ?
What are the Steps in an ERP Implementation ?
 
Putting the Ready in Business Readiness
Putting the Ready in Business ReadinessPutting the Ready in Business Readiness
Putting the Ready in Business Readiness
 
Enterprise Analysis
Enterprise AnalysisEnterprise Analysis
Enterprise Analysis
 
MongoDB - Build, Adapt, Reduce, Improve
MongoDB - Build, Adapt, Reduce, ImproveMongoDB - Build, Adapt, Reduce, Improve
MongoDB - Build, Adapt, Reduce, Improve
 
Introduction to Business Analysis
Introduction to Business AnalysisIntroduction to Business Analysis
Introduction to Business Analysis
 
BABOK Chapter 2 - Business Analysis Planning and Monitoring
BABOK Chapter 2 - Business Analysis Planning and MonitoringBABOK Chapter 2 - Business Analysis Planning and Monitoring
BABOK Chapter 2 - Business Analysis Planning and Monitoring
 
How easy it is to crack PMI-PBA with iZenBridge
How easy it is to crack PMI-PBA with iZenBridgeHow easy it is to crack PMI-PBA with iZenBridge
How easy it is to crack PMI-PBA with iZenBridge
 
Preparing for pmi ba exam
Preparing for pmi ba examPreparing for pmi ba exam
Preparing for pmi ba exam
 
Demystifying the Role of Product Owner
Demystifying the Role of Product OwnerDemystifying the Role of Product Owner
Demystifying the Role of Product Owner
 
Business Analysis - Essentials
Business Analysis - EssentialsBusiness Analysis - Essentials
Business Analysis - Essentials
 
The prince2 themes
The prince2 themesThe prince2 themes
The prince2 themes
 
Going Agile
Going  AgileGoing  Agile
Going Agile
 

Similar to Workshop Slides - Introduction to Dependency-Oriented Thinking" Feb 15, 2014, Sydney

Building Sustainable Software: An Introduction to Software Engineering
Building Sustainable Software: An Introduction to Software EngineeringBuilding Sustainable Software: An Introduction to Software Engineering
Building Sustainable Software: An Introduction to Software EngineeringMuhammad Shehata
 
Why Agile? Back to Basics.
Why Agile? Back to Basics.Why Agile? Back to Basics.
Why Agile? Back to Basics.Lucas Hendrich
 
Process Improvement for Operations vs Projects - What's the Difference? (NYBP...
Process Improvement for Operations vs Projects - What's the Difference? (NYBP...Process Improvement for Operations vs Projects - What's the Difference? (NYBP...
Process Improvement for Operations vs Projects - What's the Difference? (NYBP...Samuel Chin, PMP, CSM
 
Introduction to Project Management - PMP Workgroup
Introduction to Project Management - PMP WorkgroupIntroduction to Project Management - PMP Workgroup
Introduction to Project Management - PMP WorkgroupTùng Trần Thanh
 
Primavera Unifier: How to Tame Complexity and Achieve Success
Primavera Unifier: How to Tame Complexity and Achieve SuccessPrimavera Unifier: How to Tame Complexity and Achieve Success
Primavera Unifier: How to Tame Complexity and Achieve Successp6academy
 
Big data and other buzzwords
Big data and other buzzwordsBig data and other buzzwords
Big data and other buzzwordsAndrew Clark
 
FedEx_A7_eng_20070607_chs
FedEx_A7_eng_20070607_chsFedEx_A7_eng_20070607_chs
FedEx_A7_eng_20070607_chsJohn Suzanne
 
Introduction of business development practice "THRUSTER"
Introduction of business development practice "THRUSTER"Introduction of business development practice "THRUSTER"
Introduction of business development practice "THRUSTER"Growth Hack Studio Inc.
 
Project management - Basics for all
Project management - Basics for allProject management - Basics for all
Project management - Basics for allSurgyy Design
 
IT Planning and Budgeting Crash Course
IT Planning and Budgeting Crash CourseIT Planning and Budgeting Crash Course
IT Planning and Budgeting Crash CourseJason Samuels
 
How to Manage a Mixed Portfolio of Products by Salesforce PM
How to Manage a Mixed Portfolio of Products by Salesforce PMHow to Manage a Mixed Portfolio of Products by Salesforce PM
How to Manage a Mixed Portfolio of Products by Salesforce PMProduct School
 
Software Engineer's Career Management Toolkit
Software Engineer's Career Management ToolkitSoftware Engineer's Career Management Toolkit
Software Engineer's Career Management Toolkitozgengungor1
 
Managing software projects & teams effectively
Managing software projects & teams effectivelyManaging software projects & teams effectively
Managing software projects & teams effectivelyAshutosh Agarwal
 
The Principles of Effective P3 Governance - AXELOS Webinar
The Principles of Effective P3 Governance - AXELOS WebinarThe Principles of Effective P3 Governance - AXELOS Webinar
The Principles of Effective P3 Governance - AXELOS WebinarAXELOS Global Best Practice
 
he Principles of Effective Project, Programme and Portfolio Management Govern...
he Principles of Effective Project, Programme and Portfolio Management Govern...he Principles of Effective Project, Programme and Portfolio Management Govern...
he Principles of Effective Project, Programme and Portfolio Management Govern...AXELOS Global Best Practice
 
Aligning Feature Delivery with OKRs by Gtmhub CPO
Aligning Feature Delivery with OKRs by Gtmhub CPOAligning Feature Delivery with OKRs by Gtmhub CPO
Aligning Feature Delivery with OKRs by Gtmhub CPOProduct School
 

Similar to Workshop Slides - Introduction to Dependency-Oriented Thinking" Feb 15, 2014, Sydney (20)

Building Sustainable Software: An Introduction to Software Engineering
Building Sustainable Software: An Introduction to Software EngineeringBuilding Sustainable Software: An Introduction to Software Engineering
Building Sustainable Software: An Introduction to Software Engineering
 
Why Agile? Back to Basics.
Why Agile? Back to Basics.Why Agile? Back to Basics.
Why Agile? Back to Basics.
 
UI/UX Design in Agile process
UI/UX Design in Agile process  UI/UX Design in Agile process
UI/UX Design in Agile process
 
Module 1 - SE.pptx
Module 1 - SE.pptxModule 1 - SE.pptx
Module 1 - SE.pptx
 
Process Improvement for Operations vs Projects - What's the Difference? (NYBP...
Process Improvement for Operations vs Projects - What's the Difference? (NYBP...Process Improvement for Operations vs Projects - What's the Difference? (NYBP...
Process Improvement for Operations vs Projects - What's the Difference? (NYBP...
 
Introduction to Project Management - PMP Workgroup
Introduction to Project Management - PMP WorkgroupIntroduction to Project Management - PMP Workgroup
Introduction to Project Management - PMP Workgroup
 
Primavera Unifier: How to Tame Complexity and Achieve Success
Primavera Unifier: How to Tame Complexity and Achieve SuccessPrimavera Unifier: How to Tame Complexity and Achieve Success
Primavera Unifier: How to Tame Complexity and Achieve Success
 
Big data and other buzzwords
Big data and other buzzwordsBig data and other buzzwords
Big data and other buzzwords
 
FedEx_A7_eng_20070607_chs
FedEx_A7_eng_20070607_chsFedEx_A7_eng_20070607_chs
FedEx_A7_eng_20070607_chs
 
Introduction of business development practice "THRUSTER"
Introduction of business development practice "THRUSTER"Introduction of business development practice "THRUSTER"
Introduction of business development practice "THRUSTER"
 
Project management - Basics for all
Project management - Basics for allProject management - Basics for all
Project management - Basics for all
 
IT Planning and Budgeting Crash Course
IT Planning and Budgeting Crash CourseIT Planning and Budgeting Crash Course
IT Planning and Budgeting Crash Course
 
PROJECT WE LIKE
PROJECT WE LIKE PROJECT WE LIKE
PROJECT WE LIKE
 
How to Manage a Mixed Portfolio of Products by Salesforce PM
How to Manage a Mixed Portfolio of Products by Salesforce PMHow to Manage a Mixed Portfolio of Products by Salesforce PM
How to Manage a Mixed Portfolio of Products by Salesforce PM
 
Software Engineer's Career Management Toolkit
Software Engineer's Career Management ToolkitSoftware Engineer's Career Management Toolkit
Software Engineer's Career Management Toolkit
 
Managing software projects & teams effectively
Managing software projects & teams effectivelyManaging software projects & teams effectively
Managing software projects & teams effectively
 
The Principles of Effective P3 Governance - AXELOS Webinar
The Principles of Effective P3 Governance - AXELOS WebinarThe Principles of Effective P3 Governance - AXELOS Webinar
The Principles of Effective P3 Governance - AXELOS Webinar
 
he Principles of Effective Project, Programme and Portfolio Management Govern...
he Principles of Effective Project, Programme and Portfolio Management Govern...he Principles of Effective Project, Programme and Portfolio Management Govern...
he Principles of Effective Project, Programme and Portfolio Management Govern...
 
Andrew_Thomas
Andrew_ThomasAndrew_Thomas
Andrew_Thomas
 
Aligning Feature Delivery with OKRs by Gtmhub CPO
Aligning Feature Delivery with OKRs by Gtmhub CPOAligning Feature Delivery with OKRs by Gtmhub CPO
Aligning Feature Delivery with OKRs by Gtmhub CPO
 

More from Ganesh Prasad

Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)
Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)
Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)Ganesh Prasad
 
50 data principles for loosely coupled identity management v1 0
50 data principles for loosely coupled identity management v1 050 data principles for loosely coupled identity management v1 0
50 data principles for loosely coupled identity management v1 0Ganesh Prasad
 
(Deprecated) Slicing the Gordian Knot of SOA Governance
(Deprecated) Slicing the Gordian Knot of SOA Governance(Deprecated) Slicing the Gordian Knot of SOA Governance
(Deprecated) Slicing the Gordian Knot of SOA GovernanceGanesh Prasad
 
Sofea in a soa ecosystem v0 4
Sofea in a soa ecosystem v0 4Sofea in a soa ecosystem v0 4
Sofea in a soa ecosystem v0 4Ganesh Prasad
 
Life above the service tier preso v1 0
Life above the service tier preso v1 0Life above the service tier preso v1 0
Life above the service tier preso v1 0Ganesh Prasad
 
Life above the_service_tier_v1.1
Life above the_service_tier_v1.1Life above the_service_tier_v1.1
Life above the_service_tier_v1.1Ganesh Prasad
 

More from Ganesh Prasad (7)

Enterprise REST
Enterprise RESTEnterprise REST
Enterprise REST
 
Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)
Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)
Dependency-Oriented Thinking Sydney Workshop Brochure and Schedule (Feb 15 2014)
 
50 data principles for loosely coupled identity management v1 0
50 data principles for loosely coupled identity management v1 050 data principles for loosely coupled identity management v1 0
50 data principles for loosely coupled identity management v1 0
 
(Deprecated) Slicing the Gordian Knot of SOA Governance
(Deprecated) Slicing the Gordian Knot of SOA Governance(Deprecated) Slicing the Gordian Knot of SOA Governance
(Deprecated) Slicing the Gordian Knot of SOA Governance
 
Sofea in a soa ecosystem v0 4
Sofea in a soa ecosystem v0 4Sofea in a soa ecosystem v0 4
Sofea in a soa ecosystem v0 4
 
Life above the service tier preso v1 0
Life above the service tier preso v1 0Life above the service tier preso v1 0
Life above the service tier preso v1 0
 
Life above the_service_tier_v1.1
Life above the_service_tier_v1.1Life above the_service_tier_v1.1
Life above the_service_tier_v1.1
 

Recently uploaded

Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - Tech
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - TechWebinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - Tech
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - TechProduct School
 
UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3DianaGray10
 
My key hands-on projects in Quantum, and QAI
My key hands-on projects in Quantum, and QAIMy key hands-on projects in Quantum, and QAI
My key hands-on projects in Quantum, and QAIVijayananda Mohire
 
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptx
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptxGraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptx
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptxNeo4j
 
Automation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projectsAutomation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projectsDianaGray10
 
EMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? WebinarEMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? WebinarThousandEyes
 
TrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie WorldTrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie WorldTrustArc
 
UiPath Studio Web workshop series - Day 1
UiPath Studio Web workshop series  - Day 1UiPath Studio Web workshop series  - Day 1
UiPath Studio Web workshop series - Day 1DianaGray10
 
How to release an Open Source Dataweave Library
How to release an Open Source Dataweave LibraryHow to release an Open Source Dataweave Library
How to release an Open Source Dataweave Libraryshyamraj55
 
2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdf2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdfThe Good Food Institute
 
Stobox 4: Revolutionizing Investment in Real-World Assets Through Tokenization
Stobox 4: Revolutionizing Investment in Real-World Assets Through TokenizationStobox 4: Revolutionizing Investment in Real-World Assets Through Tokenization
Stobox 4: Revolutionizing Investment in Real-World Assets Through TokenizationStobox
 
Trailblazer Community - Flows Workshop (Session 2)
Trailblazer Community - Flows Workshop (Session 2)Trailblazer Community - Flows Workshop (Session 2)
Trailblazer Community - Flows Workshop (Session 2)Muhammad Tiham Siddiqui
 
Emil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptx
Emil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptxEmil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptx
Emil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptxNeo4j
 
Flow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First FrameFlow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First FrameKapil Thakar
 
Where developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingWhere developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingFrancesco Corti
 
Scenario Library et REX Discover industry- and role- based scenarios
Scenario Library et REX Discover industry- and role- based scenariosScenario Library et REX Discover industry- and role- based scenarios
Scenario Library et REX Discover industry- and role- based scenariosErol GIRAUDY
 
Novo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4jNovo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4jNeo4j
 
Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.IPLOOK Networks
 
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024Alkin Tezuysal
 

Recently uploaded (20)

Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - Tech
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - TechWebinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - Tech
Webinar: The Art of Prioritizing Your Product Roadmap by AWS Sr PM - Tech
 
UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3
 
My key hands-on projects in Quantum, and QAI
My key hands-on projects in Quantum, and QAIMy key hands-on projects in Quantum, and QAI
My key hands-on projects in Quantum, and QAI
 
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptx
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptxGraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptx
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptx
 
Automation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projectsAutomation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projects
 
EMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? WebinarEMEA What is ThousandEyes? Webinar
EMEA What is ThousandEyes? Webinar
 
TrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie WorldTrustArc Webinar - How to Live in a Post Third-Party Cookie World
TrustArc Webinar - How to Live in a Post Third-Party Cookie World
 
UiPath Studio Web workshop series - Day 1
UiPath Studio Web workshop series  - Day 1UiPath Studio Web workshop series  - Day 1
UiPath Studio Web workshop series - Day 1
 
How to release an Open Source Dataweave Library
How to release an Open Source Dataweave LibraryHow to release an Open Source Dataweave Library
How to release an Open Source Dataweave Library
 
2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdf2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdf
 
Stobox 4: Revolutionizing Investment in Real-World Assets Through Tokenization
Stobox 4: Revolutionizing Investment in Real-World Assets Through TokenizationStobox 4: Revolutionizing Investment in Real-World Assets Through Tokenization
Stobox 4: Revolutionizing Investment in Real-World Assets Through Tokenization
 
Trailblazer Community - Flows Workshop (Session 2)
Trailblazer Community - Flows Workshop (Session 2)Trailblazer Community - Flows Workshop (Session 2)
Trailblazer Community - Flows Workshop (Session 2)
 
Emil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptx
Emil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptxEmil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptx
Emil Eifrem at GraphSummit Copenhagen 2024 - The Art of the Possible.pptx
 
Flow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First FrameFlow Control | Block Size | ST Min | First Frame
Flow Control | Block Size | ST Min | First Frame
 
Where developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingWhere developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is going
 
Scenario Library et REX Discover industry- and role- based scenarios
Scenario Library et REX Discover industry- and role- based scenariosScenario Library et REX Discover industry- and role- based scenarios
Scenario Library et REX Discover industry- and role- based scenarios
 
Novo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4jNovo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4j
 
Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.
 
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
Design and Modeling for MySQL SCALE 21X Pasadena, CA Mar 2024
 
SheDev 2024
SheDev 2024SheDev 2024
SheDev 2024
 

Workshop Slides - Introduction to Dependency-Oriented Thinking" Feb 15, 2014, Sydney

  • 1. Dependency-Oriented Thinking Session 1 – Inculcating Dependency-Oriented Thinking (C) Ganesh Prasad, Eigner Pty Ltd
  • 2. Agenda ● Introduction – Presenter bio, Participants' backgrounds ● Prior experiences with SOA ● Expectations from this workshop ● Case studies (interactive) ● Notation (UML) for inter-system dependencies ● ● Surrogate principles and why they don't always apply Exercises (interactive) (C) Ganesh Prasad, Eigner Pty Ltd
  • 3. SOA is not just Technology ● ● Technology is the implementation of business intent A lot of analysis and design is required before business intent can be implemented (C) Ganesh Prasad, Eigner Pty Ltd
  • 4. How did SOA get to be seen as Technology? ● “Service” is a weasel word (C) Ganesh Prasad, Eigner Pty Ltd
  • 5. Understanding the term “dependency” ● Not a fancy technical term; just a regular English word ● We can represent it using a formal notation (C) Ganesh Prasad, Eigner Pty Ltd
  • 6. Why are dependencies important? ● A system with a large number of interconnections (dependencies) ● Some of the dependencies are not even obvious ● Now move the orange block without disturbing any of the others ● How confident are you? (C) Ganesh Prasad, Eigner Pty Ltd
  • 7. The impact of reducing dependencies ● A system with far fewer interconnections (dependencies) ● No dependencies are unknown or hidden ● How confident are you of making changes without breaking anything? ● How fast can you move the block? ● How much do you need to plan for the move? (C) Ganesh Prasad, Eigner Pty Ltd
  • 8. The trap of surrogate principles ● “Point-to-point connections considered harmful” considered harmful (C) Ganesh Prasad, Eigner Pty Ltd
  • 9. The converse trap ● Mediated connections considered harmful (C) Ganesh Prasad, Eigner Pty Ltd
  • 10. Logical mediation ● A “point-to-point” connection can in fact be mediated (C) Ganesh Prasad, Eigner Pty Ltd
  • 11. Dependency view ● The dependency view of a true point-to-point connection (C) Ganesh Prasad, Eigner Pty Ltd
  • 12. Dependency view ● The dependency view of a mediated “point-to-point” connection (C) Ganesh Prasad, Eigner Pty Ltd
  • 13. Logical tight coupling ● A “mediated” connection may in fact be tightly coupled (C) Ganesh Prasad, Eigner Pty Ltd
  • 14. Dependency view ● The dependency view of a tightly coupled mediated system (C) Ganesh Prasad, Eigner Pty Ltd
  • 15. Reducing dependencies – the Linux way ● Linux uses the Unix mechanism of symbolic links to abstract changes (C) Ganesh Prasad, Eigner Pty Ltd
  • 16. Dependency-Oriented Thinking Session 2 – Dependency-Oriented Thinking as a Formal Approach (C) Ganesh Prasad, Eigner Pty Ltd
  • 17. Agenda ● The BAIT Model of the enterprise ● Entities and Relationships in the TOGAF Model ● The core elements applicable to Analysis and Design (Design Artifacts) ● Dependency Principles ● The Method (C) Ganesh Prasad, Eigner Pty Ltd
  • 18. A Few Words on BAIT (C) Ganesh Prasad, Eigner Pty Ltd
  • 19. How should an architect view “applications”? ● ● The literal view of systems does not provide architectural insights The Application layer of BAIT is to be viewed functionally, not physically (C) Ganesh Prasad, Eigner Pty Ltd
  • 20. The Layered view of Applications ● ● The correct way to see the Application layer is as logical groupings of business capabilities Physical systems (hardware and software) are Technology layer entities used to implement these capabilities (C) Ganesh Prasad, Eigner Pty Ltd
  • 21. Interdependencies between BAIT layers ● The Application and Information layers always go hand in hand (C) Ganesh Prasad, Eigner Pty Ltd
  • 22. BAIT as a “Four I” model of SOA ● Intent – what is to be done ● Internal Cohesion – how functions hang together ● Interfaces and Integration – how functions interoperate ● Implementation – what the tangible, working system looks like (C) Ganesh Prasad, Eigner Pty Ltd
  • 23. BAIT and “Operation-Oriented Architecture” ● Operations are the fundamental building blocks of an enterprise ● Determine operations (the steps of business processes) ● Group related operations together (based on internals and interfaces) ● Expose operations to external consumers ● Execute operations, either alone or in combination with others (C) Ganesh Prasad, Eigner Pty Ltd
  • 24. BAIT versus TOGAF ● ● ● ● ● BAIT is only a framework It shows how to view an enterprise but doesn't show what comprises each layer We need a model that is based on BAIT to define a generic set of entities at each layer A good model to use is TOGAF TOGAF is based on industry experience and practice, and is comprehensive yet generic (C) Ganesh Prasad, Eigner Pty Ltd
  • 25. TOGAF as a well-known set of dependencies ● ● TOGAF's vocabulary includes “viewpoints”, which are subsets of the entities that make up the model of an enterprise We can mine this rich set of data to search for dependency relationships (C) Ganesh Prasad, Eigner Pty Ltd
  • 26. Enterprise-Level Entities and Relationships (C) Ganesh Prasad, Eigner Pty Ltd
  • 27. Business Layer Entities and Relationships (C) Ganesh Prasad, Eigner Pty Ltd
  • 28. Business Layer Design Artifacts ● Not all Business Layer entities are important to an analyst or designer (C) Ganesh Prasad, Eigner Pty Ltd
  • 29. Application Layer Entities and Relationships (C) Ganesh Prasad, Eigner Pty Ltd
  • 30. A Detailed Look at “Applications” (C) Ganesh Prasad, Eigner Pty Ltd
  • 31. Application Layer Design Artifacts ● Note the two types of “applications” formed by grouping Operations in two different ways (C) Ganesh Prasad, Eigner Pty Ltd
  • 32. Information Layer Entities and Relationships (C) Ganesh Prasad, Eigner Pty Ltd
  • 33. Information Layer Design Artifacts (C) Ganesh Prasad, Eigner Pty Ltd
  • 34. Technology Layer Entities and Relationships (C) Ganesh Prasad, Eigner Pty Ltd
  • 35. Technology Layer Design Artifacts (C) Ganesh Prasad, Eigner Pty Ltd
  • 36. Design Artifacts by BAIT Layer (C) Ganesh Prasad, Eigner Pty Ltd
  • 37. Dependency Principles by BAIT Layer (C) Ganesh Prasad, Eigner Pty Ltd
  • 38. The Formal Dependency-Oriented Method ● ● Starting at the Business layer, identify the Key Design Artifacts and apply Dependency Principles to arrive at an optimal design Rinse and repeat at the next lower level (C) Ganesh Prasad, Eigner Pty Ltd
  • 39. Dependency-Oriented Thinking Session 3 – The Business Layer (C) Ganesh Prasad, Eigner Pty Ltd
  • 40. Agenda ● Business Intent ● The Chain from Vision to Process Step ● Traceability and Minimalism ● The role of Domain Insight ● Dealing with changing requirements (intent versus detail) (C) Ganesh Prasad, Eigner Pty Ltd
  • 41. Business Layer Design Artifacts (C) Ganesh Prasad, Eigner Pty Ltd
  • 42. Vision and Mission ● Vision – your idea of Utopia ● Mission – your role in bringing about that Utopia ● Together referred to as “Goal” in TOGAF (C) Ganesh Prasad, Eigner Pty Ltd
  • 43. The hidden role of Strategy ● Strategy shapes organisations ● The same Mission may be accomplished in different ways (C) Ganesh Prasad, Eigner Pty Ltd
  • 44. Business Functions are largely Stable ● ● Changes in Strategy tend to impact Business Processes, but curiously, need not impact Business Functions once established Changes in Business Function are known as “restructures” (C) Ganesh Prasad, Eigner Pty Ltd
  • 45. Function, Process and Process Step ● Function is both Structure and mini-Mission ● Processes are what Functions “do” ● Processes are composed of Steps (which may or may not be reusable) (C) Ganesh Prasad, Eigner Pty Ltd
  • 46. The Traceability Principle ● Think of Traceability as a chain of “existential dependencies” ● It's a discipline that makes a business “lean and mean” (C) Ganesh Prasad, Eigner Pty Ltd
  • 47. The Minimalism Principle ● “The simplest way to get a job done” ● A discipline that leads to agility (C) Ganesh Prasad, Eigner Pty Ltd
  • 48. Domain Insight ● Helps in applying the Traceability and Minimalism principles ● More Art than Science ● Think of examples from your own organisation (C) Ganesh Prasad, Eigner Pty Ltd
  • 49. Changing Requirements ● Intent versus Detail (C) Ganesh Prasad, Eigner Pty Ltd
  • 50. Dependency-Oriented Thinking Session 4 – Process Design (C) Ganesh Prasad, Eigner Pty Ltd
  • 51. Agenda ● ● ● ● The generic business process Human workflow and asynchronous process steps Orchestration and Choreography "Orchestrable" and "Choreographable" Operations (C) Ganesh Prasad, Eigner Pty Ltd
  • 52. The Crucial Design Step between Process and Process Step ● How should Process Steps be coordinated into a Process? ● Design Exercise (C) Ganesh Prasad, Eigner Pty Ltd
  • 53. Top-Down Design of the Business Layer (C) Ganesh Prasad, Eigner Pty Ltd
  • 54. Orchestrated Processes ● The dependency relationships in an orchestrated process mirror the flow of control (C) Ganesh Prasad, Eigner Pty Ltd
  • 55. Choreographed Processes ● The dependency relationships bear no resemblance to the flow of control (C) Ganesh Prasad, Eigner Pty Ltd
  • 56. A Simple Business Process ● An Event Trigger followed by one or more Process Steps (C) Ganesh Prasad, Eigner Pty Ltd
  • 57. A Generic Business Process ● A generic process does not run to completion in one go ● It may pause, and resume based on intermediate event triggers (C) Ganesh Prasad, Eigner Pty Ltd
  • 58. “Non-blocking” Processes and Callback ● ● It's often efficient for a paused process to do something else instead of idly waiting for an event trigger This model enables the design of long-running processes (C) Ganesh Prasad, Eigner Pty Ltd
  • 59. Human workflow as a long-running process ● ● Non-blocking process design can be used to design human workflow Pause and Resume junctures occur wherever human interaction is required (C) Ganesh Prasad, Eigner Pty Ltd
  • 60. Dependencies in Orchestrable and Choreographable Operations ● Recall the different graphs for dependency versus flow of control ● The dependencies are similar, just in different places (C) Ganesh Prasad, Eigner Pty Ltd
  • 61. The Overhyped Notion of “Reuse” ● ● Reuse is not a first-class benefit It's unreasonable to expect reuse from a SOA initiative if the process steps of a business are not inherently reusable (C) Ganesh Prasad, Eigner Pty Ltd
  • 62. The potential for reuse is first seen at the Business layer (C) Ganesh Prasad, Eigner Pty Ltd
  • 63. Lower layers should confirm if reuse is in fact possible (C) Ganesh Prasad, Eigner Pty Ltd
  • 64. Dependency-Oriented Thinking Session 5 – The Application Layer (C) Ganesh Prasad, Eigner Pty Ltd
  • 65. Agenda ● ● ● What is an "Application"? The principles of High Cohesion and Decoupling of Internals from Interfaces "Goldilocks" Signatures (Stability versus Precision of Interfaces) ● Variants, Versions and dealing with change ● Shared Semantics for effective Choreography (C) Ganesh Prasad, Eigner Pty Ltd
  • 66. Application Layer Design Artifacts ● Process Steps at the Business layer map to Operations at the Application layer (C) Ganesh Prasad, Eigner Pty Ltd
  • 67. Application Layer vs Technology Layer ● The Technology layer provides a detailed “street view” ● The Application layer provides a high-level “map view” (C) Ganesh Prasad, Eigner Pty Ltd
  • 68. The Relationship between Design Artifacts at the Application and Information Layers ● Products are defined by a shared Internal Data Model ● Services are defined by a shared Interface Data Model (C) Ganesh Prasad, Eigner Pty Ltd
  • 69. The Cohesion and Coupling Principles ● At each layer, there is an internal focus (Cohesion) and an external focus (Coupling) (C) Ganesh Prasad, Eigner Pty Ltd
  • 70. Cohesion Exercise 1 (C) Ganesh Prasad, Eigner Pty Ltd
  • 71. (C) Ganesh Prasad, Eigner Pty Ltd
  • 72. (C) Ganesh Prasad, Eigner Pty Ltd
  • 73. Cohesion Exercise 2 (C) Ganesh Prasad, Eigner Pty Ltd
  • 74. (C) Ganesh Prasad, Eigner Pty Ltd
  • 75. (C) Ganesh Prasad, Eigner Pty Ltd
  • 76. (C) Ganesh Prasad, Eigner Pty Ltd
  • 77. Cohesion Exercise 3 (C) Ganesh Prasad, Eigner Pty Ltd
  • 78. (C) Ganesh Prasad, Eigner Pty Ltd
  • 79. (C) Ganesh Prasad, Eigner Pty Ltd
  • 80. Simultaneous Groupings ● It is possible to group entities in more than one way at the same time (C) Ganesh Prasad, Eigner Pty Ltd
  • 81. Simultaneous Grouping of Operations ● A dynamic grouping of Operations is a Process ● A static grouping of Operations is an Application (Product or Service) (C) Ganesh Prasad, Eigner Pty Ltd
  • 82. Anatomy of a Product ● Grouping by internals is the design principle ● External access is “canned” through a relatively rigid native interface (C) Ganesh Prasad, Eigner Pty Ltd
  • 83. Anatomy of a Service ● Grouping by Interfaces is the design principle ● External access is the very raison d'être! (C) Ganesh Prasad, Eigner Pty Ltd
  • 84. SOFEA – Architecture for Front-ends ● For the best of both worlds, build user interfaces on top of services (C) Ganesh Prasad, Eigner Pty Ltd
  • 85. Demystifying Versioning ● Variants and Versions ● Interfaces and Internals ● (C) Ganesh Prasad, Eigner Pty Ltd
  • 86. Variants ● A Variant is an operation “flavour” that may coexist with other flavours without deprecating them (C) Ganesh Prasad, Eigner Pty Ltd
  • 87. Versions ● There is always a latest Version that deprecates earlier ones (C) Ganesh Prasad, Eigner Pty Ltd
  • 88. Interfaces as Abstractions of Operations ● An Interface represents the Business Intent of an Operation ● Details are taken care of by implementation variants (“internals”) (C) Ganesh Prasad, Eigner Pty Ltd
  • 89. The Impact of Changing Interfaces ● Consumers of operations have a dependency on the interface ● Changes to operations may impact consumers to different degrees (C) Ganesh Prasad, Eigner Pty Ltd
  • 90. Impacts classified by Version Type ● Versions can be thought of as “x.y.z” ● The only criterion for classification is the level of impact from a change ● A term like “bug fix version” makes no sense from a dependency perspective (C) Ganesh Prasad, Eigner Pty Ltd
  • 91. Changes to Internals ● A change to the internal logic of an operation with no visibility at the interface changes only the implementation version, not the minor or major versions (C) Ganesh Prasad, Eigner Pty Ltd
  • 92. “Minor” Changes to Interfaces ● ● ● Some kinds of changes to operations are visible at the interface, but do not impact consumers in a practical sense They only change the minor version number Minor version changes are “backward compatible” (continue to support older consumers while supporting new ones) (C) Ganesh Prasad, Eigner Pty Ltd
  • 93. Types of changes that do not break an interface ● Interfaces that become more lenient tend not to impact consumers (C) Ganesh Prasad, Eigner Pty Ltd
  • 94. Major Changes to Interfaces ● A change to an operation that is not only visible at the interface but also forces a change to the consumer is a change to the major version number (C) Ganesh Prasad, Eigner Pty Ltd
  • 95. Types of changes that break an interface ● An interface that becomes stricter or more restrictive tends to impact consumers (C) Ganesh Prasad, Eigner Pty Ltd
  • 96. Version Mapping Convention ● ● Exploit the dependency level expressed by the “x.y.z” version numbering scheme The minor version number should always refer to the latest implementation version (C) Ganesh Prasad, Eigner Pty Ltd
  • 97. Version Mapping Convention, cont'd ● The major version number should always map to the latest minor version (C) Ganesh Prasad, Eigner Pty Ltd
  • 98. Version Routing Exercise ● Which implementation version will be executed by this call? (C) Ganesh Prasad, Eigner Pty Ltd
  • 99. Solution ● Thumb rule – It's always the latest version at the lower level (C) Ganesh Prasad, Eigner Pty Ltd
  • 100. (C) Ganesh Prasad, Eigner Pty Ltd
  • 101. (C) Ganesh Prasad, Eigner Pty Ltd
  • 102. The “Minor Version Lockstep Dependency” ● When dealing with multiple variants, changes to the minor version number of one variant will require corresponding changes to the minor version numbers of all the other variants! (C) Ganesh Prasad, Eigner Pty Ltd
  • 103. The “Goldilocks Signature” Principle ● A balance is required between the stability and the precision of an operation's interface (C) Ganesh Prasad, Eigner Pty Ltd
  • 104. What is a “Well-Designed” Interface? ● Well-designed interfaces are stable in the face of change ● i.e., they do not create unnecessary dependencies (C) Ganesh Prasad, Eigner Pty Ltd
  • 105. Why the scheme works (C) Ganesh Prasad, Eigner Pty Ltd
  • 106. Managing Breaking Changes (C) Ganesh Prasad, Eigner Pty Ltd
  • 107. Managing Breaking Changes, cont'd (C) Ganesh Prasad, Eigner Pty Ltd
  • 108. Managing Non-Breaking Changes (C) Ganesh Prasad, Eigner Pty Ltd
  • 109. Dependency-Oriented Thinking Session 6 – The Information Layer (C) Ganesh Prasad, Eigner Pty Ltd
  • 110. Agenda ● "Data on the Outside versus Data on the Inside" ● Elements of Low Coupling ● Type Hierarchy and Interface Abstraction ● Identity Association ● Context versus Content (C) Ganesh Prasad, Eigner Pty Ltd
  • 111. Information Layer Design Artifacts ● ● Only two major categories – “Data on the Outside” and “Data on the Inside” Deceptively simple! (C) Ganesh Prasad, Eigner Pty Ltd
  • 112. Variants from a Data Perspective ● ● A single abstract interface can map to multiple concrete implementation variants But the -------- ------ remains the same (C) Ganesh Prasad, Eigner Pty Ltd
  • 113. The Notion of “Context” ● “Context” is a way of formalising aspects of an operation that are not core to its business intent (C) Ganesh Prasad, Eigner Pty Ltd
  • 114. Low Coupling, or “Need to Know” ● A form of minimalism applied to data (C) Ganesh Prasad, Eigner Pty Ltd
  • 115. Decoupling of Internal Data from Interface Data ● To be decoupled, interface and internal data models cannot have dependencies on each other (C) Ganesh Prasad, Eigner Pty Ltd
  • 116. The Domain-Specific Data Dictionary ● Efficiencies are still possible! ● The internal and interface data models do talk about similar entities (C) Ganesh Prasad, Eigner Pty Ltd
  • 117. What a Data Dictionary Looks Like ● Entities and Value Objects are defined here (C) Ganesh Prasad, Eigner Pty Ltd
  • 118. Types and Instances ● Both internal and interface data models define instances of types ● Types common to both should be in the common data dictionary (C) Ganesh Prasad, Eigner Pty Ltd
  • 119. Data Model Example ● Internal and interface data models have some elements in common and some elements that are unique to each (C) Ganesh Prasad, Eigner Pty Ltd
  • 120. The Relationship between Interface/Internals and Type Hierarchy ● This is why Application and Information layer design is done together! (C) Ganesh Prasad, Eigner Pty Ltd
  • 121. A Problem We Glossed Over! ● ● ● ● ● Abstract interfaces are stable and shield consumers from many internal changes, but... How does a consumer know which concrete data elements to send and receive? The answer becomes clear if we jettison a fallacy of SOA – that a formal “interface contract” is sufficient for a consumer to begin transacting with an operation In practice, designers of consuming applications always discuss with the designers of operations and negotiate data exchange Use this knowledge to design pragmatic design processes (C) Ganesh Prasad, Eigner Pty Ltd
  • 122. Building an abstract interface to an existing implementation (C) Ganesh Prasad, Eigner Pty Ltd
  • 123. When a new consumer is supported by an existing variant (C) Ganesh Prasad, Eigner Pty Ltd
  • 124. When a new consumer is not supported by an existing variant (C) Ganesh Prasad, Eigner Pty Ltd
  • 125. The Internal Data Model ● Deals with Entities rather than Value objects (C) Ganesh Prasad, Eigner Pty Ltd
  • 126. The Interface Data Model ● Never references Entities! (That would be tight coupling) ● Value objects are packaged into messages that are exchanged ● Value objects can also be called “representations” (C) Ganesh Prasad, Eigner Pty Ltd
  • 127. The Identity Association Principle ● A common design error (C) Ganesh Prasad, Eigner Pty Ltd
  • 128. How Identity Association Works ● Consumers must not develop dependencies on internal data entities (C) Ganesh Prasad, Eigner Pty Ltd
  • 129. Revisiting the Goldilocks Signature Principle ● Think about stability and precision afresh from the viewpoint of data (C) Ganesh Prasad, Eigner Pty Ltd
  • 130. Message Data Model ● The Goldilocks Signature principle is supported by this model (C) Ganesh Prasad, Eigner Pty Ltd
  • 131. A Terrible Way to Implement Extensible Interfaces ● Extensions gradually destroy structure and meaning (C) Ganesh Prasad, Eigner Pty Ltd
  • 132. Extensibility with Control ● Setting up a Type Hierarchy supports change gracefully (C) Ganesh Prasad, Eigner Pty Ltd
  • 133. Isolation of Context from Content ● Keep extraneous considerations separate from the core business intent (C) Ganesh Prasad, Eigner Pty Ltd
  • 134. The Context Type Hierarchy ● Context has its own hierarchy with a single, optional base type called “Context Type” (C) Ganesh Prasad, Eigner Pty Ltd
  • 135. Supporting New Variants that Differ only in Context ● Building in an optional context element into every interface is insurance against breaking change (C) Ganesh Prasad, Eigner Pty Ltd
  • 136. Context of Output Data ● ● Context of input data is used to determine appropriate variants to invoke Context of output data can support choreographable operations (C) Ganesh Prasad, Eigner Pty Ltd
  • 137. Service Content and Process Context ● When considering a single operation, some data elements may be considered content rather than context (i.e., they follow from the business intent) (C) Ganesh Prasad, Eigner Pty Ltd
  • 138. Modelling Service Content as Context ● Sometimes, a process may have operations with common content ● This content could be considered to be their common context (C) Ganesh Prasad, Eigner Pty Ltd
  • 139. Context By Reference ● ● Operations sharing “content context” with other operations can then deal with references to common data These reference IDs are a form of context that is common to the process (C) Ganesh Prasad, Eigner Pty Ltd
  • 140. Context By Reference, cont'd ● Subsequent operations refer to common content through the context ID (C) Ganesh Prasad, Eigner Pty Ltd
  • 141. Example – Bringing Application and Data Layer Principles Together (C) Ganesh Prasad, Eigner Pty Ltd
  • 142. The Type Hierarchy supporting Late Binding (C) Ganesh Prasad, Eigner Pty Ltd
  • 143. “Schema Validation” (C) Ganesh Prasad, Eigner Pty Ltd
  • 144. Routing/Binding from Interface to Implementation (C) Ganesh Prasad, Eigner Pty Ltd
  • 145. Dependency-Oriented Thinking Session 7 – The Technology Layer (C) Ganesh Prasad, Eigner Pty Ltd
  • 146. Agenda ● ● ● ● ● Standards, Bundling and Tooling Standards and Standards Families - SOAP and REST Bundling - Data, Logic, Physical Components and their association Tooling - the core and supporting components of a distributed solution Implementing a logical design (C) Ganesh Prasad, Eigner Pty Ltd
  • 147. Technology Layer – The Design of Implementation ● Not implementation itself, but the design of implementation (C) Ganesh Prasad, Eigner Pty Ltd
  • 148. Technology Layer Design Artifacts ● At the most abstract level, Technology consists of three elements ● They are Standards, Tooling and Bundling (C) Ganesh Prasad, Eigner Pty Ltd
  • 149. Bundling Decisions ● “Where to place what” is a bundling decision (C) Ganesh Prasad, Eigner Pty Ltd
  • 150. Logic Bundling Principle ● This is a variant of the Cohesion principle – what belongs together must go together (C) Ganesh Prasad, Eigner Pty Ltd
  • 151. The State or “Stickiness” Principle ● ● Placing logic on one physical component as opposed to another could be the difference between a stateless and a stateful system Stateless systems have significant architectural advantages on account of their reduced bundling dependencies (scalability, failure recovery) (C) Ganesh Prasad, Eigner Pty Ltd
  • 152. Topology “Hotspots” ● ● The way physical components are connected or “wired” together can create bundling dependencies of another kind Performance bottlenecks and single points of failure are common results of topology-related bundling decisions (C) Ganesh Prasad, Eigner Pty Ltd
  • 153. Reference Architecture of a Deployable Application (C) Ganesh Prasad, Eigner Pty Ltd
  • 154. Determining Standards for Orchestrable Operations (C) Ganesh Prasad, Eigner Pty Ltd
  • 155. Determining Standards for Choreographable Operations (C) Ganesh Prasad, Eigner Pty Ltd
  • 156. Determining Tooling Components (C) Ganesh Prasad, Eigner Pty Ltd
  • 157. Determining Deployment Bundles (C) Ganesh Prasad, Eigner Pty Ltd
  • 158. Determining Description Bundles (C) Ganesh Prasad, Eigner Pty Ltd
  • 159. The Service Provider (C) Ganesh Prasad, Eigner Pty Ltd
  • 160. The Service Consumer (C) Ganesh Prasad, Eigner Pty Ltd
  • 161. Legacy Systems (C) Ganesh Prasad, Eigner Pty Ltd
  • 162. Functional Symbols for Tooling ● From Gregor Hohpe's “Enterprise Integration Patterns” (C) Ganesh Prasad, Eigner Pty Ltd
  • 163. Additional Symbol for Tooling ● Internal logic has no symbol in “Enterprise Integration Patterns” ● We have to “roll our own”! (C) Ganesh Prasad, Eigner Pty Ltd
  • 164. The Core Technology Layer Components ● Service Container ● Broker ● Process Coordinator (C) Ganesh Prasad, Eigner Pty Ltd
  • 165. Service Container ● Implements Business Logic and exposes it (C) Ganesh Prasad, Eigner Pty Ltd
  • 166. How a Service Container is Used ● The logic implemented by the Service Container and exposed as an operation is consumed by a service consumer (C) Ganesh Prasad, Eigner Pty Ltd
  • 167. Broker ● Mediates access to existing logic (C) Ganesh Prasad, Eigner Pty Ltd
  • 168. How a Broker is Used ● ● ● The special protocols and interfaces of legacy systems are hidden through “adapters” Data formats are converted through “transformer” logic Physical locations are hidden and variants are abstracted through “mediator” logic (C) Ganesh Prasad, Eigner Pty Ltd
  • 169. Process Coordinator ● Combines existing operations into business processes ● More relevant for orchestrable operations (C) Ganesh Prasad, Eigner Pty Ltd
  • 170. How a Process Coordinator is Used ● The Process Coordinator runs stateful process logic (orchestration) ● It invokes operations as required ● The operations themselves are stateless (C) Ganesh Prasad, Eigner Pty Ltd
  • 171. The Components Working Together ● The three core technology components are designed to work together (C) Ganesh Prasad, Eigner Pty Ltd
  • 172. Broker Design Error 1 ● Topology Hotspot – the Broker is not meant to be a centralised component (C) Ganesh Prasad, Eigner Pty Ltd
  • 173. Broker Design Error 2 ● Always use the right tool for the job ● The Broker is a mediator ● Do not use the Broker as a Service Container ● Do not use the Broker as a Process Coordinator (C) Ganesh Prasad, Eigner Pty Ltd
  • 174. Dependencies introduced by SOAP ● Static Description dependency ● Bundling dependency ● Synchronisation dependency (C) Ganesh Prasad, Eigner Pty Ltd
  • 175. Dependencies introduced by REST ● Semantic dependency ● Synchronisation dependency (C) Ganesh Prasad, Eigner Pty Ltd
  • 176. What is a “Semantic Dependency”? ● The requirement for a system to resolve ambiguity (C) Ganesh Prasad, Eigner Pty Ltd
  • 177. The Problem with WSDL ● WSDL is a static description of a group of operations ● Three dependencies arise from this design (C) Ganesh Prasad, Eigner Pty Ltd
  • 178. The WSDL Dependency Multiplied ● A popular service can have many consumers that are then dependent on its interface contract (C) Ganesh Prasad, Eigner Pty Ltd
  • 179. Cascading Impacts of Change ● WSDL is a dependency hotspot (C) Ganesh Prasad, Eigner Pty Ltd
  • 180. Calculating the Brittleness of WSDL ● ● A WSDL file describes exactly 1 service consisting of 5 operations, each with an input and an output document If any given document has a 10% probability of changing, what is the probability of the WSDL file changing? (C) Ganesh Prasad, Eigner Pty Ltd
  • 181. Strategies to minimise change ● Dependency principles can be applied to minimise the effects of change due to the WSDL dependency hotspot (C) Ganesh Prasad, Eigner Pty Ltd
  • 182. Dependencies arising from REST's Hypermedia Constraints ● ● There is no static description of operations in REST (WADL is not RESTian) There are still 3 dependencies (C) Ganesh Prasad, Eigner Pty Ltd
  • 183. Miscellaneous Technology Layer Considerations (C) Ganesh Prasad, Eigner Pty Ltd
  • 184. The “Canonical Data Model” Fallacy ● A Canonical Data Model could be too heavyweight and rigid (C) Ganesh Prasad, Eigner Pty Ltd
  • 185. Domain Data Models ● Domain Data Models are more flexible and federation-friendly (C) Ganesh Prasad, Eigner Pty Ltd
  • 186. “The SOA Ecosystem” ● The logical view of service providers and consumers (C) Ganesh Prasad, Eigner Pty Ltd
  • 187. Processes as Service Consumers ● Processes are a special type of service consumer (C) Ganesh Prasad, Eigner Pty Ltd
  • 188. Processes as Operations ● ● A process abstracts coarse-grained logic This coarse-grained logic may in turn be invoked by a service consumer (C) Ganesh Prasad, Eigner Pty Ltd
  • 189. Processes in the SOA Ecosystem ● A process is both a service provider and a service consumer (C) Ganesh Prasad, Eigner Pty Ltd
  • 190. Operation Signatures implemented in SOAP and REST (C) Ganesh Prasad, Eigner Pty Ltd
  • 191. Dependency-Oriented Thinking Session 8 – Worked-Out Examples (C) Ganesh Prasad, Eigner Pty Ltd
  • 192. Agenda ● ● Option 1: Detailed analysis of participants' own design problems Option 2: Canned case studies: ● ● ● ● Conducting a post-mortem based on dependency principles Designing a system based on an orchestrated business process Designing a system based on a choreographed business process Designing an interface data model to cater to change (Type Hierarchy and Goldilocks Signatures) (C) Ganesh Prasad, Eigner Pty Ltd
  • 193. Post-Mortem Example (C) Ganesh Prasad, Eigner Pty Ltd
  • 194. Exercise – Post-Mortem ● What is wrong with this design? (C) Ganesh Prasad, Eigner Pty Ltd
  • 195. A More Flexible Design (C) Ganesh Prasad, Eigner Pty Ltd
  • 196. Synchronous Orchestrated Process (C) Ganesh Prasad, Eigner Pty Ltd
  • 197. Banking Application Sequence Diagram (C) Ganesh Prasad, Eigner Pty Ltd
  • 198. Processes, Services and Operations ● Dynamic grouping of operations into a single process “Open Account” ● Static grouping of operations into 3 services (C) Ganesh Prasad, Eigner Pty Ltd
  • 199. High-Level Solution Diagram – Banking (C) Ganesh Prasad, Eigner Pty Ltd
  • 201. Insurance Application Sequence Diagram (C) Ganesh Prasad, Eigner Pty Ltd
  • 202. Processes, Services and Operations ● Two dynamic groupings (processes): Get Quote and Purchase Policy ● 6 static groupings (services) (C) Ganesh Prasad, Eigner Pty Ltd
  • 203. High-Level Solution Diagram – Insurance (C) Ganesh Prasad, Eigner Pty Ltd
  • 204. Choreographed Process (C) Ganesh Prasad, Eigner Pty Ltd
  • 205. A Maze Game (C) Ganesh Prasad, Eigner Pty Ltd
  • 206. Allowed Movements (C) Ganesh Prasad, Eigner Pty Ltd
  • 207. Cell Identifiers – Identity Association ● A cell's location must not be derivable from its name or vice-versa (C) Ganesh Prasad, Eigner Pty Ltd
  • 208. The Design – Hypermedia Constraints (C) Ganesh Prasad, Eigner Pty Ltd
  • 209. Interaction at the start of the game (C) Ganesh Prasad, Eigner Pty Ltd
  • 210. Interaction in the middle of the game (C) Ganesh Prasad, Eigner Pty Ltd
  • 211. Interaction at the end of the game (C) Ganesh Prasad, Eigner Pty Ltd
  • 212. Managing Change (C) Ganesh Prasad, Eigner Pty Ltd
  • 213. The 70s ● Banking in a simpler (and more rigid) time (C) Ganesh Prasad, Eigner Pty Ltd
  • 214. Service Interfaces to Support Arbitrary Clients (C) Ganesh Prasad, Eigner Pty Ltd
  • 215. Variants of Similar Operations (C) Ganesh Prasad, Eigner Pty Ltd
  • 216. Standardised Variants, Abstract Interfaces (C) Ganesh Prasad, Eigner Pty Ltd
  • 217. Processes as Standardised Operation Variants (C) Ganesh Prasad, Eigner Pty Ltd
  • 218. Supporting a New Variant (C) Ganesh Prasad, Eigner Pty Ltd
  • 219. Deployment of Components (C) Ganesh Prasad, Eigner Pty Ltd
  • 220. A More Likely Scenario! (C) Ganesh Prasad, Eigner Pty Ltd