Faced by the uphill struggle of justifying SOA to business managers who find the benefits of SOA hard to understand let alone quantify, it is tempting to link it to other areas of technology innovation which are (we hope) easier to justify. I have previously blogged about the attractiveness of the enterprise mash-up and impact on the infrastructure associated any wide-scale adoption of such mash-ups.

The announcement from Abode about the latest version of its RIA platform reminded me that the issues are not only associated with the ‘back-end’. In particular, the RIA space is developing fast but is still immature. The world has certainly moved well beyond the appearance of Google maps and AJAX. (Of course, AJAX was always a confusing term in that it gave the impression to outsiders that there was a well-defined piece of software rather than a general approach to creating RIA.) However, the RIA space remains an incredibly busy space as can be seen from the list of 25 different RIA frameworks listed here . This diversity reflects a great level of innovation which is good in the long term. And it is fair to point out that RIA is a wide definition – some of the 25 are focused on specific types of applications such as the Ruby on Rails for developing database backed web applications while others such as Tibco’s General Interface are clearly intended for use with enterprise middleware at the back.

This poses the challenge for the enterprise architect of which horse or horses to back. The easy answer that I have heard is that it doesn’t matter: RIA is supposedly easy to replace and are often used to create opportunistic applications (quick to create with short life-spans). If you change your mind (the story goes), simply rip and replace with another RIA. Equally, (the story continues) it doesn’t matter if one department goes for one RIA and another a second.

I remain unconvinced. Yes it is true that it is easier to replace an RIA than to replace infrastructure software such as message queues. To stretch an analogy, if switching message queuing is like a lung transplant, then switching RIA might be grafting back a finger – while I definitely wouldn’t like the first, I wouldn’t volunteer for the second either. What is being ignored is the cost of replacing or maintaining in parallel RIAs based on old tool-kits and new. What is also being ignored is that the users of these applications are the sensitive business users who will not appreciate the disruption of their favorite tool which follows on from switches in strategy.

All of which means that we need to look at the RIA options with a great deal of care: The opportunities and benefits are certainly considerable. However as with other bets on early markets, there are significant downsides as we inevitably make the wrong choices from time to time.

Ronan

Posted by rbradley in Mash ups • Product news • SOA Predictions • SOA concepts • Web2.0 | Permalink | Comments (0) | TrackBacks (0)

For all the claims of some OSS enthusiasts, OSS came to the SOA game a couple of years later than the closed source vendors. Coming in later has its benefits of course: the needs are clearer and the late comers benefit from the experiences of the early innovators. This 'second mover advantage' is particularly strong with SOA as the market has developed quite slowly. This slow growth stopped the early innovators on the closed source side from getting any sort of market dominance.

Most of the OSS SOA solutions have up until recently focused on the base infrastructure required for first generation SOA projects (I say most as Bosteq for one took a different tack by focusing on the major 'higher level' problem: developer productivity). What has been lacking or weak with the OSS offerings has been the enterprise level capabilities such as management and application connectivity which are essential for any widescale deployment of enterprise infrastructure software.

Alex Fletcher's blog on RedHat's ambitions for its SOA strategy highlights two recent partnership announcements which shows RedHat is the latest OSS SOA vendor to start to address these gaps: Partnering with iWay on enterprise application connectors and with Hyperic for management.

iWay has become the standard port of call for most if not all SOA vendors needing an enterprise application connector story - I say story because while end-users like to know that such connectors are available, they do not necessarily end-up buying them. For RedHat, it presents some interesting issues: iWay is not an OSS vendor - and hence the customer is forced into a hybrid model of OSS and closed source. While this may not be a problem (IONA follows a similar model within its own family of closed and open source products), it seems to be a major disparture for a company such as RedHat so closely aligned with OSS.

The Hyperic relationship is also a little me-too as it follows the path already followed by MuleSource. In this case there are no 'religious differences' as Hyperic is also OSS. And me-too has some obvious advantages for the users: It is better if vendors converge onto one solution as any widescale SOA deployment is bound to include multiple SOA platforms which need to be managed as a whole.

Which makes both announcements positive steps for RedHat. However, they still have a long way to go before they are ready to win the 50% of the market which Alex points out is their strategic goal. And in my opinion they must greatly accelerate their moves to make their platform enterprise grade if they are to have any chance to achieve that goal by 2012 as is their stated aim.

Ronan

Posted by rbradley in Market Trends • Product news • SOA Predictions | Permalink | Comments (0) | TrackBacks (0)

It is almost 9 months since I have blogged on ebizq. In 2008 I intend to make this my main blogging platform although I will continue to blog from time to time on the Lustratus blog as well. While I intend to change the focus of the blog from exclusively SOA related issues, I am restarting almost from where I left off 9 months ago. In particular, the hot topic was then and remains how to build a SOA business case. Joe’s SOA in Action blog returned to the topic quoting from David Linthicum

“SOA proponents need to redouble efforts to emphasize the business case, and de-emphasize the technology aspect, he said. "It all boils down to architecture." Still, he said, the reuse inherent in SOA can be made to work, and projects where CEOs can see demonstrable value -- such as a real-time analytics dashboard -- can achieve quick success.”

Meanwhile David’s ZapThink colleague, Jason Bloomberg told SearchSOA that

"Furthermore, enterprise mashups are becoming the killer use-case for SOA, that is, the ostensible reason for doing SOA from the perspective of the business. So, SOA is stronger than ever, it's just becoming part of the woodwork. Enterprise mashups are the part that shows."

I think that for better or worse these quotes reflect the reality. SOA is not an easy proposition to sell to business on its own – it is about what you use SOA to do. SOA is certainly a better way of doing internal application integration but these traditional application integration projects are not particularly interesting to the business sponsors. Lack of interest means that cost is everything and SOA can be a very hard sell as early projects have to bear the brunt of the SOA set-up costs (called the SOA tax by some). Therefore, SOA is more likely to flourish in areas where the additional initial overhead can be justified by greater returns and more importantly returns that are of greater interest to the business.

The concept of an enterprise mash-up has been attracting interest outside of the IT department. The concept is inherently attractive to business users as it suggests that there is a way to easily combine the information the business user cares about without apparent interference of IT departments with their long and expensive project cycles. Potential applications from CRM to executive dashboards quickly jump to mind.

Unfortunately, there remains no such thing as a free lunch. Enterprise mash-ups rely on the availability of reliable mechanisms to access the data and suitable access controls to ensure that only authorised users get to what could be very sensitive information. While it is possible to roll out pilot mash-ups, over time proliferation of mash-ups will have a much greater impact than the casual observer might expect: Each mash-up user touches potentially many systems and mash-ups often rely on directly polling the system at regular intervals. This means that large scale roll-out of mash-ups will put large and potentially unexpected pressure onto the applications and infrastructure if not carefully controlled.

Which brings us back to SOA: Large scale deployment of mash-ups will require enterprise grade integration infrastructure as provided by SOA. The challenge for IT departments will be to explain to the irate business user that the reason why their mash-ups don’t work so well any more is because they have to invest more in those vague and intangible concepts: middleware and architecture. We may arrive back to square one but at least our business colleagues may better understand why we need to be there!

Ronan

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

When I started to write this item I was tempted to use the title “Daddy, Mommy won’t let me play with SOA” however I held back because it is too serious a subject for a one-liner. The topic of whether IT is holding back particular innovations which business wants or vice versa is hardly new. Many will claim that the PC revolution in the enterprise was slowed down in some organizations by IT departments keen to stay in control – until the demands of business departments and their unilateral actions forced the issue.
Is the same blocking happening with SOA? ZapThink certainly seem to the think so with the claim :

“What ZapThink is finding is that the primary barriers to SOA adoption do not come from business management, which by and large realize the benefits of an agile, reusable, and loosely coupled architecture (even if they don’t call it that), but rather from within the IT organization that resists the movement to SOA for a wide range of reasons”

And Ron certainly makes some good observations on why IT departments can struggle with adopting SOA – everything from the challenge of making the required organizational change to general fear of the new to believing SOA could threaten their jobs.

While it is obvious as Joe McKendrick points out that "few analysts, commentators or pundits seem to argue the point that SOA is facing resistence", I think it is too simplistic to say business gets it and IT doesn’t or doesn’t want to. First of all, lets be realistic: Of course SOA is facing “resistance” – any major shift, as SOA is, takes time to be adopted and some organizations will go slow, others will jump ahead. Frankly - either decision can be right depending on individual circumstance.

Secondly, because SOA promises benefits that no sane business person would turn down does not mean that every business person will drive it though the organization (“the business sell” as David Linthicum puts it). What I suspect ZapThink is picking up from some SOA proponents is a “soft yes” to SOA from business, based on the benefits and frustration when IT management can’t convert this to a “hard yes” with budget. The reasons for this difficulty have been widely discussed and relate to the generality of the benefits which can be SOA’s worst enemy as my colleague Steve Craggs puts it:

the platitudes surrounding SOA have been used for 20 years on business execs, so they can be forgiven for having grown rather cautious, and desirous of looking for incremental investment where payback can be validated at each stage.

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

Lack of available expertise is now being highlighted as a major blocker to SOA adoption in 2007. What organisations need is expertise around how they can plan, create and deploy SOA successfully. This requires individuals such as architects and programme managers with the ability to develop and deliver a programme as potentially complex and all encompassing as SOA can be. However, it also requires expertise in the organization specific processes and data models – many of which are in fact not so much organization specific as specific to the industry segment it operates in. Therefore it is perhaps surprising that we haven’t heard more about industry specific frameworks for SOA: templates or “Solution Maps” as SAP calls them which provide a fast track by providing the industry expertise pre-canned.

In the past (pre-SOA), I have been sceptical about industry specific frameworks and in particular wondered whether they were actually clever ways of packaging up consultants with expensive industry specific knowledge. A scepticism I brought up with a senior manager in a European retail bank who is an early adopter of SOA of about 4 years standing. His view was that leveraging the industry based patterns that he is now using (provided by IBM in his case) earlier on would have been a significant benefit in reducing the effort and risk associated with his programme. As such a framework was not available when he started, he had to create his own framework: Using somebody else’s even if it had to be adapted would have been a major benefit in terms of time, cost and risk.

Of course whether it will work for you will depend very much on the industry you operate in, whether its processes are sufficiently standardised and whether it has attracted the attention of one of the firms creating the frameworks. However for industries where it does suit the benefit for users will be significant and the opportunity for vendors will also be big. In fact, I believe that for these “framework-friendly” segments the competitive landscape may be considerably different: The vendors with the greatest knowledge of providing industry specific solutions will be in a very strong position. In particular IBM and SAP should dominate as they have the customer base and expertise and are already investing heavily on creating the frameworks.

As such it may well provide SAP will an excellent opportunity to break out of its ERP-centric SOA niche (selling to customers who see SOA as an ERP extension) and get some return on the investment in their Cinderella-like SOA strategy: just like Cinderella, it does all the right things but still gets ignored by all the Prince Charmings!

Ronan

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

Reading Joe McKendriks’s blog piece on “Is EDA the ‘new’ SOA” got me thinking again about how EDA and SOA fit together. Event Driven Architectures (EDA) is sometimes held up as an alternative to SOA. While this may be theoretically the case, I think EDA-style capabilities are most likely to build on top of SOA to take advantage of the higher degree of integration provided by a SOA deployment.

Rather than going into detail on what EDA is, I will quote some definitions from Jason Bloomberg of ZapThink back in 2004 and suggest that anybody who wants to know more goes to Brenda Michelson’s excellent primer on the world of events and EDA in her elemental links blog.

Jason’s definitions are:

EDA is an approach where events trigger asynchronous messages that are then sent between independent software components that are completely unaware of each other.

While

SOA, on the other hand, is an architectural approach where software functionality is exposed as loosely coupled, location independent services on the network.

Therefore the primary difference between SOA and EDA is the level of decoupling between the software components. The total decoupling of source of the event and the eventual destinations in EDA means that the message fully defines the interaction between components – a very different situation from SOA where the server and client interaction is ruled by the service definition. In fact, EDA is not a new pattern – it is a form of “publish and subscribe” which has been around for a long while and effectively used to solve certain classes of problems.

The question from Joe was “Is EDA the new SOA?” – I would say no for two reasons:
• The level of enforced decoupling in EDA can make it awkward to shoehorn the range of problems that an enterprise architecture has to solve into a pure EDA form.
• For those problem types that EDA is well-suited for, SOA can be extended with a bit of EDA and therefore do the job.

Rather, I see EDA being used ‘on top’ of SOA – to allow identification and processing of unusual events or combinations of events that should generate alerts or recovery processes. SAP for one is already providing some of this type of capability within its NetWeaver product set where BPEL-defined processes can be fired off in response to specified events. This type of functionality will be crucial in terms of delivering control across the SOA-based network of integrated components exchanging more information and information of greater business value.

Ronan

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

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)

The discussions and news around SOA are clearly moving on from cool features towards tackling the nuts-and-bolts issues of how to get it done as can be seen from a few of the items that have appeared in the last week or so.

Joe McKendrick does an excellent job of pulling together a number of quite contradictory surveys attempting to measure exactly how great SOA adoption is today – with IDC coming in at the upper end with a survey claim that 90% of respondents were on the way to SOA.

His conclusion is that most organizations claiming to have deployed SOA are only in the early stages:

These statistics vary wildly, and lead one to conclude that SOA must be in the eye of the beholder, because one company's "SOA" may be, in someone else's view, a Spaghetti-Oriented Architecture or "JBOWS" (Just a bunch of Web services).

What all of the statistics show is that there is huge awareness of SOA and most people feel it is something that they should be doing. Clearly, there is absolutely no way that 90% of organizations or anything like it are already SOA based.

Accenture were recently reported as committing $450m to a new SOA technology lab in Chicago.
Meanwhile, Don Rippert, CTO of Accenture was in Hong Kong and outlined his view of the 4 phases of SOA development:

Phase one: "Organize and Strategize": get management buy-in and plan for SOA transformation

Phase two: "tactical implementations": embarkation on SOA projects and the conversion of applications into web-services, and the creation of business processes from such.

Phase Three: an emphasis on strategic and business services; consolidation of processes and services in creating an Enterprise Service Bus.

Phase Four: "SOA is industrialized," he said. This will involve cross enterprise processes, federation, predictive IT and business insight in real time.

Focused as you would expect on the high level, I am not sure there is much to argue with these statements. Each phase has its own challenges – in particular moving from phase 2 to phase 3 and beyond. That is where organizational and role changes need to begin. For instance, Wachovia took a product management based approach to ensure that SOA remains responsive to the needs of business.

And finally, David Linthicum has tackled the sensitive issue of whether the EAI dinosaurs can really dance to the SOA tune:

Many are finding that the more traditional *EAI technology is coming up short when you consider the new complexities of SOA.

And

Perhaps the core issue is innovation. While a commodity in the newer venture funding startups that don’t need to declare an EPS, are just cost to the larger companies, and thus to be avoided.

As a person who spent almost 5 years in a SOA start-up (PolarLake) I clearly believed and still believe that there is an opportunity for well-funded SOA start-ups to take on and beat the established vendors. However, some of the established vendors are already ‘evolving’ fast and their SOA offerings are already as impressive as the best of the start-ups. As so often happens in a new market, expect to see a couple of the familiar names disappear (as has already happened for instance to Mercator an old-reliable of the EAI marketplace) and a slot or two emerge for a new player.

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

It has often struck me as strange that while SOA is all about loosely coupling, the principle hasn’t often been extended to user interaction which after all is almost always at either or both the start and end of business processes. Instead even in a SOA environment, most enterprise users still interact almost all of the time with one application at a time through tightly coupled clients or browsers.

This neatly brings us back to the Web2.0 technologies which are after all primarily a revolution in user interaction and user interface. To narrow the focus a little, lets consider only the following elements of Web2.0:

- The evolution of browser based user interfaces (thanks to AJAX) into something richer and closer to the familiar desktop interface. This is exciting because client side computing hasn’t really changed since the browser first appeared in the late nineties.

- The concept of the mash-up as a combination of services into a single client-built interface has spread in the consumer web.

(While user interaction can be created through wikis and blogs, I won’t delve into these primarily knowledge management tools although they have a clear potential role to play in service definition/reuse and governance and I will focus on the social and collaborative implications of Web 2.0 in the next blog item in this series.)

The implication of much better user interfaces – and hence must more functionality embedded comfortably within those interfaces - and the ability to combine connections to multiple back-end systems as mash-ups has big implications in the enterprise: the client can now evolve towards being a peer of the back-end systems. Although clearly still a peer with limitations – it is now capable of initiating actions independent of a single system and capable of interacting with many systems in a much more intelligent way.

Furthermore because it is easy to create these interfaces and mash-ups, the client can become truly decoupled from the applications as they are now capable of rapidly adapting to handle new applications, new data feeds and new services.

A further implication of the simplicity (and productivity that I previously commented on) of some of the Web2.0 tools is that it creates the potential to take central IT function out of the implementation of these clients completely and instead focus them only on the associated governance issues: allowing less IT expert, but more business focused individuals to solve their problems themselves.

You may wonder whether this can actually happen: can non-IT people create their own interfaces. I don’t think the AJAX tools are even close to being mature enough to support this just yet – they are still built by techies for techies – unlike wikis and blogs which are usable by most people. However, I think the concept is completely plausible – look at the way Microsoft Excel is “programmed” by non-technical people to carry out very sophisticated calculations. Imagine if the same could be done with could be done with a end-user focused AJAX combined with an enterprise edition of myYahoo.

Posted by rbradley in SOA Predictions • SOA concepts • Web2.0 | Permalink | Comments (1) | 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)

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)