Services and Components, Architecture and Design

I heard a couple of things recently. One, that design subsumes architecture: when designing a system, you design the components and the interconnections between them (the interconnections representing the architecture). Two, that services are merely components, thus implying that SOA is old wine in a new bottle.

A service is a component in the broad sense that it may be independently designed and packaged, and its computational usage is via a published interface. Thus, just as for components, it makes sense to talk about service composition, substitution, interoperability, and so on. However, the engineering of services is a world apart from that of components; engineering services requires fundamentally different abstractions. The differences arise from their pragmatic aspects. Components have no stakeholders; services do. Components have no autonomy; services (via their stakeholders) do. Components do not interact (rather they invoke each other); services interact. There is no question of a component being compliant with respect to other components; the question is fundamental for services given their autonomy. It makes no sense to sanction a component; the risk of sanctions helps keep services compliant.

Moreover, in today's world of services, more so than ever, it pays immensely to treat architecture as an independent artifact of engineering. A service is not a system in the traditional sense; it is simply a participant in an open system (such as the Web, or to be more specific, Amazon marketplace). A service's architecture is a description of the service's interactions with other services, all of which may serve the interests of independent stakeholders. At a high-level, architecture entails the commitments that a service could be party to, the contextual regulations that are binding upon it (such as HIPAA or Amazon marketplace policies), the monitoring of its compliance, and the sanctions that it may face in case of noncompliance. Where only one stakeholder is concerned with a system in its entirety, such a normative view of affairs is of little value. But when multiple stakeholders are concerned, as is the case in any services application, each stakeholder would want to make sure that the architecture accurately reflects a normative stance that is compatible with his requirements.