Microsoft Pickets Salesforce.com at Cloudforce

It made me think!   Why is Microsoft picketing salesforce.com.  Could it be that they don’t like what the cloud is doing to their business?  Could it be that cloud computing will demolish IT as we know it?   Could it be that Microsoft has figured out that they are a dinosaur?   Hmmm…

Today millions of people and an entire ecosystem of companies selling billions of dollars worth of goods are involved in an activity that history will paint as the rough equivalent to “sticking a needle in your eye.”  

 Picture this:

• You allocate a significant percentage of your people and dollars and have them work on things that are out of your core competency
• Once you have done that, start buying parts that you have to put together, operate, and be totally responsible for
• And for the cherry on the top – you will have to pay the companies that sold you the bag of parts just to pick up the phone when you call

Sound like a good deal?

No way! Yet, I would say that is a fair description of the global IT market as it is today – and it’s painful!      

Benefit can be derived, but high costs, risks, and distractions to your core business are CRAZY OUT OF CONTROL!

The way I look at it, IT in its current incarnation is going the way of the dodo bird.   The global pervasive network called the Internet allows us to consume our IT in a better way – hosted and operated in the cloud by companies who make it their business to do it well.  And the best part, if you don’t like it, you change.   No bag of parts, no big capital expenditures to hold on to, no regrets.  You can even call them without having to pay something extra.   It’s all good.

Over the next 10 years – the “old” tech companies will either completely reinvent themselves or perish!   This is their buggy whip-to-automobile moment.   Cloud is it – it’s cheaper, better, and easier.   

So to Microsoft – I am sorry – we will not go back to the old ways.   We have seen the light – and its name is CLOUD!

Let's put it on the table - disconnected products are lame! THEY ARE A PAIN!

They require me to do the heavy lifting. I have to understand their every need, to learn arcane ways to interact with them, and heaven forbid if they have a flaw - I will have to live with it until the end of time.  A prime example: my high-end HD TV that chooses to lose its noodle every time the game get's close! How does it know?

Disconnected products are all little islands - they barely interact with me and hardly ever with each other. I want to corral them, to organize them, to turn them into an army that works with relentless efficiency, doing the things that I want them to do - when I want them to do them...I WANT MY PRODUCTS TO BE CONNECTED!

To be fair, today's products do amazing things, but the avalanche of complexity has caused a great disconnect between the user and the maker of the product. Users want a better product experience. Makers want to differentiate themselves from their competition and sell more product. So, where do we meet?

We meet in the cloud! I want to utilize the infinite possibilities of the cloud to teach my products new tricks! To teach them my likes and dislikes... to get them to play well with others... to evolve...

Instead of putting more complexity into my product - into a platform that can't handle and organize it - utilize connectivity to leverage capability in the cloud and give me the reigns! And here is the amazing thing: I, the consumer, will actually pay for you to give me the reigns! If it creates value, makes my product better, makes it more useful, solves problems for me, I will gladly pay. The iPhone is a perfect example of this. Today, this platform has more than 200,000 applications and has sold more than 1 billion devices. It has changed the game.

Your product, too, can become a cloud-based platform. Medical devices? Yes. Industrial machines? Yes. Consumer products? Definitely yes.  Join me on my crusade. Let's rid the world of lame disconnected products! Connect them today! http://developer.axeda.com.

Dale

There's a new Forrester report out about the next cycle of innovation, which Forrester dubs "Smart Computing". In the abstract of the report, I keyed in on an interesting statement:
 
the problems faced by business have very strong vertical industry dimensions, leading to much greater demand for highly verticalized IT solutions... Horizontal technologies -- which today represent about 95% of all technology purchases -- will continue to dominate the technology market... but vertical technology solutions will expand their market share to 25% or so by 2016.

Platform pedantry aside, it follows from the above statement that "smart computing" (which is probably best interpreted as a superset of M2M, ubiquitous computing, sentient computing, and next-generation Enterprise Integration), will need a horizontally applicable set of foundational technology that can be used to build vertical applications that are crafted to solve a domain problem.

We can expect to see an avalanche of generic and mediocre (generically mediocre?) track-and-trace and asset management apps to try to fill this expanding space. They will be horizontal, meaning that the vendors will try to sell it to you whether you are monitoring wind turbine output or your rental car customers. This is fine if you just want to get the lowest common denominator, generic experience. If you are looking to build an innovative, game-changing solution in your industry, you need a platform that offers a technology stack that is flexible enough to let you focus on your solution's unique value, while launching your development progress forward past the details of connectivity, workflow processing, scalability and security.

The enterprise software community is waking up to the importance of realtime data access, APIs and Web-Oriented Architectures.

2010 should be an exciting year for Axeda.

It's been written about before, but it bears repeating: it seems that suddenly every computing product calls itself a platform. In the early days of computing we made programs (when was the last time you met someone that called themselves a programmer?), then at some point that didn't sound good enough, so they became systems, but that started to imply green-screen terminals, so the new object oriented kidz started calling stuff frameworks. More recently, the SOA crowd got us calling stuff services. Now platform has become the term du jour, with everyone from chip makers to graphics designers jumping on the bandwagon.

That's the way it goes, I suppose. It's really hard to summarize in a sound-byte definition, but I'll make a stab:

Platform-as-a-Service (PaaS) is an offering that provides solution developers the necessary services to implement solid applications, where the application execution environment, development and testing tools, administration and configuration, and runtime monitoring are provisioned in the cloud.

Here are some corollaries to that definition:

A PaaS should:

• enable rapid time-to-market for solutions
• massively scale
• provide high availability and fault tolerance
• provide a standard security model
• abstract the physical infrastructure completely from the application
• provide standard services that are tailored to the general domain (i.e. a PaaS for remote asset intelligence should provide strong support for Assets and Communications as first-class concepts)
• provide an integrated model for the application lifecycle: develop, test, deploy, maintain, end-of-life
• have a comprehensive and open API that is consumable by the widest possible set of technologies

That's a really, really high bar. To me, calling something a platform implies an absolute commitment to addressing the above list. That's what it takes to walk the walk.

 

Last week I attended the Cloud³ conference by Xconomy Boston. It was a great opportunity to listen to various perspectives on cloud computing, including SaaS, PaaS, and IaaS.

Listened to Akamai, EMC, Microsoft (Azure), Iron Mountain, and a few other New England area startups. The most interesting part, for me, was the freeform discussion between a panel and the audience.

To summarize, here were my key takeaways

• Virtualization of computing resources: applications, platforms, middleware, and hardware - will be a juggernaut IT theme for 2010.
• SaaS and IaaS has wide applicability for IT in general.
• Major concerns are, in order: Security of data, availability, performance, compliance. All of those concerns, however, exist no matter where resources are hosted.
• Why trust Amazon to secure your app? Because they are better at it than you
• Why trust SaaS and PaaS offerings to offer high availability, scalability, and security: because deep understanding of the domain and focus on operations makes those vendors the best in the world at hosting their solution.
• The concept of SaaS is well established and no longer a point of debate. I was surprised that there was not more discussion about the economics of SaaS, particularly CMRR and CAC.
• Some discussion around CAPEX for startups - entrepreneurs want low up-front expense and rapid time to market - PaaS brings both of those.
• Concern around vendor lock-in, how to get data out of a system - "Data has gravity".
• Consensus that PaaS is all about APIs and application execution environment, not virtualized hardware.
• Some discussion about whether a startup's choice of cloud vendor could affect their M&A. (would Google want you if you were on MS Azure?).
• Compliance: Microsoft says, "lets just make the agencies that legislate compliance lean about cloud and change their policy".
• The real savings when you move to cloud is on staff.

Also very interesting was the use of Twitter as a "dark channel" during the presentations. The attendee Tweets were sometimes more interesting than the speakers! Check them out here.

The ZeitGeist is that cloud computing is the beginning of a fundamental shift in approaching computing resources, and while it may be true that some aspects are not wholly new (SaaS is a lot like the ASPs of the late 90's), the collective mass of SaaS, PaaS, and IaaS changes the economics of applications, what applications are, and how collaborating business partners and consumers take advantage of each other's services.

Exciting times.

These are the people who have lived through the process you are entering.  Learn from their experiences. 

You wouldn't hire a new employee without checking their references, would you?  It seems obvious that you would take the same time and care when selecting a strategic business changing technology such as a remote service system.  The only real question is who you should talk to and what you should ask!

A reference should be someone who has already walked the path ahead of you.  They have a system, it has devices deployed in the field, and it is actively in use. The purpose of the reference call is to evaluate the vendor, but don't be afraid to see what lessons you can learn along the way.  Ask for references from the vendor, but also take advantage of various M2M or remote service shows.  These are often great opportunities to meet and speak with many companies in a very short period of time.

Vendor performance for enterprise software comes down to three key elements:

1. Does the product do what it is advertised to do?
2. Was the implementation process performed competently, on time, and on budget?
3. Does the ongoing support provide timely answers and fixes (if needed)?

Product
If there are specific functions that are critical to the success of your project, ask for references that use those features. The real world may reveal unexpected constraints or benefits that were not obvious during your evaluation.

Implementation
Getting a good read on the implementation process is probably the most difficult aspect of reference checking. Success is often as much a function of the ability of a project team to negotiate internal politics as it is of the vendor's people or methodology! For example, during a panel discussion at an Axeda user conference, four of our most successful customers all agreed that executive commitment to the project was their biggest key to success.

In my experience, all that work you did during the evaluation phase can really pay off during implementation.  If you have done your use cases, involved your stakeholders, and purchased a product that can meet the key requirements, the implementation will be straightforward and with low risk.  Ask your reference contacts how they interacted with the vendor's implementation team and what lessons they learned.

Support
Measuring ongoing support is a challenge.  Support cases are often managed under a period of duress and imperfect information.  Were questions understood?  How long did it usually take to diagnose the problem? Are the support tools sufficient and easy to use? If a software change was needed, how long did it take? With the increasing use of social networking tools, does the vendor have an active community of users who are willing to share their experience?

Most of all, ask if your reference feels they are dealing with a vendor or a partner. In a partnership, both sides work together for the mutual benefit. Axeda management stresses partnership and customer success as an integral component of our corporate culture. Sure, we don't do everything perfectly every time, but we never forget our mission of customer satisfaction. That's one reason I'm not afraid to write a blog about asking for customer references!

To help keep customer success on top of every employee's mind, Axeda regularly asks our customer's one simple question, "How likely is it that you would recommend Axeda to a friend or colleague?" 

When you do your reference calls, you are invited to ask the same question.

Read the related articles for Randy's 10-Step Series:
10 Steps to a Successful Remote Service Evaluation
Step 1. Successful Remote Service Evaluations - Have a Vision of What Success Looks Like
Step 2. Successful Remote Service Evaluations - Work with Cross Functional Teams
Step 3. Successful Remote Service Evaluations - Answer What's in it For Your Customers! 
Step 4. Successful Remote Service Evaluations - Agree on a Scoring Matrix and an Evaluation Process
Step 5. Successful Remote Service Evaluations - Security Matters
Step 6. Successful Remote Service Evaluations - Scalability is More Than Just Multiplication
Step 7. Successful Remote Service Evaluations - Usability is the Key to User Acceptance
Step 8. Successful Remote Service Evaluations - Focus on Total Cost of Ownership
Step 9. Successful Remote Service Evaluations - Reality + Experience = Change

 

The current makeup of data sources for the digital universe is primarily created by humans. IDC estimates that in 2008, individuals created ~70% of the information in the digital universe, comprising phone calls, emails, photos, online banking transactions, and postings on social networking sites, including Twitter.

What happens when everything connects?

In 2005, the International Telecommunication Union issued a research report called "The Internet of Things." The article addresses the next step in "always-on" communications, in which new technologies like smart computing promise a world of networked and interconnected devices. As a result, a new era will be created, one in which today's Internet gives way to tomorrow's Internet of Things.

IDC forecasts that the size of the digital universe will double in size every 18 months for the next five years. The primary driver behind this explosion in the digital universe is -- you guessed it -- The Internet of Things!

 

According to IDC:

"The growth of the numbers and types of devices that aren't the traditional enterprise PCs, servers, storage systems, and network equipment, will drive changes in network and data center architecture and management. Where today, most corporate computing traffic on networks is from the server to client, more and more devices reporting in from the network edge will be reversing that trend. They will also be sending in much more diverse signal voice packets, minutes of video surveillance, and sensor signals that need to be dealt with immediately. All, of course, need security, management, and storage, at least for a period of time."

The Diverse and Exploding Digital Universe, IDC 2009

Birth of the M2M platform market

We are living on the bleeding edge of a new generation of the digital universe that will consist mainly of data passed from machine-to-machine. What has emerged from this explosive growth is the demand for ways to manage, store, and secure this new type of information -- enter the M2M platform.

What makes a true M2M platform different from a standard middleware platform is its ability to handle all types of non-standard and specialized information from any device and any connection. The value of the platform also comes from the ability to transform complex data into an object model that can then have processing, rules, and security applied to it. For small amounts of data, this may seem like a possible do-it-yourself task, but looking at the overall scale may make you consider outside assistance. Axeda has been doing this for years now and we'd like the opportunity to talk to you about how you can capitalize on the Internet of Things Economy.

For more information on the essential elements of an M2M platform, see our:

• Axeda SmartLink Platform White Paper 
• Axeda SmartLink Platform Overview Video

Groovy Joints, Man

Business applications go together like bones on a skeleton. Where they meet, we have joints. Any athlete knows that joint flexibility is important, just as any business systems integrator knows that the coupling-points - where the business systems "joint" together - needs to be as flexible as possible to embrace future change.
Today, you have your products connected to Axeda ServiceLink, and you're enjoying the remote connectivity, active alerting, and data monitoring features.

Now what you would really like is to let that intelligence interact with your CRM, repair authorization, customer provisioning databases, or other enterprise systems.

Groovy

Enter Axeda Custom Objects, powered by the Groovy scripting language. Axeda Custom Objects are the joints between Axeda ServiceLink and external systems. This feature allows you to author scripts that push, pull, and reformat information between Axeda and others.

It may be making a REST-based Web call into an entitlement system to determine if a serial number has its warranty paid up. Maybe your service techs will take different action when responding, or not.. .but they'll know. It may be making a SOAP Web Service call to open a ticket in your CRM/ ticketing system. It may be communicating to an expert system to ask if the latest reading for a sensor means an imminent failure. Or maybe it's training such a system. It may be giving your vendor systems a heads up that you need more widgets, based on the usage information that you are receiving from Axeda ServiceLink.

Creaky Joints

To achieve custom behavior, such as integration with enterprise systems or custom algorithms, one would previously have written Java code compiled against our SDK jars, manipulated system configuration files to load the customization, and then iterated this process to test and debug the customization. Later migrations to a new version of Axeda ServiceLink would require careful porting of this customization, and another test/debug cycle.

With scripting with Axeda Custom Objects, the dev-deploy-test,-debug cycles are greatly reduced, and migration efforts can be as simple as smoke-testing the scripts after the system upgrade.

Limber Up

Here's where the human-anatomy-analogy breaks down. Changing a joint between two business systems should not be like replacing your hip. With Axeda Custom Objects (powered by Groovy) and the Axeda SDK, healthy, strong joints are just a few clicks away.

 "We measure our reality according to our experience. As our experience expands, our reality is also altered." - Chin-Ning Chu, business author and management expert

I ran across this quote and thought it perfectly summarized the life of a remote service program. All programs begin with a goal. That goal leads to a set of requirements or constraints that define the solution. Once the solution is deployed, the process of experience begins. Only then do you begin to learn what you didn't know that you didn't know.

We see this often at Axeda as we work with new customers.  A set of 10, 30, or 100 data values are determined to be important sources of diagnostic information or business value. As the support engineers work with the data provided, they begin to learn new things about how the connected assets operate in the real world.  It may be alarm conditions that occur more (less) frequently than expected, a particular variable that doesn't correlate to a problem cause, or some variable that is useful but not recorded frequently enough.

At the same time, the support engineers find that there are problems for which the existing variable sets are not helpful or definitive enough. The problem may be detected, but you can't tell which subsystem is actually the root cause and thus what parts may be needed to affect the repair. This leads to a wish list of desired variables.  In many cases, the team looks at the list, does a virtual slap on the head, and says, "I can't believe we didn't think of that one!"

What next? Everyone looks at the leader of the remote support program and asks the obvious question, "Can you drop these variables that we don't need and replace them with the ones that we do need?"

This is one example where you need the ability to not only change the Agent functionality, but also to cost effectively deploy those changes into the field. The remote service program should not create the need to dispatch technicians just to solve problems with the system that was supposed to reduce dispatches!

The solution requires intelligent Agent design and software update tools to push out new updates. The Agent must be capable of being updated while it is running, i.e., you have to use the Agent to transport the updates and then reliably execute the update without losing communication with the server. Otherwise, you just bought an extra service dispatch.

The system must also have the tools to manage software updates so you can know Agent versions and which versions have been upgraded. The software update process has to consider how updates are defined, tested, and deployed.

Let's look at an example. A new variable is to be collected and reported by an Agent. With Axeda ServiceLink, this usually requires the distribution of new Agent configuration file(s). Step 1 is to create the new files and run them through the full testing and validation process. Once the new configuration files are released, they can be packaged into a software update. The package should include checking for prerequisites, file management, file upload/download, and update execution, all while reporting status. The completed package should then go through a round of testing and validation with special attention to handling any edge cases that may be found in the deployed systems (e.g., different file paths or file locks). Only when the package is fully tested should it be made available in the system for deployment.

It is important to consider how updates will be deployed. In some cases, an update should be sent to every Agent in the device population. In other cases, you may only want to send it to a particular region, customer, or only as the result of a support case. Pushing updates may be something that is limited only to specific people or under a controlled procedure. These choices may flow directly into the decisions around user management and privileges.

One last area to consider is the impact to customers as they receive a new update. Some may be able to take an update any time the machine is in Standby mode. Others may have strict requirements that an update can only be applied during a Scheduled Maintenance window. Others may only want to receive an update under control of a local attendant. The software update process should account for this user input and operate accordingly.

The Internet is a dynamic place. Things change all the time. Your knowledge of how your machines or systems work in the field will also change as you gain experience. The remote service evaluation process should carefully consider the options around how Agent updates will be managed. Assuming an asset life of three to ten years, the change management and change deployment process can have a dramatic impact on the total cost of ownership of the remote service program.

In May 2009, we announced that Axeda received VeriSign Security Certification for the third consecutive year. This certification is a result of a comprehensive assessment covering our entire product portfolio and internal processes. 

I'll resist the temptation to elaborate on how proud I am of Axeda's R&D team and instead talk about why this is important to our customers and their customers. 

First, let's briefly review the Axeda solution architecture for Smart Services.  Our customers that manufacture or manage wired assets install an Axeda Agent on or near their assets, which are deployed on their customers' corporate networks. The agent works with the Axeda Enterprise server to provide our customers with two-way, Firewall-Friendly monitoring, communications, and control of asset data and events in real time. With the transmission of data from a customer location to the manufacturer site or into our hosting center, end-to-end security is a must-have requirement! 

Since the company's inception, we have engineered security into our products because we recognized that without rock-solid security, our customers and their customers would not accept Smart Services. The initial VeriSign Certification - the first remote service application to receive this distinction back in 2006 - validated our efforts and gave manufactures third-party validation that Axeda technology was secure and that their customers would willingly accept Smart Services on their networks.

Hundreds of thousands of deployments later and our third VeriSign Security re-certification proves that our solution meets our customers' (e.g., Diebold, EMC, CareFusion, and Comverse) and their end-customers' (e.g., banks, governments, airports, and hospitals) stringent security requirements.

As reflected by this re-certification and our continuous engineering efforts, Axeda focuses on delivering end-to-end secure solutions, enabling our customers to focus on delivering high-value service and support to their customers.