Enterprise Architecture in Practice: from Datastore to APIs and Apps

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

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.

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

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

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

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?

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

Business requirements keep changing
9

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

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

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

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.

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

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

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

{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)

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

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.

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

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.

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

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.

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.

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.

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.

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

Enterprise Architecture in Practice: from Datastore to APIs and Apps

More Related Content

What's hot (20)

Similar to Enterprise Architecture in Practice: from Datastore to APIs and Apps (20)

More from WSO2 (20)

Recently uploaded (20)

Enterprise Architecture in Practice: from Datastore to APIs and Apps

Editor's Notes