Architecture Essays
All business domains and sub-domains have the following functional IT architecture systems in common. Use this for your Architectural Thinking while creating or improving IT solutions.
This paradigm gives you the model artefacts for your Architecture Decisions. Read this article and return.
Problem Context
To develop architectural solutions, you must begin with the Use Case and Interaction Type and develop architecture problem statements.
Use Cases come in a wide variety in each business domain.
We abstract Interaction Types into —
a. Online Transactional Interaction (e.g., search for a product in an eCommerce portal)
b. Online Analytical Interaction (e.g., find all customers of a specified age range and purchase location who rated a specified product higher than four stars out of five)
c. (Offline) Batch Job (e.g., extract a subset of significant fields from the master data store, summarise the quantitative values for each day and store the records in an analytics data store)
A. Functional Systems
1. Systems of Engagement (SoE)
These are systems through which humans and devices engage with the organisation. There are two types:
a. System of Engagement Write Dominant (e.g., new accounts, orders, service requests, complaints, IoT data, etc.)
b. System of Engagement Read Dominant (e.g., profile information, roles, searches, offers, ads, automated text messaging, automated emailing, etc.)
2. Systems of Record (SoR)
These are systems where copies of the master data are stored to support high-capacity low-latency read use cases, management information reporting, regulatory reporting, etc.
3. Systems of Analytics (SoA)
These are systems where a subset of master data is stored, enriched with business meaning, and analysed for business intelligence and decision support purposes.
4. Systems of Integration (SoI)
Systems do not work alone within and across business domains. They rely upon integration systems if they cannot talk to each other directly for a use case. Examples are — API gateways, queues, brokers, BPM and workflow orchestration systems, etc.
B. Data (and Information) Stores
1. SoE Master Data Store
This is the native repository of systems of engagement. Write Use Case transactions populate its data. It keeps data for the minimum time to remain performative.
2. SoR Replica Data Store
These keep copies of the data for more extended time storage and support
- High-capacity, low-latency OLTP read use cases as an Operational Data Store (ODS)
- Management reporting, regulatory reporting, etc., as a Reporting Data Mart (RDM). It can support OLAP and OLTP use cases.
3. SoA Data Store
Stores slices of transformed data for analytics use cases taken from SoE Master Stores or SoR Copy Stores. It supports OLAP use cases.
4. Log Repository
Software, middleware and infrastructure log stores for operations management, including fault avoidance, management, capacity, performance, resilience, etc.
C. Ancillary Systems
The primary model above focused on the essential systems that directly provide business functions.
The following ancillary systems are necessary but less architecturally significant. They cater to IT infrastructure, operation and development, which are supportive enablers defined by the needs of functional business systems.
1. Systems of Infrastructure (SoInf)
These are racks, servers, switches, routers, gateways, storage systems, etc., along with the associated firmware, operating systems, hypervisors, virtual servers, middleware, etc.
2. Systems of Operation (SoOps)
These are tools for monitoring, backing up and restoring, stopping and starting, increasing and decreasing capacity, logging, operations reporting, patching, etc.
3. Systems of Security (SoSec)
These are firewalls, proxy servers, reverse proxies, DoS protection systems, security incident and event monitoring systems, VPN systems, deep packet inspection systems, secure gateways, etc.
4. Systems of Development (SoDev)
These are non-production systems for coding, testing, deployment, documentation, project management, etc.
Integration Methods
With the above functional and data systems, we can think about how humans and systems interact. These are abstracted to the following.
1. Direct
In direct integration, a system (or sub-system, component, application, or service) calls another directly on its API. It is best.
2. Gateway
When a system needs to call an API published on a gateway. Gateways are suitable where there are many systems and versions of APIs and access and security controls requirements.
3. Queued
When a system needs to put information for another on a queue because it has some constraint on being called directly, or a system needs to read the information published by another only on a queue.
4. Brokered
When object types need to be converted, protocols need to be changed, and synchronous transactions need to be made asynchronous, etc., use a broker.
5. Orchestrated
When there is a need for conditional routing, functional sequences, data merging, etc., use an orchestration system (e.g., workflow or business process management).
End Note
With the above in mind, think through your list of use cases to develop or correct —
- Is your use case (and interaction type) located in the proper functional system?
- Does it use the right data source?
- Does it use the proper integration method?
It will pretty much sort out your architecture.
Once again, go back to the story below and use the model constructs of this story.
1 thought on “A Practical Abstraction of Functional IT Systems”