I’m going to cover:

SOA 2.0
WS-[way too much]
And answer e-mails.

www.soaexpertpodcast.com

Posted by davel in | Permalink | Comments (0)

I’ve seen a ton of BI solutions in my years, and now that SOA is hot they are attempting to bind their solutions to SOA, calling it real-time business intelligence.

First of all, there is clear value with the analysis of data in real time, I’ve written about it and spoken about it many times. However, in selling real time BI in the context of SOA, many are becoming confused as to where that pattern should exist. Clearly, not within a BI technology product just attached to a SOA stack. Hear me out.

While the current BI solutions are looking to “bolt-on to a SOA” (exact quote), they really need to exist at a very specific level, for a very specific purpose, and do some very specific things,….in my world that’s Level 5 (see levels below). It exists there for a few reasons, and may indeed not be a particular BI product, but abstracted into the orchestration layer altogether.

Here’s my thinking:

Within the orchestration layer all of the abstractions exist, and are indeed re-abstracted into solutions, or processes. Thus, the BI layer needs to exist within the orchestration layer to take advantage of these higher-level services. Many are attempting to place BI components directly on core or primitive services and data sources and sinks, that won’t help you much considering the larger strategic nature of SOA.

The BI layer is needed within the orchestration layer for BI services, or the ability to leverage BI services within the solution instances. Thus, we can make process decisions based on real time or near time information; it makes all the difference.

The problem is that BI products, especially real time products, are not being sold at the orchestration layer, but are more tactical in nature. Thus, they won’t have much of a life when you leverage them within the context of a strategic architecture such as SOA.

Dave’s SOA Levels

Finally, Level 5 SOAs are SOAs that leverage everything in Level 4, adding the notion of orchestration. Orchestration is key, providing the architect with the ability to leverage exposed services and information flows, real time business intelligence, creating, in essence, a "meta-application" above the existing processes and services to solve business problems.

Posted by davel in | Permalink | Comments (0)

It seems that my post of yesterday has riled up some of you out there, but most were in agreement. Indeed, while I’ve gotten a few comments posted, I received a few interesting e-mails, none of which agreed to do a public post to respond.

The pressure seemed to have come from customers of consultant who read my post, and past it along to their contractors with the comments “Then, why are you charging me to program my integration?” Then, the consultant, instead of answering the question, would fire off an e-mail to me disagreeing with my take on this, and that it was causing them problems, in some cases ccing their client. Nice.

Here’s a summary, but not the exact words, of the e-mail chains:

Mr. Anonymous: Your take on programming as [being] bad for integration was not based on reality. Indeed, we feel that you should program all of your integration so you have complete control over the integration component, thus why we advise our clients to hire us to create their connections specifically for their requirements.

Me: Great. No real issue with doing that, clearly with enough money and time you can solve their initial integration problem. However, my point was about the time and money it will take to continue that approach through changes in interfaces, rules and routing logic, application and database semantics, changes in services, movement to standards, etc., how are you going to handle that?

Mr. Anonymous: We have to re-development the integration component for all that; we do it all the time.

Me: I bet you do. How long does that take?

Mr. Anonymous: Typically one man month for most major changes, including testing and deployment.

Me: So, what are the costs over a 2 year period, typically?

Mr. Anonymous: It varies, but typically it’s $50K for programming services for each connected system, thus $150 K for 3 systems, and an average of $10K a month for maintenance and support, additional connections are extra. Well under what you would need to pay for a SOA or general integration technology product, and it’s custom to the client.

Me: So, that’s:

$150K + (10K*24) = $390,000 over two year, with no changes?

Mr. Anonymous: Yes.

Me: Does that see like a good investment to you considering that most SOA integration products are less than $50K and provide you with the ability to place volatility into a central domain, where you can better manage changes to all point systems, as well as the addition or deletion of systems. Moreover, do so much faster then development or redevelopment, thus providing a more agile solution that will provide more of a business advantage?

Mr. Anonymous: [No response]

Me: You there?

Mr. Anonymous: [No response]

Sometimes all you have to do is hold up a mirror.

Posted by davel in | Permalink | Comments (1)

Orchestration must provide dynamic, flexible, and adaptable mechanisms to meet the changing needs of the domain. This is accomplished through the separation of process logic and the abstract services employed. The loosely coupled nature of orchestration is key, since there are no requirements for all services to be up-and-running at the same time in order for orchestrations to run. This is also essential for long running transactions. Also, as services change over time, there is typically no need to alter the orchestration layer to accommodate the changes. At least, not if they are architected properly.

Orchestration has the following properties:

• A single instance of orchestration typically spans many instances of services and even organizations.
• Most orchestrations leverage public standards such as BPEL.
• Orchestrations may be public--available to everyone, private--available just to the owner, or shared--for supply chain integration scenarios.
• Orchestrations are usually driven from a single party; they are not always collaborative in nature.
• Orchestrations themselves may become services that are available for other services or orchestrations (as mentioned above).
• Orchestration is independent of the source and target systems. Changes can be made to the orchestration without having to force changes to the source or target systems. In other words, this architecture is loosely coupled.
• Orchestrations are always decomposable down to base processes within the source or target systems.

Posted by davel in | Permalink | Comments (0)

I just got off the phone with a friend of mine who is looking to connect their existing enterprise accounting system to an ERP service provider, an SaaS. They are using a consulting organization who told my friend that he had a “very simple integration issue” and that they could “program the connections for about $50 K.” Thus, “he did not need an integration product.” Arrrrrg!

Okay, I’m very sensitive about this because I wrote a book about this about 10 years ago, and still people miss the larger points, and are indeed making the same mistakes today. It’s almost like the 1980s are making a comeback, so much so I’m looking for the mullet haircuts. The fact is the rise of SaaS means that integration is a new issue with many smaller and more naive enterprises, and many are making poor decisions about integration.

Here we go again:

Say you need to connect your existing ERP systems up to your SaaS CRM system; both have well defined interfaces, either proprietary or Web services, for instance. While you can certainly pay a couple of guys for a couple of weeks to program the interaction with the interfaces, and the movement of the information from one system to another, and it may indeed work (at first), you’ll find the approach is fundamentally flawed. Why?

The core issue is that the volatility of the integration can not be addressed in a single domain, but they do it with code, at the point. Thus, as semantics change, interfaces change, systems are added and deleted, than it’s a reprogramming and testing job each an every time. Integration should be a configuration exercise, not a programming exercise, especially when considered in the context of a SOA.

The end result when you try to program to success is an ongoing maintenance programming exercise that ends up costing many times the cost of the first programming effort, thus why consulting firms like to sell integration programming. Moreover, lacking core integration tools such as transformation, routing, adapters, flow control, transactions, etc., means that your programming solution won’t be a complete solution, and thus not effective in the long term. In fact, could cost you more than money, such as customers that leave after you drop their orders 3 or 4 times due to bad integration.

So, just say no to programming. It’s always a dumb idea, and those consultants out there selling programming for integration should be ashamed of themselves, and the SaaS providers need to know better as well.

As for those that need integration, and consider programming as a viable solution, there should be some sort of intervention that needs to occur before they toss good money after bad, or worse, it cost them customers.

Posted by davel in | Permalink | Comments (2)

SOA Expert Podcast Show 38...Connecting to the Global SOA Talk

Listen to the latest SOA Expert Podcast

Presentation can be found here:

Download file

Posted by davel in | Permalink | Comments (0)

SOA Expert Podcast Show 37...AJAX and SOA Carcast

Listen to the latest SOA Expert Podcast

Posted by davel in | Permalink | Comments (0)

With the advent of Web services and SOA, and the need to leverage dynamic behavior within the interfaces, traditional browsers fall way short. Their get/push model for driving interfaces is not as well suited for SOAs, which are--at their essence--remote functions, and are better suited for more visually rich types of interfaces, such as more traditional GUI client/server interfaces that were popular a few years ago.

Rich clients are not a revolution, but an evolution of technology, including AJAX. Today we look to leverage dynamic behavior and deliver that experience directly to the end user, aggregating Web services within an interface that appears as much like a native application as possible.

As stated above, rich clients employing AJAX provide capabilities that thin clients are not able to provide, including windowing features and data navigation control such as buttons, check boxes, radio buttons, toggles and palettes. They are also able to integrate content, communications, and platform-independent application interfaces for distribution through emerging SOAs. The rich client using AJAX becomes a Web services/SOA terminal of sorts, allowing applications to communicate and even execute on one another within a distributed environment.

This is great news for those of us who are developing Web services or implementing an SOA. With the use of rich clients, suddenly those services have a much higher value. Indeed, you can mix and match services within a rich client to create some very valuable applications. Perhaps, someday, the use of static and dynamic HTML and heavyweight protocols such as HTTP will not be the primary way we view distributed applications. Rich clients give us the ability to view applications that look and act like native client programs, albeit they are running remotely. That would be step in the right direction, and the reason AJAX is so important to SOA.

Posted by davel in | Permalink | Comments (0)

As we look to make more practical use of Web services, the need has emerged for a better user interface; one that’s neither too fat nor too thin. An interface that allows developers to make the most out of the client’s native features, while at the same time, not bog down the client with services that are better kept at the back end. We call this new hybrid interface a Rich Client, where AJAX is an instance of rich client enabling technology.

However, let’s back up a bit. A rich client is a small piece of software that runs on the client to leverage and aggregate back-end Web services, allowing them to appear as a single, unified, native application. Indeed, a new interface is needed as both developers and end users begin to understand the limitations of traditional Web-based interfaces, which are the current interfaces-of-choice for many distributed applications.

Why a Rich Client when deploying interface within enterprises? Truth-be-told, Web interfaces, in wide use within enterprises, were never really designed to support true interactive applications. The Web was built as a content provider serving up documents and not dynamic application services. If you think about it, you’re reloading document after document to simulate an interactive application, and always have to go to the back-end Web server to request new content. Very little occurs at the client.

As the Web became popular and we looked to support business applications within the enterprise using the Web interface, we began to create new mechanisms to deliver dynamic content including dynamic HTTP/HTML pushers (e.g., CGI, ASAPI, ISAPI) and new browsers that supported complex dynamic behavior. We are at such an advanced state today, that entire enterprises run most of their relevant business applications using Web interfaces.

Posted by davel in | Permalink | Comments (0)

SOA Expert Podcast Show 36...WS-Too Much and SOA Link

Listen to the latest SOA Expert Podcast

Posted by davel in | Permalink | Comments (0)

I spotted this on ebizq.net. “Sixteen Service-Oriented Architecture (SOA) vendors today joined forces in announcing their commitment and mutual support for SOA Link, an end-to-end SOA Governance Interoperability Initiative.”

What’s this? A bunch of vendors that love us? My, the world is wonderful. Indeed, SOA Link is an initiative organized by Infravio, and was created to get all of the vendors in the same room who address SOA Governance, getting them on the same page in terms of interoperability.

So, who’s part of this gang? Sixteen founding members of SOA Link include AmberPoint, Composite Software, Forum Systems, Infravio, Intalio, IONA, JBoss, Layer 7 Technologies, LogicBlaze, NetIQ, ParaSoft, Reactivity, SOA Software, SymphonySoft, webMethods and WSO2.

What’s different about SOA Link is that SOA Link does not mandate a single API or common configuration for interoperability. It’s merely a public statement by partnered vendors that they will provide interoperability, at some point, for somebody. Thus, if you believe this, a customer buying SOA Link solutions can be assured that these products will work together…all of them.

I’m not buying it. While I’m sure the intentions are good, the patterns of the past are most certainly working against SOA Link. The fact of the matter is that vendors operate in their own selfish interests, and if they can add a key feature that will get them into a few more large deals, they will do it, interoperability be dammed. Indeed we are seeing this today as other key Web service standards are deployed by vendors who are adding many proprietary extensions to get a leg up on the competition, and to get around some of the limitations of the standard.

I don’t give this thing much of a chance, but I always hope for the best. At least their hearts are in the right place.

Posted by davel in | Permalink | Comments (0)