Business Making Progress

Forrester Recognizes Progress Sonic As A Leader in the ESB Market

Did you know that Progress® Sonic® was the industry's first Enterprise Service Bus (ESB)? It was, however, introduced in 2002 by Sonic Software which was an independent operating company of Progress Software Corporation.

In April independent research firm Forrester Research, Inc. named Progress Software as a leader in “The Forrester Wave™: Enterprise Service Bus, Q2 2011” report. In this detailed review of Enterprise Service Bus (ESB) providers, Progress Sonic ESB was recognized with particularly high scores for its ESB architecture, orchestration as well as change and control capabilities. The report also gave Sonic ESB high scores for product strategy and strategic alliances, while also scoring the product highly for its large customer install base.

Strategic businesses worldwide have made Sonic ESB a core component to their service-oriented architecture (SOA). A few of these companies include British Airways, Royal Dirkzwager, AutoTrader, and most recently UK-based PD Ports. Why did they choose Progress? Because Sonic ESB delivers the best overall combination of architecture, orchestration, mediation, connection as well as change and control features. It helps them achieve the business and operational responsiveness they need to be successful.

Cruise past your competition and make sure your integrated infrastructure is powered by the 1st and best ESB... Sonic ESB. If you are interested in the report, click here. It will be available FREE FROM REGISTRATION for the next five business days only. What a deal! ;-)

Feel free to also share your ESB integration and deployment experiences here.

Multi-tenant Distributed Process Environment (Part 2 of 2)

Last week at Chennai, Nasscom EmergeOut conclave recognized the prominence SaaS & Cloud hold in IT psyche today, and they had Innovation in the SaaS/Cloud space as its primary theme. I chaired a session called 'Software Procurement Model Trends'. It was interesting to note the amount of serious adoption in the whole gamut of companies from very small startups thru SMEs to large corporations like Diamler. And while today it is more about Software as a Service (SaaS), companies are now beginning to seriously look at Platform as as Service (PaaS) as well.

I also shared views on  SOA & BPM in the Cloud at the Great Indian Developer Summit in Bangalore last month and geared my thoughts on multi-tenant business processes. Like I had noted in my earlier post, as business processes get more integrated into the enterprise IT infrastructure landscape, new solution architectures are possible. We’ll begin to see whole cloud and distributed application models being encapsulated into single-solutions with embedded business processes. We’ll see these same solutions being deployed on the cloud, and even further being deployed in a dynamically scalable multi-tenant model.

This is, in my view, the more advanced of the three possible models for SOA/BPM in the cloud:

• Using Business Process Management (BPM) for integrating applications in the cloud
• Above BPM itself running in the cloud
• BPM embedded inside solutions running in the cloud (single-solution view)

BPM in a SaaS model, wherein one can model and execute their business processes over the web, is not exactly new. Gartner reviewed the web based BPM modeling and deployment possibilities in 2008, and cited the three possible deployment models:  For each application instance it may have its own BPMS and repository on a shared server, or a shared  repository, or the extreme form of shared BPMS+repository an a shared server. The whole web based BPM modeling and deployment fad has come and gone. This is partly due to limitations on the kind of use cases that fit in into BPM on the web, with solutions and services they access possibly being within the enterprise. And accessing services inside the enterprise firewall from outside is not the easiest of configurations to open up for secure access. So, model and execute on the web in a SaaS model is probably still time away from mainstream adoption. Until enterprise IT landscapes mature some more; with more widely distributed solutions over the web- possibly accelerated by rapid acceleration of SaaS model business solutions and also the accelerated adoption of public clouds within enterprises.

Now, one possibility not explored much is BPM and SOA becoming an integral part of a single solution. Though SOA is an integration paradigm and BPM is a model-driven business process layer targeting integration solutions & human workflow processes, both do offer a very elegant model for today’s modern applications. The granular coarse-grained services professed by SOA is a very good way of partitioning and abstracting sub-systems in any application. What’s more, BPM is a good mechanism to model all first level business processes and flows in any application. This is the single solution view of SOA/BPM.

However, once we switch to a single-solution view, with SOA/BPM being used in the solution as a first order design paradigm (and not just to integrate external applications or services), SOA/BPM can exist in two forms. 1) A simple solution model with an embedded BPM layer that helps organize the solutions functional sub-components better thru coarse-grained services, and all first level of solution capabilities modeled and realized as BPM processes. 2) A solution model that is actually distributed, but still in a single-solution context enabling and providing functionality for a single business solution. Extending this further, you could look at this single-solution environment as one that actually has distributed functionality (a la normal SOA - even as all the web services are essentially modular functionality that aggregate to form the whole application). These applications will use distributed sub-components in a SOA services abstraction and have business processes that provide a higher level of functionality in the application that access these components. Similar to the single solution view described above, but now these sub-components and business processes also are distributed across servers.

It is in this single-solution SOA context that SaaS and multi-tenancy become relevant. Using this model, an ISV could build an application on a platform that leverages the modularity offered by SOA abstractions and the easily customizable first level business process flows enabled by BPM. And, they can make this application available in a SaaS model. If there were to be a BPM+SOA based application platform made available by any of the BPM/middleware vendors, then it is only natural to expect this to also support declarative multi-tenancy.

Multi-tenancy enabled BPM/SOA-platform? Does it sound far-fetched? Not really… Last my month my class (Internals of Middleware Systems course at IIIT-H) built a multi-tenant SOA platform as the course project. They demo’d the solution at the end of the course. It had full working declarative multi-tenancy built into the SOA platform they built, and it included a business process (orchestration) engine based on Camel and a web services platform, registry and repository, and declarative multi-tenancy. (Phew! J ). I was pleasantly surprised. They actually got the whole solution working (albeit in a basic POC mode). So technically, a PaaS for Multi-tenant BPM/SOA based applications is definitely feasible. Sometime, hopefully soon, there could be commercial offerings in the market.  

SOA. It’s back… but it’s got more sparkle.

I’ve been working in high-tech marketing roles for over 20 years now and every time some new marketing collateral comes across my desk and “I get it”, I get excited. As a matter of fact, my first job in a high tech company was as a marketing assistant to an R&D group at BBN Systems and Technologies. They were introducing a very innovative product called BBN Slate which was a multi-media editor for Unix. Because my previous jobs involved word processing (Wang), spreadsheet analysis (Lotus), and creating pretty charts (DEC/VMS – yes, really), “I got it” and I was committed to championing it. I loved every minute of it. Well, in 2007 I was tasked to optimize the Progress Software website for SOA. We already had great traction for the enterprise service bus (ESB), but not specifically for service-oriented architecture (SOA). Well, “I got it”, got going and started optimizing for SOA Infrastructure – a popular long tail term at the time - less than two months later. As a matter of fact, this blog was once the SOA Infrastructure blog.

In January of 2009, Anne Thomas Manes of the Burton group published the blog post SOA is Dead; Long Live Services. The industry had a lot of fun with that. Now, I don’t know if it was a coincidence, but suddenly Progress stopped talking about SOA and they asked me to change the name of this blog. I was sad, I admit it.

This responsive business integration diagram was taken from a presentation by Hub Vandervoort, CTO, Enterprise Infrastructure. Listen to the archive.

Well yesterday I saw some sparkle. We announced our new Responsive Business Integration (RBI) suite. Truth be told, I’ve known about it for a few months because I had to post the content and work on my SEO plan. I know it’s not nice to play favorites, but I was delighted to see my favorite Progress technology/products back in the game – Actional, DataXtend SI and Sonic. And, I’ve concluded that the RBI suite is SOA pimped up! It’s taking the existing service and application foundation most enterprises already have (or are building) and it’s enhancing it with semantics, policy management and mediation. The Progress RBI suite is going to allow businesses to decouple systems which will give them improved visibility, agility and the ability to change.

Read more about Progress Responsive Business Integration. And check out a great presentation by Progress customer Southern Union Company. They built their enterprise integration strategy around RBI and didn't even know it.

For the lack of a better term, do you think RBI it is our next-generation SOA? Give us your comments!

Belgacom and the Case for Business-oriented integration in Communications Providers

It is no secret that the telecommunications industry has been exploring various ways to tackle issues such as declining ARPU (average revenue per user) and increasing customer churn over the last five years. The keys to proactively addressing these issues are agility and responsiveness. For example, responsiveness around customer service – to make customers feel they have a personalized valuable service – which reduces churn; and agility -- around launching new and compelling services rapidly – to increase ARPU.

Despite this quest for the Holy Grail, many communications providers have failed to lay sufficient foundations. While there may be some useful technologies deployed in an attempt to provide an agile and responsive integration platform – these technologies have often failed to deliver what is needed by the business. SOA is a prime case in point. While SOA technology has been successful in many ways, it has also led to a lot of disappointments. Often the business was sold on the promise that SOA would make operations more agile and responsive.  However, what resulted was technology for technologists that looked like plumbing and was daunting and too generic to the business.

Business people want solutions that can deliver visibility to problems and opportunities – such as key business events (e.g., an opportunity to sell a new service, based on context or location) or process failures (e.g. persistent dropped calls for an important customer) – so that problems can be responded to quickly and opportunities taken. The business also wants solutions that can enforce business-level policies and service-level agreements, as well as solutions that can interconnect services at a “semantic level” – not just plumb data together. In other words – the business wants to deal in business-level concepts, and be assured that the underlying complexity will be managed by the system.

Today’s announcement that Belgium operator Belgacom is transforming its business and IT integration programme (more information here) represents a huge step forward for the telecommunications industry. Belgacom is clearly focused around being more responsive to the needs of their customers in order to tackle issues such as churn through improved integration. By selecting the right business integration foundation to support their IT strategy, Belgacom has taken a critical step forward in a long-term strategy to become more operationally responsive to their customers.

Due to the nature of the economic times we live in, it is vital that the telecommunications industry as a whole ensures that they have the best possible integration technology in place. Only then will operators be able to enhance their customer experience management offerings to attract and retain their business customers, differentiate their offerings, and lower their service costs.

 

When it comes to Integration, Contracts Make all the Difference.

It may seem odd to talk about contracts and SOA in the same sentence, but without them experienced enterprise architects and integration developers understand the negative consequences that will ripple through the business.

A service-oriented architecture (SOA) requires establishing contracts between its participants. The first or most basic SOA contract provision concerns what formats and protocols are used. When two service participants, a provider and a consumer, establish a contract, it must start out with some protocol and format artifact (or transport and data-level semantic), such as an XSD and the associated WSDL describing the interface between that consumer and producer. These decisions establish the beginnings of interoperability, specifically how the first-level pin-outs get wired together.

Beyond this basic level, IT professionals tend to think about contracts in two broad areas: the service-level agreement (SLA) and security. For IT, an SLA usually specifies scale, response time, and availability: for example, handling 10,000 requests per second with a response time of less than 500 milliseconds, and availability to four 9s, or 99.99 percent uptime. From a security standpoint, a contract covers four or five areas.

In installment #7 of the Enterprise Integration Whiteboard Series, Hub Vandervoort delves into the sixth point of mediation - Quality of Service (QoS) and Quality of Privacy/Protection. But rather than providing a comprehensive account of the idea of QoS and QoP, the video podcast and technical paper offer a high-level overview of some capabilities within Sonic ESB by itself and in association with Actional, which is largely built into the ESB infrastructure, and how those come together to create the foundation of QoS\QoP—trust and commitment —required for effective contracts.

---

Check out all of the Enterprise Integration Whiteboard Series white papers and videos here!

Transformational IT change at British Airways

Gordon Penfold, Chief Technology Officer, at British Airways, started off by telling us that not only is the Boeing 747 40 years old this year, but so is the IT that supports the 747. Having been early to the world of real-time processes, the technology is now facing end of life at the end of 2010, and it's time for a major change.

Gordon shared with the audience at the Progress Software Summit (#progressswsummit) that to get to a SOA-based infrastructure that will deliver the vision of a single real-time infrastructure linking retail, customer, operational and corporate data and processes has required significant technical and strategic change. BA needs to use their enterprise architecture to improve quality and minimise cost, directly affecting BA's objective of being a global airline of the highest quality and providing exceptional customer service. And the term "global" isn't some platitude in this case as BA has operations and staff distributed all over the world. As Gordon said, BA is a peripatetic company.

BA's ‘common architecture’ will ensure consistent implementation, enabling BA to run existing services and implement new ones effectively. SOA is Gordon’s preferred option. The aim is to reduce complexity and increase agility, introducing a plug-and-play capability that can also manage ‘heritage’ applications, created by the industry and service providers – all to support over 15 million transactions a day.

Progress is supporting the change at BA with its Sonic, Actional and DXSI products, and is working with Gordon’s team on a proof-of-concept for Savvion and on how Apama can support with interactions with partners and other airlines. At the half-way point in the implementation, BA is now live with its Progress powered Service Integration Platform, which links the business to IT processes in a controlled way.

Gordon made some kind remarks on working with Progress - the best-in-class products and the added value provided by the Progress people who worked at BA on site. All great to hear from a business with very real mission critical requirements.

Are you a sitting duck or one that will respond immediately to threats?

While many organisations are being ‘cautiously optimistic’ about what the future holds, the realities of today’s tough business environment could leave them as sitting ducks, according to Rick Reidy, CEO at Progress Software. They might take consolation that they’re in the same pond, but when interest rates in Japan hit near-zero, banks continue to fail and mistakes can lead to a ‘flash crash’, the pond is not a safe place to be. Businesses may have money, but fear and uncertainty is holding back decision-making – we await further regulation and want to know the consequences of recent government changes.

 
Listening to Rick’s keynote at our UK business summit (#progresswsummit, if you want to follow on twitter), in the impressive surrounding of Chelsea Football Club’s ground, London, it seems most of the audience agrees – it’s not good enough to sit around and wait to see if growth returns, and you cannot grow simply by cutting costs. You have to take control of your own ‘growth agenda’, as Rick put it. Businesses that want to survive the next five years need better visibility, through putting processes in place that enable them to react quickly to meet customer demands, adapt to market changes and take advantage of new opportunities. As Rick has advised, businesses need to act on up to the minute information so that leaders can make decisions based on foresight, not hindsight.
 
If you’re a regular reader of this blog you’ll already know that we call this ‘operational responsiveness’: the ability to sense and respond to customer and market changes so that organisations can move quickly to meet challenges and take advantage of new opportunities. 
 
Rick has talked about what this means in the airline industry: the notion of irregular operations has become a weekly reality as companies face intense market pressure, striking staff and disruption from natural phenomenon. ‘Swivel chair’ communication between operational areas is no longer good enough. To react quickly enough, they need responsive processes in place that can help them maintain services and inform customers, almost as-it-happens. If they don’t, they will face massive fines, lost custom and damaged reputation – risks no company can afford at present.
 
We’ll be hearing more from Gordon Penfold, CTO at British Airways, about their approach to becoming operationally responsive to meet the challenges of today and tomorrow. Watch this space for my take on his talk…

 

Stamford Bridge, here we come

Tomorrow sees Progress Software taking over Stamford Bridge, home ground to the world-famous Chelsea Football Club. We’re not just there to check out the players’ dressing rooms – we are being joined by James Caan, of Dragons' Den fame, as well as the great and the good of the UK business community, to discuss how businesses can start to make decisions based on foresight, not hindsight, in their operations.

Gordon Penfold, Chief Technology Officer at British Airways, will be sharing his insight on ‘operational foresight’, revealing how the organization has set itself up to better deal with the irregular operations that have become a fact of life in the last year. And Mike Gualtieri, senior analyst at Forrester Research, will be sharing his views on where the next wave of truly responsive business management is coming from, and which trends to watch for. And Progress' own Chief Executive Officer, Rick Reidy, will be giving a keynote too.

I'll be there, speaking in one session but also blogging and tweeting from the event. So watch this space for the latest updates.

For those of you attending, I look forward to seeing you there.

www.progresssoftwaresummit.com

 

Who's Job is it (to Sequence and Process Errors) Anyway?

It is a common software and integration architectural principle that the more dependencies built into a service, the less reusable that service becomes.  So then, why do some many vendors and enterprises continually create tightly coupled services and therefore lose re-usability?

The answer likely has something to do with mediation, more specifically sequencing and error recovery mediation. Sequencing and Error Recovery mediation are the two topics covered in a new webcast and technical paper posted today on Progress.com.  Both discuss why and how you should delegate sequencing and error recovery completely away from services, how this makes services unaware of what order they’re called in and the order the processes execute in, and ultimately how this makes services maximally reusable and your business more operationally responsive. 

The paper also explains how the Sonic ESB is designed to perform sequencing and, with multiple output paths on each endpoint, enable error recovery processes that are separate from the “happy” path. Just as important, Sonic offers the unique benefit of enabling you to orchestrate services using BEPL or itineraries—whichever is optimal for your process scenario.

Be sure to watch the Sequencing and Error-Recovery webcast and download the technical brief to learn more about the Seven Points of Mediation and the importance of each in relation to supporting a truly agile and responsive business application infrastructure.

---

Check out all of the Enterprise Integration Whiteboard Series white papers and videos here!

The Seven Points of an ESB

When discussing an ESB, many people keep it simple, sticking to the generalities of SOA and sharing services to build composite business applications.  Certainly, these are incredibly important benefits of an ESB but what do these dicussions really mean at the architecture level? 

Another word for integration when it comes to ESBs is mediation.  After all, that is truly what an ESB does - mediates the differences between application components (services) that were not intended to work together.  So then, in context of mediation, how should an ESB be examined?  Here at Progress, we view there to be seven points of mediation that serve as a set of key principles that apply to any integration infrastructure. They are critical because adherence to all seven is necessary to achieve the ultimate goals of SOA: reuse and agility.

Any one point that is not mediated becomes a point of brittleness. Put another way, interoperability needs to be tested along seven key points, which, briefly, are:

7 POINTS OF MEDIATION
Transport/Protocol
Location/Destination
Semantic/Format
Sequencing
Error Recovery
Quality of Service/Quality of Protection
Interaction Model

To help examine these points in-depth Progress has created a series of technical briefs (white papers).  These papers use the 'Seven Points of Mediation' as a way of describing how an ESB is, in fact, a comprehensive infrastructure onto which services can delegate these points. The overriding idea is that if a service delegates each and every point of mediation, it becomes more reusable in more contexts. These papers explain how Sonic ESB enables a service to free itself of these considerations, ultimately, so that it can provide the agility that SOA promises.

Be sure to watch the Transport, Location, and Semantics podcast and download the technical brief to learn more about the Seven Points of Mediation and the importance of each in relation to supporting a truly agile and responsive business application infrastructure.

---

Check out all of the Enterprise Integration Whiteboard Series white papers and videos here!

How Being Complex Makes Transaction Assurance Simpler

I have been seeing an increasing amount on interest in the marriage between Business Transaction Management (BTM) and Complex Event Processing (CEP). On July 29^th Dr Dobbs Journal published an article called Complex Event Processing: IT Liberator or Over-Engineering Hell? This article was about the synergy of BTM and CEP (although I felt it was rather biased towards one company). Also, last week Jean Pierre Garbani at Forrester published this blog in which he discussed the evolution towards BTM and CEP working together.

Business Transaction Management is a rapidly growing area of Application Performance Management (APM). BTM enables users to look into the transaction flows within their business and ensure everything is running as expected. BTM enables problems in transaction flows to be discovered – such as a bottleneck in an important business process. The really appealing aspect of BTM is it can do this without the need to change the applications in the business; BTM can “discover the transaction flows” by tapping non-intrusively into the flows going through application servers, middleware buses, business process management systems and other systems within the environment. Over time, BTM can build up a picture of the environment’s business flows, look inside the transactions and flag up immediately problems that can really hurt the business.  Thus BTM works really well in legacy environments – not just modern SOA environments. And of course it appeals to business executives and operations users – not just IT users.

Complex Event Processing is the ability to correlate events flowing through a business  - to identify patterns in real-time. These patterns might indicate opportunities and/or threats to the business that have just happened, are in the process of happening or are likely to happen right now. Events are occurrences in the business, such as stock market quotes in trading, call data records being generated in communications or packages changing location in logistics. An example of a real-time opportunity is a trading “statistical arbitrage” opportunity – to sell one instrument and buy another at a micro profit; another is the ability to upsell something to a customer who has just purchased an item on their credit card – based on their spending and buying patterns, their location and context. Threats to be detected include risk exceeding a certain key level in a bank or gaming fraud occurring in a casino. This kind of business level visibility and immediate response also appeals to business users as well as IT.

Listening to the descriptions of BTM and CEP, does it sound like there is a little overlap? Well there is some. What BTM is really good at is non-intrusively discovering process endpoints and the events they exchange – and then tracking these events. What CEP is really good at is correlating complex real-time business events in real-time, including arbitrary user-defined patterns, which can evolve over time as the business evolves. So it makes perfect sense to put these capabilities of BTM and CEP together. For BTM this strengthens the real-time correlation and pattern detection capabilities. For CEP this enables discovery of services without the need to do expensive and time-consuming instrumentation of the environment.

At Progress we have two leading products in the BTM and CEP categories: Actional and Apama. We believe that BTM and CEP capabilities are converging for certain business use cases, so as part of our Responsive Process Management (RPM) suite we now provide seamless integration between these capabilities. Of course RPM does much more than that. More on that later!

Dynamic Routing Architecture - Strength Comes from the Core

This week's deep dive into the gears of Enterprise Integration take us to the Dynamic Routing Architecture or DRA.  SonicMQ's Dynamic Routing Architecture (DRA) technology allows the delivery of messages between applications regardless of the cluster that the application is connected to. In case of a connection failure, (e.g. between regional offices), DRA will route messages via alternative operational paths, and facilitate expansion without incurring significant administrative overhead. Clusters may connect to other clusters as needed, creating highly distributed deployments across loosely-coupled locations.

As mentioned in the first series brief, “Messaging Architecture,” every Sonic broker has a set of acceptors that define it’s connectivity to the rest of your messaging architecture. These can play three roles: as a client link, as an inter-broker link (in a cluster) and as a DRA link enabling two clusters to communicate across a WAN. In addition, because Sonic acceptors can handle multiple protocols, the DRA link can work over other various types of connections as well.

But, DRA goes beyond the Sonic clustering architecture. It optimizes communications in many complex, distributed topologies while providing administrative transparency, or single-entry administration. As a result, DRA enables easier scaling and greater agility in changing the IT environment to meet changing business needs and market
conditions.

Be sure to watch the DRA video podcast and download the technical brief to learn more about how DRA provides unmatched high-availability and delivers transparency and administrative efficiencies that truly ripple to both the bottom and top-line of business activity.

---

The forth brief and whiteboard video in the Enterprise Integration Whiteboard Series, Dynamic Routing Architecture,  explains how the Progress enterprise integration solutions work. This brief focuses on the Progress® Sonic® Dynamic Routing Architecture® (DRA), its purpose and capabilities over and above the Sonic clustering architecture as well as some special use cases..

Integration & Performance - It's all about the Clusters

As we continue our series on Enterprise Integration as a foundational element for Operational Responsiveness we venture into the world of Performance, Scalability and Reliability.

These characteristics are vital to distributed networks, and in large part, depend on transparency in the cluster to be fully realized. A cluster is a number of independent machines that behave as though they were one single logical entity. The rationale for clustering is that this single logical entity will easily scale and provide uniform performance: if one member fails or goes offline, messaging can continue. There are three dimensions of transparency that can be examined to determine the efficiency and effectiveness of an enterprise messaging solution in delivering this vision. These are administrative transparency, functional transparency, and high-availability and load-balancing transparency.

Check out the complete discussion on this topic by viewing the video podcast whiteboard session or downloading the transcript as a technical brief.

The second brief and whiteboard video in the Enterprise Integration Whiteboard Series, Clusters and Technologies, examines how the Progress enterprise integration solutions work. This brief focuses on administrative and functional transparency in the cluster architecture of Progress® Sonic® versus its competitors, showing why Sonic provides greater operational responsiveness at lower cost.

Shipping logistics with event processing

On Friday last week I visited Progress customer, Royal Dirkzwager, in the Netherlands. It’s nice to be able to talk about a customer publically - Dirkzwager have been a generous public reference for some time. This was my first visit to their head office in Maassluis, near Rotterdam, and it gave me a new insight into their business. Dirkzwager’s offices are right on the main entrance to the port of Rotterdam and it was great to be in their board room and watch the container ships move by as Paul Wieland, head of IT, took me through their business and what they are using Progress’ products for.

Dirkzwager is in the business of supplying information about shipping movements to the maritime industry. Its customers include the Port of Rotterdam, shipping companies and the logistics companies involved in supporting the ships and handling the goods. Dirkzwager currently supplies information on shipping movements at sea and in and out of ports from Le Havre in France to Denmark. Rotterdam is its epicentre - the biggest port in Europe and one of the biggest in the world, handling around 30,000 ships per year.  

Dirkzwager are users of the Sonic Enterprise Eervice Bus (ESB) and the Apama event processing platform. Sonic is used for delivering information to customers reliably and Apama is used for processing and analyzing the events reporting the positions of ships, up to several thousand per second. Live data is augmented with data from a reference database on tonnage, flag, crew, and lots of other information. Applications range from simple to more complex. One example is: “alert when a ship crosses this line”, to give an official port entry time (important for calculating harbour fees). A more complex example is the calculation of an actual time of arrival, using course, speed, weather conditions and historical information about the ship’s movements. This latter application can bring very significant benefits: on average, 50 companies are involved servicing a ship when it’s in port, from loading or unloading goods to servicing the radar. If these companies can receive more accurate information about a ship’s arrival time, they can optimize their operations resulting in the whole supply chain becoming more efficient – capacity is increased and costs are lowered. Paul gave some insight too into how Dirkzwager had become more efficient by using Apama to automate tasks that were previously done manually and in the process saving substantial amounts of money (the details of which, unfortunately, I can’t share here).

Dirkzwager’s industry is changing. Currently, most ships identify themselves by a VHF-radio system. This is shore based and has a range of approximately 60km. This is changing to a satellite based system which will give more continual and accurate reporting and also give simpler access to ship movements anywhere in the world (approximately 80,000 ships are in transit at any one time worldwide). This gives business expansion opportunities and also challenges when dealing with the new quantities of data that available. Paul Wieland clearly believes that complex event processing (CEP) is an ideal way for Dirkzwager to analyze this data and provide the monitoring of logistics and supply chain processes that they support for customers. Paul’s obviously a visionary – the room was buzzing with ideas. Now his team is experienced with Apama, Paul reported that people’s approach to problem solving had changed – they were thinking naturally about things in an event based way, both architecturally and in terms of data processing.

One might not necessarily think of shipping logistics as being the most innovative of industries, but Dirkzwager has always been at the forefront of technological innovation. Shipping was, and continues to be, vital to the Dutch economy. When the company was founded, in 1872, people used to stand at the opening of the port with binoculars. As a ship was sighted and recognized, someone would mount a horse and rush back to the port to report. Dirkzwager had the first commercial telephone line in the Netherlands. Paul showed me a room where some of the computing and communications equipment used previously by Dirkzwager is stored – examples include a megaphone, semaphore flags, telephones, telex machines and a mini computer. It was a mini museum for the communications industry. The use of event processing software is simply another step in this historical evolution.

Integration and the Responsive Enterprise

Over the last year you’ve heard a lot about Operational Responsiveness from Progress and what it means to and for your business - the ability to:

• Respond to changing business conditions as they occur;
• Capitalize on more opportunities, to drive greater efficiencies;
• Make real-time course corrections;
• Reduce risk.

Every business and enterprise wants to be operationally responsive, but getting there is the challenge. Certainly, our recently announced Progress® Responsive Process Management (RPM) suite makes this challenge easier by enabling business users to gain visibility into critical processes, immediately respond to events, and continuously improve business performance without disrupting existing infrastructure. But what about that infrastructure? What role does that play in responsive process management and Operational Responsiveness?

We believe it plays a foundational role and that is why we’ve created a completely new set of educational and informative videos, whiteboard sessions, podcasts and technical papers that services and application platform architectures in the context of Operational Responsiveness.

Beginning with four podcasts and technical papers on messaging, the Enterprise Integration Whiteboard Series will explore services integration, data connectivity, transformation and life cycles, legacy modernization, and management as core, interdependent components of every modern enterprise application integration infrastructure. In total the series will consist of 10 topics with a new topic posted every two weeks through September 2010.

The first brief and whiteboard video, Messaging Architecture, examines the four basic components of the Progress® Sonic messaging system --brokers, acceptors, clusters, and the underlying protocols—to show how they provide not only robust integration, but business and IT benefits as well.

Read the paper and watch the video and let us know what you think by commenting to this post. Share your enterprise integration experiences.

The Industry’s 1st and Best ESB Just Got Better

On Monday we announced the release of Progress® Sonic® 8.0. Sonic 8.0 enhances existing SOA infrastructure and enterprise integration by introducing the power and flexibility of an open services and integration standards development model. It’s ideal for multi-site operations management and deployment because it is backed by the industry’s only true, 100% up-time enterprise messaging environment. Here is what current and new users can expect from Sonic 8.0:

• Open services and integration standards
• Distributed Operations Management
• Continuously Available Business Systems
• Real-time Management & Security
• Semantic Data Transformation
• Legacy and Mainframe Integration

Learn more about Sonic 8.0 >
Take Sonic 8.0 for a test drive >

SOA Upgrade to British Airways

British Airways (BA) is turning to service-oriented architecture (SOA) and Progress Software to connect over 600 different electronic systems and processes involved in getting BA passengers in the air.

BA has more than 250 key applications distributed over 300 locations around the globe, which explains why they chose Progress. From an integration perspective, Progress® Sonic ESB® excels in those scenarios that require the integration and management of hundreds or even thousands of systems. One Progress customer was able to deploy its integration backbone out to 25 locations a day (and can update them in a fraction of that time).

One can only guess how many of those 250 systems are touched when you travel BA. Everything from choosing your seat assignment to charging your credit card (once only please), to selecting a vegan meal is managed via systems. And let's hope those systems succeed in keeping track of your luggage.

The real-time data synchronization of Progress® DataXtend® Semantic Integrator (SI) allows BA to significantly improves information quality while reducing costs associated with data replication. And Progress® Actional® SOA Management provides BA with the visibility they need to make sure your reservation gets booked and you make it to your destination in a timely manner. Weather permitting, of course. ;)

Thanks to SOA, BA is able to extend the features of its e-commerce site right through to its airports, allowing greater self-service functionality and 'plug and play' capability to over 25,000 users.

"Moving this to a highly automated environment is a challenge, but SOA quickly proved itself to be the right approach to achieving our goal of a fully agile environment."

So the next time you take your family to London (or Disney - that's my family's destination of choice at the moment), think about how many transactions went right along the way, automatically.

I love when technology makes a tangible difference. Pretty cool stuff.

British Airways Selects Progress SOA to Upgrade the Travel Experience

British Airways announced yesterday that they had selected Progress Software for a revolutionary project that is integrating more than 600 different electronic systems and processes which are involved in getting BA passengers in the air.  This new highly automated infrastructure will bring increased agility to the airline. Rollouts will be easier, and associated cost and time will be reduced.

As is often the case with these kinds of announcements, however, it wasn’t really news to an “insider” like me.  I had visited BA earlier in the year and met with numerous people in the organization from the CTO to Architects and Developers on a number of the projects where they are implementing our technologies.  The thing that was most gratifying to me in those meetings wasn’t the scope of this cutting edge project or even that they were implementing using nearly our entire portfolio of SOA infrastructure products, namely Progress® Sonic® ESB, Progress® Actional® for SOA Management and Progress® DataXtend® Semantic Integrator (SI).  It was that, at every level in the organization, they expressed how pleased they were in the selection of Progress.  

At the senior executive level, they were discussing the partnership that they had developed with Progress and the vision we had provided to address real business challenges, for example, improving customer service by extending the features of BA’s e-commerce website into airports.  At the architecture level, there was a great sense of partnership on how the products we provided could be brought together in a coherent SOA based approach to their infrastructure that increases agility and operational responsiveness.  The developers were just happy that it really was “best of breed” technology that “just works”.  

At a time when most airlines are cutting back, it’s great to see British Airways taking advantage of what SOA has to offer and at every level of the organization they can count on Progress as a trusted partner to help.

Have you deployed your NGMP yet?

WIN has! After doing a review of their technology, WIN and their technology partner, Tech Mahindra, selected Progress® Sonic® ESB as their Next Generation Messaging Platform (NGMP). Because rapid change in the mobile sector is driving consumer demand for innovative multimedia and high-bandwidth services, they needed to look at a service-based infrastructure (or SOA) for its new platform. Here’s a quote from our recent press release:

“As mobile services evolve into widgets, applications and mobile video on-demand, much of the integration work we do to meet our customers’ service requirements is custom-built,” Graham Rivers, CEO at WIN, explained. “But to create an efficient and agile model that allows providers to roll out new services quickly, service re-use is key. SOA brings that flexibility to our platform.”

For many companies today, SOA is a significant part of improving infrastructure response. But superior operational responsiveness and SOA deployment require innovative technology to be effective. WIN knew that in order to remain competitive and deliver the best solutions and services to their customers, including Vodafone, T-Mobile, and Sony Ericsson, their NGMP needed to deliver high performance and reliable communications. Sonic ESB gives WIN the power they need to meet customer demands and deploy an event-driven architecture that will scale with technology and innovation.

Alphameric Beats the Odds with Progress Software

It’s always great when a company is willing to talk publicly about your products and services, even when the public statement incorporates a bad pun. In this case, Alphameric Solutions Ltd., the leading technology provider to the bookmaking marketplace in the UK and Ireland, wasn’t holding their cards close to their chest when they decided to collaborate with us on a press release. Alphameric selected the Progress® Sonic® ESB to revolutionize the way they handle content and messages across their network because they couldn’t roll the dice with unreliable infrastructure. Sonic’s continuous availability architecture made this a sure bet.

With new virtual games such as poker and fantasy football being released every day, Alphameric was struggling to manually keep all the feeds and databases up to date. The new SOA-based approach makes accomplishing those tasks a lead pipe lock. Alphameric can now change data more quickly, easily bring new feeds online, without gambling with the accuracy through automation.

Using Progress, Alphameric is achieving operational responsiveness, increasing revenue and improving customer service to finish in the money. You can’t beat that. I’d add that this decision puts them clearly ahead of the game, but Matt Smith, our Senior Enterprise Architect quoted in the press release, beat me to the finish on that one.

OK, I think I got that out of my system now. Sorry about that...

Smart Integration Infrastructure for Insurance Industry

Those of us who have been entrenched in middleware and SOA infrastructure technologies over the years know the importance of having a smart integration infrastructure. Well, today we released a press release announcing that West Bend Mutual Insurance, a property and casualty insurance carrier, chose Progress Sonic ESB and Progress Actional as core applications for their service-oriented architecture. West Bend Mutual Insurance will use Sonic ESB and Actional to supplement its existing policy administration system, so its insurance agents can conduct business more easily and effectively via a single integrated portal. The insurance portal will also be a critical tool to help them improve their customer retention and acquisition. The best part is that West Bend Mutual will finally be able to enjoy operational responsiveness by being able to respond to changing conditions and react more quickly to business opportunities.

For industries like insurance that need to constantly offer new products and services to remain competitive, creating an infrastructure that is agile and scalable, and one that delivers end-to-end visibility of back-end systems, is essential. SOA is a great fit. Read the complete release.

Book Reveals How to Create SOA the Right Way

The book, An Implementor’s Guide to Service Oriented Architecture: Getting it Right, explores SOA related topics ranging from design services, registries and repositories, to runtime management, and organizing for success. The book includes insight offered by AmberPoint, BearingPoint, Composite Software, MomentumSI, and Progress Software. Purchase your copy from Amazon.com.

If you are interested in a preview of the book, download Chapter 4 entitled, Enterprise Service Buses. This chapter was written by Hub Vandervoort, CTO, Progress Software. In this chapter, Hub talks about the ESB, a messaging-based communications backbone for SOA infrastructure. He also shares his collective experience of working with over 300 ESB end-users, and summarizes the styles and applications of ESB technology. More importantly, the secret to ESB success—captured in the synopsis he has dubbed the "seven points of mediation"—is revealed to illuminate why all ESBs are not created equal, and provides practical advice about how to be successful using an ESB in your SOA initiatives.

Download Chapter 4 of SOA: Getting It Right >
Podcast Seven Points of Mediation >

Don't Forget ESB-CON 8. It starts today.

Thursday, Aug 20th
10 am PT // 1 pm ET // 1700 GMT
Register now: http://bit.ly/h6fO6

Join and listen in as 3 of the industry's top CTO's talk about the ESB, SOA and software integration. Presenters include Jerry Cuomo, IBM Fellow, Vice President, CTO WebSphere, Ross Altman, Sun Microsystems CTO, Software Infrastructure, and Hub Vandervoort - Progress Software CTO, SOA Infrastructure Products.

Learn more >

Secret No. 2 - The Myth of Five Nines

Lets continue to pull back the covers on highly available integration infrastructure.

Listen now to Part 2 of the Five Dirty Little Secrets of Highly Available Integration Infrastructure podcast series: The Myth of Five Nines.

Presented by Hub Vandervoort, CTO, and Ken Rugg, VP and General Manager, Integration Infrastructure, Progress Software, this is the second of five new interview-style podcasts that reveal the software industry’s five "dirty little secrets" or misconceptions of a so-called highly available integration infrastructure.

Three minutes of downtime may not seem detrimental now but if that failure occurs during peak transaction times, it will result in lost revenue and poor customer service. In this podcast, Hub and Ken present ideas on how to deliver a highly available enterprise infrastructure.

> Secret No. 2 - The Myth of Five Nines

Tune in next time for Secret No. 3 - Recovery Time.

Simple SOA. Not-so-simple SOA.

Open Source SOA has arrived! On a single day we have one platform announce that they have simplified basic SOA, and another has announced that SOA is never simple - and if it is simple, just use web services. The question is... is there really a simple SOA and a not-so-simple SOA?

As I look at it, there is a very fine line between simple SOA and the more complex ones that require an enterprise service bus (ESB). Lines are blurred today. Now, ESB itself can be in a single container or more massively distributed ESBs with a strong messaging backbone (like Sonic ESB). But messaging backbone or not is more about the underlying integration infrastructure. So, what does it mean for the application itself? Is the model/paradigm different for the two cases? This is what gets lost out in the melee - the application models and the underlying infrastructure are quite decoupled. From an application standpoint many of the ESB mediation requirements may always be needed functionally. Can one access services without getting the data in the right format? To get it in the right format, won't we need data transformation? And security is a given in all cases. Sometimes one can look at business rules based routing to services. All of these regardless of whether it is a simple SOA or not-so-simple (more distributed multi-data-center) SOA. 

This (common treatment of all SOA use cases regardless of complexity) is very evident with the way our open source platform, FUSE, works because it has an embeddable transport layer. One could use the containers with or without Active MQ. But with or without distribution, the same functionality is available. Simple SOA? Or not?

Actional for IONA Orbix & DB

I've been on the road since the end of May and I have also moved, so needless to say, I'm behind on my blogging and tweeting responsibilities. I mean, you know you're busy when you don't have time to tweet!

My colleagues have been out there though, doing some great things. We've got some early trials going on with Actional being evaluated at a few IONA Orbix (CORBA) customers. Since the team has tweeted this, I thought I'd blog about it!

As Frank Lynch said, "CORBA users will be mighty pleased to have Actional visibility, an no performance penalty to boot." Yep, couldn't a' said it better myself.

Why is Actional/Orbix integration important?

1. It demonstrates a key differentiator between Actional and all other solutions out there... we're not designed specifically for web services. Never were. Extending Actional beyond web services started in late 2003, and continues with the work we're doing with the Orbix team.
   
2. CORBA customers are "interesting" in that they are typical enterprise class deployments. They have high message rates, are deployed in critical infrastructure, and are sophisticated deployments due to their maturity. Right in Actional's sweet spot.
   
3. In this down economy, Progress has a key advantage over our smaller competitors, so much so that it's hard to actually view these customers as competitors. Where these small guys have to go and develop new customer relationships, we can continue to delight our existing customer base (in over 100 countries) with innovative integrations between the products in the Progress portfolio. This continued innovation enables us to drive market adoption while delivering products that meet real enterprise customer needs.

On that last point, I've got a bit of a new role here. Or, better said, my role is being further formalized as Actional Product Evangelist. I'm very pleased to have the responsibility for socially-marketing some of the new integrations we are delivering to market. In particular, those integrations between products in the Progress portfolio and Actional, and between Actional and some partners. I'm hoping I can have a real impact with this formalization to my role, as well as some fun introducing Actional to some new technologies.

That said, my initial focus is going to be on IONA's Orbix, Progress OpenEdge, and Sun Glassfish. Glassfish support has been released, and both IONA and OpenEdge are in early trials (pre-beta). As I get organized around communicating these solutions, feel free to drop me a line with questions if you are interested in seeing what we've got!

Any existing Orbix customers interested in the Actional integration should contact your sales rep... or me. You're required to have Orbix 6 or later for Java (for now... we're working on the C++ and Java/C++ for Orbix 3, but they're not ready to trial yet).

PS Why not follow Maneesh Sahu (Sr. Solution Architect, Partners), Dion Picco (Engineering) , Frank Lynch (Sr. Solution Architect, East), or Marcelo Jabali (Sr. Solution Architect, West)?

SOA Infrastructure - Back to Future, No. 2

Is anyone talking about the enterprise service bus (ESB) anymore? My Google Alerts are slow and my Google Adwords program isn't performing. Could it be that everyone already has one? Is it assumed that everyone has one? WARNING: shameless promotion...

Did you know that Progress Software introduced the industry's first ESB? Actually, independent research firm, Forrester Research, Inc., named Progress® Sonic® ESB as a leader in the enterprise service bus (ESB) market in "The Forrester Wave™: Enterprise Service Buses, Q1 2009" report. That seems like a big deal to me but yet I continue to have problems finding someone to blog or talk about it. Thankfully there's Hub Vandervoort, CTO, Progress Software. If you haven't had the opportunity to hear him speak, you are missing out. He's not only smart, he's personable, engaging, and always leaves me wanting to learn more.

This week I'd like to share a video that he did over a year ago. In this 4 minute video, Hub talks about what an ESB is, why you should deploy an ESB, and he also shares what makes the Sonic ESB unique.

Interested in more? Read Chapter 4 of Service Oriented Architecture: Getting IT Done Right. Chapter 4, entitled Enterprise Service Buses, is authored by Hub. In this chapter Hub shares his collective experience of working with over 300 ESB end-users, and summarizes the styles and applications of ESB technology.

Enjoy!

 

SOA Infrastructure - Back to Future, No. 1

The New SOA Maturity Model

Originally introduced in 2005, the SOA Maturity Model white paper and the Quick Reference diagram were co-authored by business partners Systinet, Amberpoint, BearingPoint and Sonic Software. During a 2005 live webinar an audience poll noted that 40% of the webinar participants were “currently developing a SOA project,” and 37% noted that they would “begin a SOA project within the year”. That same year, Gartner, Inc. predicted that by 2008, "SOA will provide the basis for 80 percent of new development projects." (1) But over the past few years, there has been much skepticism about the ROI and business value of SOA. That doesn't mean that SOA is dead or that companies should abandon their SOA initiatives, it means that it might be worth stepping back to review your original goals and best practices, and move forward to seek the right solutions that will help streamline and cut costs.

The players have changed—Systinet was acquired by HP, Sonic Software was brought back under the Progress Software umbrella, and Progress Software acquired Actional whose product offerings align with Amberpoint—but the goals of any SOA technology provider or practitioner are the same; software reuse, agility and the improved alignment of business and IT. (I like Miko Matsumura’s 2005 post, The Rise of the Software Architect in an SOA World.)

With that, I’d like share the New SOA Maturity Model white paper and quick reference diagram which were updated in 2007. The tone may have changed slightly but it still provides a framework for discussion between IT and business users about the applicability and benefits of SOA in an organization across five levels of SOA maturity, including: Functionality, Cost Effectiveness, Responsiveness of Business and Collaborative Services, Transformation, and Optimization. The benefit of these resources also remains the same… to not only to provide a means for organizations to benchmark current implementations, but to offer a source of inspiration as IT leaders successfully advance the value of SOA within their organizations.

Enjoy!

White Paper: The New SOA Maturity Model >

Quick Reference: The New SOA Maturity Model >

1 Hayward, S. "Positions 2005: Service-Oriented Architecture Adds Flexibility to Business Processes," Gartner, Inc. Feb. 2005.

Welcoming Scottish Widows to the Family

For the record, I think I've had three hours of horizontal sleep in the last 48 hours or so, and that was on a hard wood floor - though I did have a pillow and blanket.

That said, the title of this post makes perfect sense to me... See, we've just announced (this past Tuesday) a new customer relationship for Progress - Scottish Widows. Scottish Widows is a part of Lloyds TSB Group, and is a well known provider in the life, pensions and investment industry in the UK.

The press release is typical - you can read it - but it essentially says:

Scottish Widows performed a 20 month selection of an integration platform and selected Progress' offerings because they perform better than other offerings. Scottish Widows hope to

1. launch new products faster
2. integrate easier (probably why they hope to launch new products faster)
3. lower their IT costs overall

In fact, it's this last point that's very interesting. I was only involved with the deal on the periphery but from the beginning the deployment team of both Scottish Widows and Progress are integrating metrics into determining the success of the deployment. Among other things, they will be measuring their cost savings by using Progress Software. From an Actional perspective, this means diagnosing issues faster and reducing support costs, as well as improving customer (and end-user) satisfaction.

We've done a similar case study with a Financial Services institution, validated by Forrester Research. Email me if you'd like a copy of the case study or watch the on-demand webinar with Forrester that explains the results (as a special perk to readers... you don't have to register). The case study provides real numbers about the Total Economic Impact (TEI) and measurable results achieved by this institution.

The press release also mentions that Sonic ESB and DataDirect Shadow (mainframe integration) were also selected. Congratulations to those teams, they're great products. We're starting to see some really interesting dynamics driven by customers selecting multiple products from the Progress SOA infrastructure portfolio, but more on that after I've gotten some more sleep.

Five Dirty Little Secrets of Highly Available Integration Infrastructure

Even some of the world’s largest, most demanding companies suffer from a hardware, software, or network failure. Learn more about how a continuous availability solution will protect you from lost transactions, and guarantees in-order delivery without the cost and management complexity of the 3rd party hardware or software add-ons.

Register to download our new white paper, Five Dirty Little Secrets of Highly Available Integration Infrastructure. Topics presented in the white paper include:

• Recovery Time
• Data Corruption
• Hidden Cost and Complexity

... and those are just three secrets. Download the paper >

Embedded Not-so-lightweight ESBs

David Linthicum touched upon a very prevalent problem of technology not living up to its expectations set during the hype curve! He says, "With cloud computing, SOA, or whatever we come up with next, we still need to figure out core issues within our enterprises that no set of technologies or emerging trends can solve." In the service-oriented architecture (SOA) case, we all know that the widely professed use cases of systems "automatically" looking up service registries on the web/intranet, locating the required services, getting the interfaces, picking the right one, and actually making a service request is just a pipe dream! The reality is nowhere close! It is difficult to even find enterprise wide service buses, much less the dynamic on-the-fly service-look up-and-use!

I recently came across a scenario where even a large international bank has SOA infrastructure solving regional problems - and not necessarily as a corporate backbone! I was at this tech discussion with the regional technology head of a large bank, exploring how Apama (Progress' Complex Event Processing (CEP) engine) fits into a biz requirement they have. Specifically, he wanted to understand how Apama works and how it is a good fit for their biz problem. They were trying to build a business performance tracking solution (a la GRC) that involves tracking key biz activities, ensure due process is followed, and then proactively detect potential service-level agreement (SLA) failures so they can be averted. A classic use case for Apama!

Now, when we started to see where the business events information came from and how they could be "wired" to emit the required events into Apama, we suggested that they could just tie into their enterprise service bus (ESB)—we knew they had standardized on one. As we dwell further, it turns out they are using an ESB to solve departmental integration requirements, and there are multiple instances and no central ESB that can help integrate these "departmental integrations".

Now that was a revelation. (I am not complaining because suddenly our opportunity now included Sonic ESB, along with Apama). While we have been reading (and I myself have been blogging and talking) about how SOA failed to live up to its expectations, I still expected at least a large number of banks to have standardized backbones. But not to be! I guess, like in many large enterprises, even here SOA adoption has started purely to solve departmental integration problems—more as localized islands of "integration". And its nothing like the enterprise-wide integration platforms or service bus that we have so much noise about since 2004. This reality check at this bank was a clear validation of this failure! It seemed clear that the technology promise was something, and the actual on the ground realization was something totally different!

Come to think of it, it does seem like a good model for use cases such as BAM or GRC - to have a complete platform that in addition to the CEP engine and dashboard, it also includes a "local/embedded" ESB. Now, embedded is not about being lightweight or smallas it is about being available out of the box when you get the platform. In this case, the ESB is available along with CEP, well integrated - so no surprises as you start using it. And the purpose is to "wire" exchanges from existing ESBs or applications in the enterprise to the CEP environment.

Not a bad idea at all! Embedded ESBs!

Rage against the term 'ESB' not the need for Integration

In my opinion the rage against ESBs is directed more at the term "Enterprise Service Bus" than at the need for integration within an enterprise SOA. Few bloggers would publicly discredit integration infrastructure in the same way that they rebuke the term ESB.  Corporate IT portfolios are ripe with IT systems needing to be integrated and line-of-business executives who remain disgruntled with the lack of agility shown by IT in response to their demand for business change.  So, if you replace the label "ESB" with the word "integration", I expect that the vitriol would turn to sweet loving respect if not desire.

Integration infrastructure buyers ("ESB" buyers) are learning that most ESBs that come packaged with a platform are really unadorned web service brokers – allowing simple transformations of SOAP messages but little more.  If they've done their homework, these same buyers have learned that many vendors re-label security appliances, EAI suites and even application servers as ESBs.  So there is little surprise that the term "ESB" itself has become the object of such animosity. 

Furthermore, most new SOA infrastructure applications don't need an ESB.  ESBs are designed to provide integration between applications and are often overkill when put between services within a single development team. And when real integration projects do arise the complex nature of legacy IT infrastructure makes exceeds the capabilities of these one-size-fits-all service brokers.

Many of the clients with whom I've spoken about integration recognize the vitality of this solution and are on record with their satisfaction:

• Andy Edwardson, Vice President of information technology at FAMI, commented: "In addition to tackling internal integration challenges, our goal is to create a highly available environment in which we can more easily interact with business partners over the Web. Our desire is to develop an enterprise architecture that is less 'hard-wired' and more service-oriented, allowing us to create reusable business objects resulting in a more agile business environment. The Sonic ESB will facilitate such an environment."
• Bruce Hogg, Enterprise Architect for Pacific Blue Cross, commented: "Sonic ESB allows us to leave existing processes in place while layering new business functionality on top, and it allows us to implement a messaging-based distributed infrastructure for migrating to an SOA, step-by-step."

These supporting quotes suggest that some customers have come to draw their own conclusions about what an "ESB" is and as such, support the term - provided that the solution meets their needs (and perhaps is implemented in the right way). It's frustrating that the market has put them in a position where they have to go to such lengths – it makes their job of rationalizing the options available to them that much more difficult. Perhaps in the end, we should admit that the battle of defining ESB properly is a lost cause; rather vendors like Progress focus on SOA integration in general and the value of a robust solution to this age old IT challenge.

The past will predict the future

As you have probably read in today's press and blogs, Progress is going to acquire IONA.  This is great news and I welcome my new colleagues from IONA.  But what does this mean to our combined customers?  While I am not going to directly comment on what the Progress and IONA products will look like going forward; I will review some of the past acquisitions to understand the benefits for everyone involved.

If you look at the Actional acquisition, you will see how these products have evolved over the last couple of years to not only stand on their own and compliment other vendors' stacks, but also how they have enhanced products like the Progress ESB.  The same also goes for products from Pantero, now DataXtend SI, where we support full life-cycle of canonical models and the transformations in and out to save our ESB customers many hours of work, but again also provide the same to the application server vendors out there to ensure that we never have to go into XSLT hell again.

As I said earlier I am not going to comment on combining roadmaps, etc., but you can see from the past that not only is Progress Software adding more capability to our SOA infrastructure portfolio by allowing us to help our customers solve larger and more complex problems, but we can equally play as well in combined vendor solutions.

Why should you deploy an ESB?

An enterprise service bus (ESB) provides you with interoperability across many distributed, heterogeneous services and systems. Watch the video below and hear Hub Vandervoort tell you more about the power of an ESB and the industry's 1st ESB - Sonic ESB.

Gain Better Enterprise Visibility of Your SOA

What if you could gain better visibility of business systems and services across your SOA infrastructure? At Progress Software, we believe that you can achieve the promise of SOA without compromising your architecture or getting locked into a single-vendor approach. Listen as Giles Nelson, Director of Technology at Progress Software, presents his observations on the challenges that you and other enterprises face when trying to identify business requirements, deploy smart solutions that will support these requirements, and how - at the end of the day - you'll be able to monitor and analyze operations so that you can make smart decisions that will improve ROI and reduce risk.

Subscribe to our iTunes channel for more SOA Infrastructure podcasts from Progress Software.

Learn more about SOA Infrastructure products from Progress...

• Enterprise Service Bus - Sonic ESB
• SOA Management - Actional
• Complex Event Processing - Apama
• Data Interoperability - DataXtend
• Mainframe Integration - Shadow

Loose coupling versus decoupling ...

Last week Jeremy Suratt made an interesting point on the Infor Tech Talk blog.  He says that event-driven architecture (EDA) is different from traditional service-oriented architecture (SOA) in the manner in which applications are related - or not related.  In particular he says "key to event-driven SOA is the ability for decoupled, asynchronous operations."  I agree wholeheartedly with Jeremy and think this point is one of the least well understood aspects of modern enterprise architectures and the complexity inherent in large integration projects. 

There is a great book on this topic entitled "Software Fortresses" by Roger Sessions.  Though the book doesn't mention the term SOA (it largely predates SOA and the current hype), it does point to the fundamental need for decoupling of systems through asynchronous messaging.  In the book, one of the golden rules is "never let transactions cross software fortresses."  I may be misquoting this a bit ... but the essential point is that between application domains, which are referred to as fortresses, you should allow for no dependencies which might block a transaction's completion.  This rule flies in the face of what most SOA infrastructure advocates today suggest is the very purpose of this new architecture.  Aren't we to just make a Web Service call when we want to leverage components in other systems?  Roger says - just because you can doesn't mean you should.  Once you grok these simple architectural best practices and the power it brings through "isolation", you're fast on the road to understanding the difference between traditional SOA and event-driven SOA.  The latter abides by the golden rule by inverting the control of intra fortress communications - using an event publishing rather than a service invocation model.  The former decouples the applications and the latter couples them - albeit loosely through Web services. 

Perhaps this is a long winded "dah" moment for you, but for many organizations it's still something they wrestle with daily.   Progress chose this decoupled model for the design of our integration backbone, Sonic ESB.   As a result, applications integrated with Sonic ESB are naturally decoupled.  This means you can shut down any application without impact to the overall operation of the other applications.  Unlike systems that link through traditional SOA request/reply invocation... Sonic ensures that messages get through when the application comes back online.  Now this is very different from other ESBs on the market or available through open source today.  These ESBs employ a "traditional SOA" architecture - meaning that applications connected through them are coupled via service-proxy rather being decoupled through asynchronous message forwarding.  I don't want to belabor the point, but a loose coupling of Web services is an insufficient architecture for large integration projects.   If you're not familiar with this type of ESB, I encourage you to download our latest Sonic ESB 7.6 version and go through the tutorial on "batch to real-time" processing - which shows the power of event-driven integration in the form of a continuous pipeline processing example. 

Before you start writing you own ESB ...

Vincent Partington recently wrote on his blog "before you start writing your own services and your own ESB, have a look at what's available."  Vincent point out the challenges of migrating from a home-brew ESBs and recommends against a "not invented here" attidute.  Reminds me of a dinner conversation in Winnipeg, Manitoba several years ago following my presentation of a new SOA Maturity Model to a group of local IT directors and executives.  The gentleman next to me asked a simple question - of all the services in the world (SOA) which ones are the most important to do first?  I was a bit set back by the question since I'd never had someone ask such a straight forward and obvious question.  After chewing a bit on my dinner I admitted how profound it was and then suggested - file parsing, transformation, routing, and file writing were probably the services that everyone should invest in first.  These are precicely the same set of services now offered out of the box - in both commerical and open source ESB (enterprise service bus) implementations. 

At Progress we've gone a step further to document larger enterprise integration patterns such as "batch to real-time" and "remote data distribution" on our developers network, and we also offer public code share libraries for users of Sonic ESB.  So, long and short - consider downloading Sonic 7.6 and leveraging some of these prebuild integration services, code shares and higher level EAI patterns.  I think you'll see that Vincent was right on the money with his advice, "...have a look at what's available." 

Optimizing the SOA Assembly Line

We have all been there, performing the same task over and over again - this is no different when implementing a SOA.  There are many patterns, see www.integrationpatterns.com, that can be implemented plus many techniques to develop the particular functionality that is required, and as sure as god made green apples you will have to do it again.

In the latest version of Sonic ESB 7.6 (being formally announced soon) we've incorporated templates that any developer can create by simply copying any assembly/service that has been used before and dragging it into the templates palette.  Now any time that I want to use that pattern, it just needs to be dragged onto the canvas and all the dependent files will be generated, e.g. stylesheets, etc., and you are ready to go on knowing that the pattern is good.  Note you can export from one developer to another to rapidly build up a set of templates in a team very quickly.

The cool thing is that anyone can do this, no knowledge of Eclipse is required, no programming knowledge ,etc.  With features like this we can really start to increase productivity and solve the simple very quickly, the complicated may still take a little longer.

SOA What?  Now is the time that the business is going to start viewing all SOA infrastructure projects with a fine toothcomb, so providing the ability to deliver more functionality can only be good.  Solve once repeat many, is now truly realized by the developer.

The Fat Double-Headed Arrow

We were excited to see Philip Howard's piece on the importance of a common data model. It was heartening to read our convictions about IT architecture espoused by someone with no overt commercial agenda. Though he mentions our favorite product at the end of it, we did not solicit or contribute to the piece. So we interpret his research as reporting on an industry trend where we are at the vanguard.

That bit of bragging aside, being ahead of the trend means we'd like to see a common data model become more common. To many IT folks "Enterprise SOA" still only equates to normalized interfaces and messaging.

For many years we've seen diagrams with squares, cylinders and computers on either side of and connected to a fat double-headed arrow. The squares, cylinders and computers represent processes, databases and applications. The fat double-headed arrow is labeled as some kind of bus or backplane. Ten-plus years ago it might've been labeled "Object Bus" and the underlying technology might have been CORBA. Five-plus years ago it might've said JMS or other messaging protocol. More recently the fat double-headed arrow just says ESB.

Common messaging protocols (e.g. JMS) and interface definitions (e.g. WSDL) are critical to Enterprise SOA. But messaging and interfaces focus on normalizing business processes and do little to normalize the other half of computing: the data. That is where the common data model comes in.

SOA What? A common data model (sometimes called a common information model) is the data complement of an enterprise service bus. It is a critical component of the fat double-headed arrow.

Distributed SOA

Last week I attended the Forrester Enterprise Architect forum and heard a pretty consistent cry from people walking around and stopping at the booth; "How do I implement SOA in a distributed environment?"   This question is being raised by people talking about 3 or 4 locations distributed worldwide to 500 locations in the US.  Most of the people have evaluated the competition and realize their service orchestration engines are great in a hub and spoke model but do not really support global processing.  More to the point, even if they supported the idea of distributed applications, they do not support the idea of management/control of that environment, i.e. I can deploy the application to a remote location for version 1 of the solution, but version 2 will require me to re-deploy a whole new application.  Worse than this, there is management overhead that I must place in the remote location, e.g. someone to start/stop and monitor the application server or similar.

Well now I can see these problems are solved and have been for a number of years with Progress Sonic ESB.  The enterprise service bus (ESB) provides the ability to not only distribute the service/event processing to where it makes sense - e.g. if I am a retailer and need to allow my in store POS devices to communicate - but at the same time allows them to communicate through firewalls with the various applications distributed in other stores and the corporate headquarters.

This whole SOA deployment can be managed from a central location to ensure that no IT resources are required within the distributed locations - other than to turn the hardware on/off occasionally.  Metrics and Notifications are fed up to existing management software, and I can view log files of remote applications from the central console.  Also, new versions of the services can be deployed centrally so updates can be deployed to 500+ sites at the speed of the network, and if the network is down, the ESB will hold the request until the network returns.

SOA What? If you have a distributed SOA/event-based requirement, look no further than Progress Sonic ESB. OK, so as a principle architect, I'm probably not supposed to be "marketing" on this blog, but not only will Sonic ESB allow you to create your application with minimal code in a distributed environment, but you will also be able to manage it, and reduce the time and cost it takes to make your SOA a success.

We're Running Out of Words II

It's interesting when you have a shared blog... sometimes coordinating posts with others so there is no talking over each other leads to no one posting. It's especially hard for me, as I'm a "mood poster" - meaning, I post when I'm in the mood. Fortunately, I'm usually in the mood to talk about something I profess to know something about, so there's no shortage of material.

Which of course, leads to a brief apology. I've been quiet lately, even though there is a ton of good stuff going on (not all of it in my head). I just find it hard to be creative when I'm busy, and it's been a busy few weeks (in-and-outside of Progress) for me. Probably will be for another three weeks or so... so to all my fans, my apologies!

Back in November, I jokingly titled a post that "We're Running Out of Words." Something you could, of course, never tell by how much I talk.

The idea is that we "overload" words with meaning and often don't even realize the assumptions we make (and more importantly, others hear) when we use overloaded words. The most overloaded word in our space (IMO) is discovery. Another, management.

When I first started at Actional, our mission was to educate the market. I started presentations with a slide that said "Web Services Management" -- what the market was calling our space at the time. I then went on to put big red X's through Web and Management. What we were doing had little to do with the associations that come up when people think "[World Wide] Web" or "Management." It was a challenge then, and it's a challenge now.

SOA What? Well, today, you should be asking "SOA Why Now?" - I mean, I talked about this back in November.

My brain works weird. I read Dana's post, Progress Software adds cross-process visibility with Actional 7.1, over at ZDNet, and one thing stuck in my head. Knowing that I haven't been around for a while, I thought I'd comment on how we've overloaded the phrase "Business Process" (and the associated "Business Process Management"), and as a result might be missing the really interesting point.

Let me share an customer situation: very large telco in the mid-east - actually an Oracle customer. It was about 20 months ago, so that gives you an idea of where Oracle's BPM solution was in terms of maturity. This customer needed visibility into their business processes. Oracle told them (as would most anyone out there, I'm singling out Oracle, but picking on everyone) if they wanted to track business processes, they needed to implement them in a BPM engine. Long story short, they took their existing processes and implemented them in Oracle BPM. It was hard to do... so they only implemented their most important processes. Once implemented, they realized they had only 1/12th of the performance they had before - all in exchange for knowing where a process fails and being able to track it from end-to-end.

So, let me summarize:

1. They reimplemented processes that were already working just fine. BPM offered no process-value-add.
2. They were limited to their most important processes because of the difficulty they had implementing their processes in a BPM engine.
3. They suffered performance and scalability in exchange for visibility; visibility that was limited to what was going through their BPM engine.

This is the key point that Dana, and I think everyone else, misses when they look at Actional. Processes don't need to be orchestrated to be managed. Ad-hoc processes can be managed just as easily as anything else. And, perhaps, that means in some cases (not nearly the majority - but some) BPM isn't needed. I'd argue that most processes are actually informal... and only become formal so they can be orchestrated and controlled. What if you could gain all the visibility and control you need, without the overhead of orchestration?

Instrumenting an SOA infrastructure with Progress® Actional® means they get all the visibility they need, into ALL their processes, whether those processes are orchestrated or not, without impacting performance or scalability, and they get it cross-platform and protocol:

• All the visibility they need; anything on the platform is automatically displayed and correlated across the entire infrastructure.
• All their processes; since there is no need to change code or re-implement a process that already works, every process (ad-hoc or orchestrated) can be tracked in real-time and, more importantly, in the business context in which it is executing [that telco I was telling you about had a provisioning service - we were able to track it for landline vs mobile separately with just a few configuration steps. Then, we enhanced tracking by separating mobile provisioning into pre-paid and post-paid just as easily, and without affecting performance].
• Without impacting performance or scalability; if Oracle slowed things down to 1/12 with just some processes orchestrated, then we can be said to have been more than 12x faster than Oracle!!! And, Actional has no single point of failure like a BPM engine (and many other service management solutions) does.
• Cross platform and protocol; Do I even need to explain this? Gosh, we have customers using TIBCO BusinessWorks alongside Sonic ESB, and exposing everything as web services over SOAP, and we can track everything end-to-end from the HTTP call to the portal, to the service, to the "bus", to the BPM engine, out to the database, and back - synchronously or asynchronously. A mouthful, I know, but cool nevertheless.

There's a reason Forrester ranked us #1. But, to know what they know, I need to ask you to listen to what we mean, at least until we can make new words.

By the way, if you want to see this end-to-end visibility yourself, apply to evaluate the solution. It won't include the business process "stuff" we do, but will give you an idea of how easy it is to discover and correlate across platforms and protocols.

Multiple ESBs: SOA Reality in a Federated Environment

There has already been some hype about the audio interview between Hub Vandervoort, CTO, Progress Software, and an industry expert from Gartner, but in case you haven't listened, listen to it.

During the interview, Hub discusses how companies that are working in federated environments need to approach the governance of their SOAs in both run-time and design-time contexts. If you listen, you might gain important insights into how to isolate and manage multiple SOA domains, determine which aspects of your SOA you should control at the edge, the importance of semantic control, and how event-driven ESBs can ensure loose coupling between SOA stacks.

Download the audio file entitled, Multiple ESBs: SOA Reality in a Federated Environment .

"But, what do you DO?"

My grandfather's curiosity makes him seem younger than his 90 years. After the war, he, an immigrant in NY, became, among other things, a tailor. For the past 10 years or so, each time I've visited, at some point the conversation would turn to my job, and he would pointedly ask, "But, what do you DO?" I didn't quite understand his emphasis on "do." So, I'd respond that I travel, talk to people, listen a lot, and ultimately advise customers and our field on ways to move opportunities forward. I'd give examples. In return, I would get a confused look and a repeat of the question, "but what do you DO?"

Finally, one day in exasperation he says, "When I went to work, I made clothes. When you go to work, what do you DO?" Now, that was awkward... you see, I don't really DO anything. I'm an enabler. I'm more like a carrier of a disease than a tailor. I travel around picking up experiences in one place and leaving them in another.

I know... fascinating. But, SOA What?

Well, we just had our annual sales meeting here at Progress. And, coming off a great year, we Actional people were pretty popular. I was delivering the Actional message to a group of new employees - which I consider the 2nd most fun thing I get to do all year - and they kept asking, "what's the business benefit of Actional?"

What's the business benefit of Actional?

I'm not going to answer that here. Suffice it to say that my answers left the people in the room last Sunday somewhat unsatisfied. They wanted something tangible to take to their prospects--something that would quickly and dramatically get their attention and priority. I gave them talking points that they could use to start conversations, but nothing that would turn people's heads. The whole thing got me thinking...

Can an enabling technology have a direct business benefit?

Notice the word direct. I think an enabling technology enables business benefits. But, it requires some deeper understanding of the business situation, and then the application of technology expertise to that situation in order to achieve some tangible benefit.

An example will help. Actional has a large number of travel and hospitality customers. We help them optimize their delivery of product across various channels. Using Actional, these companies are able to differentiate service levels by customer, channel, and dynamically based upon, among other things, immediate local market conditions. In one case, a company has saved millions of dollars on hardware investment by better utilizing their shared infrastructure. They optimize their SOA infrastructure based upon "business level SLA," rather than blindly adding capacity. In short, they more closely coupled their "business" with their "infrastructure." These benefits apply equally well to any services business, and in my opinion will be a critical differentiator in the coming years.

If you look at the benefits I just described, you might think we compete with a highly customized point-of-sale system, or some reservation system, and probably a bunch of other things, however, as much as people want the "soundbyte", it's simply not the case. We don't really do anything tangible for these companies, though we are a key part of their enterprise infrastructure for delivering a highly differentiating service. I think there was a Dupont commercial that summed it up quite well... "we don't make your business systems, we make your business systems better."

Once my grandfather realized I didn't actually "DO" anything, he was able to start to understand what I accomplished. Perhaps we need to look at enabling software the same way?

Business visibility should be a driver for SOA

I've just read a Gartner research note by Massimo Pezzini published on the 16 November. It's titled Greater Business Process Insight Is an Unexpected Benefit of SOA. It argues that an unexpected and unplanned consequence of SOA projects is that organisations gain better visibility of their business processes and business data. It recommends that organisations think and plan about things like Business Activity Monitoring (BAM) from the outset.

I was surprised by this and also disappointed. Not because I don't agree that better business visibility is a consequence of SOA – it is. What surprises me is that this is still seen as noteworthy. It shows how far the industry still has to go toward understanding the merits of enterprise architectures which give them more open, simpler, more flexible access to real-time business information. service-Oriented Architecture (SOA) is about service reuse, open standards, etc. etc. But you're doing this for a reason, not for its own sake. Surely one of the benefits of a more open, flexible architecture is that you can get at your business information better so you can drive efficiencies in your processes, identify threats and opportunities more quickly, and better communicate with customers, etc?

Some organisations do recognise this. Only last week we responded to an RFI which not only included "usual suspect" SOA requirements satisfied by such things as an Enterprise Service Bus (ESB), but also requirements for event processing and BAM. The organisation recognised that the building of a SOA infrastructure gives them access to business event streams that they can obtain value from immediately. They had indeed expected this consequence and were planning for it.

SOA What? These kinds of requirements will become the norm. Real-time access to enterprise information is becoming more relevant in a whole range of industries – we're seeing this directly in some of the engagements we're involved in. Furthermore, event processing and BAM are at the more business end of the SOA universe. One of the things that the industry harps on about is that the business rarely sees the relevance of a SOA initiative. By taking the advice of the article and thinking about these things apriori then perhaps not only can organisations get more out of their initiatives but also CIOs can gain a little more credit from the wider organisation.

Buying and Driving your SOA

When I get around to buying a new car, I know what is important to me. Being 6 feet 4 inches tall the first criteria is whether or not I can sit comfortably and see myself driving many miles, and then small things become important, like whether I can see the lights at an intersection. The comfort criteria is independent of the car and must be applied to all cars that I try, although I do like the image of relatively fast cars. When you look at what I drive, it might surprise you, I have a Ford Focus SVT which is good for 140 mph and 0-60 in about 6-7 seconds I am told. Many people have asked why I do not drive a SUV or similar and the reason in many cases for me is that they typically have less room for a driver of my proportions than my Focus.

When I bought my car, there was a lot I already knew. Having driven many cars, I knew where the steering wheel, radio, rearview mirror, etc. were and I knew that I could drive the car without a specific driving course, although to push the limit and understand how it would go 140 mph on a sweeping right hander would probably require a day at some race track. My wife on the other hand has to transport kids to the school and to soccer practice so her vehicle of choice is a minivan.

Now that I have shared with you some of the reasons how my family chooses cars, you may be wondering how this relates to SOA. Well, last week in a meeting with customers and prospects alike, I was getting questioned on selection criteria for ESBs and SOA infrastructure technologies.  And in nearly every conversation, the same criteria was clear - how many messages per second, how much memory, etc. etc., and only a few really came up with a statement such as "We are facing challenge X and would like to solve it?" This is the most important question because just like my car challenge of "sitting comfortably for long periods of time" outweighs the need to do 140 mph (which I have yet to do), if I bought a car that does over 150mph, it would probably be gone by now as it might not meet my primary needs. And lets face it, how fast do any of us really need to drive? Even the cheapest car on the market will do 80mph all day.

Using standards such as Web-Services, JMS, etc. also means that developers can apply the same disciplines to one technology as another - in much the same way that most drivers can switch cars. If it did not, Hertz and other companies would not be in business. Which brings me to the second theme of questions and comments I was getting, "What do my developers have to learn to be successful?" They have to learn to transition from one environment to another but still be able to apply the same core software engineering practices. For instance, you would not write all your business logic in one Java class so don't do the same in one ESB process. In CORBA you would not make every object accessible, so why do you try to make every Java object a web-service?

SOA What? Buy the technology that makes sense for you and your business, e.g. if you are a distributed manufacturing organization build/buy a SOA that can be deployed and managed in a distributed manner.  If you are dealing in high volume transactions or events, you will, like a racing driver, need to look into performance. Once you have chosen your SOA technology, remember to still stop at red lights, and not to redline the engine at every gearshift. The speed limits may have increased, and you can break them later, but they still exist. And just like I would get special tuition to drive safely at 140 mph, remember to call on the experts of your SOA to drive at the limits.

Progress Sonic Extends Lead in Distributed SOA

Today, Progress Software announced the release of Progress® Sonic™ Deployment Manager (SDM). The Sonic Deployment Manager is an installation and configuration tool that helps project teams streamline incremental development and rollout of large-scale Sonic product deployments. By automating the installation of Sonic products (including Sonic ESB and SonicMQ) and tailoring the configuration to suit each host, Sonic Deployment Manager reduces the time and cost of project development, delivery and maintenance.

Two of the key use cases for the Sonic Deployment Manager product are lifecycle management and large scale deployments. In both of these use cases SDM delivers on the critical need to have consistent, repeatable deployments both between lifecycle stages and also across a widely distributed environment. Unique to SDM is its ability to create a completely reproducible package of all components and configurations of a given deployment instance. This capability allows precise rollback and re-creation of any given environment, enabling configuration management, auditing and regulatory compliance.

Learn more about the SDM >
Read the Press Release >
See What's New in Sonic ESB 7.5 >

The fog may be clearing but SOA has always been in the clouds

Last week's InfoWorld article, SOA meets open b-to-b integration by Brad Shimmin, couldn’t escape my attention for several reasons. Brad makes the observation that ESB offerings seem to be appearing "in the clouds" of SaaS vendors, commercial ISVs, and now open source providers. He goes on to coin the term 'IaaS' to mean Integration as a Service, and suggests its success will be driven by the 'sudden realization' that SOA has as much to do with B2B as it does enterprise integration. Finally, from all this he asserts that ESBs in the cloud, IaaS, and SOA for B2B will all become the spoils of the Open Source community because of its cost relationship to ISV solutions. While I will enthusiastically agree with much of what this article observes, I'd like to offer a slightly different perspective that leads me to very different conclusions.

Understand your organization before you architect your SOA

John Radko of GXS had an interesting blog entry about SOA versus ESB - Conflict or Collaboration where he talks about whether ESB and SOA should always be put together.  Since SOA is an architecture but an ESB is a product, deciding whether your architecture should depend on a specific product is an important question to ask yourself.

The interesting thing about this question is that answering it has little to do with technology.  In fact, the right approach has to do with the existing power structure of your organization (whether "organization" for you means project, division, or even enterprise).

Drive Operational Excellence with an ESB - SOA Success

A few months back Progress Software hosted an online event called, Drive Operational Excellence with SOA. The webinar featured a guest speaker, and customer, from Pacific Blue Cross who discussed the challenges of moving from a legacy batch and manual processing architecture to a leave-and-layer approach with an Enterprise Service Bus (ESB). Deploying the messaging-based ESB in their SOA infrastructure gave Pacific Blue Cross the ability to wrap new services around existing services. The benefits that Pacific Blue Cross and other ESB customers gain by this approach include: Reduced business process cycle time; improved consistency and visibility of in-process data; reduced cost of errors from manual intervention; cut costs of processing peak transaction loads; and improved flexibility to handle future business change.

The Approach to a Successful SOA

As an ESB practitioner for the past 4-5 years I am often asked what is the best way to make a SOA project successful, my response 'An initial win, followed up by small successful iterations,' the main thing that people are taken back about in this statement is the lack of technology and standards in the response. Yes, technology and the supported standards will help dramatically with achieving this, but it is an aid to the vision of the business, architect, or other that is pursuing the SOA vision - without that vision the project will not be successful regardless of technology.

The initial win might in fact be the easiest part of this statement, as in many projects this might be a Proof of Concept or initial pilot that is built with little regard for the challenges that are about to hit the project. However, with a bit of planning and some guidelines for the development and layering of SOA applications, it is possible to achieve the statement 'followed up by small successful iterations.' To achieve successful iterations each subsequenet iteration in the project should build directly on services built in the prevoius revisions.

To prove reuse and agility I recently created a simple demo for a distributed query across four databases, this was created in top down approach allowing the quick win to be achieved in which the sample end user portal could simulate requests within minutes of starting the project and before the databases were even defined. Then the data aggregation and connection level services were created in about another 2 hours, allowing essentially 3 phases in 21/2 hours. And now the unexpected benefits; for the next use case which was Remote Information Data, or given a document entering the ESB route it to the appropriate back-end datasources. This was done in about an hour as I not only reused some of the service instances, but the associated artifacts such as Integration Workbench projects etc.

For both use-cases I used 3 service types, 5 projects and 21 ESB Processes and not a single line of code (Java or .NET) and have the ability to reuse most of these as my demo is extended.