I notice that IBM has announced the integration of the DataPower product line into the all encompassing WebSphere branding with the DataPower SOA Appliance now becoming (wait for it ) the WebSphere DataPower SOA Appliance. It reminded me of the announcement back at the beginning of April of 31 Websphere branded products as well as the claim that IBM would have 90,000 business consultants SOA ready which I described the shock and awe approach to software marketing .

Then I read Vinnie “The Deal Architect” Mirchandani noting a claim from an IBM Consultant that they are expected to be billable for 93.5% of their time which must be close to a world record!

And then an idea struck me that I am happy to donate to IBM if they would like to take it up: Why not extend the WebSphere brand to the 90,000 business consultants…

IBM announces the addition of 90,000 business consultants to the WebSphere brand

IBM today announced that the 90,000 business consultants who have completed the extensive WebSphere SOA training will automatically be renamed inline with the WebSphere brand.

“I am delighted to announce this latest innovation from IBM, following as it does from our unique 24x7 consultant availability plan” said company spokesman WebSphere Michael Bourne, “Any business consultant who has successfully completed the WebSphere SOA training course automatically becomes part of the WebSphere family and as such will be renamed in line with the brand. For instance, John Doe will become WebSphere John Doe. This shows IBM’s commitment to SOA and WebSphere. Microsoft may provide certification that changes your resume, only IBM provides certification that changes your passport.”

The announcement has been greeted with mixed feeling by many staffers. SOA business consultant, WebSphere Brian Murphy commented: “In a way, it was quite a relief, the rumor was that we were going to be open sourced.”

Don’t worry, I will be back to the serious stuff next time....

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

Rather than focus on a single issue this time, I thought I would comment on a few articles and blogs that have interested me over the last week.

First up is the latest round of one of the longest standing debates in the SOA world, which is better: REST or SOAP based web services. It seems to be bubbling up again as I mentioned in my comments on Tim Bray’s interview about SOA. Meanwhile Microsoft blogger Savas Parastatidis spotted another proponent of REST and waded into the debate, slamming the authors of a pro-REST, anti-WS article with

I can't believe someone can write so many inaccuracies in a single article. I blame the use of the term 'REST' which today is a buzzword rather than the name of a set of architectural principles which do not relate to a specific technology

Filling the buzzword induced vacuum, I will refer back to David Linthicum succinct description of what precisely REST is about.

Moving on... Congratulations to Cape Clear on their announcement that their ESB is now going to be used by Ireland’s mysteriously named Transmission System Operator. What most people won’t realize is that Ireland’s Transmission System Operator is actually called ESB Networks (as in Electricity Supply Board, not Enterprise Service Bus). I was disappointed that Cape Clear missed the opportunity in the press release headline to tell the world that their ESB was going to be used by Ireland’s ESB.

Moving on ... The term SOA 2.0 seems to be bouncing around this week and last. For instance in this article and Mark Little of JBoss stepped up to the mark and savaged the term SOA2.0 with

Then WHAM! Along comes SOA 2.0! How? Why? WTF?! I also expected more of Oracle on this one! Giving an architectural approach a version number is crazy: it makes no sense at all!

I have got agree with Mark’s sentiments. A term coined by Oracle and Gartner, SOA 2.0 seems to mean a Service Oriented Architecture combined with an Event Driven Architecture. At the end of the day the combination of Services and events happens in just about every SOA and I am not sure we really need another name, let alone a version number increment. I can only assume that SOA 3.0 is on the way, and must surely be the combination of SOA, EDA and Web2.0.

For anybody who wants to read more about the connection between the two, Brenda Michelson, the latest ebizq blogging recruit, has written extensively on the subject in her Patricia Seybold Group blog.

Posted by rbradley in | Permalink | Comments (1) | TrackBacks (0)

I was genuinely surprised by the interview with Sun’s Tim Bray in SearchWebServices. I am always careful about reading too much into such a piece as editing and the shortness of the format often hides the real intention of the speaker. However, in this case Tim makes some pretty sweeping comments that gave me the impression that Sun’s Web Services and SOA strategy is at best deeply confusing if not actually deeply confused.

First off, Tim Bray doesn’t like the term SOA because he “can't explain what the difference is between SOA and Web services and I'm not sure I've met anybody who actually can without going into paragraphs and paragraphs prose”. In response, I will quote wikipedia.org’s definition of SOA :

In computing, the term Service-Oriented Architecture (SOA) expresses a perspective of software architecture that defines the use of services to support the requirements of software users. In an SOA environment, nodes on a network[1] make resources available to other participants in the network as independent services that the participants access in a standardized way. Most definitions of SOA identify the use of Web services (e.g., using SOAP or REST) in its implementation. However, one can implement SOA using any service-based technology.

80 odd words nail what SOA means and how they are distinct from Web Services (pick many other sources with similarly short descriptions) – although it is interesting to note that it includes REST within the definition of Web Services which is less common. The difference is SOA is a general architecture, Web Services a specific technology: you can implement SOA without Web Services – using Plain Old XML or REST or something else to create a Service Oriented Architecture.

“Web-style” is Tim’s preferred term to SOA because “it really means something”. Unfortunately in this article, he doesn’t say what it means beyond a comment that it focuses on “exchange patterns” which sounds a little like an Event Driven approach – which is certainly a well established and effective style of integration architecture.

However, Tim is also unsure about Web Services saying on the one-hand “The importance of Web services is being underestimated” and on the other “A lot of us are not sure that WS-* is the future”. His objection is that the set of standards are becoming “unreasonably big, unreasonably complex and few of the core low-level elements of the stack seem ugly and awkward and difficult”.

I certainly agree that too much complexity is building in the WS-* stack – it is getting more and more baffling to the beginner but many of these standards will be invisible to the programmer – buried in the stack implementations. However, it is important that the standards bodies now vigorously weed out the standards which are not ‘working’ and focus on those that are being used.

Furthermore Tim states (correctly to my mind) that POX and REST are both simple and good alternatives and “We observe that people are putting out lightweight distributed applications using good old XML and HTTP and getting them done in days and they work great”. That is of course true for some applications where HTTP is sufficient. However, there will be others where guaranteed message delivery is required and others where SOAP based communication meets the need.

The point is that all of this can fit within SOA (hence the importance of the distinction between SOA and Web Services) and as with any IT project it is important to bring the right firepower to bear to solve each problem: If HTTP is sufficient that is the right choice, but that does not mean that it is sufficient for every project. Equally, don’t deploy a complex middleware stack to solve a web-style communication problem.

Posted by rbradley in Market trends • SOA concepts | Permalink | Comments (0) | TrackBacks (0)

Dennis Howlett has added some comments to my recent blog on Web2.0 and SOA. Dennis makes three points, one of which I agree with, one I don’t and a final one which highlights an interesting issue. To paraphrase Dennis’ points:

1. SOA is already a dead concept: “The real problem lies in the term itself, its vagueness and its associations with blue sky projects that demonstrate little more than debatable business value.”

2. SOA is poorly named and would be better called Service Based Architecture.

3. SOA projects need to be applied to specific edge projects – as Web 2.0 projects have been.

I won’t argue point 2 – the Service Oriented term echoes (of course) Object Oriented and indeed service based would be a closer match to what it is about. However, the fight is long over on this one, and we will have to live with Service Oriented.

I will argue with point 1 – Dennis’ points of evidence are application vendors such as SAP saying it is dead and EAI vendors claiming that it is nothing new. SOA is potentially deeply threatening to application vendors such as SAP who sell tightly integrated suites of applications as SOA in its essence encourages mix-and-match. On the other hand, EAI vendors have embraced SOA and following the usual software marketing approach claim that they were doing it for years before the term was coined – we simply didn’t notice.

Moving onto point 3, Dennis is absolutely right that SOA projects need to be prove value and there is a tendency to redefine the term to stand for Seriously Overly Ambitious – turning them into big bang projects which are hard to fund and hard to demonstrate RoI on in many cases. This is not necessary – SOA implementation can and should be done incrementally. Furthermore Dennis hits the nail on the head when he says that one of the distinguishing features of Web2.0 has been the strong focus on productivity: it is easier to work with and therefore encourages innovation. Why doesn’t SOA seem to follow the same path? In our keenness to stress the architecture, as proponents of SOA we risk missing the point that the tools and approaches used can and indeed must be productive if we to prove the benefit of SOA quickly enough to maintain momentum within the organization.

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

I read with interest David Linthicum's postings of a couple of weeks ago on semantic transformation, here and here. In particular, he gives a good description of the scope of the term transformation in SOA by saying:-

Accounting for the differences in application semantics is the process of changing the structure of a message, and thus remapping the structure and data types so that it is acceptable to the target system.

And later

Related to the concept of accounting for the differences in application semantics, accounting for content changes is another important aspect of transformation. In short, it’s the reformatting of information so that it appears native when sent to a target system.

While I agree with his claim that this is not in essence a new problem – similar problems occurred with data warehouses and data marts, I would caution extrapolating to the point where it is thought of as a straight forward and solved issue. The reasons for my caution are two-fold:

 Transformation is poorly supported in most products claiming to be SOA integration suites or ESBs. They mostly provide tools such as XSLT editors which can be hard to use with many more complex formats and are, in general, not very user friendly – treating transformation as a functionality tick-box, not a core feature. Before this is greeted with a wave of comments from readers who are entirely comfortable with using these tools and the vendors of products with this limited support, I will set a benchmark: these should be usable by the averagely skilled developer and not require the team XML or data format guru. This is because in my experience creating transformation mappings is one of the most common tasks in any SOA integration project which brings me nicely onto the next point:

 Some SOA proponents don’t believe that transformation is much needed because they believe strongly that correct definition of service should remove the need for any smarts in the middle. This is a debate I won’t reignite beyond referencing my blog-item here - it is answered in the section “The ESB is aspirin for the headache of badly defined services” – while it focuses on the ESB, the argument is in essence about whether you need to transformation in the middle or whether by correctly defining the service the need is removed. However, I will state again that this is a view that I fundamentally disagree with unless your organization is blessed by simple data formats and your projects focus primarily on writing new applications integrated into old rather than linking together old applications.

Which brings me to my last point, one size doesn’t fit all for transformation as with most attributes of a SOA implementation: the importance of transformation can only be assessed by each organization as it adopts SOA. You need to assess how complex your data is and how many formats are flowing around. The more complex the data and the larger the dictionary of formats the important transformation will be and more likely that you will need to consider how to capture and use the semantics.

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

Jason Bloomberg of ZapThink writes about what he thinks the killerApp for SOA will be and to paraphrase him: it will be the mother of all modeling tools, spanning service definition, BPM, extending into deployment with monitoring, policy, management and so on. It will also be the mother of all dashboards – pulling together all the information currently scattered through multiple dashboards and monitoring tools. The twist is that for Jason, the killerApp will be an enterprise mash-up :

We spoke of the SOA Killer App as containing modeling and development capabilities, a wide range of dashboards, and the capabilities of every service consumer under the sun. But that doesn't mean that you'd expect to buy such a thing as a shrink-wrapped package from a single vendor. Instead, the SOA Killer App enables the creation and evolution of itself as a composition of services -- an enterprise mashup tool that is itself an enterprise mashup.

It highlights again what is becoming apparent to more and more people: the technology of Web2.0 is as applicable and attractive within the organization as across the internet. (For anybody wanting a good starting point on Web2.0 read Tim O'Reilly's article)

I agree with Jason’s view that the mashup approach to creating rich user interaction is the way forward in the enterprise – although there are clearly lots of issues around identity and security to figure out as the openness of the consumer web is not appropriate inside the organization. However, I do not think that on its own it will be a killerApp for the following reason:

Clearly, SOA and Web2.0 both add load onto both the applications being interacted with and the level of network traffic and the complexity of flows through the network. In the case of SOA, the load probably won’t cause major problems as the number of applications connecting will remain relatively small.

However, enterprise mashups could be used by every person in an organization. As their popularity grows the number of data flows will increase exponentially. Furthermore, dashboards are likely to be popular components of these mashups and these will be polling (using RSS for instance) with customized queries to get at the data – putting potentially high load onto the queried applications and flooding the network with traffic.

This of course means that for enterprise mashups to scale, the load put onto the network and the queried applications needs to be controlled and to do this a whole infrastructure of enterprise centric aggregators and harvesters need to be put in place as well as traditional management and monitoring capabilities. This doesn’t mean that mashups aren’t a great idea – simply to my mind it is in this area of flow control and management the opportunity to stir things up and create a killerApp lies.

Posted by rbradley in Web2.0 | Permalink | Comments (1) | TrackBacks (2)

Only a couple of weeks after I commented on IBM's increasing mainframe revenue and the importance of the mainframe in SOA, I see that IBM itself is ramping up its own support for the mainframe in the SOA area and has announced that its WebSphere ESB and Process Server will be available on the mainframe.

According to Jim Rhyne, an IBM engineer quoted in the article,

Now mainframes are finding new life as the hubs for service-oriented architectures (SOAs), most notably in the growing field of e-commerce.

A little confusing to refer to a hub for SOA but I assume he means that more of the mainframe based applications are being integrated via SOA and obviously many such applications can be hosted on a single mainframe.

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

I am struck by the difference between discussions around SOA and Web2.0 – don’t panic I am not going to get involved in the REST versus SOAP debate or the debate about which is more hyped or a vaguer term!

What has struck me is the way the big software players are talking up the concept of a SOA platform in a very traditional way: as a stack of vertically integrated software all of which is required to solve the SOA problem, and recently covered on ebizq.net here and here . Bizarrely RedBoss, the new boy in town which should surely be rooted in the new world rather than the old, is taking it even further back in time by suggesting an Operating System is also needed in the stack!

At the same time as all of this, the analyses of what have already happened on the Web and what is accelerating with Web2.0 shows that the very concept of a platform is changing. This is best summarized by Tim O’Reilly’s much referenced article on “What is Web2.0”. The point of relevance here is that the Web 2.0 battle is not between a platform and an application or even between competing but broadly similar platforms – it is between radically different platforms with radically different business models.

So why is this not happening in the enterprise? The old claim that integrating the stack removes the need to integrate multiple vendors’ products and hence reduces cost and risk must be much less true than it was. Open Source in particular has demonstrated that it is possible and relatively easy to stick together multiple products/projects.

Obviously there are many different business dynamics at play in the enterprise than across the consumer focused web. One dynamic is the need in the enterprise to limit the number of vendors (‘one throat to choke’) and incumbency is also important both from a skills and relationship point of view. However, this can’t justify the view that a single integrated stack is the right way to go, unless the stack is at least a good-enough solution. Furthermore, integration in particular is clearly not about tightly coupling homogeneous single-vendor supplied software: Its essence is spanning across platforms, applications and organizations.

The question is therefore will the changes coming from consumer-centric Web-world change the way the enterprise-centric SOA-world to the same extent?

We are already seeing the use of technologies related to Web2.0 (RSS, AJAX etc) growing in the enterprise. However, these are towards the edges of what SOA is attempting to do as they are about user interaction rather than system to system integration: This is important but not yet core.

What I do not believe we have yet seen is the appearance of a google equivalent (which could be an open source project) for SOA – a company which solves the problems in a radically different and much better way and hence dislodges the good enough solutions. Until that happens the big vendors will continue to push enterprise software the same way they have pushed it for 10 years and more.

Posted by rbradley in SOA Predictions • Web2.0 | Permalink | Comments (0) | TrackBacks (0)