Different industries have different priorities and adopt SOA in different ways. Ilog has just announced that their rules product, JRules is being used in Hiscox (a major insurance company which focuses on specialist and hence more complex insurance products). By a strange co-incidence, Elizabeth has just announced an upcoming event on SOA and the insurance industry.

The Ilog announcement is interesting in that it clearly states two of the most common requirements in Insurance that SOA (and in this case SOA with additional business rules) tries to meet - and one which is less commonly stated:

“First, Hiscox wanted to be able to add new distribution channels as quickly as possible.

Second, the company wanted to reduce the time and cost associated with both making changes to existing products and bringing new products to the market.

Finally, Hiscox needed to increase the ability of underwriters and business analysts to make changes to rules directly without having to change complex system logic, allowing the company to improve its business response time.”

The ability to add new distribution channels is common across financial services. As the products are purely electronic, adding a distributor is equivalent to integrating their systems with your own. This requires mediation of the message formats and flows – clearly Hiscox is using a rules based approach but of course others are possible.

The need to get to market quickly with novel products is also common across insurance, retail banking and its most extreme case in derivative trading. Again, it requires good message manipulation capabilities in the middleware.

The final requirement is to my mind the most controversial and clearly the most valuable if achieved: To take IT out of the loop when changes need to be made. If it can be done, it has clear cost and agility benefits. However to be successful it requires well formulated message formats, well understood processes and above all careful controls around what can be changed as the underwriters and business analysts are unlikely to appreciate the implications of their actions in the way IT staff have been long trained to do.

Ronan

Posted by rbradley in Financial Services • Product news • SOA concepts | Permalink | Comments (0) | TrackBacks (0)

Mash-ups are one of the hot areas for trialing in 2008 and a likely major project area in 2008, 2009 and beyond. The concept is appealing to business users and allows rapid development of useful applications. As I have previously blogged about, mash-ups put a strain on the infrastructure. However the impact is not on the infrastructure alone, it also puts unexpected pressure on the applications supporting the mash-ups. An early adopter in a global investment bank was quoted in a recent article in Waters as pointing out:

"you can't create a service that is designed to support 100 trades per minute and then let someone with a black-box trading system connect to it and expect happy results. The resulting automated traffic would bring the service to its knees and those supporting it would be faced with fielding phone calls from users letting them know the system had gone down."

However, system outage is only one problem - you must also ensure that mash-up user is entitled to use the data (both from an authorization perspective and also from a rights-management perspective as the data may not be licensed for use by the mash-up user).

The only solution is to increase the level of control and governance by defining and enforcing SLA and so on - in effect bringing mash-ups back with the framework of enterprise IT. The challenges will then be

- Finding out where mash-up development is happening in the organization. The very ease with which mash-ups can be created will tend to put them under the radar.

- Convincing the users and developers of the mash-ups that governance is there for good business reasons and not simply central IT attempting to regain control and squash innovation that they do not control.

Ronan

Posted by rbradley in Financial Services • Mash ups • SOA concepts • Web2.0 | Permalink | Comments (0) | TrackBacks (0)

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)

As the title of this blog is "Roads to SOA" (for the moment at least), I though it was worth noting two anniversaries which relate to two of the most significant factors in the implementation of SOA: The Open Source movement and XML.

Over the last 3-4 years in particular, Open Source has been one of the major feature of SOA technology landscape and looks like only becoming stronger as OSS projects mature and IT budgets get squeezed in the economic downturn. Denis Byron also celebrates the anniversary and provides some excellent counterpoints to the more outlandish OSS claims in general. To quote Dennis: " I can't quickly think of any (never mind "many") "business computing category" in which open source software is a leader". In the context of SOA, OSS is a major feature - although it is not a leader as yet.

XML is also 10 years old - I almost felt like writing 'only' as XML is so much part of the fabric these days it is hard to imagine a time before it existed. Over the 10 years, XML turned out to be a giant leap forward by allowing data formats to be defined independently of technology in a way not attempted before and launched countless bodies to define XML standards for industries from telecoms to financial services to travel.

In 'celebration', Tim Bray published a long piece on the people and early history which Tim Anderson both summarises and criticises for Tim Bray's hostility towards Microsoft (a common feature of the OSS community as well of course). Criticism is hardly surprising when Tim Bray makes the delightful remark that "Mick [Microsoft in his semi-allegorical history] is a domineering, ruthless, greedy, egotistical, self-centered, paranoid bastard.".

Tim's views on Mircosoft's attitude to standards are clearly heart felt. However, having been involved with standards processes over the years - I am not sure Microsoft is necessarily that much more 'evil' than other companies which attempt to manouver the standards process to aid their commercial goals. Also having lived through the CORBA/DCOM wars in the 1990s when Microsoft was not part of the process, it seems clear to me that XML benefitted more from Microsoft's involvement more than it would have benefited from being pure and free from Microsoft which no doubt would have followed a different track and created a competing standard.

Ronan

Posted by rbradley in SOA concepts | 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 post before Christmas sparked an excellent thread on the SOA Yahoo! Group around whether an Enterprise Service Bus was really a “keystone product in a SOA strategy” as I claimed . What the discussion highlighted for me was the importance of balance between the need to strive to design reusable services and the need to be pragmatic and fix service definition mismatches when they inevitably occur.

Anne Thomas Mane contributed to this discussion with points that I would at least partially agree with (A statement that she may find surprising as she identified herself as one of the "remaining hold-outs who continue to argue strongly that ESBs are irrelevant or transitory" who I referred to in the original posting.) Her points were:

1. “[An ESB] provides a means to expose legacy application functionality as services, and it supports mediation (although not efficiently) and sometimes orchestration”. Most ESBs provide good support for accessing existing applications, manipulating message formats and doing the work required to covert one or more existing systems into a black box service implementation which consumers can access without worrying about what is going on inside the box. I certainly agree with these statements.

2. “not all messages must flow through an ESB. Only those messages that require the services of the ESB should flow through the ESB.” To a degree, I agree with this one as there will be cases where the ESB provides little value beyond the acting as a common infrastructure through which all messages can flow – the value of which commonality must be judged on a case-by-case basis.

3. Anne’s third point is that by relying so strongly on an ESB – with its integration capabilities – it can undermine the focus on getting the service definitions right. In effect because an ESB can fix deficiencies with your service definitions on the fly, organizations can get away with poor service design – initially at least. Again I have sympathy with this but I feel it is like shooting the messenger. The SOA message is that the service definitions are crucial to getting the reuse/sharing which drives the economic argument. It is absolutely the case that adopting an ESB or any other product should not be used as a way of avoiding that architectural investment. Using an ESB without investing in service design is simply using an updated EAI product to do old style EAI!

Which brings me back to a favorite question: is it possible to create services which are capable of being used by all potential consumers now or in the future without some mediation (such as transformation orchestration) between the service implementation and consumer? I simply do not believe it is. Even if you can design the service to suit all possible needs today without mediation, there will be unforeseeable changes in the future.

The answer could be to refactor the service but the experience of many years of attempting to build large scale data models (which is effectively what you are trying to do – build a shared model between service definition and all the consumers) tells us that this gets more and more difficult to achieve as the scale (the number and diversity of clients in this case) increases. Therefore, the only alternative is to accept that to some degree there will be a need for mediation as the service definition will not be perfect for every consumer. The only remaining issue is whether individual ESB products provide sufficient mediation capabilities. And again I tend to agree with Anne when she criticizes the three ESB vendors that she name checks (IBM, Sonic and BEA) as these do not provide great mediation capabilities within their ESB products. However, current product deficiencies should not (yet) lead to the ESB baby being thrown out with the bath water.

Ronan

Posted by rbradley in Enterprise Service Bus • SOA concepts | Permalink | Comments (0) | TrackBacks (0)

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 was forwarded an excellent article written by Kevin Kelly, now of Kemar Solutions, from a new book called Secrets of SOA. Kevin worked for the Irish national airline in the 1960s on a project that with hindsight he believes was Service Oriented. In the extract, Kevin describes the cultural and attitudinal changes required by SOA (The first chapter is free to download from the site and includes this piece as well as others).

Kevin makes some excellent observations on the 1960s project and its relevance to any SOA project today. In particular, he stresses the idea that if the culture of an organizational is truly service oriented, developers will begin to naturally reuse:

“SOA is as much a state of mind as it is a technology. It’s as much about behavior and orientation as it is about programming per se. When I came to IPARS at Aer Lingus [The project he worked on], the overall orientation was a fait accompli; we were introduced to it as the way the system worked. It never occurred to us to vary from that orientation.”

He also stresses that to reuse is not the behavior previously encouraged in developers – in fact it is quite the opposite as developers are normally rewarded for innovation. Therefore, as I said last time, organizations need to make it clear that they reward reuse. As Kevin puts it:

“The decision to reuse is usually a good decision for the enterprise but often a painful decision for the solution builder accustomed to being rewarded for innovation and technical know-how… If we preach reuse while rewarding developers who pay no attention to it, we should not be surprised when the majority of developers perceive reuse as unimportant.”

And finally, Kevin stresses that SOA is about culture change as much as technology change:

Because of this existing critical mass [in the Aer Lingus project], it was easy to follow the example of our predecessors and continue in the service-oriented vein. It’s not so easy when you start trying to introduce SOA to an organization with no experience. It’s necessary to have a holistic approach, one which includes organizational, behavioral and attitudinal perspectives. Having a sound technology base will certainly help, but you need more, and it’s a slow haul.

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

Joe McKendrick’s summary at the end of August of opinions about whether reuse is achievable with SOA or even if it is the real benefit of SOA seems to have ignited an increasingly widespread debate. Reuse is now being discussed in CIO blogs such as here , slammed by Miko Matsumura in “Die SOA Reuse Die”, and defended in my own Illuminatus Research blog among other places, with Joe stirring the fires again at his own blog .

So why the big debate? First off, it is not surprising that at this stage in the SOA adoption curve, failures (or at least lack of success) will be trumpeted more loudly than success. However, there have been successes with SOA reuse for instance at Wachovia as I previously commented on.

Even if we accept these set-backs, I do not believe that we should simply abandon reuse as a goal – frankly without reuse, aren’t we giving up on the benefit of SOA which is most tangible? And while it is tempting to move away from the tangible and adopt the higher level abstract goals of “business agility” or “better infrastructure”, they are hard to measure without being tied back to reuse and hence hard to justify a business case with. As my Illuminatus Research colleague, Steve Craggs puts it:

“a lot of these are grand, strategic benefits can be somewhat difficult to measure, and this is a problem to those people trying to build business cases to justify SOA investment. I think this brings us back to reuse as being a major pragmatic driver of SOA - that is, a driver that actually drives real SOA investment.”

Which brings me to my own three step solution for driving up reuse levels (yes – it is high level and simplified but anyway):

1. Get the technology right – make sure your service definitions are designed with reuse in mind (Gary So of Webmethods has recently covered this subject . Get the technology back-up in place to ensure that services are easy to reuse from registries to repositories to governance to wikis.

2. Get the organization right – SOA isn’t just about technology and in particular it is clear that relying on the technology alone won’t deliver reuse. Some commentators seem to throw the towel in and say that conservative organizations won’t be able to make the change, I am not sure so. The primary change I would recommend is to identify clearly service owners. This was the approach taken in Wachovia and other places that have had SOA reuse success. It is also an approach which is inline with even conservative management theory: clear responsibility, clear measurement.

3. Pay up: Incent with bonuses both the service owner and the service consumers to meet reuse targets. If you incent both ends of the transaction, things start to happen. Yes, there are risks of abuse that must be policed against but the rewards are greater than those risks. I have written a free-to-download piece on this and the second step on at the new Illuminatus Research site http://www.illuminatusresearch.com/.

Unfortunately, as technologists we are comfortable with item 1, willing to discuss item 2 primarily in the context of the IT department (SOA competency centres and service librarians are good ideas, simply not sufficient) and seem shy to address 3 at all!

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

AJAX remains one of the hotter topics around the industry with the initial excitement now translating into actual product announcements – most recently Tibco and JackBe. A lot of these announcements are linking strongly back into the SOA space and the cynical eye might suspect some bandwagon jumping is underway – however this time I am not in the cynic’s camp.

JackBe, a company with a strong ex-Sun contingent, has announced its Presto platform
will be released in the first quarter of 2007. This will support the creation of rich clients for SOA which are “Situational Applications”. Situational Applications are applications rapidly developed to solve a specific requirement and are typically written by developers with less technical skills and more context knowledge. To put it another way according to Dan Gisolfi, a Certified IBM Executive IT Architect:

“Situational applications are a way for people with domain expertise to create applications in a very short time. Many IT shops have a backlog of small little projects that their customers want. If it takes 3 weeks to get to a project, the need is gone before the developer even starts coding. We want to give knowledge workers the tools to solve their own problems.”

You might ask what that has to do with SOA. Of course, traditional middleware had little need for interfaces except for management purposes and message repair type facilities as all the user interaction occurred within applications. While this line has been blurring for quite a long time as the EAI vendors added Business Intelligence layers – the generic need for rich client capabilities was limited and this was reflected in features provided in most middleware products.

As you move into the SOA world, you are deploying more business processes into the middleware and more of the business processing resides there. Therefore it makes sense to allow direct user interaction with this layer and using AJAX is of course a way to write these rich user-focused clients. However, JackBe has gone further by realising that simply addressing the presentation and interaction side is not sufficient. If something will be deployed into SOA, it must be capable of conforming to the SOA governance rules and being a “good SOA citizen”.

Finally, what makes their offering a platform for situational applications rather than a generic rich client platform is what they call their “Enterprise Mashup Server” which acts as a consolidation point for the various services and streams of data that will be presented to the users. Of course as the use of the word Mashup suggests, the focus is on making it easy to create new client interface/applications from the available services and data streams.

All of which is clearly of potential benefit within any SOA based enterprise. However, I have two caveats. The first is the use of the term AJAX Service Bus – I am not sure we really need to invent a new term. The second, more serious one is the claim by JackBe of creating “situational applications”, a claim echoed by Jason Bloomberg of ZapThink:

“The Presto platform is poised to take advantage of the opportunity where enterprises are looking to enable business users to compose services into SOBAs (Service-Oriented Business Applications) that implement business processes in a flexible, agile manner.”

Will this really allow business users to do it themselves? This has been the promise of all sorts of client-side software for as long as I can remember (second only to the claim that programs will be auto-generated by modeling tools!). I can see how it will make it easier and require less technical skills for developers to build these situational applications. However, based on the webcam demo I watched, I remain to be convinced that it will really allow non-developers to start work. Having said that, I haven’t seen the released software yet and so I could be wrong!

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

As new IT concepts emerge, we tend to take words from the ‘real world’ and twist and turn them into technology terms. Unfortunately, SOA is currently a particularly bad offender when it comes to creating as much confusion as clarity with the terminology that is being used (even with term SOA itself). And what better examples than orchestration and choreography – is a business process really best described with reference to an orchestra or a dance?

This lack of clarity means that we seem to spend more and more time explaining what we mean by the terminology we use instead of actually communicating. In case you aren’t convinced, a great example of a basic but still unclear bit of terminology is the term Transformation which is used in hugely different ways by different people – all the way from bit-twiddling data fields to complex processing of the information contained (I tend towards the second).

If we look at the definition of the ‘real’ word “transformation”, it comes from the verb: to transform which has meanings such as To change the form of; to change in shape or appearance; to metamorphose, to transmute. It all sounds close enough except when one comes to actually ask different people what they think is technically involved in transformation and discover that some think it is a simple reordering while others regard it as fundamentally complex and more about semantics than anything else.

Unfortunately I don’t see much alternative to current situation until SOA matures and all of this terminology settles down. In the meantime, we will have to show patience and accept that one man’s transformation is another man’s translation is another man’s something else. (And these thoughts were inspired by yet another discussion I was caught up in which was more about terminology than substance)

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

With all the stories appearing around the level of reuse actually being achieved and even the level of reuse we should reasonably expect, what has caught my attention recently has been how the challenge of reuse plugs into the need for organizational change as part of a SOA program.

I covered this in passing in my previous blog posting on how the architect role seems to be greatly expanded by SOA and how business needs to be involved particularly in the area of service ownership. Richard Akerman, a technology architect with NRC CISTI, expanded this in his own blog saying:

“One of the things we found useful was separating the business-level service description, from the IT-level service implementation. What we're currently thinking is that the business should own the business-level service ideas, but the IT-level implementation should have an IT owner. This is important, because I think you can get a bit carried away in the "business drives technology" or "business-driven SOA" enthusiasm. Yes, the business is in charge of generating and validating the business ideas, but they shouldn't be deep within your IT organization making technology decisions.”

I agree with Richard’s point – we need to remember what we are trying to achieve with service ownership: it is not to make business people into enterprise architects or enterprise architects into business people (although there are some who are already both). It should be all about achieving the goals of SOA which in the case of service ownership is primarily about driving the rate of reuse up. The technical goals around perfecting the service definition, interacting with registries, repositories and governance etc. should all support this goal of reuse being achieved in a resource efficient, controlled and ‘safe’ way.

Similarly, we need to figure out in a given organization how to use business ownership in a way that increases reuse. The way this works will depend on the service in question and the structure of the business. In the case of some services (say a booking service for the logistics function), the service maps pretty well onto a business line and the purpose of the service is easy to communicate to a business owner. With others, the purpose of the service is less easy to map as they are inherently more technical – say querying a logging system about failed messages. It is still a valid service but ownership fits better within the IT organization – all be it with an owner who looks at his/her costs and sees how the service will reduce them. I will return to this topic again!

To change track a little, Jeff Schneider of MomentumSI looks at service ownership from another perspective in “Lessons from Planet Sabre”: He points out that some services will be built by units which are primarily in the business of providing services to others, while others will be built by a unit for its own use. Both are still valid and need to be handled with equal care. As Jeff puts it:

“The shared services group had a great process for managing the deployment and operational processes around services that THEY built. But what about ours? Doh!”

and

“Lesson: New services will be found on projects and in some cases they will be 'non-shared'. Understand who will build them, who will maintain them and how they will be supported in a production environment.”

However, he saves his best lesson for last:

“Lesson: SOA takes time to figure out. Once you do, you'll never, ever, ever go back. If you're SOA effort has already been deemed a failure it only means that your organization didn't have the leadership to 'do something hard'. Replace them.”

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

SOA addresses such a broad problem domain that it is obvious that there must be significantly different architectural patterns or styles within SOA – each best suited to address different types of integration problem and within any organization it is likely that multiple styles will need to coexist. Understanding these distinctions in the context of your organization is clearly crucial to evaluating which products (or custom coded alternatives) should be used for a specific project. Equally, ensuring that the products selected for different SOA products work well together will be essential to ensuring SOA works across the organization.

Oracle published a white paper over the summer which described at a high level some of what I would call styles and they call “Value Patterns” emerging among their customers adopting SOA. These styles are:

• SOA based integration
• Modern, composite application development
• Modernising mainframe and legacy applications

The first two styles were also well described by Brenda Michelson back when she was with Patricia Seybold before launching out as Elemental Links Inc, in “Service Oriented World: Cheat Sheet” (Brenada calls SOA based integration “flow” style integration):

“The two primary styles of SOA used in business solution development are composite application development and flow. In composite applications, the user interaction drives a request for one or many services. Most of the service invocations are synchronous in nature. A composite application typically serves one business domain. Composite applications are often delivered in a portal.

In flow, business process and/or events drive the service invocations. The service invocations are a mix of asynchronous and synchronous; however, the overall flow is usually long running and asynchronous. A flow typically crosscuts business domains and often extends outside of the enterprise. "

(Oracle’s third style I am afraid I simply don’t buy as a different style: mainframes and legacy application modernisation may be the requirement but it isn’t a value pattern in itself. Although it does make sense to make the distinction at product selection as most vendors/products are either very mainframe focused or not at all.)

The style selected of course reflects the type of solution you are trying to create but it is often also influenced by the expertise within the organization which may reflect the problem domain or be an accident of history: if there is a strong background in EAI, flow will tend to be favored; if application servers are the preferred platforms, composite application development may feel more natural.

The three styles also drive very different technical requirements which strongly links back to product selection as products will tend to specialize in one style and provide weak(er) support for the others. This is of course at odds with the normal marketing hype of “Universal SOA platform for all known problems”.

Even in the case of Oracle, IBM et al, while their portfolio may include solutions for each style, it is very unlikely that a single product can address more than one style and the degree of integration between the products is then the issue. This is probably why Oracle stressed the level of integration within their latest releases as I previously commented on and why there is still a need to consider best of breed products unless the big vendor can really prove the strength of each product and their complete portfolio.

Posted by rbradley in Enterprise Service Bus • Market trends • SOA concepts | Permalink | Comments (2) | 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)

There has been a spate of customer success stories emerging over the last few weeks - one feature of these that is prominently highlighted is the focus on data. This should hardly be surprising given a major component of all integration problems (once you get beyond technology integration) is bridging between the data models. Within a SOA, the data models built are then exposed through the service definitions. The requesting applications must either formulate the request using the data model of the service provider or more commonly rely on an intermediary such as an ESB to bridge the gap (something I refer to as mediation).

Chief Application Architect Eric Peebles for the City of Chicago recently highlighted the role of data within SOA and he pointed out while speaking about why Chicago moved to SOA using iWay’s products:

city departments and even major citywide applications are separate islands of information about people, companies, land, and buildings. We needed a strategy to integrate these applications and data in order to drive business improvements more effectively.

There are two fundamental approaches to dealing with data integration within SOA: Build a global data model for your business which each connecting business unit must bridge into and out of in order to integrate with other units or build multiple data models. At their most extreme, there are major problems with each approach:

 Attempting to build a single global data model becomes harder as the size of the organization grows and the level of change increases. It requires an excellent understanding of the business at the start and an understanding of how change will impact upon it to successfully wire the data model for change. The approach of attempting to adopt a public standard is also not the solution (for instance FpML in financial services for derivatives) as there will significant divergences between the standard and what your business needs – it can be too complex, too simple or just plain wrong! That is not to say building a global data model is impossible – simply it is never as simple as it appears at the start!

 Allowing each unit to build their own data model and then providing bridging capabilities between each business unit. This builds cost and complexity into the integration layer which can slow down each project if the intermediary (such as an ESB) is not sufficiently powerful. It can also reduce the level of reuse between the business units of knowledge around building data models for your organization.

The solution is of course balance between the two approaches – and the precise balance will depend on the industry and the organization. For instance:

 If your architecture requires a central data exchange through which multiple organizations combine to complete business transactions, it may make sense to veer towards a global data model for this exchange.

 If your organization uses a lot of out sourcing or provides out-sourcing to other organizations, it may make sense to veer towards a per-unit data model as you will have limited control over the data model of the other parties.

Finally, the approach to building data models within a SOA context must be sensitive to the types of integration problems that need to be solved and specifically the data models that your model must integrate with. I have seen models which are theoretically perfect, but because of complexity and the mismatch between the model (exposed through service definitions) and what it needed to interact with where almost impossible to use. As with so much in integration, where possible keep it simple and build in the ability to change.

Posted by rbradley in SOA concepts | Permalink | Comments (3) | TrackBacks (2)

One of the much touted benefits of SOA is that it aligns IT with the business – the concept of a misalignment between IT and business is one that I have always found puzzling: how much is just a cliché and when it is not, how can things have got misaligned in the first place. Clearly cliché or not, it is essential that SOA is seen to address this problem. To do this SOA must be implemented in any given company in a way that reflects the organization’s goals, structure, history and even its corporate culture.

Before telling you what my three principles are, lets go back to the perceived misalignment. As was noted by one blogger I read (unfortunately I can’t remember or find out who), how come nobody ever talks about how to align manufacturing with the business? It would be nonsensical – manufacturing can only exist if it is aligned. Similarly, it would be strange for accounting or finance to become misaligned with business. So how come IT can be misaligned? A few suggestions:

- There is a lack of credibility around IT in business – one measure of this is the number of CIOs without IT backgrounds. We need to accept that this lack of credibility is a reasonable response to a history of well-publicized overambitious and under-delivering projects.

- The IT structures in a corporation can become a power center independent of any business line – a cost center blamed for swallowing huge budgets without generating obvious business return.

- The scale of many IT challenge (particularly when it comes to integration) is often not appreciated by business people who do not understand why what appears straight forward can be hard and very expensive (what could be easier than linking a few databases!).

All of this predates SOA and as I mentioned a while back the NASCIO report made a key observation: one of the key aspects new about SOA was that it was building a justification for what has been best practice in enterprise architecture for a while: a justification targeted at business and hence at overcoming these issues.

Which brings us back to how to align your SOA strategy with business and some general principles that I have found along the way:

1. Adopt an incremental approach to rolling out SOA: Focus on achievable but worthwhile projects which can generate real and understandable benefits (such as NASCIO’s reference to collection of fines by a state agency which yielded rapid and measurable cash benefits). While SOA is all about architecture, don’t over-invest too early unless you are sure of the patience of your backers!

2. Don't attempt to use SOA to change the way the world is: Create your SOA strategy inline with the business organization as it is, not the way you wish it was - even if this makes your life more difficult. There is no point creating a single global registry with strict controls on who can add or amend items if the business is highly devolved and dynamic. Similarly, don't believe that your SOA will remove the complexity inherent within many business processes - it may remove technology complexity, but at the end of the day if the business is complex you will need a SOA that can handle that complexity.

3. The only worthwhile SOA is a pervasive SOA: The strategy has to be broad enough to allow most if not all projects to get going without excessive change-over costs or risks. Your SOA shouldn’t force major changes in infrastructure, otherwise the disruption could make the project too risky or the cost too high. Your SOA should be scalable down to the smallest projects in a meaningful way. If there are types of projects which can't be handled because they are too big or too small or too legacy focused or whatever, it will undermine the entire SOA program. All of whcih means that the technology platform(s) has to be plug-and-play to allow capabilities to be deployed where needed and stripped out for the projects which need a simpler solution.

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

SOA can appear overwhelming because as an architecture it is proposed as a solution to all integration challenges for every industry and for every scale and complexity of company. Clearly, the way SOA will be manifested in any given company will reflect that organization’s goals, structure, history and even its corporate culture. This is not only from a technology point of view but also from a business point of view – after all SOA is all about alignment of technology with the business.

The Forrester ESB wave research I mentioned in the last item reported different rates of take up among different sized firms, with 67% of larger firms implementing SOA this year compared to 44% of small to medium sized businesses. This is hardly surprising as the larger firms will typically have larger problems and larger IT departments capable and willing to take on SOA earlier in its evolution.

Aberdeen’s latest research focuses in part on a different issue: the emerging styles of SOA adoption. In particular, they identify three styles:

• SOA Lite is for users who are primarily deploying web services that do not require mission-critical capabilities such as high-volume scalability, high availability and failover, management, governance, and security.

• SOA ERP is used by companies that are choosing to deploy SOA surrounding their ERP application software.

• Enterprise SOA requires and uses mission-critical SOA middleware suite capabilities.

I don’t think that the fact there are different styles is in anyway surprising, nor are the three identified surprising as they match three common approaches to integration and within a single organization one or more will be present.

The first is for those organizations which solving light-weight problems in a direct and immediate fashion. SOA for these people provides a more systematic approach but must avoid over-burdening them with cost through over-engineering.

The second is the natural progression for organizations which have already chosen an ERP centric architecture – for these it makes sense to use SOA as an extension mechanism. It would make no sense to abandon the ERP centric world-view while moving to SOA.

The third is for those typically large organizations which have a multi-polar IT architecture, without a single center of gravity corresponding to an ERP system (for instance). These are typically the most complex organizations which probably have the most significant investment in middleware. This is the SOA style that gets talked and written about most – partly because these are often the organizations that adopted SOA first and they are also the organizations being targeted by vendors because they will make the largest purchases!

Of course, this is but one approach to defining SOA styles. You could also think about vertical specializations of SOA as David Linthicum recently covered or more technical distinctions between event-focused SOA and RPC-focused SOA, a distinction that unfortunately spawned the concept of SOA 2.0 (and I use the word spawned deliberately).

The inportance of all of this is that it allows us to move from the view of SOA as all encompassing (and confusing) architecture to something more focused on our problem domain – hence allowing appropriate architecture and product selections to be made. The fact that styles are being thought about and identified now simply shows the maturing of the SOA world.

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

Sometimes it feels like this industry resembles the old game of “whack a mole” just when you have whacked the last one, another pops up. The SOA community has recently risen up against the horrible term SOA 2.0 and I remain hopeful that this term will disappear as quickly as it appeared. Now another “threat” is bubbling under: The strange view (to me at least) that Web2.0 is in some way incompatible or even competing with SOA.

Steve Jones has written recently about this latest phony war in an excellent blog item. I guess in some ways it was inevitable: Both Web2.0 and SOA suffer from multiple interpretations and when combined with the blogsphere's love of a good row, it was just too easy to set up an “either-or” discussion.

SOA has also been suffering from an on-going naming and scoping discussion to confuse matters further - although I believe the smoke is clearing from the battle-field as we seem to finally agreed that SOA is not simply Web Services or an ESB and equally that SOA can use ESBs without being tainted and that while we may or may not like the term SOA that is what we are stuck with.

With regard to the SOA versus Web2.0 debate in particular, there has been unhelpful throwing around of what are intended as positive or negative terms depending on your side of the argument: 'lightweight' when discussing Web2.0 or 'enterprisy' when discussing SOA (a debate well covered by Joe McKendrik here and here ). This is dangerous as it leads to the mistaken view that the enterprise and all of its integration problems can be solved by either only the heaviest grade middleware or by only the most fluid Web2.0 style approaches. This can only be a plausible view to some software vendors who believe that their product can solve all known ailments or technology purists who believe their chosen technology can really make the world this simple! Instead as Steve Jones points out, there is a role and requirement for many different technologies and approaches: horses for courses -

One size doesn't fit all, and taking an architectural and particularly a business view of SOA helps you pick the right delivery approach for each service rather than trying to shoe-horn one method onto everything.

Web2.0 is of course more than just a set of technologies - it can also be considered to be a set of business models, and a philosophical approach to developing software around participation and easy access and these are certainly challenging to the attitudes often entrenched in the enterprise.

This is the interesting discussion to be had: how the Web 2.0 technologies, philosophy and even business models can be used in the context of the Service Oriented Architecture. And it is going on in many places for instance here – but somehow, perhaps, it is all less interesting than a good fight.

Posted by rbradley in Market trends • SOA concepts • Web2.0 | 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 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)

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)

Mrs Beeton, the 19th century cook and writer, famously started her recipe for rabbit pie with the line, “First catch your rabbit”. Some explanations of how to adopt SOA sound depressingly similar with something along the line “First get your senior sponsor” and just as with rabbit catching, it is easier said than done. The big bang approach to SOA – with its requirement for a top level management sponsor, major long term commitment and notions such as integration competency centers – may be the ideal but I believe that CIOs who are willing to bet their career on SOA before the approach is proven in their business are still as rare as rabbits running towards Victorian writers bearing large cooking pots.

Luckily, this is not the only way of adopting SOA and Joe McKendrick spotted what looks like an excellent event which includes a session outlining some of the different approaches.

Entitled “Building SOA in Cost-Constrained Environments” (and unfortunately that is the world the vast majority of us live in), Jonathan Mack, Senior Architect, 1800FLOWERS.COM summarizes different approaches as follows:

1. Bite the big bullet and go for the big bang;
2. Implement one key SOA element at a time (e.g. Message broker, then portal for on-the-glass composites, then ESB for process orchestration and finally BPEL for full BPM;
3. Slip in the back door – build an SOA under the cover of meeting business functional requirements and
4. Minimalist SOA – expose only a limited number of activities as services while focusing investment on cleaning up and improving existing processes.

Approach 1, I have already covered – good if it works but hard to find the people willing to go along for the ride. The alternatives are of course variations on the incremental approach and they are potentially complementary in many cases. Point 3 in particular, to my mind is the only way most of us are going to implement SOA - as part of meeting business functional requirements – whether through the back-door or front door (and frankly the business requirement owner doesn’t much care whether we use SOA or anything else so long as it works and is on time and under budget!). This is because within our cost constrained environment, there is going to be little opportunity to spend money on something positioned as a long term architecture generating long term returns (jam tomorrow) – the money is allocated to projects that generate benefit for