Real World SOA | David Linthicum | June 2007

MORE ENTRIES

June 2007

June 29, 2007 | Comments: (0)

Those that are creating an SOA are jumping right to services, and in most cases that's a huge mistake. I understand that the S in SOA is services, however, without a good foundation of data understanding you're creating services won't be of much use. Indeed, the foundation of a good service design is a good data design, or use of data abstraction. Without that you're putting lipstick on a very ugly pig, and you'll have to revisit the data issue at some point in the future. Thus, when you're thinking SOA, think DFSS or Data First, Services Second.

The point of DFSS is that you can't deal with information you don't understand, and that includes information bound to behavior (services). Thus, it is extremely important for you to identify all application semantics—metadata, if you will—that exist in your domain, which will allow you to properly deal with that data within the context of your SOA.

The understanding of application semantics establishes the way and form in which a particular application refers to properties of the business process. For example, the very same customer number for one application may have a completely different value and meaning in another application. Understanding the semantics of an application guarantees that there will be no contradictory information when the application is integrated with other applications at the information or service levels.

Defining application semantics is a tough job since many of the existing systems you'll be dealing with are older, proprietary, or perhaps both. The first step in identifying and locating semantics is to create a list of candidate systems. This list will make it possible to determine which data repositories exist in support of those candidate systems.

Any technology that can reverse-engineer existing physical and logical database schemas will prove helpful in identifying semantics within the problem domains. However, while the schema and database model may give insight into the structure of the database or databases, they cannot determine how that information is used within the context of the application or service.

Posted by Dave Linthicum on June 29, 2007 08:09 AM

June 27, 2007 | Comments: (0)

Still no Focus on the “A” of SOA

Back from the SOA World conference held in NYC. I was only there for a day, but enjoy my short time at the conference including meeting practitioners and vendors. I'm seeing the same people at all of these SOA conferences, including vendors and speakers. Not sure if that is good or bad.

One of the things that keep popping up in my mind was once again the lack of "architecture" when you consider "service oriented architecture." I saw this in two major ways:

First, was one of the case studies given during the general sessions. The focus was more on the technology and vendors they selected, ESB, governance, etc., and not on how they derived the solution and the method and process for doing so. At the end of the day I felt that what they really had was a JBOWS (just a bunch of Web services) with some fancy software around it. I hope they solved their business issues, but from the presentation it was not clear.

Second, was the way that the vendors on the expo floor explained their products. I asked everyone the same question: "How does one figure out how and where your product should be leveraged." In most instances I got the blank look, then back to the product pitch. In other words, they are able to define the core value of governance, development, and integration within an SOA, but don't have a clue as to what you need to do to figure out how and where their product fits. Perhaps I'm being a bit unfair talking to those who are pulling booth-duty, but this is a huge issue nonetheless.

SOA technology vendors need to teach as well as sell, and there is a difference. If I'm selling a SOA governance solution, for instance, I'm going to have the procedures, meta models, and best practices to demonstrate how my customer can both leverage my product correctly, and thus determine it's value. The issue is that you're in essence suggesting that a prospect go off do some homework before providing the PO, that's something vendors don't typically do, but should.

Keep in mind, there is no SOA without architecture, and SOA is something you do not something you buy. I'm not sure that's widely understood at this point.

Posted by Dave Linthicum on June 27, 2007 06:34 PM

June 25, 2007 | Comments: (0)

Web 2.0 and SOA and more SOA Consolidation

Download file

Posted by Dave Linthicum on June 25, 2007 08:17 PM

June 25, 2007 | Comments: (0)

SOA and Web 2.0

I'm off to NYC again to speak at the SOA World Conference and Expo. My talk is entitled: 'Web 2.0'? – It's the Universal SOA taking place tomorrow, Tuesday, at 12:40. If you're at the event stop by. I'm just doing a session, not a keynote, so I'll be "hit and run" for that conference.

Here is the session description:

"In this session we'll talk about the notion of the Universal SOA, and how to prepare your SOA to see the outside world, and the emerging Web. It's clear that many of the services we consume and manage going forward will be services that exist outside of the enterprise, such as subscription services from guys like Salesforce.com, or perhaps emerging Web services marketplaces. This is 'outside-in' SOA, in essence reusing service in an enterprise not created by that enterprise, much as we do today with information on the Web. Thus, those services outside of the enterprise existing on the Internet create a 'Universal SOA' - ready to connect to your enterprise SOA, perhaps providing more value. This is nothing new, by the way; we've been talking Universal SOA for some time now, at least the notion, and we are just seeing bits and pieces appearing today."

This is not a new subject, we've been trying to link SOA to the emerging Web for a while, and as time passes, the links are becoming more of a reality. Indeed, I think we'll see big movements in the next few months where the larger Web players, such as search engines, larger retailers, and some innovative startups will quickly move into the service provider space. Thus, with more services out there to leverage, the need to build an infrastructure that's able to consume and manage these services will drive SOA in many enterprises.

So, we'll see SOAs built in two major directions: First, those that are building SOA as an enterprise architecture improvement project, fixing fragile and static architecture so that IT can finally align with business. Second, those enterprises that are building SOA as a point of consumption and a point of production for services, which is really around the influence of Web 2.0. Of course, we'll see many SOAs that are looking to address both.

Those that are claiming to define the "new links for SOA and Web 2.0" are being a bit silly. Web services, for instance, where not really an enterprise concept, but a new Web concept from the beginning. Same can be said for UDDI, and some of the early test cases around SOA…all Web-based. So, we have a clear pattern of proving something on the Web and then dragging it into the enterprise. Indeed the Web continues to influence more than we know, and the next generation Web will continue this pattern.

Posted by Dave Linthicum on June 25, 2007 04:41 AM

June 21, 2007 | Comments: (0)

SOA Consolidation Heats Up

According to this article in Enterprise Networks and Servers, outlining research from the Butler Group, SOA consolidation will continue. Thus, those implementing SOAs need to keep a careful eye on the consolidation as they progress their SOAs into instances of technologies.

"A new report, just published by Butler Group (www.butlergroup.com), Europe's leading IT research and advisory organization, reveals the competitive nature of the market for Service Oriented Architecture (SOA) deployment technologies. According to the report, 'SOA Platforms', SOA vendors need to acquire a 'critical mass' market share in order to sustain the ongoing development investment that will be needed, and to prosper in a market that is set to become commoditized. For enterprises the adoption of SOA provides significant potential to improve the value they derive from their IT investments, in terms of increased flexibility, improved use of assets, alignment with business objectives, and reduced integration costs."

The issue really is that the SOA market is becoming more sophisticated, and in order to raise the value of your offering you need to own more in your portfolio. Clearly, IBM and Oracle have taking on this strategy, purchasing many SOA startups before they really have gotten traction. Moreover, we're seeing uber deals, such as Software AG's purchase of WebMethods. According to this report, this trend will continue if not accelerate.

So, is this good news, or bad news? Depends on who's buying whom, if you ask me. One of the things that seem to be lacking are clear and concise product plans around these larger acquisitions, or many acquisitions. In other words, what are you really going to do with the technology you just purchased, and how will that affect the consumers of that technology? Also, what's the meta-strategy going forward around your product offering? I often ask those questions to those buying up the SOA technology space and get blank looks, or worse, spin.

However, eventually the market for these "big honking SOA stacks" or BHSS, will run out of projects, and those with huge SOA portfolios will have to learn to sell down market.

"At the present time SOA vendors mainly target large enterprises, so the market is dominated by high value, low volume sales. Butler Group expects this will start to change within two or three years as the large enterprise market starts to become saturated. The need to address medium-sized enterprises will impact not just sales and marketing strategies, but will also have a large impact on the products themselves, with ease-of-use and reduced administration being prerequisites to mid-market success. In fact Butler Group expects some vendors will find it difficult to address the high volume market."

I suspect that won't be something that the larger vendors do well, and the best-of-breed players may already have taken that market by then. That is, of they are not all part of a larger player by then.

Posted by Dave Linthicum on June 21, 2007 06:40 AM

June 19, 2007 | Comments: (0)

We’re at Mile 2 in the SOA Marathon

In this recent ADT article, Kurt Mackie highlights some recent research into SOA, showing that we're still very early in the SOA game.

"A report from Research 2.0 describes the current use of service-oriented architecture (SOA) as experimental. The research firm's report of May 31, 2007 predicts that SOA will be embraced as mainstream technology by the year 2015. Packaged SOA applications will become market disruptors for companies such as Oracle, SAP and Salesforce.com, the report speculates."

So, it's 2007 and we have to wait until 2015 before SOA becomes "mainstream?" I don't think things will take that long; I do, however, think that SOA is a marathon not a sprint. Moreover, it is architecture not product, thus I don't think we'll see to many market disruptors that are products, albeit they will drive some architecture within many enterprises. I'm seeing that today with SAP. Indeed, many enterprises are creating SOAs that orbit around SAP. Not sure that's smart, by the way.

"Forester reported in a study that 21 percent of North American and European (NA-EU) enterprises said they'll adopt SOA in 2007. It also reported that 22 percent of Asia Pacific enterprises and 14 percent of NA-EU small-to-medium businesses plan to adopt SOA in 2007. However, the authors of the report, "Planned SOA Usage Grows Faster Than Actual SOA Usage," think that those figures may be optimistic because of results from an earlier survey. In 2006, 14 percent of NA-EU enterprises said they'd adopt SOA, but only two percent actually did."

I'm finding this as well. While the SOA expectations are high, there is a delta between what's being talked about and planned, and what's being implemented. I would say it's a 50 percent difference at this point. I'm sure this will change over time, but I've been finding that any relatively new concept, such as SOA, gets a lot of the "manage by magazine" crowd excited and talking. But, when implementing, they quickly understand that SOA is complex, risky, and takes a lot of smart people to get it right. I suspect that won't change for a while.

Keep running.

Posted by Dave Linthicum on June 19, 2007 05:53 AM

June 19, 2007 | Comments: (0)

Notes from the Gartner Show, and is reuse a key value for SOA?

Download file

Posted by Dave Linthicum on June 19, 2007 05:35 AM

June 17, 2007 | Comments: (0)

When Thinking Service Design...Think Integration, not Agreement

Many of those now designing and building services are stuck on what design patterns to apply to services. Keep in mind services are not applications, nor are they APIs. They are a small granular part of an application, and indeed a functional component, that should fit into many consumers, composites, processes, or applications. Get me?

Thus, the core feature that a service needs to support is the ability to work and play well deep inside of many different things, albeit being an external entity that's remotely hosted. While most of the "predicted use" of services is known, many are not know. Thus, services should be designed with this in mind.

However, in order for services to be truly useful they need to logically layer deeply into the application or composite that's leveraging the service, indeed becoming a functional component that is near native. To that end, the deeper a service can integrate or couple with the consumer, the more value that service will bring to the consumer and the SOA as a whole.

Considering that what I just said is true, the value of a service is directly related to its ability to layer into a consumer with near native capabilities. However, most of those designing and building services are focusing more on the "loose coupling" features, and create service that drive more towards logical agreement and not deep integration. This could be a mistake.

Don't get me wrong, I'm all for loose coupling when it comes to SOA, however the dimension of loose coupling may not, and should not, extend to the way services interact with consumers. Instead the focus should be on deeper integration, using different degrees of coupling, where the design patterns of the service have more value. Service coupling that means deeper meshing with the points of integration, more complex interfaces, and better coordination between service and consumer, thus more native appearing and thus having much more value.

The whole dimension of services design needs more focus, if you ask me. We're missing the boat on some larger issues here.

Posted by Dave Linthicum on June 17, 2007 04:16 AM

June 15, 2007 | Comments: (0)

SOA ROI = Dynamic Analysis

In speaking at the Gartner Show this week on SOA ROI, as well as attending some of the other sessions on the same topic, a few things became clear to me:

First, reuse is a "wash" in the world of SOA. While a valuable as a byproduct of SOA, there is typically no cost justification for building a SOA for reuse alone.

Under the concept of service reuse, we have a few things we need to determine to better define the value. These include:

The number of services that are reusable.
Complexity of the services.
The degree of reuse from system to system.

The number of reusable services is the actual number of new services created, or, existing services abstracted, that are potentially reusable from system to system.

The complexity of the services is the number of functions or object points that make up the service.

Finally, the degree of reuse from system to system is the number of times you actually reuse the services. We look at this number as a percentage.

One of the things that are true with this notion is that the weight that you place on each of these key metrics is dynamic and domain dependent, not static. Thus, you need to carefully consider the problem domain, and variables around the problem domain. For instance, while complexity is typically a representation of value, in many instances it's not. Thus, your analysis needs to be dynamic.

Moreover, the notion of agility should be consider using the same dynamic analysis. If you've been reading my stuff you'll understand that I put forth 3 key metrics to determine the value of agility as a value of SOA:

The degree of change over time is really the number of times over a particular period that the business reinvents itself to adapt to a market.
The ability to adapt to change is a number that states the company's ability to react to the need for change over time.
Finally, the relative value of change is the amount of money made as a direct result of changing the business.

While a good start, you can go well beyond these metrics to determine the value of SOA within a particular enterprise. For instance, the presence of regulation in a particular industry that limits, or drives change. Thus while there is a desire for change, and an ability to change, and a huge value to change, they can't change quickly. All of this needs to be factored in.

I'm working business cases for SOA a lot these days, including speaking at conferences such as Gartner's this week. As I discover better ways to analyze SOA ROI, I'll make sure to share them here. For now, SOA ROI is clearly something that needs dynamic analysis from somebody that's able to adjust the approach for a particular enterprise. While one size should fit all…that's almost never the case in the world of SOA.

Posted by Dave Linthicum on June 15, 2007 05:35 AM

June 12, 2007 | Comments: (0)

Gartner Application Architecture, Development & Integration Summit...SOA, SOA, SOA

I'm at the Gartner Application Architecture, Development & Integration Summit in Nashville this week, as a few of you know, perhaps you are here. The sessions have been pretty good, albeit a bit on the high level side of things…but that's what Gartner does, takes complex topics and makes them more understandable.

The highlight of yesterday was SOA Governance and the SOA Portfolio: Joined at the Hip given by Daryl Plummer. I thought that Daryl did a great job in describing a topic that has been evolving a lot lately, and indeed is often defined differently. Daryl was attempting to show the synergy between the Enterprise Architecture concept of Portfolio, as related to SOA. Moreover, how a SOA portfolio works with SOA governance solutions and approaches.

Can't say I can disagree with that, clearly we are seeing EA and SOA, both notions and technologies, beginning to morph together into something that will hopefully be more useful. I think that many enterprise architectures are too static and fragile, and something has to be done…SOA or not.

Daryl does not see the differences between runtime and design-time SOA governance, since runtime services often have to be redesigned. While I can't disagree with that, I do see many problem domains where there should be different tools and approaches for the design time and runtime side of things. Also, the SOA governance tool vendors are falling on either side right now…not sure any provide one-stop-shopping for both runtime and design-time solutions.

One of the things I see missing for Daryl's presentation, which was excellent by the way, is a step-by-step procedure for approaching both SOA governance and SOA portfolio management. Cleary, that's something that SOA Practitioner's are asking for.

Posted by Dave Linthicum on June 12, 2007 08:27 AM

June 12, 2007 | Comments: (0)

Seeking the Illusive SOA Stack

Download file

Posted by Dave Linthicum on June 12, 2007 04:43 AM

June 11, 2007 | Comments: (0)

SOA and Cancelled Flights

I speak a lot, and thus travel a lot. I've learned through the years to use a system I call being "tri-redundant." That means if I'm speaking at a conference on Wednesday afternoon, I book a flight that will get me there the day before. Also, I look at the schedule to select two other flights after that flight, that will still get me there on time for the talk, just in case. Typically, it works great, and a cancelled or delayed flight just means moving to another flight, and even another if needed.

While the system has worked well over the last 10 years of public speaking, this week it failed. I had my seminar "SOA Practitioner's Crash Course" schedule in Nashville on Sunday (yesterday), from 3:15 – 6:15 PM, so I booked the flight out the night before, with two other flights after it just in case.

Well, Saturday came with the hangover from Friday's air traffic system outage, and that flight was a no go. No worries, I'll catch the flight first thing in the morning. I showed up for that flight only to learn that the captain did not show up, thus the flight was cancelled. When attempting to get on the other flight, it was so overbooked from Saturday's cancellations they would not even let me stand-by for it, and none of the connections would get me there on time. Thus, I did not make it there, and thus did not deliver the seminar yesterday.

Not much you can do, other than to get frustrated and mad at yourself, the airline, and circumstances. The largest issue was the people who showed up on Sunday specifically to attend the course, and were told I was not showing up. I plan on catching up with most of them this week to apologize in person…I'm sure it was aggravating for them. I would have been the loudest complainer, were it me. Gartner, was very professional about the whole thing, albeit I'm sure not happy about the situation as well.

Long story/short. Garter rescheduled the seminar for Tuesday. I'm actually doing two sessions to work around the other content. Thus, if you're at the event now, could not make it to Sunday's session, and would like to attend….please see the Gartner Reps at the Nashville site. I plan on knocking it out of the park.

Posted by Dave Linthicum on June 11, 2007 06:30 AM

June 10, 2007 | Comments: (0)

Many Government SOA Projects Facing Talent Challenges

In my practice I'm doing a lot of work with the government and government contractors. I enjoy working with the government now much more than I did in the past, they are clearly more aggressive with technology and in some cases more innovative. Yes, I said it…I used "innovative" and "government" in the same sentence.

So, what's changed? The fact that IT is a strategic weapon to do more with less, and that's something many agencies are asked to do all of the time. Moreover, many see SOA has a strategic direction…again looking to align IT better with the business, or the case of government, "the mission."

However, there are some clear challenges out there as well for many agencies, and the military, namely that fact that there is a huge demand for SOA expertise, but not enough talent to drive many of the larger strategic SOA projects in the right directions. Moreover, government in many cases is leading the way. This makes the issue more drastic since you're leading, not following, and that's harder and more risky.

The core issue is that if we have any widespread problem in the world of SOA it's the fact that few understand what it is exactly, and how to go about approaching the problems. So, they typically revert to more traditional approaches that in many instances won't work, and indeed are much more costly when considering the amount of rework that has to be done, or the lost value of having an SOA.

While there are many traditional architectural concepts that carry forward to SOA, the fact is that it's a very different way of approaching architecture. We build solutions upon a foundation of services, and those services need to be defined and designed correctly, including semantics, performance, granularity, etc., else the whole thing comes tumbling down. Moreover, you have to consider new concepts such as SOA governance, orchestration, services management, and SLAs.

The deal is this. Those who are attempting to build an SOA for the government, or for the commercial world for that matter, need to understand the core concepts and the processes required to get to the desired destination.

There are few things that need consideration here:

You get what you pay for. The lowest bidder is not always the company that will make you successful with your SOA. Lower hourly rates could result in huge strategic losses down the line, both in delays, rework, and not having the benefit of your SOA in the timeframe required. Good SOA guys are expensive, but perhaps worth it, all things considered.
Planning, planning, and planning. Those that jump right into SOA without advanced planning are planning to fail, I can't say that enough. Many of the projects I'm seeing are diving right into the technology without a clear understanding of the desired outcome.
Splurge on training. Investment in SOA training pays clear dividends when considering the productivity benefits. Moreover, leverage a SOA mentor along with training is also a good idea.

SOA is a great concept for the taxpayer, considering that government has an opportunity to do much more and thus provide better services. However, the concepts behind SOA are also complex, and you'll need to right soldiers around to win those battles. Trust me.

Posted by Dave Linthicum on June 10, 2007 11:19 AM

June 07, 2007 | Comments: (0)

Approaching Information Access for the Rest of Us…Use the Browser

Truth-be-told, there are a number of limitations to the existing approaches to information access employed by today's traditional middleware and application development tools. The larger limitation is the fact that most data is unstructured. Therefore, traditional information access techniques are impossible. So, what do you do?

Traditional APIs provide access to internal application behavior and information, but have to be tightly coupled to the core application and thus to the applications that leverage the API. Moreover, APIs are typically closed approaches to information access, and don't work and play well with other information access methods without a lot of modifications.

Database access methods, such as call level interfaces (CLIs) like ODBC or JDBC, do provide advantages, but are built primarily for structured relational databases, and not unstructured information. Moreover, they are strongly typed, and thus have to change as the database changes, or, in other words, they can't react automatically to changes in the data without a lot of extra programming.

Other approaches to information access, such as FTP and queuing systems, once again are too strongly typed to work well with unstructured data. The movement of the information is static, and any attempts to alter the information will result in exceptions.

Considering the limitations of traditional interfaces when considering unstructured data, it's important to look for the least common denominator when considering an information access technique. When considering unstructured information that's externalized via Web pages, the least common denominator is the browser, or Web Integration. While most don't like to consider the browser as a point of access for their SOAs, given the fact that most information exists behind browser interfaces these days, you may not have a choice. Moreover, the technology is well tested and works well.

Web Integration is the process of leveraging the informational and functional resources of the Web in an application of your choice. There are a number of compelling reasons why such an approach is preferred:

The first and most obvious is the sheer quantity of resources that are available through the browsers, such as blogs, catalog data, even enterprise applications. This data is typically valuable and not structured for consumption by other systems. When using the Web Integration approach, the user interface is your machine interface.
Second, the Web Integration approach allows you to take advantage of existing enterprise information systems (EIS) that provide Web interfaces. Most traditional enterprise systems provide a browser-based interface, and thus are accessible when using Web Integration, no matter if they have an API or other information access mechanism, or not.

The potential here is big. Not only providing your SOA with access to structured information you paid big bucks to create, but unstructured and valuable information others paid to create…that's just cool.

Posted by Dave Linthicum on June 7, 2007 05:15 AM

June 06, 2007 | Comments: (0)

Heading to the Gartner Application Architecture, Development & Integration Summit

On Sunday I'm off to the Gartner Application Architecture, Development & Integration Summit, held in Nashville TN. I'm doing a pre-conference workshop on Sunday night, and a talk on Wednesday morning. Long week in Nashville, and I hope productive.

Some of the key things I'll be looking for when at the conference include:

Signs of synergy between the whole world of Enterprise Architecture and SOA…what are the common threads that are emerging?
New ways of thinking about integration in light of the oncoming SOA wave.
Any new leadership around the SOA space, versus the loud noises that are around today.

I typically don't attend, nor speak at Gartner events. This event was the exception, seemed very interesting to me. Also, gives me a chance to meet more SOA practitioners…I love SOA practitioners.

I'll blog as much as I can from the event. You know me, no free WiFi and I'm packing up and heading to the closest Panera.

Posted by Dave Linthicum on June 6, 2007 12:45 PM

June 05, 2007 | Comments: (0)

Those Seeking a "Standard SOA Stack" Don't Understand SOA

In this article by Rich Seeley there is clearly some debate about the emergence of the illusive "Standard SOA stack."

"While some vendors, most notably IBM, say they would like to see everyone agree on a single Web services stack -- the protocols used to define, locate, implement and make Web services interact -- it does not appear likely to happen."

This kind of stuff drives me nuts. SOA, the A meaning architecture. Thus, it's not a one instance of anything; it's an architecture that meets your requirements. The technology solution is going to fit your requirements, and requirements differ from business to business, thus the "stack" will be different from business to business, and perhaps not even leveraged Web services (gasp!).

Thus, the notion that we can create one approach and one set of enabling technologies is just silly, and those that promote the single stack approach should rethink the core concept of SOA, and how it's something you do, not something you buy, nor will it ever be a standard stack.

"Bradley F. Shimmin, principal analyst of application infrastructure at Current Analysis LLC. agreed that standardization on a single Web services stack is unlikely given competing stacks from different vendors and the heterogeneous environments of most customers. 'I don't think that will ever happen. I don't see how it could happen. It's like assuming that software will never get versioned.'"

The issue here is that the product guys are pushing technology, their technology. Thus, they are promoting a single solution approach typically around some mega SOA suite they are selling. Not that their technology is bad, that's not the issue. The issue is that each enterprise has their own needs, and the way you approach each problem domain varies greatly from domain to domain, thus no one-stop-shopping. I think the real problem here is that many are still seeking a single stack, and thus delaying the implementation of SOA. Worse, some are implementing SOA now, without doing the planning, and thus are using the wrong stack.

Sorry this world can't be that simple, but that's they way architecture works.

Posted by Dave Linthicum on June 5, 2007 05:50 AM

June 04, 2007 | Comments: (0)

Why SOA Governance Needs to Consider the Data

Download file

Posted by Dave Linthicum on June 4, 2007 09:23 PM

June 03, 2007 | Comments: (0)

Scalable SOA Solutions Continue to Emerge

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, however 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 in many instances.

My daily routine is to answer an e-mail from somebody, somewhere, asking me why their SOA does not scale. Unfortunately, the answer is something they don't want to hear. It's really the fact that they took the wrong approach, used the wrong technology, and the fix is going to be painful. However, you can avoid these issues by just doing some additional planning and testing up front before you commit to a solution.

The core issue is that many SOA technology vendors have not focused on scalability within their solutions. Instead, feature/function enhancements are the rule of the day. It's more important to add orchestration features and more adapters to your solution than to figure out how to pump more information, and manage more services. Thus, these single threaded solutions, on top of the issues around Web services in general, make for solution that are more about integration than true business transaction loads.

Dependence on the traditional architectures is the core problem of scaling SOA solutions. The most popular SOA technologies require that all information and services under management do so within a single server domain (in most cases). This processing is a mixture of service abstraction, service management, schema and content transformation, rules processing, message splitting and combining, as well as message routing (ESBs). This is despite the fact that Web services, at their essence, are more about distributed service invocation model that is not as well followed.

Why the scaling crisis around SOA is not well known at this point, considering the fact that the larger SOA projects have just started moving, there are a few vendors that I've been watching that do indeed provide the distributed architecture needed to better bring distributed reliability to SOA. Rogue Wave's HydraSCA, for instance, provides a service grid based on "Software Pipelines." Software Pipelines is an architecture and methodology that enables the development and deployment of a scaleable SOA-based application(s). Rogue Wave is promoting Software Pipelines as a cross vendor approach to service distribution, and key players are in their as well.

Software Pipelines, the approach and the instance of technology (Hydra), increases scalability by providing concurrent computing of business services within, and across servers, while preserving business rules. For those of use who've been in the business for a while, this is really common sense scalability, meaning that the processing is distributed across more than one processing entity, and thus the throughput increases using this parallel processing model. As long as this distribution is managed well…it's very effective.

There are other SOA solutions moving this direction as well, and as SOA becomes more accepted, the ability to make your SOA scale is clearly going to be on the critical path.

Posted by Dave Linthicum on June 3, 2007 05:25 AM

REAL WORLD SOA PODCAST

Listen to the latest podcast:

MP3 •

•

• Archive •

Technology White Papers

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert