Technology-as-a-Service: An enterprise M2M strategy

Machine to Machine (M2M), Industrial Internet, Internet of Things (IoT)… different names, but they all in a way converge on the same thing, looked through different lenses. This is one of the biggest emerging trends in network computing. Mega-trends like these happen once in a decade or longer. At Sun Microsystems where I spent 10 years, we used to have a tag line from start till the end which said: The Network is the Computer. What a vision that was, and it outlasted the company! Scott McNealy and others at Sun frequently would talk about the connected refrigerator. Today, it is a reality. Smart machines are here to stay and not only stay, but to grow and thrive. A company that sells any kind of hardware (washing machines to MRI machines, cars to planes, computers to mobile devices, the list goes on to virtually every physical object sold by someone), cannot afford to sit by on the sidelines and watch this mega-trend demolish them. These companies have to react and respond, and do it now.

GE, Cisco, and many other large corporations have long realized the importance of IoT. One of my favorite ads on TV (I don’t see it on anymore) comes from GE where all kinds of machines are coming home (I found this, but those videos are no longer active on youtube, however I did find this one that still works, sort of). Also check out what Dave Evans, Chief Futurist at Cisco says about this topic.

The point is, we have not only been talking about IoT for a long time, in fact, it has silently become a reality. Those that are still asleep at the wheel of their organizations can now ill afford to not notice and take some action.

MQ Identity Methodology

I was talking to my friends Alok Batra and Jane Ren, who just launched their new company MQIdentity. Alok and Jane are well-known thought leaders and change leaders behind the Industrial Internet and M2M related transformations at Cisco and GE. Their knowledge of this space is quite vast and impressive.  So I asked them, what is MQ? They explained it stands for Machine Quotient. They went on to describe two concepts: Machine Quotient (MQ), the technical measure of efficient machines. You want MQ to be really high. And Service Coefficient (SC), the business measure of service competency. For your organization, you need to find the right combination of MQ and SC to bring the maximum effective business value out. All this sound too complex? This is where I think Alok and Jane with their MQIdentity methodology can help.

For me the most fascinating aspect dawned on me when I read their white paper titled Technology-as-a-Service (TaaS), which they just released on their website. It is a well-written, thought provoking paper that lays down a solid foundation to think about how to transform your business into the new IoT economy. They argue that TaaS will be the path of technology transformations for tech industries into service-centric economy. The paper is quite detailed and there is a lot to think about. But if I were to distill it to a few key take aways, here they are ¹:

• TaaS gives you a new way to expand your proprietary IP and technology, by unlocking its access to new customer base leveraging other proven services model (IaaS, SaaS, etc.).
• Your business is heavily disrupted by technology trends and you cannot stand by any longer and watch your customer base erode to newer solutions while you still have huge value locked inside your proprietary technology/products that can generate new revenues and expand in ways that you can’t otherwise think of expanding.
• Your business is also disrupted by new startups who are going to offer the state-of-the-art solutions at a much lesser price, even though their solution may not be as excellent as yours, you will see customers erode to the “good-enough” solutions.

In short, this is a space (M2M/IoT) that I am totally fascinated about, and this space is going through tremendous innovation. As a result, in the coming years, there will be a new emergence of creative solutions, products, business models. In my opinion, Alok and Jane are right in the thick of it. So watch this space, it will be exciting!

---

^{1 – There are many other implications, consequences and micro-disruptions at work in this area, read their white paper or their executive summary for more details. Don’t just take my word for it.}

Advertisements

Balancing Act: Build and Buy Strategy

In most startups, you begin with a hypothesis of how you are going to address a need, and hope to build a product or a solution that can fulfill that need and build a business out of it. The time to market is one among the many pressures weighing down on your mind. How do you execute in this scenario?

1. Build: You can build everything on your own. Though you don’t know what to fully build yet,  you will discover along the way.
2. Buy: You can find other technologies that address certain problem in a generic way and bundle (integrate) those to create your product. ¹
3. Build and Buy: You can build what you think is the core competency that your startup is going to focus on, and buy/acquire the other peripheral components to create your full offering.

Sometimes building everything on your own is stupid, why would you want to waste your time and resources in solving problems already solved. And you can’t just buy everything and cobble together a unique product that is worth something. So you have to really come up with a Build and Buy strategy for your product to both be uniquely valuable and addresses time to market. Time kills startups.

So if you are in charge of building the product, you are bound to face all these pressures coming from your CEO, CTO, Marketing and Sales visionaries in your company. And this is where if you are not careful, you will end up building something that probably takes more time, is not elegant, and does not add any real value. And thus, if the product has no real value, how can you expect your company to establish itself as a viable business. The paranoid around you will start proposing ideas, most of them tend to be hare-brained, spur of the moment types coming from really loud voices in the organization. This is the time when you have to stand strong. After all, you are there to build a new product that offers a new and unique value proposition and change the dynamics in the market.

I have gone through this experience myself and wondered if I and our product team caved to these pressures and simply bundled what is out there already in the market, would we really be a product company or just another integrator? Where does innovation rank? Where is the IP that is going to make your company highly valuable and set us apart? As a product owner, you need to really think hard and have the courage, conviction and vision. You need to lead and convince others that what you propose to build will be more valuable than just cobbling together a piece of other technologies. At JackBe, we established very early on that innovation was going to be the key value my team was going to live (or die) by, and as such, we went against the opposing forces time and time again to innovate and really build the core technology and IP that established JackBe as the market leader in enterprise mashups and real-time intelligence. Our product gained customer admiration, won several awards and eventually, the company was acquired by Software AG because of the value of our unique product and IP.

I am not saying that your complete product has to be 100% home-grown, every line of code written by your team. There are plenty of FOSS products for you to build your unique product or platform. And there may be commercial products or components that you might want to OEM and license to build your product. There is no need to build those from scratch. That would be silly and a stupendous waste of time and resources. The key is to identify what is core to your differentiation and what is commodity, and then build your core by leveraging the commodity components out there and that’s how you balance the forces and address the time-to-market. Some common commodity components to consider (I only mention a few to just illustrate the example)²:

• Server Side (Java Based): Application Server (Tomcat/Jetty/etc.), Application Frameworks (Spring, Akka, Play, etc.), Utility Libraries (Apache Commons, Apache Axis, Saxon XML Parser, etc.)
• Database Systems: RDBMS (Apache Derby, MySQL, etc.), NoSQL (MongoDB, Redis, etc.)
• JavaScript: jQuery, jQuery Mobile, Prototype, Angular JS, etc.
• Visualization: Fusion Charts, High Charts, D3, NVD3, etc.

So my message to you is this. Don’t just bundle other COTS to create your product. It won’t help you to build a revolutionary new product. Instead make  your own unique and secret sauce and mix it with what is commodity already to create a high value game changing product.

---

^{1 – Buy: For the purpose of this discussion, I am using ‘buy’ very generically. In some cases, you don’t really buy, but you can just acquire it via partnership. For open source products and components, you just use it (beware of what open source license they come with and their restrictions there upon. My favorite FOSS licenses are Apache 2, MIT, BSD. I tend to stay away from GPL (all versions) and LGPL.
2 – Free or Commercial: Note that some of the components are open source, and some are commercially available sold by other vendors in an OEM friendly license that you have to acquire from the respective vendor for a price.}

Mashups: New and Agile way to Integrate

I came across this interesting post: How Mashups Could Eliminate Integration Projects by Loraine Lawson. In a related post, she refers to John Crupi’s article Enterprise Mashups Part I: Bringing SOA to the People which I would recommend to readers who want to understand JackBe’s take on defining mashups. Anyway, Loraine’s post led me to Ron Schmelzer’s ZapFlash.

Here are some excerpts of Ron’s article that caught my eye, with my take on it:

A year or two ago, assuming that a mashup was a web browser-based, static, user interface composition of web-based functionality would be a reasonable presumption. But in the enterprise context, none of those assumptions necessarily hold – we might want non-Web access to mashed applications, we might want to change them regularly, and we might want to mash up information that exists below the user interface abstraction. For sure, Web mashups might embody the ideals of the original mashup concept, but we now have the desire to mash up a wide variety of IT resources from application to infrastructure to data that might be exposed with a wide range of interfaces – or without. And, it’s the desire to mash up information freed from the application that diversifies the mashup term to include the concept of the data mashup.

Introducing the Mashup Tier

My take: This hits the point right on what we at JackBe have been saying all along about mashups. While some mashups are done purely in the UI/Browser, in the enterprise, such mashups need to be supported by a new tier, the mashup tier, which sits between the presentation and business tier. So enterprise mashups will have some mashing done in the client, but most of the mashing happens in server side where security, governance, policies can be applied before any mashing can happen in the client.

Another excerpt:

There are many scenarios for composing data, but some are better suited for static, tightly-coupled, IT-driven, non-Service Oriented form. In fact, 80% of the value that businesses derive from data come from the 20% of fixed, highly optimized data integration approaches implemented over decades. In this realm, traditional data integration approaches retain high value. However, it’s the other 80% of data integration requirements, most of which come from the need to meet short-term, often ad hoc, integration requests that cause 80% of the problems. Anyone who has lived long enough in the enterprise IT space knows that business-driven requests for reporting, forecasting, analysis, or other interpretations of data can present significant complications and cost to the IT organization. The reason for this is that the IT organization is set up to meet the recurring needs of the business and not “situational” needs for information.

Long Tail of Enterprise Software Demand

My take: This highlights another issue which we have been talking about at JackBe about the long tail & enterprise applications need which was so nicely discussed here by Dion Hinchcliffe.

Bottom line: Something new and interesting is happening in the enterprise architecture space. A new flexible and agile tier is being introduced in the architecture to meet the increasing demand on IT and  add value to existing architecture, applications, services and data. Question is, are you embracing this inevitable change? If not, it’s still not too late. 🙂