If you read this column and listen to my podcasts, you know that I call SOA what SOA is - an architectural pattern. In many instances, SOA is a vital component of healthy enterprise architecture. Indeed, I've provided some keynote talks around this very topic at about half-a-dozen enterprise architecture conferences to date. However, generally speaking, the enterprise architects out there still don't 'get' SOA, and they continue to do a poor-to-average job of creating enterprise architectures that...well...support their enterprise.

For the past ten years application developers have been stuck with only two desktop client choices. Traditionally, they can choose either a very thin Web-client technology implemented in HTML and CSS, or a very heavyweight thick client experience implemented using traditional client/server (C/S) technologies (e.g. Java Swing, MFC). It wasn't until the introduction of RIA technologies (e.g. AJAX, Adobe Flex, Curl, and Silverlight) and widget engines (e.g. Yahoo! Widgets and Google Gadgets) that we were given more options.

As companies continue the pursuit of reaping the cost savings and productivity enhancements offered by integrating real-time voice traffic over the corporate Wide Area Network (WAN), unified communications (UC) has found an unlikely ally: service-oriented architecture (SOA).

Some of us are ready for the Web 2.0 wave that is now breaking over us, and some of us are not. The McKinsey Quarterly just put out an insightful article, 'Eight Business Technology Trends to Watch' (registration required), that outlines eight unique business trends that will be enabled by the Web 2.0 technology wave. With apologies to the guys at McKinsey for oversimplifying their detailed work, here's my brief synopsis of their 'Big 8'

This morning I received a message from TechTarget telling me that SearchWebServices.com is renaming itself to SearchSOA.com. According to TechTarget the move is in line with a shift of attitudes and efforts within the application development community. As I've written many times, SOA is not Web Services. This move is a signal that application developers are voting with their feet.

Can afford to take just one day off, get out of your cubicle and see what other people up to these days? Is J2EE still in favor? What's this ESB is about? Have you even heard of using Flex as a Web front end of your Java applications? Do not miss an event in NYC this Monday, that is created for people who think that they are way too busy to take several days off and spend them in the class. Just take one day off and attend the Real-World Java event. The discounted rate for this event is $395. To get this discount, enter the coupon code ?JUGgold' while registering

While delivering a talk on SOA I've asked the audience the following question, 'What do you think is the driving force for implementing any technology or architecture in a decent size Enterprise?' The answers were typical: better code re-usability, accessibility? But I was looking for a different answer that has nothing to with technical merits of any technology...

Here we go again. While the paint is still wet on this new Web 2.0 stuff, many SOA vendors and large analysts firms are calling their market SOA 2.0. It's one of the silliest things I've heard in a long while, and both the analysts and vendors who use this term should be ashamed of themselves.

We are at an inflection point in the SOA roll out: with enterprises developing infrastructure and deploying services, the attention is now turning to how to deliver the services to the end user, increase service reuse, and deal with governance. The last mile of SOA needs to be bridged in order for IT to fully reap the benefits of their efforts by squeezing the last bit of ROI out of their infrastructure. To achieve this, IT needs to make SOA tangible to end users, while maintaining enterprise control and reliability.

At my firm, Infosys Technologies, I have come across several clients who are actively trying to explore, consider, adopt, embrace, or become completely immersed in SOA. Here is a typical call I've received, where our client rep says, 'Ajit, we've got a very critical meeting with the CIO of company ABC. He is very excited about moving his entire organization toward SOA. Can you come and present our SOA capabilities to the client on Monday?'

Working directly on SOA projects as an independent I'm exposed to many more organizations than when I was building technology. As such, I see some common patterns or issues emerging. The largest and most disturbing is the fact that there seems to be a huge chasm yawning between the traditional enterprise architecture crowd and those looking at the value of SOA.

The term 'architecture group' is a heavily loaded one. I've run into different scenarios at the various clients that have engaged us for consulting on their architecture strategy. In some cases, we have been asked to help seed and grow such a group. In other cases, we've been asked to put together plans to define the organization of an architecture group. And sometimes, we just supplement the existing architecture group.

When building the right project team to complete a custom solution there are many forces at work. These include business drivers, technical drivers, and organizational and political motivations. Regardless of the business or organization there are three basic rules to follow in building a team to deliver a technical solution. The first is to involve the business before the team is even assembled. Each organization has certain technology standards that govern specific tools and products that can be used on a given project.

At the end of each year, when SYS-CON informally polls its globe-girdling network of software developers, industry executives, commentators, investors, writers, and editors, our question is always the same: where's the industry going next year?

The entire premise behind the Web services paradigm is enabling access to loosely coupled services via the Web. In essence, Web services are based on a synchronous request-response type interaction. On the other hand, a client's interaction with a Web service can be synchronous or asynchronous.

Data is king in today's information-driven economy, which is why organizations are willing to spend tens or even hundreds of thousands of dollars on data integration frameworks and applications. These organizations understand two critical truths: they have yet to capitalize on the potential business value stored in relational databases, EDI, flat files, and XML-based systems; and they must seamlessly connect with customers, suppliers, and business units - all of which may store and process data in different formats - to remain competitive.

Companies that decide to invest in SOA sometimes end up going to extremes - too little or too much. Too little happens when some stakeholder latches onto the buzzword and wants to get the benefits promised. However, the environment may be too conservative to invest in the infrastructure and planning required to service-orient existing applications. In this case, an analysis concludes that business as usual is doing just fine, and that there's no need to introduce fancy technologies and platforms. A few minor tweaks to the existing infrastructure are considered sufficient to get on the SOA bandwagon.

In financial trading, if you're slow to act on an opportunity, it's gone, seized by a quicker competitor. His profit is your loss. Electronic traders can easily miss a trading opportunity because their trading algorithms failed to detect the right conditions - or didn't detect them quickly enough. So for securities trading operations dependent on automated algorithmic trading - where profit or loss is determined in less than a second - milliseconds do matter.

A few years ago, when Web services started out as a buzzword in the enterprise, the whole paradigm was associated with (and still is) associated with three concepts - SOAP, WSDL, and UDDI. Now, when enterprises are putting Web services into production, you will most likely see two out of the three stakes being driven into the ground, but I have yet to see any real adoption of the 'dynamic' part of any Web services implementation. Web services are taking root as a very feasible platform for achieving service orientation (not the only platform, mind you), but none of the clients that I have interacted with have any plan to adopt a UDDI-based service registry in the near or long term.

I caught a review in Fast Company of an interview that Craig Newmark of Craigslist had with ABC's Nightline News. I didn't see the interview myself, but Fast Company did a good job highlighting the more important points, including the fact that Craigslist, which offer free classified ads, is killing the local newspapers.

One of the biggest barriers to SOA adoption is fear of not meeting the high demands of the runtime environment coupled with the need to provide business agility. As more layers have been introduced by the components of the new technology stacks, the points of failure in distributed application have multiplied. While the IT side of the house is very enthusiastic about the plethora of features provided by technologies typically associated with the SOA stack - object-orientation, process orchestration, Web services, business rules, and so on - the business side of the house is usually hesitant to invest substantially in new territories that may lead to high risk for existing businesses.

I know what you're thinking: SOA hype has reached an absurd level and now someone is literally proclaiming that it will change the world - but bear with me for a minute. Anyone who has been around corporate IT for the last five years or so has seen an avalanche of development work sent offshore for two primary reasons: cheaper unit labor cost and the flat-out inability to find qualified American developers. Also, the mainstay system development model whereby business units built up app silos, which served to minimize reuse and increase integration complexity, demanded a way to deal with the cost of its own inefficiency.

'So much can go wrong if all stakeholders are not in complete sync - in both the kitchen renovation and SOA world,' writes John Crupi. Currently in the process of renovating his kitchen, he keep seeing similarities between renovating a kitchen and building a SOA. Read on for his brilliant analogy...

Ask 10 people the question: What is SOA? You will most likely get 10 different answers. Chances are that in more than 50 percent of the cases, the word 'Web services' will be a part of the answer. Another 20 percent will talk about process orchestration, XML, integration, and so on. All of these answers definitely describe either the elements of SOA or the components used for the implementation of SOA. One of the technology paradigms that does not instantly come to mind though is 'business rules.'

It never ceases to amaze me how ambiguity in the definition of simple terms can lead to design choices that have a huge impact on the success of projects. Recently I had a long discussion with a colleague at a client site, where we are in the process of assessing the artifacts that have been created for a Web services-based service-oriented architecture. While we are talking about terms and definitions, let us be clear about the fact that there is a paradigm called service-oriented architecture, and there is a platform on which it can be realized called Web services. Often the two are confused. They are definitely not the same. One is a concept, the other is a technology platform.

Last month I talked to a couple of vendors who are making new inroads in the services arena through open source offerings. Open source support in Web services is definitely very heartening. While the frameworks and utilities for implementing Web services in enterprise applications have matured, the standards of critical functions of promoting the 'service bus' concept, which decouples Web services from the realization of an SOA, and the effective deployment and management of services, are still evolving. ESB as a concept has caught on very well in architecture discussions and vision, but I haven't seen too many examples of where large enterprises have actually implemented the design in their applications.

BEA, IBM, Oracle, SAP, Iona, Siebel and Sybase today announced their united support for a new specification for building and packaging applications called 'Service Component Architecture' or SCA ? characterized as 'a deployment descriptor on steroids' by those close to the spec.

Timely delivery of a quality Web services solution requires functional testing at each layer, throughout the development process. New test automation solutions empower insurance domain experts to verify critical business processes at each phase and layer of delivery.

Christopher Wilson explores the things to watch out for in the workplace that might be sure signs that it's time to move on from your current IT gig. Included in his analysis are three major mistakes to look for in your manager. 'Take any of these as a sign that it is time to have that interview suit dry cleaned,' writes Wilson.

It seems as though as soon as the open source community rallies around a technology, the IT industry starts taking it more seriously - and finds practical application for it. Ironically, although organizations like the concept, despite the maturation of the open source community in a variety of platforms and technologies, adoption of open source products in large organizations is still an uphill battle. The good news is that mainstream vendor products are now based on a combination of open source technologies, and so mature products from the community are finding homes in many corporations.

I know I shall be accused of being old-fashioned, but sometimes in order to understand the present, let alone the future, one of the very best starting-places is the past. Take for example the present surrounding Web services. The best clue to what is happening right now comes from a philosopher, the English philosopher and political economist John Stuart Mill.

Over the last few years, Web services and SOA have made a lot of inroads into not only the IT departments of large enterprises, but also into the minds of the business owners of different LOBs (Lines of Business). SOA is more than Web services; it is the mantra for bridging the gaps and walls between IT and business.

As organizations bravely venture into the world of Web services, they grapple with the age-old question - where do we begin? The main challenge that I have seen with key stakeholders looking to move towards the agile enterprise is solving the dilemma of which approach to take, top down or bottom up.

Over the last couple of years, the industry has rallied around SOA and its main realization platform - Web services. While many of the clients I meet are still wary about the adoption of new technology, integration dilemmas posed by the variety of software and hardware platforms has led them to buy into the promise of improving on business agility through SOA. The ubiquitous nature of Web services is something that even business owners appreciate, as they have been burned before by the disparity in the technologies that their applications have been based on.

As SOA and Web services adoption in the industry is gaining more momentum, the need to get quick wins and to show the value of adopting new (or old) paradigms is weighed against the risk of facing the repercussions of slapping something together in a quick and dirty fashion and paying the higher cost later. Many of our smart clients (not to be confused with .NET smart clients) are putting together the right groups to facilitate the adoption of these new technologies across their organizations.

The enterprise service bus (ESB) is, arguably, emerging as the preeminent platform for building, deploying, and managing Web services. However, once you have created and deployed your Web services, what's the next step? For many developers, it is the orchestration of those services into composite applications and business processes. In the past, this area has proved troublesome.

I'd like to take a moment to introduce myself. I've been working with SYS-CON for about eight years now, across different publications, so when Sean talked to me about providing regular content for WSJ, I thought to myself, 'Cool.' I am also the enterprise editor for JDJ - so you should see a lot of cross-magazine content. Part of what I want to bring in as 'International Technical Editor' for WSJ is some articles from around the world.

Packaged business applications have dominated enterprise IT landscapes for over a decade. Now these products are undergoing major changes to segway into the world of Web Services. SAP has been one of the most aggressive companies in embracing this revolution. Its NetWeaver platform is an ambitious suite of integration technologies designed to morph SAP into enterprise SOAs.

A couple of months ago I got an e-mail inviting me to keynote an SOA/Web Services conference in Beijing. My immediate reaction was - 'Good. China has reached the stage where it's hosting international conferences on the subject.' Actually, 2005 marks the fourth time this particular conference is being held. While China is growing rapidly in IT, it's fairly new to the services game. My subsequent thought was - 'This is great, the pitch for service orientation is becoming a reality.'

For Christmas this year, I got just what I asked for - a new gadget. I collect gadgets, so this was nothing new, but this gadget has altered the way I live; I now live with a BlackBerry on my hip.