1.
Habitual thinking
Patterns for IT disappointment and failure
Henrik Wivel & Jeppe Cramon

2.
Corporate growth slowed due
to lack of funding
Berlingske Finans
6 out of 10 public projects
going over time and budget
Version2

3.
How well is your company doing?
• Are your IT projects delivered on time, on
budget and with the right functionality?
• Are your IT systems running smoothly and
stable?
• Does your system landscape contain more
applications performing the same or similar
tasks?
• Do you Outsource / Offshore the right tasks
(or are you doing the right tasks in-house)?

4.
How well is your company doing?
• Are your IT projects aligned with business
needs?
• Is the business actively involved in IT projects
and investments?
• Do you balance the entire organization's
needs with the individual business needs in
terms of architecture and infrastructure?

5.
Does this seem familiar?

6.
Each new project starts from scratch

7.
PRODUCT VIEW
We need a combined Implement Siebel CRM in the
customer view Call center
We need to better Buy and install HP Quality
manage our Center
requirements
We need a Service Build a solution using Web
Orienteret Architecture services in Oracle Service Bus
/ SeeBeyond / ...

8.
Git REST
BlackBerry
Oracle Service bus
Documentum
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
Groovy
Policy Manager
Foundation
BPMN
Portal Server
Hg
Flash XML
JavaScript
Requirement Management tools Spring

9.
Typical management thinking
• We choose the tools and architecture that
Gartner recommends
• More resources on a project = The sooner we
will be finished
• 100 foreign developers are better than 10
local, even if the total price is the same

10.
The Silver Bullet

11.
All this leads to
• High complexity and a fragmented system
landscape
• Strong need for product specialists who can
not always participate across projects
• Danger of hiring habitual thinkers rather than
technical domain experts
This creates the need for many resources
on projects and therefore result in high costs

12.
Same procedure as last year?
Same procedure as every year!!!

13.
Because!!!
• “We haven’t got time to look at new
technologies”
• “It requires more money and time”
• “We have tried it before and failed”
• “We realize we have challenges”
• ”We _______________________________”
(Insert an excuse)

14.
Open for new ideas?
Poul, you idiot, what's that!?
You should only bring things we
can eat!

15.
If it takes 1 man 10 days to dig a
telephone cable , how many men do I need
if I want it done in 2 days?
5 men in Denmark
10 men in Indien. Half time and even half price
How about using: Wireless network?

16.
Do you still beat up your wife?

17.
This is how we often ask
• Where can I get 200 developers for my project?
• Where can I get them cheapest?
• How do I scale my technical platform to 200
developers?
• How do I manage large teams over a long
project cycle?

18.
This is how we should ask
• Why do I need 200 developers?
• How would I do if I "only" had:
– 30 developers
– 3 months and not 3 years for the project
• Do I need distributed teams?

19.
What?
How?
Why?

20.
Is the solution Offshoring?
• 10 techinical domain experts in Denmark at
$150 an hour = $1500 an hour
• 100 developer in China/India at $30 an hour =
$3000 an hour
It’s a bit like bying app on the Apple AppStore
They only cost $1

21.
Project Economy
Productivity
Productivity
Administrative
overhead
Administrative
overhead
10 technical domain experts
100 developers

22.
Inspiration
Desperation

23.
Solutions
Pattern for IT disappointment and failures

24.
Here are the solutions!
SCRUM
XP
LEAN
Agile
Outsourcing
What was it exactly we were trying to solve?
Getting closer to the business

25.
Status Quo

26.
We need a strong foundation for development
11% 7%
Highly aligned
”Alignment Trap” ”IT enabled Growth”
+13 +35
Source: Bain Analysis
-14 -6
Alignment
74% 8%
”Maintenance Zone” ”Well-Oiled IT”
+0 +11
Less aligned
-2 -15
Less effective Effciency Highly effective
% of the 504 Combined yearly growth-
respondents % difference compared to the overall averages IT spending
rate over a 3 year period

27.
A strong foundation is!
• Simple architecture
• Assignments and data owned by one system
• Automation
• Tests

28.
NOT a Simple architecture
Client Client
Client Client
Proces Service Proces Service
Remote Facade
Application Service Activity Activity
Service Service
Domain Domain
Object Object
Data Access Layer Data Data
Data Data
Service Service
Service Service
Data Storage Data Data Data
Storage Storage Storage

29.
This does’t help either

30.
A big unified model is every architects
pibe dream
But as they say

31.
ONE MODEL TO RULE THEM ALL
ONE MODEL TO FIND THEM
ONE MODEL TO BRING THEM ALL
AND IN THE DARKNESS BIND THEM

32.
Still too big a model
Online Ordering System
Product Pricing
Description
Unit Price
Promotional Price
Promotion End Date
Stock Keeping Unit (SKU)
Quantity On Hand (QOH)
Location Code Inventory
Customer Price
Quantity Ordered
Sales

33.
There’s always more than one
model at play in any big project
But when code based on
multiple models is combined

34.
… then the code becomes filled with
errors, unreliable and difficult to
understand
Communication between team
members becomes confusing.
It is often unclear in what context a
model should NOT be used!

35.
Context is lacking

36.
Smaller models and ”service reuse”
Enterprise
Pricing Service
Product
SKU
Unit Price
Promotional Price
…
Web Shop
Product
SKU
Description
Pricing
Price
Quantity Ordered
Customers … Inventory Service (SAP)
Product
SKU
Description
QOH
Location Code
… Inventory
Sales

37.
Now even better – with an ESB
Enterprise
Watch out! Pricing Service
It's so easy to see a Product
product as the SKU
Unit Price
solution to all your Promotional Price
…
problems!
Web Shop
Product
SKU
Description
Pricing
Price
Quantity Ordered
Customers … Inventory Service (SAP)
Product
SKU
Description
QOH
Location Code
Enterprise … Inventory
Service Bus
Sales
Before we had 1 problem.
With the ESB we now have 2 problemes

38.
Business focus is still lacking
Processes and state changes are
important components

39.
A much better recipy
Enterprise
Pricing Service
Product
SKU
New SKU Unit Price
Promotional Price
Event …
Web Shop
Product New SKU
Price
SKU
Description
New SKU Event Pricing
Price
Price
Quantity Ordered Event
Customers … Inventory Service (SAP)
Product
New SKU SKU
Description
Event QOH
Location Code
… Inventory
New SKU
Message Bus
Event
Sales

40.
What is a strong foundation?
• Simple architecture
• Assignments and data owned by one system
• Automation
• Tests

41.
In brief…
• Clean up the system landscape ...
• Remove redundant systems
• Remove systems that no longer have a
reasonable cost-benefit
• Modernize systems which can still be make a
difference
• Build new systems that can differentiate you from
the rest
• ... And do it based on Neil Nickolaisen's Purpose
Alignment Model

42.
Neil Nickolaisen’s Purpose Alignment Model
Invest
High Partnership and
Differentiate
Market
Differentiation
Grade
Who cares? Keep on a par with
Low competitors
Low High
Criticality

43.
What is a strong foundation?
• Simple architecture
• Assignments and data owned by one system
• Automation
• Tests

44.
Automation
• Continuous Integration
– The code is automatically built and necessary tests
are conducted for verification
• Setting up environments
– Server setup, firewalls, deployment
• Integration testing
• there is much more to get here ...

45.
The solution in
ETL

46.
Electronic Landregistration
Background Information on Electronic Landregistration for those who have not heard about it ...

47.
ETL – Suggested Architecture
Internal
WebLogic Portal External Portal
Portal
Proces Service Proces Service
Integrations
Oracle Service Bus
Service
Activity Activity
Service Service
Integrations
Service
Data Data Data
Service Service Service
Database

48.
Suggested ETL Architecture
• Advantages
– Logically a reasonable decoupiling (Single
Responsibility Principle)
– Oracle makes good money on it
• Disadvantages
– Logical layers are turned into physical layer
– High complexity
– Difficult to find resources that can work with the OSB
– Stability
– Performance (both runtime and for developers)
– Deployment

49.
ETL – Simplified Architecture
Internal
Java applications External Portal
Portal
WebLogic Server
Portal Facade
Integrations
Service
Business Service Business Service
Integrations
Rich domain object Rich domain object
Service
Data Access Layer
Database

50.
Simplified ETL Architecture
• Advantages
– Physical and logical architecture are closer to each other
– Low complexity
– Stability
– Easier to find resources that can code Java
– Performance (both runtime and for developers)
– Deployment
• Disadvantages
– The CV will not be boosted with Enterprise Service Bus
– Oracle do not earn nearly as well ...

51.
ETL - Automation
Context
• Extremely complex domain area
• The rules are determined by Law (not logic)
• Covering registrations there are several
hundred years old
• Complex logic required to automate law
• Very short deadline for the third attempt to
build ETL

52.
Electronic Landregistration
• Technical choices
– Programming language: Java
– Database: Oracle
• First challenge
– How do we integrate Java and Oracle database?

53.
How it’s usually done
SQL
Java code

54.
Means we go from this…

55.
package dk.tigerteam.mdsd.demo.model.internal;
@Entity
@Table(name = "Customer")
To this…
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;
}
…
…
…
}

56.
The line between modeling og
muddling in hand written code is
very thin

57.
Can’t see the shoe for the toes?
package dk.tigerteam.mddexample.model.customer;
@javax.persistence.Entity
public class Customer extends dk.tigerteam.mddexample.model.user.User {
When all you wanted to
private static final long serialVersionUID = 1328488396L;
@javax.persistence.Lob
@javax.persistence.Basic
@javax.persistence.Column(name = "comment")
private String comment;
convey was this
@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;
}

58.
Hand held consistency…
@Entity @Entity
public 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);
}
}

59.
Automation
From sweatshops to automation


60.
At ETL we introduced this process
UML class diagrams
SQL
Java code
Hibernate Tests

61.
Another possibility

62.
Sounds hard, but it’s quite easy 
Rule Language Meta Model

+
Rule Grammar (using Xtext)
Text Editor
+
Data Language Meta Model
 Editor & IDE

63.
Point of No Return, traditionally
Cost of
Rework
Time Freeze V 1.0

64.
Point of No Return, Model Driven
Cost of
Rework
Time Freeze V 1.0

65.
The end of writing tedious code by hand
Model Generator
Interesting code
Frameworks
(Written by hand)
(Hibernate/JP Schematic code
A, Entity Written by hand
Framework)
Libraries (f.eks. Java/.NET)

66.
What do we get out of it?
• Higher level of abstraction
• Technical decisions can be postponed
• "Point of No Return" can be postponed
• Documentation is always update to date
• Higher Quality and Uniformity
• Refactoring is both faster and cheaper
• Short development cycle

67.
The real short version
We can achieve the same with fewer resources
We can achieve the same in less time
We can achieve more with the the same
resources and at the same time

68.
Electronic Land registration
Questions?
http://tigerteam.dk @TigerTeamDK on Twitter