Category: Web Services
November 20th, 2009
Posted by Joe McKendrick @ 8:16 am
Categories: Business ROI, Case Studies, Data managemetnt, Management, SOA Events, Vendor Watch, Web Services, cloud computing
Tags: Cloud, Cloud Computing, Virtualization, Hardware, Joe McKendrick
The purpose of information technology is “to provide compute and storage. That’s it. full stop. That compute and storage can be provided by mainframes, private data centers, distributed networks, or by the cloud.”
- Allan Leinwand, venture capitalist
At this week’s Interop conference in New York, I heard a great panel discussion, moderated by AT&T’s Joe Weinman, on the economics of cloud computing. Weinman was joined by Adam Selipsky of Amazon Web Services, Allan Leinwand of Panorama Capital (which invests in cloud vendors), Andy Rhodes of Dell, Harris Tilevitz of Skadden Arps, one of the largest law firms in the world, and William Forrest of McKinsey & Co., author of the last spring’s watershed report on “Clearing the Air on Cloud Computing.”
A public cloud provider, private cloud operator, consultant, network provider, and venture capitalist debate cloud’s business value
McKinsey’s Forrest, for one, stated that while his research “found significant amounts of workloads today could be moved to public cloud providers,” it still “wouldn’t make economic sense to move large chunks of data centers to the cloud.”
Nevertheless, he predicts, “there will be a continued move to the cloud, as there are increasingly attractive economics over people building their own data centers.” He says that these economics keep getting better because “the public cloud guys have built a better box, they buy in volume, and operate more efficiently than most enterprises.”
“The idea that you buy an individual server, that is going away. You either buy racks of servers or go to the cloud.”
Amazon’s Selipsky, needless to say, was bullish on the cloud computing paradigm. He noted that in a government CIO rountable last week, Vicek Kundra, the US CIO, “certified that 45% of all government IT could run on public clouds.”
Selipsky went on to say that cloud computing is suitable for both large and small enterprises. “For start-ups, its a total no-brainer. We also have a lot of big enterprises using our services.” He foresees many enterprises moving to a hybrid cloud environment in the coming years. And, he noted that cloud providers also bring another advantage beyond cost savings: “The biggest benefit of the cloud is that is it enables focus. You can take the intellectual capital of your staff and focus on your business — not IT.”
VC Leinwand, however, says he still sees a “huge gap” between cloud services offered and the ability to effectively manage them in an enterprise environment. “Cloud storage costs one-tenth of onsite data storage,” he points out. But what about configuration, integration, data deduplication, and monitoring? There’s a gap between what the enterprise is used to doing behind the firewall and what cloud providers can do.” He added that he is seeking to fund companies that can help close that gap.
AT&T’s Weinman, for his part, raised doubts about the sustainability of cloud computing economics, which may break down as enterprise management requirements come into play. “I’m not sure there are any unit-cost advantages that are sustainable among large enterprises,” he said. A more likely scenario that will be seen is hybrid adoption of cloud computing in some areas, and private capabilities for others where it makes business sense.
Another option is private clouds, and Skadden’s Tilevitz reports great success at his global law firm of 2,000 partners. Originally, the initiative started after September 11, 2001, as a way to ensure business continuity by operating three regional data centers. Now, built on a Citrix environment, the virtualized environment has evolved into an internal cloud of sorts, from which the firm’s various office access online services. For example, he related, a partner may need to load five million pages of documentation into an online format overnight. “We have more than a petabyte of image data that we keep for seemingly forever that we use for litigation,” he said.
Economies of scale have also kicked in as well. “Our expenses for this private cloud have dropped over time,” Tilevitz said. “I see it as almost a reversion back to the mainframe world. Everyone is now using applications and data remotely.” Tilevitz also said his firm is looking at becoming a “public” cloud provider of sorts as well, selling excess disk capacity online.
November 18th, 2009
Posted by Joe McKendrick @ 1:34 pm
Categories: Case Studies, Data managemetnt, Enterprise Architecture, Management, Standards Watch, Web Services, business process management
Tags: SOA, Simple Object Access Protocol, United States Coast Guard, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
This is the third of three installments of my discussion with Jim Jennis, chief technology officer for the US Coast Guard Operations Systems Center, and Steve Munson, SOA branch chief for the US Coast Guard, about the department’s growing roster of service-orientation initiatives. In the first post, Munson and Jennis described the business case for SOA within the Coast Guard. In the second post, they discussed how they built organizational support.
Coast Guard opts for ‘lightweight’ services; now tackling governance and security issues
The US Coast Guard prefers more lightweight services for its maritime and inventory tracking systems. “We are very REST oriented,” Munson explains. “We like the REST model very much. So where applicable, we have leveraged it in a significant way to develop our service oriented architecture. Internally, Munson points out, the prevailing standard is POX, or Plain Old XML for message exchange. “We do not subscribe to the extra wrappers and envelopes and overhead that’s required to serve out SOAP-based services.”
“What we have found within the Coast Guard is that the Web services model, particularly the traditional RPC-style Web services, are not suitable for implementation in the Coast Guard’s architecture,” he explains. “Our architecture is fundamentally message based. Where we do implement Web services interfaces, they’re all document-driven Web services for external users, where those kinds of interfaces are required.”
Munson and Jennis are also seeing some reusability in its SOA-aware services, particularly for lower-level services. However, Munson cautions, “we certainly don’t want to oversell that yet.”
That’s because the SOA team is still wrestling with the technical aspects of service governance. “The issue around SOA governance is still a challenge for us as it is with any organization,” he explains. “We have not implemented, for example, any formal service registry or automated service discovery. Were continuing to look at how we want to do that.”
The issue with registry and repository solutions on the market, he says, is that they are oriented toward the traditional SOAP-based Web services. “Most of them are still tailored to the Web services approach,” he says. “Many of them don’t have good answers for non-WS-* type of registration.”
Data security is another challenge for the Coast Guard’s SOA team, and this is holding back the ability to offer services to port partners and other outside parties. “One of the challenges in an enterprise service bus, and an SOA architecture in and of itself doesn’t solve this, are all the security challenges surrounding data services, particularly once you get outside of your organization,” Munson says. Internally, within the Coast Guard organization, the security around services is pretty straightforward. But starting with sharing with external partners at any level, security rapidly becomes a challenge for us. Like other folks, were still looking at how to crack that nut, and we still don’t have a silver bullet for that yet.”
The Coast Guard soon intends to make some services available to other federal agencies and its port partners. For example, the Coast Guard is participating in an inter-agency program called Watchkeeper, in which data is provided as part of a homeland security system. “We have probably a dozen or more services that are in testing that will be deployed as part of that system,” Munson says.
Additional services being piloted — and still in development — will feed data to and from WatchKeeper to other Coast Guard systems, such as MISLE, MAGNet, MASI and others, Munson adds. Additional services leveraging the Coast Guard’s ESB and SOA include systems for the National Oceanic and Atmospheric Administration surrounding Right Whale speed enforcement zones, as well as a system for monitoring and tracking Self-Locating Data Marker Buoys (SLDMB) for Search and Rescue.
The Coast Guard is making substantial progress with its SOA effort, and Jennis and Munson credit this to the close coordination between their teams and the Coast Guard management. “If you define what SOA means for your organization, and go forward with that, you’ll get SOA right,” Jennis advises. “In our case, we’re very much tied to the Coast Guard’s mission, and the doctrine of the Coast Guard. But if you go with a lot of the buzzwords, and you don’t have a clearly defined meaning for what your SOA will look like, you’ll get in great trouble in a hurry.”
November 16th, 2009
Posted by Joe McKendrick @ 2:06 pm
Categories: Business ROI, Case Studies, Data managemetnt, Enterprise Architecture, Management, Vendor Watch, Web Services
Tags: Homeland Security, SOA, United States Coast Guard, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
Did you know the movement of any ship headed toward US waters is tracked by an SOA-aware service running on the US Coast Guard’s systems? And that SOA services are being employed to provide data to an international registry of maritime activity? And there is also an SOA service keeping track of the all the spare parts, equipment, and other assets the Coast Guard maintains? 
The Coast Guard already has close to 25 services that are either already or about to go into production as part of its growing SOA initiative – and more are planned. I recently had the opportunity to speak with Jim Jennis, chief technology officer for the US Coast Guard Operations Systems Center, and Steve Munson, SOA branch chief for the US Coast Guard, about the department’s growing roster of service-orientation initiatives.
The Coast Guard – part of the US Department of Homeland Security – started looking at SOA in early 2007, as a way to address growing requirements to be able to share information not only across its own various units, but with federal, local and international agencies concerned with keeping an eye on vessels entering and leaving US shores. “We had the same conundrum of silos of excellence that many IT organizations have – IT systems tailored in stovepipes within lines of business,” says Munson.
Prior to its SOA implementation, the Coast Guard relied on slower and more manual methods of data sharing with its port partners. “It would either be some form of composed file that would be potentially handed over, or many times, a hard-copy printout or phone call,” Munson relates. In addition, sharing data with its fast-moving cutter fleet was also a challenge. “The cutters get underway and go where they’re needed, so we have fairly low-bandwidth connectivity to these kinds of assets at best,” Munson says. “So were also looking at not only data sharing, but also if there’s a better way with emerging technology to help address some of the problems of being able to use our systems with deployed assets.”
To address these requirements, the Coast Guard implemented an enterprise service bus-centered SOA that enabled asynchronous messaging from Fiorano Software Technologies. The solution was employed in the Coast Guard’s Long Range Identification and Tracking (LRIT) system, which at any given time, is tracking up to 6,000 vessels moving toward or in US waters as well as vessels anywhere else in the world. LRIT tracks signals emitted from vessels every six hours. “That information is running entirely on the Coast Guard’s SOA framework in production,” says Munson. As a result, the Coast Guard SOA requires extremely high-volume services, “processing thousands of messages per second.”
A second system, the Nationwide Automated Identification System (NAIS), relies on a second transponder on ships exceeding 300,000 gross tons, broadcasting navigational information for ships of 300 gross tons or more at three-second intervals. These broadcasts from US territorial waters result in about 2,000 messages per second received in the NAIS system. The Coast Guard is currently protoyping various data services around this system for maritime domain awareness, Munson says.
This is the first of a three-part series. Next post: How the Coast Guard built organizational support for SOA.
November 13th, 2009
Posted by Joe McKendrick @ 10:14 am
Categories: Business ROI, Data managemetnt, Enterprise Architecture, Management, Vendor Watch, Web Services
Tags: Data Service, Data Quality, SOA, Ash Parikh, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
A couple of months ago, as reported here, Neal Fishman released a book that warned of SOA-based infrastructures helping to spread “epidemics” of viral data across enterprises — since data can be pulled from multiple, formerly siloed sources and quickly distributed across service-oriented systems and applications.
How much data pulled from multiple sources is bad data?
Informatica’s Ash Parikh, a long-time advocate of the data services approach to SOA, has also been warning of this scenario. I have gotten to know Ash through our participation on the Informatica Perspectives site, and recently had a chance to talk to him and Informatica’s Chris Boorman prior to the launch of Informatica 9, which embraces the SOA data services concept.
Ash proposes that organizations adopt a data services layer that provides “a model and standards-based reusable data abstraction layer that can make holistic, accurate and timely information available to an enterprise integration infrastructure, without all the typical complexity and maintenance costs.” He defines a data service as “a modular, reusable, business-relevant service that enables the access, integration, and delivery of complex enterprise data throughout the enterprise and across corporate firewalls in batch, near real-time and real-time modes, including federation.”
As companies move into the next level of SOA maturity, in which services start reaching across enterprise boundaries, many have been struggling to improve SOA’s ability to deliver business value. One factor is companies can’t trust the data that is being pulled in from all the stovepipes into enterprise services. SOA, as Chris puts it, “has lacked the data abstraction layer that enables organizations to basically define the data objects and the rules associated with data objects, that can then be permeated through — whether it be Web services or SQL or batch or anything else — to the applications that are using that data.”
Ash, who has been warning the industry about the quality of data — or lack thereof — surging through SOA-based infrastructures for some time now, says SOA data services open up many new avenues for connecting SOA with enterprise data management. “It’s much more than just data access,” he points out. “It’s making sure the data that is delivered is of the greatest quality.”
SOA data services also helps create a more collaborative environment between IT, data managers, and business data owners. In the real world, Ash says, “when people talk about data, they never talk about ‘data source X’ or ‘data source Y’ that’s sitting in a corner somewhere,” he says. “They report the data as a business representation of data — my customer data, my product data, things like that” This brings things in line with the perspective required of SOA architects, who need to better assure more timely and accurate and consistent views of their data and the product data.
Given this backdrop, I saw that Mike Kavis also has been doing work in this area, and just posted a business case for data services at his site. He describes the issues that can be rectified via an abstracted data layer: real time failover among multiple virtual data centers; managing multi-channel partners with multiple data structures; regulations and laws affecting data management and movement; and data security against direct access to databases.
Maintaining a loosely coupled data services layer takes away the complexities and inconsistencies of attempting to manage multiple data sources. “By abstracting the data layer and creating configurable services as access points to the data, teams can quickly implement solutions in a controlled and standardized manner,” Mike says. For example, they can move quickly “due to the simplicity of the data access and the fact that they don’t need extensive knowledge of the underlying data.”
Ash Parikh also talks about the divide between data management and real-life business needs, something that SOA and data services can help address. For example, he observes, many companies have built great data models, but these models tend to be static. “It’s great to have a model, but I also need a way to find all that information, and to make sure that information I’m finding across a multitude of these data sources – which can be varied in structures and formats — is relevant to me.” Many of these issues can be resolved at the data services abstraction layer, he says.
November 9th, 2009
Posted by Joe McKendrick @ 6:52 pm
Categories: Business ROI, Management, Standards Watch, Vendor Watch, Web 2.0-Enterprise 2.0, Web Services
Tags: Enterprise Mashup, Joe McKendrick
Kudos to JackBe’s Luis Derechin for his refreshingly candid admission and personal journey of discovery in an effort to arrive at the definitive definition of “enterprise mashup.”
You may recall that last spring, following a TV news interview, Luis was not happy with the explanation he gave to describe enterprise mashups. JackBe sponsored a couple of contests, along with a lot of discussion among practitioners and analysts.
Here, at last, is the working definition Luis and his team have arrived at:
“Enterprise Mashups are secure, visually rich Web applications that expose actionable information from diverse internal and external information sources.”
Wait — that’s not all. The JackBe crew also sought to answer the question of “why” people need enterprise mashups. They didn’t want enterprise mashups to be solutions in search of problems, as has been the case with many a technology initiative:
“Poor decisions are often made because decision-makers do not have the right information at the right time. Enterprise mashups deliver new insights and enable better decisions through personalized access to the right, real-time information for the specific problem at hand.”
And finally, the JackBe crew also addressed the “how” aspect — as in how enterprise mashups can be created:
“An enterprise mashup platform is a technology suite that enables the rapid, collaborative, user-driven creation of Enterprise mashups without the complexities, costs and risks of traditional information integration projects.”
In this last passage, the user-created aspect of enterprise mashups are included in the definition. This is where mashups can potentially deliver business benefits, as more flexibility can be put into users’ hands. And, as the “why” part of this definition shows, enterprise mashups put decision makers in touch with performance data from across the organization. The greatest challenge to delivery of information at this time is the time it takes to prepare and deliver reports. Let’s give end-users the tools to quickly and configure their interfaces to back-end enterprise applications and data.
November 4th, 2009
Posted by Joe McKendrick @ 9:34 am
Categories: Business ROI, Enterprise Architecture, Management, SOA Events, SOA Surveys and Research, Web Services, business process management
Tags: Gartner Inc., SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
Pro-SOA view: SOA is the greatest thing since sliced bread.
Anti-SOA view: SOA is toast.
SOA moderate view: Let’s just worry about baking service orientation into our business processes where we can.
I just had the pleasure of hosting a Webcast keynote with Gartner’s Yefim Natis over at the ebizQ “SOA in Action’ event, and Yefim did a great job of popping the myths around SOA — not only among the naysayers, but among the over-optimistic SOA proponents as well. Instead, Yefim urges a balanced middle course with SOA, with a serious emphasis on what it can do for the business.
Here are the 10 most common myths — promulgated by both SOA “fanatics” as well as naysayers — that need to be put to rest (no pun intended):
SOA Fanatic Myth #1 - Services were invented in the IT department and are spreading out to the business. This myth assumes that SOA architects and designers “will be bringing solutions to the business that the business itself couldn’t invent,” Yefim says. However, he observes, “encapsulated functions have existed in business forever. This is how business is structured.” Instead, SOA is about improving the “ability of software designers and software architects to model the real world better. Software is not bringing the solution to the business, its better understanding the business.”
SOA Fanatic Myth #2 - SOA applications are assembled from pre-built components. “SOA is not a Lego game,” Yefim says. “Although service oriented systems indeed include encapsulated components, or services, they also include clients, batch components which are not service oriented, and include legacy systems that need to be connected to.”
SOA Fanatic Myth #3 - Sharing or reusing application logic is the main benefit of SOA. “In reality, a successful environment will have reuse of about 30%, so that is a ballpark number where you should feel good about your level of reuse,” Yefim says. “If that’s the case, it means many organizations will have less than 30% — so reuse is not the primary benefit, although it is one of the benefits of service oriented architecture. There are many other things, such a making your internal architecture more manageable, having greater extensibility, and applications that function a lot better when they are service oriented.”
SOA Fanatic Myth #4 - SOA eliminates the need for application integration. No matter how effective your SOA infrastructure, you’re still going to need enterprise application integration, Yefim says. What SOA does do is “introduce a consistency to the architecture, as well as tools and standards that help application integration.”
SOA Fanatic Myth #5 - SOA reduces the cost of IT. It may help reduce IT costs in the log run, but early on, “investment in SOA costs in fact costs more,” Yefim says. “Not because SOA is more complex, but just because when you do something new, you have to understand new approach, you have to train people, you have to buy new tools — and that all is costs.” What SOA does do is “shift the costs, distribute the costs differently.”
Yefim also took the occasion to refute some of the negative things also being said about SOA as well. Here the top five naysayer myths about SOA:
SOA Naysayer Myth #1 — SOA introduces new complications and new problems. “That might be true, depending on what you were doing before,” Yefim says. “After all, complications and problems are all relative to prior experience.” However, he points out, “most issues that have to do with deploying and establishing service-oriented systems are not issues of SOA; they’re issues of distributed computing, or of modern grid based computing networks.” Without SOA, he says, companies would “probably be facing the same complications and issues.” At least SOA provides a more consistent approach to tackling these problems.
SOA Naysayer Myth #2 — SOA is nothing new, it’s hype, it’s taking old wine and trying to sell it in a new bottle. SOA is merely a set of coarse-grained remote procedure calls (RPCs). SOA builds upon earlier models of distributed computing and RPCs, but it’s something different, Yefim points out. “SOA is intended to address a business topology of the business functionality of the application, whereas RPCs were intended to simply distribute an application.”
SOA Naysayer Myth #3 — SOA is doomed because Web services don’t work well enough. This widely held misconception is based on the view that SOA is entirely based on SOAP. “There’s nothing in common between the two, yet people confuse SOA with SOAP. SOA is not about Web services — Web services is one of the ways of establishing connectivity between the clients and the services of SOA.”
SOA Naysayer Myth #4 — SOA is hard to sell because the business can’t see the benefits. This is probably true for basic-level SOA, but as more companies move into advanced SOA, business benefits will become more apparent, Yefim says. “After all, SOA is an architecture, and the business sees software as a means to a goal, rather than the goal in itself.’ However, as SOA begins to support new initiatives such as event-driven processing, business awareness may grow. “Event-driven SOA has very important components to it that allow direct benefits, clear benefits to business operations, to any business that wants to gain control over its overall IT information environment or wants to build situation awareness.” Event-driven SOA, Yefim adds, “is the foundation for business activity monitoring, business intelligence, situational awareness. All of these directly serve business.”
SOA Naysayer Myth #5 — SOA is obsolete, and its time to move on. Indeed, the industry is probably ready for a new round of buzzwords, Yefim says. “There’s no intrigue anymore in basic SOA. We know how to do it, it’s not talked about as much as before.” But, he asks, “What are you going to move on to? The only alternatives you’re going to find to SOA are going to be advanced forms of SOA.” [See SOA Nay-sayer Myth #4, above...]
October 29th, 2009
Posted by Joe McKendrick @ 7:15 am
Categories: Links, Standards Watch, Web Services
Tags: IPv4, IPv6, IP, Internet, Networking, Telecommunications, Joe McKendrick
The impending changeover from IP version 4 to IP version 6 won’t really be a big deal, and most people won’t even notice it as it happens. But the Internet will be running on both protocols for a while, and the head of the American Registry for Internet Numbers (ARIN) cautions that some online applications may run slow as a result. Online content providers need to start preparing as well.
In a recent interview, John Curran, president and CEO of ARIN, explained why businesses need to sit up and take notice of the impending shift that is taking place as we move from Internet Protocol version 4 (IPv4) to the more expansive IP version 6.
What’s happening is the original Internet numbering system — which assigns addresses such as 192.168.1.1 — is running out of numbers. IPv4 is a 32-bit system with four billion possible combinations. “That sounds like a lot of numbers, but it really isn’t when you think about the size of the globe and the number of devices being connected these days,” Curran says. In fact, we’re due to run out of numbers within 700 days, he warns. IPv6, with 128-bit addressing space, enables “numbering of all of the molecules in the galaxy,” he says.
As soon as the last IPv4 number is used up, every new device or site that comes along after that uses IPv6. Don’t loose too much sleep over your systems, however. Industry planners have been aware of this matter since the 1990s. Most hardware and software has been ready for IPv6 for some time.
However, Curran advises businesses to check their configurations before the changeover takes place, as glitches may come up. “We can’t actually get an IPv6 host and an IPv4 server to talk to each other, because the IPv4 server only knows 32 bits. It’s much like if your telephone was set up to only ever dial seven digits, and it wouldn’t let you dial 10. Sure you could almost have a conversation, but you couldn’t call most of the world.”
When the changeover occurs, “ISPs are going to have to start using IPv6 to connect customers,” he explains. “Then, they’re going to have to put IPv6 gateways in, boxes that work like network address boxes, to translate IPv6-connected customers to the IPv4 websites on the Internet. That will work, but that’s going to be suboptimal, because those are gateways doing the translation.” This may slow down online applications such as Skype, Voice over IP, real-time video games, which “won’t necessarily run smoothly going through those translators.”
Curran points out that the Internet will be running on two protocols for some time. “If you really want to start a business that’s Internet based, you’re going to want to take your equipment, and make it connected by both IPv4 and IPv6.”
Some businesses have more of a challenge ahead of them than others, Curran continues. While the major ISPs have been underway with IPv6, “the content providers are just beginning to work on this,” Curran says. “And that’s going to take a lot of work, and they need to enable a lot of software that we think of as the Web 2.0 software infrastructure. While all the parts may run IPv6, that doesn’t mean your infrastructure is ready.”
Consider the two years remaining to address IPv6 configuration issues as an opportunity to get a jump on the competition, says Curran. “I would recommend that people start thinking about the fact that the IPv4 Internet has a fixed size, and the global Internet is going to keep growing. What this means that you don’t want to be left behind on the fixed-size network. You don’t want to be left behind on a fixed-sized network in an Internet ‘backwater.”
By the way, the interviewer, Howard Greenstein, said it’s important to get this cautionary message out on ZDNet and other popular channels — so there you go, Howard!
October 14th, 2009
Posted by Joe McKendrick @ 7:14 am
Categories: Event processing, Links, SOA Surveys and Research, Web Services, business process management
Tags: SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
Does event driven architecture (EDA) represent the next phase of SOA? This is a subject of continuing debate, but Udi Dahan makes the case for EDA as the next logical stage of SOA. In a recent post, he connected the dots between SOA and EDA, suggesting that EDA will shift the inherent nature of SOA.
Dahan makes his case thusly: SOA is currently based on a “commonly used request/response communication pattern of service consumer to service provider in SOA,” in which the consumer delivers the command, and the provider service responds accordingly. “Commands are often named in imperative, present-tense form—for example, ‘update customer’ and ‘cancel order.’”
With EDA, this relationship gets reversed, he points out:
“In EDA… Consumers do not initiate communication in EDA; instead, they receive events that are produced by emitters. The communication is also inherently unidirectional; emitters do not depend on any response from consumers to continue performing their work.”
Developing an architectural approach that employs both SOA and EDA principles will go a long way toward better so-called “business-IT” alignment, Dahan observes. The fusing of the two approaches may be the key. Either approach alone won’t do it. As Dahan illustrates:
“Architects can explain to the business the ramifications of their architectural decisions in ways that the business can understand—’There might be a couple of seconds during which these two bits of data are not in sync. Is that a problem?’—and the answer to those kinds of question is used to iterate the architecture, so as to bring it into better alignment with the business.”
SOA and EDA have been moving closer in recent years, as companies start to understand the value of event processing to ongoing operations and opportunities.
October 6th, 2009
Posted by Joe McKendrick @ 3:21 pm
Categories: Enterprise Architecture, Links, Management, Web 2.0-Enterprise 2.0, Web Services, cloud computing
Tags: SOA, WOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
Has the time come for a change in the way we do SOA?
Dion Hinchcliffe, ZDNet’s resident Enterprise Web guru, has posted an interesting analysis of the state of service oriented architecture, and what it will take to kick-start it into the future. SOA has a couple of issues that is keeping it from reaching its potential, Dion wrote in new post over at ebizQ.
- First, the velocity of SOA seems too slow to keep up with the rapid changes buffeting organizations:
- Second, SOA service consumption remains at “depressingly low” levels;
- Third, SOA projects tend to be over-engineered.
What’s a beleaguered SOA proponent to do? Time to move to a new level, Dion says: Web Oriented Architecture. Dion calls WOA a “parallel track” for SOA that’s evolved in the more open Internet space, versus behind the opaque walls of corporate enterprises. Or as Dion puts it: WOA has grown “organically in the wilds of the online world to meet many of the same challenges that we have in our organizations today.”
Dion defines WOA in terms of open APIs, such as we see in cloud-based or Enterprise 2.0 services. WOA will help SOA reach its next level of performance. Ways we will see this evolve is the trend toward running SOA more like a business in itself; cheap, lightweight service delivery models; and access via REST-based interfaces and mashups.
The WOA approach makes a lot of sense, in no small part because of its relative simplicity and cost-effectiveness. SOA evolves from being an IT-centric megaproject to a series of initiatives in which business end-users can partake. Yes, there are many instances where iron-clad SOAP Web services are required. But everyone is already doing mashups, and the extended enterprise may benefit from the rise of WOA.
Dion will be talking about the SOA-WOA evolution at the SOA in Action conference I will be emceeing October 28-29.
October 2nd, 2009
Posted by Joe McKendrick @ 1:58 pm
Categories: General, Vendor Watch, Web Services, cloud computing
Tags: Amazon.com Inc., Amazon EC2, Randy Bias, Cloud Computing, Virtualization, Hardware, Joe McKendrick
Anyone wondering how the commercial cloud computing business model is working should look no further than Amazon Web Services.
Randy Bias just published estimates that AWS is pulling in about $220 million annually for its Elastic Compute Cloud (EC2) offerings. He bases his conclusions on “actual verified EC2 numbers plus some guesses and a rough model of it’s current annual usage.” He also estimates that AWS runs about 40,000 servers to support the service. EC2 probably grew at a rate of 10% from year to year, Randy believes.
Not bad for a business model based on increments of 10 cents to 80 cents an hour for standard usage. EC2 is a Web service that provides resizable compute capacity in the cloud.
With these numbers in hand, Randy also observes that they may also tell the story about the overall size of the infrastructure cloud computing (Infrastructure as a Service) market. Randy sizes this marker at about $400 million to $600 million, and growing about 10% to 20% annually.
The EC2 revenues represent about 1% of Amazon’s revenues for the most recent fiscal year. ($19.2 billion.) Amazon has really effectively leveraged the capacity from its retail business to offer services to the rest of the market. Is this something other companies with large IT infrastructures can contemplate?
September 30th, 2009
Posted by Joe McKendrick @ 7:18 am
Categories: Business ROI, Enterprise Architecture, Management, Web 2.0-Enterprise 2.0, Web Services, business process management, cloud computing
Tags: SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
Remember, SOA is a journey, not a quick overnight fix. It’s a transformative process that your organization will follow for the long run.
A few years back, I put together a list of where companies appeared to be steering in the wrong direction in terms of SOA implementations. The list bears repeating, because the issues still keep getting in the way of SOA success. Many companies run the risk of jumping into the approach without looking at where they are leaping. Here are the most common pitfalls that could tie an SOA installation into knots.
1) Viewing SOA as a global, enterprise-scale project involving the entire enterprise: An SOA need not be a galactic initiative that sucks up resources all across the enterprise. In fact, one of the beauties of SOA that it can start small and simple, deployed across a single business process. Definitions of SOA vary, but SOA can start with something as simple as some Web services that accomplish an end-to-end process, such as fulfilling a purchase order.
2) Looking to a single vendor to offer very complete SOA solutions: There’s no such thing as buying an SOA solution; there’s no such thing as SOA in a box, no matter what a vendor may tell you. SOA is not a product that a vendor can ship to you for installation over the weekend. Rather, SOA is a philosophy around developing your infrastructure using those vendor tools. If you have a J2EE or .NET Framework, you have a framework. An SOA is what you eventually do with those frameworks.
3) Assuming that SOA will automatically grow out of a primordial soup of Web services: Many companies think they have SOA when they actually have a JBOWS (Just a Bunch of Web Services) architecture. Somehow, there’s an assumption out there that a spaghetti architecture of Web services will somehow evolve into something resembling a full-functioning SOA. Actually, it’s possible (but not advisable) to build an SOA-enabled infrastructure with no Web services at all. An organization could have 1,000 Web services, but unless these services work in concert to address specific end-to-end business processes, that does not an SOA make. One additional point about JBOWS, however — there’s nothing wrong with being in the JBOWS stage of evolution, because that’s what it is, a stage of the evolution. But don’t expect the full-fledged agility of SOA at this stage — that’s where the disappointment has crept in.
4) Build it, and they will come: SOA is not an illuminated ballpark in the middle of a cornfield that can be seen from miles around. No one will take advantage of an SOA-enabled infrastructure if they don’t know where to find it, or even if it exists. There’s a rule that if developers have to spend more than 10 minutes to find what they are looking for (and don’t find it), they will create it themselves. An SOA will never be of value if it’s confined to one silo of the organization, and its components are not made available and shared across business unit. An SOA service built, managed, and used by one business unit will cost just as much as any other legacy application.
5) Assuming that businesspeople don’t, or won’t, understand SOA: Actually, most people on the business side can intuitively grasp the potential savings and opportunities an SOA can bring. And Enterprise 2.0 and the cloud dynamic really drives the points about service orientation home on the business side. The potential of reusing services across various business units, versus paying developers to rebuild a new service in each instance, is Management and Finance 101. The difficult part is building and managing such an infrastructure, applying IT governance, monitoring, and management to ensure that services are kept up and running, are scalable, and perform well.
6) Assuming that IT people don’t, or won’t understand the business: It’s time to put this misconception, which has been weaving its way through conferences, articles, and analyst reports for years, to rest. Indeed, SOA needs to be a multi-disciplinary, cooperative effort between IT and other departments. However, IT is part of the business, and IT professionals’ paychecks are signed by the business. Most IT departments understand that they play a vital role in moving the business forward. However, inevitably, specs and priorities will change during the life of a project, and that’s why projects fail. It’s incumbent on both IT and business users to keep each other informed; both have a financial stake in the business’s success.
7) Treating SOA as something far superior to a mere mortal “project:” SOA success is delivered one project at a time. If you have been to any number of SOA conferences, or tuned into the multitude of SOA Webcasts, you probably have heard the message over and over again that “SOA is more than just another project.” Yes, true. SOA does represent a new way of thinking, and will transform your IT, and ultimately, your business processes. However, SOA still needs to be treated as a project, with the same deliberate planning of timelines, establishment of baselines, and measurement of key performance indicators as other large IT projects. SOA requires executive buy-in, it requires resources, and it requires proof that it is paying off.
September 25th, 2009
Posted by Joe McKendrick @ 2:56 pm
Categories: Web 2.0-Enterprise 2.0, Web Services
Tags: XML, AJAX, Software/Web Development, Web Development, Internet, Web 2.0, Joe McKendrick
Jack Vaughan has got things all abuzz with a recent post that ponders whether XML’s best days are behind it.
Is the ‘X’ in Ajax (Asynchronous JavaScript and XML) fading?
With the growing popularity of Rich Internet Applications an enterprise mashups, it’s conceivable that we may see less and less XML, Jack speculates. “Like Pick or Fortran or other once-popular languages, it is conceivable that XML’s use will at some point decline.”
For example, he quotes Yahoo Architect and JSON originator Doug Crockford, the original developer of JSON (JavaScript Object Notation), who says the protocol “was a reaction to complexity arising around XML. Such complexity did not make sense in simple Web applications.”
Many applications written in Ajax (Asynchronous JavaScript And XML) “never go near XML,” Jack adds. As he puts it: “The ‘X’ in Ajax is fading. Some would say Ajax and XML have forked. At the same time, those simple Web apps are growing in complexity.”
I don’t know if XML would ever go the way of Fortan or Pick, since these are programming languages, and XML is a meta language used in conjunction with programming languages. XML is at the foundation of many integration efforts, Web services, and SOA projects. We finally have something that’s bringing together all the world’s systems and data. I have a feeling there will be lots of XML around in the years to come. But, as Jack reminds us, nothing is invincible — not even mighty XML.
September 24th, 2009
Posted by Joe McKendrick @ 8:45 am
Categories: Data managemetnt, Links, Standards Watch, Vendor Watch, Web 2.0-Enterprise 2.0, Web Services, cloud computing
Tags: Enterprise Mashup, Enterprise Mashup Markup Language, Joe McKendrick
As reported a couple of days ago, the enterprise mashup market promises to be a huge one, growing to almost $2 billion in a few years. So it’s high time people involved in this space start organizing and working around some standards everyone can agree on.
Can enterprise mashup proponents avoid the mistakes made with ESBs?
A new consortium, called the Open Mashup Alliance, is the first effort to coalesce around this growing phenomenon. The group’s stated mission is to promote “the successful use of Enterprise Mashup technologies and adoption of an open language that promotes Enterprise Mashup interoperability and portability.”
One of the founding members is ZDNet’s resident Enterprise Web 2.0 guru, Dion Hinchcliffe. Additional charter members include Adobe, Bank of America, Capgemini, HP, Intel, JackBe, Kapow Technologies, ProgrammableWeb, Synteractive, and Xignite.
One of the OMA’s first endeavors is to shepherd the budding Enterprise Mashup Markup Language (EMML) specification for submission to a standards body. EMML is an XML-based, domain-specific language that was designed to address the characteristics that make mashups easier to create and reuse.
There were a bunch of supporting quotes included with the OMA’s announcement, but I think Michael Ogrinz, principal architect at Bank of America and author of the book Mashup Patterns, said it best: “For enterprise mashups to take hold, we need to remove the ‘vendor lock-in’ concerns raised by today’s proprietary toolsets. We also need to inspire the innovative minds of the open-source community to start working in this space. By establishing an open standard for mashups, the OMA and EMML addresses both of these issues.”
Perhaps the industry learned some lessons from another development that proliferated without guiding standards — the enterprise service bus. One of the fiercest criticisms of ESBs has been the way vendors took off in all different directions with their implementations before standards could be established. Perhaps we can avoid this with enterprise mashups. But the looming market size must be a huge temptation.
September 22nd, 2009
Posted by Joe McKendrick @ 9:28 am
Categories: Links, SOA Surveys and Research, Web 2.0-Enterprise 2.0, Web Services, cloud computing
Tags: Enterprise Mashup, SOA, Service-Oriented Architecture (SOA), Web Services, Enterprise Software, Software, Joe McKendrick
A new report from Business Insights predicts that the enterprise mashup market, worth around $161 million in 2008, will expand more than tenfold to $1.74 billion by 2013.
About 33% of companies now use enterprise mashups, Business Insights says.
The catalyst for the enterprise mashup market will be SOA — Business Insights puts the SOA platform market at about $1.4 billion in 2008, which will double in size, to about $2.77 billion by 2014.
It’s interesting that the enterprise mashup market, which currently is about 11% the size of the overall SOA platform market, will soon be 63% the size, or getting close to comparable. This is huge for the front-end part of the equation, if these numbers pan out. But does it make sense?
September 16th, 2009
Posted by Joe McKendrick @ 9:33 am
Categories: Links, Standards Watch, Vendor Watch, Web 2.0-Enterprise 2.0, Web Services
Tags: Red Hat Inc., Specification, RESTful, Standards, REST-*, REST, Quality, Open Source, Business Operations, Joe McKendrick
Should we call it “REST-star” or “REST-splat”?
Paul Krill reports that Red Hat has launched a community-based standards set it is calling REST-*, which could serve as a counterpoint to the WS-* specifications for Web services. Red Hat says it hopes to work with major vendors such as IBM and Microsoft, “to define standards or recommendations for REST-based system integration.”
Mark Little, CTO of JBoss/Red Hat, announced the new initiative at the recent JBoss World conference in Chicago, noting that the WS-* series of Web services have become complex. “Maybe REST is a better way of doing certainly Internet-scale integration, but one of the problems of REST is it lacks clear guidelines,” for enterprise capabilities, such as security, transactions, and high availability.”
Red Hat even now has a home page for the REST-* effort, which outlines the vision, specifications, and community for the standards set.
Red Hatter Bill Burke makes the case for REST-* thusly:
“While REST has gained huge momentum in the SOA community, there hasn’t been a lot of standardization of traditional middleware services. The REST-* community aims to introduce new REST-based standards for these traditional services where none exist and provide well-defined guidelines where protocols do exist.”
There are two efforts now underway as part of the REST-* set:
REST-* Transactions: A specification that attempts to define a RESTful interface for transactions. “It describes the interaction between coordinator services and transaction participants as well as how transactions can propagate in distributed applications. It defines both a 2-Phase-Commit model as well as a Forward-Compensation protocol.”
REST-* Messaging: Messaging encompases publish and subscribe and point-to-point protocols. This specification defines a RESTful interface for queues (p2p) and topics (pub/sub).
Not everyone is welcoming the new initiative with open arms. Anne Thomas Manes, for one, says she’s “got a bad feeling about this.” She points out that REST-* may stray from REST principles, and “you won’t attain the desirable RESTful characteristics (scalability, serendipity, network effects, etc) that REST is supposed to enable.”
“A more useful effort would be one that defines RESTful patterns that support and enable mission-critical capabilities like reliable delivery, transactional integrity, and the like. But please, let’s not reinvent CORBA on REST. Here’s hoping the whole REST-* thing just dies out.”
Sure, mistakes were made with SOAP and WS-*, and Burke admits that “blind idealism,” combined with Red Hat’s experience with communities, will guide this latest effort past obstacles, complexities, and pitfalls. Red Hat is “jumpstarting and founding the standards body itself,” and is “battle tested in specifications efforts at the JCP and other bodies.” Burke adds that “we’ve often been frustrated by the closed and inflexible attributes of these organizations. We feel our open source roots and ideals make us an excellent candidate to drive and host standardization efforts.”
September 15th, 2009
Posted by Joe McKendrick @ 9:16 am
Categories: Enterprise Architecture, Links, SOA Surveys and Research, Standards Watch, Web Services
Tags: Enterprise Service Bus, SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, EAI, Enterprise Software, Software, Joe McKendrick
Thomas Rischbeck, a contributor to Thomas Erl’s SOA Design Patterns, wants to clear the air on some of the confusion and controversy that has been associated with enterprise service buses (ESBs).
From day one, ESBs have suffered from lack of standards
That is, he writes in a new article, “The essence of an ESB can be much more easily grasped by talking about the ESB as a pattern: the pattern of applying an intermediate proxy to service communication. The ESB pattern is about performing integration tasks and adding value to client-service communication in an SOA – all completely transparent to the participants.”
The confusion with ESBs date back to their very start, when vendors took the lead with pushing these products out to market. But they rushed things because they were under the gun, Thomas says:
“Faced with market domination by IBM, [message-oriented middleware vendors were the first to jumpstart the ESB concept with the aim of developing a unique selling proposition. They added Web service and EAI capabilities on top of existing message broker capabilities, and with analyst support coined the term ESB. ESB was positioned as a low-cost alternative to EAI and panacea for all integration needs – tell-tale signs of hype. Unfortunately, the standards community was too late to get on the bandwagon. In the absence of standards guidance and the lack of a clear definition, each vendor interpreted ESB to its advantage. As a result, comparing ESBs is like comparing apples and oranges. No two products are compatible today with severe consequences (in terms of vendor lock-in) for end users.”
As a result of all this vendor confusion and FUD-creation, ESBs mean a lot of different things to different people. Instead of thinking of ESBs in terms of what vendors say they are, Thomas urges thinking of ESBs as a pattern — as he puts it, “the pattern of applying an intermediate proxy to service communication.”
He provides a more detailed definition for the ESB pattern:
“The ESB pattern is about performing integration tasks and adding value to client-service communication in an SOA – all completely transparent to the participants. …The ESB is a compound pattern that pulls together many enablement and enforcement capabilities that come in handy to the SOA practitioner. Reliable Messaging, Message Manipulation, Data Format and Data Model Transformation as well as Protocol Bridging are just some sub-patterns examples under the ESB umbrella. These are all enablement aspects where the ESB allows communication between endpoints not possible otherwise.”
There are two major alternatives to ESBs, Thomas adds — either application servers everywhere or nothing at all. While doable, this makes efforts to support delivery of services more complicated than they are, he says. Of course, there are many SOA proponents that say ESBs are essentially useless appendages that do more harm than good in the long run. Perhaps elevating the discussion to more vendor-neutral territory will help clarify what, if any, roles ESBs could play in tomorrow’s SOAs.
September 8th, 2009
Posted by Joe McKendrick @ 1:47 pm
Categories: Enterprise Architecture, General, Links, Management, Vendor Watch, Web Services, cloud computing
Tags: Joe McKendrick
One of the major selling points of SOA and cloud computing is that service consumers don’t have to worry about the platform and hardware that the service is hosted on, be it somewhere else within the enterprise or maintained by an outside third party.
SOA’s greatest risk? Too much success, catching planners unprepared
Providers of services (and users), however, need to assure the availability of the service, and how much stress the underlying infrastructure can take as the service is repeatedly accessed. Lori MacVittie just posted a detailed analysis of the load balancing challenge associated with SOA-based deployments.
Lori cites a post by Stephan Koser, who provides a vivid scenario of what can go wrong with unbalanced SOA.
To function effectively, Lori observes, any load-balancing algorithm put into to place to assure availability and scalability of the service-delivery network be able to take into consideration the current load being handled by the particular server handling the request:
“This requires that the load balancer, the application delivery controller, be aware of the application, its environment, as collaboration well as the network and the user. It must be able to make a decision, in real-time, about where to direct any given request based on all the variables available. That includes CPU resources, what the request is, and even who the user/application is.”
However, when the cloud paradigm is introduced, this ability to see and monitor the systems providing services is, well, clouded over. If anything, Lori warns, cloud computing leads to poor visibility and renders load-balancing strategies useless. “The belief that the infrastructure should be ‘hidden’ from the user (that’s you) means that configuration options – like the load balancing algorithm – aren’t available to you as a user/deployer of cloud-based applications. Even though load balancing is going to be used to scale your application, you have no clue or control over how that’s going to occur.”
Lori very aptly points out that despite all the emphasis on virtualization, “applications are not islands,” and the ability to deliver and manage applications ” requires collaboration between a growing number of components in the data center.” Load balancing is a good start.
There’s plenty of talk about SOA failure, but, ironically, the greatest risk may come from too much SOA success. Organizations deploy shareable services, only to have them pounded into the ground by a growing number of requesting applications. Here’s a case where SOA costs may be driven up by the need to quickly put in or provision additional hardware. Cloud adds a new dimension to the challenge.
September 3rd, 2009
Posted by Joe McKendrick @ 8:12 pm
Categories: Links, Standards Watch, Web 2.0-Enterprise 2.0, Web Services
Tags: SOA, Simple Object Access Protocol, REST, SOAP, Service-Oriented Architecture (SOA), Web Services, Software Development, Research & Development, Middleware, Enterprise Software
Speak now or forever hold your peace…
Has anyone ever actually heard someone disrupt a wedding ceremony by voicing an objection to the proposed union?
Has anyone ever heard someone object to an SOA plan because its based on SOAP, and not enough REST?
In an interesting new post, Justin Cormack says not enough people speak up when corporate decisions are made to adopt of SOAP-base Web services as the foundation of SOA, before the deal is sealed and things really start to get messy:
“I went to a meeting a while back with a company starting to move to a Web service based, internal API based architecture, and there was a minute where the CTO said (more or less) “does anyone know of any let or hindrance to this being a SOAP API?”. Like those moments at weddings, no one spoke out. But I do object. SOAP is not the backbone of a happy architecture, but we do not have the strength to say no right now.”
Justin says this is the time for enterprises to move from SOAP to REST, and transition their service oriented architecture (SOA) to a resource oriented architecture (ROA).
Not a bad nomenclature — and he makes his case for a RESTful ROA:
- Web developers favor REST. “It is more productive. It does not involve programs to generate huge chunks of useless code. It involves hypertext, not opaque documents that are mappings of database schemas.”
- REST is less expensive, as it requires fewer application development resources.
Look at modeling systems as resources, Justin continues. “Resources are much easier to work with than services, as they share uniform semantics, and they are addressable, two keys to making application design simple.” A CRM system is an example of something that needs to be modeled as resources, he says. “You need API calls that can find products a customer has bought, support tickets, all the core data that you would need to build customer service portals, internal support applications.”
REST enables a resource oriented architecture based on HATEOS or Hypertext as the Engine of Application State. HATEOS “involves is moving the vague and very expensive field of business logic from code (often code that is not even owned or understood by the enterprise, as it has been embodied into code written into systems from suppliers) into hypertext documents,” Justin explains.
Thanks to Dilip Krishnan for pointing to this post.
September 2nd, 2009
Posted by Joe McKendrick @ 12:52 pm
Categories: Business ROI, General, Links, Management, Web Services
Tags: Web Service, SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
Alex Kriegel, an active enterprise architect, picked up on my JBOWS (Just a Bunch of Web Services) theme written back in 2005, and shared with us a great analogy that he says has served him well in explaining the difference between JBOWS and full-functioning SOA:
It all started with frustration on Alex’s that people just weren’t getting the message that putting up some Web services doesn’t magically gel into a service oriented architecture: “I found myself explaining – time and again – to the managers on every level why Web services do not equal SOA,” he says.
Thus, this metaphor to which the business can relate: mail delivery systems.
JBOWS: Brittle, non-scalable. “If you need to deliver a package from point A to point B, a courier service would be one option. It is fast, it is reasonably secure and it is reliable; you can even trace the way the parcel will be delivered to the recipient, All you need to know is the exact location (address) of the point B. Oh, and you need to pay the courier.
SOA: Economies of scale, built-in fault tolerance. “The second option would be USPS – United States Postal Service. It is a lot cheaper than private courier; it is reasonably fast, reasonably secure and reliable. It also could forward your mail should your intended recipient have moved without notifying you beforehand.”
August 31st, 2009
Posted by Joe McKendrick @ 7:51 am
Categories: Vendor Watch, Web Services, business process management
Tags: Wal-Mart Stores Inc., Web Service, Amazon.com Inc., Cloud Computing, Web Services, Web Technology, Strategy, Enterprise Software, Software, Management
Wal-Mart, the gigantic discount retail which is able to offer discounts via a well-orchestrated systems-based supply chain, announced it is launching an online marketplace featuring close to a million items from various sources.
Speculation is that this is Wal-Mart’s move to capture some of the success Amazon has seen in the online space. While the retail sector suffered through the recent economic downturn, Amazon blazed along with barely a hiccup.
Now, if Wal-Mart really wants to take on Amazon across the board, they should consider an entree into the cloud space, such as that dominated by Amazon Web Services. Amazon essentially took its vast array of IT assets built for its e-commerce operation and turned it into a shared offering for the business IT sector.
Will we eventually see Wal-Mart do the same with its massively expanding IT infrastructure? Wal-Mart Web Services, anyone? (This is a tongue-in-cheek speculation, sort of…)
Joe McKendrick is an author and consultant with deep knowledge and insights regarding trends and developments in the technology industry. See his full profile and disclosure of his industry affiliations.
Email Joe McKendrick
Subscribe to Service Oriented via
Email alerts or .
SponsoredWhite Papers, Webcasts, and Downloads
