Real World SOA | David Linthicum | December 2007

MORE ENTRIES

December 2007

December 31, 2007 | Comments: (0)

SOA Report Podcast Continues Next Week…

Stay tuned for my predictions for 2007, and more tough love.

I hope everyone has a Happy New Year! Be careful.

Dave

Posted by Dave Linthicum on December 31, 2007 03:30 AM

December 27, 2007 | Comments: (0)

Are you the “Christmas Geek?”

Off the SOA topic for this one, but perhaps interesting to SOA people nonetheless.

I've noticed that there is a role that's been emerging over the last few years, one of a "Christmas Geek." Perhaps you're one, and you don't even know it.

I love technology, always have, always will. Like many of you in your 40s, I started with computing as a hobbyist when I was a teenager, building computers, programming computers, and trading computers with friends. In college, besides more core computer courses, I repaired computers, wired networks, configured software, debugged operating systems, and supported a small office in a telecom company on nights and weekends (they actually made me wear a tie). When I entered the executive ranks, I found myself still involved with technology, both as somebody who enjoyed playing with new technology, but also as a contributing editor for PC Magazine and working inside of ZD Labs. In other words, I dig understanding things, and figuring things out for myself. I'm perhaps much like many of you.

What's occurred recently is that the number of high tech toys that are given as Christmas gift is off the charts. iPods, iPhones, GPSs, laptops, hi def TVs, are under the trees these days. However, what's missing is somebody to actually show the recipients how to use them, or work around the inevitable problems that arise. Of course, the support lines are closed, you can't get a "geeks on call" guy to the house on Christmas, so this Christmas I found myself not enjoying the day as much as fixing, debugging, and working through issues with new high tech toys for my friends and family…in other words I was a "Christmas Geek."

On Christmas day I debugged Windows so iTunes would load, created a network to support a Sling Box, enabled an iPhone so it works with an existing WiFi network, installed and configured a GPS, added a switch to create more ports on an existing router, and configured a HD TV so it was actually an HD TV. That was just the short list.

I did not get to play with my toys into the next day. Oh, the work of a "Christmas Geek" is never done.

Posted by Dave Linthicum on December 27, 2007 06:26 AM

December 23, 2007 | Comments: (0)

Larry Ellison says SOA Uptake is Slow

Just taking a break from the break to bring you this interesting tidbit I found in CIO magazine. You can read the complete article here.

In essence Oracle's CEO Larry Ellison has admitted that the rate of SOA adoption is slow.

"'While I've read [these articles], people have to understand when you have a fundamentally new computer software architecture, SOA, it takes a long time for adoption,' Ellison said. Moving to SOA is not as easy as flipping a switch, he said. "

"'It takes about 10 to 20 years before [you can] rewrite all of your applications,' he said. But Oracle sees this process accelerating in its middleware business. "

"'We think it's a long-term growth story, it's a very rapid growth story,' said Ellison. 'It takes a long time for our customers to have a majority of their applications modernized and we think this is a growth story for a decade for us,' he said."

So, there you have it. SOA is not a quick fix, but a systemic change in architecture, thus it's going to take a while before the use of the "SOA approach" is has an impact. However, this is also an indication to me that many have not yet begun the journey, and perhaps will find that they missed the train when considering the amount of work that needs to be done. Is that you?

Posted by Dave Linthicum on December 23, 2007 06:51 AM

December 18, 2007 | Comments: (0)

Tough Love for SOA Vendors

Download file

Posted by Dave Linthicum on December 18, 2007 06:36 AM

December 15, 2007 | Comments: (0)

Linthicum’s SOA Predictions for 2008

It seems that pundit predictions are mandatory this time of year, so I'll not be an exception. So, here are my SOA predictions for 2008.

IBM will purchase one big SOA company and one small SOA company. You got to hand it to IBM, they are mixing one hell of a SOA cocktail and 2008 will mean more stocking up on ingredients. Figure one large deal, perhaps a publicly traded company, and one or more small deals, perhaps less than $100 million. Not game changing, but very interesting.
More SOA projects will highlight a lack of qualified SOA talent. The more SOA projects that move forward, the more smart people they will need. The demand for "SOA proven" architects will increase sharply, and most positions will be tough to fill with quality players. Thus, the need for training will also rise sharply.
SOA and "traditional" enterprise architecture will continue to merge. Not sure why they were ever apart, but existing enterprise architecture best practices will continue to incorporate SOA approaches and techniques. The best indication of this is the existing enterprise architecture standards bodies, such as the Open Group, rolling out more methods and approaches for SOA.
Resources on the new Web will drive many enterprises towards SOA. If you want to make your enterprise work and play well with emerging resources on the Web, you need to build a SOA. Let's face it, many of the core business processes are going to move outside of the firewall, and the ability to leverage those services is going to be a key business driver going forward.
The press will highlight huge SOA failures. There are a lot of people doing a lot of dumb things out there, and when a few of them blow up the press and bloggers will be right there to report on it. Typically, the huge SOA failures will be around those enterprises that "invested" in technology before they understood their own core architectural issues. Bad move. Learn from their mistakes.
Large consulting organizations will continue not to get SOA. Acting as channels for large technology companies, and thinking far too much around "quick fixes," many large consulting organizations will continue to miss the boat on SOA, and thus will facilitate many of the huge SOA failures I just mentioned. Seems to be a pattern to send in the senior talent to sell a project, and then parachute in the kiddies. Not a good mix when you're driving a strategic change to your IT resources…you need the best of the best.

Let's see if I'm right. I thought I was wrong once, but I turned out to be wrong. :-) Happy holidays and a happy new year.

Dave Linthicum

Posted by Dave Linthicum on December 15, 2007 05:30 AM

December 14, 2007 | Comments: (0)

Santa and SOA?

You can tell that it's a slow time a year for IT, when you see articles like Sandy Carter's post "Is Santa the Original SOA Architect?" Actually, pretty cute.

"… perhaps we could all learn some important lessons about building a service oriented architecture by taking a closer look at one of the first and most successful SOA projects. This project is representative of a Smart SOA strategy, is based in the North Pole and was initiated by Santa Claus to better manage his workshop.

Here are 10 reasons why Santa's SOA is exemplary:"

She goes on to list a few things such as:

"3. BPM support: has built in business process management (BPM) capabilities to streamline and ensure consistency of toy manufacturing and distribution."

4. Flexibility: enables The Workshop to easily anticipate and respond to sudden spikes in end-of-year activity without resulting in any hiccups in workflow.

5. Reusability: the SOA takes advantage of reusable services so that employees can accommodate consistent customer requests (dolls, teddy bears) as well as easily manage and integrate new requests (Wii, DVD player) using the same, proven best practices."

However, the best one is:

10. Everybody knows that SANTA is an acronym for the North Pole's SOA approach: Strategic Architecture, Not Tactical Achievements.

Truth be told I'm not sure Santa has anything to do with SOA based on the fact that I've never seen a turned on computer in his sleigh, and I hear that the WiFi at the North Pole is only 802.11b not 802.11g. Moreover, the need for agility is low considering that they run the same damm business processes year-to-year, not much changes. Also, I would like for the EEOC to look into the enslavement of "little people" up there. Oh sure, they look happy, but I bet they are pissed. You need happy end users to make a SOA work…you need to change the people with the technology.

So, I would love to have Santa as a SOA mentoring client, I bet I can get efficiency up at least 35 percent, and also find that Tonka Truck I wanted when I was 8 that never showed up. My parents told me it fell out of his sleigh before takeoff…we'll see.

Posted by Dave Linthicum on December 14, 2007 04:40 AM

December 12, 2007 | Comments: (0)

Where the SOA Technology Vendors are Falling Down

There seems to be a few core issues out there that are haunting most SOA vendors today. While the number of issues are complex and far reaching, I believe we can boil them down into a few key talking points, including:

• Let's talk not listen.

• We're a hammer, thus you must be a nail.

• Let's just bolt something on.

Let's talk not listen refers to the fact that many vendors are so bound to their messaging, collateral, and sales pitches that they don't seem to find the time to listen to the issues of the customer before proposing a solution. While it would be nice if everyone had the common courtesy to have a SOA problem domain that fit your definition of SOA, the truth is that enterprises are like snowflakes…no two are alike and in order to propose the correct solution you have to spend the time understanding what the native issues are. In fact, I would recommend an 80/20 rule. Spend 80 percent of your time listening, and 20 percent of your time talking. You'll be surprised how much better things go.

We're a hammer, thus you must be a nail, refers to the fact that most SOA vendors sell a particular product that does a particular thing. Thus, when looking at the unique issues of the customer, attempt to force fit the technology no matter what the architectural issues are. For instance, when selling an data integration solution all SOAs that they see are data integration problems, ignoring the need for behavior and transactional integration, even though they are needed, because those concepts don't fit into the patterns of the product.

Let's just bolt something on, refers to the fact that most vendors are attempting to sell "magical technology," that when bolted onto the existing infrastructure will indeed create an SOA. However, that never works, and in many instances they are actually making things worse by driving their existing architecture to be even that much more complex. The hard truth is that SOA, as the "A" implies is an architecture, which means a systemic change in the use and configuration of the IT resources, and in a SOA world means abstracting things as services and configuring those services into solutions. An ESB or a governance tool won't do that, it takes careful planning, execution, and selecting the right technology. There are many best practices and a true lifecycle issues to consider here, it's never just technology driven.

Posted by Dave Linthicum on December 12, 2007 06:09 AM

December 11, 2007 | Comments: (0)

Another Example of the Oversimplification of SOA

Download file

Posted by Dave Linthicum on December 11, 2007 05:08 AM

December 07, 2007 | Comments: (0)

An Example of a SOA Strategy: “Government of Canada Service Oriented Architecture Strategy - Statement of Direction”

You have to hand it to some organizations, they are indeed thinking proactively around SOA. Case is point is the "Government of Canada Service Oriented Architecture Strategy - Statement of Direction." You can find it on-line here.

From the Introduction:

"In this context "Service Orientation" is the planning and delivery of all services by formally componentizing each of the services and their subordinate services such that the overall collection of services work as a whole and supports a high level master-plan (or strategic design).

This document introduces the Service Oriented approach and the GC SOA reference model that provides all departments and agencies a statement of direction and orientation to help ensure a consistent adoption of SOA in support of a cohesive approach to service delivery across government."

In essence, they are stating a few critical things. First, that SOA is strategic and we're moving in that direction. Second, we want to do it consistently and thus why this document (site) exists. Moreover, kudos to them for putting it on the Web, that shows commitment.

In reading further:

"This document provides a statement of direction for a GC Service Oriented Architecture. The statement of direction consists of:

An announcement of CIOB's intent to place a strong emphasis on service oriented architecture;

An introduction to the concept of service orientation, its benefits and implications; and

An outline of next steps planned by CIOB to provide specific guidance in the adoption of Service Oriented Architecture across the Government of Canada."

Unfortunately, I can't really point to similar document on the US government side of things that is as specific or direct. However, that does not mean they don't exist, perhaps my blog readers can point me to a few.

What's exciting about this to me is that it's so direct, and provides specific guidance, not just "we're moving towards SOA" but how we intend to do it, and why it's important. Moreover, there is a fairly complete definition of the value, thus validating this direction.

I would urge you to read through this and perhaps use it as a template for your own SOA strategy…commercial or government.

Posted by Dave Linthicum on December 7, 2007 06:44 AM

December 05, 2007 | Comments: (0)

SOA Wins in Vegas

It was only a matter of time before the gaming industry discovered SOA, and that appears to be the case after reading this article.

"Walk down the Las Vegas Strip, and it is SOA that drives much of what the city has to offer, according to Tim Stanley, chief information officer for Harrah's, the casino and entertainment company.

"'We have eight properties in Las Vegas, and each has its own IT systems, but all eight are tied together,' explains Mr Stanley. 'A customer might be staying at Caesar's but wants a meal at Margheritaville or to go to a club. All that is connected together and recognized in our loyalty scheme, Total Rewards.'

The fact of the matter is that any problem domain and/or enterprise that are volatile by nature, casinos being an example of that, will typically benefit from SOA. In essence the agility that's built into the architecture allows the organization to shift constantly without a huge penalty in redevelopment and redeployment.

"Mr Stanley says meeting such deadlines would have been much more difficult had Harrah's had to write new applications or transfer data to its servers at the same time as keeping the casinos running."

Moreover, if you read more of the article, SOA is also leveraged to manage odds, which is basically the same thing as risk to an insurance company…it's everything.

Knowing Vegas I suspect the other hotels will jump on the SOA bandwagon, if they have not done so already. Also, they have the capital and the urgency to make the investment in SOA, which is large but well worth it once you understand the future benefits.

Posted by Dave Linthicum on December 5, 2007 07:35 AM

December 05, 2007 | Comments: (0)

A Need for SOA

Download file

Posted by Dave Linthicum on December 5, 2007 03:58 AM

December 03, 2007 | Comments: (0)

Perhaps United Airlines Needs to Look at Their IT Architecture

Sorry about the lack of blogging this week. I've been on a whirlwind tour of Rochester, NY and Ottawa, ON. I always thought myself to have good travel karma, but that all ended on the way back from Ottawa, when I experienced firsthand the problems with air travel today. Specifically, a computer outage at United Airlines - Ottawa that left travelers, let's just say, a bit on edge. However, it leads me to do some research and ask some questions…perhaps making United a good example of how IT architecture can ruin your business.

First of all, I'm not going to get into another big circle and kick the airlines. Many are already doing that these days, as delayed and cancelled flights spin out of control. Having to fly for business, as I do, I can tell you that it's about as much fun as a root canal, between the long lines in security and rude airline employees, as well as cancelled and delayed flights. But, I'm digressing.

So, upon entering the terminal in Ottawa I noticed that the line for the small United Express operation there stretched all the way to the entrance doors. Looking closer, I saw that the agents were checking people in using paper and pen. Long story short, they had no idea who had a ticket and who did not, they overbooked the flight, boarded the flight, and after figuring out they had too many passengers for the plane, kicked 3 or 4 off, including yours truly. Not sure why. However, being a million mile flyer on United, perhaps they figured I had flown enough…but…they can't figure that out can they?…the computers were down.

In doing some research when I got home, I found that this was not the first instance of outages at United. Indeed, in June 2007, United had a 2 hours outage that halted flights and frustrated passengers. Not sure how extensive the outage was yesterday, or what happened, or even how their systems are configured, I just know the damn thing did not work and as a customer I had to pay the price. However, so did the airlines. If they think this does not send loyal customers packing, they are greatly mistaken.

So, what does this have to do with SOA? Everything. What's key here is that no matter what caused the problem, the fault exists with the IT architecture. The fact of the matter is that systems should be, and need to be, setup to work around outages. In essence, creating layers services, and mechanisms to leverage those services in different ways as the need arises. In United's case, how about a Web-delivered system for use as a backup, accessing the same services as the core systems, and making those services both virtual and redundant. Thus, there is no single dependency built into the architecture, and therefore outages are dealt with as mere interface changes. In many instances, outages could be completely transparent to the user. I used this approach when building banking systems back in the 1990s. This approach is even easier today, with the service virtualization and management technology we have available.

Again, I'm not a United insider, so I have no idea what the heck happened, I'm just using United as an example of how IT architecture can get you into trouble. I would provide a general advisory that they take the following steps:

Break the architecture down to its functional level, and make sure you have a semantic-, service-, and process-level understanding before proceeding.
Divide the data and data services up into virtual redundant domains, making sure they are housed at different locations and leverage different networks. Make sure to leverage a virtual data and service management tool to handle automatic cutovers and services utilization.
Same deal with the transactional services; divide them up into virtual redundant domains that are location independent. Again, they must be managed.
Bind the data and transactional services to a primary user interface, and then to a secondary user interface. Perhaps Win32 and Web delivered, depending on the types of clients utilized.
Test the damn thing. Make sure there are no single points of failure.

Of course, the argument could be around the affordability of this SOA solution, but I would say it may pay for itself in a short period of time just by avoiding outages. You guys have enough to worry about with the weather, safety, and the normal hassles when operating an airline. Take this one off the list.

Posted by Dave Linthicum on December 3, 2007 12:34 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