Vanetænkning - Mønstre for IT skuffelse og fiasko

878 views
772 views

Published on

Præsentation i 3 dele der afdækker problemet med Vanetænkning i IT, løsninger på hvordan man kan bryde vanen og dermed skabe grundlaget for IT drevet vækst. Til sidst deler vi erfaringerne fra implementering af vores foreslag i forbindelse med Elektronisk Tinglysnings projektet.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
878
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • IntroFokus på at man kan gøre andet end man plejer3 dele i præsentationen:1: Lidt om vanetænkning og hvorfor vi skal tænke anderledes. Udpluk af hvad vi oftest møder ude i virkeligheden.2: Hvad vi kan gøre ved det. Mange ting hvor vi tager fat i 2 tekniske områder. Lavet hængende frugter3: Hvordan vi løste opgaverne i ETL
  • Skrækscenarie: Jorden går under, Maya kalendrenVigtigst: Økonomisk krise og det ser ikke ud til at blive bedre
  • DermåtænkesanderledesVi ertvungettil at gørenogetandet end vi plejerIkke kun småvirksomheder, også storePengehængerikkelængerepåtræerne
  • Spørgsmålsom alle IT viksomheder bør stille sig selv og have svar påHvor mange kan ærligt svare ærligt til alt ovenstående?Kan også bruges som eksempel på dårlig (ledende) spørge teknik
  • Fra Men in Black – sletter din hukommelse X antal timer/dage tilbage
  • Mange projekter starter forfra hver gang. Opfinder hjulet i hvert projektProblemet med en projekt organisationManglende opfølgning
  • Forretningens ønsker har en tendens til at blive ændret til tekniske kravMan glemmer det faktiske behov og bruger for megen tid på teknik fnidder
  • Teknologier = LøsningerMan tænkeriteknologierfør man hargjort sig klarthvilket problem man skalløseTeknologiblirdetsammesomløsningen: Løsningenskalvære service orienteretså vi skalbruge en service bus ogdetskalværeWebSphereFor mange teknologierkræver for mange specialisterFor mange teknologierbetyderstørreprojektrisiko
  • ForklaringtilhvadårsagernekanværeHusk at sige at deterlidtprovokerende for at fåtankerne I gang hos deltagerneGartner group er med til at gøre ting til silver bullets. Godt at læreafandre men man skalikkekaste sig over det bare fordigartnersiger det. Gartner siger Service Bus, såderforskalalle ha det. Problemeter at ledelsenvælger de tekniskeløsninger
  • Man forsøger stadig at finde det værktøj der kan klare altOne sizefits all
  • Det betyder at vi gør verden alt for kompleksDet koster og er med til at alt tager for lang tid
  • Der sker intet nytMan gør det samme hver gangMan tør ikke satse på nye måder at gøre ting påMan tør ikke prøve noget nytGør det samme hvert år selvom alle deltagerne er døde
  • Offentligtsynpåverden. “Vi skal ha’ flerepenge”7 godevaner: Den 7. vane “Sharpen the saw”. “Vi harsåtravlt med at kørebil at vi ikkehartidtil at fyldebenzinpå”
  • Man skal være åben for nye ideer!!!
  • Stil de rigtigespørgsmålErdet kun antalletafpersonerogderespris der erafgørende5 mandkangøredet I danmark10 inderekangøredetpå en dag til den halve pris, men de erjo I indienMen hvad nu hvisdetrigtigesvarertrådløstnetværk?Detsvarfår man kun når man har en fagmandligevedhåndenOutsourcing eratskæreingeniørenfrasmedenogsåopstår de godeideerikkelængereHvaderdetjegharbehov for?Behov for at kommunikereikkebehov for at kabel
  • SpørgeteknikMangegange ligger svaret implicit I spørgsmåletHer kan man kun svareforkert. Ligegyldigthvad, såer man en voldsmand.Husk at vendetilbagetilspørgsmålenefratidligere
  • Sådanspørger vi
  • Detervigtigt at heletidenudfordre sig selvSørge for at stille de rigtigespørgsmål
  • Sådanburde vi spørgeManflytter sig kun ved at bliverusketudafvanetænkningHvilkeopgaverer der man husker? Deterdemhvor man harlykkes mod alle oddsHvorforkan man bypasseprocessernenårdeter ultra vigtigt men ikkenår man har god tid.
  • Viglemmer at serpåhvaddeter vi skalVi ergodetil at spørgehvad vi skaloghvordanVi glemmer at spørgehvorfor?
  • Lav timepris => mindre fokus på at eliminere waste => får mere grisset system => dyrere vedligeholdelse
  • Husk at fortælle at det her er almindelig viden, men oftest er noget man glemmer i praksis
  • Mange ændringerkræver store udefrakommendepåvirkninger – desperation eroftest en megetstørre motivator end inspirationMed alt hvad der sker nu, såburde vi væreklar ting at gøre ting anderledes
  • I første del hørte vi om udfordringerne.Der er mange løsninger og vi kan ikke komme ind på dem alle sammen.Vi vil tage fat i de 2 vi mener man kan nå flytte med med, med en beskeden indsats+ at vi kan holde det indenfor IT’s egen rammer (involveringen af forretningen er minimal)
  • SCRUM og LEAN dækker som de anvendes i dag meget de bløde værdier Det værste man gjorde for LEAN var at give det et navn, så antager ledelsen at det kommer i en kasse og kan installeresTager længere tid at få payoff, men der er lavt hængende tekniske frugter der kan kan være med til at gøre os Lean og Agile1: simplere system landskab2: AutomatiseringXP beskriver hvordan vi bedst arbejder tekniker til tekniker
  • Vi bygger på ustabil grund – svagt og fragmenteret systemlandskabHvor mange har ved idriftsættelsen af et nyt system sat en livstid op for det?Videns overdragelse, erfaringsopsamling (alt dør sammen med projektet)
  • Bygger på faktiske analyserMan skal blive meget bedre til at kategorisere og målrette indsatsen
  • Lagende er teknisk afkoblede men ikke datamæssigt eller temporalt.Hvert lag har et teknisk integrationslag, der gør det sværere at gennemskue sammenhængeneFejl søgning bliver besværliggjortSingle point of failure
  • En samlet model for virksomheden er ikke længere muligt.Verden er blevet langt mere kompleks end tidligereI dag skal man indsamle information fra langt flere datakilder end tidligereEn samlet model betyder langt større sårbarhed
  • Det er ikke muligt at lave en kontekstfri modelGør man det får man noget der ikke virker i nogen kontekstFor mange utilsigtede side effekterEksempel. Skade forsikring med liv dækning. Mit firma forsikrer mig min kone og børn er begunstigede. Hvem er kunden? Det afhænger af hvornår i tid jeg ser på det.
  • Use Cases. Der er forskel på den statiske og den dynamiske del af et systemDet dynamiske er med til at give en præcis kontekst
  • Løs kobling – data og temporaltWeb shop kan køre uden de andre
  • Få styr på hvilke systemer der ligger hvor!!!I ”Invester og differentier” er TIME TO MARKET vigtig – stiller krav til IT effektivitet
  • Oprydning i system landskabet kan tage tid, her er nogle tiltag der er billige og nemme…Vigtigt at få med at vi bruger ETL som praktiske eksempler på hvordan man kan gøreDet er så næste præsentation efter pausen
  • Med udgangspunkt i Simpel arkitektur og automatisering, vil vi snakke omHvordan vi greb opgaven an på ETL
  • Kort forklaring til hvad ETL er for en størrelse
  • Der er mange lighedspunkter med den tidligere arkitektur vi talte om ikke var en god ide…
  • HUSK: Her er skiftet fra Arkitektur til Automatisering. Endnu lavere hængende frugter end Arkitektur
  • Velmenende arkitekter, data modellører, analytikere tegner den initielle data/domæne model hvorefter den bliver overgivet til udviklerne der kaster sig over at implementere den i hånden.Efter få iterationer repræsenterer koden på ingen måde modellen i diagrammerne og dermed er dokumentationen, overblikket gået tabt.Analytikere og forretnings eksperter forstår ikke koden og kan dermed ikke indgå i samarbejdet på samme overskuelige måde når hele modellen ligger i koden.
  • Danmark har en lang tradition for at arbejde effektivt og automatisere kedelige og repetitive opgaverVi har en lang tradition for at ville arbejde for fælles bedsteDet burde vi gøre indenfor IT ogsåDen positive side effekt af høje lønninger og store kvalitetskravSender man det ud er det svært at automatisere bagefter, Offshoring partneren der får alle mulighederne for effektivisere og tjene pengeVi snyder of selv for fordelenIgen, de gode ideer opstår kun når smeden går sammen med ingeniøren
  • Alt centrerer omkring modellen, der i et agilt (og iterativt setup), bliver kørt igennem TigerTeams TRIMM (Kode generator) og derigennem producerer bi-produkter så som Java kode med Hibernate/JPA annoteringer, WSDL (blev ikke brugt på ETL, men er et tilvalg man kan foretage), SQL og automatiseret test kode der gennem teknisk test (Junit baseret) tester den kode der er blevet produceret og på den måde sikrer at database koden fungerer uden datatab.
  • Note: Blev ikke anvendt på ETL
  • Note: Blev ikke anvendt på ETL
  • HUSK: Her ser vi på fordele ved automatisering generelt
  • Flere ugers programmering kan spare få dages omtankeMed den korte deadline på ETL kunne en senere frysedato sikre en meget bedre teknisk og forretnings mæssig løsning
  • Det vigtige i denne proces er at sikre et stabilt interface mellem den genererede skematiske kode og den interessante kode, der på den ene eller anden måde benytter den skematiske kode.Dette er typisk ikke svært.
  • Højere abstraktionsniveau:Tættere på forretningens syn på verdenMindre teknisk fokus og mere fokus på at løse forretningens udfordringerTekniske beslutninger kan udskydesModellen dekoreres med information til generatorerneMan kan beskrive at ”her skal være historik” og så først senere beslutte hvordanPoint of No Return kan udskydes Ændringer koster ikke ekstra selvom kodebasen bliver størreDokumentationen er altid opdateret Modellerne sander ikke til, da det er dem man genererer ud fraHøjere kvalitet og Ensartethed Alt følger samme mønstre Kodestandarder overholdes Enten virker alt, eller også har alt samme fejlRefactoring er både hurtigere og billigere Generelle ændringer koster mindre da man genererer om. Der skal ikke skrives om Selv grundlæggende ændringer kan foretages ret sent Det koster ikke så meget at tage fejl. Man kan prøve flere ting af på samme tid Man får derfor et bedre systemKort udviklingscyklus Man kan sidde med forretningen og ændre modellen om morgenen og have noget kørende dagen efter de kan teste og prøve af
  • Afsluttende pointer:Vi vil gerne være Lean og AgileXP, SCRUM osv er de bløde værdier men tager længere tid En enklere teknisk arkitektur kan hjælpe med til at blive Agile og Lean, men kan også stå aleneAutomatisering kan implementeres nedefra. Og er igen bedre på en enkel teknisk platformAlt er med til at vi kan blive mere effektivePostulat: Vi kan IKKE blive mere effektive end vores tekniske platform og automatiseringsgrad giver os mulighed for
  • Vanetænkning - Mønstre for IT skuffelse og fiasko

    1. 1. Vanetænkning Mønstre for IT skuffelse og fiasko
    2. 2. Virksomheders vækst bremsesaf mangel på finansiering Berlingske Finans6 ud af 10 offentlige projektergår over tid og budget Version2
    3. 3. Hvor står jeres virksomhed?• Bliver jeres IT projekter leveret til tiden, på budget og med den rette funktionalitet?• Kører jeres IT systemer problemfrit og stabilt?• Indeholder jeres systemlandskab flere applikationer der udfører samme eller lignende opgaver?• Outsourcer/Offshorer I de rigtige opgaver (eller laver I de rigtige opgaver in-house)?
    4. 4. Hvor står jeres virksomhed?• Er IT projekterne afstemt med forretningens behov?• Er forretningen aktivt involveret i IT projekterne og investeringerne?• Balancerer I hele organisationens behov med de individuelle forretningsbehov mht. arkitektur og infrastruktur ?
    5. 5. Virker det her bekendt?
    6. 6. Hvert nyt projekt starter fra scratch
    7. 7. PRODUKT SYN Vi har behov for et Implementer Siebel CRM i samlet kundeoverblik Call centeret Vi skal have bedre styr Køb og installer HP Quality på vores krav Center Vi skal have en Service Byg en løsning der benytter Orienteret arkitektur Web Services i Oracle Service Bus/SeeBeyond/…
    8. 8. Git REST BlackBerry Oracle Service busDocumentum Ruby on Rails Workflow system WebLogic Cloud SharePoint JAVA MS SQL Server F# Oracle DB Layered Architecture SOA SubVersion Dart BizTalk WebSphere VB.NET C# Scala iOS .NET NoSQL Android Web Services Team GroovyPolicy Manager Foundation BPMN Portal Server Hg Flash XMLJavaScript Requirement Management tools Spring
    9. 9. Typisk management tankegang• Vi vælger de værktøjer og den arkitektur, som Gartner anbefaler• Flere resourcer på et projekt = Jo hurtigere bliver vi færdige• 100 udenlandske udviklere er bedre en 10 lokale, selv om den samlede pris er ens
    10. 10. The Silver Bullet
    11. 11. Alt dette medfører• Høj kompleksitet og et fragmenteret system landskab• Stort behov for produkt specialister der ikke kan gå på tværs af projekter• Risiko for at hyre vanetænkere i stedet for tekniske domæne eksperterBehov for mange ressourcer på projekterne og derfor høje omkostninger
    12. 12. Same procedure as last year?Same procedure as every year!!!
    13. 13. For!!!• “Vi har ikke tid til at se på nye teknologier”• “Det kræver flere ressourcer og penge”• “Vi har prøvet og det fungerede ikke”• “Vi er opmærksomme på at vi har udfordringer”• ”Vi _______________________________” (Indsæt selv undskyldning)
    14. 14. Åben for nye ideer?
    15. 15. Hvis det tager 1 mand 10 dage at grave ettelefonkabel ned, hvor mange mand skal jeg såbruge hvis jeg vil ha det gjort på 2 dage?5 mand i Danmark10 mand i Indien. Halv tid og oven i købet til halv pris Trådløst netværk
    16. 16. Slår du stadigvæk din kone?
    17. 17. Sådan spørger vi oftest• Hvor kan jeg få 200 udviklere til mit projekt?• Hvor kan jeg få dem billigst?• Hvordan skalerer jeg min tekniske platform til 200 udviklere?• Hvordan styrer jeg så store teams over et langt projektforløb?
    18. 18. Sådan burde vi spørge• Hvorfor har jeg behov for 200 udviklere?• Hvordan ville jeg gøre hvis jeg “kun” havde: – 30 udviklere – 3 måneder og ikke 3 år til projektet• Har jeg behov for distribuerede teams?
    19. 19. Hvordan?Hvorfor? Hvad?
    20. 20. Er løsningen Offshoring• 10 tekniske domæne eksperter i Danmark til 1000 kr. i timen = 10.000 kr. i timen• 100 udviklere i Kina/Indien til 200 kr. i timen = 20.000 kr. i timen Lidt som at købe apps på AppStore det koster jo kun 6 kr.
    21. 21. Projekt økonomi Produktivitet Produktivitet Administrativ overhead Administrativ overhead10 tekniske domæne eksperter 100 udviklere
    22. 22. InspirationDesperation
    23. 23. Agenda• 16:00: Intro v. Diego Børresen Lladó. IDA-IT• 16:05: Vanetænkning v. Henrik Wivel• 16:30: Sådan kan vi gøre noget ved det v. Jeppe Cramon• 17:00: Pause• 17:20: Elektronisk Tinglysning v. Jeppe Cramon• 17:55: Tak for god ro og orden
    24. 24. LøsningerMønstre for IT skuffelse og fiasko
    25. 25. Her er løsningerne! SCRUM XP LEAN Agile Outsourcing Hvad var liiiiige vi ville opnå?At komme tættere på forretningen
    26. 26. Status Quo
    27. 27. Meget tilpasset Vi har behov for et stærkt fundament for udvikling 11% 7% ”Tilpasnings fælden” ”IT understøttet vækst” +13 +35 Kilde: Bain Analysis -14 -6Tilpasning 74% 8% ”Vedligeholdelses Zonen” ”Velsmurt IT Maskine” +0 +11 Lidt tilpasset -2 -15 Lidt effektiv Effektivitet Meget effektiv % af de 504 Samlet årlig vækstrate % forskel i forhold til det samlede gennemsnit IT udgifter adspurgte indenfor en 3 årig periode
    28. 28. Et stærkt fundament er!• Enkel arkitektur• Arbejdsopgaver og data ejes af ét system• Automatisering• Tests
    29. 29. En IKKE enkel arkitektur Klient Klient Klient Klient Proces Service Proces Service Remote Facade Applikations Service Aktivitets Aktivitets Service Service Domæne Domæne Objekt Objekt Data Access Layer Data Data Data Data Service Service Service Service Data Storage Data Data Data Storage Storage Storage
    30. 30. Det her hjælper heller ikke
    31. 31. En stor Fælles-Model er det enhver arkitekt drømmer om i sin rus Men som de siger
    32. 32. EN MODEL TIL AT HERSKE OVER DEM ALLE EN MODEL TIL AT FINDE DEM EN MODEL TIL AT HENTE DEM ALLE / OG MORKET FORENE DEM
    33. 33. Stadig en stor model Online Ordering System Product Priser Description Unit Price Promotional Price Promotion End Date Stock Keeping Unit (SKU) Quantity On Hand (QOH) Location Code LagerKunder Price Quantity Ordered Salg
    34. 34. Der er altid flere modeller i spil i store projekter Men når kode baseret på forskellige modeller kombineres ...
    35. 35. … bliver koden fyldt med fejl,upålidelig og vanskelige at forstå Kommunikation mellem teammedlemmer bliver forvirrende. Det er ofte uklart, i hvilken sammenhæng en model IKKE bør anvendes!
    36. 36. Der mangler kontekst
    37. 37. Mindre modeller og ”genbrug” Enterprise Pricing Service Product SKU Unit Price Promotional Price … Web Shop Product SKU Description Priser Price Quantity OrderedKunder … Inventory Service (SAP) Product SKU Description QOH Location Code … Lager Salg
    38. 38. Nu endnu bedre – med ESB Pas på! Det er så nemt at Enterprise se et produkt som Pricing Service løsningen på alle Product ens problemer! SKU Unit Price Promotional Price … Web Shop Product SKU Description Pricing Price Quantity OrderedKunder … Inventory Service (SAP) Product SKU Description QOH Location Code Enterprise … Inventory Service Bus Salg Før havde vi 1 problem. Med ESB’en har vi nu 2 problemer
    39. 39. Der mangler stadig forretnings fokus Processer og tilstandsændringer er vigtige bestanddele
    40. 40. En meget bedre opskrift… Enterprise Pricing Service Product SKU New SKU Unit Price Promotional Price Event … Web Shop Product New SKU Price SKU Description New SKU Event Priser Price Price Quantity Ordered EventKunder … Inventory Service (SAP) Product New SKU SKU Description Event QOH Location Code … Lager New SKU Message Bus Event Salg
    41. 41. Hvad er et stærkt fundament?• Enkel arkitektur• Arbejdsopgaver og data ejes af ét system• Automatisering• Tests
    42. 42. Kort fortalt…• Få ryddet op i system landskabet…• Fjern overflødige systemer• Fjern systemer der ikke længere har en fornuftig cost-benefit• Moderniser systemer der stadig kan gøre en forskel• Byg nye systemer der kan differentiere jer fra resten• …og gør det med udgangspunkt i Neil Nickolaisen’s Purpose Alignment Model
    43. 43. Neil Nickolaisen’s Purpose Alignment Model Invester Høj Partnerskab og differentier MarkedsDifferentierings grad Lad det være som det er Hold på niveau med Lav konkurrenterne Lav Høj Vigtighed
    44. 44. Hvad er et stærkt fundament?• Enkel arkitektur• Arbejdsopgaver og data ejes af ét system• Automatisering• Tests
    45. 45. Automatisering• Continuous Integration – Koden bliver automatisk bygget og nødvendige tests bliver udført for verifikation• Opsætning af miljøer – Server opsætning, firewalls, deployment• Integrations test• der er meget mere at hente her…
    46. 46. Løsningen i ETL
    47. 47. Elektronisk TinglysningBaggrundsinformation om Elektronisk Tinglysning for dem der ikke har hørt om det…
    48. 48. ETL – Foreslået Arkitektur Intern Portal WebLogic Portal Ekstern Portal Proces Service Proces Service IntegrationsOracle Service Bus Service Aktivitets Aktivitets Service Service Integrations Service Data Data Data Service Service Service Database
    49. 49. Foreslået ETL Arkitektur• Fordele – Logisk set en fornuftig afkobling (Single Responsibility Principle) – Oracle tjener godt• Ulemper – Logiske lag er blevet til fysiske lag – Høj kompleksitet – Svært at finde ressourcer der kan arbejde med OSB’en – Stabilitet – Performance (både runtime og for udviklerne) – Deployment
    50. 50. ETL – Simplificering af Arkitekturen Intern Portal Java applikationer Ekstern PortalWebLogic Server Portal Facade Integrations Service Forretnings Service Forretnings Service Rige Domæne Rige domæne Integrations Service objekter objekter Data Access Layer Database
    51. 51. Simplificeret ETL Arkitektur• Fordele – Fysisk og logisk arkitektur er tættere på hinanden – Lav kompleksitet – Stabilitet – Nemmere at finde ressourcer der kan kode Java – Performance (både runtime og for udviklerne) – Deployment• Ulemper – CV’et bliver ikke boostet med Enterprise Service Bus – Oracle tjener ikke nær så godt…
    52. 52. ETL - Automatisering• Yderst komplekst domæne område• Reglerne er bestemt af Jura (og ikke logik)• Dækker tinglysninger der er flere hundrede år gamle• Kompleks logik er påkrævet for at automatisere jura• Meget kort deadline for 3. forsøg på at bygge ETL
    53. 53. Elektronisk Tinglysning• Teknisk valg – Programmeringssprog: Java – Database: Oracle• Udfordring – Hvordan binder vi Java og Oracle databasen sammen?
    54. 54. Sådan plejer man at gøre SQLJava kode
    55. 55. Betyder at man går fra dette
    56. 56. package dk.tigerteam.mdsd.demo.model.internal;@Entity@Table(name = "Customer") Til dette…public class Customer extends AbstractEntity { package dk.tigerteam.mdsd.demo.mode.internal; private static final long serialVersionUID = 2098912667L; @Entity @Basic @Table(name = "Booking") @Column(name = "name", nullable = false) public class Booking extends AbstractEntity { private String name; private static final long serialVersionUID = 170080605L; @OneToOne(cascade = { @Basic CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REFRESH}, @Column(name = "comment", nullable = false) fetch = FetchType.LAZY) private String comment; @JoinColumn(name = "addressId") @NotNull @Basic private dk.tigerteam.mdsd.demo.model.internal.Address address; @Temporal(TemporalType.TIMESTAMP) @Column(name = "time", nullable = false) @OneToMany(cascade = { private java.util.Date time; CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REFRESH}, targetEntity = Booking.class, mappedBy = "customer", @Basic fetch = FetchType.LAZY) @Column(name = "timeslot", nullable = false) private Set<Booking> bookingCollection = private int timeslot; new java.util.HashSet<Booking>(); @ManyToOne(cascade = { public String getName() { CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REFRESH}, return name; fetch = FetchType.LAZY) } @JoinColumn(nullable = false, name = "customerId") private Customer customer; public void setName(String name) { this.name = name; public String getComment() { } return comment; … } @Entity … @Table(name = "Address") … public void setComment(String parameter) { public class Address extends AbstractEntity { … this.comment = parameter; private static final long serialVersionUID = 1697028161L; … } … @Basic … public java.util.Date getTime() { @Column(name = "street", nullable = false) … return time; private String street; … } … … @Basic … @Column(name = "zipCode", nullable = false)} … private String zipCode; … … @Basic … @Column(name = "city", nullable = false) … private String city; } public String getStreet() { return street; } public void setStreet(String parameter) { this.street = parameter; } … … … }
    57. 57. Forskellen mellem at mudre ogmodellere i håndskrevet Java er meget lille
    58. 58. Kan du heller ikke se skoven for bare træer? package dk.tigerteam.mddexample.model.customer; @javax.persistence.Entity public class Customer extends dk.tigerteam.mddexample.model.user.User { Versus det du ønskede private static final long serialVersionUID = 1328488396L; @javax.persistence.Lob @javax.persistence.Basic @javax.persistence.Column(name = "comment") private String comment; at kommunikere @javax.persistence.Embedded @javax.persistence.AttributeOverrides({@javax.persistence.AttributeOverride(name = "firstName",column = @javax.persistence.Column(name = "name_firstName") ) , @javax.persistence.AttributeOverride(name = "lastName",column = @javax.persistence.Column(name = "name_lastName") ) }) private dk.tigerteam.mddexample.model.customer.Name name; @javax.persistence.Embedded @javax.persistence.AttributeOverrides({@javax.persistence.AttributeOverride(name = "street", column = @javax.persistence.Column(name = "address_street") ) , @javax.persistence.AttributeOverride(name = "state",column = @javax.persistence.Column(name = "address_state") ) , @javax.persistence.AttributeOverride(name = "zipCode",column = @javax.persistence.Column(name = "address_zipCode") ) , @javax.persistence.AttributeOverride(name = "city",column = @javax.persistence.Column(name = "address_city") ) , @javax.persistence.AttributeOverride(name = "country",column = @javax.persistence.Column(name = "address_country") ) }) private dk.tigerteam.mddexample.model.customer.Address address; @javax.persistence.OneToMany(cascade = { javax.persistence.CascadeType.MERGE, javax.persistence.CascadeType.PERSIST, javax.persistence.CascadeType.REFRESH} , targetEntity = dk.tigerteam.mddexample.model.customer.Pet.class, mappedBy = "customer", fetch = javax.persistence.FetchType.LAZY) private java.util.Set<dk.tigerteam.mddexample.model.customer.Pet> petCollection = new java.util.HashSet<dk.tigerteam.mddexample.model.customer.Pet>(); @javax.persistence.OneToMany(cascade = { javax.persistence.CascadeType.MERGE, javax.persistence.CascadeType.PERSIST, javax.persistence.CascadeType.REFRESH} , fetch = javax.persistence.FetchType.LAZY) @javax.persistence.JoinTable(name = "Customer_invoice", joinColumns = @javax.persistence.JoinColumn(name = "CustomerId") , inverseJoinColumns = @javax.persistence.JoinColumn(name = "invoiceId") ) private java.util.Set<dk.tigerteam.mddexample.model.invoice.Invoice> invoiceCollection = new java.util.HashSet<dk.tigerteam.mddexample.model.invoice.Invoice>(); @javax.persistence.OneToMany(cascade = { javax.persistence.CascadeType.MERGE, javax.persistence.CascadeType.PERSIST, javax.persistence.CascadeType.REFRESH} , fetch = javax.persistence.FetchType.LAZY) @javax.persistence.JoinTable(name = "Customer_appointment", joinColumns = @javax.persistence.JoinColumn(name = "CustomerId") , inverseJoinColumns = @javax.persistence.JoinColumn(name = "appointmentId") ) private java.util.Set<dk.tigerteam.mddexample.model.customer.Appointment> appointmentCollection = new java.util.HashSet<dk.tigerteam.mddexample.model.customer.Appointment>(); public String getComment() { return comment; } public void setComment(String parameter) { this.comment = parameter; } public dk.tigerteam.mddexample.model.customer.Name getName() { return name; } public void setName(dk.tigerteam.mddexample.model.customer.Name parameter) { this.name = parameter; }
    59. 59. Håndholdt konsistens…@Entity @Entitypublic class Customer { public class Pet { @OneToMany( @ManyToOne targetEntity = Pet.class, private Customer customer; mappedBy = "customer” ) public void setCustomer(Customer parameter) { new ManyToOneWrapper<Customer, Pet>(this) { private Set<Pet> petCollection = new HashSet<Pet>(); @Override protected void addManySideObjectToOneSideCollection(Customer oneSide, Pet manySide) {public Set<Pet> getPetCollection() { ((WrappedSet<Pet>) oneSide.getPetCollection()).getWrappedCollection().add(manySide); } return new OneToManySetWrapper<Customer, Pet>(this, petCollection) { @Override @Override protected void removeManySideObjectFromOneSideCollection(Customer oneSide, Pet manySide) { protected Customer getOneSideObjectInManySideObject(Pet manySideObject) { ((WrappedSet<Pet>) oneSide.getPetCollection()).getWrappedCollection().remove(manySide); return manySideObject.getCustomer(); } } @Override @Override protected Customer getOneSideObjectInManySideObject(Pet manySide) { protected void setOneSideObjectInManySideObject(Pet manySideObject, return manySide.customer; Customer oneSideObject) { } manySideObject.setCustomer(oneSideObject); } @Override }; protected void setOneSideObjectInManySideObject(Pet manySide,Customer oneSide) { } manySide.customer = oneSide;} } }.updateOneSideObject(parameter); } }
    60. 60. AutomatiseringFra sweatshops til automatisering 
    61. 61. På ETL introducerede vi denne proces UML klasse diagrammer SQLJava kodeHibernate Test
    62. 62. En anden mulighed er…
    63. 63. Lyder svært, men er nemt  Rule Language Meta Model  + Rule Grammar (i Xtext) Tekst Editor +Data Language Meta Model  Editor & IDE
    64. 64. Point of No Return, TraditioneltOmkostningved Rework Tid Freeze V 1.0
    65. 65. Point of No Return, Model DrevetOmkostningved Rework Tid Freeze V 1.0
    66. 66. Slut med at skrive kedelig kode i hånden Model Generator Interessant Frameworks Kode (Skrevet i hånden) (Hibernate/JP Skematisk Kode A, Entity Skrevet I hånden Framework) Libraries (f.eks. Java/.NET)
    67. 67. Hvad får vi så ud af det?• Højere abstraktionsniveau• Tekniske beslutninger kan udskydes• ”Point of No Return” kan udskydes• Dokumentationen er altid opdateret• Højere kvalitet og Ensartethed• Refaktoreringer er både hurtigere og billigere• Kort udviklingscyklus
    68. 68. Den helt korte versionVi kan nå det samme med færre ressourcer Vi kan nå det samme på kortere tid Vi kan nå mere med de samme ressourcer og på den samme tid
    69. 69. Elektronisk Tinglysning Spørgsmål?http://tigerteam.dk @TigerTeamDK på Twitter

    ×