According to Paul Krill of Infoworld Oracle is going to release a developer release of what it is calling its SOA suite – a term which is gaining ground to describe a fully featured ESB-based integration stack. According to Paul, Oracle is stressing the one-click install – presumably as a proof that they have managed to integrate the pieces of technology from various acquisitions notably Oblix and Collaxa. Although the focus on installation suggests to me that the underlying components may need a bit of work before they are truly integrated.

Telecoms has been at the forefront of SOA adoption – which is not surprising as it is an industry which has a deep understanding of architecture in general and integration architectures specifically (for instance they were probably the strongest adopters of CORBA – along with Wall Street). TMC covers remarks by Doug Tucker, Chief Technology Officer at Ubiquity Americas who believes that Telecoms are already increasing revenue by using SOA to offer enhanced services to subscribers. I would agree as I know that telecom operators worldwide have been building SOA based service delivery platforms for the last three years or so. These typically don’t get the same publicity as projects in other industries as can be seen from.

Dun and Bradstreet has announced a successful SOA program that already seems to be paying off in terms of reuse and in particular consolidation of legacy applications. Doug Smith, vice president for technology strategy at Dun & Bradstreet Corp. is quoted…

“As Smith saw it there were business processes that were used in perhaps 20 or 30 D&B information products. His thought was to commoditize those processes through a repeatable service that "time after time has some level of predictability in terms of service quality."

Posted by rbradley in Product news | Permalink | Comments (0) | TrackBacks (0)

There has been a lot of commentary on organizational changes required by SOA, but I have not seen much about how SOA will redefine existing roles and create new ones within the changed organization. Instead what seems to be assumed is that much of the responsibility for making SOA work is put at the door of the enterprise architect. As Daryl Plumber of Gartner puts it:

The first thing they have to do is make sure that they have proper architects.

Which sounds a little threatening – how many existing enterprise architects will pass this new ‘properness’ test?

Daryl’s comment comes from an excellent and wide-ranging interview around the organizational impact of SOA. He follows this line with some comments which probably reflect the consensus view on the subject but made me stop and think (http://mediaproducts.gartner.com/gc/webletter/progress_sonic121606/issue2/gartner1.html) There has been a lot of commentary on organizational changes required by SOA, but I have not seen as much about how SOA will redefine existing roles and create new ones within the changed organization. Instead what seems to be assumed is that much of the responsibility for making SOA work is put at the door of the enterprise architect. As Daryl Plumber of Gartner puts it:

The first thing they have to do is make sure that they have proper architects.

Which sounds a little threatening – how many existing enterprise architects will pass this new ‘properness’ test?

This comment comes from an excellent and wide-ranging interview with Daryl around the organizational impact of SOA. He follows this line with some comments which probably reflect the consensus view on the subject but made me stop and think . In essence, he sees architects having a role which is a tricky combination of coordinator and influencer:

If an enterprise makes the architect the center of that organization, then the roles of the other people around them, the developers, and the administrators and so forth, begin to change.

An architect is going to be looking at principles and guidelines, but a developer now has to recognize that not only are they building code for a system, they are building a set of components, modules, or services, as in service-oriented architecture.

What made we stop and think is two-fold:

Firstly, in Daryl’s world the architect becomes the interface point with business and even the center of the organization. While most enterprise architects are very capable of speaking with the business, SOA can and should change the goal-posts radically: In a successful SOA, there should be a high level of alignment between IT and business and therefore more and deeper communication. If enterprise architects are meant to be deeply involved in this interaction across the entire business, this is a potentially huge increase of the scope of the role.

The second part of the suggested role definition removes the architect from any sense of ownership of the services themselves (which is right as this would certainly be the wrong job and too big a job). However, this definition risks placing the architecture role in that classic no-win position of all the responsibility and none of the control and pushes a primarily technical role into what should be a strongly business focused environment of a business-aligned SOA.

The second issue that made me stop and think that struck me from Daryl’s interview relates to who owns the services: The key artefacts within a SOA are of course the service definitions (and their related data models). The benefits of reduced cost and increased flexibility rely on these being maintained, evolved and most importantly used as often as possible. So what is the role of the owner and what does he/she own? To my mind ‘owning’ in a business-aligned SOA environment should be in the sense of being responsible for making sure the services are used and used in the way to give most benefit to their business. This person can’t be our super-SOA architect who has all those other jobs!

The solution to me seems quite obvious – if a SOA is business aligned, the business must be more involved in SOA. this suggests that the owners of the service need to be directly aligned to the business owners of the associated business services. How this is done in practise will depend on the organization and its structures and goals. What will be true in every case is that the focus of this role should shift towards business skills and away from technical skills. The service owner can always go ask the architect for help and the architect can then focus again on ensuring that principles and guidelines are followed!

Posted by rbradley in SOA Organization Issues • SOA concepts | Permalink | Comments (0) | TrackBacks (1)

My last blog item “SOA is not just data” reignited an important debate – whether the data model or the functional definition is the most important dimension of SOA – and which is a subset of the other! Of course both are always present in SOA and the reason debating the issue is important is that it is easy to focus exclusively on one or the other without careful consideration of where the balance between the two should lie for your problem domain – a mistake which may cause you to create the wrong architecture and select the wrong products to implement that architecture.

Responding to my piece, David Linthicum represented one perspective on the data/function debate when he wrote:

Truth-be-told, services can be anything really. They can abstract data, they can produce or consume data, even restrict access to data. However, considering the notion of reuse, the most ROI from the creation of services is the ability to provide true behavior or more simply put: application functions with data bound to those functions.

And used Calculate_Risk(); as an example of a function which is purely behavioral. Taking that example, Ipedo’s Tim Matthews explained the other perspective: that application functions are types of data abstractions:

First, data services [Tim’s term for data based services] can support application services (get me customer data, get me risk profile, get me consolidated sales figures, etc.). Second, many Web Services [Tim’s term for application function based services] really are just data services, allowing easy access to information.

In the past, these differences in perspective have been reinforced by artificial technology and product differences that forced you into deciding to go exclusively down the ETL route or the EAI route. These boundaries have broken down due to the XML and Web Services standards which allow both data and function to be addressed within the same framework and which allow products to be developed which can mix-and-match capabilities traditionally associated with only ETL or EAI. As Tim puts it:

I also think you'll see more and more use of EII within ESBs, where ESBs will call a Data Service that is mediated by an EII product.

However, my view is not that the data and function are now the same thing and hence you don’t need to make choices about which to focus on. Rather, the balance between focus on the data exposed through the service and focus on the functionality exposed through the service depends on the type of organization and type of integration you require. If you business tends towards business processes which are primarily multi-step coordinations across applications which are self contained and transmit little data between them – then the predominantly functional approach suits. However, if your business shares and exchanges large amounts of data between the applications – then that emphasis on data must be incorporated within your SOA.

What started this discussion was my observation about data being at the heart of SOA. What appears to be happening is that while people may start from a predominantly function based perspective on SOA, as organizations get further into SOA it is becomes increasingly obvious that the emphasis must move into the middle and balance function with data.

Again, this is different to traditional EAI which primarily solved coordination problems and which left data to ETL products. To use some terminology David coined in his EAI book, I believe that all of this supports my long held view that the SOA future will require a seamless combination of what used to be called Information oriented and service oriented integration – under the umbrella term of Service Oriented Architecture.

Posted by rbradley in SOA Predictions • SOA concepts | Permalink | Comments (1) | TrackBacks (0)