Web Services
On the subject of Web services, you have several potential revenue opportunities with this one technology. But implement it carefully.

As mentioned, creating Web services around your core code allows you to incorporate it into a variety of other offerings, from SaaS to mobile to a few more you're about to discover. But depending on your business, you might also consider offering some key functionality to customers, or even third-party developers, on a subscription basis.

Do a quick search on "Web services API" and you'll find a ton of free services from sites like Yahoo, Google, Amazon, Flickr, and others. Dig a little deeper and you'll find thousands of free and paid services that you can experiment with or incorporate into a solution.

Think about your core business. If your company offers a lead management system, for example, then what kind of logic could you sell separately? Perhaps you can package a "Hot Lead" class as a service in a way that allows customers to incorporate your product into their internally developed time management system. Or perhaps as an add-on to the clinical trial application you market to the medical industry, you can offer labs a collection of Web services around scheduling and notification, which they can integrate into a custom Microsoft Office Outlook application.

With some creativity, you'll discover a lot of potential new markets for your existing code, with comparatively little additional investment in development. But do your research, especially around the issue of security. Poorly designed Web services can open your system to attack or worse. When you develop your service, you'll notice that it can be accessed through a public .asmx page which can easily be discovered using the right software. Tales abound of companies who have carelessly exposed functions like GetAdminUsers() in those same public services because their developers were too lazy or inexperienced to architect their code properly.

Read this:

Bookmark this:

Embedded Applications
As you can see from a recent Q&A with Mike Hall, embedded systems are growing tremendously in reach, sophistication, and market size. For developers unfamiliar with this space, the confusing point here is the difference between mobile and embedded. In general "embedded" is a classification of small-footprint operating systems that can be installed, in most cases with custom locked-down configurations, on specialty hardware devices. These devices can include anything from digital billboards to kiosks to set-top boxes and TVs to GPS devices to cash registers to Thin Clients to light switches. And, of course, to mobile devices. So "mobile development" is then the practice of coding to a specific embedded deployment, in this case a custom configuration of Windows Embedded CE onto which an set of applications and common APIs have been added, known as "Windows Mobile 6." Likewise, "embedded development" is the practice of coding to a hardware device that contains its own chipset and runs an embedded OS.

Currently, Microsoft offers four types of embedded systems: a low-foot print OS less application platform (.Net micro Framework), a low foot print componentized OS (Windows Embedded CE 6.0), a componentized version of Windows XP Professional (Windows XP Embedded SP2), classic desktop and server OSes for use on embedded systems (Windows XP Professional, Windows Vista Business and Windows Vista Ultimate, numerous versions of Windows Server 2003 based servers) Componentized OS allow manufacturers to pick and choose individual components and build a low footprint OS that's most appropriate to the particular platform and application they're providing. For example, an airport terminal likely doesn't need the ability to print or scan bar codes, like a point of sale terminal does. Another embedded system that doesn't allow componentization but has an ultra-low footprint and can run on a bare hardware without MMU and OS, is the .NET Micro Framework. It can live on small devices and appliances, like your light switch or a SideShow™-compatible device, which I'll go over in a moment.

By definition, building an embedded application requires you to target a specific hardware device and, usually, develop and test using a physical emulator board provided by the device manufacturer. Fortunately, you can still leverage your tools, coding skills, and code. As with the other deployments described here, you'll use Visual Studio and the appropriate SDK, such as the Platform Builder for Windows Embedded CE or Target Designer for Windows XP Embedded.

Your targeted platform will determine how extensible your code needs to be. Windows XP Embedded, for example, compares to Windows XP Pro in its feature set and available APIs. In fact, it's designed to run regular Windows-based applications. Windows Embedded CE 6.0, on the other hand, uses a subset of Win32® APIs and/or the .NET Compact Framework (it supports both, as well as MFC), so you may need to revise your code. .NET Micro Framework jettisons so many extraneous features that you would probably need to look at this as a value-add product. In other words, start fresh but tie into your existing solution. That is assuming you have both a micro device and a use for it. (CRM on a toaster? Maybe not. But weather on a coffeepot? Definitely!)

The biggest challenge, nay opportunity, for extending your app to the embedded market will be finding the right hardware supplier. For example, you can upsell your inventory management software by providing a new Bluetooth-enabled barcode scanner that syncs with mobile devices running your app. But to break new ground, what about building a barcode scanner with its own embedded OS, onto which you install your app directly?

Look over the Q&A for an overview of the different types of embedded systems. Then peruse the Embedded group's MSDN® site to go deeper into the how-tos.

Read this:

Bookmark this: