Here’s my speaking calendar for the Fall

Next week, Intelligent Enterprise Summit, October 5th, 2005… “Strategies for Integrating and Leveraging Disparate Information Sources.”

Delphi Group Service Oriented Architecture Summit, October 19th-20th, 2005….”Why Coordination & Transactions are Key to Building an Operational SOA”

Enterprise Architectures Conference, October 25th-27th, 2005…” Understanding and Leveraging Service Oriented Architecture.”

InfoWorld SOA Executive Forum, November 7th and 8th, "SOA Reality Check"

DCI’s BPM Conference, November 8th-10th, 2005… “Creating an Integration Platform to Support BPM”

I'll blog and podcast around these events for sure.

Dave

Posted by davel in | Permalink | Comments (0)

One thing that’s missing in the world of SOA today is an organization that does a fair and impartial evaluation of the dozens and dozens of products out there that claim to meet all of your SOA needs. Truth-be-told we really don’t have anything like that right now in this space where the technologies are purchased, not donated, brought into a lab, criteria created, test planes created, and the technology run through its paces…very much like Consumer Reports does today with TVs, window replacements, and laundry detergent.

Sure, the analysts do a good job in describing the technology that’s described to them by the vendors, perhaps a few customer experiences, but I’m not sure that’s the best way to understand what the technology really is, and where it fits into a SOA stack, as well as a typical problem domain and solution pattern. That takes a lab, a lot of time, a lot of money, and some good independent evaluators. But, I think you could make a nice business out of that.

It was during my tenure as a contributor to PC Magazine that I understood the value of such detailed evaluations. We spend days on the criteria, weeks on testing, and really tried to nail the reviews, providing a balanced view of the product set, even selecting a winner. Of course, sophisticated and high priced SOA technology are not development tools, word processors, or printers, but they should be put under the same sort of rigorous testing, including ease of installation, set up, performance, scalability, and maintenance.

Indeed, you may be surprised how some of the leading solutions fall down in certain areas, even vendors that have been in the business for years. This approach gets beyond the marketing, and lays out the real capabilities that you get for your million or so dollars, considering cost of technology and services required.

I’m unable to do this, but somebody should. I think the end users would pay big to get the evaluation work done for them, and get beyond the hype down to the real capabilities of this technology set. Vendors, back me up here.

Posted by davel in | Permalink | Comments (5)

I’m reading this article this morning, and I can not help but think that IBM is blowing a huge opportunity in the SOA marketplace. Just a few key notions:

“While analysts agree that IBM has been leading the SOA charge, they also believe the tech giant has to refine its SOA message and bring its sometimes conflicting product set into harmony with that message. “

The fact of the matter is that IBM has been mixing a huge application integration and SOA cocktail for the last several years, with many acquisitions and product development efforts. However, many of the messages in support of the products are in direct conflict….something that’s leaving many IBM purists scratching their heads these days, as the SOA market explodes.

"I blame that on a lack of communication between the WebSphere and Tivoli groups,” says Burton Group vice president and research director Anne Thomas Manes who also believes IBM "missed an opportunity" with this latest SOA push.

What with all this? When you’re a company as big as IBM, with the power to reach thousands of existing customers, as well as shape an emerging market, your messages need to be clear as to where all of your technology exists within a SOA solution pattern, and how you form a SOA with that technology. However, when technology organizations get that large too many fortresses of technology are often formed, each with their own marketing messages and product strategies, and sometimes they conflict. I think that’s the case here.

So, Dave, what would you do if you ran IBM? First, I would call all of my friends and have them come over and see my new cool office. Second, I would have the mother of all off-sites with key leaders in the organization and read them the riot act about adhering to a common strategy with a consistent message to the marketplace. Finally, we would follow up the off-site with 2 days of golf. Executive privilege.

Posted by davel in | Permalink | Comments (0)

You can’t beat some of the vendors in this space. They want you to purchase their SOA products, thus they must tell you how to view the notion of a SOA. So, how do you do that? Create a reference model of course, there are dozen now. One more won’t matter. Right? Other than adding to the confusion out there, this is becoming an epidemic.

So, who are the latest reference model makers? Next week, a group of software makers, including Sonic Software, AmberPoint, Systinet and BearingPoint, will announce the creation of the SOA Maturity Model white paper. You’ll find more information here.

Why? “While SOAs have been in the public eye for years, there haven't been many publications that help people explain the cost-saving benefits of an SOA to corporations. The Sonic-led paper aims to help architects articulate the cost-benefits of using an SOA to conduct business transactions.”

Hmmmmm. What about this one? Perhaps this one. Also, you can’t forget about the standards guys such as OASIS SOA Blueprints.

Come on guys. Do something original. Instead of telling people how they should think about a concept, this time SOA, tell them how your product works as a solution pattern, including where it works best, and where it does not. The users would love that.

However, Ron Schmelzer from ZapThink, does sum things up nicely. Ron said that while best practices are definitely needed to make SOA work, "all these discreet, separate efforts are confusing end users. I suggest that these folks team up with the OASIS Reference Model and OASIS SOA Blueprints teams to coordinate their efforts and make something happen in a more cohesive way that reduces, not adds, to architect confusion around how to implement SOA best." Yep.

Posted by davel in | Permalink | Comments (0)

I saw this come across the wire today, and other legacy integration solution. As you know, integrating with existing legacy systems for a SOA is going to be a challenge, and technology like this could make it easier…perhaps.

So, how does one expose existing legacy systems for a SOA? The architect has only three choices in determining how to accomplish this with existing legacy systems:

• One, he or she can move much of the business logic to a shared server, such as an application server. Others can leverage the services at that point of integration, versus communicating directly with the legacy system. We can call this porting.

• Two, he or she can rebuild each application using an application service-sharing mechanism, such as Web services, to create a tightly coupled application that allows easy cross-accessing of application services. We can call this wrapping, or service-enabling.

• Three, you can leverage a middleware layer that’s able to translate the local proprietary services, existing in the legacy system, as open interfaces such as Web services. We can call this service abstraction.

If the architect decides that the second choice is the most attractive, he will have to “wrap” the application logic encapsulated inside both applications. To accomplish this, he will use a service sharing technology, such as Web services, so that there is a common mechanism to share application services remotely. This will require rewriting the applications and then testing them. Fortunately, this is not as daunting a task as it might appear. Tools exist for each environment to wrap each application, re-creating the applications as truly distributed systems able to share both application services and data.

The third choice is typically the most practical. By leveraging service abstraction products there are typically no changes that need to be made to the existing legacy systems, the abstraction technology is able to account for the interface differences at run time. Thus, outside applications looking to leverage the services of a legacy system invoke a Web service exposed by the abstraction layer, with the abstraction layer managing the translation of the interfaces to the legacy system. Of course there is a bit of latency when using this mechanism.

We’re going to need some good technology here.

Posted by davel in | Permalink | Comments (0)

www.soaexpertpodcast.com

Posted by davel in | Permalink | Comments (0)

I’m speaking at Java Pro Live tomorrow, doing my now famous talk on “12 Steps to SOA.” Then, I have to run for an airplane. I’m an important CEO now, I can’t be seen collecting cups, hats, bags, and other trinkets on the showcase floor. Okay, perhaps a cool mug.

What’s interesting is that this show has morphed into more of a SOA conference than a Java conference, but I think that’s a good thing. If you can believe it Java is more than 10 years old, and those that program in Java and the Java standards were really one of the first enabling technologies for SOA, after Corba that is. But, we’re not suppose to mention Corba these days.

I’m finding that most Web services, new ones at least, are written in Java and Java developers lead the game in terms of service design and implementation. Moreover, as we create new SOA and Web Service standards we can look towards the Java standards as a basis of understanding as well as how well specific notion work, such as transactions, inter process communications, and even service-oriented capabilities.

You have to look at the problems that have already been solved before you attempt to create solutions for problems that are really old. Make sense? The Java guys get it. I wonder if they will be serving coffee.

Posted by davel in | Permalink | Comments (0)

I was Google-ing for information today, when I came across this blog. I got a kick out of it. Here’s an excerpt:

“Let me be blunt here: this whole SOA hype is pure marketing-poop. I mean: every developer on the planet knows that if you have several different elements in your application (gui, business logic, perhaps even a data-layer), element E provides services for element F and F is consumer of the services of element E. That's as old as what, client-server? Similar for library L which provides a set of functionality for application A which loads L at runtime. Offering a 'service' is nothing more than offering functionality (in any form you may think of) to others.

On a sunny day, some marketing department thought it would be great if the company's products would get a new 'unique' feature. What would be better than to re-hash the current features by giving them a new name? After days of brainstorming, consulting expensive advisors and visiting hand-reading guru's, they came up with... Service Oriented Architecture, better known as SOATM©®. SOATM©® would be the unique new feature of their products, which would give them an edge on the competition! Now, in the country were I live, The Netherlands, this acronym was already taken: "Seksueel Overdraagbare Aandoeningen", which roughly translates to: "Deceases transferable through sexual intercourse". Of course an unlucky coincidence. ‘

Although I’m not as skeptical, this guy has a point. Indeed, as I’ve been saying to anyone who will listen, there is not a lot of new stuff here. Indeed I would call a SOA a good architecture, which is what it is. We’ve been attempting to do that for years.

The guy has a point. While I would not call it “marketing-poop” I would say we are reinventing old stuff with a new buzzword, with some new technology surrounding it.

Posted by davel in | Permalink | Comments (0)

www.soaexpertpodcast.com

Posted by davel in | Permalink | Comments (0)

Ya know, it’s going to be a very interesting next couple of years, I’m excited. Things are changing rapidly, especially the move towards the use of service providers. Who are they? They are enterprise applications dressed up like Web sites, but they are morphing into something much more interesting, specifically entities that provide true application services versus Web sites that appear like enterprise applications.

This is nothing new, we’ve seen the rise of Salesforce.com, NetSuite, RightNow, and about a hundred other well funded ankle biters, very much like the early days of the Web. What is new is that these guys are moving from providing canned applications with user interfaces, to a collection of Web services that are able to be leveraged inside enterprises as if they were native and local.

Salesforce.com, for instance, is making about 20 percent of its revenue just selling services, and I suspect the others are moving there quickly. So, these guys will become huge enterprise applications that are sold as a collection of services that you rent. Service you don’t need to build, nor maintain, thus enterprise applications done on the cheap as composites. It’s a beautiful thing.

What’s missing is the ability to provide an infrastructure to leverage these service providers. Critical issues have to be dealt with, including; how you leverage your existing enterprise applications with service providers, how you manage security, how you manage integration, and how you manage growth over time. Also, you need to consider synergy with your SOA strategy which is still in development.

Tough issues, but there are some good answers, thus the reason for this blog. Keep tuned in.

Posted by davel in | Permalink | Comments (0)