This document provides an overview of enterprise architecture and integration challenges. It discusses the evolution from client-server to peer-to-peer architectures and common integration problems. The document outlines approaches to solving integration problems including getting data to and from systems, focusing on predictable outcomes through standards and best practices, and developing iteratively. It then provides an example approach involving starting with both data and APIs/apps, testing initial plans, facilitating data access, designing interfaces for users and third parties, and connecting different technologies while avoiding over-engineering solutions. The document promotes the WSO2 integration platform as offering open source products for connecting systems but notes there is no single best solution and the unexpected will occur.

1. Enterprise Architecture in Practice:
from Datastore to APIs and Apps
Senaka Fernando
Solutions Architect, WSO2 UK

2. What to Expect
2
 A brief introduction to the evolution of
enterprise architecture. This will help you
validate your thinking.
 Typical challenges faced by enterprise
architects when dealing with customers – from a
integration vendor’s perspective.
 Proven approaches towards “most-acceptable”
and “best-value-for-money” solutions to common
integration problems.
 Insight from experience in working with
customers.

3. Outline
3
 A bit of history
 Business requirements keep changing
 From problem to solution
 Lets take an example

4. A bit of history
4

5. Client-Server Architectures
5
 Many applications served
over the internet (even
today) are client-server
oriented.
 A simple, centralized
model of interacting with a
number of different
systems.
 Earlier systems were
mostly around content
delivery.
Image: https://en.wikipedia.org/wiki/Client%E2%80%93server_model#/media/File:Client-
server-model.svg

6. Peer-to-Peer Architectures
6
 A simple de-centralized
model of distributing data
across multiple nodes.
 Mostly implement some
form of overlay on top of
some physical topology.
 Can be structured or
unstructured in terms of its
operation.
 File-sharing,
communication, Bitcoin
Image: https://en.wikipedia.org/wiki/Peer-to-peer#/media/File:Unstructured_peer-to-
peer_network_diagram.png

7. Some Common Problems
7
 How can I build an application that is both client-
server and peer-to-peer?
 Are there ways to reuse what I develop?
 How can I decouple server-side logic from the
corresponding consuming client?
 Am I the only person with the same problem?
Are there any standard solutions?

8. A 3-Tier Architecture
8 Image: https://en.wikipedia.org/wiki/Multitier_architecture#/media/File:Overview_of_a_three-tier_application_vectorVersion.svg

9. Business requirements keep changing
9

10. More Money: COTS
10
 Commercial-off-the-shelf software are pre-built
packages of an application tailored to suit a
broad set of businesses in a given industry:
 Media
 Finance
 Retail
 Transportation
 Also for Home Users

11. More Time: Process-driven/Bespoke
11
 Tailor-made processes with some reuse of
existing logic.
Image: http://blogs.technet.com/b/yungchou/archive/2010/09/21/business-intelligence-bi-with-visio-services-in-sharepoint-2010.aspx

12. Modern Reality: Less Time & Money
12
 A totally different ball game
 Agile development
 Pay as you go (PAYG) pricing
 Cloud/Hybrid infrastructure
 Minimum viable product (MVP)
 DevOps
 Continuous delivery
 Rapid change/evolution
Image: https://upload.wikimedia.org/wikipedia/commons/thumb/5/58/Scrum_process.svg/2000px-Scrum_process.svg.png

13. From problem to solution
13

14. Get Data to/from Systems & Humans
14
 If you take the integration space, this is the
absolute problem behind everything.
 The solution you choose depends on what you
need.
 How you solve it depends on who you choose to
work with.
 The ideal project is where the two points
mentioned above align perfectly.

15. Both Vendor & Customer Contribute
15
 Others (Analysts, Consultants, Developers)
assist.
 The best approach is where the outcome is
predictable.
 This is why you need standards and best
practices
 This is why patterns are preferred over one-
offs

16. Predictable Outcomes
16
 Different approaches
 Frameworks (TOGAF, Zachman)
 Models (OSIMM, CMM)
 Languages/Notations (ArchiMate, TOSCA,
BPMN)
 Practices (Gartner, Vendor-driven)
 What generally works: Best of Breeds

17. The Devil is in the Detail
17
 Customer requirements
 Mobile-first APIs
 A variety of storage formats
 Unified look and feel across heterogeneous
applications
 Limitations of Technology
 Slow back-ends
 Hybrid cloud challenges
 Edge-cases
Image: https://encrypted-
tbn3.gstatic.com/images?q=tbn:ANd9GcQSBPsKsbziy5xeUYXnzyfby
DPMVK3CByArpYT9lqkRq5D6boodEQ

18. {foo, bar} in Practice
18
 Because at the end of the day, no matter what is
said and done, it has to work
 The 80-20 Rule
 You never can estimate everything in advance
 Developing in Iterations (regardless of what
the methodology is)
 Fail early, fail often (aka Fail fast, fail often)

19. Lets take an example
19

20. Step 1: Where to start?
20
 Data-first (bottom-up)?
 API-first or App-first (top-down)?

21. Step 1: Where to start?
21
 Data-first (bottom-up)?
 API-first or App-first (top-down)?
 From experience: it is always a “Meet in the
Middle”
 So start @ both ends.

22. Step 2: The Perfect Plan
22
 Many people who I worked with want to start
with the best, if not perfect approach.

23. Step 2: The Perfect Plan
23
 Many people who I worked with want to start
with the best, if not perfect approach.
 From experience: it always changes.
 So, test the waters before you jump in.
 And, walk before you run.

24. Step 3: Getting to/from Data
24
 No database or data repository will give you an
API or Application that is a perfect fit for your
requirement. At least for now.
 So, prepare to do something (code, configure,
build).
 The vendor who wins:
 Is easy to learn/adopt
 Saves both time and money

25. Step 4: How to Design the Interface?
25
 When you build your Application, think like Steve
Jobs.
 Your should settle for nothing but the best.
 But, when I say best it should be the best for
both you and your consumer.
 When you create your APIs think it is the next
Android.
 Unless your API can be used by a 3rd party, it
will never succeed.

26. Step 5: Make the ends Meet
26
 This is the last and most important step.
 Enterprise Integration Products
 Business Processes
 Mobile Back-ends
 …
 Support your infrastructure with security,
governance, analytics, etc.
 But, don’t just deploy a set of products just for
the sake of it.

27. Why WSO2?
27
 Your solution need not be 100% WSO2.
 We have some customers like that, but that’s
a different story.
 We happen to have a complete platform of
products, when it comes to connecting anything
to anything.
 Which is also 100% open source and 100%
free to use.
 Yes, we get paid, but that’s for support and
services – value for money.

28. 28
Why WSO2?

29. There is No Silver Bullet
29
 Read “No Silver Bullet —Essence and Accident
in Software Engineering, Fred Brooks (1986)”
 You never can build the ultimate system, so
don’t worry about things you don’t need
immediately.
 Focus on real problems and real solutions rather
than things that may happen in the future.
 Be prepared to expect the unexpected. There is
no such perfect system.
 Think practically; not simply because someone
told so.

30. Summary, Q&A
30

31. Thank You ..!http://wso2.com/