Business Ecology Initiative & Service-Oriented Solution

Yesterday, on the magic date of 09.09.09, IBM held the SOA Architect Summit in London. I do not know how many architects participated but, to my estimate, there were a few hundred attendees. The Summit ran two tracks, the hands-on test drive and the demonstrations. The overall tone was set by Rob High, Chief Architect for the SOA Foundation, IBM Fellow; he's outlined that the future of SOA is in the closer work between IT and Business, that this is the ever present need and that this delivers a much more powerful and valuable SOA environment to the business.

As you have, probably, noticed I argue for the same close collaboration between Business and IT, and even call for convergence. The basis for this I see in the concept of service orientation; the details of this approach you can find in the book 'Ladder to SOE'.

Rob articulated how to realise SOA from the beginning keeping business objectives and values as the highest priority criteria for every step including buying and using solutions from IBM, which was very nice of him. Also, he warned that "SOA must not become just another silo, each project starting from scratch". Rob talked about SOA in the Enterprise and how we could leverage the early adoption of SOA across the whole Enterprise

One of attendees told me by the end of the day that we were not discussing 'Product version X.Y.Z.' any more, we were discussing the business value of SOA solutions and infrastructure or methods of how to provide such value or how to demonstrate it to the business. I think, this is the sign of our time.

I could not participate in all sessions but for those I took place in, I would like to note two practical SOA presentations. In the first one, the BSkyB jointly wit IBM described experience and lessons learnt in the POC SOA implementation for BSkyB order fulfilment service. The most valuable information, IMO, was not how they realised their solution but what they did not / could not do due to various reasons.

In the second presentation, Garry Farrow, Technical Solution Architect from IBM, talked about SOA Anti-Patterns he found 'implemented' in his recent engagements. The first Anti-Pattern - Interface Bloat - was placed on generalizing the data structures passing to and from a specific architectural layer. The result of this was a 'bloating' of an interface whereby more data than is necessary is passed between layers. In the second Anti-Pattern - Architecture Redundancy - the responsibilities of the different architectural layers were ignored. The result of this was that some layers added no value and merely acted as a pass-through for data. Garry has described several re-factorings for his business cases two of which I think are very useful.

In the first re-factoring, he introduced Presentation Layer Services responsible for supporting intensive user interactions, on one hand, and coarse-grained business operations of the business layer services. You can read about such solution here. However, in the presentation, he separated the layers of the business processes and business services. In the discussion I had with him, he agreed that the separation was mostly for the illustration purposes; in reality all business process, i.e. service orchestrations, might be replaced by corresponding composite services.

Actually, I discussed this topic with several IBM experts in the Summit and all agreed with the statement: in SOA, any business process is the business service; the opposite is not true. This just confirms that SOA and BPM are not complementing peers but there is a strong superposition between SOA and BPM. It is a great advantage if one has a service-oriented mind when s/he is doing BPM (hereinafter, service and processes are not necessary automated procedures).

In the second re-factoring, he limited the use of canonical data within business process and service layers only. No canonical data should move between other architectural layers if we want to preserve SOA flexibility. This re-factoring is quite natural, especially if considering previously commented process inclusion into service - both of them have to 'speak' the same 'data' language (if a foreign service-process is engaged into the composition, the meta-data ontology and semantic mappings are a must have requirement).

Also, let me mention the presentation authorised by Martin Aggarwal, Lead Security Architect NE IOT from IBM. He illustrated SOA security standards (mostly WS*- standards) by how different customers apply them. The tricky thing was that not all 'practical' security approaches were really secured... Demonstrated solutions were good for relatively simple consumer-service-resource cases. In the followed discussion, we agreed on that if the service would be a composite service, which might engage other composite services, propagation of the end-user identity and security credentials through the service chain might loose its sense. Particularly, if services are really created as Services with no a priory assumptions about concrete end-users, the latter may be not know to the services, i.e. even if the end-user ID and credentials are delivered to such service, it would have no knowledge of what to do with them (note, in the case of different ownership and authority of the services, the user profiles might be not shared). You can read more details about this case here. Finally, we concluded that security federation of trust is, probably, the most adequate security solution for SOA. In this federation, all interested services must authenticate and authorise each other, i.e. they must have Service Identity that they can exchange during the interactions. These Service ID and credentials substitute end-user ID and credentials in the chain of inter-service interactions leaving the only end-user facing service responsible for the end-user security controls.

It might be interesting to notice that so popular wrapping of legacy applications (all applications become legacy applications the next moment after being deployed) has problems with the security federation of trust. The reason for this is in that those applications, especially, COTS applications, have their own security systems (e.g., Documentum, Business Objects and others) that may or may not be incorporated into the federation. This is why I have always argued that Web Service interface on an application does not make this application a service capable to meet Composability Principle without additional constraints. To make the security federation of trust to work in the described situation, we need a real service that proxies the application with its own security system; this service has to deal with multiple consumer ID and credentials via an authentication and authorisation security service, and the security of the application has to know and trust the proxy service only (not the end-users).

I would like to complete the Summit observation talking about the Mark Ketteman's discussion 'Culture Shock' [of SOA]. First of all, I have to mention that real SOA, not SOA-technology, can cause a shock to the developers who think that the code is The Everything and that there is nothing more important than the code. For others, who accept things in the business context, SOA is not and was never been a shock. Mark demonstrated numerous cases and concerns where people tried to put a 'new sock into old shoe'. He promoted the ides that organisations of IT delivery need to flex to cope with the changes involved, that people have to learn to share and to think about reuse.

Here is my take on this topic: corporate, and IT, culture does not exist on its own even if there are strong personal characters in the management. The culture, at the primitive level, is based on incentives and punishments, this is the human nature. Of cause, individuals may be more or less agnostic to incentives and punishments. SOA is not an exception, it does not make magic. If a manager asks why s/he has to collaborate and share the department's investments with others, there are no strong arguments in any architecture or technology, it is a social life question (this is why OASIS SOA Reference Architecture draft puts special attention on the social aspects of SOA).

In my opinion, the manager's question is the result of the business model called Value Chain, which is very popular for last couple decades. The model promotes the idea that a business activity or action is good if it provides business value to the organisation. Very many organisations use this model, i.e. create the culture that motivates managing people to increase their individual/departmental values; there is no incentives for a collaborative work or shared business context and common business goals in the model. Nonetheless, the corporate business objectives, strategies and goals exist, and management and personnel are awarded for contributing into the common goals but the contributions are still measured as individual values, not as values in the context of relationships with other operating entities in the organisation.

Ignorance to the relationships and resistance to the inter-dependencies (that threaten individual value) frequently lead to disproportional departmental growth in the organisations and slowing down the corporate business. This is why the Value Chain environment has so many problems with the culture required for the SOA success. At the same time, another business model called Value Networks highly appreciates business values in the context of the relationship with other values, shared results and collaborative people efforts. This model results in the SOA-friendly business atmosphere but this is the special and separate topic.