Business Ecology Initiative & Service-Oriented Solution

For the whole last year we waited for new TOGAF version with high expectations regarding proper positioning SOA in the Enterprise Architecture. Being a TOGAF 8 Certified Practitioner and a 'SOA guy', I was, probably, among the most impatient ones. I mean positioning of Service Orientation (SO) rather than SOA, though. The TOGAF 9.0 release has finally brought a lot of very right words about business nature of SO but still lacked the right order of those words in a few crucial places.

While not mentioning that TOGAF 9.0 does not refer any other SOA standards (from OASIS or OMG), I am mostly dissatisfied with three areas of 'Using TOGAF to Define & Govern SOAs' chapter:

• representation of the essence of service
• Service contract
• SO role in ADM

Representation of the essence of service
Version 9.0 was released in a month after many leading SOA experts discussed and agreed in the most of cases that bottom-up technical approach to SOA had failed business expectations facilitated by unrealistic IT promises. Nevertheless, the bottom-up approach to SOA is encapsulated and treated as a first-class-citizen under the name of 'developer-led SOA' in the mentioned TOGAF document section. Also, the section distinguishes a business-led SOA from a developer-led SOA and addresses them as two self-contained equal in rights existing communities. I do not know who among SOA experts still disagree with the statement 'SOA is not a technology'; if we accept this as well, there is no real room should be left for the developer-led SOA in the Enterprise Architectural Framework. Encapsulating developer-led SOA into new version of TOGAF promotes recognised mistake, which is a pity.

A different confusion comes from the explanations of business function, business services and information service in SO environment given in TOGAF 9.0. I think that this roots in the misunderstanding or misinterpretation of the notion of business model. The business model is not a product of Enterprise Architecture, as the document declares; the business model gets formed at the very first moment of creating an organisation and consists of business services, business functions, business features and some business processes. Coming later Enterprise Architecture just records the business model and supports C-level executives in its maintenance. The Information System Service is not 'a thing that a business does' but the thing that Business uses as an instrument for its services, functions, features and processes. That is, TOGAF's Information System Services, if used by Business, should exist only in the context of business-led SOA and not by themselves.

TOGAF's SOA model conceptually separates Process Services from Application Services stating that Process Service represents a 'business flow and application composition' while Application Service encapsulates an 'application function', not even a business function. Both of these service types are in muggy relationship with represented Service-Oriented Application. The TOGAF's Technology Components, i.e. 'products purchased to create Service-Oriented Application', just add more fluid into this muggy relationship because it does not matter what do you buy, this does not create a Service-Oriented Application; service orientation is not what is running as an application, it is how do you use running application. SOA applications realise our own business functionality; this is why we cannot buy them.

To complete this observation, it is interesting to discuss following definition from the TOGAF 9.0 section on SOA: 'Function: Services support functions, are functions, and have functions, but functions are not necessarily services. Services have more specific constraints than functions '. I find this definition rather ambiguous because how can we understand 'Services support functions, ... and have functions' if we still do not know what 'Function' is. The declaration that 'functions are not necessarily services' depends on perception and definition of the business model, which is not given in TOGAF 9.0. A business model of an organisation defines business services first, i.e. what organisation offers to its customers and what brings profits to the organisation. Business functions and their features represent the next level of details and constitute the mechanisms of how business services would do their job. I have an impression that discussed definition mixes concepts of business and technical services. At least, this assumption allows me to explain that technical services support business function, or can implement the business function in full, or can have their own technical functions; but business function may include not only technical services. Then, technical services do have more 'specific constraints than' business functions, which is not true for business services comprised business functions.

To pre-phase following posts on SOA in TOGAF 9.0, let me mention here that

1) mapping of SOA specifics on old ADM does not really help proper SOA positioning in the Enterprise Architecture because SO concept and principles demand serious modifications in ADM
2) the document ignores existing standard on SOA - SOA RM - and coming SOA RA. As a result it misses very important concept of Services Description that the Service Contract (including SLA) is derived from. That is, if talking about architectural level, we have to deal with the Services Description while the Service Contract is a private matter between service provider and particular service consumer whilst public Service Contract - one for all - is rather an exception from the regular practice.