I will have to admit to having just figured out how to publish comments that people have been making on this blog, which gives me the perfect opportunity to respond to some of them...

In particular, both James Taylor and Bob McIlree commented on my piece on government and SOA suggest the problem was not technical and was around management and project management. Bob goes further to say that

Indeed this is mere wand-waving and managerial mumbling of "magic words" in the hope that something, _anything_ might prove useful.

Before going any further and appearing to be using broad generalizations to condemn a huge diversity of people and organizations, I should of course caveat all of this by pointing out that some government agencies have been successful in both vision and delivery for a long time, and more are catching up fast and showing vision and capability ahead of many commercial organizations. However, inevitably the disasters make for better news.

To get back to the comments, I would absolutely agree that the problem is not exclusively about the approach taken, nor about the specific type of product used. However, ‘fixing’ the management approach will tend to go hand in hand with moving towards a SOA approach.

Fixing the management approach to a degree is about recognizing the scale and nature of the problem. The old approach of outsourcing strategic initiatives in isolation may have worked when these were typically around rolling out a new application which existed in isolation from any other. However more and more of the political agenda is about efficiency and agility through better organizational integration (nothing to do with technology necessarily). This agenda can be driven by the need to control escalating costs in a government controlled health sector or the need to detect and respond to security incidents or natural disasters. Better organizational integration is constrained by many operational constraints related to the sheer number of agencies involved (the many hospital groups, community health workers, family doctors, etc in the health example, the multiple police and emergency services at town, county, state and federal level in the second example) and the diversity of their systems as well as legal constraints in particular around privacy and security.

This political agenda translates into, among other things, an IT agenda which now must also be primarily about integration of IT assets as that underpins the organizational integration. Which is where SOA comes in: SOA can be used as a government wide architectural approach to integration which can inform each integration project that is undertaken.

The attractiveness is obvious:

* SOA is about integrating independent entities which matches the government domain with its many independent or semi-independent agencies involved, each with agendas and legacies. It allows each agency to make their own technology decisions and incorporate their choices within the overarching architecture.

* Furthermore, SOA is also about distribution rather the centralization of functionality. This matches both technological limitations associated with building mega-hubs and more importantly the political constraints as most citizens are suspicious of government agencies attempting to centralize control and power too much.

All of which has meant that governments world-wide have become some of the most enthusiastic adopters of SOA and is already being used strategically by a number of agencies that I am aware of.

Posted by rbradley in Government • Market trends | Permalink | Comments (1) | TrackBacks (0)

Anybody who knows me and my views on SOA will know that I have a strongly held view that SOA will only deliver the goods if it is pervasive and will only become pervasive if it can include not only the latest coolest technology but also what to some is “boring” or “legacy”. I have previously commented on the need to include Excel. The case is even stronger with the mainframe, the death of which has been predicted for more years than I have worked in this industry.

As I was reading about IBM and SOA in IBM’s annual report which I previously commented on, I spotted another proof point that not only are mainframes not going away but the trend is in fact upwards: 2005 was the best year for IBM mainframe sales since 1998 and shipments of the zSeries mainframe were up by 28% over 2005. This of course means that anybody considering building a pervasive architecture such as SOA must incorporate mainframe based applications into their approach.

Luckily there are a number of companies with deep expertise in the mainframe space, providing solutions to extending SOA to the mainframe. I stress deep because any decent solution requires significant knowledge of mainframe technology which typically means that you need to look for a company which is primarily mainframe centric rather than a SOA company which sees mainframes as just another tickbox.

As I say there are a number of companies which provide these capabilities, but I would like to highlight one (GT Software) for no better reason that I am familiar with their products and like their approach which follows what I would regard as SOA best practices: easy to install with little training required and easy to use while being a mainframe native product set. Another well known vendor is Seagull Software and I am sure IBM has something in its recently announced 31 SOA products which does the job!

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

Sometimes when you are deep in a particular technology area it can be hard to figure out how your area is really regarded by those looking in from the outside. For instance, IBM clearly cares about SOA but how important is it really to that huge organization?

The question was answered for me when IBM’s annual report arrived in my mailbox yesterday. SOA is the highlight of the Software section and Software accounts directly for $15.8b of IBM’s $88.3b and must be indirectly responsible for a large chunk of the $47.4b in services revenue. Unlike any number of interviews by execs on technology websites or press releases, if a company puts something into the annual report and even more so highlight it as the most important trend, they mean business. And to quote Samuel J. Palmisano, CEO of IBM, in his opening letter:

“There is a significant shift underway in the world of software toward what is called Service Oriented Architecture (SOA).” And
“IBM is in a strong position to capitalize on the SOA market which some analysts expect to more than double, to $143b, by 2008”

Having read this, I decided to read again the announcement from IBM at the beginning of April. This is the one where they announced 31(!!!) SOA products –11 are new and the rest are enhancements to existing products. IBM also claimed to have trained 90,000 of the company’s business consultants for SOA implementations. All of which was framed by Steve Mills, head of IBM Software Group, as the fruits of IBM’s $1b per year bet on SOA. Again - impressive commitment.

Clearly SOA is key, if not the core, to IBM’s software strategy. We will of course have to wait and see if this “shock and awe” approach to dominating a market will work - not to mention solve the customer problems. I do wonder how 31 separate products (so far!) can really deliver the simplicity and agility that is meant to be at the heart of SOA. More importantly, SOA is about providing a solution, not selling an even more complex collection of products.

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

I was interested to see an article from ZDNet Australia about government IT projects highlighted by ebizq.net. Overall it is a positive story claiming a surprisingly high rate of success but also highlighting some notable failures including an AU$250m(approximately US$180m) customs project that went wrong. Australia is certainly not alone in government IT disasters. From the FBI’s $170m virtual case file project which spectacularly failed in 2005 to the £456m (approx $800m) IT disaster suffered by the UK government’s child support agency, this is a world-wide phenomenon.

However, we should not launch into a tirade about how our tax dollars, pounds and euros are being wasted. It is certainly true that in the past there has been a litany of disastrous projects failures (and quite probably this will continue to a degree into the future) but this is partly because governments world-wide are investing hugely in upgrading IT. In particular, they are spending on integration projects in order to enhance efficiency and provide better services to citizens and better security.

What I have found striking over the last two years or so is the number of government organizations in the US and Europe who have learnt from their mistakes and are now attempting to solve IT problems in an incremental and flexible way and one that is based on SOA and ESBs. There are specific areas that are particularly going in this direction: criminal justice both at a state and national level is investing heavily in SOA and ESBs and in the UK the National Health Service is spending colossal amounts of money on integration and use a leading SOA product from Sun (what was formerly SeeBeyond).

Government and SOA is a much bigger field than can be covered in a blog entry and one which I hope to cover in greater detail as an article. For the moment, let me finish with a quote reflecting the direction that the Australian government wants to take IT:

"It's about ensuring that our organisations can change to be able to deliver change,"

Sounds likes if they aren’t already using SOA, they will be soon

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

It has been clear since the end of last year that 2006 was going to be an exciting time for SOA adoption: a time when SOA would start proving itself or risk becoming last year’s cool idea. On the positive side, it is going to be a year when vendors’ offerings will start matching the promises of 2005 (as can be seen with recent announcements from Sonic Software, IONA and IBM among others). But it is also going to be a year when the stories of SOA missteps will echo louder than the SOA successes as some adopters learn the hard way and the press looks for a fresh story from SOA.

I have been thinking about what needs to happen for SOA to move through this dangerous period and here is a quick list – feel free to add your own as comments:

Develop SOA patterns
The value of patterns is well understood and in the integration/EAI space there has been some excellent publications such as Gregor Hohpe and Bobby Woolf’s Enterprise Integration Patterns. As SOA deals with integration, some SOA patterns should be simple updatings of the integration patterns. Of course others will not. I have seen various comments about the need for patterns and even a web-site with some initial suggestions but can’t find anything that feels any way complete. If any reader can point me at anything more concrete, please feel free to comment or email me.

Identify best-chance use cases
The next step up from patterns are use cases which allow practitioners to identify what type of project will yield the best results quickly. I know from my experience that there are types of projects which are good candidates for those high visibility first step into SOA initiatives and others which should be avoided (perhaps they are too small to matter or to entwined in political issues to be successful whatever the technology).

While the information is out there, the problem is always getting them into the public domain and inevitably vendor use cases highlight how great the product was over the pattern.

Focus on the standards that work and get to work
We live in a world always interested in the new new thing – and even more so in the technology industry. Bottom line is that the technology we have is good enough to get started with. SOA should be flexible enough to evolve as the standards evolve. Lets not wait for the WS-mumble to be standardized, released and adopted.

Figure out how to convince the business that SOA is a way to save money and increase efficiency, not burning budgets on this year’s new thing
As yet another survey shows that even IT chiefs are sceptical of SOA seeing it as hyped and a marketing term. The telling quote is from Melvin James of Diagonal (a Systems Integrator and SAP partner): “There is a worry at board level that SOA is about new technology and new spend rather than leveraging what organisations already have and improving process”.

As SOA champions we need to be clear on the real core benefits of SOA: a way to increase efficiency and reduce cost through leveraging existing investment. In fact these are precisely what board level management is looking for, but as Mr James also points out, too often it all gets lost in competing vendor pitches and technology standards.

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

Network Computing recently published a pair of articles - a review of eight of the ESB products available and the results from an online poll with 530 respondents (I will talk about the survey and some other views on the state of the market in another blog item soon). Each throws out interesting results and both point a high level of diversity in terms of product features and customer views of what an ESB should do. As I have said elsewhere at greater length, I do not regard this diversity as undermining the ESB concept. If you accept that an ESB is an approach to implementing SOA, and SOA is clearly being used in a huge variety of settings, it is not surprising that ESBs also reflect that diversity. Overtime this diversity will probably converge as we better understand the reoccurring patterns that occur in many SOA implementations.

The review is an impressive piece of work that must have taken a huge amount of effort on the part of their reviewers and they should be thanked for helping peel back the marketing hype to allow the potential users to look at the underlying products. However, I would caution any reader that any lab test tends to oversimplify and be tidier than the integration challenges faced in the real world. This can favor the well-polished over the deep.

One finding that might have surprised readers was an absence of BPEL support in 5 out of the 8 products reviewed (the exceptions being Cape Clear, Fiorano and Oracle). BPEL is certainly a standard over sold by some – it is about process orchestration within a specific model and has lots of limitations – it doesn’t do the peer choreographies like CDL or human workflow and it ignores data manipulation. However, not using BPEL isn’t necessarily the solution as the rest of the vendors are either pushing a non-standard solution (clearly a major weakness for an ESB which is meant to be standards based above everything else) or simply have a major gap in the product functionality.

Unfortunately, I would have one major quibble with the marking scheme: the focus on raw license cost over project cost. To be fair it is a failing that most product comparisons share. However, I do not think it can be stressed enough that in most cases the cost of the licenses are but a small portion of the overall cost and therefore the raw license cost is not indicative of which product will cost most to use in the target project.

A better estimate of project cost is the combination of license cost and a measure of productivity which neatly brings us onto another interesting point: Three of the products (IBM, Sonic Software and Cape Clear) required coding to complete the lab test. While this may be just a quirk of the lab test, this is still a much more worrying point as code extensions to an integration product are typically much more costly than configuration of what comes out-of-the-box and if these products can’t solve the lab problem without code what will they be like with the real (and more complex) projects.

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