Boost Employee Productivity by Replacing Proprietary Distributed Broker Technologies with Open RESTful APIs

New Orleans

Move your older, distributed broker technologies like CORBA, RMI, DCOM & RPC to REST APIs that communicate with any device, app, browser or endpoint.

A lot of the bigger companies built large, complex, distributed systems that relied on a variety of technologies to make them work. For example, code in an app makes local function calls in order to get things done. In distributed systems that spanned multiple servers, data centers and geographies, the notion of software in one system calling a function in a system somewhere else was referred to as a remote procedure call (RPC). This was a transformative technology but making it work wasn’t trivial.

The Object Management Group created the specification for the Common Object Request Broker (CORBA) based on the concept of interface definitions. Microsoft created a distributed form of its Common Object Model (COM). Sun baked a Remote Method Invocation (RMI) technology in Java and later added support for CORBA. Lots of distributed software built in the 90s used this stuff to make remote procedure calls, but it was tightly-coupled to those respective technologies and therefore not extensible.

The Simple Object Access Protocol (SOAP) and Extensible Markup Language (XML) came along in the early 2000s and put all those earlier technologies out of their misery. This technology had broad support from standards bodies and corporations alike because it was based on HTTP, worked over the Internet and was platform-agnostic. Web Services were born. All kinds of specifications were created to perform every kind of object passing and remote function calling needed to build cross-platform, distributed systems. A new discipline around Service Oriented Architecture (SOA) came to life based on SOAP.

While SOAP was taking off, Roy Fielding wrote a dissertation on Representational State Transfer (REST) which was a software architecture style consisting of guidelines and best practices for creating scalable web services based on HTTP verbs. REST eventually won out over SOAP and XML during the 2000s due widespread, grass-roots efforts. David beat Goliath. Remember the lesson of standards bodies vs. grass-roots endeavors the next time you’re paralyzed waiting for standards to come along before innovating with new technologies. You might miss an entire technology wave.

The simpler, lighter-weight nature of REST makes it a superior choice over the bloated SOAP wire protocol for your mobile communications needs. Those LTE wireless data networks sometimes crawl along like GPRS and your employees will be glad you used something lighter.

A variety of server technologies allow you to create web APIs based on RESTful principles. Via server API code, you’ll write the same dynamic SQL queries or stored procedure calls that are currently in use with your existing client/server systems. This code will return data formatted as JSON that is consumable by any mobile app or browser. This mobile and firewall friendly way of moving data between devices and databases can also take advantage of server-side caching to further boost performance and scalability.

Reduce risk to your business by removing dependencies on unsupported, proprietary technologies and improve user productivity by implementing a distributed technology that works anywhere with any device. What is your organization doing to empower every employee with business API connectivity?

Learn how to digitally transform your company in my newest book, “Mobile Strategies for Business: 50 Actionable Insights to Digitally Transform your Business.”

Book Cover

Click to purchase a copy of my book today and start transforming your business!

Sharing my knowledge and helping others never stops, so connect with me on my blog at http://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany

Improve Productivity by Publishing Services to Mobile Employees via a Web Gateway

Salt Lake City

Rather than extending your entire network out to mobile devices via VPN, publish individual services through a web gateway or the cloud.

Most remote employees gain access to Intranet resources through a virtual private network (VPN). Using 3rd party or built-in software, employees provide credentials and sometimes a smartcard to create a VPN tunnel. Once created, employees can securely exchange data with internal resources. This is anything but seamless and employees find setting up VPN sessions and re-authenticating due to dropped connections to be a hassle. They want to access things the same way they do on the Internet.

Let’s take a look at a better mobile reality. Most companies around the world use Microsoft Exchange for corporate email. For more than a decade, mobile users on virtually every platform have been able to securely sync their email without first creating a cumbersome VPN connection. This was possible because Exchange publishes its Active Sync service through a reverse-proxy over TLS. The email app is responsible for passing credentials to the server. It works the way mobile employees expect all their mobile apps to work.

You can do this too by publishing your internal web sites and REST + JSON APIs on port 443 through a reverse proxy that lives at the network edge. Reverse proxies are appliances or server software that let you create a multi-channel access gateway. Of course, when you move your workloads to the cloud, none of this will be needed anymore.

Improve user productivity by eliminating the need to create cumbersome VPN connections to achieve secure connections. What remote access technology changes are you making at your organization to make life easier for your employees?

Learn how to digitally transform your company in my newest book, “Mobile Strategies for Business: 50 Actionable Insights to Digitally Transform your Business.”

Book Cover

Click to purchase a copy of my book today and start transforming your business!

Sharing my knowledge and helping others never stops, so connect with me on my blog at http://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany

Reduce Corporate Expenses by Mobile-Enabling Existing Business Systems with REST APIs

Portland

Mobile-enable backend business systems by wrapping them with REST APIs that speak the same language as any device, browser or app.

Most backend business systems organizations have deployed over the last several decades have absolutely nothing common. They all speak different languages via myriad binary and text wire protocols. They typically don’t talk to each other and they don’t talk mobile.

This is a big problem in today’s mobile-first world because CIOs expect data from any of their backend systems to be delivered to any device, thus empowering their employees.

Companies are faced with difficult choices ranging from replacing the old systems with new, mobile-friendly ones, rewriting custom systems, upgrading to newer versions if they exist, or moving workloads to the cloud. Many companies are unable to make any of these choices for the same reason they haven’t upgraded their Windows apps from the 90s. Limited budgets.

A lower-cost alternative is to leave these working systems in place but create a RESTful API wrapper around them. You basically encircle these systems with commodity servers or cloud gateways that map proprietary APIs to mobile-friendly APIs. This mapping can be accomplished via code or through connectors or adapters. Now all your existing systems will be able to communicate bi-directionally with any mobile device and more easily interface with customers and business partners. Think of this as mobile SOA.

Reduce business expenses by extending existing workloads to mobile devices rather than replacing those workloads with new solutions. What is your company doing to empower every employee with any device?

Learn how to digitally transform your company in my newest book, “Mobile Strategies for Business: 50 Actionable Insights to Digitally Transform your Business.”

 

Book Cover

Click to purchase a copy of my book today and start transforming your business!

Sharing my knowledge and helping others never stops, so connect with me on my blog at http://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany

Reduce Business Risk by Utilizing Open Mobile Internet Standards

San Jose

The mobile Internet communicates with HTTP(S), follows an architectural style called REST, serializes data as JSON & compresses with GZip and Deflate.

These different standards weren’t mashed together by a working group. They represent a grass-roots phenomenon that transformed how the Internet communicates.

Data traverses the globe through routers and firewalls via the Hypertext Transfer Protocol HTTP(S). While standards bodies worked for years to create the simple object access protocol (SOAP), the representational state transfer protocol (REST) emerged from a Phd dissertation. REST used the basic verbs of HTTP including GET, POST, PUT and DELETE, to pass messages and call remote procedures across heterogeneous systems.

You probably remember the XML craze in the late 90s and early 2000s. This way of formatting data was self-describing and worked with any system. Unfortunately, it was quite verbose and therefore not as efficient across slower, wireless data networks. Luckily, the slimmed-down JavaScript Object Notation (JSON) data format came along and gave us a better and smaller way to serialize data. To further shrink data traversing the Internet, GZip and Deflate represent universal ways to compress everything. HTTP/2 is a game-changer with improved speed and multiplexing. Protocols like OData are based on REST/JSON and are found in many recent technology platforms. You should care about this stuff because it works with any browser, device or server.

Reduce risk to your business by betting on open standards to support all devices rather than taking dependencies on proprietary technologies you don’t control. What is your organization doing to eliminate vendor lock-in by moving from closed to open standards?

Learn how to digitally transform your company in my newest book, “Mobile Strategies for Business: 50 Actionable Insights to Digitally Transform your Business.”

Book Cover

Click to purchase a copy of my book today and start transforming your business!

Sharing my knowledge and helping others never stops, so connect with me on my blog at http://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany

Wrap a Web API around Your Enterprise & Take Microsoft SQL Server 2014 Data Offline w/ NoSQL via Universal Apps for Windows

Windows NoSQL

At TechEd New Zealand, I presented a session on how to integrate a company’s backend systems into SQL Server 2014 and deliver that data out to mobile devices via Web APIs to support the operations of occasionally-connected apps on mobile devices using NoSQL tables.

Enterprise mobility is a top priority for Chief Information Officers who must empower employees and reach customers by moving data from backend systems out to apps on mobile devices.  This data must flow over inefficient wireless data networks, be consumable by any mobile device, and scale to support millions of users while delivering exceptional performance.  Since wireless coverage is inconsistent, apps must store this data offline so users can be productive in the absence of connectivity.

In this video, I’ll teach you how mashup disparate backend systems into high-speed, SQL Server 2014 in-memory staging tables.  I boost the speed even further through the use of natively-compiled stored procedures and then link them to fast and scalable REST + JSON APIs using the ASP.NET Web API while employing techniques such as in-memory caching.  On the device, I’ll show you how your apps can work with offline data via in-memory NoSQL tables that use LINQ to support the same CRUD operations as relational databases.  You’ll walk away from this session with the ability to deliver flexible server solutions that work on-premises or in Azure and device solutions that work with Windows Phones, Tablets or Laptops.

Sharing my knowledge and helping others never stops, so connect with me on my blog at http://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany

//build/ : Wrap a Mobile API around your Enterprise and take Data Offline with NoSQL on Windows Phones and Tablets

BuildSession

For those of you who couldn’t make it to San Francisco, here’s my session on Wrapping a Mobile API around your Enterprise and taking Data Offline with NoSQL on Windows Phones and Tablets from //build/.

Enterprise mobility is a top priority for Chief Information Officers who must empower employees and reach customers by moving data from backend systems out to apps on mobile devices. This data must flow over inefficient wireless data networks, be consumable by any mobile device, and scale to support millions of users while delivering exceptional performance. Since wireless coverage is inconsistent, apps must store this data offline so users can be productive in the absence of connectivity.

In this video you’ll learn how to build fast and scalable REST + JSON APIs using the ASP.NET Web API while employing techniques such as data sharding and in-memory caching. On the device, you’ll learn how your apps can work with offline data via in-memory NoSQL tables that use LINQ to support the same CRUD operations as relational databases. You’ll walk away from this session with the ability to deliver flexible server solutions that work on-premise or in Azure and device solutions that work with Windows Phones and Tablets.

Download the two Visual Studio projects and associated source code from GitHub:
https://github.com/robtiffany/build-2014-mobile-api

Sharing my knowledge and helping others never stops, so connect with me on my blog at http://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany

Happy Mobile New Year

iPaq

It’s a new year and therefore it’s time to throw some rapid-fire mobile architecture concepts at you to help improve your mobile enterprise systems.

 

  • For starters, developers and IT Pros involved in mobility need to start thinking holistically about backend systems, data transports, and mobile endpoints.  Working in the mobile enterprise space doesn’t mean you just get to be a “device guy.”  Remember, your CIO wants to empower her employees by moving data from any backend system out to any device.
  • Here’s my obligatory statement on keeping things simple.  Large enterprise mobile systems will get complicated enough on their own without you contributing to the chaos.
  • Take the idea of Mobile SOA seriously and wrap your enterprise in a Web API.  Your various backend ERP, CRM, and custom systems use a variety of proprietary wire protocols to communicate.  You need to make all those backend systems “mobile friendly” by having them all speak a device-agnostic language.  You all know I’ve been a REST guy for more than a decade so it’s no surprise that I want you to map those proprietary APIs to RESTful APIs.  REST is lighter then SOAP and works with all mobile devices.  For your coarse-grained APIs that send larger payloads of information, make sure to serialize that data as JSON.  JSON is lighter than XML and works with all mobile devices.  The other litmus test here is around simplicity.  If a webpage with JavaScript can consume your REST/JSON API without needing an SDK to interpret your wire-protocol, then native apps will find your API simpler to work with than a system that requires an SDK.  Remember, you’re not just building this API for mobile devices.  You’re building it for developers.  If it’s not super-simple to work with, they may not use it.
  • Some backend systems that you’re building Web APIs for are designed for serious web-scale, but most are not.  If a particular backend package already has the performance and scalability to handle millions of devices, then have your middleware Web API servers sit directly in front of them and map REST API calls directly to their proprietary APIs.  For the the majority of backend systems that are wholly incapable  of handling an onslaught of millions of devices, you need to give them some help.  You’ll need to create a server facade in front of them via a database server that includes EAI adapter capabilities along with the ability to scale out via replication.  You’ll use an adapter designed specifically to interface with the backend system in question to prefetch data from the proprietary APIs and put that data in staging tables in the database.  You’ll then shard this database via replication to scale either complete databases, tables, or parts of tables to n number of “shared-nothing” database nodes on different servers.  In this scenario, your middleware Web API servers will make calls to the various database shards to return cached data to mobile devices in order to solve your scalability problem for backend systems that need help in this department.
  • Common sense tells us that if you make your backend systems faster, then the user experience on the mobile devices will improve because users won’t be waiting around for data to arrive to fill their screen.  The first and easiest thing I want you to do is switch all your spinning hard drives to solid state drives (SSDs).  Moving all your backend systems, database servers, middleware servers, and web servers to lightning-fast SSDs will instantly boost the performance of your entire system without writing or changing a line of code.  This is a no-brainer.  The next thing I want you to do is take better advantage of cheap RAM and in-memory operations.  I want every mapped API call between your middleware Web API servers and backend systems to be cached in-memory.  If you’re using a server facade in front of backend systems, ensure the EAI/ETL capabilities of the database support in-memory data movement operations.  Likewise, I want you to use database servers that support in-memory OLTP.  All the Web API calls between your mobile devices and the middleware servers also need to be cached in-memory as well.  Last but not least, the native and web apps on your mobile devices need to cache data offline in a local data store so that users can keep working without needing to constantly call your Web APIs.
  • Implement a lightweight Enterprise Mobility Management (EMM) system in your organization.  It needs to provide things like an enterprise app store, security policy enforcement, and things to make an employee’s life easier like the simple provisioning of Wi-Fi, VPN, and email profiles.  In order for mobile apps to access the Web API you’ve built, your EMM should also support a secure gateway to access internal corporate servers via single sign-on (SSO).
  • Finally, keep investigating HTML5.  It’s the world’s most important shared technology that isn’t owned by any one company.  It works with the browsers on every mobile device and makes things like app deployment and updating easier than equivalent processes with native apps.  It supports offline operations and even includes two options of local data storage.  Web pages no longer submit/post data to themselves or other pages but use JavaScript instead.  Mobile web apps can make AJAX calls to you Web API and easily work with the JSON data that’s returned.  Mobile browsers keep getting faster and use optimizations like hardware acceleration and JIT-compiling of JavaScript to blur the lines with native apps.

Happy New Year!
Rob

Sharing my knowledge and helping others never stops, so connect with me on my blog at http://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany

Sign Up for my Newsletter and get a FREE Chapter of “Mobile Strategies for Business!”

[mc4wp_form id=”5975″]

ASP.NET Web API: The New Mobile Web Services

aspnet

Those of you who know me or have attended one of my presentations know that I’m a total RESTafarian when it comes to the software architectural style I prefer for web services.

I started using REST in the early 2000s to create a high-speed, human-readable, server API to trade financial instruments between brokerages and counterparties. When SOAP finally got traction in the .NET and Java world, I started using it because WSDL and widespread tooling made it easy for people to consume the web services I had to publish. XML was having its moment in the sun. That being said, I could never get past the clear drop in performance I saw vs. the lighter-weight RESTful way of doing things.

Fast forward to to the cross-browser standardization of Ajax in JavaScript, and RESTful web services started to surge since SOAP was way too heavy for client-side web page calls. Along the way, a compact way of describing objects and collections of objects called JSON began to steal XML’s thunder as a way to serialize data. While this new REST + JSON pattern of lightweight communication and data serialization got it’s start with the web and JavaScript, it soon found a home in the surging tidal wave of devices that have proliferated over the last decade.

The slow, unreliable wireless data networks that brought Smartphones to life demanded a new level of efficiency when it came to wire protocols. While proprietary, binary protocols ruled in the early days, they finally gave way to something that could work with any device. At Microsoft, we began to make it easier for developers to create REST web services via our Windows Communication Foundation (WCF) and special toolkits in .NET 3.5 and 4.0.  I started using it because of the obvious benefits to wireless-efficiency and also so I could stop having to “roll my own” REST web services using bits and pieces of other technologies.  WCF is a Swiss Army Knife and does lots of things which sometimes makes it overkill when you need to expose simple function calls or data to the Internet via REST.

I’m thrilled to say that our newest, simplest way to create RESTful web services is called the ASP.NET Web API.  Using the power of ASP.NET MVC 4, we’ve delivered a framework that makes it easy to build HTTP services that reach a wide range of clients, including web browsers and most every Smartphone.  I’m using it now to expose enterprise data out to the Internet where it can be easily consumed as collections of JSON objects.  Mobile web browsers can retrieve this data via Ajax calls and store it offline in Web Storage.  Smartphone apps can download and store the data in local databases or serialize it to flash storage as JSON.  I like it!

Take it for a spin.

-Rob

Sharing my knowledge and helping others never stops, so connect with me on my blog at http://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany

Sign Up for my Newsletter and get a FREE Chapter of “Mobile Strategies for Business!”

[mc4wp_form id=”5975″]

Sync Framework v4 is now Open Source, and ready to Connect any Device to SQL Server and SQL Azure

Sync

Microsoft has brought the power to synchronize data with either SQL Server on-premise or SQL Azure in the cloud to the world of mobility.

The profound effects of the Consumerization of IT (CoIT) is blurring the lines between consumers and the enterprise.  The fact that virtually every type of mobile device is now a candidate to make employees productive means that cross-platform, enabling technologies are a must. If you’ve ever synched the music on your iPhone with iTunes, the calendar on your Android device with Gmail, or the Outlook email on your Windows Phone with Exchange, then you understand the importance of sync.  In my experience architecting and building enterprise mobile apps for the world’s largest organizations over the last decade, data sync has always been a critical ingredient.

The new Sync Framework Toolkit found on MSDN builds on the existing Sync Framework 2.1’s ability to create disconnected applications, making it easier to expose data for synchronization to apps running on any client platform.  Where Sync Framework 2.1 required clients to be based on Windows, this free toolkit allows other Microsoft platforms to be used for offline clients such as Silverlight, Windows Phone 7, Windows Mobile, Windows Embedded Handheld, and new Windows Slates.   Additionally, non-Microsoft platforms such as iPhones, iPads, Android phones and tablets, Blackberries and browsers supporting HTML5 are all first-class sync citizens.  The secret is that we no longer require the installation of the Sync Framework runtime on client devices.  When coupled with use of an open protocol like OData for data transport, no platform or programming language is prevented from synchronizing data with our on-premise and cloud databases.  When the data arrives on your device, you can serialize it as JSON, or insert it into SQL Server Compact or SQLite depending on your platform preferences.

The Sync Framework Toolkit provides all the features enabled by theSync Framework 4.0 October 2010 CTP.  We are releasing the toolkit as source code samples on MSDN with the source code utilizing Sync Framework 2.1.  Source code provides the flexibility to customize or extend the capabilities we have provided to suit your specific requirements. The client-side source code in the package is released under the Apache 2.0 license and the server-side source code under the MS-LPL license.  The Sync Framework 2.1 is fully supported by Microsoft and the mobile-enabling source code is yours to use, build upon, and support for the apps you create.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Now some of you might be wondering why you would use a sync technology to move data rather than SOAP or REST web services.  The reason has to do with performance and bandwidth efficiency.  Using SOA, one would retrieve all the data needed to the device in order to see what has changed in SQL Server.  The same goes for uploading data.  Using the Sync Framework Toolkit, only the changes, or deltas, are transmitted over the air.  The boosts performance and reduces bandwidth usage which saves time and money in a world of congested mobile data networks with capped mobile data plans.  You also get a feature called batching, which breaks up the data sent over wireless networks into manageable pieces.  This not only prevents you from blowing out your limited bandwidth, but it also keeps you from using too much RAM memory both on the server and your memory-constrained mobile device.  When combined with conflict resolution and advanced filtering, I’m sold!

I think you’ll find the Sync Framework Toolkit to be an immensely valuable component of your MEAP solutions for the enterprise as well as the ones you build for consumers.

Keep Synching,

-Rob

Sharing my knowledge and helping others never stops, so connect with me on my blog at http://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany

Sign Up for my Newsletter and get a FREE Chapter of “Mobile Strategies for Business!”

[mc4wp_form id=”5975″]

Consumerization of IT Collides with MEAP: Windows > Cloud

In my Consumerization of IT Collides with MEAP article last week, I described how to connect a Windows 7 device to Microsoft’s On-Premises servers.

Whether you’re talking about a Windows 7 tablet or laptop, I showed that you can follow the Garter MEAP Critical Capabilities to integrate with our stack in a consistent manner.  Remember, the ability to support multiple mobile apps across multiple mobile platforms, using the same software stack is a key tenant to MEAP.  It’s all about avoiding point solutions.

If you need a refresher on the Gartner MEAP Critical Capabilities, check out: http://robtiffany.com/meap/consumerization-of-it-collides-with-meap-windows-on-premises

In this week’s scenario, I’ll use the picture below to illustrate how Mobile versions of Windows 7 in the form of slates, laptops, and tablets utilize some or all of Gartner’s Critical Capabilities to connect to Microsoft’s Cloud infrastructure:

image

As you can see from the picture above:

  1. For the Management Tools Critical Capability, Windows 7 uses Windows Intune for Cloud-based device management and software distribution.
  2. For both the Client and Server Integrated Development Environment (IDE) and Multichannel Tool Critical Capability, Windows 7 uses Visual Studio. The Windows Azure SDK plugs into Visual Studio and provides developers with everything they need to build Cloud applications.  It even includes a Cloud emulator to simulate all aspects of Windows Azure on their development computer.
  3. For the cross-platform Application Client Runtime Critical Capability, Windows 7 uses .NET (Silverlight/WPF/WinForms) for thick clients. For thin clients, it uses Internet Explorer 9 to provide HTML5 + CSS3 + ECMAScript5 capabilities. Offline storage is important to keep potentially disconnected mobile clients working and this is facilitated by SQL Server Compact + Isolated Storage for thick clients and Web Storage for thin clients.
  4. For the Security Critical Capability, Windows 7 provides security for data at rest via Bitlocker, data in transit via SSL, & Authorization/Authentication via the Windows Azure AppFabric Access Control Serivce (ACS).
  5. For the Enterprise Application Integration Tools Critical Capability, Windows 7 can reach out to servers directly via Web Services or indirectly through the Cloud via the Windows Azure AppFabric Service Bus to connect to other enterprise packages.
  6. The Multichannel Server Critical Capability to support any open protocol is handled automatically by Windows Azure. Crosss-Platform wire protocols riding on top of HTTP are exposed by Windows Communication Foundation (WCF) and include SOAP, REST and Atompub. Cross-Platform data serialization is also provided by WCF including XML, JSON, and OData. Cross-Platform data synchronization if provided by the Sync Framework. These Multichannel capabilities support thick clients making web service calls as well as thin web clients making Ajax calls. Distributed caching to dramatically boost the performance of any client is provided by Windows Azure AppFabric Caching.
  7. As you might imagine, the Hosting Critical Capability is knocked out of the park with Windows Azure.  Beyond providing the most complete solution of any Cloud provider, Windows Azure Connect provides an IPSec-protected connection with your On-Premises network and SQL Azure Data Sync can be used to move data between SQL Server and SQL Azure.  This gives you the Hybrid Cloud solution you might be looking for.
  8. For the Packaged Mobile Apps or Components Critical Capability, Windows 7 runs cross-platform mobile apps include Office/Lync/IE/Outlook/Bing.

As you can see from this and last week’s article, Windows 7 meets all of Gartner’s Critical Capabilities whether it’s connecting to Microsoft’s On-Premises or Cloud servers and infrastructure.  They great takeaway from the picture above, is Windows 7 only needs to know how to integrate its apps with WCF in the exact same way as is does in the On-Premises scenario.  Windows developers can focus on Windows without having to concern themselves with the various options provided by Windows Azure.  Cloud developers just need to provide a WCF interface to the mobile clients.

When an employee walks in the door with a wireless Windows 7 Slate device, you can rest assured that you can make them productive via Windows Azure without sacrificing any of the Gartner Critical Capabilities.

Next week, I’ll cover how Windows Phone connects to an On-Premises Microsoft infrastructure.

Rob

Sharing my knowledge and helping others never stops, so connect with me on my blog at http://robtiffany.com , follow me on Twitter at https://twitter.com/RobTiffany and on LinkedIn at https://www.linkedin.com/in/robtiffany

Sign Up for my Newsletter and get a FREE Chapter of “Mobile Strategies for Business!”

[mc4wp_form id=”5975″]