Real World SOA | David Linthicum | August 2007

MORE ENTRIES

August 2007

August 28, 2007 | Comments: (0)

SOA ROI Survey Analysis

Download file

Posted by Dave Linthicum on August 28, 2007 05:33 AM

August 27, 2007 | Comments: (0)

IBM: “ESB-oriented architecture: The wrong approach to adopting SOA”

I found this little goodie today from IBM, I had to read it twice.

"An increasingly common request from clients is to complete a project that does not use service-oriented architecture (SOA) as a whole, but instead implements only an enterprise service bus (ESB) architecture. Such an ESB-oriented architecture is easy to envision, but its success is difficult to measure. What clients requesting such projects do not understand is this: An ESB-oriented architecture does not produce business value. A project based on ESB-oriented architecture needs to be made into one based on SOA-oriented architecture to help ensure that it successfully delivers business value."

I've stated basically the same thing, so many times, but I never thought IBM would agree with me. Kudos to Bobby Woolf, WebSphere SOA and J2EE Consultant at IBM, who wrote the article. The truth seems to finally be coming out…you can't buy a SOA. Indeed, SOA is something you do, and an ESB is not an architecture, it's a mere instance of technology.

While the vendors would love you to believe that technology products make the solution, the fact is that it's a sure fire way to kill your SOA when you purchase the technology too early in the lifecycle of the architecture. SOA requires a great deal of planning and other up-front work to figure out what the issues are, and conceptually how they should be solved, before dragging any SOA technology into the enterprises…ESBs being on that list.

As Bobby Woolf concludes:

"Clients often want to build only an ESB because that involves a technology challenge without the need for messy business requirements. Building just an ESB becomes an IT field of dreams, where IT builds an ESB and then hopes some SOA will come along and use it. Such an ESB-oriented architecture loses the benefits of SOA. It does not create business value. In fact, it incurs cost without reaping immediate benefit. And it does not align IT and the business."

Amen brother.

Posted by Dave Linthicum on August 27, 2007 11:38 AM

August 22, 2007 | Comments: (0)

SOA ROI in Question?

Everyone is talking about this study from Nucleus Research stating that SOA is having limited success when considering ROI.

"Only 37% of enterprises have achieved a positive ROI from SOA deployments."

Michael Krigsman followed up with his comments here, and I suspect many will have something to say about this.

Joe McKendrick also had some interesting comments in his blog.

"Frankly, I'm surprised… that the results are that high. About 37 percent — more than a third of companies — seeing positive ROI from SOA doesn't seem too shabby, in my humble opinion. Remember, most companies are just starting to learn and implement SOA methodologies. Most don't have key performance indicators that link SOA activities to business metrics. How many other types of corporate ventures have seen results like that while still just out of the starting gate?"

In looking at the study it appears that only one data point was looked at…developer productivity. As I've found time and time again, developer productivity is just a side benefit from SOA. Indeed the core benefit is agility, or the ability to have IT work better with business. Unfortunately, agility is not an easy metric to figure out, and thus many who are implementing SOA focus too much on reuse, and not enough on the larger more strategic picture. As Joe puts it:

"Uh oh…. So far, developer productivity is the only real tangible metric most SOA efforts have been able to demonstrate — it's the most easy to capture, and the metric most obviously tied to an SOA effort. This may be where those 37 percent are getting their positive ROI.

But the promise of developer productivity boosts is not enough to get the business all excited about SOA. Enterprise-wide support for SOA hinges on the ability to demonstrate value to the business at large — more growth, revenue opportunities, and all that good stuff. These are still uncharted waters."

The larger issue is that SOA, at the end of the day, is a systemic change in the way organizations approach enterprise architecture. Thus, the benefits will only be understood when the architecture has undergone that change. I suspect those surveyed were talking about small projects, and typically projects that just stood up Web services and called it a day. There is not much benefit in doing that unless you're willing to take it to a logical conclusion, including a complete overhaul of your architecture and then measuring the value of agility and reuse at the end state.

To Joe's point, I'm also surprise the success rate was 37 percent considering the tactical nature of the projects I'm seeing today, and the unwillingness of many enterprises to turn SOA into what it really is…an architecture. Architectures take careful planning, design, as well as implementation. Moreover, the ROI is years out, but still very much worth the effort.

As Krigsman puts it:

"The takeaway: if you're considering a SOA project, meticulously plan ROI right from the start. Assuming your project rests on a solid business case, careful management will help protect that all-important business payback."

Posted by Dave Linthicum on August 22, 2007 06:49 AM

August 21, 2007 | Comments: (0)

Top 5 Reasons SOAs Succeed

Now that we know what fails, let's talk about what works.

The enterprise has invested in education. The professionals who are building the SOA are schooled in the approaches and technology needed to solve the problem. You can count on spending up to $ 30K per person to get them up-to-speed.

The enterprise has invested in hiring the right people. Many organizations attempt to leverage their existing staff to work on their SOA, not considering their aptitude for the approach. No matter how much training you provide, some just don't get it. Investing in staff is as important as investing in technology, and the best and the brightest—albeit, they cost a bit more—payback huge dividends.

The enterprise understands their requirements as well as their business case. The requirements gathering portion of understanding your SOA domain is perhaps the most important thing you can focus upon. Once understood, you can back in the appropriate technology set to solve the problem (from above). Moreover, when creating a business case, you also understand how much value the SOA is bringing into the organization.

The movement toward SOA (notice I did not say 'project') is driven by a commitment from the top. Nothing is worse than attempting to do something innovative in a highly territorial environment that spans into those environments. SOA spans territories. Thus, you need buy-in from the top of the organization, and they must have the political will to embrace change.

A proof of concept is leveraged to validate the technology. You don't know if a car works for you unless you take a test drive. The same can be said about SOA technology. You must also put performance and security into the mix.

So, learn from the mistakes of others, and from the successes as well. Go do good SOA.

Posted by Dave Linthicum on August 21, 2007 03:15 PM

August 21, 2007 | Comments: (0)

The Growth of SaaS Linked with SOA

Download file

Posted by Dave Linthicum on August 21, 2007 04:43 AM

August 19, 2007 | Comments: (0)

Top 5 Reasons SOAs Fail

1. The enterprise considers SOA a project versus what it is; a more holistic notion. Thus, management thinks they can implement an ESB or other SOA technology, and they're done. I've been ranting about this enough that I won't do it here. However, just to recap, you need to determine your requirements first, and then the technology that works to solve the problem. Common sense, one would think, but more enterprises are failing this way, or will fail this way.

2. They use 2nd tier talent. They attempt to implement SOA using people who really don't understand the concept of SOA, and perhaps never will. We know who these people are. They must be stopped. It takes education to get this stuff, and those who lack the education yet are making critical decisions are down right dangerous.

3. They are under-resourced. "Go make huge sweeping changes within our IT infrastructure, and do so with about 10 percent of the resources you really need." You can't do this on a budget, unfortunately. You have to lubricate SOA projects with money.

4. They allow the vendors to define their solution. The vendors don't understand your core business issues, and really have a conflict of interest. When you sell a hammer, everything looks like a nail. Work with vendors, make them understand your requirements, but you're ultimately responsible for the solution.

5. Requirements are not fully gathered. There is no domain understanding before the solution is developed. I've been ranting about this as well; I'll leave it alone. Use them, please.

I'll talk about the top 5 reasons SOA succeeds, tomorrow or Tuesday.

Posted by Dave Linthicum on August 19, 2007 03:11 PM

August 15, 2007 | Comments: (0)

Service Design for Service Externalization

Most of my projects are "real world," and as such things are never perfect. While most think about SOA as the design and development of these new shiny services that are perfectly designed, tested, and implemented, the real world is that most services leveraged within an SOA are from existing interfaces (e.g., APIs) that are abstracted, and exposed as services. That being the case there has not been much thinking around this approach, which is a bit different than designing and building services from scratch.

So, how to you approach service design for services that are externalized from existing interfaces? It's really a matter of understanding, defining, and designing.

Understanding

First, you need to figure out what you're dealing with. There are many types of interfaces that can potentially become services. For instance, APIS, user interfaces, transactions, and direct-to-hardware interfaces (e.g., impeded interfaces). Each type if interface requires different approaches, techniques, and enabling technology. Here, it's best to work back from the interface to a level of abstract data and behavior…that's how you'll feed your services.

Defining

Next, you need to define the interface at a high level. Typically, they produce or consume information, but may provide more direct access to behavior as well. Thus, define the structure of the information, and the functions that act upon the data. In other words, what are the raw structures, and what behaviors are externalized along with the data?

Designing

Once you understand the mechanisms to deal with the interface, and the meta-service information (data and behavior) around it, it's time to design the service. I've written a lot on service design, so I won't discuss it here. However, what is different with externalization, when it comes to service design, is that you really should consider the layers of abstraction under the service, and the unique nature of those interfaces and how they drive design.

You'll find that the interface mechanisms really control how your services are defined, designed, and implemented. For instance, it's difficult to normalize services that are bound to interfaces…one interface-one service. Therefore, it's difficult to break apart the services as autonomous units since they in essence reflect an abstraction of the interfaces, and are indeed tightly coupled to the interfaces.

Not pretty, but not ugly either. Good luck.

Posted by Dave Linthicum on August 15, 2007 03:07 PM

August 14, 2007 | Comments: (0)

Is SOA Working?

Download file

Posted by Dave Linthicum on August 14, 2007 06:55 AM

August 12, 2007 | Comments: (0)

The Future of SOA

In doing my weekly reading, I came across the transcript around the July 27^th Podcast, Briefings Direct, hosted by Dana Gartner. Just a few comment to share around the future of SOA, and especially my comments during my keynote presentation at the Open Group conference held in Austin last month.

"Our topic today is "The Future of SOA." We want to take a look at what might happen if a lot of the things we've been considering for SOA actually happen."

One of the interesting things we heard this morning from Dave Linthicum was that he's anticipating that, in as few as five years, the role of enterprise architect and the role of SOA architect will meld.

I thought that was a little ambitious, and I wonder if I could put that to our panel. Before we get into the future of SOA, we should actually determine when the future of SOA will be important."

From Beth Gold-Bernstein:

Five years is definitely ambitious. All the polls that we've done at ebizQ have shown that the market is really in the early stages of adoption. From my point of view, the sooner the SOA architect's role is rolled into enterprise architecture in terms of governance the better. It is a subpart. And it is, as Dave said, best practice in architecture. We've known that for a couple of decades, actually."

I think I agree with Beth here, indeed we are at the early stages of adoption. However, you also need to remember, this is the computer business, thus 5 years is a long time, and like other architectural concepts, such as B2B, and EAI, SOA will both influence and drive architecture in 5 years, and therefore the crossover will be complete. Trust me.

And, InfoWorld's own Eric Knorr:

"Dave had it exactly right this morning. It's something that will be subsumed within enterprise architecture, as a whole. It's part of the ongoing saga of making IT more efficient.

If you listened to Dave's keynote this morning, he also mentioned that out of the implementations that he had seen, 80 percent were in trouble. Adoption, on a broad level, is still relatively at an early stage right now.

So there is a certain danger right now in SOA in terms of the acronym and its impact on the industry. It maybe another one of these initiatives that looks like it's going to be very successful. You go through the hype curve, and then it begins to fall away. When that happens, I think it will be absorbed into enterprise architecture. The basic principles won't go away.

Everybody is gravitating toward service orientation within the enterprise, and there are all sorts of reasons why that makes sense from management and architecture reasons, redundancy development, and other things. That will continue to go on, but as a trend, it may have a definite life span -- and that may be only a couple of more years."

Actually, my first thoughts around this notion were from a discussion with Eric at the last InfoWorld SOA Conference. Indeed, buzzwords have a lifecycle, but good ideas don't. I think SOA will become one of those things that sets the groundwork for better things to come within IT.

I hope we can stop struggling tactically, and begin thinking strategically about this stuff. It's the only way to win the battles and the war.

Posted by Dave Linthicum on August 12, 2007 12:22 PM

August 10, 2007 | Comments: (0)

SOA Maturity, Who has seen it implemented?

This came in as a Google alert on SOA, a gentleman named Willem Kossen, who is an ICT Architect and Consultant at M&I/Partners.

He asks the question:

"SOA Maturity, Who has seen it implemented?"

He goes on to clarify, and I'll see what I can do to help him.

"I see SOA implementations daily. Most of them are either software products that use SOA internally or very small 'limited number of services' Low Hanging Fruit type implementations. What I don't see are:
Full blown SOA based implementations "

You have something there. As I've been stating, most of those calling projects "SOA" are largely JBOWS, and really provide no value. Therein is the current crisis in this emerging area, misunderstanding about what qualifies as a solution. You don't see too many "SOAs" that are actually SOAs, and unless you're able to take the project to a complete solutions-oriented conclusion, that investment won't find much return. Having said that I can point to a few of my clients that are moving quickly to "Full blown SOA." It takes time, planning, and hard work. No shortcuts here.

"2. Thorough and working SOA governance."

Working? Yes. Thorough? Not really. SOA governance takes a lot of planning, time, and effort. You can't just toss a SOA governance system at it and hope for the best. That's what has been going on lately. I'm sure the SOA governance vendors will chime in here.

"3. Full scale inter-company or inter-[organization] type SOA information exchange "

Sure, this is occurring but typically not between SOAs. It's more service to service, typically from JBOWS to JBOWS.

"4. Total efforts to transfer Legacy applications to SOA participants to achieve full scale SOA"

Sure, this is working, but typically just around exposing services. I just completed a project with Legacy applications as the majority of the services employed.

"5. Working Middleware / information brokers / enterprise service buses supporting nearly all functionality in a SOA environment"

Sure they are there, but define "SOA environment." To your point above, most are not leveraged within a complete SOA solution, more around simple integration.

"6. Fully implemented BPM on top of a full SOA implementation."

Yep, a few of my clients have them running, and they are working great. I'm sure the vendors will chime in here, so look out.

"Do you actually are or know someone that qualifies and is willing to share knowledge?"

My honest answers, good questions.

Thanks.

Posted by Dave Linthicum on August 10, 2007 06:57 AM

August 08, 2007 | Comments: (0)

Strategic SOA 'outpacing tactical Web services for ROI'

This article by Rich Seeley, who interviewed me for the article, appeared in Tech Target yesterday discussing the results of that Aberdeen survey I discussed, both on my blog and Podcast.

"Organizations investing in a 'full SOA infrastructure,' reported better results in terms of lower application development and maintenance costs and high end user satisfaction, than those doing tactical Web services, according to the Aberdeen survey. The report, 'SOA Middleware Takes the Lead: Picking Up Where Web Services Leaves Off," covered results of a worldwide survey of 150 organizations and concluded that investment in enterprise service bus products, as well as registries and repositories pays off."

The fact of the matter is that SOA is something you do, not something you buy. Thus, when thinking about SOA a long term strategic plan is best, albeit few seem to be chasing the strategic value of SOA just yet.

"Linthicum, who emphasizes the importance of taking a strategic approach to SOA with detailed planning prior to any product purchases, said he believes the vendors in the space would do well to follow a more strategic approach. In fact, he believes they could actually sell more products that way.

'I agree with Aberdeen that you need to have middleware technology to be successful with SOA,' Linthicum said. 'However, I'm not sure there's a direct correlation with what you spend and the success. The direct correlation is how much planning work is done before you select a technology, and select the right technology, not just buy technology.'"

Clearly, everyone I still thinking technology first, and strategy second, and that just won't scale. Thus, you'll find that there will be two major mistakes being made: Those that stand up JBOWS, and call it an SOA. Or, those that purchase a ton of technology, before understanding their own issues, and call that successful. Both approaches will be expensive, and will require a lot of additional work to find the value.

Posted by Dave Linthicum on August 8, 2007 02:35 PM

August 08, 2007 | Comments: (0)

SOA is Strategic...Get Me?

Download file

Posted by Dave Linthicum on August 8, 2007 07:19 AM

August 03, 2007 | Comments: (0)

SOA Beginning to Pay Off

According to this IT organizations that made the investment in SOA infrastructure significantly outperforming companies that develop only web services, or JBOWS, according to a new benchmark report from Aberdeen Group.

"The report, 'SOA Middleware Takes the Lead: Picking Up Where Web Services Leaves Off,' is based on a survey of more than 150 organizations worldwide. In the study, best-in-class companies were twice as likely to have deployed SOA middleware as those that use only web services. Performance was measured in application development and maintenance costs, and in overall end-user satisfaction.

"'IT organizations that are succeeding have realized that enterprise-level infrastructure investments are necessary,' said Perry Donham, Aberdeen's director for enterprise applications research and the report's author. 'Groups that are deploying applications in silos, even when those silos are a mix of web services and SOA, are suffering from the lack of an enterprise-wide messaging infrastructure.'"

Okay, anybody have the same thought I did?

"This just in…fire is hot."

I'm not sure that anybody ever questioned the fact that just a bunch of Web services is even indeed an SOA…it's not. In case you were wondering, and I hope that nobody out there thinks any different, but just the fact that this survey was done leads me to believe that there is still a lot of education that needs to occur.

Just to be clear, you have to turn those services into solutions, and for that you need orchestration, process, binding services, governance, etc.. Just building or exposing services is analogous to creating hundreds of network connections, and never hooking up anything to them.

Posted by Dave Linthicum on August 3, 2007 11:33 AM

August 01, 2007 | Comments: (0)

SOA Domain Analysis…Do You Know What to Do?

So, what's one of the first and most difficult steps in defining your SOA? It's having a complete semantic and service level understanding of your domain, of course. While the work required is pretty straightforward, the amount of effort and time required is typically huge, and the enabling technology or tools you can employ are complex and emerging. Thus, it pays to spend some time up front planning exactly how you're going to do this step, and what tools you may use to make this job easier.

Why are we doing this? Let's face it; you can't deal with information you don't understand, including information bound to behavior (services). Thus, it is extremely important for you to identify all application semantics—metadata, if you will—and services that exist in your domain, thus allowing you to properly deal with the data and services that are there, and understand the inner workings as well. Remember, the goal here is to create a service level abstraction of the existing systems, and at this point, we're merely just figuring out what's there.

The best place to begin with service and data is with the creation of a services directory. As with other directories, this is a repository for gathered information about available services, along with the documentation for each service, including what it does, information passed to a service, information coming from a service, etc.. This directory is used--along with the now-understood application semantics--to define the points of integration within all systems in the domain.

While you could certainly do this using Word, Excel, or other small databases, there are a few tools on the market that are beginning to show up to provide you with a repository or registry customized for SOA, typically with other features added in as well.

So, what's the difference between an SOA repository and an SOA registry? An SOA repository is a persistence mechanism that stores information published to an SOA registry. An SOA registry is a resource that enterprises share to publish, discover, and consume Web services. Content such as XML Schemas, Document Type Definitions (DTD) and Web Services Description Language (WSDL) documents can be persisted in an SOA repository, which is then used in an SOA registry.

If you get this right, you're setting a good foundation for your SOA…trust me.

Posted by Dave Linthicum on August 1, 2007 06:36 PM

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