Adaptive Project Management Using Scrum

Adaptive Project Management Using Scrum - Part 1

Craig Murphy, www.craigmurphy.com

Scrum is a lightweight process that can manage and control software and product development: it is a project management process. However, instead of promoting the traditional analysis, design, code, test, deploy "waterfall" approach, Scrum embraces iterative and incremental practices. Similarly, instead of being "artifact-driven", whereby large requirements documents, analysis specifications, design documents, etc. are created, Scrum requires very few artifacts. It concentrates on what’s important: managing a project or writing software that produces business value.

What is Scrum?

The first question that you’ll probably want answered is: is Scrum an acronym for something? You would not be alone in thinking this; most other project management processes and techniques are acronyms. Scrum however is just a name, it’s not an acronym. Similarly, it has very little to do with rugby either, although there is a "daily meeting" that might be compared to a traditional rugby scrum.

Scrum borrows from the "agile" world through its promotion of iterative and incremental practices. It has a simple implementation that is designed to increase productivity and reduce the time it takes to benefit from a software/product development. Importantly, it embraces adaptive and empirical systems development.

That last paragraph introduced two of Scrum’s key facets: adaptive and empirical. The majority of project management methods and techniques are very prescriptive; they tie us down to a fixed sequence of events and offer little in the way of flexibility. Similarly, newer, less mature methods often claim to be a panacea, yet they lack any definitive proof or track history. Fortunately, Scrum is mature; it has a track record going back as far as 1995 and earlier. Similarly, it is scaleable: Scrum can be used on projects of any size. Whilst I will not be discussing it in this article, "Scrum teams" allow Scrum to be used to manage enterprise-level projects.

Scrum also promotes and lends itself to managing eXtreme Programming (XP) based projects. XP uses "customer on site" as a means of ensuring that the development team’s questions are answered but also to ensure that what the development team is producing what the customer actually wants.

The Opposite of Waterfall

Traditionally, we followed a cycle involving requirements gathering, analysis, design, develop, test, deploy with each stage being completed before moving on. This was known as the waterfall approach. Whilst there is a place for the waterfall approach, it has been the subject of a torrent of abuse in recent years. Most notably, the waterfall approach promotes the creation of up-front documentation before any real business value is created. This is confounded by the fact that product development is started downstream, or much later in the project’s expected timeframe. This has the obvious disadvantage of delaying the point at which business value can be realised.

But it gets worse: the customer/user endeavour to ensure that all of their requirements are documented during the early stages, thus the feature set is top-heavy. Failure to prioritise the feature-set often results in low quality systems that are overloaded with features that the customer/user does not actually require in "version 1". Indeed followers of Mary Poppendieck’s work (www.poppendieck.com) will know that "80% of a product’s value comes from 20% of its features".

With this in mind, can we conceivably build a product (a software product) that provides 20% of the feature set? Yes, we can and we do it iteratively. We can deliver "version 1" with 20% of the features, then, a little later, "version 2" with a further collection of features. The beauty of this approach is that development of 20% of the features should not take 100% of the project’s expected schedule and budget: we can realise business value much earlier in the cycle.

Scrum embraces the opposite of the waterfall approach whereby we start working on the analysis as soon as we have some requirements, as soon as we have some analysis we start working on the design, and so on. In other words, we work on small pieces at a time. This approach can be called iterative. Each iteration consists of some requirements gathering, some analysis, some design, some development and some testing culminating in an iterative release cycle (many deployments).

Scrum Basics

Scrum revolves around the ethos of simplicity, resulting in delivery of something that moves the project forward. It achieves this by proposing the following questions (referred to as Scrum’s three questions).

Scrum asks…	Fundamental Project Management issue
What have you done during the last 24 hours?	This is progress, it’s work completed to date
What do you plan to do in the next 24 hours?	This is forward planning, it is work you are about to do
What’s stopping you getting on with the work of the next 24 hours?	These are your impediments or obstructions, it might be things you need in order to work… more forward planning. It’s also identification of immediate risks.

Scrum Roles

Scrum uses three "roles": Product Owner, ScrumMaster and Project Team.

The Product Owner is possibly a Product Manager or Project Sponsor, a member of Marketing or an Internal Customer.

The ScrumMaster is key, he or she "represents management to the project". Such a role usually filled by a Project Manager or Team Leader. They are responsible for enacting Scrum values and practices (more about these shortly). Their main job is to remove impediments, i.e. project issues that might slow down or stop activity that moves the project forward.

The Project Team should consist of between 5-10 members. The team itself should be cross-functional, involving individuals from a multitude of disciplines: QA, Programmers, UI Designers, etc.

The Process

"Out of the box" Scrum is best described by Figure 1. Most projects have a list of requirements (type of system, planning items, type of application, development environment, user considerations, etc.) Scrum records requirements in a Product Backlog. Requirements need not be precise nor do they need to be described fully. As with most projects, the requirements are sourced from the expected users or "the business". The Product Owner prioritises the Product Backlog: items of importance to the project/business, i.e. those items that add immediate and significant business value, are bubbled up to the top.

The Project Team responsible for doing the actual work then creates a Sprint Backlog: this comprises of Product Backlog items that they believe can be completed within a 30 day period. The Project Team may liaise with the Product Owner and others in order to expand item(s) on the Sprint Backlog. After 30 days have elapsed, the team should have a "potentially shippable product increment". I will discuss the make-up of the Project Team later in this article, under the topic: Scrum Roles.

The Product Owner, the ScrumMaster and the Project Team will make an initial pass over the Product Backlog items where they work out roughly how long each item will take. Initially, these are estimates, best guesses. As time progresses, well within 30 days, we’ll know if the estimate was even close.

Scrum lets us refine our estimates on-the-fly: if we believe that a task will take longer than envisaged, we have the ability to say so before the tasks starts. By only ever working with small work packages (time-boxed to 30 days), any schedule/requirement issues are dealt with as soon as they are identified, not much further downstream where the cost of recovery is considerably higher.

What does this "potentially shippable product increment" actually mean? Put simply, every 30 days, the team should provide something of value to the business, something they can use or something that provides considerable direction.

The beauty of the 30 days approach is this: if the Product Owner, customer or the business likes what they see at the 30 day interval, they can then re-prioritise the Product Backlog. This is important as it means that we are only ever producing goods that will be used by the business: remember that only 20% of a [software] product‘s features are used frequently. In other words, 80% of a software product’s "value" comes from 20% of it features.

Figure 1 - The Scrum Process

Daily Scrum Meeting

One of Scrum’s primary practices is the 24 hour cycle shown in figure 1: the Daily Scrum meeting.

How many of you attend meetings on a regular basis? If you are in the corporate environment, meetings seem to be the norm and often they have little business value apart from to act as a caffeine injection mechanism. Folks who sit down at meetings get too comfortable: they attend meetings for the coffee and doughnuts, not for the project’s sake. Once relaxed, those same folks often stray off the meeting agenda and start discussing items that are either on the project periphery or are not even project related. I am sure you’ve all been in such meetings…

Scrum resolves these issues using two simple approaches.

Firstly, Scrum-managed project meeting rooms are devoid of chairs. Attendees have to stand up. This might sound cruel, but it focuses the mind and those folks who are capable of sitting in (often unproductive) meetings for hours on end are soon discouraged.

Secondly, Scrum-managed meetings are time-boxed or time limited. The Daily Scrum meeting is typically time-boxed to 15 minutes. Only extraordinary projects should require more than 15 minutes. Here is the crux: if you can’t say what you have to say succinctly in a short space of time, you’re waffling, get your coat. Keeping it time-boxed focuses folks’ minds and helps keep agenda items targeted at what’s important: Moving the project forward towards delivery of "something"… and identifying and removing obstacles that prevent this goal being met.

The purpose of the Daily Scrum meeting is to answer Scrum’s three questions:

1. What did you do yesterday?

2. What will you do today?

3. What obstacles are in your way?

But there is more! The ScrumMaster and the Project Team are the only people who are allowed to talk: outsiders may listen in, but are removed or silenced should they say anything. This is all about who is committed to the project or not. Outsiders tend to volunteer items that are important to them, but not necessarily to the project and its immediate goal: delivery business value within the 30 day sprint.

Scrum refers to those who are committed to a project as "pigs" and those who are not as "chickens". The story goes like this: A chicken and a pig where chatting about setting about a business together. The pig asked the chicken: "What kind of business would we set up?" The chicken thought for a moment and said "How about a restaurant?" The pig liked the idea but asked "What would we serve?" The chicken responded "How about ham’n’eggs?" At which point the pig refused to take the business venture any further. The chicken was confused and asked "Why?" The pig responded "Well, you would only be involved, whereas I would be committed."

One thing I should mention is the fact that Scrum expects late-comers to any of its meetings to pay a nominal £1, $1, or €1 fine: at various milestones within the project the fines are donated to charity. You may find this slightly humorous; however it does focus the mind and it does prevent meetings dragging on because of late-comers (we have all been in meetings that have to start over because of late-comers, right?) Late-comers are simply told to pay their fine, the meeting continues without further ado.

Adaptive Project Management Using Scrum - Part 2

Craig Murphy, www.craigmurphy.com

Scrum Artifacts

Scrum has remarkably few artifacts. There are three artifacts, each of which can be managed using nothing more than an Excel spreadsheet. More advanced / complicated tools exist, many are expensive, web-based or are still under development. Web-based tools are great, but they are not much good if there is no "off-line" operation: I conduct much of my project management (and thinking) in airport lounges where Internet connectivity is a pay-for luxury.

Figure 1 hints at Scrum’s artifacts: there is a Product Backlog and a Sprint Backlog. The Product Backlog is a prioritised list of first cut refinements. I say first cut, because the Product Owner is free to adjust the order in which Product Backlog items are development, they are even free to add new items this is the spirit of "agile".

Graphical feedback that can be printed out and displayed in a public place makes progress reporting very visible. Scrum encourages this kind of reporting and offers Burndown Charts as a means of graphically displaying a project’s progress or not as the case may be. We will take a look at burndown charts later in this article.

I mentioned earlier that Scrum’s artifacts can be managed by nothing more than a spreadsheet. Indeed, the Product Backlog can be represented using an Excel worksheet. Each Sprint Backlog then occupies another sheet within the same workbook.

Figure 2 presents a sample Product Backlog. Keeping with the ethos of Scrum and "agile", you shouldn’t be planning more than one sprint into the future. Indeed, the contents of a Sprint are usually defined during a "Sprint planning meeting".

Figure 2 – A sample Product Backlog

Using the information in Figure 2, we can derive another worksheet, the Sprint Backlog (Sprint 1). Figure 3 presents a sample Sprint Backlog: it contains a list of the things that will be "done" during the Sprint. Each Sprint item has an estimate of how long it should take to complete, usually measured in hours. Looking at figure 3 again, you can see that none of the six tasks have been worked on.

During the Sprint’s 30 day period, the Project Team must update the Sprint Backlog. For example, if BC spent four hours on item 1, Remove user kludge in .dpr file, on Tuesday 2nd (November in this case), he would enter ‘4’ into Sprint day 2’s Backlog item 1 column/row combination.

Figure 3 – Sprint 1 at inception

Keeping the Sprint Backlog updated is key: not only does it allow us to work out how fast a team can work (their velocity), it is an early warning indicator.

What is useful about the Sprint Backlog is its ability to be displayed graphically. Scrum uses burndown charts to represent "work done". Figure 4 presents a burndown chart where no work as been performed in the sprint. The idea behind burndown charts is that they should demonstrate a steady drive to zero hours remaining: it represents a pace of work that should be sustainable. In reality however, some work takes longer than others, and some are even shorter, so the burndown graph may not be a perfect straight line.

Figure 4 – Sprint Burndown, no work performed

Figure 5 presents a Sprint backlog that has been updated after work has been performed. Following the "Remove user kludge in .dpr file" item through, BC performed 4 hours work on Wednesday 3rd, followed by 2 hours work on Thursday 4th and finished the task on Friday by spending 2 hours on it.

You will also notice that on the same Wednesday, BC spent 4 hours on "Remove cMap/cMenu…". Assuming a working day of 8 hours, BC has split his time between two tasks.

Figure 5 – Sprint 1 after work has been performed

The beauty of the Sprint Backlog is its simplicity. By recording the hours of actual work completed versus the estimated hours to complete, we are able to plot equally simple, but powerful Burndown Chart that should provide you with the confidence that progress is being made. If the Burndown Chart does not indicate that progress is being made, then it has served another good purpose: it gives you an early warning that this sprint contains either too much work or too little.

Figure 6 presents a Burndown Chart based of Figure 5’s Sprint Backlog. Ideally, the Burndown Chart should indicate a level velocity, i.e. work is performed at a steady rate. In reality, we need to factor in weekends and other week-day distractions. As we will see shortly, if a Project Team or individual is distracted for a few hours, Burndown Charts are a great way of identifying the distraction very early in the project.

Figure 6 – Sprint Burndown after work has been performed

Figure 7 presents a burndown chart demonstrating that progress is being made, however by no means fast enough. The Burndown Chart gives us a clue that there is something wrong within 2 to 3 days of starting and confirms that work is not progressing at a good speed by days 7 through to 14.

There are a few reasons why this shape of Burndown Chart appears:

1. The Project Team, or individuals are being distracted from their work

2. The Sprint Backlog is not being updated

3. The Sprint Backlog items are too difficult

Figure 7 – Sprint Burndown after work has been performed, but not fast enough

Of course, Burndown Charts can reveal that the Sprint Backlog might finish early. For example, if a sprint does not contain enough work, you might end up with a burndown chart similar to figure 8. There are other reasons why a Sprint Backlog might appear to finish early:

Excessive working: if the Project Team works more that an 8 hour day (in this case), work might be completed "ahead of schedule". In reality, excessive working only ever appears to have short-term gain – the project will pay for it either in a loss of product quality and/or tiredness downstream resulting in loss of productivity.

Sprint Backlog item estimates may be incorrect: we may have to revisit our initial estimates as the work is being completed well within the existing estimates. This kind of exception can be caught if the Project Team know to announce the fact that the have completed a task ahead of schedule – the Sprint Backlog simply requires that a task is marked as having "0" hours remaining to indicate that it is complete.

Figure 8 – Sprint Burndown after work has been performed, but too fast (not enough work)

In reality of course, we notice burndown charts that have their ups and downs whilst still meeting their target. If the ups or downs are dramatic, then alarm bells can ring indicating that something is wrong with either the sprint’s scope or the sprint’s Project Team. Either way, you’ll get an early warning indicating that this sprint (less than 30 days of work) is about to encounter a problem. It’s better to encounter and solve project issues as soon as they arise: Scrum’s burndown charts put the project issues into context, better that you "lose" 30 days early in the project than you have to find time later in the project to fix mistakes made early on.

Sprint Backlogs and Burndown Charts are early warning indicators, they highlight "lack of progress". Similarly, they highlight scenarios where there is not enough work or work is too easy". However, their use does assume that everybody is committed to keeping the Sprint Backlog up to date and that is a job for the ScrumMaster.

With careful use, even these simple spreadsheets can assist in a number of other ways. For example, it is possible to extract "individual" Burndown Charts for each Project Team member. Whilst an overall Burndown Chart might highlight an overall problem with the project, using individual Project Team member Burndown Charts can help identify the one team member who is causing the problem!

Similarly, by allocating Sprint Backlog items to team members, we can respect their working time: ideally no employee should have to work more than a given number of hours per day (in this case 8).

Adaptive Project Management Using Scrum - Part 3

Craig Murphy, www.craigmurphy.com

Why Iterative Development Works

Consider figure 9, it presents an ideal profit and loss curve comprising of cost over time. Early in most projects, there is an initial hit, a start up cost and that’s the period below the line.

After some time passes, typically a number of years, the project starts to make some profit and that’s the period above the line.

Figure 9 - Profit & Loss using "traditional" development (from Software by Numbers)

The crux is getting the project into profit as quickly as possible. Obviously there are a number of tricks that you can use to achieve this, some of which may involve cutting corners, reducing quality, reducing scope etc. Beware if you do use such techniques – early inducement of the profit position point can be a short-term solution that may affect future profit. Poor quality (of product, of support, etc.) can lead to a reduction in future sales.

Iterative development is a technique that allows a controlled inducement of the profit position: if we can release a product earlier on an iterative and incremental basis, we can realise the benefit of the early release much earlier on in the project. Consider figure 10, it presents a typical profit and loss curve where iterative development has been applied.

Figure 10 - Profit & Loss using iterative development (from Software by Numbers)

Iterative development means you are able to deploy your application sooner than before. The earlier you are able to deploy your application, the sooner you can reap the profit.

Scrum promotes iterative development: every 30 days you have a "potentially shippable product increment" (or executable). If you are able to move much of the useful functionality into early releases, not only are your customers going to appreciate early access, they’ll be in a better position to confirm that they’re getting what they asked for.

Adapting Scrum

I have enjoyed reasonable success by adapting Scrum’s three questions. Early in 2004 I used the three questions in front of a small audience: they really appreciated the simplicity. They also appreciated the honesty that the questions seemed to portray: because of their simplicity, it’s difficult to incorporate untruths into the answers to these questions.

I discovered that my upper managers wanted four questions answered:

1. Summary of work completed to date

2. Summary of work completed in the last 14 days

3. Plan of work for the next 14 days

4. Project issues requiring their action

Ignoring question 1 for now, it’s clear that questions 2, 3 and 4 map directly on to Scrum’s three questions: "what have you done?", "what do you plan to do?" and "what’s getting in your way/stopping you working?".

If we keep track of our responses to Scrum’s first question, "what have you done?", it lets us answer question 1, it gives us a summary of work completed to date. Indeed, whilst I have not been able to implement Daily Stand Up Meetings, because of geographical and diary time issues, their benefit has not gone unnoticed. I have had some buy in to "stand up" meetings, but not enough: we don’t practice them right now.

Summary

I hope this article has provided you with a flavour of what Scrum is and how it can help you manage your next (or even current) project and help you deliver software incrementally instead of "big bang".

Keep asking these questions:

1. What is the simplest thing that can move the project forward?

2. Does what I am doing right now move the project forward at all?

3. Are there any impediments that are preventing progress?

I will let you think about figure 11. Where does your current/future project appear? Scrum lets us move our projects from "top right" towards "bottom left". Those projects that try to implement 100% of the requirements move themselves into anarchy; they try to do too much. By doing less work, accepting that 80% of a product’s value does come from 20% of its features means you can move through complex and complicated towards simple.

Figure 11 - Where’s your project?

Lastly, if you take one thing away from this article, it has to be Scrum’s co-founder, Ken Schwaber being quoted in April 2004, Vienna : "Don’t procrastinate, do something, no matter how small…"

Scrum: the ethos of simplicity and the art of the possible.

This article’s resources

1. Scrum: It’s About Common Sense http://www.controlchaos.com

2. Slide Deck accompanying this article: http://www.craigmurphy.com/sd/WhyScrumWorks.zip

3. http://www.scrumalliance.org : Pay your £1, $1, €1 late-comer fee via this site!

4. Software by Numbers: Low-Risk, High-Return Development, By Mark Denne, Jane Cleland-Huang. Prentice Hall PTR, 2003, ISBN 0131407287

5. Agile Project Management with Scrum, Ken Schwaber, Microsoft Press, 2004, ISBN 073561993X

6. Agile Software Development with Scrum, Ken Schwaber, Mike Beedle, Prentice Hall, 2002, ISBN 0130676349

Stacking Up High-speed Bluetooth Against Certified Wireless USB

By Mike Foley

April 2, 2007

The emergence of Certified Wireless USB and high-speed Bluetooth technology, both using the same WiMedia UWB radio, has led many to assume that one technology will dominate across all types of devices and usage scenarios, much as earlier wireless technologies, such as Wi-Fi and even today's Bluetooth wireless technology, had once been hyped as the single solution for all wireless needs.

Bluetooth technology defied the original "one-size-fits-all" hypeýand the pessimism that followedýby gaining traction in the market for which it was originally designed. Namely, mobile phones and the devices that connect to mobile phones.

Wi-Fi, too, established its own dominance in the market for which it was optimized: wireless local area networking between PCs and access points. While the marketplace did not satisfy observers' lust for decisive victory between Wi-Fi and Bluetooth technologies, it did sort out which technology is superior for each application.

Similarly, high-speed Bluetooth technology and Certified Wireless USB work best in different applications, and the marketplace will once again decide where each technology will land based on these technologies' core strengths.

Figure 1: Combined Bluetooth Certified Wireless USB protocol stack.

Bluetooth: Optimized for the Mobile Environment

Bluetooth technology has firmly established itself as the short-range wireless technology of choice for mobile devices and personal area networks. Its dominance in the mobile market is set to continue.

Led by strong penetration into mobile phones, over 600 million Bluetooth enabled devices were shipped in 2006, creating an installed base of more than a billion Bluetooth units. Growth in shipments is widely predicted to continue for years to come, and by the end of the decade, manufacturers will likely be shipping more than two billion Bluetooth enabled devices every year.

With data rates of up to three megabits per second, the Bluetooth radio has proven more than adequate for applications like streaming audio and voice, image and text file transfer, printing, and input from human interface devices.

Bluetooth technology has established the model for quick and easy setup of ad-hoc personal area networks between PCs, mobile phones, headsets, cars, cameras, printers, and other portable devices.

Crucial to Bluetooth technology's success in mobile devices has been the work put into the technology's profiles, defining usage scenarios as diverse as stereo music streaming, home-patient monitoring, and dial-up networking.

The Bluetooth profiles enable a driverless model where manufacturers need only incorporate the necessary profiles into their devices to be assured of compatibility and interoperability with companion devices from any manufacturer.

This "forward compatibility" means that today's products are compatible with tomorrow's accessories, with no driver installation or updates required. The Bluetooth wireless solution is perfect for "closed boxes" such as media players, embedded automotive electronics, and many mobile phones.

Mobile phones have already taken over the role of camera, address book, and personal organizer, with digital cameras, email, and Internet browsing capabilities standard features in today's high-end phones. Handsets continue to acquire functions once reserved for dedicated portable devices, and music-capable mobile phones are forecast to outsell dedicated MP3 players within several years.

Likewise, the array of accessories that connect wirelessly to the mobile phone continues to grow. Along with today's headphones, hands-free car kits and speakers in the car, in the office, and at home, tomorrow's mobile phone will be able to connect to video screens.

According to Fiona Thomson of IMS Research, "The equipment where Bluetooth has established itself is increasingly being used to provide data-hungry applications. Where once a short-range wireless connection was used to synchronize an address book, it may now be used to synchronize part of a music collection.

"With these changes in use there was a threat that Bluetooth could be left behind, restricted to voice applications and to handset and headsets products. However, with its combination with UWB, being able to utilize the technology's high data rates has meant that Bluetooth has the potential to be more than just a voice application."

High-speed Bluetooth technology opens up new media experiences, letting the user stream video and music content stored on the mobile phone or other portable player to whatever screen and speakers are nearby.

Synchronizing music and video libraries becomes easier than ever before, with high speed Bluetooth technology allowing wireless transfer of data between media player and PC at the speed of today's wired connections.

At home, high speed Bluetooth technology will enable streaming high-definition video and "surround sound" audio from a portable media player to a home theater. The experience will be enhanced further by a screen on the TV remote control that will show "picture-in-picture" videoýor live video from a baby monitor in the next room.

In the car, video will stream from the phone to the car's built-in video screens, while digital still and video cameras will display images on the TV or computer screen, or print them directly to a photo printer.

Legacy Bluetooth Applications

To ensure that tomorrow's Bluetooth enabled devices can connect to the billion Bluetooth devices already shipped, high speed Bluetooth technology will retain the robust, power-efficient 2.4 GHz radio found in existing Bluetooth devices.

This dual-radio approach means that devices always have a low-power channel available for pairing and maintaining connections when high data throughput is not required and provides backward compatibility with the installed base of over a billion devices.

This strategy allows devices such as headsets, mice, and keyboards that require long battery life but limited data rates to continue to use the 2.4 GHz radio for low power communications, while maintaining compatibility with high speed Bluetooth devices.

Certified Wireless USB: Strengths and

Having emerged as the primary contender among a variety of technologies advertised as "wireless USB," Certified Wireless USB will assume its place as the pre-eminent wireless USB technology once qualified (or "certified") devices begin shipping in 2007.

Certified Wireless USB is backed by the organization responsible for wired USB, the USB Implementers Forum (USB-IF), and enjoys broad industry support.

Certified Wireless USB will come to market with the advantage of wired USB's proven position as the interface of choice for connecting peripherals to the PC. Early Certified Wireless USB devices will attempt to replace the cable for existing USB devices using so-called Device Wire Adapters (DWAs).

By converting a PC's USB port into a wireless USB hub, DWAs will quickly extend wireless capability to a host of USB devices, such as printers and scanners, while opening up new applications such as wireless stereo speakers for the PC. For devices that traditionally connect to the PC in a 'host-to-device configuration, Certified Wireless USB will most likely enjoy a quick market adoption.

However, as Bluetooth wireless technology has demonstrated, simply cutting the cord changes the way people use their electronic devices, and Certified Wireless USB must take these changes into account if it is to move beyond simple cable replacement into a technology that changes the way people use technology in their daily lives.

Without products available today, it is uncertain whether Certified Wireless USB will grow into product categories outside of the PC environment, USB's traditional domain.

Unlike wired USB, which was designed from the start for connections from a PC to a peripheral device, Wireless USB must accommodate so-called "dual-role" devices in situations where it is not clear which device should govern the connection.

Under Certified Wireless USB it will be possible, for example, to connect a camera directly to a printerýboth devices that would fall under the category of a peripheral when connected to a PC via wired USB.

Such devices have given rise to the need to "re-architect" USB for the wireless environment. Those who expect the switch from wired to wireless USB to be as easy as placing a radio on each end of the connection are bound to be disappointed, as issues caused by the move to wireless have made Certified Wireless USB significantly more complex than regular wired USB.

The USB protocol was designed to work in the safe confines of a cabled connection, where data packets arrive predictably and on time, and where the two devices are always in touch with one another.

By contrast, in a noisy, unpredictable radio environment, obstacles such as the loss of large chunks of data due to interference, not to mention connections that are dropped entirely, are commonplace.

Certified Wireless USB requires additional layers of complexity to handle the loss of significant amounts of data and the need to re-establish connections in a noisy RF conditions.

Usability, Pairing, and Setup

As one of the first true "plug and play" interfaces, wired USB represented a major leap forward in improving ease of use for PCs and peripherals. In the consumer's mind, wired USB possesses a brand image all wireless technologies envy: it is simple to connect, and devices "just work" with each other.

In the translation from wired to wireless, the USB-IF faces the same tradeoffs between security and ease-of-use that Bluetooth technology engineers dealt with years ago, and by the time devices come to market, the Certified Wireless USB user experience will look very similar to that of Bluetooth wireless technology.

Certified Wireless USB has adopted a similar device pairing technique: pressing a button on each device and comparing a visual indication on both devices to confirm the devices have found each other.

Consumers unfamiliar with this process face a learning curve just like they would with Bluetooth technology. The constraints imposed by operating in a wireless environment require very different user interactions as compared to the "plug and play" experience consumers have come to expect with wired USB.

In fact, to get around these constraints, proposals exist for the optional use of a wired USB connection in order to pair Certified Wireless USB devices. While simple and familiar, the wired pairing model will seem anachronistic to many consumers expecting a full wireless experience, and is impractical for the type of "ad-hoc" or "peer-to-peer" pairingsýsending a calendar appointment to a business colleague, or transferring a file from one PC to another at a meeting, for exampleýwhere Bluetooth wireless technology excels.

Meanwhile, like wired USB, Certified Wireless USB will continue to require the use of driversýsoftware installed on the PC or mobile phoneýto properly manage connections between devices. This stands in contrast to Bluetooth technology, which enables a full-featured "out-of-the-box" user experience without requiring any software installation.

There is no guarantee that Wireless USB will satisfy users who expect wired USB-like simplicity in setting up their Wireless USB products, and customers are quite unforgiving of difficult technology; according to recent data from Microsoft as quoted in PC Magazine, 30% of wireless access points are returned because customers have trouble setting up the devices.

Name and Trademark Issues

To complicate matters further, the USB-IF will face an uphill struggle to establish a brand that represents compatibility and ease of use in the customer's mind. A 2005 brand awareness study by Millward Brown revealed that nearly 30% of consumers in the UK, US, and Japan believe they already own one or more wireless USB products, even though no Certified Wireless USB devices have been shipped to date.

In reality, these devices that consumers associate with Certified Wireless USB actually represent a combination of Wi-Fi, Bluetooth technology, and other proprietary wireless devices. Thus any wireless device or adapter that plugs into a USB port is at risk of being considered "Wireless USB."

Unfortunately, the USB-IF has lost trademark control over the term "Wireless USB' and has been forced to adopt 'Certified Wireless USB" as an enforceable brand name. The Cable-Free USB and WirelessUSB brands, along with the large number of Wi-Fi and proprietary products currently marketed as "Wireless USB," have set a compatibility trap that will spring as soon as Certified Wireless USB devices start to hit the market.

None of these different but similar-sounding brands are interoperable with one another, though buyers have so far shown little ability to discern among the different technologies.

Power Requirements

One of the main benefits of UWB radio is its extremely high power efficiency: by sending so much data so quickly, the "power per bit" required is extremely low when sending large amounts of data. Unfortunately, this form of power efficiency is only useful when sending large amounts of data at a time.

For devices that spend most of the time in "sleep" or "standby" mode, the existing 2.4 GHz Bluetooth radio requires far less power than the UWB radio to maintain a connection.

Current estimates place the standby battery current drawn by the UWB radio in standby mode at 20 to 100 times greater than that of the 2.4 GHz Bluetooth radio in its standby mode.

Bluetooth enabled keyboards and mice, which only need to transmit a few bytes of data at a time with long periods of inactivity, enjoy much longer battery life than they would with a technology such as Certified Wireless USB that lacks a low-power alternate radio.

For this reason, Bluetooth technology will remain the wireless standard of choice for connecting human interface peripherals to PCs, PDAs, and mobile phones. Global Regulatory Issues The USB-IF has chosen the 3-5 GHz frequency band for Certified Wireless USB's WiMedia radio, achieving a shortened silicon development cycle but subjecting Certified Wireless USB to limited global regulatory approval.

Outside the United States, much of the spectrum below 5 GHz remains encumbered with restrictions, and in the spectrum that is allowed, costly detect-and-avoid (DAA) schemes are required to utilize the full allowed bandwidth.

In contrast, High Speed Bluetooth Technology is designed to operate above 6 GHz, where more spectrum is available around the world. The Bluetooth Special Interest Group brings its proven regulatory negotiating expertise to the table, ensuring that High Speed Bluetooth Technology is a truly global solution.

Conclusion

As has happened with today's wireless technologies, manufacturers will pick the right UWB-based wireless technology for the job, and the marketplace will put an end to the "one-size-fits-all" hype.

Built on top of the highly successful wired PC interface technology, Certified Wireless USB lets manufacturers take advantage of specialized software for their own devices, in the same way that a conventional USB printer or camera is supported by specialized software installed on the PC.

Designed to "cut the cable" for USB devices, Certified Wireless USB is a logical choice for applications that are already designed to run on the PC through a USB interface, such as printers, scanners, cameras, and other highly capable and specialized PC peripherals.

These PC-centered devices will continue to utilize the extensibility that has made USB successful, including software updates and downloadable drivers, while taking advantage of the freedom and convenience that Certified Wireless USB offers.

The choice is a different one for devices outside of the core PC/USB realm, where the requirement for software installation is a disadvantage, and where existing software development and compatibility assurance is most beneficial.

Supported by extensive software development and the standardized profiles that can be easily built into a product for instant compatibility with all varieties of companion devices, Bluetooth wireless technology is perfect for the "ecosystem" of devices built around the mobile phone, as well as the growing array of sophisticated devices in the home and office, including set-top boxes, televisions, and game consoles.

All of these devices need to support a broad range of compatible devices right out of the box, and High Speed Bluetooth Technology ensures this compatibility for today's and tomorrow's devices.

The WiMedia UWB radio opens up exciting new applications such as streaming video, bulk photo downloading, and MP3 player synchronization. Retaining the proven, highly economical 2.4 GHz Bluetooth radio as secondary channel, high-speed Bluetooth technology also ensures backwards compatibility with the one billion Bluetooth enabled devices shipped to date, while offering a low-power connectivity mode for the best possible battery life in mobile handsets, mice, keyboards, and other battery-powered devices.

Mobile phones will continue to add capabilities for both work and play through rich music and video streaming experiences, in-phone video cameras, email synchronization, and other functions already appearing in the latest high-end handsets.

In the next few years, mobile phones will be firmly established as the center of the user's on-the-go media and computing experience.

Users will continue to learn the benefits of printing from their mobile phones via Bluetooth wireless technology, while high-speed Bluetooth technology will provide the needed connectivity for the growing array of video devices centered around the mobile phone, including televisions, set-top boxes, and in-car video screens.

As IMS's Thomson elaborates, "High speed Bluetooth is optimized for different scenarios than previous Bluetooth solutions and is expected to penetrate into a growing number of portable electronic devices to provide new use cases such as transferring music to a portable digital media player, downloading a music video onto a cellular handset and streaming video.

However, high speed Bluetooth will meet head on with Certified Wireless USB (WUSB) in some applications. IMS expects high-speed Bluetooth to remain dominant in cellular handsets and WUSB to become prolific in the PC space, however, in certain portable applications such as printers and digital cameras the market will have to decide."

Meanwhile, there is another factor at work that will likely influence the market's decision: the number of individual radios in today's high-end mobile phone is increasing at a rapid and potentially unsustainable rate.

Added to today's cellular, Wi-Fi, infrared, and Bluetooth radios will be a variety of specialized radios such as Near-Field Communications (NFC) and RFID. There is only so much room for radios in a mobile phone, and manufacturers will need to pick the few that offer the best connectivity per dollar and per square centimeter of circuit board.

Bluetooth wireless technology, the solution with global regulatory approval, proven ease of use, and profile support, is the obvious choice for the mobile devicesýand the devices they connect toýtoday, tomorrow, and into the future.

---

Dr. Michael Foley is the Executive Director for the Bluetooth Special Interest Group (SIG). He joined the SIG in March 2004 as the Executive Director. He is responsible for guiding the qualification and interoperability programs, promotion of the technology, the specification publications, and the long-term roadmap of Bluetooth wireless technology. Dr. Foley previously worked with Bluetooth wireless technology and other WPAN and WLAN technologies as a senior wireless architect with Microsoft.

Amazon EC2 and Oracle SOA Suite a Strong Combo

Amazon EC2 and Oracle SOA Suite a Strong Combo

Agility meets extensibility in the combination of Amazon EC2 and Oracle SOA Suite 10g

By Mamoon Yunus, Rizwan Mallal, and Dave Shaffer
Jan 14, 2007

The union of Amazon Elastic Compute Cloud (EC2) and Oracle SOA Suite is a match made in heaven. Recently, we tested Amazon EC2 by marrying components of Oracle SOA Suite with EC2 to demonstrate how utility computing and SOA are shaking the foundations of current IT provisioning, development, deployment and maintenance models. This article examines how SOA technologies enable utility computing to move beyond the vision stage and become a reality.

Amazon EC2 is a massive farm of Linux servers at your finger tips. It enables you to bring up a single server or many server instances -- all installed with preconfigured Linux images -- with a single command. You can use pre-packed Linux images provided by EC2 -- public images are currently available that include Apache and MySQL -- or build new images and upload them to Amazon's S3 storage service.

Organizations have to anticipate expected load/traffic and plan the capacity accordingly, but they often waste capacity during idle time. Amazon EC2 eliminates the need to do capacity planning. Organizations can use the dynamic provisioning of Amazon EC2 instances to scale up and down based on the load, making optimum use of the infrastructure, smoothing out utilization curves, and saving costs.

The recently released Oracle SOA Suite 10g is a packaged set of standards-based components for enabling web services-based SOA. Oracle SOA Suite covers web services development, orchestration, monitoring, and security. Within the SOA Suite, Oracle BPEL Process Manager orchestrates transactions across disparate applications within and across corporate boundaries. But across all such technologies, what is important in the context of this article is that they be Web-service enabled and support a grid computing model where several low-cost servers can be deployed in a cluster to provide scalability and high availability.

Web services-based SOA has fundamentally changed how applications integrate. Add on top of that Amazon EC2 to host your business operations, and you get a potent combination. The significant, yet unnoticed breakthrough of Amazon EC2 is in its ability to spawn up a server instance by a mere web-service call. In addition to a command line interface, EC2 provides a detailed provisioning WSDL that can be used by any web-services application to dynamically control (e.g., run, terminate, authorize) Linux instances within the Amazon Cloud.

This EC2 provisioning enables WSDL-aware products to readily call into EC2 through SOAP-based messaging. Because of this approach, SOA platform products and orchestration languages like BPEL can now be extended beyond their typical application development role to also manage infrastructure provisioning. Now the same components which run business applications can also control dynamic provisioning and maintenance of the very physical infrastructure that they are deployed on. With Amazon EC2, for the first time, SOA components are aware of and in control of their host machines and can clone new instances of themselves based on environmental factors such as user load, available resources and cost.

Shifting Sands: New Business and Usage Models

Amazon Elastic Compute Cloud is a pragmatic beginning to utility computing that has the potential of transforming how IT assets are used. With EC2 a number of new business models and shifts are emerging such as:

Software Rentals: Software as a Service (SaaS) now moves from renting entire business applications such as Salesforce.com and NetSuite to renting industrial strength software components. Companies like Oracle, SAP, BEA and IBM now offer SaaS but have to create their own enterprise-strength infrastructure for it and typically only offer entire packaged applications through this model. An external compute capacity provider like EC2 brings the same capability to all organizations, while grid-enabled SOA infrastructure and applications mean they can actually take advantage of it.

Of course, open source software fits this model particularly well. In EC2 beta, Amazon has provided public images of Apache and MySQL, indicating the direction of things to come.

Zero-Configuration Services: AMIs are pre-configured, pre-packaged templates that can be instantiated by a simple web service call. Software vendors can "ship" their products in the form of pre-configured images that will never require any sort of configuration and/or installation and it just works. With the ability to pass in configuration data to instances at launch time (Parameterized Launches), AMIs can be created more generic in nature and vendors can "ship" generic images and instantiate instances with "editions." For example, an Oracle AMI can be packaged to spawn an "Oracle App Server with 8i DB" Instance or an "Oracle App Server with 10g DB" Instance.

Value-Add Services: Much like StrikeIron and Xignite provide Functions for Rent, a new breed of service providers will emerge that harness the scale of Amazon EC2 to provide and charge for general purpose and business specific Web services.

General purpose web services are independent of business process and can include operations such as time-stamp, sign, encrypt, validate, or archive a SOAP message. Business specific services are related to core business functions and may include operations such as calculating mortgage payments, sales commissions, or sales tax. Rentable business-specific operations may mature into manageable modules of complex business processes such as processing insurance claims, aggregated items catalogues or fulfilling customer orders. Amazon EC2 Images can be shared with other users, and this will enable users to reuse already existing AMIs (created by other users) that are completely pre-configured with installed software (say Oracle App Server with Oracle 10g DB and Ordering BPEL process)

IT Asset Marketplace: Amazon EC2 is ideal for building shareable and reusable services. For example, User 1 can share with User 2 an entire pre-packaged EC2 Linux image with configured applications. Imagine an "AMI Marketplace" where users could shop for Images and reuse and in fact even start working on somebody else's unfinished work (AMI). The marketplace concept could be further extended to enabling corporations to sell their under utilized assets dynamically and buy required assets from sellers. IT asset trading exchanges could become a possibility although such exchanges would only follow heavy commoditization and liquidity of such services.

Outsourcing Testing: There will be a new twist in Quality Assurance and Testing, especially the outsourcing companies. Since Outsourcing companies can provision instances as "testboxes" and since they only pay for as much as they use, they now have the ability to bill their customers for infrastructure they used for a project and also relinquish the "testboxes" when the project is over. Not to mention, they can get as many test boxes as they need at their disposal for stress/load/functional testing.

Setup: Oracle SOA Suite and Amazon EC2

To understand the merits of EC2 combined with Oracle SOA Suite, we set up a joint Oracle & Amazon architecture as shown in Figure 1. We started by loading Amazon EC2 WSDL and Amazon S3 WSDL into SOAPSonar, a SOA testing tool from Crosscheck Networks . The EC2 and S3 Web services interfaces provide full provisioning control with capabilities such as stopping and starting servers in EC2 and creating and viewing image storage buckets in S3. It is this provisioning through SOAP messaging, without having to write a single line of code, that makes Amazon EC2 and S3 so powerful. For detailed setup instructions see Using SOAPSonar to Provision Amazon EC2 .

We continued our provisioning process by starting a clean, publicly available Linux Amazon Machine Image (AMI). Once a base Linux image was up and running in the Elastic Cloud, we installed Oracle Application Server 10g (OC4J). Using Oracle JDeveloper, we built a couple of simple web services getServerInfo() and getDate() and deployed them on our OC4J instance running in the Elastic Cloud. Once we were happy with the base configuration of our OC4J Application Server, we bundled the image (EC2 chops the image into small manageable parts), uploaded it on Amazon S3 in a storage bucket named oc4j, and finally registered the image with EC2. When an image is stored on S3, it is fully preserved for future instantiation by EC2.

Figure 1: Oracle SOA Suite components deployed with Amazon EC2

As shown in Figure 1, we started two instances of our new Oracle Application Sever image using SOAPSonar as a Provisioning console. Next we installed Oracle BPEL Process Manager outside the Amazon Cloud for use as an orchestration engine across the two instances of Oracle Application Server.

We loaded the Transactional WSDL generated by the Oracle Application Server instances and the WSDL generated by the BPEL engine into SOAPSonar. The transactional WSDLs gave us the ability to unit test each instance of OC4J and system test the BPEL engine from within the SOAPSonar console.

Our setup was complete. We had both Provisioning control and well as Transactional control over our SOA infrastructure deployed in Amazon's Elastic Compute Cloud.

Grid Orchestrator: BPEL Engine

Oracle BPEL Process Manager is a natural infrastructure fit for a utility computing-based SOA. Typically, BPEL engines are used to orchestrate and execute business processes. However, in our setup we deployed a BPEL process for SOA traffic management such as failover, switching, load balancing and parallel processing across the Oracle Application Server instances in the Amazon EC2 cloud. While there are lots of ways to handle traffic management, many of which are more appropriate than BPEL, this was an interesting architecture because it demonstrated the dynamic capabilities " here including dynamic orchestration of services, provisioning and even run-time traffic across the instances on the cloud.

Let's examine a few of these traffic management functions across multiple copies of a web service. Figure 2 shows a simple BPEL process modeled using Oracle JDeveloper.

Failover: To see how Failover can be accomplished, consider Figure 2 with an Invoke_OracleAppServer_on_Amazon_EC2 task in the BPEL process calling a Partner Link Amazon_EC2 . This Partner Link has a property named location defined with two service endpoint URIs listed:

1. http://domu-12-31-34-00-00- 0d .usma2.compute.amazonaws.com:8888/EC2
2. http://domu-12-31-34-00-00- e0 .usma2.compute.amazonaws.com:8888/EC2

These endpoints only differ in the URIs and provide identical instances of the web services hosted on Instance #1 and Instance #2 on EC2. The number of instances can be scaled by a single EC2 command the corresponding additional endpoint URIs can be added to the location endpoint URI list. The BPEL engine provides extensive fault handling capabilities including managing runtime exceptions . If the first Amazon EC2 instance URI becomes unavailable because of a network, software or hardware failure, a run-time fault occurs that automatically enables the BPEL engine to retry the second instance URI.

Figure 2: BPEL Flow for Failover across OC4J instances deployed within Amazon EC2

Using such failover techniques adds resilience and reliability to Web services hosted with Amazon EC2. Oracle BPEL Process Manager extends the virtualization capabilities of Amazon EC2 by adding failover across multiple instances of web services deployed in the Amazon Cloud.

Switching: Figure 3 is a process display for switching between two instances of Oracle Application Server deployed in the Amazon Cloud. The switching condition is defined in the case statement and can be based on any input parameter extracted from the client request. For example, a certain class of purchase-order numbers for platinum customers can be targeted towards Amazon 1 whereas others can be sent to Amazon 2 endpoints. Such content-aware switching can align resource costs with preferred customers and provide granular IT asset alignment with revenue.

Switching can be combined with other SOA traffic-management functions such as Failover. For example, Amazon 1 in Figure 3 below can have multiple failover endpoints " as shown in Failover Figure 2. This would ensure that the corporation is paying a premium for providing reliability only for high-value customers by enabling significant redundancy, whereas the low revenue generating customer would be sent to nominally redundant partner links.

Figure 3: BPEL Flow for Switching across App Server Instances in EC2

Additional Traffic Management: A few additional SOA traffic management processes are described below:

Dynamic Scalability: Oracle BPEL Process Manager provides a powerful mechanism called dynamic binding . This enables a BPEL process to decide which endpoint to call at run-time. A BPEL process can start off by invoking the Amazon EC2 SOAP API and calling the DescribeInstance operation. This operation can return a list of all instances running and available to the BPEL process within the Amazon Cloud. Once all the endpoints are known, dynamic binding can be used for failover, switching, load balancing or any other traffic management algorithm. This is called a "Parameterized Launch," which lets you pass configuration data at launch time and you can also "read" Instance Metadata like IP address, DNS, and so on, from the EC2 API.

Concurrent Processing: Oracle BPEL Process Manger provides Parallel Flows to perform multiple tasks at the same time. Selected computationally intensive processes can be deployed within Amazon EC2 and Parallel flows within a BPEL engine can be used to control client interaction with such intensive processes. With flowN activity, any arbitrary number of parallel branches can be invoked dynamically based on the upstream data available. For example, a process can first determine the number of endpoints available through an invoke call to Amazon EC2 DescribeInstance . If an array of say 5 endpoints is returned by Amazon, this data can then be sent to the flowN activity to create 5 branches for simultaneous invocations of the 5 Amazon EC2 instances.

SOA: Practice of Grand Unification

Oracle SOA Suite components and Amazon EC2 Grid Provisioning both provide native support for Web services. This enables Web services-aware client tools, such as SOAPSonar to act as a unifying console for end-to-end testing and management. Figure 4 shows a screen shot of SOAPSonar with a number of WSDLs loaded. As shown in Figure 1, the WSDLs can be categorized as Provisioning WSDLs , those that help manage the environment, and Transactional WSDLs , those that are used to pass SOAP messages for business processes. With a unified console such as SOAPSonar users can readily manage multiple Linux instances, manipulate storage, and test transactions across SOA components.

Figure 4: SOAPSonar Console controlling Amazon S3, EC2 and Oracle SOA Suite.

Within a complex SOA deployment that goes across corporate boundaries, a product like SOAPSonar can enable:

Provisioning: Control both hardware and software assets provisioning from a single console. User can create Linux images on Amazon S3, provision them on Linux Servers, start and stop such servers, add newer instance of an image stored on S3. Beyond just hardware provisioning, the user can also control software assets such as Oracle OC4J within the Amazon Cloud through simple SOAP API calls.

Unit Testing: Each software component can be unit tested independently from within the same console. A user can ensure that all published services are up and running and meet functional, performance, and interoperability base-line requirements.

Production Controls: Users can test SOA component reliability, scalability, fault-tolerance and availability by pointing the test console to different components within the SOA deployment and continuously checking the health of published services against established base-lines.

As shown in Figure 4, SOAPSonar provides Unified Provisioning and Transaction Controls for SOA components deployed in a utility computing model.

Dynamic Provisioning: We are starting to see enterprises deploy automated business processes using standards like BPEL and put in place rich real-time monitoring dashboards using Business Activity Monitoring (BAM) products like Oracle BAM. The power of BAM is that an organization can monitor in real-time how they are doing in terms of processing business transactions and meeting service level agreements. This provides business visibility into conditions that may cause SLAs to be violated. However, besides being aware of the problem, the real value here is only achieved when the problem can be addressed is a timely fashion. With utility computing approaches like EC2 that can be provisioned dynamically, we believe that self-regulating systems will start to emerge such that a system will identify a need for additional computing power, generate an alert (because people will always want to know about such a condition), and then automatically provision new grid servers to handle the surge in load. When the surge abates, the additional servers can be released. While such self-regulating systems may seem futuristic, all the pieces are in place today for them to emerge.

Optimized SOA

Amazon Elastic Compute Cloud is an ideal hosting environment for commodity SOA components. Web services-based administration and provisioning of Linux servers on-the-fly heralds a new era of dynamic traffic management. With such flexible SOA components, reliable, resilient, scalable and high-performance SOA deployments can be built on utility computing infrastructure that lives outside corporate boundaries. Some simple enhancements to the Amazon Web services API and open collaboration with the developer community as well as with commercial software vendors could position Amazon EC2 as the utility computing platform of choice. Overtime, business models, service level agreements, and regulatory requirements will all find a happy balance to optimize IT assets' efficiency. We anticipate that the Amazon EC2 cloud coupled with grid-enabled software like Oracle SOA Suite will help realize IT gestalt: The whole is greater than the sum of the parts. At the same time, the ability to share computing pools across many users can smooth out the issues of peak loads for much more efficient use of resources. This will enable an effect which could be called "economic gestalt": the whole costs much less than the sum of the parts .

---

Mamoon Yunus is CTO of Forum Systems and a pioneer of SOA Gateways & Firewalls. Prior to Forum, Mr. Yunus was at webMethods where he developed XML-based techology. Mamoon holds two Graduate Degrees in Engineering from MIT.

Rizwan Mallal is Technology Director at Crosscheck Networks and Chief Security Architect of Forum Systems. Previously, Rizwan held various positions at Sonicwall and Raptor (now Symantec). Rizwan holds a Masters in Computer Science from University of Vermont.

David Shaffer is Sr. Director of Product Management at Oracle for the Oracle SOA Suite and Integration products. Prior to Oracle, he has held leadership roles at a wide-range of technology companies including Collaxa, Apple Computer and NeXT Software. Dave can be reached at david.shaffer@oracle.com.