S90.03: SOA Design and Architecture Across Services and Modern APIs

S90.03 is the older Arcitura exam label for SOA Design & Architecture in the first-generation SOA Certified Professional program. It brought service-orientation principles into concrete design work: identifying service boundaries, defining contracts, applying design patterns, building compositions, balancing autonomy and reuse, and shaping service inventories. Arcitura’s current Service Technology School now teaches updated services-and-microservices architecture and uses newer complete certification exams and B-coded module options, so S90.03 should be understood as historical credential lineage with still-relevant design content.

The exam belongs to the SOA certifications family and is conceptually between fundamentals and advanced architecture. It asks a more practical question than “what is a service?”: how should a portfolio of services be designed so teams can change systems without recreating tightly coupled silos behind network interfaces?

Modern microservices and APIs make these questions more important, not less. Small deployable components can still be badly bounded, overly chatty, insecure, or impossible to evolve independently. Service-oriented design provides a language for evaluating those problems even when the implementation technology is different from the original SOA era.

Service boundaries should align with stable responsibility and ownership

A boundary is strongest when it encloses a coherent capability and the data or rules required to fulfill it. Splitting services around database tables often produces chatty interactions because business operations span several tables. Splitting around organizational teams can be equally fragile if team structure changes faster than the domain.

Domain analysis helps identify boundaries around business behavior rather than technical artifacts. The service should own enough of its responsibility to change without coordinating every release with neighboring services. That does not mean duplicating everything; it means making dependencies explicit and deciding which data or capability is authoritative.

The broader lesson in architecture driven by constraints applies here. Service boundaries should emerge from business change, data ownership, consistency needs, security, latency, and team responsibility instead of from a desire to create a particular number of services.

Contracts should minimize accidental coupling while remaining meaningful

A service contract is the consumer-facing expression of the boundary. It should expose business capabilities with clear inputs, outputs, errors, and policies while hiding implementation details that consumers do not need. If an internal database column rename requires every consumer to change, the contract is leaking provider structure.

Contract-first design can improve review because teams discuss interface semantics before implementation makes them expensive to change. The same discipline now appears in OpenAPI, AsyncAPI, protobuf schemas, and event contracts. The notation differs, but the goal is to create an interface that consumers can understand and providers can evolve deliberately.

REST API contracts illustrate this evolution. Resource names, HTTP methods, status codes, pagination, and error bodies become part of the public behavior and should be treated with the same care that earlier SOA designs applied to formal service contracts.

Reuse should be earned through stable semantics rather than forced centralization

Service reuse was a major SOA objective because shared capabilities can reduce duplicated logic. Yet reuse creates a wider blast radius: more consumers depend on the contract, so careless changes become expensive. A service should be reusable because the underlying business concept is genuinely shared, not because architecture policy requires every piece of logic to become a universal service.

Over-generalized services can accumulate optional parameters, branching logic, and competing consumer needs until no team can change them safely. A smaller number of domain-appropriate capabilities may provide healthier reuse than one “enterprise” endpoint that tries to satisfy every workflow.

Candidates should therefore balance normalized service inventories with local autonomy. The design question is not “can this be reused?” but “does reuse improve consistency enough to justify shared lifecycle and governance?”

Composition design should make coordination and failure visible

A composition combines services to deliver a larger outcome. Central orchestration can make sequence and state explicit, while choreography lets participants react to events without one coordinator owning every step. The trade-off affects observability, autonomy, coupling, and the ability to understand business progress during failure.

Asynchronous composition can reduce temporal coupling, but the system must handle delayed, duplicate, or reordered messages. Event-driven systems work well when producers and consumers can be independently owned, provided the event contract, replay behavior, and idempotency strategy are clear.

Long-running workflows also need compensation. If several services commit independent changes, a later failure may require new business actions to restore an acceptable outcome. The architecture should model that process explicitly instead of assuming distributed work can be rolled back like one local transaction.

Service inventories need consistency without becoming architecture bureaucracy

An inventory defines how services coexist within a broader environment. Naming, data definitions, contract standards, security conventions, and lifecycle states can make independent services easier to combine. Without some consistency, every new integration becomes a translation project.

Governance should focus on shared risk. A service used by one team may need lightweight review, while an identity, payment, or customer capability with dozens of consumers deserves stronger compatibility and security controls. Applying the same process to every interface can slow delivery without improving the highest-risk areas.

Discoverability is useful only when metadata is trustworthy. Owners, support contacts, versions, dependencies, and deprecation status should reflect reality. An inventory that cannot distinguish active services from abandoned endpoints encourages new consumers to adopt unsupported dependencies.

Patterns provide tested trade-offs, not automatic answers

SOA design patterns capture recurring problems such as contract centralization, service façade, protocol bridging, asynchronous queues, canonical schemas, and composition. A pattern is valuable because it makes the forces and consequences discussable. Applying it without the original forces can create unnecessary layers.

Patterns often interact. A façade may protect consumers from a complex provider, while asynchronous messaging reduces temporal coupling, and a canonical model reduces translation between several domains. Combining them can solve a real integration problem or can create a stack of indirection that no one understands. Candidates should be able to justify each layer.

Modern architecture has its own related patterns around API gateways, sidecars, event streams, containers, and serverless functions. The specific implementation changes, but experienced designers still ask what coupling is reduced, what new dependency is introduced, and how failure will be observed.

Security and policy should be built into service design rather than attached afterward

Service boundaries are also trust boundaries. A public API, internal service, partner integration, and privileged administrative interface may require different authentication, authorization, rate limits, audit, and data handling. Reusing one security policy everywhere can be as dangerous as having no standard at all.

Authorization should be evaluated in the context of the requested business action. A gateway can confirm identity, but the service often knows whether that identity may act on a particular account, record, or workflow. Central and local controls need clear responsibility so neither assumes the other is enforcing the rule.

Composition adds delegation challenges. A downstream service needs to know whether an upstream component is acting as itself or on behalf of a user. Identity propagation and service credentials must be designed so a trusted intermediary does not become an unrestricted privilege escalation path.

S90.03 concepts remain relevant as the certification program moves forward

Older S90.03 study should emphasize durable design principles: capability boundaries, contracts, coupling, reuse, composition, governance, patterns, and policy. Historical standards may provide useful examples, but current practitioners should map them to the APIs, events, microservices, cloud platforms, and automation used in their environment.

The foundational S90.01 and technology-focused S90.02 explain the ideas and mechanisms that S90.03 turns into designs. The Gen 1 architect sequence continued into S90.08 and the S90.09 lab, while Arcitura’s current architecture track now incorporates services and microservices in an updated structure.

The lasting test of service-oriented design is whether change remains local. If adding a field, replacing a database, scaling a workload, or changing a deployment requires coordinated edits across many consumers, the architecture is more coupled than its service count suggests. S90.03 remains useful because it trains practitioners to see those dependencies before they become expensive.

Data ownership is often the boundary decision that exposes whether a service design is truly independent. If several services directly update the same tables, their deployment independence is mostly an illusion because schema and transaction changes still require coordination. Giving a domain authority over its data can reduce that coupling, but it may require events, replication, or read models so other domains can access the information they need.

Operational design should be reviewed alongside logical design. A service that looks cohesive on a diagram may be difficult to run if it has no health model, no capacity expectation, and no clear owner for incidents. Error budgets, latency objectives, deployment rollback, dependency monitoring, and runbooks help convert architectural independence into operational independence.

A useful architecture exercise is to simulate a breaking change. Change a contract field, dependency behavior, or data owner and trace which consumers fail. Then redesign the contract or interaction so the change becomes additive or isolated. This makes coupling measurable and helps practitioners recognize when a service boundary is protecting consumers versus merely moving code behind a network call.