The Virtues of (Personal) Networking

I’ve taken a bit of hiatus from blogging as I’ve settled-into my new gig at WSO2. But I’m back with a career and social observation that applies to everyone. 

This past week – partly by chance, partly by design – I’ve had lunch/coffee with

• A CEO / Serial entrepreneur looking for marketing guidance on his latest venture
• A college alum reaching-out for an informational interview
• A product marketing leader wanting to share professional experiences

It’s been an interesting set of wide-ranging conversations. But taken as a whole, it dawned on me that everyone, no matter what their level or level of discussion, should go out of their way to expand their network and “pay it forward” by sharing experiences, knowledge, and connections.  Never turn down an opportunity to exchange ideas or to meet someone new. 

The LinkedIn era

This is a new career era where potential employment is as much about using your network and knowing someone, as it is about being discovered via blogs, LinkedIn, etc.   

As a hiring manager, rarely does a good resume come in because of a passive job posting. Rather, almost always good candidates are found in the blogosphere, on LinkedIn, or through a referral by a friend / colleague / Tweep.

So as the saying goes, one’s professional value is as much “what you know” as “who you know”. Per the Network Effect, every new contact you make exponentially expands your marketability, source of knowledge, and overall professional value. So the act of expanding your network makes you more discoverable and valuable.

A nod toward WSO2 Principles

The other aspect of my (new-ish) philosophy is reflected in two of WSO2’s six new principles (we will announce them soon) that all of our employees embody. I try to take-them-to-heart every day in the office.... and outside. You should too:  

[Life is a] Journey of Experiences

• Each person is on a journey of constant growth.
• We provide everyone opportunity for their best journey.
• We are humble in accepting feedback and act with integrity.

[We are a product of] Community Contribution

• We are part of a wider community.
• We stand on the shoulders of other giants.  
• Everyone contributes; therefore, everyone can influence.
• We want to contribute to communities, facilitate external contributions and encourage community participation.  

These two principles speak to me professionally – to see that my career is a journey, and it is my (and our) individual responsibility to make the most of opportunities to learn from anyone and everyone. And the broader tech/business community is valuable to us when we constantly share our experiences amongst friends and colleagues.

As corporate principles, they also speak to me – to appreciate every employee and colleague’s experience, perspective and approach to their job. And to take all feedback (the good and the bad) as a contribution. As part of the open source community, we also have to be humble, but also realize it’s our responsibility to contribute back to the community-at-large.  

Networking is holographic - Our network of experiences, and our contribution to/from our community, is true at work as it is in life.  So meet new people. Struggle against being insular; share information, don’t hide it.

Propel others. In doing so, you’ll propel yourself.

  

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.

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.

The CIO as a Cloud Supply Chain Manager

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

Preface

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.

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.

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 3^rd 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: 

AWS: 

• 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

Azure:

• 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.   

VMware:

• 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.