Different types of Architecture patterns for Analytics and Big Data of Enterprise Architecture

Lambda Architecture: Kappa Architecture: Data Lake Architecture:

• Purpose: This pattern was proposed as a • Purpose: This pattern caters to organizations
• Purpose: This pattern aims to handle massive
simplification of the Lambda Architecture. Instead that need to store vast amounts of raw data in
quantities of data by taking advantage of both its native format, allowing for flexible, on-
of maintaining two separate code bases for batch
batch and stream processing methods. demand processing and analytics.
and stream processing, Kappa uses a single
codebase.
• Components: • Components:
• Components:
• Batch Layer: Manages the master dataset • Ingestion Layer: Collects and ingests data
and pre-computes batch views. • Stream Processing Layer: Handles incoming data from various sources in its raw format.
• Speed Layer: Deals with real-time data and streams and processes them in real-time. It can • Storage Layer: Acts as a repository storing
computes real-time views. reprocess all data if needed. vast amounts of raw data, usually in a
• Serving Layer: Responds to ad-hoc queries • Serving Layer: Holds the processed data and distributed file system.
by using both batch views and real-time serves queries. • Processing & Analytics Layer: Contains tools
views. and frameworks to process and analyze data
• Technologies: Apache Kafka for the data stream on-demand. This can be batch or real-time
• Technologies: Hadoop (for the batch layer), management, Kafka Streams or Apache Flink for processing.
Storm or Kafka Streams (for the speed layer), stream processing, and any fast, distributed • Consumption Layer: Where processed data
and Apache Cassandra or HBase (for the database for the serving layer (e.g., Apache is made available to end-users, either for
serving layer). Cassandra or Elasticsearch). querying, reporting, or further analytics.

• Technologies: Hadoop's HDFS or cloud storage

solutions like Amazon S3 for storage, Spark or
Hadoop for processing, and tools like Hive,
Presto, or drill for querying and analytics.
 Different Architecture patterns for Application Integration of Enterprise Architecture
Hub-and-Spoke Architecture:
• Purpose: Centralize integration logic, simplifying connections between multiple systems.
• Key Characteristics:
• Integration Hub: All applications connect to a central hub.
• Spokes: Represent connections to the individual applications.
• Transformation and routing usually occur at the hub.
• Advantages:
• Reduces the number of point-to-point connections.
• Centralizes error handling, monitoring, and management.

Enterprise Service Bus (ESB) Architecture:

• Purpose: Offer a more flexible and scalable approach to integration by abstracting point-to-point connections and providing common services.
• Key Characteristics:
• Centralized or distributed middleware that provides services like transformation, routing, and orchestration.
• Supports both synchronous and asynchronous communication.
• Typically, event-driven and message-based.
• Advantages:
• Reduces tight coupling between systems.
• Facilitates scalability and introduces intermediate processing capabilities.
• Supports diverse communication protocols, making it adaptable to various technologies.

API Gateway Architecture:

• Purpose: Centralize the exposure of APIs from various backend systems and Microservices, providing a unified entry point.
• Key Characteristics:
• API Gateway: A server that acts as an intermediary for API requests, routing them to the appropriate backend service.
• Provides features like rate limiting, caching, authentication, and logging.
• Backend services remain decoupled from direct external requests.
• Advantages:
• Centralized management of APIs simplifies monitoring, analytics, and security.
• Facilitates decoupling between frontend and backend services.
• Can optimize requests and responses, catering to specific client requirements.
 Architecture patterns for Compute

Serverless (Function-as-a-
Microservices Architecture Grid Computing Architecture
Service) Architecture

• Purpose: Decompose a monolithic application

into smaller, independent services that can be
developed, deployed, and scaled • Purpose: Execute code in ephemeral Purpose: Solve large-scale computation
independently. containers without managing the underlying problems by using multiple computers
• Components: infrastructure. You're only billed for the organized in parallel.
• Service Instances: Individual actual compute execution time. Components:
microservices that provide specific • Components: Task Decomposition: Breaks down the
functionalities. • Trigger: An event that starts the problem into smaller tasks.
• Service Discovery: Helps services execution of a function (e.g., HTTP Resource Allocation: Assigns tasks to
discover and communicate with each request, database change). available resources.
other. • Function: A piece of business logic Task Execution: Individual compute
• API Gateway: A single entry point for that runs in response to a trigger. nodes that process the tasks.
external consumers, directing requests • State Store: A place to store Result Aggregation: Collects and
to appropriate services. data/state if needed, as the functions compiles results from all tasks to
• Centralized Configuration: A central themselves are stateless. provide a cohesive outcome.
place for storing configuration shared • Technologies: AWS Lambda, Azure Functions, Technologies: Globus Toolkit, Oracle Grid
across services. Google Cloud Functions, and their respective Engine, and other specialized tools for high-
• Circuit Breakers: Prevent failures in one event sources and storage solutions. performance computing (HPC) environments.
service from cascading to others.
• Technologies: Docker (for containerization),
Kubernetes (for orchestration), Netflix Eureka
(for service discovery), Netflix Zuul (API
gateway), and Spring Cloud Config (centralized
configuration).
 Different Architecture patterns for Containers

Multi-host, Distributed
Single-host, Multiple-
Containers Pattern Sidecar Pattern
container Pattern
(Orchestrated Containers)
Purpose: Extend or
Purpose: Isolate Purpose: Distribute and enhance the functionality
application components manage containers across of a container without
or services within different multiple host machines, modifying the container
containers on a single providing fault tolerance, itself. Sidecars are typically
host, enabling component high availability, and used for tasks like logging,
scaling and isolation scalability. monitoring, security, etc.
without requiring multiple
host machines.

Components:
Components:
Orchestration Engine: Coordinates and manages containers Components:
Host OS: The base operating system of across multiple hosts (e.g., Kubernetes, Docker Swarm).
the host machine. Application Container: The primary container that holds
Service Discovery: Helps containers discover and communicate the main application logic.
Container Engine: Software that with each other across hosts.
manages the creation and runtime of Sidecar Container: The secondary container that runs
containers (e.g., Docker). Load Balancer: Distributes incoming traffic to appropriate alongside the application container, providing additional
containers, ensuring even load and high availability. functionality or features.
Containers: Each container
encapsulating a specific service or Nodes: Individual host machines or VMs that run containers. Shared Volumes: A storage volume shared between the
component of the application. Containers: Each container encapsulating a specific service or application and sidecar containers to exchange data or
Typical Use-Cases: Development component of the application. configuration.
environments, small-scale production Typical Use-Cases: Large-scale web applications, microservice Typical Use-Cases: Enriching application features without
applications, or any scenario with architectures, and other distributed systems demanding high touching its core logic, especially useful in microservices
limited infrastructure resources. availability and scalability. where common concerns (e.g., logging, monitoring) are
externalized into sidecars.
 Different Architecture patterns for Databases

Master-Slave (or Master-Replica) Architecture

•Purpose: Improve database availability and distribute read queries to enhance performance.
•Components:
• Master Database: The primary database where write operations are executed. Changes to the master database are replicated to one or more slave databases.
• Slave Databases: Read-only replicas of the master database. Read queries can be distributed among slaves to balance load.
• Replication Module: Manages the data replication process from the master to the slaves.
•Technologies: MySQL replication, PostgreSQL replication, and many other RDBMS that support replication.

Sharded Database Architecture:

•Purpose: Distribute a database across multiple machines to achieve horizontal scalability.
•Components:
• Shards: Individual database instances that store a portion of the total dataset. Each shard operates independently and is typically hosted on a separate machine.
• Routing Layer: Directs incoming database queries to the appropriate shard based on the query's data key or some routing logic.
• Shard Key: A key in the database schema that determines how data is distributed across shards.
•Technologies: MongoDB, Apache Cassandra, and many relational databases with manual sharding setup.

Multi-Model Database Architecture

•Purpose: Support multiple data models (e.g., document, graph, key-value, column-family) within a single, integrated backend, often eliminating the need for deploying and
managing multiple databases.
•Components:
• Data Storage Layer: Where data is persistently stored, typically optimized for diverse data structures.
• Data Model Interfaces: Different interfaces or views of the data, catering to various data models.
• Query Engine: Interprets and executes queries, translating them to operations on the underlying data models.
•Technologies: ArangoDB, OrientDB, and Cosmos DB.
 Different reference Architecture patterns for front-end Web and Mobile
Model-View-View Model Progressive Web Application
Single Page Application (MVVM) (PWA)

Purpose: Enhance web applications with native-like

capabilities such as offline access, push notifications, and
Purpose: A variant of the MVC pattern, MVVM is particularly
installability, aiming to offer a high-quality user experience on
popular in mobile application development and offers a clear
Purpose: Deliver a more fluid and responsive user experience the web.
separation of UI from business logic, facilitating easier testing
by loading a single HTML page and dynamically updating it as
and maintenance.
the user interacts with the app.
Components:
App Shell: The minimal HTML, CSS, and JavaScript powering
Components:
Components: the user interface, cached for fast load times.
View: Displays the UI, often using declarative bindings.
View: The user interface (UI) that displays information. Service Worker: A script running in the background, separate
ViewModel: A mediator that holds the presentational logic
Controller: Manages user input and updates the view. from the web page, enabling features like offline support,
and transforms the model data into a format that the view
Model: Represents the data and business logic. resource caching, and push notifications.
can easily display.
Router: Handles navigation between different parts or views Web App Manifest: A JSON file providing metadata about the
Model: Represents the data and the core business logic.
of the application without causing a full page refresh. app, allowing it to be installable on the user's home screen.
IndexedDB or Cache API: Storage mechanisms allowing for
Technologies: For web, frameworks like Knockout.js support data persistence and offline functionality.
Technologies: React, Angular, Vue.js, and other JavaScript
this pattern. For mobile, platforms like Xamarin, Android
frameworks.
(with Android Architecture Components), and iOS (with tools
Technologies: Most modern web browsers support PWAs.
like Combine and SwiftUI).
Frameworks and libraries like Workbox, Ionic, and Angular
can aid in PWA development.
 Different reference Architecture Patterns for Management and Governance
Service-Oriented Architecture (SOA) Governance
Purpose: Oversee the lifecycle of services in a Service-Oriented Architecture, ensuring that they meet organizational objectives, align with design principles, and offer maximum reuse and
interoperability.
Components:
• Service Registry & Repository
• Policy Repository
• Governance Workflow Engine
• Service Test Harness
• Policy Enforcement Points
Typical Use-Cases: Large enterprises deploying SOA to integrate disparate systems and promote business agility.

Cloud Governance Architecture

Purpose: Manage and oversee cloud resources to ensure they align with organizational objectives, security standards, and cost constraints.
Components:
• Cloud Management Platform (CMP)
• Cost Management Tools
• Policy Engine
• Security & Compliance Module
• Resource Templates & Blueprints
Typical Use-Cases: Organizations with multi-cloud environments or those looking to optimize and secure their cloud infrastructure.

Enterprise Architecture Management (EAM)

Purpose: Align IT assets, processes, and projects with business objectives and strategies, facilitating decision-making and long-term planning.
Components:
• Architecture Repository
• Modeling & Visualization Tools
• Governance Framework
• Standards & Guidelines Library
• Decision Framework
Typical Use-Cases: Large organizations undergoing digital transformation, mergers & acquisitions, or those aiming to optimize their IT landscape.
 Different reference Architecture Patterns for Migration

Lift-and-Shift (Rehosting):
Purpose: Quickly migrate applications and data from one environment to another with minimal changes, often used for moving on-premises infrastructure to the cloud.

Application Refactoring (Replatforming):

Purpose: Modify or extend the existing application's codebase to fit and optimize for the new platform, while not making significant changes to the core architecture.

Rebuilding (Re-architecting):
Purpose: Redesign and rewrite the application from the ground up, leveraging the features and services of the target platform to achieve better scalability, resilience, and flexibility.

Lift-and-Shift(Rehosting) Application Refactoring Rebuilding

Components Components Components
• Migration Tools • Refactoring Tools • Application Frameworks
• Target Environment • Middleware Replacements • Microservices and Serverless Architectures
• Configuration Mapping • Data Migration Tools • Data Transformation Tools
• Continuous Integration/Continuous
Technologies: AWS Server Migration Service, Azure Technologies: AWS App2Container, Azure Database Deployment (CI/CD) Pipelines
Migrate, Google Cloud Migrate for Compute Engine. Migration Service, Google Cloud Anthos Migrate.
Technologies: AWS Elastic Beanstalk, Azure
Kubernetes Service, Google Cloud Run, and
various CI/CD tools like Jenkins, GitLab CI, and
others.
Different reference Architecture Patterns for Security, Identity and Compliance

• Components
• Identity Provider (IdP)
Zero Trust Network Architecture • Policy Engine
Purpose: Assume no trust for any user or device, regardless • Network Segmentation
of whether they are inside or outside the network perimeter. • Continuous Monitoring & Analytics
Grant access based on strict identity verification and ongoing • Technologies: Google's BeyondCorp, Cisco's Zero
context-aware security checks. Trust, and solutions like Okta, Duo Security.

• Components
• User Directory
Identity and Access Management (IAM) • Authentication Service
Purpose: Manage digital identities and their permissions • Authentication Engine
across systems and services. Ensure the right individuals • Multi-Factor Authentication
access the right resources at the right times for the right • Role-Based Access Control (RBAC)
reasons. • Identity Federation
• Technologies: AWS IAM, Azure Active Directory,
Google Cloud Identity, Okta, and many others.

• Components:
• Data Classification
• Data Loss Prevention (DLP
Data-Centric Security Architecture • Data Masking & Tokenization
Purpose: Focus on securing the data itself rather than just the • Data Encryption
perimeter or endpoints. This is especially relevant with the • Access Control
rise of mobile devices, cloud computing, and decentralized • Audit & Monitoring
data storage. • Technologies: Symantec DLP, McAfee Total Protection
for Data, Microsoft's Azure Information Protection,
and various encryption solutions.
 Different Architecture Patterns for Storage

File System Storage (or

Object Storage Architecture Block Storage Architecture Network-Attached Storage -
NAS) Architecture

Purpose: Store vast amounts of unstructured

data, such as photos, videos, and backups, Purpose: Deliver high-performance storage that Purpose: Provide a centralized location for data
while providing high scalability, data applications can access as if they were storage and access over a network, best suited for
durability, and ease of management. accessing a physical hard drive, suitable for shared folders, user home directories, and
databases, file systems, and virtual machines. collaborative projects.

Components Components
Components:
Storage Nodes Storage Array
Storage Devices
Data Distribution & Management Layer Controller
File System Layer
RESTful API Interface Logical Unit Numbers (LUNs
Network Protocol Layer
Metadata Store Storage Protocol
NAS Head or Controller
Technologies: Amazon S3, Google Cloud Storage, Cache Layer
OpenStack Swift. Redundancy Mechanisms
Technologies: Amazon EBS, Google Persistent Disk,
traditional SAN (Storage Area Network) solutions. Technologies: Solutions like NetApp, QNAP,
Synology, and cloud equivalents like Amazon
EFS or Azure Files.
 Different reference Architecture Patterns for Payments

Centralized Payment Gateway Distributed Ledger Payment System

•Purpose: A centralized system that processes payments, acting •Purpose: Use a decentralized approach to process transactions,
as an intermediary between merchants and financial eliminating the need for intermediaries and offering potential
institutions. This pattern simplifies the payment process for improvements in speed, cost, and transparency.
merchants, abstracting the complexities of direct interactions •Components:
with banks or card networks. • Nodes
• Consensus Mechanism
•Components: • Smart Contracts
• Merchant Interface/API • Wallets
• Payment Processor • Integration APIs
• Risk & Fraud Detection •Typical Use-Cases: Cryptocurrency payments, cross-border
• Settlement & Reconciliation remittances, programmable financial systems.
• Integrations with Financial Institutions

•Typical Use-Cases: E-commerce platforms, online service

providers.

Microservices-based Payment Architecture

Purpose: Break down the payment processing into smaller, decoupled services, each handling specific functionalities. This approach facilitates scalability, resilience, and faster iterations.
• Components:
• Payment Initiation Service
• Payment Queue
• Processing Microservices
• Notification Service
• Audit & Logging Service
• Security & Fraud Detection Service
• Typical Use-Cases: Large-scale e-commerce platforms, fintech startups, businesses requiring high customization or integration with multiple payment methods.
 Different reference Architecture Patterns for Headless e-Commerce

API-Driven Headless Architecture JAMstack-Based Headless Architecture Microservices-Based Headless

Architecture

Purpose: Decompose e-commerce functions into smaller,

Purpose: Utilize APIs to bridge the gap between the frontend independent services that communicate via APIs. This
and backend, ensuring decoupled operations. This allows for Purpose: Embrace the JAMstack (JavaScript, APIs, and
Markup) paradigm to deliver highly performant, secure, and enhances scalability, resilience, and allows for modular
multiple frontends (websites, mobile apps, IoT devices) to use development and deployment.
the same backend services seamlessly. scalable e-commerce solutions, leveraging static site
generation and decoupled services. Components:
Components:
Components: Product Service
Content Delivery API
Static Site Generator Cart Service
Commerce API
Headless CMS Order Service
User Profile & Authentication API
Serverless Functions Payment Service
Payment Gateway API
CDN (Content Delivery Network User Service
Frontend Applications
E-commerce Backend APIs Frontend Service
Technologies: Netlify, Vercel, Contentful, Snipcart, Stripe for Technologies: Kubernetes for orchestration, Istio for service
Technologies: Platforms like CommerceTools, Magento (via payments. mesh, platforms like Shopify's Storefront API or Magento's
API), and Big Commerce (via API). Microservices architecture.