Tuesday, May 1, 2018

4 Warning Signs an Integration Wall is Approaching

The Integration and API Management markets are growing,  expanding in both popularity and use.  Enterprise App integration will surpass $33b by 2020, and other markets like iPaaS and Data Integration are growing at double-digit CAGRs.  Enablers, such as  containers and serverless technologies are only accelerating the move toward increased disaggregation of applications.

All seems rosy. And it mostly is.

But with the explosive growth of APIs and endpoints, traditional centralized tools like ESBs will become unsuitable, and simple low-code snap-together tools won’t scale to address the broader scope.  We’re potentially about to hit an “integration wall” at high speed.

Consider the following four warning signs – some technical, some process – that I find are beginning to plague the integration market:

1. Waterfall Development for integration is hitting a wall. 
Although most code development has shifted to an Agile Development model, the same can’t be said for Integration tools. As the quantity and diversity of endpoints increases, and as Integration projects become more diverse and complex, use of the waterfall model is beginning to slow down integration projects.  And with a future where there will be billions of Integratable endpoints, it’s obvious that an Agile Development model for integration will need to become the norm.

2. Existing tools and programming languages aren’t optimized for Integration-at-scale.
Enterprises that currently use low-code, snap-together, centralized integration technologies (including iPaaS) will not be optimized for orchestrating, integrating, observing and governing the expansion of constantly-changing endpoints. Nor are traditional centralized approaches (think: EDI and older ESBs) prepared to handle increasing endpoint scale or diversity.  Many of these existing tools are well-adapted for Line-of-Business or Citizen Integrators of relatively small-scale implementations but are far from well adapted for more complex integration-at-scale projects.

3. Current programming languages are not optimized for Integration. 
With languages like Java/Spring or JavaScript/Node, developers can engineer flow, but must take responsibility for solving the hard problems of integration. With these languages, developers have to write their own integration logic or use bolt-on frameworks.  Clearly a new programming paradigm will be needed long term.

4. The Exploding Endpoint Problem is very real.
As I referenced above, IT is ill-prepared to address the oncoming wave of service disaggregation, the diverse types of APIs, differing sources of service endpoints, challenges from Big Data, and multiple approaches to serverless IT. The industry is about to hit a scale and diversity wall. To wit,
 • 917 apps in use per enterprise (Netscope, 2016) 
 • 893-1206 average cloud services used per employee (Kleiner Perkins, April 2017)
 • 19,000 APIs as-of January 2018 (Programmable Web, 2018) 

And if you don’t believe those numbers, Matt Eastwood of IDC recently pointed out that the number of containerized services has expanding well beyond where VMs ever were.  Yep, billions of programmable endpoints aren’t kid’s stuff.

Where does this leave us?

A new approach to addressing the future of integrating thousands – or millions – of endpoints could lie in a new programming language, Ballerina.

Ballerina is a simple programming language whose syntax and runtime have been optimized for the hard problems of integration.  Its focus is integration – bringing concepts, ideas and tools of distributed system integration into the language.  Based on the concepts of interactions within sequence diagrams, Ballerina has built-in support for common integration patterns and connectors, including distributed transactions, compensation and circuit breakers. And it supports JSON and XML, making it simple and effective to build robust integration across distributed network endpoints.

So, watch this space for future developments. And in the meantime, beware of the approaching wall.

Thursday, March 15, 2018

My Next Big Thing

Skating to where the puck is going to be

Some of you have noticed my professional interest has shifted. This week I joined WSO2 to help them achieve their next stage of growth.

I am thrilled about this move because the ever-increasing popularity of cloud services and cloud sprawl is triggering the need to integrate those exploding quantity of endpoints – APIs services, events, and data streams.  This is an important technology market, helping companies harness the power of the cloud to generate real business value. It's where the industry is headed.

For me, the opportunity to develop and shape new technology categories for integration, API management, identity and services analytics was too exciting to pass-up.  And WSO2 has a number of unique advantages that I found compelling – ranging from their suite of technologies to their open-source model (and culture) to.... well, stay tuned for a big announcement in the near future.

To be sure, there are already a number of industry players in the API and Integration markets. Most are either pursuing relatively straightforward SaaS integrations around a “hub” (think: SalesForce, WorkDay, Netsuite, Oracle) or building simplified “Citizen Integrator” templated approaches to Integration (think: iPaaS).

And if you somehow haven’t been reading about Containers, Serverless Architectures, IPaaS and others, you should know that the exponential trend toward more, smaller, cloud services is already upon us. Leveraging these technology resources will enable (if not accelerate) the trend away from large monolithic apps (and SaaS apps) toward more granular – and more flexible – services and APIs. And businesses that move in this direction will find themselves with a more agile IT that can respond/adapt to needs more quickly.

Continue to watch this space for tips and observations on WSO2, as well as about the API Integration space overall.

Thursday, February 1, 2018

The CIO as a Cloud Supply Chain Manager

Transforming IT from engineers and builders... to assemblers and integrators

About 5 years ago, I wrote a GigaOm article, The CIO as the IT Supply Chain Manager. The focus was how cloud services would transform how CIOs shifted from Technology Builders to become Service Assemblers. This concept is now more relevant than ever – with 30+ vendors offering API management products, Integration Platforms as a Service (iPaaS), Serverless functions and containerized microservices.  Let’s look at how technology is helping CIOs in this transition...

Setting the stage
If you’ve been a CIO for more than 10 years, you’ve probably thought of yourself as a builder of technology. You’ve had oversight of app development, built custom databases, managed director and identity systems, and hired scads of coders. 

But the CIO as a software engineer and builder of technology is changing.

Let’s consider enterprise application evolution. Over time, monolithic applications made way to special-purpose apps... which then made way to third-party SaaS apps. This evolution afforded IT with higher-value and better fit-for-purpose infrastructure, while allowing for broader choice to use different app sources and vendors. Indeed, the number of SaaS apps being consumed by enterprises is exploding, with the average midsized company consuming 20+ SaaS apps

However, today we’re now seeing the SaaS apps beginning to yield to component web services, public APIs, and even micro-services.  We’re also seeing companies beginning to front-end their existing services with internally published APIs, so that they can be consumed like external micro-services.

But these changes are challenging IT teams with the need to integrate the cloud services, APIs and workflows, so that the services work seamlessly with the business.

But all of this comes with new challenges that require a new CIO mindset and set of capabilities.

Enter: The Transformational CIO

As Tim Crawford recently pointed out, the job of the CIO is going through a transformation. CIOs are becoming more central to the business, more critical to strategic agility, more essential to competitive advantage. 

To achieve those goals, IT departments are now looking at how they need to use and consume services, whether they’re internal apps, external SaaS providers, data sources, public API-generated microservices, and even IoT-generated event streams. And, more CIOs are taking inventory of their internal apps, disaggregating them, and internally publishing their APIs and event streams so app services can be more readily consumed by other apps.... becoming service creators themselves.

The driving force behind these changes are simple: large, monolithic apps – and even large SaaS app suites – are difficult to modify.  So, when a business need requires a new function, supplier integration, app integration, data source, etc., IT has to be able to respond quickly.

Act II: Integrating the Cloud Supply Chain

The new mindset for IT requires them to think as integrators of resources... whether internal, external (public cloud, SaaS, etc.) and a hybrid of both. This is the “IT Supply Chain”.

If the CIO is successful, the result is a monolithic-app-to-API-and-service-centric transformation that yields a new set of capabilities for IT as well as for the business: 
  • Standardization: Curated and managed APIs make service use (and re-use) simpler. 
  • Technology agility: Assembly, workflow and orchestration of service components helps IT add/adjust its capabilities and portfolio more quickly
  • Business agility: By adjusting technology quickly, IT can enable the business with new revenue-generating, competitive, and strategic services sooner than the competition. 
Take, for example, a marketing-driven company that typically consumes a dozen or more web services for different functions such as demand generation, operations, customer communications, and web development. There are nearly 100 services to choose from and integrate, and few if any the company will want to natively develop. 
Credit: Storm Ventures

However, if the CIO views their role as a supply chain manager of these services, they can provide their company – in short order – with a sophisticated, integrated set of services that are customized to their needs. And agile enough to change should business conditions change too.

The advent of cloud services, public APIs, and integration/programming platforms will transform how CIOs operate. And in turn, these new supply chain-oriented CIOs will drive a new advent of change in their organizations.

Monday, November 20, 2017

Trying to Market a Horizontal Technology? Think Again.

Why marketers fail to focus on industry-specific buyers

I was recently speaking with 2 CEOs of leading-edge technology companies about how they go-to-market. One is a brilliant open-source software firm, the other a groundbreaking virtual networking startup. 

When I asked them what their industry marketing approach would be, each essentially said “I don't need that – we have a horizontal technology.”

My reaction was one of surprise. Were their technologies applicable cross-industry? Yes. Will the companies continue to grow? Absolutely.  But after years of my own leading product- and corporate marketing teams, I’ve found that it will take longer for each company to reach their full potential and market penetration if they don’t first adjust their go-to-market approach to industry-focused buyers.  I’ve blogged about this in the past as it applied to Service Providers, and how they can also use Verticalization to reap increased profits.

Avoiding technology marketing gaffes

Speaking as a (recovering) technologist I can say that engineers and technical leaders are unbelievably proud of their accomplishments... so proud in fact, that to them, their technologies ought to speak for themselves. 

The problem is, most customers aren’t buying technologies... they’re shopping for solutions to needs that they have in their business. 

The 4 biggest Go-to-Market errors I typically see are

  • “Build it and they will come” - A dangerous tech mentality that really only succeeds in rare, industry-wide transformations. How many great ideas have you seen flop?
  • “It’s good for everyone” – Ironically, this is a myopic view. Beware of the fact that while the idea probably good for everyone, it’s probably not great for anyone. Actual (or perceived) focus on segments is critical.
  • “The technology speaks for itself” – This might be true. But the issue is that humans search for (and buy) solutions to problems, not for technologies
  • “Just see how it works” – Perhaps illustrating functionality helps in the buying process (inside the “marketing funnel”) is cool. But talking about how a technology works high in the funnel doesn’t accomplish helping get the initial attention from a prospective buyer.

Instead, think about how buyers think
The takeaway is that buyers rarely look for a generic technology... and even when they do, they want to know (and see) how it’s applied to their specific market, industry, or company size.  They want to be assured that it’s the right solution, and one that’s been successfully tailored to other companies just like theirs.

  • Buyers think about solutions specific to their immediate needs and their problems. And each buyer thinks (often justifiably) that their problem is unique to their type of business.  So solutions and descriptions have to be tailored to sounding industry-unique.
  • Buyers identify with, search for, and buy, solutions that align with their title, industry and company type. So your solution personas need to appeal to these specific attributes and use these specific keywords
  • Most buyer agents prefer solutions that appear to be fit-for-use and/or ready-to-use, rather than generic “engines” that might imply wasteful customization.  So it’s critical to illustrate how “finished-goods” the solution is for each industry solution.

What to do now – Even for the most “horizontal” technology

  1. Know your customers and know your buyers
    understand the keywords they use in their industry, what terms resonate with them, especially terms that are industry-specific.   Also, understand the specific problems they’re solving for... Even a small tweak to your “horizontal” solution description that uses terminology in the selected industry or specific persona will get an added resonance with a buyer. 

  2. Emphasize industry-specificity

    Every industry has unique language and terminology – so use them. Plus, most industries have specific forms of legal constraints, compliance requirements, and/or security approaches.   Learn these and explain – in industry terms – how your horizontal technology maps to each on, individually.  You may need to hire someone from these industries to help you understand them and craft unique messages.

  3. Highlight use-cases!

    Not every buyer can envision how your technology applies to them, how critical it might be, or how valuable it is. Make sure you illustrate a broad set of use-cases that highlight individual industries. And once again, ensure you’re using industry-specific terminology, value propositions, and personas as you tell the use-case stories.

  4. You can differentiate with your channel
If you sell indirectly (via resellers, system integrators or distributors) often your channel partners can take your technology and adapt it to specific markets, buyers or geographies. This is often a win-win relationship: You get a differentiated product that’s adapted for a market or use-case, and your partners get an opportunity to add value and increase revenue.
  5. Other creative ways to differentiate

    There are surprisingly simple ways you can differentiate a basic technology in the market such that it has greater appeal to specific audiences.   For example, consider how you might address a small/medium/large customer – perhaps with slightly reduced functionality and associated pricing for smaller or entry-level customers.
  6. Organize your customers by industry
Every time you get a new customer “success story”, make sure you categorize it in an industry category. Rest assure, when buyers come to your website, they’ll instantly gravitate to verticals they play in... and even want to see what competitors of theirs have done with your products.

Back to where we began...
I’ve taken a shot at using my own advice – and applying it to the two CEO examples that I experienced earlier. I hope you find these interesting and thought-provoking for your own products:

Vertical marketing advice for the Open-Source firm....

  • Can re-categorize their ~ 400 public customers by vertical - and making the list searchable
  • Illustrate integrations with major industry-specific enterprise apps in ways that resonate with buyers of those products; Also, partner tightly with those app vendors.
  • Emphasize vertical industry use-cases (i.e. they already cite Banking) and how each industry is each deriving value differently from the product
  • Attend and/or secure speaking opportunities at core vertical-industry trade events where they have solid use cases and success stories
  • Team with value-add technology partners who further customize the open-source platform.

Vertical marketing advice for the Networking technology firm

  • Create a content marketing initiative focusing on solutions and use cases, not just on “how it works”
  • Assess and expand upon ROI and benefit analyses that are specific to different industries – in their terms and cost/benefit models
  • Differentiate the offering with alternative pricing models, such as dedicated instances vs. peak load “burst” instances 
  • Build off of the vertical messages that the adjacent competitors use, illustrating why this new technology is better for each industry.

Wednesday, November 1, 2017

A Tale of 3 Cloud Strategies - Part III

How the major vendors are vying for hybrid cloud dominance

Over the past few years it’s been an exciting show to see the Big 3 cloud providers jockey for strategic dominance, each with a different approach. As an IT professional, it’s useful to understand each of these in context as you try to determine which horse(s) to ride and what bets to make.

To recap how I’ve been tracking some of the evolution:
  • In Part I (back in 2013) we observed AWS experimenting with expansion by reaching down into the enterprise by licensing its APIs (remember Eucalyptus?) and building a VPC (which evolved into Direct Connect). Meanwhile VMware was experimenting with growth by partnering with independent cloud service providers, a precursor to their failed vCloud Air approach – an attempt to reach from the enterprise up into the cloud. 
  • In Part II (later in 2013) I added a 3rd player to the scrum, when Microsoft introduced the concept of the Azure Pack to their Server stack, a strategy to reach down from the Cloud into the enterprise and bridging the two with a common set of APIs.
In essence, AWS, VMware and Microsoft all looked at ways to expand their presence to create easy-to-adopt hybrid cloud strategies that would lower barriers-to-adoption... and hopefully accelerate enterprises landing workloads onto their stacks.

Enter VMware Cloud Foundation: 

Recently, VMware announced Cloud Foundation, a new strategy to (in my opinion) replace vCloud Air.  In concept, this approach is not unlike Microsoft’s Azure Stack strategy.  VMware is building a common cloud workload management platform that incorporates their SDDC that will operate with both public clouds and on-premises VMware implementations... thereby lowering the barrier-to-adoption of hybrid workloads based on VMware technology.

While Cloud Foundation is similar in concept to Microsoft’s Azure Stack, the two companies took very different approaches to implementation.  Microsoft in essence took the Azure API set, and embedded it into their on-premises server software.   In contrast, VMware took their (mostly) on-premises API sets and is embedding them to public cloud provider offerings.

VMware’s approach is interesting – and potentially very successful. First, they’re cutting deals with major public cloud providers like IBM, AWS, and Azure, so they are able to embed their virtualization stack on top of these public cloud platforms.  And next, they’ll (likely) begin to work with their ~ 4,000 cloud service provider partners to do the same, enabling a pervasive set of common APIs across thousands of providers large and small.  If you buy-into the VMware view of the world (and, some say, the “vTax”) this could give you the ultimate degree of common cloud choice... and put the reach of VMware across as many clouds and on-premises infrastructures as Azure.

Snapshot: Where we are today
As I see it, we now have the following competitive landscape and strategies: 

  • Strategy: Abandoned licensing APIs; Now 100% invested in public cloud presence, and in building-out a dominating set of services – to make their APIs into a de facto “cloud OS”
  • Play: Focus on the single best public cloud IaaS platform and PaaS services for developers and enterprise workloads
  • Business Model: Make money from services and from running workloads
  • Strategy: Expand from Cloud  Enterprise. Take their public cloud APIs and duplicate them on-premises within their installed base within the enterprise.  Further helps blur the line between on-premises and cloud, as-has Office365.
  • Play: Reduce/remove barriers-to-adoption of the public cloud by first encouraging API adoption on-premises
  • Business Model: Make money both from server software (traditional) as well as from cloud workloads landed on Azure.   
  • Strategy: Expand from enterprise  Cloud. Introduced Cloud Foundation, coupled with SDDC. Initially work to deploy on major public cloud providers, then expand platform to 1000’s of cloud service providers.
  • Play: Encourage pervasiveness of the platform by expanding its reach onto public clouds and into managing heterogeneous hypervisors and containers
  • Business Model: Make money from becoming the central management software (while partners make money on workloads)
Other Players? 

There are still some players out there that are still to be reckoned with.  Namely Google Compute Cloud, as well as IBM/SoftLayer.  While I’m not yet aware of any Google GCP approach/strategy, IBM has just announced their “IBM Cloud Private” approach, based on a number of open-source technologies. This also seems to be a hybrid container/deployment management model – and we’ll look to the future to see what traction it gains. 

In summary... 

As go most major industries and technologies, it appears that industry consolidation has pared-down the major cloud players to 3-5.   So, I’ll close by pointing you of my favorite, prescient Blog back from 2006 by Greg Papadopoulos, then Sun Microsystem’s CTO – Why the world only needs 5 computers.  True Dat.

Thursday, October 19, 2017

Cultivating a New Tech Category

9 Things every marketer should know before they introduce a new technology

At some point in their career, most technologists think they have the “next big thing”, a product or technology that stands out uniquely from anything else on the market. In fact, it’s so great that it deserves to be a new category in-and-of itself.

Now, if you’re a reasonably-seasoned marketer, your initial response to this is “They first need to properly price and position the technology so that it solves a well-defined problem, or creates a new valuable capability that customers will pay for”.

That would be true if the product was in a well-understood, mature market. But it’s far from sufficient when the technology or category is new or nascent.

Maturing a new market category and building an ability to execute

The problem technologists face is that most potential customers approach buying-into the product the way Gartner Research sees their “Magic Quadrant” – (a) is the revolutionary have a “Completeness-of-vision”?  [often Yes] and (b) do they embrace a reasonable “Ability to execute” [often No]

Why “No”?  Because most often, customers shy away from purchasing products in a vacuum. Rather, they demand a “Whole Product” – one in a category that’s mature, well-understood, and ultimately poses minimal risk of long-term adoption.

Besides good messaging, how should product marketing, market development, and alliances organizations help build a mature market category?  And, how can they accelerate the journey to “Ability to Execute”?

Top Market Category Development Initiatives

1.     You need the competition
Look... nobody will believe you if you claim there’s no competition. Rarely is it ever true. If you want to ensure a mature market category – one where customers believe the technology is worthwhile, will someday be mainstreamed, and represents a relatively low-risk option – then customers will expect and demand competitors. So, don’t hesitate to include mention others in adjacent markets, or companies that are just nipping at your heels.

2.     Encourage healthy Analyst awareness & coverage
Some of the top influencers in the tech market are industry analysts. Find out who the individual analysts are that cover adjacent spaces to your new category and educate, educate, educate. This process won’t result in instantaneous reports, but is critically important nonetheless. If analyst organizations don’t first recognize your category, they won’t assess it or follow it. And that means that buyers – who follow the analyst’s evaluations – won’t buy into it.   You know you’ve reached your goal when analysts formally cover the category with ratings, Magic Quadrants, and competitive evaluations.

3.     Ensure a known/understood product and pricing model
Mature markets have known (and often, expected) pricing models.  If your category’s approach is different or unusual, consider changing it to a more industry-standard style.  Otherwise, you may need to wait until other competitors in the space offer similar pricing approaches so that customers see it as the “standard” for the category.

4.     Cultivate a Developer following
For most technologies, you’ll absolutely require a community of developers, admins, and/or architects to adopt your platform, APIs, architecture, etc.   Their expectation is that you’ll publish information, examples, and best-practices and even free testbeds – to get them that information essentially free-of-charge as they learn/adopt your technology.  Make sure you create an enthusiastic following of developers, local user groups, and even ISVs, and liberally nurture this critical population of customer/buyer influencers.

5.     Cultivate an ecosystem of ISVs and 3rd-parties
Similar to cultivating a developer following, the notion of offering a “whole product” requires that you also work with partners, software vendors, service providers, or any other company that directly (or indirectly) adds-value to your technology.  (They’re always there. If you have trouble identifying them, look harder... or ask your customers).  You should consider investing in an ISV and/or alliances program, where you’re actively helping promote your value-add partners to your customers. Remember, if you have a robust ecosystem of partners, your customers will immediately recognize it, and further trust in your new technology category.

6.     Develop the right terminology, and work it into the industry vernacular
Customers won’t buy-into your new category if nobody’s talking about it.  You’ll need to invest in very intentional content marketing, social marketing, hashtag use, SEO seeding, conference speaking opportunities etc. to begin to get your market category terms in use.  Choose the terms judiciously, and only use 1-2 lest you dilute their use.  Wherever possible, also work with influencers near the space (analysts, editors, tweeps, etc.) and engage them in conversation where they begin to use your terminology

7.     Cultivate the new topic at trade shows and conferences
This is not about exhibiting at conferences.  Rather, it’s that you really know your category is mature when entire industry conferences are based on it. But in the meantime, you should focus on getting your new topic inserted into conferences on adjacent topics/technologies by submitting speaker abstracts, and by encouraging customers of yours to do the same.  If you know of complementary companies (or even competition) in the space, then also consider approaching conference promoters to create a small “neighborhood” of like-minded technologies within the larger exhibition floor. That will help develop customer awareness of the new category.

8.     Pursue industry awards
It never hurts to get mentioned in industry awards, or even in those “best new xxx” or “coolest vendors in xxx” surveys.  Search for who’s conducting awards and surveys, and make sure you are on the short list of those getting considered (remember: you don’t need to win... just getting an honorary mention is OK). And don’t forget to have your customers and partners nominate you, too.  The more your technology category gets mentioned and considered, the closer you are to getting in the mainstream.

9.     Hype that customer momentum!
True for all forms of marketing, the best seller/marketer to customers is another customer. Focus on developing great customer stories that illustrate your outcome/benefit (not how “cool” your technology is). Ensure these stories contrast your new category against the “old” ways of doing things. And get the customers to directly endorse the technology/category/segment.  Their peers will always take notice, and have greater confidence in the new sector/category.

As always, I'm interested in your thoughts, reactions, additions. Part of the magic here is bringing new and innovative ideas to the table. Please have at it.