Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 1
Technical System Structure:Technology or Enterprise?
Dan JohnssonOmegapoint AB; [email protected]
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 2
What We Do, Why We CareGoing to build a system
or extend
All requirements minedFunctional requirementsNon-Functional Requirements (NFR)
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 3
Inventory of FunctionalityPresentationBusinessIntegration
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 4
Deploy-PointsBackendCentralPeripheral
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 5
StructureWhat functionality in which deploy point?Presentation, Business, IntegrationPeripheral, Central, Backend
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 6
CapabilitiesMakes the differenceDepend on system as wholePerformanceCapacityReliabilitySecurityExtensibility
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 7
Capability Trade-offCannot have allArchitectual transformation
give up some of onegain some of other
ExamplesEncryption (performance –> security)Optimistic locking (reliability –> capacity)
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 8
Good or Bad?Good if fulfils NFRsElse: apply transformations
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 9
Origin of NFRsNFRs defined by businessEval driven by business risksEbay vs Bank
Architecture is Good if eliminates business risks
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 10
Anything Interesting Yet?
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 11
ArchitectureTechnical structure of system
Structure functionality into components in such a way that all NFRs are fulfilled
Requires deep technical knowledge of component technologies
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 12
Two ModelsArchitecture too big subjectRestricted discussionTechnology-based data-flow-architectureEnterprise-based abstraction-architectures
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 13
Dataflow Architectures
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 14
Based on TechnologyWe build what we know
Can be a good choiceFast initial development
Should be conscious Can be result of “design by coincidence”
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 15
Typical RealisationData pump in centre
e.g. Session EJBdesigned ∅-state
Architectural methodsfew, load/store-style
Argument data classes/structsFat in dataPoor in behaviour
Logic in peripheral deploypoints
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 16
Example (Bank)Errand systemTuxedo backendEJB
fetchCustomer()updateCustomer()
Arguments: data graphsCustomerVO, ContactVO, AccountVOGetters/setters
• Primitives• Relations
GUIJust one account of each type (saving, checking, etc.)
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 17
EvaluationSome scenariosStudy impact
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 18
Scale CapacityBuy bigger serverCannot scale one aspect
e.g. increase in direct stock buy/sell
Must scale up “everything”
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 19
Business TransactionMulti step update
IncrementalFast fail (vs system state “= reality”)
System has no concept of constraintsNo protection against inconsistent updatesHave to pass all data in one call
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 20
Non-Trivial Access ControlNon-trivial
not just binarye.g. role-based
Example permissionsCashier: change balance, not create accountOn-line customer: move moneyTelephone bank: create account
System cannot tell them apart
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 21
System IntegrationBusiness constraints enforced in clientBusiness constraints enforced in client systemsMess
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 22
Summary of CapabilitiesShort-term extensibility +Scaling -Reliability -Security -Long-term extensibility -
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 23
Abstraction ArchitecturesAll Computer Programmes are Simulations
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 24
AbstractionAbstract = part of organAbstraction = simplificationHides technical realisationModel of conceptual understanding
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 25
Based on EnterpriseModels understanding of enterpriseHard
Very hardBudget for analysis & design
Tips: Do not spend entire budget at onceSave some for later insights
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 26
Typical RealisationService components in centre
Session EJBState if appropriate
Argument data objectSlim in dataRich in behaviour
Clear “system border”Logic in central deploy-points
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 27
Example (Bank)Counter BazaarTuxedo backendSession EJBs:
AccountManagementMoneyMovingStockDepau
Arguments: objectsAmount, ContactInfo
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 28
EvaluationSome scenariosStudy impact
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 29
Scale CapacityRedeploy popular serviceSeparate deploy / clusteringCan scale up part
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 30
Business TransactionConstraints inside systemEJB enforces consistent update
Can check vs backendFast fail
Can span several calls later “finalization”
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 31
Non-Trivial Access ControlSession methods match enterprise eventsNatural place to plug in access controlCashier: change balance, not create accountOn-line customer: move moneyTelephone bank: create account
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 32
System IntegrationBusiness constraints enforced in systemClient systems must build callsEasy to publish for integration (Web Services hype is about integration)
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 33
Summary of CapabilitiesShort-term extensibility -Scaling +Reliability +Security +Long-term extensibility +
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 34
Getting It Done
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 35
Myth of Doing It Right“Can’t afford to re-implement”
Can afford to keep it?
“We’ll schedule a redesign later”Not a show-stopper
“Next system”Trade-offs will be same
“If it works, don’t touch it”“works”?
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 36
Migrating the StructureNew Session EJBs publish business methodUses tech-oriented functionChange client code one-by-one(Some time might pass)Hide tech-oriented function
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 37
Problem En RouteLong parameter lists
Lift business tier functionality
Bloated Session EJBsSplitting sessions
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 38
Lifting the Business TierGet validation out of thereRich data objects
“business logic value object”Date, CurrencyCodeSupplierCode, PhoneNumber
Struts/JSF actions create objectsValidation (form/validator)• Static Amount.wellformed(String)
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 39
Splitting SessionsDoing-it-all-sessionDraw state diagramIf state have several “aspects” – splitSplit
externally – two Session EJBsinternally – two internal states: same EJB
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 40
Trade-offsEarly in system
Speed-of-development important
Late in system Other capabilities important
Maturing systems/componentsTrend More enterprise basedLess tech based
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 41
ConclusionsArchitecture is technologyTech architectures often fastBusiness architectures often betterCan go from one to the other
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 42
Anything Interesting at All?
Colorado Software Summit: October 24 – 29, 2004 © Copyright 2004, Omegapoint AB; Sweden
Dan Johnsson — Technical System Structure: Technology or Enterprise? Page 43
Stonecutters’ GuildWe, who cut mere stone, must always envision cathedrals