This is the full slide pack containing all the slides from my all day workshop on Dependency-Oriented Thinking. If people don't have the patience to read the 264 page document (http://slidesha.re/1cPwPD2), they can flip through this first.

1. I used to think that REST had no contracts. After I read 'RESTful Web APIs' by Leonard Richardson and Mike Amundsen, I realise how much effort has gone into supporting 'dynamic contracts'. Look up the book, especially the section on 'profiles', and all the new standards like XMDP, ALPS, JSON-LD, Collection+JSON, etc. 2. It is not true that 'REST exposes resources of services for clients to orchestrate'. The design of 'resource' is itself an abstraction that hides the internals. I have mentioned to you before that we can have a 'resource' called 'eligible-customer', which does not correspond to a physically distinct set of records in any internal table. It requires the application of business rules to determine who is an eligible customer. There are any number of such abstractions that REST allows, so this criticism is unfair. Also, REST is not Distributed Objects. It does not pass around object references to remote clients. It explicitly deals with representations (like DTOs), with the understanding that these are to be applied in some way to resources to effect changes. 3. Yes, both the 'front' and 'back' of services are important. Slides 100, 101, 141, 142, 143 and 144 should address this idea.

I generally like the precision and quality of the content and your 'softer' dependency on REST.

I would however note that WSDL should not be viewed as 'the service contract' but 'a' contract (as in one of many) between a service and a group of consumers. A service can expose as many WSDLs as it needs (to form specific contracts). A contract is always better than no contract (say like REST) because it enables for formal reasoning (access, validation, ...).

The true usage pattern of WSDL is many WSDLs for a single service implementation.

What I see critically missing though in your presentation is that a service has two sides (see my presentation on Service-as-a-Software, the other SaaS, http://www.slideshare.net/jdubray/service-asasoftware)

I understand that the industry has solely focused on service implementations and service consumers. In reality, a 'service' is just a middle-tier, even in the physical world. We should walk away from 'services' as a black box (reinforced by REST which mistakenly exposes the resources of the services for the client to orchestrate).

A service is a set of resources (soft or hard) and skills (machine or people) that governs a consistent outcome of activities.

The 'back' of a service is as important as the 'front'. Hence the way you design the back of a service, in relation to its consumable interface is as critical as the consumable interface itself. The back of a service should be designed for onloading / offloading dependencies easily.

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

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

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

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

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

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

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

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

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

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

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

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

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

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