This document summarizes a guest lecture at UNSW about contemporary software challenges and solutions. It discusses how technology can provide a competitive advantage if developed properly. It presents case studies of legacy systems that were difficult to change and scale, as well as examples of systems that used newer architectures like microservices. The lecture promotes approaches like test-driven development, REST, and self-organizing teams to build independent, scalable services.

1. A Tale ofA Tale of
Contemporary SoftwareContemporary Software
UNSW Guest LectureUNSW Guest Lecture
March 2015

2. About MeAbout Me
Comp Science Bachelor UNSW
Applied Finance PostGrad at Macquarie Uni
IBM, Sun, Accenture, BGI/BlackRock, Macquarie Group
Now innovating and opinionating at Trunk Platform
yunspace yunzhilin yunspace.com
My opinions does not reflect the view of the company
Shout out if you have questions or need a break

3. ChallengesChallenges
Case StudiesCase Studies
SolutionSolution
Implement*Implement*

4. ChallengesChallenges

5. Market EfficiencyMarket Efficiency
We live in a market
Stock prices reflect and adjust to all public information
Little room for arbitrage or outrageous profit
Information Efficiency also applies to business & competition:
What you try to do, others are already doing/copying
Your customers are very likely to know more than you​​
You need to process information fast, but also relevant
Semi-Strong Efficiency

6. TechnologyTechnology
becomes Key Differentiatorbecomes Key Differentiator
Superior technology gives competitive advantage:
Exploiting Market Anomalies such as Momentum trading
Arbitraging tiny inefficiencies: Quantitive, Frequency trading.
Destroying information asymmetry and "experts": RPdata
Disrupting established markets: Uber, Tesla
Providing better UX for boring things: CBA, Simple.com
All we need is good software ...

7. Every CompanyEvery Company MUST beMUST be
Software CompanySoftware Company
The era of separating traditional industries and technology
industries is over—and those who fail to adapt right now will
soon find themselves obsolete.
- Forbes 2011Now Every Company is A Software Company
Offshoring and underinvestment in core technology is
detrimental
solution is not cost cutting, but more effective technology
"tech refresh" is primitive idea, should always refresh
CIO are supposed to be visionary leaders, not accountants

8. Conway's LawConway's Law
organizations which design systems ... are constrained to
produce designs which are copies of the
communication structures of these organizations
Melvin Conway - 1968
- Sarah Novotny (NGinx)Don't Forget Conway's Law
MelvinConway.com
Good Software Design starts off with Orgnisational Design

9. Siloed SystemSiloed System
Information and Capabilities lost in translation between silos

10. Prefered SystemPrefered System
Lead to architecture based around business capabilities

11. Software Systems must ConnectSoftware Systems must Connect
Information are rarely stored in a single place,
but integration of systems is hard:
Any two applications are different
Application changes are inevitable
Networks are unreliable and slow
, Gregor HohpeEnterprise Integration Patterns

12. ConclusionConclusion
Technology can differentiate in a competitive world.
Challenge is to process information more efficiently
But building good software is hard:
Traditional siloed teams hinder collaboration
Integrating applications is painful

13. CaseCase
StudiesStudies

14. Aladdin PlatformAladdin Platform
25Million lines of code
One stop shop for risk & portfolios
Central DB, no integration needed
20,000 users, 30,000 portfolios
1000+ developers, built over 20 yrs
single point of failure
death by stored procedures
slow change cycle (legacy)
siloed development team
thick client
Built around 1994. Iconic Monolithic, OS for traders

15. Tightly Coupled SystemsTightly Coupled Systems
= Useless but Deadly Change Review Meetings= Useless but Deadly Change Review Meetings
Legacy monoliths tend to be defensive, "keep the lights on"
Lack of tests -> unknown risks -> afraid to make changes
Making changes is equivalent to "chucking a Prince Oberyn"

16. BGI Global MesssagingBGI Global Messsaging
Publish / Subscribe
Real time, high speed
Across 3 time zones
Canonical Data + Enrichment
Decoupled end services
custom 3rd party messaging
ESB potential point of failure
Data is Publisher driven
Cross functional stops at ESB
Bottleneck shift to ESB
$$$ internal & external work
Tragedy of the commons
Enterprise Service Bus
ETFCash FixedEquities
Custodians SWIFT
Counter
Party
early 2000s, Traditional SOA, quite ahead of its time:

17. ESB promises:ESB promises:
That's a lot! Concerned about Separation of Concerns?

18. Scaling the ESBScaling the ESB
One size fits all: Every on the Bus gets same treatment.
Looser coupling and independent scaling would be nice

19. ESB in RealityESB in Reality

20. ConclusionConclusion
Monoliths and tight coupling are bad
ESBs isn't perfect, but stepping in right direction

21. SolutionSolution

22. 40 years of Service Evolution40 years of Service Evolution
- PWC Technology Forecast 2014
Microservices: The resurgence of SOA principles and an alternative to the monolith

23. Change ManagementChange Management
- PWC Technology Forecast 2014
Microservices: The resurgence of SOA principles and an alternative to the monolith

24. What are MicroServicesWhat are MicroServices
NetFlix, Amazon, realestate.com.au, Tyro, Atlassian
http://martinfowler.com/articles/microservices.html
Similar to traditional SOA, except no more ESB
Consumer driven contracts instead of Canonical Data
Fault tolerant and independently scalable

25. Activity Based Working

26. SelfSelf
OrgnisingOrgnising
TeamTeam

27. Cross Functional DeliveryCross Functional Delivery
Business
UI/UX Design
Front End
Dev
Back End
Dev
Infrastructure/
DevOps

28. ConclusionConclusion
Split into Self Organised Teams around Capabilities
Cross functional collaboration deliver Capabilities
Decoupled and scalable Capabilities collectively
form Microservices Architecture (MSA)

29. ImplementImplement
(optional homework)(optional homework)

30. Test Driven DevelopmentTest Driven Development
How do you know when you broke something?
you don't, so write tests!
There is no such thing as untestable code @CodaHale

31. Highly recommend Uncle Bob's book:
Clean Code
The Clean Coder
Find out more at:
cleancoder.com
cleancoders.com
Write Clean CodeWrite Clean Code

32. Twelve Factor AppTwelve Factor App
By Heroku:
Some opinionated points that apply to University work:
One Code base - use git: github/bitbucket
Config - use environment variables
Dependencies - use gradle to avoid death by xml:
12factor.net
repositories {
jcenter()
maven { url "http://dl.bintray.com/trunkplatfo
}
}
dependencies {
compile group: 'com.trunkplatform', name: 'servi
}
<repositories>
<repository>
<snapshots>
<enabled>false</enabled>
</snapshots>
<id>bintray-trunkplatform</id>
<name>bintray</name>
<url>http://dl.bintray.com/trunkplatform/osworkflow</url>
</repository>
</repositories>
<dependencies>
<dependency>
<groupId>com.trunkplatform.opensymphony</groupId>
<artifactId>service</artifactId>
<version>3.1.4</version>
<scope>compile</scope>
</dependency>
</dependencies>

33. Use REST, no WSDL/SOAPUse REST, no WSDL/SOAP
{
"streetNumber": "80",
"streetName": "Clarence",
"suburb": "Sydney"
}
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:p="http://www.platmasphere.com/createProperty.xsd">
<p:CreateProperty>
<m:Property>
<m:streetNumber>80</m:streetNumber>
<m:streetName>Clarence</m:streetName>
PUT /hostname/properties/<definitions name="PropertyService"
targetNamespace="http://namespaces.snowboard-info.com"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<!-- not including model schemas -->
<message name="CreatePropertyRequest">
<part name="body" element="CreatePropertyRquestModel"/>
</message>
<message name="GetPropertyResponse">
<part name="body" element="CreatePropertyResponseModel"/>
</message>
<portType name="Properties_Port">
<operation name="CraeteProperty">
<input message="CreatePropertyRequest"/>
<output message="CreatePropertyResponse"/>
<fault message="CreatePropertyFault"/>
</operation>
</portType>
<binding name="CreateProeprtySoapBinding"
type="GreatePropertytType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="CreateProperty">
<soap:operation
soapAction="http://www.platmasphere.com/CreateProperty"/>
<input>
Managed to avoid death by XML again!

34. Good RESTGood REST
is notis not
Remote Proc Calls over HTTP:
POST /api/getUserById/{id}
POST /api/createUser/
POST /api/updateUser/{id}
POST /api/delUserById/{id}
isis
Resource oriented, http verbs:
GET /api/user/{id}
POST /api/user
DELETE /api/user/{id}
PUT /api/user/{id}
REST Verbs Reference:
http://www.restapitutorial.com/lessons/httpmethods.html

35. REST in JavaREST in Java
1. Java API for Restful Services:
2. Implemented by Jersey:
3. Made even more awesome by:
https://jax-rs-spec.java.net/
https://jersey.java.net/
http://dropwizard.io/
++ == PROFITPROFIT

36. Dropwizard.ioDropwizard.io
Dropwizard makes it easy to do the right thing,
allowing you to concentrate on the essential
complexity of a problem rather than the plumbing
ThoughtWorks Technology Radar
Getting Started:
Sample Project with Heroku support:
Our Dropwizard-Turbo LazyBones Template:
http://www.dropwizard.io/getting-started.html
https://github.com/Trunkplatform/dropwizard-petstore
https://github.com/Trunkplatform/lazy-bones-dropwizard-turbo

37. PostManPostMan
For manual testing: https://www.getpostman.com/

38. Swagger.ioSwagger.io
Who needs WSDL when you have Interactive Docs

39. Questions?Questions?
I'll be talking some more at:
- Microservices Meetup 1st AprilDropwizard and Friends
www.trunkplatform.com
Startup focusing on Real Estate
Old industry, new ideas
We are very Contemporary
Self Organised
And we use Microservices
We are Hiring!We are Hiring!