SOA Expert Podcast Show 41...SOA vs. BPM and When are you Done with your SOA?

Listen to the latest SOA Expert Podcast

Posted by davel in | Permalink | Comments (0)

If you're in San Francisco, note I'll be doing the Tuesday morning keynote at the Strategies for Developing, Managing and Governing Service-Oriented Architectures, June 27-28, 2006, The Ritz-Carlton San Francisco. Here's the description:

"Morning Keynote: Steps to Success with Service-Oriented Architecture

David S. Linthicum

Many may understand the notion of SOA, but very few have any idea how to get there. Truth-be-told, there is no hard and fast rule as to how one builds an SOA in their organization. Clearly, SOA is a situational thing and your mileage may vary. However, some common patterns are emerging which may provide a guide toward implementing an SOA, either in the fast track (revolutionary) or the slow track (evolutionary)—as long as you’re on the right track. "

Stop in, say hi.

Posted by davel in | Permalink | Comments (0)

As I’m exposed to more service-oriented development projects and SOAs I’m finding that good service design, as well as how existing services are exposed, is core to success. Also, there is not much difference between good traditional application design techniques and good service design techniques, many of the same notions apply. The most important thing is to build your SOA to meet your own business requirements. That’s the test of a good design.

Of course, most services are not built as new services, they are exposed out of existing systems. So, how you expose services in that manner is a bit more involved, especially when considering granularity. In essence you’re not designing a service, but you are designing the abstractions of that service.

When exposing existing services you typically can’t decide as to what will exist as a raw service in the systems your exposing, however you can abstract them in such a way that you create a set of well designed and defined services, even if the raw (originating) services are not.

For instance, we may look to expose a very course grained service, an poorly designed API perhaps, found in an existing legacy application.. Say the pattern is: Manage Employees, which is a complete set of functions bound to a single API call or service that manages all employee data, including add, edit, validate, update, delete, etc.

We are able to expose this API as a service, but we may want to go a few steps further including breaking this service out into many independent services by building abstract services (plural) above the raw service. It’s the role of this process to make the larger more course grain service appear as fine grained or as course grained as needed for a good usable design.

Posted by davel in | Permalink | Comments (0)

Thinking over the weekend, Orchestration/BPM has the following properties:

1. A single instance of orchestration typically spans many instance of service- and information-oriented points of integration, perhaps many integration domains and even organizations.
2. Most orchestrations leverage public standards such as BPEL.
3. Orchestrations may be public, or available to everyone, private, available to just the owner, and shared, for supply chain integration scenarios.
4. Orchestrations are usually driven from a single party, they are not always collaborative in nature.
5. Orchestrations themselves may become services available for other services or orchestrations.
6. Traditional application integration typically means the exchange of information between two or more systems without much visibility into internal processes and services. In contrast, orchestration defines a meta-application, of sorts, that has visibility into many encapsulated application services (web services) as well as application information that may be bound to those services.
7. Orchestration is independent of the source and target systems. Changes can be made to the orchestration without having to force changes the source or target systems. In other words this architecture is loosely coupled.
8. Orchestrations are always decomposable down to base processes within the source or target systems.
9. Traditional application integration is typically a tactical solutions, motivated by the requirement for two or more applications to communicate. Orchestration, in context to a SOA, is strategic, leveraging business rules to determine how systems should interact and better leverage the business value from each system through a common abstract business model.

Posted by davel in | Permalink | Comments (1)

So, how do you test services you’ve not yet built? It’s called a “proof-of-concept,” meaning you stand up very raw and simplistic versions of the services (either existing abstractions or new services) for the purpose of proving that they work and to illustrate their operational characteristics. This is typically done in parallel with existing design work, and the proof-of-concept is largely a throw-away after you gather your data, but nonetheless important to your understanding of the final product before you complete the design and development.
.

Many of those who focus on the discipline of performance within complex distributed systems such as SOA will first steer you toward modeling. Unfortunately, we don’t know enough about how services behave to model how they will perform, so it’s a good idea to test the services that will make up your SOA before you build your performance model; otherwise, you’re just guessing.

Testing services, even proof-of-concept services, means that you simulate operational characteristics during the test, or, how you intend to leverage the service. You do this by building or buying test harnesses that can load the service as needed for testing. You should utilize low use, medium use, and high use scenarios to determine how the service behaves under an increasing load, and make sure you have some sort of monitoring mechanism to gather the data for analysis.

What you’ll find, in most cases, is that the service will reach a saturation point where performance drops off significantly as the load increases. The saturation point is largely dependent upon the patterns of the service. For instance, transactional services should be able to support a much higher load than light weight services.

Posted by davel in | Permalink | Comments (0)

SOA Expert Podcast Show 40...Connecting the Enterprise to the Web 2.0

Listen to the latest SOA Expert Podcast

Posted by davel in | Permalink | Comments (0)

I have to tell you, I’m hot and cold on the larger analyst firms these days, especially after many of them have combined forces during the downturn a few years ago. The heart of the problem is that the advice and data points you get from these guys are in many cases are too general to be useful, and often don’t align with reality.

Today, we have another problem. Larger firms are playing the hype game, attempting to make up as many buzzwords as they can. “SOA 2.0” was the latest instance of this, and I can name plenty others. As I’ve said before, this stuff only serves to confuse the marketplace, and really does not identify new or valuable notions. Indeed, there is push back on this type of behavior now.

So, where do you get your information if the large analysts are no longer the best place? There are a few places where I’m having luck, including the smaller “boutique” firms, many of which are made up of ex large firm analysts. These guys seem to focus more on your issues, and are not as concerned about publishing general information you can already find on the Internet, nor making up new terms.

However, bloggers seem to be the most disruptive. Bloggers seem to be the best place to find information, if you know where to look. I would say I’m getting better market data from bloggers then from the analysts these days.

Right now I’m drinking from the fire hose a bit, but it’s all worth it considering that many of the data points are pretty good, in many cases more valuable than the subscription research I’m giving from the larger firms. Also, it’s free.

Thus, we may see bloggers push out many of the larger analyst firms, very much like Craig’s List is killing newspaper classified ads today. At this point, I’m not sure that’s a bad thing.

Posted by davel in | Permalink | Comments (0)

SOA Expert Podcast Show 39...SOA 2.0 WS-Too Much and SOA Testing

Listen to the latest SOA Expert Podcast

Posted by davel in | Permalink | Comments (0)