#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 in Enterprise Systems

Architect Roles and Responsibilities

Modern Technical Architect Roles

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.

Interface Example: REST API

  • Data interface: JSON format
  • Function interface: HTTP methods
    • GET /customers/{id} - retrieve customer
    • POST /customers - create customer
    • PUT /customers/{id} - update customer
  • Process interface: state transitions
  • Technical interface: HTTPS, port 443, authentication
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, ...