Real World SOA | David Linthicum | February 2008

MORE ENTRIES

February 2008

February 28, 2008 | Comments: (0)

Saw this post by Galen Gruman.

"The number of companies investing in service-oriented architecture (SOA) has doubled over the past year in every part of the world, with a typical annual spend of nearly $1.4 million, according to a new research report from the analyst firm AMR Research that surveyed 405 companies in the U.S., Germany, and China."

You know, when you read something like this a letdown is coming.

"Now the bad news: 'Hundreds of millions of dollars will be invested pursuing these markets in 2008, much of it wasted,' said AMR analyst Ian Finley. The AMR survey found that most companies don't really know why they are investing in SOA, which Finley said makes long-term commitment iffy."

He goes on to site some of things you've heard from me before, namely that…

" Another danger seen from the SOA survey is that the main benefit that the vendors sell around SOA (code reuse) is not the real benefit that early SOA adopters have gotten. Often the code from project A is irrelevant to project B, he noted. That focus on reuse can cause organizations to dismiss SOA's benefits because they're looking at the wrong metric."

Of course, I've already been down this road, several times in fact. The core issue is that reuse, as a notion, is not core to the value of SOA…never has, never will. Not that you won't achieve reuse, and that there is benefit, but that the value of agility, or creating an architecture that's changeable around the needs of the business is far more valuable than any services you can share.

To the point of this post, people chase SOA understanding that reuse is the core value. Thus, when it's not they consider SOA a failure. To the point of the author "they are looking at the wrong metric." We need to stop selling reuse as a core benefit of SOA.

Posted by Dave Linthicum on February 28, 2008 11:06 AM

February 28, 2008 | Comments: (0)

Putting SOA Governance in its Place

Download file

Posted by Dave Linthicum on February 28, 2008 04:15 AM

February 26, 2008 | Comments: (0)

More on SOA Governance and Architecture

Bob Rhubart's had some interesting follow-up to my last post.

"I agree with David's assessment that the strategy of building services and then layering in SOA governance technology is unwise. The first problem with that strategy is that SOA governance should apply to the entire service life cycle, not just the determination of how existing services should be used, but also the determination of what services should be built in the first place."

"SOA governance is about organization, about clearly defined roles, processes, and policies. It's about knowing what you have and how it's being used. It's about shaping behavior to insure compliance with architectural guidelines -- and ultimately with business objectives -- at every stage in the service life cycle. Technology's role in larger SOA governance picture is to provide the tools necessary to address the responsibilities and information needs of the various roles, automate the various governance processes, and apply and enforce the appropriate policies. Technology isn't SOA governance -- technology is a tool of SOA governance. Let's not forget that other mantra: SOA governance is something you do, not something you buy."

I wish I could say I converted Bob, but he was obviously in the "you do" camp versus "you buy" camp. Not sure I was really attempting to say he was thinking differently, just commenting on the results of his survey.

Also, some confusion.

"I agree completely with David's assertion that no single technology will deliver SOA governance, but I'm a bit confused by his comment that SOA governance should be a 'small part of a more holistic solution.' When properly organized and implemented, SOA governance is the holistic solution, no? It's true that SOA governance should be a part of the larger SOA effort, but it's a critically important part. Effective, holistic SOA governance is exactly what is necessary to place the focus on architecture, and keep it there."

Yes, and no. SOA governance is indeed a part of SOA, just as governance is a part of enterprise architecture. In my way of thinking I'm really morphing all of those things together, in essence defining SOA as architecture, and architecture as holistic to the enterprise. SOA governance is a set of behaviors and disciplines with supporting technology that is powerful in the context of architecture.

Once again I think that everyone is in agreement with that. However, makes for good blogging. :-)

Posted by Dave Linthicum on February 26, 2008 07:21 AM

February 24, 2008 | Comments: (0)

Too Much Focus on SOA Governance…Not Enough on Architecture

Joe McKendrick highlights a survey completed by Bob Rhubart, in his most recent blog. Bob Rhubart published the results of an informal poll that shows that most IT managers and technologists know that governance is critical for SOA, however don't really know when you should use it. I'm working from Joe's post, since I think his insights are pretty good here.

"Governance is not here yet. Only 15% actually had a governance program up and running. Sixty-four percent were still in the 'planning/research' stage.

Three percent, in fact, declared that their SOA was flourishing without SOA. Fifty-seven percent said governance was critical, and SOA will fail without it.

The other 40% said that governance is 'somewhat' important to SOA, which is what had Bob wondering. Where's the 'tipping point' that makes it 'important'? He wonders if governance only makes a difference — and is worth the trouble — when SOA efforts hit a certain number of services, or a certain number of service consumers. 'Or are they waiting until the need becomes obvious? When they reach that point, will they regret waiting?'"

Once again we are focused too much on a single notion, rather than the holistic value of the architecture. It goes to the continued thirst for the "cool technology," and not taking an architectural approach. The fact of the matter is that when I walk into a SOA project, and the discussion goes quickly towards "what SOA governance" and not "why SOA governance" I know right away that the project is in deep trouble.

The clear path that most are taking is to build the services, and then layer in the SOA governance technology without a clear understanding of what they will do with those services. There is typically no architectural notion of how to place volatility into a domain to facilitate agility. SOA governance, at the end of the day, is good infrastructure for SOA (behavior and technology). SOA governance should be more of a best practice than anything else, and a small part of a more holistic solution. No single technology will allow you to win the game here, trust me.

Posted by Dave Linthicum on February 24, 2008 06:37 AM

February 22, 2008 | Comments: (0)

SOA…By Any Other Name

David Millman made some thought provoking points in his post, SOA - We Got the Name Wrong.

"So to shift the focus, I am renaming SOA from Service Oriented Architecture to Solution Oriented Architecture, this moves the problem front and center not the technology. Yes, we still need the various technologies to solve the solution: ESB for connection, mediation and control of the services, governance and visibility to manage and control the complete solution, and data management to ensure that all the information we use is correct. But we are now also using these and others in a combined manner to reach a complete solution."

Okay, I think I get that. However, the term "solutions oriented" has a pretty heavy list of applications over the years, and I'm pretty sure that the name will confuse things even more. I coined a term "Solutions Oriented Middleware" in the 90s, when I was CTO of SAGA (now a part of SoftwareAG), and I'm pretty sure I picked up "solutions oriented" in my tenure as a consultant in the early 90s. Who knows, who cares?

To David's point, however, the term service oriented architecture does lead many to believe that Web services are always the way. That's not really true, indeed services can be deployed using any number of technology approaches, languages, and standards. I never saw SOA as a Web services only approach. It's really just a way of doing architecture, no biggy there.

If you've seen my posts and listened to my Podcasts, you know that I believe that SOA and enterprise architecture will morph together over time, since both are really more about architecture than anything else. However, we love new TLAs, and SOA stuck before other ways of describing this approach. I guess you can call it anything.

David concludes:

"Or, perhaps, we should look at changing the acronyms completely and SOA becomes SOB - Service Oriented Business (or what you do if it fails), but my new favorite is BaaS - Business as a Service where companies would now be a service or services, but I guess nothing is that new because I can Google BaaS and get references to that too."

Not sure it really matters what you call it, as long as you do it right.

Posted by Dave Linthicum on February 22, 2008 05:55 AM

February 21, 2008 | Comments: (0)

SOA and the New Web

Download file

Posted by Dave Linthicum on February 21, 2008 03:42 AM

February 18, 2008 | Comments: (0)

Yes, There Are DSGs

Mike Kavis, had some good thoughts around my posting yesterday.

"I just read an entertaining post from Dave Linthicum called Do you Have a DSG (Dumb SOA Guy) Issue? A DSG refers to a person leading the SOA effort who has the political clout but has no clue what SOA is. If you have one of these, you could be in for a long painful and expensive journey."

"My head was nodding when I read this. I can tell you from experience over the last 18 months that the hard part is culture change, change management, and establishing governance. If you have a few smart architects and a good implementation partner like I have, the technology part can be easily conquered. The hardest part I have experienced from the technology standpoint is getting all of the tools in the stack completely integrated and stable. But even these issues are a one time hit that you have to deal with on your first implementation. "

He goes on to provide some good advice:

"The person leading the SOA initiative needs to be strong in the following areas:

Technology - must understand SOA at a conceptual level or better

Political Clout - must have a high level of influence to remove roadblocks

Business - must align technically with business drivers

People Skills - must know how to motivate and direct people"

I can't argue with that. Good thing DSGs don't read this blog. :-)

Posted by Dave Linthicum on February 18, 2008 07:24 AM

February 17, 2008 | Comments: (0)

Do you Have a DSG (Dumb SOA Guy) Issue?

I get these about once a week, an e-mail from a Yahoo or Google e-mail account that talks about issues within a large enterprise as related to building their first instance of SOA. The fact is that most of these e-mails are not around proper approaches or the right enabling technology; they are around the people issues. Specially, the emerging existence of Dumb SOA Guy(s), or what I call DSGs.

DSGs are those people (sorry ladies, I'm including you with "guys" as well) who seem to have the political power within the IT organizations, but don't have a clue as to what an SOA is, nor how to go about building one. The core issue is that the "guys" within the organization, who understand what SOA is, and how to build it, typically don't have the political skills to gain control of the projects. Also, the guys that have the political skills, and are the chosen ones for the new SOA work, don't have a clue as to what SOA is, and deal with it as a technology or system, and not what it is…architecture. I bet some heads are nodding as you're reading this post, right?

Again, the technology around SOA is simple, and I never worry about how we're going to leveraged technology to solve a problem. However, the people issues are more concerning and more difficult to fix. DSGs are out there, and I think will continue to grow as SOA becomes more and more the "important project" with high visibility to corporate leadership. I've noticed when that occurs, the DSGs move in quickly to control the projects.

Not sure how to solve this one, other than to shine a light on the problem. Leadership within the Global 2000 will have to understand it, and fix it.

Posted by Dave Linthicum on February 17, 2008 06:00 AM

February 15, 2008 | Comments: (0)

How SOA and the “New Web” are Married

Another response from an e-mail question from a blog reader: "How is SOA and Web 2.0 related?" Here is a quick response:

Web services were created around the notion that it's easier to discover and leverage somebody else's service, rather than write your own from scratch. Also, it is much easier to create applications made up of many services (composites), allowing change to occur at a pace faster than anything we've seen in the industry thus far.

The idea of Web services was to create a standard interface, programming model, description language, and a directory which would allow this to happen in and between very different systems. Indeed, today you can leverage services across the Internet that are functionally equivalent to the services being hosted locally. This is becoming a very important component to Web 2.0, or the ability to mix and match "outside-in" services for use within enterprise applications.

Taking this concept to the next level, we can build applications (composites) through the selection and use of these Web services. For instance, we have no need to write a logistics subsystem if one exists on a server someplace for you to leverage it. No need to write a risk analytics application; instead leverage somebody else's work. You get the idea. This is clearly a more traditional computing concept than something new, thus saving a ton of time in the application development process and allowing businesses, large and small, to become more agile and have a much more cost effective IT. Moreover, we can support access to valuable information as needed, when needed, within whatever application. This is the promise behind SOA, and outside-in services will clearly deliver on that promise of making SOAs more valuable.

Considering that we both understand the benefits of leveraging Web services and are willing to change our existing systems to support the exposure and leveraging of services, now what? The next step is brokering, or, allowing consumers of services to find producers of services. There are a few instances of brokers or Web service providers today, including StrikeIron. These guys provide a single stop shopping and management mechanism for those looking to consume those service. In other words, you sign up, find the service you need, download the WSDL, and you're in business.

Keep in mind that these brokers are also similar to directory and governance systems we are defining in SOAs today, however their existence on the Web means that they also provide central sharing of services, service reviews and other centralized information sharing, and the ability to support fail safe, scalability, and continuous management through economies of scale. In other words, you're able to leverage a service that somebody is always watching, and managing. That's much more than you can say for traditional enterprise systems.

These brokers, and brokers yet to emerge, will provide a few key features to facilitate consumers finding producers, and the ability to monetize this interaction, including:

A directory service where the Web services can be found, containing a description of the service, owner, technology documentation, etc..
An ability to charge for the service, either through a perpetual license, or a pay-per-drink kind of arrangement.
An ability to share reviews and other user information with other services users.
Ability to support a federated identity infrastructure.

Think of the PC before the Web. While it did have value, the Web provided the current content, and that made all the difference. The same with emerging Web. Just think services and machine to machine information exchange using standards interfaces. The world is heading in this direction quickly, and SOA not only becomes the core enabling architecture, but liberates existing information contained in legacy, as well as provides a mechanism to consume services from the Web. Indeed, SOA and the Web 2.0 are married. In fact the Web could become the mother of all SOAs very quickly.

Posted by Dave Linthicum on February 15, 2008 04:46 AM

February 13, 2008 | Comments: (0)

What is SOA Governance?

Download file

Posted by Dave Linthicum on February 13, 2008 04:56 AM

February 12, 2008 | Comments: (0)

Getting Sick of SOA Governance Yet?

Is there a better way to say SOA governance? That is the question that Michael Meehan had in Tech Target article you can find here.

"Yet let's be honest, the term 'SOA governance' sucks. It reeks of someone else telling you what to do, hectoring you over every little detail of a project. It sounds about as desirable as a colonoscopy with an IMAX camera.

It's a particularly sticky term here in the U.S.A. We don't like a lot of governance. In fact, we get uppity when we think we've been placed under the yoke of too much governance. We'll dump your tea in the harbor when that happens. In fact, you can be sure many project teams have formed some unprintable thoughts about governance without representation."

The idea is pretty sound (not the IMAX camera). In the USA we don't like architectural control, specifically any sort of behavior modification or discipline. It's a cultural thing, but at the root of how many enterprises have a dysfunctional and inefficient architecture. The trick is will people do governance, and will they understand it. I think it's pretty simple if you ask me, it's just a matter of planning and control.

"The rub comes in how to sum up all of the things that exist under the heading of SOA governance in a term that doesn't cause automatic resentment. As ZapThink's David Linthicum noted recently, SOA governance encompasses a lot of import facets in application development and management. We need to call it something. I've heard 'productivity' and 'business value' tossed around as replacement terms, but those still sound a bit too buzzwordy."

How about just a "good idea?"

Posted by Dave Linthicum on February 12, 2008 11:21 AM

February 10, 2008 | Comments: (0)

5 Things that SOA Vendors are Missing

SOA vendors are trying to figure out how to sell in this emerging marketplace. For most of them, things don't seem to be going very well. At the heart of the issue is the fact that SOA is an architecture (hence the "A"), and not a class of technology. Rather than providing tools to help build a SOA, they are selling products that could be a SOA unto itself. At the same time, the customer is pulling their hair out in total confusion.

To that end, here are 5 things that all SOA vendors should know at this point if they plan to be successful in this emerging marketplace. Just my 2 cents.

1. Make sure your product works.

Sounds like a simple thing, but many SOA vendors do not properly develop and test their products, and thus many SOA products fail when they are put into production, or even during proof-of-concept testing. At issue is the fact that, with the sense of urgency around the emerging market, many vendors push their products out the door too quickly. Thus, the products are "buggy," the customers discover that quickly, and your name is "mud." Your reputation takes a hit, and you lose the deal as well.

2. Make sure you know what SOA is.

This also sounds like a simple thing, but the fact of the matter is, most of those who sell SOA technology don't understand the first thing about SOA. They typically play "buzzword bingo," reciting terms such as "agility," "reuse," "loosely coupled," etc., and all the while they do not understand anything about their customers' issues, and perhaps not even about the content they provide.

3. Get wise about the approach to SOA.

Building on number 2, once you understand SOA and how your product fits, it's time to figure out how you and your customer should approach SOA. SOA is a complex distributed architecture, leveraging many of the traditional enterprise architecture concepts, but with some new angles, frameworks, and approaches. In essence, SOA is an architectural pattern. You need to understand how to educate and explain this to your customer. In many instances, your customer will rely upon you to be the SOA expert, or at least the SOA educator.

4. Don't sell yourself as "one stop SOA shopping."

A typical issue with SOA vendors is that they view themselves as a "SOA-in-a-box" solution. In reality, nobody is a one-stop SOA shop. SOA is an architecture. Thus, you can't sell an architecture, just the technology that makes up certain components of the architecture. So, those SOA vendors that fess up to that now will find that they have a much more creditable position with the customer versus overselling the product and not having it live up to expectations.

5. Consider the future.

Architectures are journeys, not projects, and SOA is no exception. Thus, you need to think long term when you work with a customer and a customer's architecture. That means inserting yourself at key points in the process, even after technology selection, such as working directly with any committees that exist around the architecture, user groups, and even working with your customers as they increase their knowledge of SOA, and thus your product.

Posted by Dave Linthicum on February 10, 2008 08:02 PM

February 07, 2008 | Comments: (0)

More on the SOA Governance Thing

I had a few good responses to my blog post on SOA Governance.

First, from Miko:

"This is helpful for sure, but one of the things that's worth pointing out is the fine research by Gartner which suggests that making an artificial distinction between design time and run time governance is potentially dangerous.

To quote:

'Vendors of these solutions tout their product "suites" as SOA governance platforms, but in reality, many of these products only enable some aspects of governance. To further differentiate their products from competitors', these vendors mold their messages into governing either the runtime or design-time environments. Although this differentiation helps the vendor identify potential buyers and would-be "champions" of their products, it can be detrimental because it promotes the erroneous notion that, with SOA governance, there should be two distinct and mostly separate viewpoints: development and execution.'"

The purpose of the post was to define the patterns found in SOA Governance tools, and it is indeed okay to define those patterns. Not sure it's "dangerous," just adds clarity for those looking at these tools. In essence, that was the purpose of the post. I should have been clearer about that.

More of a pushback came from Todd Biske.

"I was surprised at David Linthicum's latest blog entry. Normally, he's pretty good about emphasizing that you can't buy an SOA, but in his 'Defining SOA Governance' post, a lot of the conversation was very tool-centric. He stated the following."

"I've said it before, and I'll say it again. Governance is about people, policies, and process. Tooling really only comes into play when you start looking at the process portion of the equation. I don't want to dismiss tooling, because it absolutely is an important part of the governance equation, but if you don't have the people or the policies, tools won't help."

I'm not sure my post took "people, policies, and process" out of the mix. Indeed, I was talking about SOA Governance in the narrow (to use a term from ZapThink). The larger value of SOA governance is an approach, methods, as well as technology. Todd and I agree on that. Again, perhaps I should have been more clear about that, but the other bloggers will keep me honest.

SOA governance is indeed something you do, and there is some good technology supporting the notion of SOA governance. That technology has certain emerging patterns that allow you to better define the features and function of the tools.

Posted by Dave Linthicum on February 7, 2008 06:06 AM

February 06, 2008 | Comments: (0)

Is Big Consulting Killing SOA?

Download file

Posted by Dave Linthicum on February 6, 2008 01:13 PM

February 05, 2008 | Comments: (0)

Defining SOA Governance

SOA governance is one of those topics that mean different things to different people in the world of SOA. I'm a bit tired of briefings by governance vendors who start out the conversation with "What's your definition of SOA governance?" Thus, I've seen design repositories, directories, and even development tools sold as "SOA governance" products.

I guess I can't blame them; I mean, there is really no accepted definition of SOA governance out there. And not only are the vendors defining SOA governance in different ways, but the analysts and press are as well. So, who's right? Let's wimp out, and go to Wikipedia:

"SOA Governance is an emerging discipline which enables organizations to provide guidance and control of their service-oriented architecture (SOA) initiatives and programs."

I'll go with that one, but I have my own spin on this as well, especially considering that there are really two flavors emerging: Design time and runtime. It's important to understand the differences, and that you may indeed need two SOA governance products, at the end of the day.

Design Time SOA governance, as the name implies, typically provides an integrated registry/repository that attempts to manage a service from its design to its deployment, but typically not during runtime execution of the services, albeit some do.

Key components of design time SOA governance include:

A registry and/or repository for the tracking of service design, management, policy, security, and testing artifacts.
Design tools, including service modeling, dependency tracking, policy creation and management, and other tools that assist in the design of services.
Deployment tools, including service deployment, typically through binding with external development environments.
Links to testing tools and services, providing the developer/designer the ability to create a test plan and testing scenarios, and then leverage service testing technology.

In essence, design time SOA governances works up from the data to the services, gathering key information as it goes. Thus, you typically begin by defining the underlying data schema and turning that into metadata, and perhaps an abstraction of the data. Then working up from there you further define the services that interact with the data, data services, and then transactional services on top of that. You can further define that into processes or orchestration. All this occurring, with design time information managed within the design time SOA governance system.

Runtime SOA governance works and plays in the world of SOA management, and should be linked with design time SOA governance, but often is not. Thus we have design time, which is all about defining the policies that need to be enforced by the services and implemented by the consumer that's going to consume the services. Thus, runtime governance is the process of enforcing and implementing those policies at service run time, but may do other things as well (see below).

Runtime SOA governance, like design time SOA governance, comes in many flavors due to the number of vendors in that space and how it's being defined by that vendor. There are no defacto standards as to what runtime SOA Governance needs to be, but there are certain patterns that are emerging.

Runtime SOA governance typically supports:

Service discovery
Service delivery
Security
Setting and maintaining appropriate service levels
Managing errors and exceptions
Enabling online upgrades and versioning
Service validation
Auditing and logging

As we progress in the world of SOA, the notion of SOA governance will morph into more solid foundations of technology, and the standards around this space should mature and normalize. What's important now is the need for this technology. SOAs are indeed complex, and you have to create or implement a mechanism that's able to track and manage of the service assets within the organizations. Considering that, SOA governance systems will have to be standard equipment for most SOAs.

Posted by Dave Linthicum on February 5, 2008 05:39 AM

February 01, 2008 | Comments: (0)

IBM Agrees with Me…Good SOA People are Hard to Find

I found this article to be an interesting read this morning, specifically the data points that IBM has around the lack of SOA talent hindering the forward progress of SOA.

Here is the most interesting excerpt:

"From IBM's internal survey of F1000 executives using or considering SOA, Carter shared the following findings. [The survey was conducted during IBM's 2007 IMPACT Conference]:
56% respondents say a lack of SOA skills is 'the #1 Inhibitor' to launching and delivering SOA projects with strong business impact
About half of all respondents admit they have less than 25% of SOA skills they deem necessary to meet long term goals
80% of respondents will invest to increase SOA skills in their company this year
More than 60% of corporate executives invested in SOA-targeted retraining for both IT and Business staffs in the past year

The IBM survey findings are in accord with at least one SOA analyst firms' views: 'One dire prediction…is that there simply won't be enough qualified and SOA experienced enterprise architects (EA) around,' said a 2007 report from Zapthink."

I've been screaming about this for a few years now, and so has ZapThink. Now the data points are coming in that the lack of SOA talent is killing SOA. Indeed, the larger issue is that the wrong people are working SOA projects, and thus are being setup for failure (see below). Moreover, people are paying big bucks for SOA consultants, and they also have no clue.

The reality is that those who are attempting SOA need to have a holistic understanding of all enterprise systems, from the data to the processes, and have the ability to create an approach and process around the use of SOA concepts, in synergy with Enterprise Architecture. This needs to be done independent of the technology. This is architecture driven, not technology driven.

Another issue is the fact many of those working on SOA projects within the larger enterprises get those jobs for political reasons. It's a cool project, and if you're in good with the CIO chances are you'll get the gig. It does not matter if you're qualified or not. This is also a recipe for disaster.

So, get your talent established first. Then, do the project.

Posted by Dave Linthicum on February 1, 2008 10:06 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