Please enable JavaScript.
Coggle requires JavaScript to display documents.
Solution-Related Architectures (Enterprise (Strategic) (elements (org.…
Solution-Related Architectures
Enterprise (Strategic)
elements
org. structure
processes
products/services
mission
info/data about org.
context/environment
Strategy
need to evolve through changes
strategy to achieve needs over time
vision for future of org
Architecture Domains
Data/Information
Application
Business
Infrastructure or Technology
Frameworks
Zachman Framework for EA
TOGAF (The Open Group Architecture Framework)
FEAF (Federated Enterprise Architecture Framework) (US Gov)
DODAF (Department of Defense Architecture Framework) (US)
MODAF (Ministry of Defense Architecture Framework) (UK)
Governance
Principles (General rules, guidelines) (examples)
'change not to affect primary bus. processes' (all domains)
'apps have common look/feel' (app. design domain)
'routine tasks are automated' (bus. / app. domains)
'changes only made according to bus. needs' (app/tech. domains)
'business units are autonomous' (bus domain)
Policies (More actionable than principles) (e.g.)
how change activities run
supplier engagement
comply with legislation/standards/regulations
tech choice for standardisation
dev. standards (e.g., style guides)
non-compliance always an option for valid bus. reasons.
Solution (Tactical)
Elements
Drive/Control Design
Holistic
Scope
breadth
depth (description stops, design takes over)
focus
Architecture Contract (deliverables defined)
Could have hierarchical architecture domains
Bus. svcs (↓↓↓ Provide svcs. to ↓↓↓)
Customers
Bus. Processes (↓↓↓ Implement/Release ↓↓↓)
App. Svcs. (↓↓↓ Provide svcs. to ↓↓↓)
Infra. Svcs. (↓↓↓ Provide svcs. to↓↓↓)
Tech Infrastructure (↓↓↓ implement/Release) ↓↓↓
App. Components (↓↓↓ Implement/release)↓↓↓
Governance
Compliance
Enforcement
Software
elements
purpose of software
structure of software
choice of dev languages / tools
structural constraints of chosen tech
proper design patterns for robust design/implementation
Tiered
Two-tiered
Client-server
Thin client has UI but no logic
Thick Client contains app logic and UI
hierarchical
Client-server
Client dependent on server
server dependent on client
No flexibility
three-tiered
Client-server
logic de-coupled from
data sources
components in 3rd tier
shared with multiple clients
focus on svcs delivered by UI
N-Tiered
Component-Based
Assemblies of Components
what software already exist
May need adding/updating
can be re-used as-is
What software is missing
CoTS
Non-CoTS
Components
Testing
Interoperability
Specification
Stakeholders
External Legal/Standards Compliance regimes
Senior Bus. Mgmt.
Org. Owners/Board
Project, Prog. Portfolio Mgmt.
Ops. Mgmt.
Process Workers/App Users
Suppliers
Devs
Common Patterns
Loosely Coupled
Components can b updated or replace without significantly affecting others.
Dependency typically one-way
Almost always preferable to tight coupling
Components not dependent on any tech. aspect of the other.
Interfaces
Abstractly defines signatures of modules:
algorithms
methods
operations
strategies
functions
services
Coupling = "how dependent"
Cohesion = "how closely modules need to operate operate or be changed together"
Tiered/Layered
Modular (tight coupling)
Library Modules
Changing one module means others need updating
Dependencies exist both directions on any pair
Requires strong version mgmt controls
Hierarchical
Communication & Interop Patterns
Hub-and-Spoke
Service-Oriented Architecture
Point-to-Point (e.g., USB)