Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,040 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
  • Be the first to comment

  • Be the first to like this

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

×