The gap has been clear for a while between the SOA aspiration of “aligning technology with business” and the reality that surveys and personal experiences reflect: SOA is proving remarkably difficult to justify to the business community. You can talk about reuse and agility but unfortunately they are terms that either cause the eyes to glaze over entirely, sound like attempt to justify investment in the intangible (again!) or require long and complex explanations. However, the issue is probably more about terminology than anything else and the key may be to stop talking service reuse and start talking about service sharing.

A few weeks back I was part of the ebizq podcast on reuse:

During this podcast, this issue was tangentially addressed when both I and Neil Ward-Dutton agreed that there was a problem with the word reuse itself: Reuse was being assumed by some to mean precisely the same as reuse means in OO. This is both inaccurate and brings with it a whole load of baggage around the perceived failure of OO to deliver business benefit. In the SOA context, most if not all reuse is actually about the sharing of services between multiple projects. Sharing is a much better description of what actually happens in SOA: Reuse suggests taking a copy and using it elsewhere, whereas sharing suggests multiple simultaneous use of a single resource. i.e. Precisely what Service Orientation is about.

However while the concept of shared services is well established as a ‘good thing’ from a business perspective, many organizations have found that it has proven hard to implement from an IT point of view in a cost effective and flexible way. And the degree of acceptance of the shared service model can be seen in the Economist Intelligence units report on the public sector and commented on by Joe McKendrick recently:

“at least 70 percent of public sector agencies are using or intend to use a "shared-services model" to enhance citizen service and increase efficiency”

Therefore explaining that SOA enables the implementation of the business concept of shared services at a much lower cost is both comprehendible and addresses a well-known problem. Moreover, SOA allows any organization to take shared services much further – identifying all sorts of internal resources which can be effectively shared as services and hence unlock further cost saving and business flexibility.

All of this may be obvious to many, but often the message is getting lost in the terminology. Perhaps it is time to create a new slogan for SOA: “SOA enables shared services”.

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

I don’t know who first said that you learn most from your own mistakes but they missed the follow-on: Learning from other’s mistakes is a lot less painful! In that context, the FBI is continuing to give us all learning opportunities as they attempt to modernize and integrate their complex systems.

I wrote about the FBI Virtual Case Manager debacle a while back: After they ditched their first attempt at solving this problem (at a cost of only $104m to the US taxpayer), they went SOA and created project Sentinel . However, since then they seem to have gone through a rapid and painful learning curve on SOA. Jerome "Jack" Israel, the FBI's chief technology officer puts it like this:

“We've gone from maybe hyped-up about it to the cold realization that 'Hey, this SOA is a lot harder than industry is making it out to be,”

In particular, the discontent seems directed at vendors who think that all it takes is some minor product modifications and a new marketing gloss on their old proprietary (often EAI ) products to magically make them SOA platforms. Dennis Nadler, a former chief engineer at the Defense Information Systems Agency, puts it rather bluntly:

"On the edge, sure, it may look like an enterprise service bus . . . but behind the scenes, it's all proprietary,"

Dragging old products into new markets is hardly a new phenomenon. However, SOA is particularly at risk because the focus on architecture has allowed some vendors to suggest that their own pre-SOA products can cut the mustard. They mostly don’t: Take note IBM, Microsoft et al – renaming products or simply declaring them ESBs or SOA platforms isn’t enough.

To finish with some good news, all of this doesn’t mean that the FBI is facing Virtual Case Manager debacle v2 – rather they have focused on the best returns on investment – which in their situation is integration with regional data exchanges (which sound similar to the UK CJIT approach).

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

Within a couple of days of each other two very different organization starting to talk about the success they have achieved from moving to SOA: Wachovia, the 4th largest bank in the US and the District of Columbia.

A couple of year back, Wachovia embarked on what was understood to be a major investment and organizational shift – an investment strongly backed by the CEO of the corporate and investment banking division. It is also possibly the largest deployed SOA project in investment banking (that I am aware of at least). The remit reported in InfoWorld was to “Rock the boat, change everything, and build a multihundred million dollar, end-to-end, services-oriented development and delivery platform”.

Clearly, this was a project that followed the dream formula – the most senior sponsor signing up to stay the course. Also clear is that Wachovia believes that it is bearing fruit delivering more quickly and at much lower cost the types of custom apps that investment banks build all the time to support trading in new and ever more complex types of financial product.

In contrast, D.C. followed what is probably a more common approach – they had a serious organizational challenge that simply could not be easily fixed with the old point-to-point approach to integration: The city needed to address the crime rate and to do this the city agencies needed to work more closely together and this meant that they needed to integrate better.

Unfortunately, this integration required the 370+ data sources to be connected together. The solution was to make this the start of a SOA and implement based on an ESB (from SeeBeyond – now part of Sun):

“A few years ago, more and more [organizations] started using ESBs for data-sharing purposes,” Adam Rubinson, deputy CTO of D.C. said. Federal customers in particular have used this approach to unlock older databases.

The benefits were again clear and matched what other government agencies moving to SOA have found: It saved money in unexpected places – in this case because they were able to identify vacant properties and collect the higher taxes due on those properties. An important lesson for anybody migrating for SOA - regularly review you RoI model to ensure that you are picking up these unexpected benefits along your path to SOA.

D.C.'s experience echoes what I have seen happening in other US criminal justice organizations at state level and in the UK where the national Criminal Justice IT organization (CJIT) has been spearheading similar initiatives over the last few years.

For more details, the story is here for Wachovia and here for D.C.

Posted by rbradley in Enterprise Service Bus • Financial Services • Government | Permalink | Comments (0) | TrackBacks (0)

The National Association of State CIOs (NASCIO) recently published a research brief entitled “Service Oriented Architecture: An enabler of the Agile Enterprise in State Government”. Although targeting government, much of what it says applies to any large organization and as such it provides a good succinct summary of the case for SOA. The fact that the US Department of Justice in particular has chosen to sponsor NASCIO’s enterprise architecture initiative, of which this is a part, is not surprising given the fit many people see between what enterprise architecture in general and SOA in particular can deliver and what justice networks need to do in terms of integration.

As I have said before the justification for SOA in government is clear: an environment consisting of numerous complex organizations and the increasing need to integrate rapidly across and within these organizations requires a high degree of integration agility such as promised by SOA. As the report puts it:

“In today’s world, government leaders expect to be able to move quickly, using all information appropriate to make effective choices that benefit constituents. Enablement of this expectation requires an organizational culture that embraces the sharing of assets and information.”

It is also nice to see some positive deployment stories showing quick return on investment – and of course as they report rightly points out these are not solely due to SOA, improving project management also plays a role.

“This particular project [in Chicago] saw immediate return on investment in multiple departments, for example, an increase of 20% in parking permit revenues and collection of outstanding parking violation collections.”

The collection of fines is a major problem for governments world-wide. As a SOA starting-point, it has a number of benefits: the return on investment is obvious and it is at its heart an integration problem: linking between applications to complete the business process.

As I said at the beginning, the report also covers much of the usual ground – SOA is an architecture and although building on previous approaches, it is new in significant ways. It is particularly clear when it explains SOA’s relationship with enterprise architecture more generally:

“The objectives and ultimate outcome of successful SOA is already embedded in the philosophy of enterprise architecture. The concepts of sharing, and reuse within both the business and technology areas of the organization have been around for sometime. Maybe what is really going on with the “advent” of “SOA” is that there is finally an understanding of the value of architecture, reuse, and services.”

And finally, before recommending that anybody interested in SOA and government go read the report, I will pull out one last quote:

“SOA focuses IT on being business driven. The underlying assumption in SOA is that not everything in technology can be the same, so standard methods and processes must be defined to enable disparate technologies to communicate, regardless of manufacturer or language.”

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

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)