What TOGAF Finds in Service Contract and What Doesn't
SOA Service contract is a new 'boy' in TOGAF 'town'. Probably, the lack of knowledge of other SOA standards is in fault for this 'boy' comes without its older 'brother' - Service Description. TOGAF 9.0 has skipped a notion of service announcement via Service Description entirely whereas it might represent what SOA service is (which is absent in the document). Though TOGAF recognises that 'For services to interact, they do not need to share anything but a formal agreement that describes each service and defines the terms of the information exchange between consumer and supplier', it stays unaware (and broadcasts this ignorance onto the Enterprise Architecture) about significant architectural motivation: to interact via services, the participants have to have needs, firstly, while an agreement can follow if needed.
As we know already, service consumers look for the business functionality and RWE that might satisfy the needs, and only then they contact the service provider to set the Service Contract. Service Description is the source of any Service Contract. As an exception, Service Description may play a role of Service Contract if the service does not assume any agreements with consumers (e.g. security service). That is, the contract may be informal, without explicit consumer conformity. The TOGAF definition of service contract - 'A contract is a set of metadata that describes how parties will interact both functionally and non-functionally' - seems to me suspiciously similar to interpretation of 'service contract' for Web Services where 'service contract' is set around the interface and some invocation policies only.
TOGAF formulates: 'Contracts are key architectural tools for communicating and enforcing policies, as well as other requirements in a heterogeneous and distributed IT environment... In SOA, policies are not hard coded into a specific application, but are coupled to services. ' I try to make my mind around this new architectural key. To begin with, we, probably, have to find how a set of private agreements - service contracts - existing outside of an architecture realm can become a key architectural tool for an Enterprise Architecture; such 'toolkit' seems to me a bit odd. In all cases, a contact cannot be a tool for enforcing policies 'as well as other requirements' by the nature of the contract (in common semantic of this word). Moreover, TOGAF 9.0 is, probably, unacquainted with the concept of service Execution Context that clearly separates policies from the services. The whole purpose of policies in SOA is to independently influence interactions with services, which is possible only if policies decoupled from or loosely-coupled with the services.
At the end, TOGAF 9.0 proposes 'two different senses of contract:
• A Governance Contract between two business entities which specifies what interaction is needed, inputs, outputs, SLAs, OLAs, and KPIs
• A Operational Contract which specifies the actual communication protocols and message formats'
Though TOGAF 9.0 proclaims the higher priority of the 'Governance Contract' for the Enterprise Architecture, mentioned separation is senseless to me. How can we talk about SLA in detachment from 'the actual communication protocols and message formats'? However, the most unusual thing is in the explanation of the 'Governance Contract... which specifies what interaction is needed, inputs, outputs, SLAs, OLAs, and KPIs'. '... what interaction is needed' is the subjected of particular Service Contract between service consumer and provider; this may not be governed in SOA. Also, it is difficult to imagine a governance between two independent business entities (as we know, even industry policies are called regulations, not governance). Provided example of a contract for the service 'technically automated as an XML web service' confusingly demonstrates the contract comprising an interface, message schema and bold policy that together fit neither into the 'Governance Contract' nor into the 'Operational Contract'.
Service Contract may have many different senses like marketing, or domain, or cross-domain to name a few. However, it does not seem right having, e.g., just an 'Operational Contract' without definition of what business functionality to be provided and under what constraints/policies. Once again, I do not see any serious reasons for distinguishing governance and operational senses of contracts from other senses unless the authors have meant the senses of the Service Contract parts, but this is my speculation only.
Leave a comment