97 Things Every Project Manager Should Know by vxi16839


More Info
       A Deconstructed Software

Eben Hewitt
November 3-4, 2009
•   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"….‖
                            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
    (O‘Reilly, 2009)
    – Also contributor to 97 Things Every Software Architect
      Should Know (O‘Reilly, 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
             What‘s 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
              Our Answers…
• Project Manager-types proliferate
  – XP, Scrum, TDD, Kanban
• Programmer-types proliferate
• Much less focus on domain
  – Domain Driven
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
• A Few Words on/about/around
                                                                 “I believe Tim thinks
                                                                 he made my ideas
                                                                 practical, whereas
                Ted Nelson: Hypertext                            I think he
•   ―By 'hypertext,' I mean non-sequential writing — text that   them-- with
    branches and allows choices to the reader‖                   today's extreme
     --Ted Nelson                                                complexity as
                                                                 the result.”
•   ―…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
• 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
             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
• Deconstruction in 25 Words or Less
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
 •He will publish more than 60 books before his
 death in 2004
            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 author‘s
 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
              How to Deconstruct a Text
                      an embarrassing over-simplification

1. Analyze a text for conceptual oppositions
   – speech/writing, presence/absence, poison/remedy,
     surplus/lack, nature/culture
2. Find how one of the terms has been privileged
   – May be considered more ‗normal‘, ‗general‘, ‗culturally
     preferred‘, ‗self-evident‘, ‗valuable‘, ‗true‘
3. Look for what has been overlooked, suppressed, or
4. Show how the unprivileged term has
   unacknowledged significance
5. Look for multiple meanings of key terms to show
   how the text actually supports ‗opposing‘
         Iterability: the opening out of a
         mark‘s 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
Deconstruction Applied to Other Fields
    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 modernism‘s 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
                               Deconstructed Buildings
                                   MIT‘s Strata Center: Cambridge, US
                                                                                                           Guggenheim Museum Bilbao, Spain


                                                                        Inifinity Tower: Dubai
                                                                        Walt Disney Concert Hall: LA, US

                                                                                                              Vietnam Veterans Memorial


Turning Torso: Malmo, Sweden
              Deconstruction in Culinary Arts
                                                                                       Bloody Mary
•   Contains all ingredients of original       Tomato Soup & Grilled Cheese
     – But perhaps in different form
•   Ingredients prepared individually
     – So you can truly taste each
•   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                                                           Caesar Salad
    remembered taste of the unified [dish]
       –Anthony Bourdain

                                                                         Pina Colada
              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
• Look for what has been overlooked,
  suppressed, or marginalized
   – Show how they have unacknowledged
• Look for ―loose threads that at first glance
  appear peripheral yet often turn out to
  undermine or confuse the argument.‖
   Deconstruction has Practical Importance in:
• Philosophy
   – Examine how we ab/use language so we can clarify our
• 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
• Software…
                     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
Can deconstruction help us
 build better software?
     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
            •―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,
Presentation/Application Deconstructs
                       •The Presentation Tier is more
                       automated, with more options,
                       than ever
                           •XForms, RSS, RDF,
                       •Is there such a thing
                       •What accidental complexity do
                       we incur by maintaining this
                       (false) opposition?
Other Binary Oppositions that Deconstruct

            • Business/IT
               – Ahem.
            ―Time is the longest distance between two places‖
                --Tennessee Williams

So What Does a Deconstructed Software
       Architecture Look Like?
               SPEARS DSA: Services, Processes, Events,
                      Agents, Rules, Semantics

1.       Analyze with Deconstruction
2.       Disassemble ―application tier‖
3.       Disassemble ―data tier‖
     •     Variety of platforms fit to purpose
     •     Contexts include state, RDF, RSS, images, XForms
4.       Represent domain with Events, Semantically
     •     Move ―business logic‖ into rules engine, CEP/ESP,
           access via event services
5.       Build an Event-Driven Architecture on SOA
     •     ESB, Policy Brokers virtualize services
     •     Central controller  choreography
      Deconstruction in Software Analysis
• All software domains are potentially
   – Architect as textual analyst
• Instead of suppressing the indeterminacy
  of meanings, embrace it
• Domain Objects  Terms ―sous rature‖
• Domain Objects  Events
   – Don‘t ignore Contexts
• Find a supporting structure
   – that works with, instead of against, this fluidity
   – sufficiently decoupled and flat to work with—
     instead of against—the de-stabilized meanings
     and series of contexts
         Application Disassembly
• Single, monolithic app (EAR)  many
  – Search, Order, Appointments, Tracking
• Everything in App Server  simple
  adapter to Event Services
• App Logic  configurable business rules
  – Business Logic, Routing, Analytics, Event
     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
    – Reduced ETL (an accident of focusing on
      simplicity and closing meanings)
    – Improved near-time BI
                   Data Disassembly
• Consistency at any cost  eventually consistent
• Everything RDBMS  Storage fit to context
  – XML/Object/Document Databases, Distributed
  – Non-Relational, Columnar databases
• Partition data
  – Transactional data in one cluster
  – Non-transactional data separate, in shards
• URI Addressable resources/representations
  – Craig‘s List search available as RSS
         Impact of Data Disassembly
•   Better performance
•   Higher cohesion
•   More reliability
•   Problem in one area doesn‘t take down
    whole app
• Data as types  Data as Semantic tuples
• Unbridled enthusiasm for types adds
  accidental complexity
• Semantics preserve relationship—predicate
  is first class citizen
                      Semantic Domains
• The business domain is analyzed like a text using
   – 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
   – How does weather affect sales? American Idol?
   – Do Lexus owners also use a Mac to search your site?
• An Event is something that happens or
  doesn‘t 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
• Header
   – correlation ID, event type, event name, timestamp, event
• 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
                                            Event Structure
   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.
                     Event Processing
   – 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
     hasn‘t happened in sliding window
   – May correlate events across temporal patterns,
     geographic patterns,
• Emit new event
   – Start business process, invoke service, loop back
•   Monolithic            •   Many bundles/contexts
•   Centralized           •   Decentralized
•   RDBMS                 •   Variety, Schema-free
•   Stored Data           •   Stored Queries
•   Happy Path            •   Designed to Crash
•   Request-y             •   Event-y
•   Data Types            •   Semantics
•   Pretends Simplicity   •   Acknowledges Complexity
•   Wired                 •   Choreographed
•   Deterministic         •   Inferential
                 More Comparing…
•   Synchronous           •   Asynchronous
•   Nightly Batch         •   In-time
•   Application Actions   •   State Machine
•   Sequential            •   Parallel
•   Transactions          •   Compensation, Retry
•   Design-Time Paths     •   Run-Time Paths
•   Stored State          •   State in Event
•   Central Control
                          •   Choreography
A Brief Example
                    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
                     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,
•   Pipe and Filter for variety of outputs
     – RSS, RDF, microformats
     – Create URI-addressable response fragments
•   Expect it to fail & compensate
   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 what‘s advertised is achievable
   – More manageable
       • If ―simple‖ doesn‘t match the world, accidental complexity results
       SPEARS Reference Architecture
•   Architecture diagrams
•   Component descriptions
•   Features
•   Design patterns
•   Templates
•   Coming soon to
thank you

To top