Technical System Structure: Technology or Enterprise?softwaresummit.com/2004/speakers/JohnssonStructure.pdf · Title: Microsoft PowerPoint - JohnssonStructure.ppt Author: Wayne Created

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]

mailto:[email protected]



What We Do, Why We CareGoing to build a system

or extend

All requirements minedFunctional requirementsNon-Functional Requirements (NFR)



Inventory of FunctionalityPresentationBusinessIntegration



Deploy-PointsBackendCentralPeripheral



StructureWhat functionality in which deploy point?Presentation, Business, IntegrationPeripheral, Central, Backend



CapabilitiesMakes the differenceDepend on system as wholePerformanceCapacityReliabilitySecurityExtensibility



Capability Trade-offCannot have allArchitectual transformation

give up some of onegain some of other

ExamplesEncryption (performance –> security)Optimistic locking (reliability –> capacity)



Good or Bad?Good if fulfils NFRsElse: apply transformations



Origin of NFRsNFRs defined by businessEval driven by business risksEbay vs Bank

Architecture is Good if eliminates business risks



Anything Interesting Yet?



ArchitectureTechnical structure of system

Structure functionality into components in such a way that all NFRs are fulfilled

Requires deep technical knowledge of component technologies



Two ModelsArchitecture too big subjectRestricted discussionTechnology-based data-flow-architectureEnterprise-based abstraction-architectures



Dataflow Architectures



Based on TechnologyWe build what we know

Can be a good choiceFast initial development

Should be conscious Can be result of “design by coincidence”



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



Example (Bank)Errand systemTuxedo backendEJB

fetchCustomer()updateCustomer()

Arguments: data graphsCustomerVO, ContactVO, AccountVOGetters/setters

• Primitives• Relations

GUIJust one account of each type (saving, checking, etc.)



EvaluationSome scenariosStudy impact



Scale CapacityBuy bigger serverCannot scale one aspect

e.g. increase in direct stock buy/sell

Must scale up “everything”



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



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



System IntegrationBusiness constraints enforced in clientBusiness constraints enforced in client systemsMess



Summary of CapabilitiesShort-term extensibility +Scaling -Reliability -Security -Long-term extensibility -



Abstraction ArchitecturesAll Computer Programmes are Simulations



AbstractionAbstract = part of organAbstraction = simplificationHides technical realisationModel of conceptual understanding



Based on EnterpriseModels understanding of enterpriseHard

Very hardBudget for analysis & design

Tips: Do not spend entire budget at onceSave some for later insights



Typical RealisationService components in centre

Session EJBState if appropriate

Argument data objectSlim in dataRich in behaviour

Clear “system border”Logic in central deploy-points



Example (Bank)Counter BazaarTuxedo backendSession EJBs:

AccountManagementMoneyMovingStockDepau

Arguments: objectsAmount, ContactInfo



EvaluationSome scenariosStudy impact



Scale CapacityRedeploy popular serviceSeparate deploy / clusteringCan scale up part



Business TransactionConstraints inside systemEJB enforces consistent update

Can check vs backendFast fail

Can span several calls later “finalization”



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



System IntegrationBusiness constraints enforced in systemClient systems must build callsEasy to publish for integration (Web Services hype is about integration)



Summary of CapabilitiesShort-term extensibility -Scaling +Reliability +Security +Long-term extensibility +



Getting It Done



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”?



Migrating the StructureNew Session EJBs publish business methodUses tech-oriented functionChange client code one-by-one(Some time might pass)Hide tech-oriented function



Problem En RouteLong parameter lists

Lift business tier functionality

Bloated Session EJBsSplitting sessions



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)



Splitting SessionsDoing-it-all-sessionDraw state diagramIf state have several “aspects” – splitSplit

externally – two Session EJBsinternally – two internal states: same EJB



Trade-offsEarly in system

Speed-of-development important

Late in system Other capabilities important

Maturing systems/componentsTrend More enterprise basedLess tech based



ConclusionsArchitecture is technologyTech architectures often fastBusiness architectures often betterCan go from one to the other



Anything Interesting at All?



Stonecutters’ GuildWe, who cut mere stone, must always envision cathedrals

Documents

Technical System Structure: Technology or Enterprise?softwaresummit.com/2004/speakers/JohnssonStructure.pdf · Title: Microsoft PowerPoint - JohnssonStructure.ppt Author: Wayne Created