Event-driven SOA has been grabbing some headlines lately as a couple of vendors have launched new tools to support this architecture.  Infor was one of the first major applications vendors to embrace event-driven SOA. It was somewhat of a challenge to explain at the time because there wasn’t a reference point for people to understand the concept and some of the terminology is still fluid even now. Some purists, for example, refer to Event-Driven SOA as “Event-driven Architecture.”

One of the key aspects of event-driven SOA is the ability for decoupled, asynchronous operations. Software components are decoupled and communicate through a publish/subscribe process over an ESB. Asynchronous can be thought of as “fire and forget” – when a business event occurs, the publisher pulls the trigger and many subscribers can consume this information.  This is different from traditional SOA, where components are loosely coupled, services are invoked at the request of a single client, and communications are synchronous (bi-directional) on a one-to-one basis.

What’s the advantage of asynchronous? Think of this analogy from our current mortgage meltdown in the U.S. Today our financial institutions are so interconnected that one problem can create a ripple effect that threatens the stability of the entire global system. The same is true in an IT architecture dependent on synchronous operations – because bi-directional communications are required, if one service fails to reply then it can theoretically breakdown the entire end-to-end business process for all users.

In an event-driven world, this doesn’t happen. Processes are triggered by events, published, and not dependent on a reply or confirmation from the consumer. So if, for example, one component goes offline or is upgraded, it can be done independently without jeopardizing the entire system.  Business events queue up for the unavailable component while it is off-line, and then continue processing when it comes back on-line. Meanwhile the rest of the systems were unaffected and users continue to operate while they still have information to process.

Why is this so important?  Heterogeneous IT environments are here to stay.  If anything we are going to see an increase of new innovative solutions and technologies in your typical customer IT ecosystem.  As the number of supported solutions increases, so does the complexity and dependencies of a traditional SOA deployment.  Event-driven SOA provides IT organizations with the architecture to make managing their increasingly heterogeneous mix of solutions much more manageable, enabling quicker response times to new business requirements. 

Now isn’t that what we are all looking for?

Posted by Jeremy Suratt, Director, Technology Marketing

Manufacturing Business Technology just published a great article about SOA.  Tony Baer provides an overview of SOA and reviews different vendor approaches.  Comments welcomed.

Posted by Jeremy Suratt, Director, Technology Marketing

Hello – I’m Massimo Capoccia, Director of Product Management for Technology at Infor. I’ll be blogging here from time to time alongside Jeremy, Bruce and my other colleagues. Ironically, in my first blog post one of the things I would like to talk about is the challenges we technical people have in communicating!

I talk to a lot of CIO’s and IT managers in my role and a common topic with them is how they can explain SOA to the CEO, CFO and their other non-technical executives. What seems like an intuitive and simple concept to a techie can sound like nonsense to a top executive who comes from Finance or HR.

Explaining it to business management is necessary because, well…. they sign the checks! Seriously, it's important because SOA is fundamentally about enabling business agility. It's not just part of the IT strategy, it's about the corporate strategy and how fast you can respond to changes, threats and opportunities. Business people understand that.

So what’s the best way you can start? Begin by asking them about the future of the business. How much will the business change in the future or, if there’s a chance it does change, how quickly will they need to respond? Is there a new business model or essential business process in the works for the future?
For companies with dynamic businesses, the ability to quickly reconfigure the enterprise architecture is an important competitive advantage. Even more important for CFO’s, an SOA helps reduce the time and costs of implementing change when compared to a more traditional and rigid IT architecture.

For instance, I visited a customer recently who inherited a large number of ERP systems through their various acquisitions over the years.  The C-level executives of this company understood the pains of integrating these businesses.  They recognized the enormous time and cost of bringing these businesses together.  Surprisingly enough, they even referenced the costly integration challenges they were having in IT. 

When I explained that SOA could help them speed-up this process, it clicked for them.  They didn’t care about the bits and bytes – that’s up to the IT staff to validate.  For the executives, it’s all about improving the bottom line, and now it was clear what SOA could do for them. 

Once they understand that SOA is not about technology for the sake of technology, but delivers real world business advantages, then they become its biggest fans.

Posted by Massimo Capoccia, Director Product Management, Technology

Why do we need SOA? Truth be told, the need for SOA stems from the development practices of the enterprise software market over the last 20 years. Vendors and customers have traditionally built large monolithic applications that limited the ability to respond to changing business demands with new innovative solutions. This can be categorized in two ways:

1. Lack of native interoperability: Business solutions were not originally designed for interoperability. They were designed with a framework that would be continually expanded with new modules to meet new requirements. The customer trended the other direction and continued to purchase best-of-breed applications to source key functionality for their business. The net result is a growing collection of software solutions that don'€™t know how to speak to each other. Regardless of the industry or mix of vendor solutions and technology platforms, you are faced with this reality. Software integration is hard.


2. Disruptive process in changing functionality: As business applications have become bigger and bigger, their scope included more departments and more of the business requires that these applications be available at all times. As customers'€™ departmental requirements change over time, the impact of making any upgrade or change to their business applications has had more impact on the rest of the business. For example, if your biggest supplier came to you with new requirements on how you purchase with them, it might require new functionality that is not currently available on the version of the application you are currently running. An upgrade might deliver the needed functionality, however, the rest of the business may have a different agenda. They may restrict any changes to the system to certain times of the year. How will you respond to these new requirements in a timely manner and avoid non-compliance fees? Application architectures of the past did not provide a way to easily swap out or upgrade functionality that serves a portion of the business.

Both of these challenges need to be met in order for customer to increase their responsiveness to new business challenges. The business software industry has led us down this path and created SOA as the solution. This is why we say that IT architecture today is an impediment to business agiliity and that SOA is designed to enable IT flexibility and business agility. In future posts I will discuss how Infor Open SOA addresses both these problems and helps customer align IT with the business to create a more responsive enterprise.

Posted by Jeremy Suratt, Director, Technology Marketing

Are there different flavors of SOA?

The answer is yes. And how you distinguish between them depends on your orientation. Do you like to buy or build?

Ask yourselves the following basic questions: What are you trying to do? What is your objective? Are you trying to build a new application? Or are you trying to assemble and reconfigure the applications you have? How much of a software development shop do you want to be?

Without belittling your requirements - most likely there is a packaged application that can meet the majority of your needs. Leveraging packaged applications reduces the need for pure development resources.

If you need a supplier portal, you can buy it or build it. If you buy a packaged supplier portal, you will benefit from a supported, configurable application. SOA can help provide flexible interoperability with your various purchasing systems and manage future requirements and resulting changes to your systems.

If you choose to develop your own supplier portal yourself, you will want to develop it using service-oriented techniques which will promote reuse and flexibility. Both are valid approaches and cost benefits will direct you to the right approach.

So, we classify the two flavors as:

1. Development tools for building applications
2. Pre-packaged application architecture that allows re-configuration and reuse of business solutions

Some may argue that there is a third flavor that is a combination of the first two.  Do you prefer chocolate, vanilla or swirled?  (I am a big ice cream fan)  The reality is that customers are having great success using SOA to bring together packaged applications and custom developed applications.  However, we still see that there are two principal strategies that are employed to make this happen and they are summarized by the two flavors above. 

Infor is a packaged application provider and we are focused on the second flavor. Our objective is to provide our customers with a SOA-based framework that embraces the heterogeneous IT environments that exist today and gives them a framework to snap-on new applications to their enterprise in the future. (By the way, we have a great supplier portal solution for those of you who are interested.)

So the focus of our Infor Open SOA strategy is not to provide custom application development platforms, but to provide a service-oriented architecture for our applications so that they serve the needs of customers who prefer to buy and assemble rather than build.

Posted by Jeremy Suratt, Director, Technology Marketing

What is SOA?  How does Infor define SOA? 

If you are a technologist and haven't been living in a cave for the last 5 years, you probably have a good understanding of what SOA is.  However, to make sure we have a clear understanding on what Infor's approach is, let me define it according to Infor's perspective:

SOA is a new way of building and deploying software that allows customers to respond more quickly and more cost-effectively to changing business requirements.

In an effort to keep these blog posts short and sweet I will avoid getting into a lengthy, technical discussion  on the details, and instead point you to our whitepaper, Introducing Infor Open SOA.   

For those of you who are looking for the bits and bytes here in the blog, don't worry it's coming.  ; ) 

Posted by Jeremy Suratt, Director, Technology Marketing

I get asked the question a lot – “Why is Infor taking such a different approach to SOA?”

It really started with going around the world talking to customers about their enterprise software. Early on in this process, it became clear to me that packaged software would disappear if we didn’t solve a fundamental problem, which is the cost, risk and complexity of upgrades.

We knew in 2002, back when Infor was founded, that this was a problem and that we would have to move in a new direction to solve it. It wasn’t a big secret… all our competitors knew it too and the entire industry has since moved towards SOA as the answer. (SaaS is another answer, and we’re doing that too, but it doesn’t address existing investments.)

The problem customers want to avoid is the need to ‘rip and replace.’ That meant a gradual, phased approach to SOA… and that’s where we parted ways with the competition. The value of SOA is business agility without IT disruption, but to get to that point they require their customers to go through major disruptive software upgrades. That’s the definition of paradox.

It’s no wonder that customers aren’t rushing to upgrade to these kinds of SOA platforms. The analyst figures bear this out. The benefits just don't outweigh the costs and risks. In this kind of model, the money that customers pay for maintenance doesn’t deliver a lot of value. We knew that wouldn’t work for our customers.

So while we are completely re-engineering our approach to software, moving from a centralized model to a centralized and decentralized model, it is a revolution by evolution. That means incremental upgrades that deliver SOA-enablement and the ability to expand existing systems through component-based development. It's SOA that's customer-centric rather than vendor-centric.   

In my next post, I’ll talk in more on the “How” - how we are gradually re-engineering our codebase and what this means in detail. But I think this answers the question of why we are taking such a different approach.

Posted by Bruce Gordon, CTO