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