Week 1

Lecture
Outcome:
Assemble applications
Evaluate different architectures for building enterprise solution
build SOA
und
Low code dev platform : OutSystems, mindex
messaging platform: HTTP, AMQP
Package application for deployment: Docker
API Gateway: kong Gateway
Now, almost all end - to - end process is automated
Activity: Identify applications that may be involved in the business process(es) for buying a book from amazon.com
Product management System:
Details and description of each product
atomic service: smallest piece of code for optimal reuse
All the relevant information is consolidated in one service
CRUD applicable to one service
unaware of other atomic svc or composite svc
Reusable
keep all data in one place; do not duplicate into different systems
Composite Service: Calls multiple different atomic systems
Keep exclusive service; only atomic svc needed for a composite svc accessible
Sees all the atomic svc it needs; can call to other composite svc
SoA Layers:
UI
Composite Svc
Atomic Svc
SME doesnt need enterprise SoA; monolithic is sufficient
Data in motion vs data at rest:
find out about this
Data concurrency
Create single thread
Good to have project
online
real-time interaction by humans
offline
batch mode processing; doesn't require real time interaction
Categories of different application:
Commercial of the shelf (monoliths)
meet ~80% of requirements;
the remaining 20%: Have third party to tailor the software or change the business process to remove the remaining 20%
Custom (both)
key-man risk: the person build it left the company and no one else in the company knows how to maintain it
trade secret/ process: cannot spec it out
cost can be the same as COTS
Legacy (monolith)
time frame of old system: ~20 years old
e.g. IBM main frame
Very reliable and high performance
Reluctancy to change technology; require to halt existing system that many people rely on;
have wrapper svc to make it reusable and extend the legacy system

Monolithic Application Architecture:

1 IU
Many functions in the server
Developed in 1 programming language
Can be large and complex
1 database
Difficult to scale; one option is horizontal scaling by adding servers; expensive
tightly coupled; changing one functions need to retest the entire functions

Micoservices architecture

Two pizza rule: If u need more than 2 pizzas to maintain the team, the code is too big
API; webservice standards allow different services communciate despite different languages
scaled independently using containerisation technology (using docker)

Messaging: AMQP

REST API
Must use HTTP
Use URL or URI
{Protocol/domain name/functions or routes/ port number}
Any data format
port 5000 - default port for flask
JSON schema: swagger file / OpenAPI
Define the structure of the message
made json to be more wildly used compare to XML

Definition of Enterprise
An organisation, company or business:
a manufacturing/catering/farming enterprise
a large/small/medium-sized enterprise/start-up
a state/state-owned/multinational enterprise/government agency
a domestic/local/foreign enterprise
either for profit or non profit
 include people, business processes and products/services

Enterprise Ecosystem Example

Applications in an Enterprise
Refers to IT Systems, IT applications etc... Can also include hardware
Each business unit plays different roles and produces/process different type of datas
Each unit can involves multiple processes and perform various activities
An activity in a business process often relies on enterprise applications

Interactions among Enterprise Applications

An activity performed by a person in an enterprise can affect other parts of enterprise according to business process
Enterprise applications supporting the activities need to interact and collaborate
The same application can be (re)use to support different activities in different business processes (excel used for tracking cash flow also used for generating financial statement)

Role of Enterprise Applications in Business Process

An activity often needs supports from applications; which can support various activities across various processes
It can:
Provide interface to perform business activity
Apply pre-defined rule to process input data
Analyse data
Produce data
Retrieve data
Send data to another application

Need for Enterprise Applications to Exchange Data

Many applications support different business activities and handle different data relevant to different parts of enterprise
Some business process requires applications from >2 enterprises to collaborates
Not all activities or data can be supported or handled in one application
Automating exchange of data among applications automate business processes and improv productivity

Definition of Enterprise Solution

An enterprise solution refers to one or more enterprise applications that produce, process and exchange data in order to fulfil business requirements

Characteristics:
Data:
Store a lot of persistent data
Data is often accessed and processed concurrently
Often need to exchange data among applications
Provide a lot of user interface screens for different business units and/or processes
 Not all processing happens real-time online; some offline (batch) processing is used; depend on to business logics
Can be in the form of executable rules
It is a challenge to make applications easily adaptable to changing requirements
A large enterprise often has applications that were built over many years using different technologies
It is a challenge to enable data exchange among various kinds of applications

Monolithic Application Architecture

In the past, an enterprise application is usually built as a single unit with a single executable
It usually comprises three main parts
Client-side User Interface (e.g., HTML pages and javascript running on the browser)
A database (consisting many tables covering multiple entities)
Server-side application that handles:
The HTTP requests,
Executes business logic,
Retrieve and update data from the database,
Select and populate HTML view to be sent to the browser,
The server-side application is usually deployed as a single package, referred to as a monolithic application or monolith

Characteristics:
Has a single code base implementing all functions needed for various business processes
e.g., one big archive file (with .war or .ear suffix) for a Java enterprise application
one folder containing various subfolders and many files for a PHP web application
Typically, the entire application is developed in one programming language on one platform
Easier for different parts of the application to be compatible
Less flexibility for the choices of technologies
Less suitable for heterogeneous environments
Over the years, the single code base may become large and complex, difficult to understand and maintain
Different parts of the application have too many interactions and dependencies, even though the code may be modularised
Deployment of a monolith is often either all or none
Not easy to deploy only a part of the application due to dependencies
A change to one function often requires redeploying the entire application package
Scaling only a specific function is not possible, the entire application has to be scaled
Scaling refers to adding/removing computing resources