Real World SOA | David Linthicum | June 2006

MORE ENTRIES

June 2006

June 29, 2006 | Comments: (0)

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 Dave Linthicum on June 29, 2006 05:36 PM

June 21, 2006 | Comments: (0)

When does SOA stop being worthwhile? Part II

Joe McKendrick elaborated on my last post pertaining to the fact that SOA will have a diminishing return, and you need to figure out when that occurs.

"In one his latest posts, David Linthicum asks a very good question that everyone will need to think about: When building a SOA, how do you know when you're done?

As with all things, the return is greatest when you start out, reaches some type of crescendo, then falls into a diminishing point of return.

There's some kind of economics curve at work here, like price elasticity, in which raising prices too high will reduce demand, and therefore revenues; and likewise, charging too low will sell a lot of product, but at a loss."

I'm not sure that is the essence of my argument, but that is indeed a new dimension. It's really about attempting to figure out when to slow down the investment in SOA...when the benefits no longer seem to be there in great numbers, or don’t equate to the incremental investment. However, I do agree with Joe's conclusion, and I'm rethinking the domain here.

"Let me throw this thought into the mix: SOA may be more about economies of scale. Perhaps the ROI comes later in the evolution, and the most expenses incurred and risks taken in the earliest years of an SOA effort, since that's when the first components for a particular service area are designed, developed, debugged, tested, and put in the registry/repository."

Joe may be on to something here. In short, he's stating that we spend the majority of the investment to build the platform, and realize the benefits in the out years as the organization leverages that platform. I can't argue with that, and perhaps the formula should change to add a new dimension, that of expected future value. However, I'm not sure how to figure that one out just yet, give me a few more weeks.

Posted by Dave Linthicum on June 21, 2006 06:10 PM

June 19, 2006 | Comments: (0)

When Building a SOA, How Do You Know When You're Done?

Just thinking over the weekend, as those building SOAs in their organization...how do they know when to stop, or slow down? I mean, you can service enable and orchestrate the entire enterprise, perhaps your supply chains as well, but I doubt the cost of doing that is going to justify the benefits on most cases. However, clearly you can do to little, and thus not get the benefits you need. You need to find a balance.

So, we are assuming that there comes a time in the implementation of a SOA when the effort has a diminishing return or the point when the amount of effort won’t produce enough value to justify continued work at the same level of effort. So, how do you figure that out?

Again, back to the core values of SOA, agility and reuse, are things you can measure (well, kind of). You may want to check out my SOA and ROI blog to get the feel of that.

So, consider the amount of effort over time as EOT, and the value of agility as VA and the value of reuse as VR. We're assuming that VA and VR change as EOT changes, over time, the trick is to determine the degree of change, or relative value, and how that relates to EOT over time.

Thus,

Relative Value = (EOT * (VA + VR)

As an example, let's say that EOT is a constant 25 percent of resources, typically as to how SOA projects work. Furthermore, we're assuming that VA diminishes by 10 percent yearly and VR diminishes by 5 percent yearly...again, back to my ROI article.

Thus,

Year EOT VA VR RV

1 0.25% 90 95 0.4625
2 0.25% 81 90.25 0.428125
3 0.25% 72.9 85.7375 0.39659375
4 0.25% 65.61 81.450625 0.367651563
5 0.25% 59.049 77.37809375 0.341067734
6 0.25% 53.1441 73.50918906 0.316633223
7 0.25% 47.82969 69.83372961 0.294158549
8 0.25% 43.046721 66.34204313 0.27347191
9 0.25% 38.7420489 63.02494097 0.254417475
10 0.25% 34.86784401 59.87369392 0.236853845
11 0.25% 31.38105961 56.88000923 0.220652672
12 0.25% 28.24295365 54.03600877 0.205697406

So, it looks like year 5 or 6 is the time when it makes sense to ramp down the efforts, else suffer diminishing return. Once again, just a set of data points to assist you in making a decision.

I'll give this some more thought. Perhaps you should as well.

Posted by Dave Linthicum on June 19, 2006 05:36 AM

June 16, 2006 | Comments: (0)

SOA Article in CIO Magazine

Christopher Koch, at CIO did a good write up on SOA. This article was more realistic than many articles on the topic, defining the real value and what’s really going on. I've always found that there is a bit of mystery when it comes to SOA, and the vendor hype is leading implementation reality. Old news, really, I've blogged about that over and over again. This article reflects that, but with better researched points.

A few tidbits:

First, there is really a problem there to be solved.

"A recent survey by the Business Performance Management Institute found that only 11 percent of executives say they're able to keep up with business demand to change technology-enabled processes—40 percent of which, according to the survey, are currently in need of IT attention. Worse, 36 percent report that their company's IT departments are having either 'significant difficulties' (27 percent) or "can't keep up at all" (9 percent)."

We all know this to be true, IT is not keeping up with the change of business, and IT executives are thrashing around looking for a magic bullet. In comes SOA. While it does define some newer approaches, enabling technology, and standards to leverage, at the end of the day this is integration and architecture, and that stuff is complex and hard to implement. Thus, no magic bullet.

The articles goes on to talk about the pragmatic aspects of SOA, including defining ROI, and figuring out what to do with your existing infrastructure. Which comes first, services or processes? How do you define and measure agility? I've taken on those topics with the SOA ROI work I've been doing, but to the author's point, there are not hard and fast metrics yet.

So, what have we learned? SOA is hard, expensive, and takes a lot of time. If there was anybody out there who did not understand this, perhaps you will now. It's a good thing that we are looking beyond the hype now, and there you’ll find the real value with realistic expectations. Now, get to work.

Posted by Dave Linthicum on June 16, 2006 06:53 AM

June 15, 2006 | Comments: (0)

Are there any Good SOA Design Tools?

You remember CASE don’t you? There were and are very powerful graphically tools that, while providing a good way to create diagrams and track metadata, really could not generate anything of value. The notion kind of died over the years, albeit CASE tools are still around today, but serve a much more tactical role, typically program design.

Enter SOA, and the need for good architecture/design tools that can work from the bottom up, or the top down, providing a central place to manage complexiity Or, in other words:

Provide a high level visual design mechanism that's able to represent services found within a problem domain, and describe those services to the tool in terms of semantics and service description. These services would be tracked in an active repository, thus when services change the repository changes as well.

Define and diagram abstraction and composites from the service layer.

Define and diagram orchestrations or processes from both services and abstractions, and generate artifacts and code for runtime. That's it.

This would be "killer technology." I’ve seen a few tools that do bits and pieces of this, but no one tool that nails this. Thus, perhaps there is an opportunity for a new company, or better yet a few combine forces to get close to SOA design heaven.

I volunteer to test the beta.

Posted by Dave Linthicum on June 15, 2006 05:19 AM

June 14, 2006 | Comments: (0)

SOA Expert Podcast Hits 1000 Subscribers

Hey, I was checking my stats and I found out that my Podcast has hit 1000 subscribers. That's either 1000 people downloading the Podcast directly, or into a "Podcatchers" such as iTunes, or one guy using 1000 different computers. I hope it's the former.

My secret to success? Absolutely no planning or quality production, I wing the whole thing on the least expensive equipment I can purchase. In fact, I did 3 Podcasts in my car driving from meeting to meeting. It's almost as if I'm trying to make people not listen, but they still do. Go figure.

Okay, what's on the agenda this week? SOA and BPM, reflecting my last blog post. This time I plan on doing my Podcast from the treadmill at the gym...not really...oh...maybe. Tune in.

Posted by Dave Linthicum on June 14, 2006 06:56 AM

June 12, 2006 | Comments: (0)

While SOA Needs BPM, and the Other Way Around

There seems to be a silly chasm developing between the SOA guys and the business process management guys (BPM), as pointed out by ZD blogger Joe McKendrick.

"Now, this ongoing process war is aligning behind two technology concepts — BPM and SOA, Koch says. The BPM folks come from the business side, and the SOA folks come from the technology side. However, he holds out new hope, but emphatically states that SOA (and the technology side) have the best chances of driving real change in the business at this point"

I can see it now, two gangs on either side of the dark street, one with black leather jackets with "West Side SOA" embroidered on the back, and the other gang wearing tank tops with process symbol tattoos all down their arms and legs, both tossing boxes of enterprise software at each other.

I do think there is a bit of "acronym envy" on the part of the BPM guys, now that SOA is getting all of the headlines and they have been off in dark rooms drawing lines and boxes for the last decade, or more. However, there is more synergy here than either camp understands right now, albeit I've been writing about it for 10 years now.

Truth-be-told the discipline of BPM is really a part of everything having to do with integration, including EAI, B2B, and yes SOA. SOA’s ultimate goal is to provide abstraction layers that works with a business process (or orchestration) layer, allowing those who want to change processes to do so at that layer, and have the changes reflect back on the underlying information flows and service invocations. Thus, they are linked, so stop trying to spin them a separate disciplines, perhaps attend each other’s conferences, and learn what each side has to offer.

Posted by Dave Linthicum on June 12, 2006 10:10 AM

June 09, 2006 | Comments: (0)

Make sure to focus on service design

At the end of the day, services are small, specific applications and need just as much attention paid to design. If SOA supports composite applications and composite processes made up of services, then the overall design of services will determine the overall success of things made out of those services...it's just that simple. Tried and true design techniques are applicable for service design as well. Please use them.

A few service patterns are beginning to emerge. We can categorize them into larger buckets, including:

Legacy abstraction services are services built on top of existing services, including elderly technology such as Cobol and CISC on the mainframes, or perhaps services liberated from mini computers, or even enterprise class Unix systems. You can toss ERP and CRM applications into this mix as well. The notion is that you somehow are able to externalize these internal processes as services and leverage them as modern Web services, no matter how ugly and arcane the interfaces are.

Simple composites are one or two services that are bound together in a new service.

Complex composites are many layers of services that are bound together; perhaps a composite that's made up of other composites.

New autonomous services are services that are created for a single purpose such as a Web service, and are typically not based on other services (non-composite).

Transactional services can be a simple or complex composite, or even new autonomous, but they support transactional characteristics including ACID (Atomicity Consistency Isolation Durability).

Data services, as you might expect, are services that are built to produce and consume data. These could be Web service abstractions on top of call level interfaces, or simple services exposed out of an ERP system that produces data. These are very simplistic services, with schemas, access controls, and the encapsulated data. Almost always these are services built on top of relational databases, but other database types are leveraged as well. Moreover, through a data services abstraction layer, you can emulate database types to meet the needs of your SOA.

Light weight services, as the name implies, means that you're doing things with a light volume (typically less than 10 invocations or messages-per-second), and the size of the message that the service is passing is small (typically less than 50 KB).

Heavy weight services, in contrast, do heavy volumes (greater than 10 invocations or messages-per-second, but more typically 100-300 invocations and message-per-second), and can transmit and consume huge messages.

Posted by Dave Linthicum on June 9, 2006 01:29 PM

June 08, 2006 | Comments: (0)

More on Performance Modeling...

So, what are the details of performance modeling? It's really comes down the information movement and services.

Information Movement Modeling, typically asynchronous in nature, means we're attempting to simulate how information moves from point to point, point to many points, or many points to many points. Based on the information we accumulated we know the:

Information production rate from a service
Information consumption rate from a service

For example, an instance of a service is able to produce 52 messages (or similar groupings of information) per second...the source service. An instance of a service is able to consume 34 messages per second...the target service. This is a simple point-to-point relationship, but keep in mind that multi-points to multi-points are always possible, and those are a bit more complex to model since you have to determine patterns of movement between multiple points vs. all messages produced by a single service that are consumed by another.

Moreover, keep in mind transformation and routing latency is typically an issue here as well, and needs to be modeled along with consumption and production. You should have test data from these services, but the performance of transformation and routing services will be largely dependent upon the complexities of the transformations and logic associated with the routing. What many do when creating performance models is to model very complex, complex, and simple transformation scenarios, and the percentages of each.

Service Invocation Modeling, typically more synchronous in nature, means we're attempting to determine the number of times a service is able to provide a behavior (application function) in an instance of time, typically a second.

For instance, you may have a service that provides a risk calculation for the insurance business, and is perhaps abstracted into several different applications (composites). We know through testing that each composite can invoke the service up to 100 times a second before it hits a saturation point, meaning the performance of the service quickly diminishes as additional load is placed upon it. This saturation number plugs into the model, as well as the number of applications that are abstracting this service. You have to model all of these services in the same way.

Making solutions scale is nothing new. However, the SOA technology and approaches recently employed are largely untested with higher application and information and service management traffic loads. SOA implementers were happy to get their solutions up and running, yet, in many cases, scalability is simply not a consideration within the SOA, nor was load testing or other performance fundamentals. We are seeing the results of this neglect now that SOA problem domains are exceeding the capacity of their architectures and the technology. It does not have to be this way.

Posted by Dave Linthicum on June 8, 2006 06:42 AM

June 07, 2006 | Comments: (0)

Performance Modeling...The Missing Piece of SOA?

I'm always surprised by those who find their first generation SOAs slow. When I dig into the architecture, and the process of getting their, I almost always find that there was little of no consideration of performance, no modeling nor testing.

Performance is a project killer, as we discovered over the years. If the SOA does not perform well, then those that leverage its edge applications, especially composites, won’t find the term "SOA" as something good. Indeed, many SOAs have gone back to the drawing board due to performance issues they did not expect, or were able to architect around.

So, how does one deal with the notion of performance with SOA? It's really a matter of check points, testing, and selecting the right enabling technology. However, much can be done using performance models, or mathematical models that will estimate the performance of your SOA before you build anything or purchase technology. You can find out all about performance modeling in this book, or just think in terms of queuing models you may have built in college. It's not new stuff.

SOAs are not unlike any other distributed computing systems, and thus designing a performance model should be nothing too new. At this point we understand exactly how each service behaves under an increasing load, and we have enough data to plug into a model. Now, it's just a matter of building a model. I'll pick up on that tomorrow.

Posted by Dave Linthicum on June 7, 2006 06:40 AM

June 05, 2006 | Comments: (0)

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

Listen to the latest SOA Expert Podcast

Posted by Dave Linthicum on June 5, 2006 02:05 PM

June 01, 2006 | 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 Dave Linthicum on June 1, 2006 06:48 AM

REAL WORLD SOA PODCAST

Listen to the latest podcast:

MP3 •