agile architecture in action - iasa itarc › webroot › documents › 40 › w11_jason_bloo… ·...

1

Copyright © 2015, Intellyx, LLC

1

Agile Architecture in Action

Jason BloombergPresident

[email protected]

@theebizwizard

Introducing 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 © 2015, Intellyx, LLC2

2

Bloomberg Agile ArchitectureMind Map


BAA Technique

• The Bloomberg Agile Architecture™ (BAA) Technique offers a way of thinking about and doing architecture that is laser-focused on business agility as the fundamental business driver

• Approach to Enterprise Architecture• Not a framework or a methodology• BAA Technique works with & simplifies TOGAF or

SAFe or Zachman etc.• Lays out a particular path through all the options

that leads to greater business agility


3

Cross-Cutting Architecture

• Organization, process, applications, data, infrastructure

• Role for Enterprise Architecture

• Wakeup call for EAs & their organizations

• Essential for addressing silos


Phot

o Cre

dit:

pen

guin

cake

sht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/pe

ngui

ncak

es/2

8316

6280

3/si

zes/

l

Architecting Human-Technology Systems

• Architecting technology isn’t enough

• You have to architect the people as well

• Organizational and process layers rightfully part of EA

• Business architecture also focuses on human behavior

• BAA streamlines and formalizes these approaches


Phot

o Cre

dit:

Jav

iM h

ttps

://w

ww

.flic

kr.c

om/p

hoto

s/84

5789

94@

N07

/

4

Architecting People?

• Governance: creating, communicating, and enforcing policies– Apply to both human & technology behavior– Policy-related processes

• Automated & lightweight• Focus on important policies

– Security– Regulatory compliance– Software interface standards


Not a traditional approach to governance!Not a traditional approach to governance!

Phot

o Cre

dit:

Dav

e Cat

chpo

le h

ttps

://w

ww

.flic

kr.c

om/p

hoto

s/ya

kety

yaky

ak/5

9132

5084

9/si

zes/

l

Agile EA & Architecture Frameworks

• Architecture frameworks (TOGAF, Zachman, DoDAF, etc.) do not adequately address business agility– Difficult to use properly– Can help achieve baseline

or specific business outcomes

• Take subtractive approach– You need to figure out

which bits to use• BAA Technique is additive

– Works within context of frameworksCopyright © 2015, Intellyx, LLC8

Phot

o Cre

dit:

Ste

phan

ie O

vert

on h

ttps

://w

ww

.flic

kr.c

om/p

hoto

s/sl

over

ton/

7303

5709

30/s

izes

/l

5

BAA Introduces “Meta” Thinking

• Remember, we’re architecting for change

• Agile architect doesn’t think about the thing, but about how it changes

• Metaprocesses– Processes for creating, managing,

changing processes• Metapolicies

– Policies for creating, managing, changing policies

– In other words, policies for how to do governance


Phot

o Cre

dit:

Ska

raCom

mun

http

s://

ww

w.f

lickr

.com

/pho

tos/

6379

4459

@N

07/6

1893

8185

1/si

zes/

l

Avoiding the Hall of Mirrors

• If a metaprocess is a process for changing processes, how do we change metaprocesses?

• Leads to infinite repeating rat hole– Not really a problem,

more of an illusion– Only takes 2 mirrors

to create illusion of infinity

• Generally have only 2 layers, top one is manual


Phot

o Cre

dit:

The

Int

eger

Clu

b ht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/in

tege

r_cl

ub/5

4482

8751

4/si

zes/

l

6

Introducing the BAA Maturity Metamodel


The Role of Maturity Models

• Coordinate efforts across the organization• Balance maturity across dimensions• Establish metrics for measuring maturity• In some cases,

compare maturity from one organization to another– Not appropriate for

architectural maturity


Phot

o Cre

dit:

Gus

tavo

Dev

ito

http

s://

ww

w.f

lickr

.com

/pho

tos/

devi

togu

stav

o/

7

Maturity Model vs. Maturity Metamodel

• Metamodel is a model for creating models• Use the BAA Maturity Metamodel to create your

own Maturity Model– May improve

over time– Even your

Maturity Model can mature!


Be iterative & iconoclasticBe iterative & iconoclastic

Phot

o Cre

dit:

rjr

gmc2

8 ht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/rj

rgm

c28/

Elements of BAA Maturity Model

• Dimensions (rows)– Organization,

Process, Information, Technology

– Broad EA categorizations

• Levels (columns)– Chaotic State, First-

Gen SOA/Centralized, Next-Gen SOA/Cloud-Centric, Agile Architecture

– Agile Architecture is a journey

– SOA is part of the story– You don’t have to hit all

the levels all the time


Phot

o Cre

dit:

Tob

y Fr

uge

http

s://

ww

w.f

lickr

.com

/pho

tos/

ybot

84/

8

Improving Maturity in Practice

• Always start with business priorities

• Maturity Model drives your Agile Digital Transformation Roadmap

• Moving up levels should represent your goals, not be goals in themselves

• Too difficult? Iterate!


Phot

o Cre

dit:

Set

h Saw

yers

htt

ps:/

/ww

w.f

lickr

.com

/pho

tos/

side

wal

k_fly

ing/

Iterating a BAA Initiative

• Each iteration (sprint, for example) is well-defined, practical, and manageable

• Leverage iterative best practice from your methodology of choice

• If your problem of the day is too difficult or risky, break up your phases into smaller iterations


Any goal, no matter how difficult, is achievable this way!

Any goal, no matter how difficult, is achievable this way!

Phot

o Cre

dit:

Pax

son

Woe

lber

http

s://

ww

w.f

lickr

.com

/pho

tos/

paxs

on_w

oelb

er/

9

Change at the Meta Level

• In fact, your entire architecture subject to change

• BAA is a meta-architecture: an architecture for building inherently dynamic architectures

• The key to thinking like a Bloomberg Agile Architect!


Phot

o Cre

dit:

UK M

inis

try

of D

efen

ceht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/de

fenc

eim

ages

/

IT is the Business

• BAA is technology-driven• The business of today’s enterprises

is IT– Subtract IT from a bank, what’s left?

• Too many organizations have adversarial relationships between business stakeholders & IT– Part of the natural chaotic state of

the enterprise• BAA seeks to realign business & IT

– Continuous business transformation


Phot

o Cre

dit:

Fam

Zoo

Sta

ff h

ttps

://w

ww

.flic

kr.c

om/p

hoto

s/fa

mzo

o/

10

Continuous Business Transformation

• With BAA there is no to-be architecture– Not in the physical sense

• Instead, the focus of the architecture is expecting and supporting ongoing change by specifying technology that is inherently flexible

• Architects must begin at the Meta layer


Phot

o Cre

dit:

Sha

wn

Car

pent

er h

ttps

://w

ww

.flic

kr.c

om/p

hoto

s/sp

cbra

ss/4

3883

9626

8/si

zes/

l

Digital Strategies & Chasing Rainbows

• Established enterprise challenges:– Innovator’s Dilemma – don’t want

to jeopardize existing revenues – Legacy Dilemma – how to become

a next-gen, “digital enterprise” given all the legacy technology?

• Disconnect between the next-gen digital vision and the reality of today’s IT

• Spending time and money on the former without a plan for dealing with the latter is simply chasing rainbows


Phot

o Cre

dit:

Moy

anBre

nnht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/ai

gle_

dore

/

11


21

Enterprise as Complex Adaptive System

Where’s Our Business Agility?

• Organizations must be responsive, resilient, and innovative

• Business agility is a property of the enterprise• People and technology can be flexible as well,

but we must architect our organizations to be agile


Phot

o Cre

dit:

Stu

art

Ber

wic

k ht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/la

plea

der/

7935

0796

2/si

zes/

l

12

Introducing Complex Adaptive Systems

• Systems of systems that exhibit emergent properties– Properties of system

as a whole• Component systems

can be human, technology, etc.

• Self-organizing


Phot

o Cre

dit:

Dir

ectD

ish

http

s://

ww

w.f

lickr

.com

/pho

tos/

1380

0911

@N

08/3

5577

8902

1/si

zes/

l

Enterprise as Complex Adaptive System

• Business agility is property of organization as a whole, hence an emergent property of the organization

• Enterprise is system of systems that exhibits emergent properties– System of people and

technology


Phot

o Cre

dit:

agu

2000

_de

http

s://

ww

w.f

lickr

.com

/pho

tos/

3812

3550

@N

00/1

6693

0597

/siz

es/o

/

13

Business Agility as Emergent Property of Enterprise

• We want our organizations to be agile

• Individual subsystems (people or technology) can be flexible, but business agility is a property of the enterprise (or possibly portions of the enterprise)

• Innovativeness, resilience, responsiveness also emergent


Phot

o Cre

dit:

fot

olog

icht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/fo

tolo

gic/

1161

3339

50/s

izes

/o/

Engineering a Complex System

• Architecture focuses on the overall design of a system– How all components of the system

must work together to achieve business goals

• Engineering focuses on the best way to build and run a system– Lifecycle best practices (quality

assurance, deployment, updates, etc.)– Compliance with architecture


Agile principle: respond to change over following a plan

Agile principle: respond to change over following a plan

Phot

o Cre

dit:

Bre

nt 2

.0 h

ttps

://w

ww

.flic

kr.c

om/p

hoto

s/br

entino

z/42

2129

1984

/siz

es/o

/

14

At the Heart of Agile Architecture

• Think of the enterprise as a system of systems– Component systems are people and technology

systems• We must architect the organization so entire

enterprise exhibits business agility

• We can only engineerbusiness agility via its component systems

• Change is constant & how changes to component systems affect the enterprise is unpredictable


Phot

o Cre

dit:

nic

kodo

hert

yht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/ni

ck-o

d/91

5119

1333

/siz

es/l

Complex vs. Traditional Systems

• Avoid emergent properties in traditional systems• Traditional system: given requirements, build

to requirements• Complex system: establish initial conditions

and rules for behavior of component systems, and emergence takes care of itself– Feedback loops are

common


Phot

o Cre

dit:

Fra

nco

Folin

ihtt

ps:/

/ww

w.f

lickr

.com

/pho

tos/

liven

atur

e/80

6466

0509

/siz

es/l

15

The Secret to Emergence

• Rules that affect behavior of component systems can be very simple

• Emergent behaviors often unpredictable

• Try something, see what happens, repeat

• Feedback loops & iterative approaches


Phot

o Cre

dit:

Jua

n Le

is h

ttps

://w

ww

.flic

kr.c

om/p

hoto

s/ka

ibar

a/46

3238

4645

/siz

es/l

Sound Agile to You?Sound Agile to You?

Attractors for Complex Systems

• Stable– Emergent behaviors die out or

never occur– Not applicable to enterprise

• Cyclical– System bounces between two or

more well-defined states– Also not applicable

• Chaotic– Unpredictable, few discernable patterns– “Normal” state for enterprise

• Agile– Exhibiting desired emergent behaviors


Phot

o Cre

dit:

And

ers

San

dber

g ht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/ar

enam

onta

nus/

2731

8066

9/si

zes/

o/

16

Architecting Complex Systems

• Coherence of system– If emerging behavior strays from desired outcome,

have pre-established means for bringing organization back in line

• Feedback loops– Gather & analyze data on emergent behavior to

correlate with initial constraints and determine next course of action

• Mimics natural selection– Favor desired behavior and discourage undesirable

behavior, and system will adapt to changed environment


Agility vs. Flexibility

• Flexibility is the ability of a component system to deal with change within a specified set of parameters– People can be flexible vs. rigid in

their decision making– Software can be flexible if it is

configurable to behave differently given different requirements


Phot

o Cre

dit:

Joe

Gol

dber

g ht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/go

ldbe

rg/4

3948

299/

size

s/o/

17

Does Flexibility Lead to Agility?

• If your people and your software are flexible, does that make your organization agile?– Necessary, perhaps, but

definitely not sufficient• Being able to change

inflexible software quickly doesn’t necessary make it flexible


Phot

o Cre

dit:

A.

Dra

uglis

http

s://

ww

w.f

lickr

.com

/pho

tos/

artd

raug

lis/4

1932

6126

6/si

zes/

l

Architecting Enterprise as Complex System

• Architect people as well as technology– Very different sets of activities

• Emergent behaviors often unpredictable– Continual adjustment necessary– Automation critical for ensuring agility

• Small changes to component system behavior may lead to significant emergent behaviors– Butterfly effect


Too slow and you’re not agile!Too slow and you’re not agile!

Phot

o Cre

dit:

Dig

anta

Talu

kdar

http

s://

ww

w.f

lickr

.com

/pho

tos/

naga

on/4

3945

8283

3/si

zes/

l

18

Essential Tool: Self-Organization

• Component systems of complex systems are generally self-organizing

• Traditional hierarchical organizational models limit or eliminate self-organization– “Tightly connected”

• “Skunk works,” startups, and DevOps organizations work best when self-organized– “Loosely connected”


Management challenge: when and howto facilitate self-organization

Management challenge: when and howto facilitate self-organization


36

Agile Software Architecture

19

The Agile Manifesto

Manifesto for Agile Software DevelopmentWe are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:

– Individuals and interactions over processes and tools

– Working software over comprehensive documentation

– Customer collaboration over contract negotiation

– Responding to change over following a planThat is, while there is value in the items onthe right, we value the items on the left more.


Sou

rce:

htt

p://

ww

w.a

gile

man

ifest

o.or

g

Context: Software Development

• Focus on small teams that crank out code

• Iterative, self-organizing, collaborative

• Focus on creating working software


Well-run Agile development means producing a lot of good software

quickly

Well-run Agile development means producing a lot of good software

quickly

Phot

o Cre

dit:

Phi

l Whi

teho

use

http

s://

ww

w.f

lickr

.com

/pho

tos/

phill

ieca

sabl

anca

/247

3728

872/

size

s/l

20

What about Architecture on Agile Projects?

• We don’t need no stinkin’ architecture!

• Architecture lumped in with documentation (less is more)

• Architects slow down developers

• Architects produce artifacts that aren’t Agile– Lead to extra work


Phot

o Cre

dit:

Yor

twht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/yo

rtw

/547

0226

807/

size

s/l

Widespread belief that Agile and Architecture don’t mix

Widespread belief that Agile and Architecture don’t mix

But we Do Need Architecture!

• Software architecture– Appropriate

modularization of code

– Selection of appropriate components & libraries

– Integration strategy• Systems architecture

– Scalability of distributed application– Cloud deployment issues– Availability, caching, etc.


21

Create Minimum Viable Architecture

• All documentation, artifacts, diagrams, etc. are means to an end

• Don’t architect more than the stakeholders want

• Problems:– Shortsighted– Leads to legacy

issues– Limits agility

Copyright © 2015, Intellyx, LLC41 Phot

o Cre

dit:

Cam

era

Eye

Phot

ogra

phy

http

s://

ww

w.f

lickr

.com

/pho

tos/

cam

era_

is_a

_mirro

r_w

ith_m

emor

y/66

2893

4195

/siz

es/l

Plan for Technical Debt

• Bad technical debt– Sloppy work that has to be cleaned up later– Rarely if ever a good idea

• Good technical debt– Intentional simplifications or missing functionality– Often specific to individual iteration/sprint– Well-planned resolution as within backlog/Kanban

board


Good technical debt an important part of Agile development

Good technical debt an important part of Agile development

22

Team Responsibility for Architecture

• Lean principle: everybody is responsible for everything

• Everybody should understand architecture

• Anybody may contribute or refactor architecture

• Adjust based upon skill sets


Phot

o Cre

dit:

Kri

s Kru

g ht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/kk

/297

9360

538/

size

s/l

Everybody isn’t a competent architect!Everybody isn’t a competent architect!

Avoiding “Ivory Tower” Architectures

• Agile software architecture reaction to Ivory Tower architects who don’t work directly with developers

• Team may have specialists in architecture– Involved day-to-day with

Agile team– Regular or constant

feedback on architectural artifacts


Phot

o Cre

dit:

Iai

n W

atso

n ht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/da

goat

y/47

0014

9799

/siz

es/l

23

Solicit Stakeholder Participation

• Stakeholder participation on traditional Agile projects focuses on functional requirements

• Stakeholder participation in architecture focuses on nonfunctional requirements

• Expect intractable stakeholders


Phot

o Cre

dit:

Bre

tt J

orda

n ht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/x1

bret

t/33

9856

5908

/siz

es/o

/

The Lesson of Scrum Buts

• Statements of the form:– “We want to follow Scrum BUT retrospectives

are too difficult SO we won’t do them.”• Important part of Agile

– Responding to change over following a plan!• Problem: not always a good idea

– “We want to be iterative BUT it’s too much trouble SO we’ll do all our development in one massive sprint.”

• How do you tell which is which?


24

Change-Case Agility Model

• Questions for your analysis– How much flexibility does your software need?– What features will be needed?– How flexible must

infrastructure be?– How dynamic will your

data be?– Etc.

• Must perform analysis at the meta level to avoid overbuilding


Phot

o Cre

dit:

Jef

f Bel

mon

te h

ttps

://w

ww

.flic

kr.c

om/p

hoto

s/je

ffbe

lmon

te/

The Challenge of Updating Software

• Cascading & complicated dependencies

• Requirement for coordinated updates

• Challenge updating consumers/clients out of your control

• Backward compatibility/ deprecated functionality challenges


Phot

o Cre

dit:

clk

ohan

http

s://

ww

w.f

lickr

.com

/pho

tos/

razz

mat

az/5

1649

8630

2/si

zes/

l

25

Instant Legacy

• Difficult to upgrade• Systems are

inflexible• Impossible to

replace• Difficult to

customize• Challenge to

integrate• Expensive over time


Phot

o Cre

dit:

LH

OO

N h

ttps

://w

ww

.flic

kr.c

om/p

hoto

s/lh

oon/

2288

3391

51/s

izes

/l

Extending the Agile Manifesto

• Individuals and interactions over processes and tools– As a system of people & technology,

the enterprise is more about people• Working software over comprehensive

documentation– Technology must actually work to

enable agility• Customer collaboration over contract

negotiation– Slice across the silos

• Responding to change over following a plan– Architect for change


Phot

o Cre

dit:

Mar

y M

argr

et h

ttps

://w

ww

.flic

kr.c

om/p

hoto

s/do

uble

-m2/

4384

5785

34/s

izes

/l

26

Scaling Agile for the Enterprise

• Enterprise Architecture context– Organization,

process, technology, and information

• Legacy context– Existing applications,

middleware, systems of record• Business focused, iterative, get stuff

to work, iconoclastic


Phot

o Cre

dit:

Bos

ton

Publ

ic L

ibra

ry h

ttps

://w

ww

.flic

kr.c

om/p

hoto

s/bo

ston

_pub

lic_l

ibra

ry/8

9621

0616

4/si

zes/

l


52

Bloomberg Agile Architecture in Practice

27

Revisiting BAA Layers of Abstraction


META Dealing with Change (metaprocesses, metapolicies, etc. )

DYNAMICAbstract Models (dynamic schemas, dynamic APIs,

etc.)

ABSTRACTED (LOGICAL)

Abstracted Technology (schemas, software interfaces, etc.)

PHYSICAL Technology (software, middleware, databases, etc.)

BAA Initiative Phase 0: Getting Prepared

• Understand business hot spots– Problems the business is willing to spend money to

solve• Understand as-is technology

– Focusing on problem areas – don’t get bogged down

• Understand political context for transformation– Transformation means

changing human behavior

• Clean up your mess!


Phot

o Cre

dit:

US G

eolo

gica

l Sur

vey

http

s://

ww

w.f

lickr

.com

/pho

tos/

usge

olog

ical

surv

ey/

28

Clean Up Your Mess

• Organizations with legacy issues who want Cloud, mobile, etc.– Lack business agility – Desperate need of

architecture • Focus initially on

establishing the appropriate separations of concerns

• Sketch out a roadmap – Tackle issues iteratively

• Establish baselineCopyright © 2015, Intellyx, LLC55

Phot

o Cre

dit:

Jef

frey

Bea

llht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/de

nver

jeffre

y/19

5040

9800

/siz

es/l

Good role for TOGAF

Good role for TOGAF

Physical Layer

•What are your:–Current assets?–Current problems?–Current business drivers?–Political context?


PHYSICAL Technology (software, middleware, databases, etc.)

29

BAA MM: Technology

Chaotic StateFirst-Gen

SOA/CentralizedNext-Gen

SOA/Cloud-Centric Agile Architecture

Coupling

Tight coupling/point-to-point integration predominant

Modest loose coupling based on Service contracts

Uniform interface for HTTP interactions Dynamic Coupling

APIs Rats' nest Web Services REST-based Dynamic APIs

PlatformLegacy middleware ESB

RESTful/stateless intermediaries

Tool-building platform


Meta Layer

•Top-down & bottom up at the same time

•Architect should always focus on how things change


META Dealing with Change (metaprocesses, metapolicies, etc. )

30

Abstracted (Logical) Layer

• Is SOA in place?– No really, what do you mean by SOA?

• How do you abstract data?• What is role of the process abstraction in

your organization?• Look for areas of inflexibility• Keep an eye on agility drivers

– What should be inherently flexibleCopyright © 2015, Intellyx, LLC59

ABSTRACTED (LOGICAL)

Abstracted Technology (schemas, software interfaces, etc.)

Dynamic Layer

• Core to the BAA Technique–Least mature part of technique at

organizations overall• Where much of your work will fall• Expect gradual progress as your

architecture matures


DYNAMICAbstract Models (dynamic schemas, dynamic APIs,

etc.)

31

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 ChangeArchitect for Change

Phot

o Cre

dit:

Pau

lioG

4eor

dio

http

s://

ww

w.f

lickr

.com

/pho

tos/

paul

ioge

ordi

o/23

0870

3486

/siz

es/l

Dynamic Coupling

• Tight coupling– Must code all nodes at

once• Loose coupling

– Interfaces abstract underlying code

• Dynamic coupling– Interfaces resolved at run

time


Phot

o Cre

dit:

Gor

don

Rob

erts

on h

ttps

://w

ww

.flic

kr.c

om/p

hoto

s/go

rdon

_rob

erts

on/5

5076

4573

8/si

zes/

l

32

BAA MM: Information

Chaotic StateFirst-Gen

SOA/CentralizedNext-Gen

SOA/Cloud-Centric Agile Architecture

Big Data Isolated BI apps Big Data pilotsStrategic Big Data initiatives

Data-driven feedback across organization

Semantics Fully siloed

Limited fixed abstractions that support some interoperability

Emerging RESTful semantic media types

Abstracted semantic resolution

Syntax Siloed data models

MDM/canonical data model initiative in progress

Widespread use of schemaless data Dynamic Schemas


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


Phot

o Cre

dit:

Juh

anSon

inht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/ju

hans

onin

/231

7185

234/

size

s/l

33

The Schemaless Data Trap

• JSON often favored over XML because it is schemaless

• No fixed metadata representing data syntax or semantics

• Problem: interpretation of data falls to underlying logic


Another shell gameAnother shell game

Phot

o Cre

dit:

Van

essa

Dua

libht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/re

rinh

a/

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


Phot

o Cre

dit:

neo

fito

http

s://

ww

w.f

lickr

.com

/pho

tos/

neof

ito/

4037

4375

04/s

izes

/z/

34

Resolve Dynamic Schemas at Run Time

• Abstract representations of semantic metadata

• Platform resolves metadata references at run time

• Perhaps the most advanced (and powerful) part of the BAA Technique


Late Binding

• Mechanism in which the method being called upon an object is looked up by name at runtime (Wikipedia) – Useful in Microsoft’s

Component Object Model (COM), because compilers wouldn’t have to reference libraries at compile time

• Related to dynamic dispatch– Selecting which imple-

mentation of a polymorphic operation to call at runtime


Phot

o Cre

dit:

Phi

lo N

ordl

und

http

s://

ww

w.f

lickr

.com

/pho

tos/

philo

n/25

2196

7364

/siz

es/z

/

35

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 timeCopyright © 2015, Intellyx, LLC69

Phot

o Cre

dit:

Ral

ph R

epo

http

s://

ww

w.f

lickr

.com

/pho

tos/

ralp

hrep

o_ph

otol

og/4

0792

8557

4/si

zes/

l

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


Phot

o Cre

dit:

gei

shab

oy50

0 ht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/ge

isha

boy5

00/2

9151

5599

8/si

zes/

m/

36


71

Supporting Digital Transformation with

BAA

Who is the Digital Professional?

• Old days:– Web programmers, graphic

designers, UI/UX people, information architects

• Today:– All of the above, plus

marketing/product people, Agile teams, operations people, enterprise architects, etc.


If you touch something your customer touches, you’re a digital professional

If you touch something your customer touches, you’re a digital professional

Phot

o Cre

dit:

Tre

vG

rant

htt

ps:/

/ww

w.f

lickr

.com

/pho

tos/

trev

gran

t/

37

The Importance of the Consumer

• Consumer behavior & preferences driving digital– Even for B2B providers

• The Facebook effect– Everybody expects

personalization, asynchronous interaction, & high performance


The Buck Stops with the ConsumerThe Buck Stops with the Consumer

Omnichannel: Retail’s Digital Challenge


The customer sees only one channelThe customer sees only one channel

Phot

o Cre

dit:

Mik

e M

ozar

t ht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/je

eper

smed

ia/

38

Omnichannel: Beyond Retail

• Healthcare– Phone/tablet/desktop/medical device integration

for physicians• Utilities, logistics,

etc.– Field technicians

• Manufacturing– Factory controls

• Too many others to list!


Phot

o Cre

dit:

Bak

bone

iPad

Hol

der

http

s://

ww

w.f

lickr

.com

/pho

tos/

ipad

_acc

esso

ries

_hol

der/

Optimization Pitfall


Phot

o Cre

dit:

Jas

on B

loom

berg

The Problem of Local OptimaThe Problem of Local Optima

39

Process for Innovation?


Disrupt Innovate

Innovation is not a typical business process!

Innovation is not a typical business process!

How do You Manage?

• Each Line of Business/Division has its own goals & business outcomes

• LoB Management drives toward optimizing those outcomes

• Maximize shareholder value/profit/revenue

• Better-Faster-Cheaper, then repeat


Phot

o Cre

dit:

Ken

ny L

oule

http

s://

ww

w.f

lickr

.com

/pho

tos/

kwl/

40

The Problem with Better-Faster-Cheaper

• Digital BFC pushes technology to its breaking point

• Technology team must focus on dealing with failure

• Resilience becomes top priority• Requires holistic view of organization because

weakest link could be anywhere


Phot

o Cre

dit:

Frits

Ahl

efel

dt-L

aurv

ight

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/hi

king

artist

/

Organizing for Innovation

• Move from high connectivity to low connectivity– Provide flexible technology– Autonomous, self-

organizing teams– Teams must cut across

organizational silos


Phot

o Cre

dit:

Mel

issa

Mar

ques

htt

ps:/

/ww

w.f

lickr

.com

/pho

tos/

mel

issa

mar

ques

/

41

What about the Data?

• Huge quantities of Big Data about customer preferences & behavior every minute

• No end of fancy tools for analyzing those data

• For every Sony Walkman or Apple iPad, hundreds of less successful innovations

• With all these Big Data, why aren’t we better at innovating?


Phot

o Cre

dit:

Asi

mBija

rani

http

s://

ww

w.f

lickr

.com

/pho

tos/

asim

zb/

Data & Innovation at Cross Purposes

• Data analysis better suited for optimization than innovation

• As we leverage data to get better at marketing, we’re making decisions that stifle innovation

• Incessant march toward “better-faster-cheaper” making us more brittle, not more innovative


Phot

o Cre

dit:

Dav

id P

rasa

d ht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/33

6710

02@

N00

/

42

Recipe for Agility


Mistake #1: Focusing Digital on Technology

• Easier than changing organization & culture• Leads to “tone deaf” Digital efforts

– Unresponsive Mobile– Social Media that put off or anger customers– Customer “service” snafus


43

Mistake #2: Shifting Digital Away from IT

• Leads to Digital efforts disconnected from IT

• ‘Legacy’ systems of record act as limitations

• No effective cooperation between Digital & IT (CDO & CIO for example)

• Leaving legacy behind moves organization awayfrom business agility


Phot

o Cre

dit:

Erik

Pitt

ihtt

ps:/

/ww

w.f

lickr

.com

/pho

tos/

epitti/

“Demise” of Enterprise IT Department

• Out:– IT as cost center– IT as gatekeeper, slowing

things down– IT as owner of all technology

• In:– IT as service

provider– IT as

marketplace– IT as facilitator

of security, governance, and access to systems of record


Phot

o Cre

dit:

Bill

Bra

dfor

d ht

tps:

//w

ww

.flic

kr.c

om/p

hoto

s/m

rbill

/

44

Better Way to Manage

• Build cross-organizational teams• Leverage data to

understand when to optimize and when to innovate

• Embrace disruption• Give people the tools

they need and get out of their way


Phot

o Cre

dit:

Phi

lip L

eara

http

s://

ww

w.f

lickr

.com

/pho

tos/

phill

eara

/

Jason BloombergPresident, Intellyx

[email protected]

@theebizwizard

Thank You!


Area Dimension Level 0 Level 1 Level 2 Level 3

Chaotic State First-Gen SOA/Centralized Next-Gen SOA/Cloud-Centric Agile Architecture

OrganizationBusiness Transformation None IT as Service provider Cloud-driven ContinuousOrganizational Governance Hierarchical management

Limited Service domain management Digital vs. traditional

Coordination of emergent behaviors

IT Organization Siloed by division and app Cross-departmental Service reuse DevOpsBizDevOpsContinuous Delivery

Process Business Process Spotty, inflexible automation Limited Service composition Cloud-friendly BPMDynamic customization & personalization

Governance Process Automation None or scattered

Security & Service abstraction processes automatedSOA Repository

RESTful integration with GRC tooling Dynamic constraint satisfaction

Architecture Rigid and artifact-driven Centralized SOA Team Decentralized SOA teamsCoordination of emergent behaviors

Information Big Data Isolated BI apps Big Data pilots Strategic Big Data initiativesData-driven feedback across organization

Semantics Fully siloedLimited fixed abstractions that support some interoperability

Emerging RESTful semantic media types Abstracted semantic resolution

Syntax Siloed data modelsMDM/canonical data model initiative in progress

Widespread use of schemaless data Dynamic Schemas

Technology CouplingTight coupling/point-to-point integration predominant

Modest loose coupling based on Service contracts

Uniform interface for HTTP interactions Dynamic Coupling

APIs Rats' nest Web Services REST-based Dynamic APIs

Platform Legacy middleware ESB RESTful/stateless intermediaries Tool-building platform

Bloomberg Agile Architecture™ Maturity Metamodel

Copyright © Intellyx LLC. Permission to distribute granted as long as no changes are made and this notice remains. For more information email [email protected].

agile architecture in action - iasa itarc › webroot › documents › 40 › w11_jason_bloo… ·...

Documents