This document discusses dynamic coupling and semantic interoperability. It argues that existing approaches to integration and interoperability are too rigid and inflexible, limiting business agility. The document introduces the concept of Bloomberg Agile Architecture, which aims to drive business agility through dynamic schemas, extreme late binding, and abstracting integration details. This is achieved by modeling metadata at design-time and resolving it dynamically at run-time based on business context.

1. Dynamic Coupling
Copyright © 2014, Intellyx, LLC
1
The Pot of Gold
under the
Semantic Rainbow
Jason Bloomberg
President
jason@intellyx.com
@theebizwizard

2. About Jason Bloomberg
• President of Intellyx, Global Advisory Firm
focused on Digital Transformation
through Architecting Agility
– Formerly with ZapThink 2001 - 2013
• Contributor to Forbes
– http://www.forbes.com/sites/jasonbloomberg
• Created the Licensed ZapThink
Architect (LZA) SOA course &
associated credential
• Run the Bloomberg Agile Architecture
Certification Course around the world
• Buy my newest book,
The Agile Architecture Revolution
• Include @theebizwizard in tweets Copyright 2 © 2014, Intellyx, LLC

3. Human Interactions
Always Have Context
Copyright 3 © 2014, Intellyx, LLC
Photo Credit: The Lex Talionis https://www.flickr.com/photos/65251861@N07/5988080131/sizes/o/
Every department, team,
group, or interaction has its
own business context

4. Traditional Apps Have their
Own Business Context
Copyright 4 © 2014, Intellyx, LLC

5. Don’t Shoehorn your
Data
Shoehorning information into techie ideal of
canonical data model woefully unrealistic
Copyright 5 © 2014, Intellyx, LLC

6. Why Semantic Interop
has been Out of Reach
• Existing technology
approaches have
been too inflexible
• Require a more
agile approach
• Not just about
technology
We require Agile Architecture
Copyright 6 © 2014, Intellyx, LLC

7. What is Bloomberg Agile
Architecture?
• Bloomberg Agile
Architecture™ reinvents
Enterprise Architecture
(EA) to drive business
agility across the
organization
• New architecture paradigm
• EA technique focused on
architecting agility
Copyright 7 © 2014, Intellyx, LLC

8. BAA Maturity Metamodel
Copyright 8 © 2014, Intellyx, LLC

9. BAA Maturity Metamodel
Copyright 9 © 2014, Intellyx, LLC

10. Loose Coupling
• Abstract underlying
code with contracted
interface
• Separation of concerns
between consumers &
providers
• Can change underlying
code without breaking
interaction, as long as
endpoints comply with
contract
Copyright 10 © 2014, Intellyx, LLC
Photo Credit: Ray Foster https://www.flickr.com/photos/94418464@N08/9631393073/sizes/c/

11. Contracted Interfaces
• We must somehow contract
interfaces in order to abstract
the underlying functionality
– Provides loose coupling
– Some measure of flexibility
• Contracts (including REST’s
uniform interface) are always
a compromise
– Interface itself now lacks
flexibility
– IT becomes limiter of
business agility
Copyright 11 © 2014, Intellyx, LLC
Photo Credit: MLB Fan Cave http://mlb.mlb.com/fancave/

12. Pros & Cons of Loose
Coupling
• Pros
– Can make some changes
without breaking interaction
– Increases flexibility of
distributed computing
interactions
– Supports Service
discoverability & late binding
• Cons
– Inflexible interfaces limits
business agility
– Challenges versioning
Services
Copyright 12 © 2014, Intellyx, LLC
Photo Credit: Steven Depolo https://www.flickr.com/photos/stevendepolo/4482491295/sizes/o/

13. The Importance of a
Uniform Interface
• Web Services have custom operations
– Unwanted tight coupling
– Vendor incompatibilities
• REST has only HTTP verbs as operations (GET,
POST, PUT, and DELETE)
– HTTP verbs, URI structure,
and Internet Media Types
fully define API
– Dramatic simplification of
integration
Copyright 13 © 2014, Intellyx, LLC
Photo Credit: DVIDSHUB https://www.flickr.com/photos/dvids/6343684939/sizes/z/

14. Deep Interoperability
Copyright 14 © 2014, Intellyx, LLC

15. Challenges of HATEOAS
• Central architectural constraint of REST
• How to program client to obtain necessary
metadata via hyperlinks?
• Hypermedia-based data
formats area of active
research
– Many immature options,
no clear best practice
Copyright 15 © 2014, Intellyx, LLC
Photo Credit: Horia Varlan https://www.flickr.com/photos/horiavarlan/4439643419/sizes/z/
Hypermedia as the Engine of
Application State

16. HATEOAS and
Affordances
• Resolve URIs, process
requests via a uniform
interface
• Clients render
representations that
conform to standard
Internet Media Types
– Generalized affordances
– Doesn’t matter what URI,
request, or representation
as long as they conform to
the constraints of the
architecture
Copyright 16 © 2014, Intellyx, LLC
Photo Credit: EraPhernalia Vintage https://www.flickr.com/photos/eraphernalia_vintage/3034341310/sizes/o/

17. Does REST Provide Deep
Interoperability?
• Deep Interoperability
– Endpoints automatically negotiate
basis for integration
– Transport & message protocols, API
contracts, data schemas
• HATEOAS potentially allows for
deep interoperability
– Difficult to program in practice
– How to program software client to
know how to follow hyperlinks to
obtain necessary metadata?
Copyright 17 © 2014, Intellyx, LLC
Photo Credit: plaisanter https://www.flickr.com/photos/plaisanter/5360976781/sizes/z/

18. Custom Media Types
• REST loose coupling depends upon Standard
Internet Media Types (formerly called MIME
types)
• Internet Media Types designed for display
metadata
– HTML, PDF, etc.
• REST’s answer for custom
data formats are Custom
Media Types
• Introduce tight coupling
– How to communicate, maintain, & version them?
Copyright 18 © 2014, Intellyx, LLC
Photo Credit: Pen Waggener https://www.flickr.com/photos/epw/4341554771/sizes/z/

19. Automating HATEOAS
• Hypermedia affordances depend upon HATEOAS
being handled manually
• A person changes the state of their application
by clicking hyperlinks
• Code an arbitrary piece
of software to serve as
the RESTful client
– May not have a user
interface
– Knows how to follow
hyperlinks to gather all
the metadata it needs to understand how to
behave Copyright 19 © 2014, Intellyx, LLC
Photo Credit: Chad Miller https://www.flickr.com/photos/chadmiller/136700905/sizes/o/

20. The Agility Platform
Your
Application
Your
Application
Application-
Building Tool
Your
Application
Application-
Building Tool
Copyright 20 © 2014, Intellyx, LLC
Tool-Building
Platform
Automated HATEOAS in Action

21. BAA Layers of Abstraction
META Dealing with Change (metaprocesses, metapolicies, etc. )
DYNAMIC Abstract Models (dynamic schemas, dynamic APIs, etc.)
ABSTRACTED
(LOGICAL)
Abstracted Technology (schemas, software interfaces,
Copyright 21 © 2014, Intellyx, LLC
etc.)
PHYSICAL Technology (software, middleware, databases, etc.)

22. Working with Abstract
Models
• Abstracts choice of
schema
• Abstracts choice of API
contract
• Abstracts semantic
context
Copyright 22 © 2014, Intellyx, LLC
Photo Credit: Tony Calrns https://www.flickr.com/photos/tonycairns/14731782052/sizes/l
Resolve to logical models at run time

23. Supporting Abstract
Models in Software
• Tool-building platform
(business agility platform)
– All affordances, affords tool-building
capabilities
• Application-building tool
– Affords application-building
capabilities to non-developers
– Rich UI support
– Non-imperative logic
• Event-driven, process-centric,
and/or rules-based, for
example
Copyright 23 © 2014, Intellyx, LLC
Photo Credit: ellenm1 https://www.flickr.com/photos/ellenm1/6489345851/sizes/l

24. Assembling the Pieces of
Agile Architecture
• Architecting for change
requires working at higher
levels of abstraction
• Abstract models resolvable
to capabilities at run time
– Dynamic coupling
– Dynamic schemas
– Extreme late binding
Architect for Change
Copyright 24 © 2014, Intellyx, LLC
Photo Credit: Paulio G4eordio https://www.flickr.com/photos/pauliogeordio/2308703486/sizes/l

25. Dynamic Coupling
• Tight coupling
– Must code all nodes at
once
• Loose coupling
– Interfaces abstract
underlying code
• Dynamic coupling
– Interfaces resolved at run
time
Copyright 25 © 2014, Intellyx, LLC
Photo Credit: Gordon Robertson https://www.flickr.com/photos/gordon_robertson/5507645738/sizes/l

26. Dynamic Schemas
• Rigid data schemas
– Entity-Relational
Model, XML Schemas
• Schemaless data
– Problem of implied
schemas
• Dynamic schemas
– Metadata modeled at
design time, resolved
at run time
Copyright 26 © 2014, Intellyx, LLC
Photo Credit: Juhan Sonin https://www.flickr.com/photos/juhansonin/2317185234/sizes/l

27. Dynamic Schemas
• WSDL files, URIs, HTTP verbs, and
Internet Media Types don’t
contract message semantics
• Metadata describing such
semantics scattered about
– Reintroduces tight coupling &
inflexibility
• Dynamic schemas abstract all
such semantic metadata in a
consistent way
Copyright 27 © 2014, Intellyx, LLC
Photo Credit: neofito https://www.flickr.com/photos/neofito/4037437504/sizes/z/

28. How Late is your Binding?
• Early binding
– Traditional integration
• Late binding
– Web Service discovery
– Content-based routing on
ESBs
– DNS resolution for RESTful
endpoints
• Extreme late binding
– Fully dynamic discovery
– Resolve URIs & metadata
references in real time
Copyright 28 © 2014, Intellyx, LLC
Photo Credit: Ralph Repo https://www.flickr.com/photos/ralphrepo_photolog/4079285574/sizes/l

29. Extreme Late Binding
• Metadata-driven, late-bound
schemas
• Schemas (and all other
metadata) bound in real
time
– Across the organization
– Regardless of change
• Business entities maintain
separate, dynamic business
contexts
Copyright 29 © 2014, Intellyx, LLC
Photo Credit: geishaboy500 https://www.flickr.com/photos/geishaboy500/2915155998/sizes/m/

30. Getting to Agile
Architecture
Copyright 30 © 2014, Intellyx, LLC

31. Thank You!
Jason Bloomberg
President, Intellyx
jason@intellyx.com
@theebizwizard