September 30th, 2005

SOA innovation amid spending crunch

Posted by Britton Manasco @ 7:57 am

Categories: General

Tags:

Companies are holding the line on IT spending — even as they seek smarter ways to invest in IT innovation, according to Information Week’s annual survey of top IT users. "Average IT spending among the InformationWeek 500, at $293 million, is at its lowest level in five years," it states. As a percentage of revenue, the average IT budget was 3% for the top 100 and 2.8% for the next 400 companies on our list…This reflects strides some companies have made to cut costs through efficiency so they can spend money on new projects even though they’re working with smaller budgets."

Such trends are actually good news for SOA champions. Some of the greatest potential in SOA lies in its ability to leverage existing IT assets or even replace massively expensive ones with less costly alternatives.

Starwood Hotels & Resorts Worldwide Inc., which is mentioned in the issue, is now actively implementing its service-oriented architecture. Dubbed "Valhalla," the initiative involves transferring 750 hotels from a mainframe environment to services-based infrastructure by February. "Hopefully, this time next year, our mainframe will be very, very idle," says chief technology officer Tom Conophy.

The company now is developing roughly 150 Web services in order to manage tasks such as room-availability searches, booking processes, and loyalty registration.

The objective to enable Starwood to deliver services to "a new generation of networked televisions," which will be in hotel rooms next year. However, the Starwood continues to work to ensure that the Web services can handle the volume and won’t be exposed to the public until they can. As Conophy puts it, "The last thing we want is somebody in Zimbabwe to sell out one of our Sheratons just because he can."

September 28th, 2005

Clearing out the cobwebs

Posted by Britton Manasco @ 7:18 pm

Categories: General

Tags:

Point-to-point integration "has crippled the health and flexibility of most IT architectures by creating a cobweb of hundreds, even thousands, of brittle linkages that have to be torn apart and reassembled every time one of the applications changes," according to an excellent piece in CIO Magazine by Christopher Koch.

In a recent survey in the magazine, integration was even listed as the top technology concern of CIOs. Fortunately, we are now witnessing the emergence of "a new, winning strategy that promises to blow away the cobwebs and radically improve IT’s responsiveness (while also reducing integration costs). It is the integration layer, a virtual stratum in the architecture that is composed of two major pieces: messaging and services."

The integration layer of messaging and services lies between the presentation layer (which faces the user) and the data layer (which houses the data).

The messaging element is responsible for "translating, routing and monitoring information from different systems without these systems needing to connect directly." However, messsaging is IT-oriented, not business-oriented. That’s where services emerge — the other element of the integration layer. "The idea behind services is simple: Technology should be expressed as a unit of business work—like "get credit," or "find customer record"—rather than as an arcane application such as ERP or CRM. This is an old concept, based on object-oriented programming from the ’80s. Services extract pieces of data and business logic from systems and databases around the company and bundle them together into chunks that are expressed in business terms."

This is where a service-oriented architecture (SOA) comes into play — described in this piece as "the blueprint that guides the development of the integration layer…An SOA is the big picture of all the business processes and flows of a company. It means businesspeople can visualize, for the first time, how their businesses are constructed in terms of their technology."

Randy Heffner, vice president for Forrester Research, explains that that the integration layer enables "a change in business policy [to] be made quickly rather than opening up an application project…With business services, you are saying you are designing the business, and the design is too important to leave to ad hoc implementation teams working on a deadline."   
 
Toby Redshaw, Motorola’s corporate vice president for corporate IT strategy, architecture and e-business, says that integration costs have been cut by a factor of 10 in some cases using this approach.

However, the integration layer demands centralized IT management. As Rick Sweeney, chief architect for Blue Cross and Blue Shield of Massachusetts, explains: "SOA isn’t a technology; it’s a framework, a blueprint, and if you don’t have control over it and aren’t guaranteeing that it’s being applied across the organization, you’ll never have a true SOA. There are probably a million ways to architect an integration layer, but you can’t have a thousand different ways inside your company."

September 27th, 2005

Liquid language

Posted by Britton Manasco @ 10:26 am

Categories: General

Tags:

The award for SOA eloquence has to go to BEA Systems. (Hats off to the brand and market positioning team.) "SOA is the most powerful movement in enterprise technology today," said Alfred Chuang, chairman and chief executive officer, BEA Systems, Inc., at the company’s BEA World conference this week. "The days of business silos and software smokestacks are coming to an end, and our customers couldn’t be happier. No longer will managers have to cobble together scraps of information through dozens of phone calls, requests from corporate databases and hours of spreadsheet work. For the first time, they will be able to tap into a network of services that deliver what they need when they need it, all based on a common software infrastructure for applications and services that masks the complexity of underlying technologies."

And one can’t help but love the metaphorical imagery associated with "unthawing" today’s "frozen" assets. "SOA is a powerful reality for customers today and the real power of SOA will come from freeing ‘frozen and idle assets,’ which represent a huge part of IT spend," said Bruce Graham, BEA’s vice president of worldwide professional services. "Many of our customers are trying to deal with bad architecture that has resulted from monolithic application stacks, non-standard infrastructure and disruptive business changes. The real-world approach shows that best-of-breed and heterogeneity are just a fact of life, and thawing out those assets are key to gaining business advantage from IT."

The critics of SOA will continue to insist that BEA is merely trying to liquify our minds. All marketers, as Seth Godin would have it, are liars. Ah, but if we are going to be told a story — even if the truth falls somewhere short of the reality — we appreciate when it is done with panache.  

September 27th, 2005

SOA skepticism

Posted by Britton Manasco @ 9:09 am

Categories: General

Tags:

Not everybody believes the SOA hype, as our blog talkback section demonstrates week in and week out. And, in the spirit of free inquiry, we continue to welcome any and all skepticism (and downright rejection) of the SOA movement right here in this space. One forceful argument — "SOA Sucks!" — was recently made by Derek Ferguson of Web Services Journal.

"Now, please don’t misunderstand me," he begins. "I am not saying that there isn’t a myriad of benefits to be derived from exposing systems’ functionality for access by other automated systems simply by passing XML across industry-standard networking protocols such as HTTP and TCP. Web services are great! If you have to interoperate with non-Microsoft systems, they may be your only option. If you are building a system today and you suspect that some other system might want to tap into its functionality at some point in the future, then you are wise to architect in a way that will lend itself to exposure via Web services."

He then launches into his tirade. As Ferguson sees it, we shouldn’t embrace the idea that "that all systems should be seen either as services that expose their functionality only via unidirectional XML messaging or as clients of such systems. Specifically, I don’t think that all of our problems will be solved if we move in this direction as an industry, nor do I think that such an approach is without colossal problems of its own."

He points to problems he has seen at his with his own clients: "To begin with, the move to asynchronous system operations requires a massive change in thinking on the part of most developers. Having a separate Architect role on a team can offset a lot of this difficulty by allowing just one individual to orchestrate how a set of discrete, asynchronous services can be aggregated into various useful systems…Versioning and reliability are two problems that are more tactical, and in some ways harder to resolve. If one considers the move from COM to .NET, for example, one of the major problems that .NET was intended to solve was the so-called ‘DLL Hell’ versioning conflicts that were common in the days of COM. Many of these problems return with a vengeance when one begins to rely heavily upon external Web services, because a change in a Web service that is beneficial to one system may be quite detrimental to another system using that same Web service. Unlike .NET code that is run in process, there are no out-of-the-box standards and tools to help with the versioning of .NET Web services."

That said, he also points to ROI problems and the challenges associated with constantly shifting standards. He considers these "the difficult questions that SOA must answer if it is to remain relevant" in the coming years and beyond.

September 27th, 2005

[Fill in the blank] services

Posted by Joe McKendrick @ 8:38 am

Categories: General, Standards Watch, Web Services

Tags:

In response my posting on proposals to take the "Web" out of Web services, Loek Bakker [formerly with Capgemini] alerted me to a similar posting in which he took up the "Web" question. (Do great minds run in the same rut, or what?)

Bakker debates whether to call it Web services, XML services or just plain services:

First of all, "Web services" doesn’t exactly fit what we’re doing anymore, he writes. The "Web" in Web services implies HTTP and REST. It also implies RPC (remote procedure calls), Bakker adds, "a bad thing, I think, in general for scalable services."

"XML services" may fit, as SOAP does not need the Web. However, XML services do not require SOAP — both RSS and REST are SOAP-less protocols.

Just plain "services" creates a hairball.  Likewise, just plain "services" creates confusion with the stuff vendors are supposed to do for you. Complicating matters further, Bakker also notes that "services do not require XML" either.

Bakker’s bottom line: Use any and all of the terms, as the situation fits. "We should use the terms wisely and appropriately, and using the terms should be aimed at providing maximum clarity on what kind of services we are talking about. A lot of the naming issue depends on the abstraction level at which you look at your architecture. On a conceptual level, you get away with calling it just ’service,’ but especially when talking about the physical architecture (the implementation), it might help to precisely brand the service ‘XML Service,’ ‘SOAP Service’ or even ‘CORBA Service.’"

September 26th, 2005

Another SOA piece falls in place

Posted by Joe McKendrick @ 4:42 pm

Categories: General, Standards Watch, Vendor Watch, Web Services

Tags:

JBOWS, or Just a Bunch of Web Services, is far more prevalent than SOA, but vendors are taking the first steps toward helping companies’ systems to become less spaghetti-like and more service oriented.

Evidence of this is Oracle’s latest announcement with Systinet, a vendor specializing in UDDI-based registries. The two companies just announced an agreement in which Oracle will embed Systinet’s SOA registry within Oracle Application Server 10g Release 3, a component of Oracle Fusion Middleware. The partnership will provide Oracle customers tools for service discovery, service governance and service lifecycle management across the enterprise.

Registry is one of the key ingredients needed to make SOA work, along with an orchestration mechanism (likely BPEL), full process testing, and management/monitoring tools. UDDI is seen as the most popular option for registry, which will help producers and consumers of services determine what services exist within a particular network. Systinet Registry, based on UDDI, captures service description and usage information into a centrally managed and searchable location.

September 26th, 2005

Time to drop the 'Web' from Web services?

Posted by Joe McKendrick @ 8:38 am

Categories: General, Web Services

Tags:

Sys-Con’s Jeremey Geelan takes to task the whole meaning of the term "Web services," which he says has been a little contorted through vendor filters in recent years.

He cites the thoughts of Philip Greenspun, a now-retired computer scientist who first coined the term and saw it run amuck. "I might have coined the term but not with its current meaning," he told Geelan. "What I meant by a ‘Web service’ was what I might today call a ‘Web application,’ i.e. a Web site that does the job formerly done by a desktop app. The Microsoft .NET-style ‘Web services’ we just called ‘Web-based distributed computing’."

Greenspun says we should drop the "Web"  from Web services. "I personally think something incorporating the standard 1960s and 1970s term ‘distributed computing’ is the right one. ‘Web services’ doesn’t fit because most/much of this stuff will eventually be happening on the Internet but without what most people think of as the Web (users will not be viewing in HTML though probably HTTP will be used, so technically it could be called ‘Web’)."

The same phenomenon occurred with application servers a few years back, which were originally called "Web application servers." 

Increasingly the market is talking more and more about SOAs, and less about Web services. In fact, nobody talks about WSOAs, because Web services are but one enabling aspect of SOAs. It will only make sense that ’services’ will eventually be the operative term in this space.

September 24th, 2005

Could technology tame future Katrinas and Ritas?

Posted by Joe McKendrick @ 7:42 am

Categories: General

Tags:

We all know how much informational power technology has provided us in recent years. And we have very powerful and sophisticated systems that can draw on current and historical data to model impending hurricane events. But can we use this information and technology to actually tame these ferocious beasts? 

Ross Hoffman, a principal scientist and vice president for research and development at Atmospheric and Environmental Research (AER) in Lexington, Mass., wrote in Scientific American last year (October 2004) that it may be possible someday to head off hurricanes. Hoffman and his team took models of past hurricanes (Andrew and Iniki in 1992) and tweaked changeable variables such as temperature, and found, at least in the modeling, that the hurricanes changed course or were reduced in ferocity. "The most significant modifications proved to be in the starting temperatures and winds," Hoffman wrote. "Typical temperature adjustments across the grid were mere tenths of a degree, but the most notable change–an increase of nearly two degrees Celsius–occurred in the lowest model layer west of the storm center. The calculations yielded wind-speed alterations of two or three miles per hour. In a few locations, though, the velocities changed by as much as 20 mph because of minor redirections of the winds near the storm’s center."

Armed with real-time information and analysis of temperature variations within an approaching storm, proactive measures could be taken, such as selectively heating parts of the storm with microwaves or coating the ocean surface underneath with a layer of biodegradable oil to slow evaporation. Or, perhaps altering air traffic in days previous to hurricane events to "precisely position contrails and thus increase cloud cover."

September 23rd, 2005

The SOA glass -- 35% full, 65% empty

Posted by Joe McKendrick @ 1:09 pm

Categories: General, Web Services

Tags:

Capgemini just released a survey of 200 Oracle OpenWorld attendees that is almost ho-hum — about one-third (35%) of respondents currently say they have SOA, and a total of eight in ten (82%) plan on adoption in the near future. Surveys on hot technology areas tend to always show high rates of "planned" adoption some time off in the future, because no CIO is going to say that he or she won’t even consider the technology.

What caught my eye, however, was the composition of the survey respondents. Namely, about 41% hail from large organizations with $1 billion or more in annual revenues.  While Capgemini is hailing the results as proof that SOAs are emerging as a "new strategic reality," I think the results are telling us we have a way to go yet.

Think about it — only about a third of the largest corporations out there say they have SOAs. That means, conversely, that two out of three are SOA-less. Mind you, these are the big guys, with all the money and resources to build SOA anytime they want. And, to reiterate, eight out of ten may be saying they "plan" SOA development in the "near future," this is a vague timeline. I doubt we’ll be seeing 80% of this group with SOAs in 2006 or 2007.

Of course, SOA is not a well-defined concept, either. If you install an ESB to tie together a couple of applications, do you have an SOA?  If all of your applications support Web services standards, is that SOA? If one department builds standardized and reusable components, but nine other departments don’t use them, or aren’t even aware of them, is that an SOA?

Going back to the survey, there’s that group of 18% who not only don’t have SOA, but aren’t even considering it for the future. What’s their story?

September 22nd, 2005

BPEL battle

Posted by Britton Manasco @ 5:04 pm

Categories: General

Tags:

Tod Nielsen, a former BEA Systems marketing exec who defected to Oracle, is now bad-mouthing his old employer. Well, sort of. Actually, he’s just suggesting that BEA’s BPEL (Business Process Execution Language) capabilities are not up to snuff. BPEL, the specification for orchestration of processes in SOAs, is considered one of the next battle grounds for companies jockeying for position in the SOA arena.  

"Today, BEA doesn’t have BPEL support," Nielsen said at the recent Oracle OpenWorld conference. However, he claimed Oracle’s BPEL Process Manager tool can work with the BEA WebLogic Server application server. 

BEA quickly fired back. Bill Roth, BEA vice president of solutions and product marketing, said BEA supports BPEL in its WebLogic Integration product. But also argued that no firm standard yet exists. "I think our position is that frankly, Oracle’s making too much of BPEL," he said. "Sure, it’s a useful way of orchestration. [But] the fact of the matter is that BPEL has been approved by absolutely no standards body…We’re grateful that the Oracle folks aren’t as familiar with our product as they should be."

BPEL has been submitted to the technical committee of OASIS, a web services standards organization. However, no final standard is yet in place. "The important thing is [BPEL is] not done yet and while we look at BPEL as a promising development, Oracle users are taking a huge risk by developing on BPEL 1.1 and getting locked into something that they think is standard but isn’t," Roth said, noting that the feature set could still change.

September 21st, 2005

Microsoft: too little. IBM: too much.

Posted by Joe McKendrick @ 11:04 am

Categories: General, Vendor Watch, Web Services

Tags:

This is too ironic to pass up. The other day, I posted a piece about how Microsoft wasn’t talking up SOA enough. Now, this article by Michael Meehan in SearchWebServices.com pops up — stating that IBM is overdoing the whole SOA bit, with too many conflicting messages.

"In the wake of IBM’s latest barrage of service-oriented architecture product announcements, analysts agree that there’s a lot of Big Blue to love, but add that it could stand to go on a diet," Meehan observes.

What seems to have analysts perplexed is IBM’s delivery of not one but two enterprise service buses (ESBs) — one for heavy transaction environments, and another lightweight ESB for smaller sites.  (See "IBM gets on the bus, twice.")

Burton Group’s Anne Thomas Manes is quoted as saying that IBM should have produced an integration product that could cover all bases in growing SOAs. "Instead, it produced a minimalist ESB product with limited integration capabilities and no management functionality, and an advanced ESB product that is really an integration broker — not an ESB — and it doesn’t support management either. Meanwhile, the Tivoli product won’t be integrated with either one."

Manes also noted that "IBM would have served its customers better by sticking to its guns and making it clear that you can’t buy SOA."

Well put. That’s a message Britton and I try to convey at this site as well, and I agree that it is surprising that IBM would jump on the ESB bandwagon. SOAs are not built overnight, but are developed through an incremental and evolutionary process, in line with business needs. And that’s been IBM’s message for years.

September 21st, 2005

Success-based SaaS

Posted by Britton Manasco @ 7:11 am

Categories: General

Tags:

The failure to understand the operational challenges associated with Software as a Service (SaaS) helps to explain why the first wave of SaaS vendors crashed and burned a few years ago. Back then, such vendors called themselves application service providers  (ASP). So what’s different this time?

I’m persuaded that the Saas movement is on more stable ground thanks to the infrastructure and operational expertise of today’s SaaS enablement companies. Whether the enabler is IBM, JamCracker or OpSource, it’s clear that software companies and other fledgling Saas providers now have the capabilities available to them to develop, launch and operate a credible and scalable service on an on-demand basis. They no longer are forced to do it themselves.

The SaaS enablers are taking the movement far beyond the traditional ASP "managed services" operations that were associated with companies such as Corio and USinternetworking. To a great extent, the ASP movement was a horseless carriage. With a big nod to Marc Benioff and his relentless committment to the movement at SalesForce.com as well as other pioneering companies like RightNow and NetSuite, the business, pricing and delivery models for software are now truly being transformed.  

While there is no space to discuss all of the market differentiators and operational capabilities of today’s SaaS enablers here, one differentiator that I find particularly important is something OpSource calls "Success-based Pricing." Rather than charge its software vendor clients on a per license or per server basis, it charges them just as they would charge their customers. It is priced based on a "pay as you go, shared success model." In other words, OpSource will share the risks and rewards with its clients, enabling them to invest their precious capital in relation to actual business growth.

This is the direction the software industry needed to move. The future of the industry will revolve around deep alignment — shared risk and reward — between company and client.

Mike Mankowski, SVP, Tier 1 Research, is particulary fond of OpSource, which has lined up an array of clients such as Agile Software, Kana, and Blue Martini. But what Mankowski says of this impressive SaaS enablement provider should be applied to the SaaS movement overall. Software companies, he contends, "should take a hard look" at the approach. "It could mean the difference between life and death in the software world.”

September 19th, 2005

Make way for the loosely coupled business

Posted by Joe McKendrick @ 8:27 pm

Categories: Business ROI, General

Tags:

Make way for the loosely coupled business, run on loosley coupled services.

That’s one of the messages coming out of Teradata’s annual Partners user meeting, taking place this week in Orlando, an event attended by some of the heaviest hitters in the data management arena.

One of several compelling sessions was presented by Mohan Sawhney, professor at Northwestern’s Kellogg School of Management, on the nature of the successful organization of the near future. Essentially, the best-run companies may not be producers themselves, but networks of producers, orchestrated by a front-end broker of services.

Sawhney quipped that some mobile phone companies provide a good example of this orchestrator role, in that "they don’t do anything themselves, they just collect the money." Even Cisco comes close to this orchestrator model: "85 percent of Cisco’s products are never touched by a Cisco employee," he pointed out.   

Just as businesses are evolving into loosely coupled components, so to are the systems that support them.  "Five years from now, the concept of an application will be obsolete," Sawhney said.  "They will all be services, combined, mixed, matched and reused as needed."

Over the years, there has been a great deal of angst about the viability of the "hollow" corporation, which links processes and services to customers, but produces nothing itself. Thanks to new technologies, what was a linear supply chain is now close to being a synchronous network, affording better visibility and control over processes.

September 19th, 2005

Microsoft's SOA strategy: wait and see?

Posted by Joe McKendrick @ 6:24 pm

Categories: General, Vendor Watch, Web Services

Tags:

What is Microsoft’s thinking regarding SOA? To many, it seems as though Big Red isn’t talking about SOA enough, unlike Big Blue, which talks about nothing but. Microsoft seems to place more emphasis on its traditional home turf, operating systems and productivity applications.

Dana Gardner of Interarbor Solutions writes this insightful piece on whether Microsoft may be missing the SOA bus, or has something else in mind. Last week in this blogsite, we explored Microsoft’s wait-and-see ESB strategy. That is, if you’re looking for an ESB in Microsoft, look no further than BizTalk Server. But BizTalk will still be around for other roles just in case ESBs crash and burn.

There rarely are grand SOA-related announcements coming out of Redmond. That’s not to say Microsoft isn’t involved. Web services and SOA support and functionality are built into the Windows OS, .NET Framework, and Visual Studio.NET IDE.  Microsoft seems to want to blow its horn about other things. As a matter of fact, Microsoft has a whole cadre of evangelists and technologists that are very, very involved in Web services standards formulation and interoperability initiatives with other systems. (Check out Microsoft’s SOA site here and interoperability site here.)

A few years back, when the Department of Justice was breathing down Microsoft’s neck, an analyst speculated that the vendor’s .NET strategy was actually a ".DOJ strategy" — moving Microsoft’s business up into the middleware stack in case it was forced to break up into separate OS and applications companies.

Similarly, Gardner says, SOA also appears to be more a matter of convenience in case the market shifts underneath Microsoft’s business — the vendor "seems to want to relegate SOA as on-ramps and off-ramps to Windows Connected Systems, which use Web services standards, WS-* principally, to offer interoperability, but not broad integration to other IT assets. If you want to do B2B, Microsoft expects you’ll use Windows/.NET-based services for that. For Microsoft, SOA is a means to Windows everywhere, and not an end unto itself."

Microsoft built its success by following the mass market, and this is not where SOA is yet. Every product Microsoft has ever launched has been tuned for mass market adoption, not for pioneering to early adopters. The mass market is still exploring XML and Web services, and many are doing so within the .NET Framework. At this time, that’s the sweet spot of the market — just where Microsoft wants to be, and has been since 1981.

September 16th, 2005

High maintenance in the software industry

Posted by Britton Manasco @ 10:29 am

Categories: General

Tags:

One source of potential pressure on enterprise software companies is their ability to hang onto maintenance contracts. Oracle, for instance, derives 45% of its revenues from maintenance agreements.

In fact, a recent piece in Forbes suggested that this is one area that might be attacked by competitors. It pointed to TomorrowNow, a company that offers Oracle service maintenance for Peoplesoft and JD Edwards products at as little as half the price. While the contracts on offer are not comparable on an apple-to-apples basis, it does potentially threaten a source of key vendor revenue. TomorrowNow (which was recently acquired by SAP) also commissioned some recent research stating that 80% of JDE’s customers "believe they’re paying too much for their maintenance and support and would consider a third-party."

Well, maybe so. But this isn’t likely to be the match that starts the fire — and the fire, be sure, is coming — in the software industry. 

As Forbes notes, "The real test of one’s ability to hang onto customers will not come when maintenance contracts expire but when the major software companies, Oracle, SAP, Microsoft and to some extent IBM, transition to so-called ’service oriented architectures,’ a fundamental change in the way applications are deployed, integrated and accessed."

September 16th, 2005

Patterns of SOA success

Posted by Britton Manasco @ 7:27 am

Categories: General

Tags:

Acknowledging that there is now "more hype than actual work" in the field of SOA, David Linthicum, a prolific author and host of SOA Expert Podcast, offers several patterns of success to think about as one puts their SOA plans to work.  "These patterns are not always obvious, so perhaps this is a good time to learn through the successes of others and do our own homework before we spend millions on moving to an SOA," he says.

While he notes that "some of this is trial and error," he nevertheless insists that certain patterns are emerging. Among these successful patterns and practices:

Focus holistically, act locally. SOAs are all-encompassing architectures, not mere projects, and those who consider them "projects" are doomed to failure. You’re in for a pound when implementing an SOA due to the fact that, the more penetration the architecture gets, the more value it has within the enterprise.

Define the value. [W]e have a tendency to leverage the most popular technology without regard for how its use will affect the bottom line - not a good practice if you want IT to have a strategic position within an organization. We [need to] build SOAs because they provide an infrastructure for agility, or the ability to change processes in support of a changing business, or both. They also allow for reuse [and] services should be designed for reuse.

Don’t neglect service design. At the end of the day, services are small, specific applications and need just as much attention paid to design. If SOA supports composite applications and composite processes made up of services, then the overall design of services will determine the overall success of things made out of those services.

Remember the semantics. If you don’t understand application semantics, or, simply put, the meaning of data, then you have no hope of creating a proper SOA. You must understand the data to define the proper integration flows and transformation scenarios, and provide service-oriented frameworks to your data integration domain, which means levels of abstraction, as well as how data is bound to services.

The proper place for orchestration. For our purposes we can define orchestration as a standards-based mechanism that defines how Web services work together, including business logic, sequencing, exception handling, and process decomposition, including service and process reuse. While all SOAs don’t need orchestration, most do, and you must find the right fit and application.

Classify the patterns of use. As we build an SOA, we need to determine how the SOA will be leveraged within the enterprise - not only now, but in the future. Thus we need to determine patterns of use for several reasons, including:

• Understanding the value of the SOA
• Understanding how we will test the SOA
• Understanding how we can improve the SOA

Persistence is important. You need to think about persistence for a few reasons, including federation of services around the SOA. When building an SOA you may end up with composites or processes created out of services that may exist over a dozen or more different systems, and as such, persistence becomes more complex if done at the points. So, in these types of situations (which are becoming more common), it makes good sense to centralize the persistence for the composites and processes, as well as some supporting services to a central data tier or central data service. This data tier exposes a custom schema view or views to the composites, and may also abstract some data at the points as well.

"New patterns continue to emerge, and each SOA is unique and deserves careful consideration," concludes Linthicum. "However, these patterns should provide a good base on which to plan your next SOA."

September 16th, 2005

An 'eBay' of Web services

Posted by Joe McKendrick @ 7:00 am

Categories: General, Vendor Watch, Web Services

Tags:

I recently had the opportunity to chat with Bob Brauer, CEO of StrikeIron, Inc., about the latest phase of his firm’s "Web Services Marketplace" offering.  (Q&A published here.) Since the marketplace will serve as a forum for both subscribers and publishers of various services, Brauer evoked the eBay analogy for what he is providing; though he stresses that pricing of services will be fixed, and not auctioned.

The eBay analogy is popular across many disciplines now; Salesforce.com’s Mark Benioff evoked it for his company’s services, as noted in this post from ZDNet’s Dan Farber. Nevertheless, I find the idea of building an ecosystem, which potentially could foster a new class of service publishers, intriguing.  Some folks are running their own businesses off of eBay, for example. I have a friend that makes a few thousand a year buying and selling used golf equipment within eBay.

How does this all fit into the SOA scheme of things?  I talk a lot in this blog about the JBOWS architecture (Just a Bunch of Web Services) that most companies now have, versus fully functioning SOAs. Will having a frenzy of services bought and sold over the open market just add to the confusion?

Two thoughts: Brauer sees StrikeIron’s marketplace playing a role in providing services that companies may not have the time or inclination to build. Why reinvent the wheel by having your staff spend time building service components, when you can quickly subscribe to a component, that’s been tested and uptime certified, and pay for it on as-used basis? "We are providing, through our partners and ourselves, a bunch of new Web services that you can hook in through your existing SOA," Brauer said. "For example, things like our live tax rates, or our address verification Web service. Different things where it makes a lot more sense for companies to hook into our Web service, rather than having to rebuild and update and gather the data themselves."

The other thought is that if such a marketplace approach does take off, this may push some software vendors to change their models to component delivery, based on a micropayment business model.  This also makes plenty of room for smaller start-ups.

Amazon and others are reportedly in interested in this marketplace concept as well. This could open up a whole new way of doing business.