Organisational Constraints
Team structure, skills and budget cycles as architectural inputs.
4 to work through
-
beginner Multiple choice
You are designing a new order-management service for a mid-size retailer. Four facts about the organisation come up in the first week. Which one changes what you are allowed to design, as opposed to merely making the work slower or less pleasant?
3 min answer -
intermediate
Every change to a cross-team interface must be approved by an architecture forum that meets weekly with six 20-minute slots. About 14 requests arrive each week. Over the next two quarters, what happens to the queue and — more importantly — what happens to the designs themselves?
3 min answer -
advanced
An architect proposes a design requiring three teams to coordinate on every release. The organisation will not restructure. What are the options?
2 min answer -
advanced
Which organisational facts would make you reject a technically sound microservices design?
2 min answer
3 terms in this topic
Decision Latency
The elapsed time from a design question being raised to a decision being made, whose length changes not only when designs ship but how complicated th…
conceptOrganisational Constraints
The structural, procedural and human limits that determine which designs can actually be built and operated here.
conceptOrganisational Readiness
Whether an organisation has the skills, capacity, structure and appetite to operate a proposed architecture, independent of the design's technical merit.
Neighbouring topics
Business Architecture
General material on the business side of architecture.
Business Capabilities
What a business does, stated stably and independent of implementation.
Capability Mapping
Overlaying systems onto capabilities to expose duplication and gaps.
Business Processes
How work actually flows, including the handoffs nobody documented.
Value Streams
End-to-end delivery of an outcome, and where the waiting happens.
Domain Boundaries
Where the language of the business changes, and services should too.
Stakeholder Analysis
Who is affected, what they need, and who can block you late.
Product Thinking
Treating platforms and services as products with users and a lifecycle.
Business KPIs
The numbers a design is ultimately judged against.
Regulatory Constraints
Non-negotiable requirements that remove design options entirely.
Time to Market
The constraint that dominates most products, and how to trade against it.
Build vs Buy
Differentiation versus table stakes, priced over five years.
Business Cases
Expressing an architecture proposal in the currency that gets funded.
Operating Models
How delivery, platform and governance functions fit together.
Team Topologies
Stream-aligned, platform, enabling and complicated-subsystem teams.
Platform as a Product
Adoption earned rather than mandated, with an owner and a roadmap.
Outcome Measurement
Knowing whether the thing you built achieved what it promised.
Portfolio Prioritisation
Choosing between investments with incomparable benefits.
Business Continuity
What the business does while the system is unavailable.