SPEARS: A Deconstructed Software Architecture

1
SPEARS A Deconstructed Software Architecture
Eben HewittBangaloreNovember 3-4, 2009
2
goal

• Illustrate the underpinnings of a deconstructed
  software architecture

Perhaps something has occurred in the history of
the concept of structure that could be called an
"event".
3
who i am

• Architect at a multi-billion dollar US retailer
• Speaker on SOA at JavaOne, others
• Interviewed on SOA by InfoQ
• Author of 5 books including Java SOA Cookbook
  (OReilly, 2009)
• Also contributor to 97 Things Every Software
  Architect Should Know (OReilly, 2009)
• Other contributors include Gregor Hohpe, Bill de
  hÓra, Neal Ford, editor Richard Monson-Haefel
• Technical Reviewer for multiple books including
  upcoming RESTful Web Services Cookbook
• Many certifications in Java, Web Services, TOGAF
• Studied Continental Theory including
• Post-Structuralism, Deconstruction in
  Graduate School

4
Whats the Problem?

• Complexity
• Expense
• Reliability
• Manageability
• Time to Market

organizations which design systems ... are
constrained to produce designs which are copies
of the communication structures of these
organizations --Melvin Conway
5
Our Answers

• Project Manager-types proliferate strategies
• XP, Scrum, TDD, Kanban
• Programmer-types proliferate frameworks
• Much less focus on domain
• Domain Driven

6
Software Fashions

• 1950-60s Program as Text
• Grace Hopper FLOW-MATIC, COBOL
• Kristen Nygaard runs Simula 67 on UNIVAC
• Easier, ? talk in language of the business
• In the future, there will be no programmers!
• 1970-80s Program as Objects
• More Reliable Reusable,
• ? map real world phenomena
• 1990s Program visually
• Easier, ? drag and drop
• In the future, there will be no programmers!
• 2000s Program as Service (SOA)
• Simpler, because your programs align
• with the business
• Web Services unprecedented complication

7
Agenda

• A Few Words on/about/around Hypertext

8
Ted Nelson Hypertext
I believe Tim thinks he made my ideas practical,
whereas I think he oversimplified them-- with
today's extreme complexity as the result.

• By 'hypertext,' I mean non-sequential writing
  text that branches and allows choices to the
  reader
• --Ted Nelson
• Nelson wrote in 1965 of Literary Machines,
  computers that would enable people to write and
  publish in a new, nonlinear format, which he
  called hypertext.
• --Tim Berners-Lee, Weaving the Web
• His CV cites Principle Software Designer Xanadu
  literary structure and software architecture
• In 1981 Ted Nelson published Literary Machines,
  a non-linear book

9
Hierarchy

• The Internet itself is fundamentally
  non-hierarchical
• No one owns or controls it
• It is distributed, de-centralized
• We use linear means to produce a non-linear
  format
• This produces accidental complexity
• Our answer to this complexity is more tools of
  the same kind
• XML and OO languages impose hierarchy on systems
• We call this the business domain model
• This is an up-and-down structure
• We use hierarchy to determine system composition
• Current tools cannot represent cross-connection,
  interpenetration, overlap, or the other tangles
  of the real world
• --Ted Nelson, Geeks Bearing Gifts

10
The Real World

• The Real World is very complex
• Our answer to dealing with complexity is always
  to try to make it simpler
• This creates accidental complexity
• We then need to add more tools of the same kind
• Which ultimately means that we keep moving the
  problem

11
Agenda

• Deconstruction in 25 Words or Less

12
Jacques Derrida

• French Philosopher, father of Deconstruction
• 1966, Johns Hopkins University gives paper
  called Structure, Sign and Play in the Discourse
  of the Human Sciences
• Examines the structurality of structure
• The history of philosophy is a series of
  replacements of the center
• 1967 publishes 3 books including Of Grammatology
• He will publish more than 60 books before his
  death in 2004

13
Signs in Deconstruction

• Everything is mediated by signs
• We operate entirely within a codification of
  signifiers and signifieds
• The only thing knowable is symbolized,
  constructed experience
• A sign is understandable only because of
  difference from other signs
• Texts cannot communicate an authors intention

14
Basic Ideas in Deconstruction

• Shows how two opposing terms
• Rely on each other conceptually
• Are similar
• Are metaphorical
• Meanings are not stable, decidable, or universal
• meanings can be parsed in many ways and viewed
  differently within a variety of contexts
• Does not show that texts are meaningless,
• but rather overflowing with (multiple, often
  conflicting) meaning

15
How to Deconstruct a Textan embarrassing
over-simplification

• Analyze a text for conceptual oppositions
• speech/writing, presence/absence, poison/remedy,
  surplus/lack, nature/culture
• Find how one of the terms has been privileged
• May be considered more normal, general,
  culturally preferred, self-evident,
  valuable, true
• Look for what has been overlooked, suppressed, or
  marginalized
• Show how the unprivileged term has unacknowledged
  significance
• Look for multiple meanings of key terms to show
  how the text actually supports opposing
  arguments

16
Iterability the opening out of a marks
structure, the partition and redistribution of
the unitary identity its former context had
secured

• Dissemination attempts to disclose the
  contingency of meaning
• not to close it
• brings out the play between surplus and lack
  within signification with no prospect of
  stabilizing or closing it
• Meaning is constructed, therefore deconstructable

17

• Deconstruction Applied to Other Fields

18
Deconstruction in Building Architecture

• Architecture is a language, capable of
  communicating meaning and can be treated by
  methods of linguistic philosophy
• Any architectural deconstruction requires the
  existence of a particular archetypal construction
• a strongly-established conventional expectation
  to play flexibly against
• Does not follow modernisms adage form follows
  function.
• Exhibits fragmentation non-linear process of
  design
• Apparent non-Euclidean geometry
• May appear disharmonious
• wide variety of building materials and
  geometrical shapes used
• May have irregularity, flow, marked flexibility
• as Nature does
• Buildings may look unfinished, about to collapse
  or improvised
• they appear made of energy

19
Deconstructed Buildings
MITs Strata Center Cambridge, US
Guggenheim Museum Bilbao, Spain
RESIDENTIAL
Inifinity Tower Dubai
OFFICES
Walt Disney Concert Hall LA, US
Vietnam Veterans Memorial
TEXTUAL
Turning Torso Malmo, Sweden
20
Deconstruction in Culinary Arts
Bloody Mary

• Contains all ingredients of original
• But perhaps in different form
• Ingredients prepared individually
• So you can truly taste each component
• Components come together only in final
  presentation
• After eating the dish, you have the effect of
  eating the original
• Intermittent flavors of the constituent elements
  mingle with the remembered taste of the unified
  dish
• Anthony Bourdain 

Tomato Soup Grilled Cheese
Caesar Salad
Pina Colada
21
Deconstruction in Law

• it attempts to discover how conceptual
  oppositions are related to the contexts that give
  them force and meaning.
• JM Balkin, Yale Law Professor, author of Cultural
  Software
• Look for what has been overlooked, suppressed, or
  marginalized
• Show how they have unacknowledged significance
• Look for loose threads that at first glance
  appear peripheral yet often turn out to undermine
  or confuse the argument.

22
Deconstruction has Practical Importance in

• Philosophy
• Examine how we ab/use language so we can clarify
  our concepts
• Culinary Arts
• Taste the same food in new ways, reinvent to be
  at once new and familiar, to delight
• Law
• Improve justice system by unraveling
  social/political agendas underpinning its
  constructs
• Buildings
• Give beauty and thought-stirring energy to the
  places we inhabit
• Software

23
My Assertion
We seek ease simplicity because of the
enormous accidental complexity that is a direct
result of perpetuating the fantasy of
rationality, stability, determinacy,
close-ability, and intention in domains

• Our approaches to software have not addressed the
  root problems of indeterminacy, fluidity,
  contextualization, and the hierarchical gap
• We have been moving the problem, using the same
  assumptions about the world
• and the cycle repeats, disguised in a new fashion

24

• Can deconstruction help us build better software?

25
Simplicity/Complexity Deconstructs

• Simplicity is privileged
• Causes accidental complexity
• Often moves the problem
• The world our systems seek to represent is
  complex
• We need to right-size our complexity
• Not try to eliminate it
• Make it the size shape that actually works for
  us

26
Tier-rany

• Simple!
• Application Tier is the center, home of
  business logic closed meanings
• Business Logic deconstructs
• This is the magical center where everything
  happens
• We demand cohesion of our domain objects, less so
  of our architecture
• Enterprise concerns are marginalized
• Complexity moved to ETL, Monitoring

27
Presentation/Application Deconstructs

• The Presentation Tier is more automated, with
  more options, than ever
• XForms, RSS, RDF, Microformats
• Is there such a thing anymore?
• What accidental complexity do we incur by
  maintaining this (false) opposition?

28
Other Binary Oppositions that Deconstruct

• Business/IT
• Ahem.

29
So What Does a Deconstructed Software
Architecture Look Like?
Time is the longest distance between two
places --Tennessee Williams
30
SPEARS DSA Services, Processes, Events, Agents,
Rules, Semantics

• Analyze with Deconstruction
• Disassemble application tier
• Disassemble data tier
• Variety of platforms fit to purpose
• Contexts include state, RDF, RSS, images, XForms
• Represent domain with Events, Semantically
• Move business logic into rules engine, CEP/ESP,
  access via event services
• Build an Event-Driven Architecture on SOA
• ESB, Policy Brokers virtualize services
• Central controller ? choreography

31
Deconstruction in Software Analysis

• All software domains are potentially
  deconstructable
• Architect as textual analyst
• Instead of suppressing the indeterminacy of
  meanings, embrace it
• Domain Objects ? Terms sous rature
• Domain Objects ? Events
• Dont ignore Contexts
• Find a supporting structure
• that works with, instead of against, this
  fluidity
• sufficiently decoupled and flat to work
  withinstead of againstthe de-stabilized
  meanings and series of contexts

32
Application Disassembly

• Single, monolithic app (EAR) ? many contexts
• Search, Order, Appointments, Tracking
• Everything in App Server ? simple adapter to
  Event Services
• App Logic ? configurable business rules
• Business Logic, Routing, Analytics, Event
  Handling

33
Benefits of Application Disassembly

• Can scale individual contexts separately
• Best opportunity for asynchronous agents
• High cohesion of architectural elements
• Events allowed to operate in a variety of
  contexts
• Reduced ETL (an accident of focusing on
  simplicity and closing meanings)
• Improved near-time BI

34
Data Disassembly

• Consistency at any cost ? eventually consistent
• Everything RDBMS ? Storage fit to context
• XML/Object/Document Databases, Distributed
  Hashtables
• Non-Relational, Columnar databases
• Partition data
• Transactional data in one cluster
• Non-transactional data separate, in shards
• URI Addressable resources/representations
• Craigs List search available as RSS

35
Impact of Data Disassembly

• Better performance
• Higher cohesion
• More reliability
• Problem in one area doesnt take down whole app

36
Semantics

• Data as types ? Data as Semantic tuples
• Unbridled enthusiasm for types adds accidental
  complexity
• Semantics preserve relationshippredicate is
  first class citizen

37
Semantic Domains

• The business domain is analyzed like a text using
  deconstruction
• Domain classes less strict, mutable for context
• Two dimensions class context view
• Order is not stable throughout contexts
• identity ? correlation IDs
• URI-addressable assemblies
• FOAF, RDF, RSS
• View fragments
• Combine with Events for richer Business
  Intelligence opportunities
• How does weather affect sales? American Idol?
• Do Lexus owners also use a Mac to search your
  site?

38
Events

• An Event is something that happens or doesnt
  happen
• Inside or outside your business
• Could be a problem, potential problem, deviation
  from an SLA, or a state change to a Term in the
  domain
• It is represented in the past

39
Event Structure

• Header
• correlation ID, event type, event name,
  timestamp, event originator.
• Body
• Carries all state
• Use a semantic ontology to fully describe so
  listeners can determine action
• Use a Canonical Data Model to reconcile disparate
  event source representations

Event Sources Could be row inserted in a
database, a user request, an RFID source or
sensor, an update to an RSS feed, receipt of an
email, service, etc.
40
Event Processing

• Use CEP/ESP
• Upside down database
• Correlate with other events
• Use ESB to connect events to one or more
  listeners
• Listeners use Rules Engine
• Send event data through Event Engine
• Look for specific value, derived value, something
  that hasnt happened in sliding window
• May correlate events across temporal patterns,
  geographic patterns,
• Emit new event
• Start business process, invoke service, loop back

41
Comparison

• Monolithic
• Centralized
• RDBMS
• Stored Data
• Happy Path
• Request-y
• Data Types
• Pretends Simplicity
• Wired
• Deterministic

• Many bundles/contexts
• Decentralized
• Variety, Schema-free
• Stored Queries
• Designed to Crash
• Event-y
• Semantics
• Acknowledges Complexity
• Choreographed
• Inferential

42
More Comparing

• Asynchronous
• In-time
• State Machine
• Parallel
• Compensation, Retry
• Run-Time Paths
• State in Event
• Choreography

• Synchronous
• Nightly Batch
• Application Actions
• Sequential
• Transactions
• Design-Time Paths
• Stored State
• Central Control

43
A Brief Example
44
Typical Order Flow

• Customer submits Order
• State held in app server session
• Execute 14 steps to insert Order and give Order
  number back to customer
• Synchronous
• Totally dependent
• Failures apparent
• Show customer thank you page with that number,
  then wait for ETL
• Business view lags

45
Deconstructed Order Flow

• No state in app server
• Store in database, cookie, event itself
• Order in own context, pluggable via OSGi
• Return immediately from Correlation Factory
• Create Order.Created Event in Service
• Assign Correlation ID
• Leave Headers
• Put Order in an asynchronous choreography
• Publish event to ESB
• Stream to CEP/ESP, alert new listeners
• JMS Topic Event Listener
• Process in handlers with BRMS
• Listeners are variety of Event Services
• Determine processing via BRMS
• Emit new Events with transitioned state
• (Order.Validated, Order.Logged,
  Order.StockAssigned, etc)
• Pipe and Filter for variety of outputs
• RSS, RDF, microformats
• Create URI-addressable response fragments

46
aims of SPEARS a Deconstructed Software
Architecture

• We are overrun with software complexity, cost,
  and project delays
• We thrash repeatedly through software fashions
  attempting to handle this
• Instead, outline how software practitioners can
  deconstruct software systems to
• Create software that is
• Less expensive
• Because less accidentally complex
• Though perhaps more epiphenomenally complex
• More reliable
• Acts as advertised
• And whats advertised is achievable
• More manageable
• If simple doesnt match the world, accidental
  complexity results

47
SPEARS Reference Architecture

• Architecture diagrams
• Component descriptions
• Features
• Design patterns
• Templates
• Coming soon to www.spearsource.com

48

• thank you