#META_LECTURE#: #TITLE#

Modified: #LAST_MODIFIED#
Humla v#HUMLA_VERSION#
Architecture Overview

Global Architecture

Views

Enterprise Architecture

Enterprise Architecture Levels

Enterprise Architecture Representation

Organization Types

Architect Roles

Data, Functions and Processes

Process Classification Framework

Order Process Example in Telco

Syntax and Domain Semantics

Simplified Order Type Example

Integration

Integrating Applications

  • Intra-Enterprise Integration
    • Applications exist in a specific area
    • Functions and data often overlap across areas
    • There is a need to integrate applications within enterprise:
      • Applications need to share the same data that are often in different formats.
      • Applications need to communicate – a result of one process may trigger another one.
  • Inter-Enterprise Integration
    • Also called Business-to-Business Integration (B2B)
    • Automation support for communication and collaboration among enterprises
    • For example, B2B automates customers' orders processing, tracking orders, etc.

Integration Example – O2C

Integration Issues

  • Key to integration = interface
    • standards – data, functions, processes, technical aspects
      • enterprise standards, committee standards
      • unified environment from a single vendor
    • mediators
      • where standard do not work out
  • Data
    • Message exchange formats, data representation
      • often standardized
    • Semantics of data
      • also standardized, more difficult
  • Functions and processes
    • how apps' functionalities should be consumed and orchestrated, protocols, naming issues
    • A service concept
Software Architecture
Types, Separation of Concerns, Interface

Software Architecture Types

  • Centralized – Client/Server (C/S)
    • Central server, a bunch of clients
    • monolithic, two–, three–, multi–tier architectures
    • Single point of failure!
      • when a server fails the whole system fails
      • need for a scalable and highly reliable server-side solutions
    • Enterprise systems (mostly) use centralized solutions
      • But, enhanced with peer-to-peer principles
  • Decentralized – Peer-to-Peer (P2P)
    • Reliability
      • when a node fails, other nodes take up its function
    • Scalability
      • multiple nodes can share the load
      • such as messaging systems in enterprise systems

Separation of Concerns

  • Separation of Concerns
    • also called Separation of Layers
    • Concern – any piece of interest (part) in the application
      • concerns should overlap in functionality as little as possible
    • Basic application concerns: data manipulation, data integrity, application logic, user-interactions
    • Software architecture separates concerns into layers
      • presentation, application, data
  • Interface
    • ∼ agreement on "how layers should communicate"
    • most important artifact in Separation of Concerns
    • If an interface is in place, application development and innovation can happen independently at each layer

Interface

  • Definition
    • Agreement (contract) between two or more layers during communication
  • May be achieved by
    • Through standards (accepted or enforced),
    • Through a social agreement during design
    • A dominant position of a technology on the market
  • Interface includes subsets of domain architectures
    • Subsets that are subject to communication between layers
    • data – defines communication language (syntax, semantics),
    • functions – defines entry points (operations),
    • processes – defines valid states and transitions between them
    • technical details – protocols, ports, IP addresses, etc.

Complex Interfaces

  • More levels of interfaces
    1. DBMS native interface
    2. JDBC – universal connectors for various DBMS systems
    3. JDO – mapping of Java classes to data objects
    4. Domain Object Model (OM) – app-specific (~API, SDK)
      • try to be as universal as possible; cover many technologies
Client/Server Architectures

Monolithic Architecture

  • All layers on a single machine
    • usually non-portable apps; specific OS
    • first types of computer systems, typical for 90-ties
    • single-user only; standalone apps, minimal integration
    • technologies: third-gen programming languages, local storage systems
  • Drawbacks
    • hard to maintain (updates, distribution of new versions)
    • data security issues
    • performance and scalability issues

Two-tier Client/Server Architecture

  • Presentation and app layers separated with data
    • Thick client – desktop application, OS-dependent
    • Data on a separate server (DBMS)
    • Multi-user system, all sharing a database
    • Storage system of high performance, transactions support
    • SQL technology; native OS desktop application
  • Drawbacks
    • Thick client hard to maintain (reinstallation with every update)
    • No app logic sharing (only through copies)
    • Data-oriented integration (integrity in the app logic!)

Three-tier Client/Server Architecture

  • All layers on separated machines
    • Thin client – desktop application or interpreted code
    • Multi-user system, all sharing app logic and a database
    • App server of high performance, scalability
  • Drawbacks
    • Spaghetti integration
    • Limited, single app server scalability

Multi-tier Client/Server Architecture

  • Additional middleware layer
    • provides value-added services for communications
    • individual servers or a compact solution (e.g., Enterprise Service Bus)
  • Drawbacks
    • Monolithic apps are difficult to scale as a whole
    • Deployment overhead
    • A single technological environment for all app functions in the monolith

Client/Server Architecture (microservices)

  • Microservice architecture
    • Middleware, app and DB monoliths are microservice architecture
    • Improved scalability and technology neutrality of app components
  • Service orchestration layer
    • Kubernetes (K8s)
    • Large K8s cluster for all, middleware, app, DB
    • Separate K8s cluster

Client/Server Architecture (microservices)

  • Not-a-microservice Architecture
    • Monoliths deployed to Kubernetes cluster
    • Improved Deployments (via container images)
    • Improved fail-over
    • Not cheaper (Kubernetes costs come into play)

Types of Middleware

  • Scalability
    • They help to achieve high performance through better scalability
    • Messaging Servers (message queues, publish/subscribe)
    • Load Balancers
    • Proxy servers, reverse proxy
  • Functional
    • They help to achieve more flexible integration
    • Process servers
    • Repositories, registries of services/components
    • Mediators – data interoperability, process interoperability, technical interoperability (SOAP server)
    • Monitors for analytics of apps usages
  • Security
    • Firewalls, Gateways, ...