Digital Agility Gets a Boost with Identity Management

(A version of this Blog originally published on Auth0 Blogs) 

Apps are becoming componentized and API-based to facilitate reuse and agility; Identity management cloud services will help.

"In today's online-first, intensely competitive environment, creating a monolithic, inflexible CIAM system will quickly put the firm on the path toward extinction." ~ Forrester's Customer-Obsessed IAM Operating Model April 2020

There is an "old-school" view of Identity and Access Management (IAM) that sees it purely as a security requirement for apps and websites. Simply, IAM is there to keep the bad guys out and let the good ones in.

A more progressive view recognizes how IAM helps provide a better level of user convenience and app-level personalization, as well as lower-friction interactions. Plus, it can offer the business better CRM data, a lever for managing data privacy and compliance controls, and (if implemented properly) a consistent context-sensitive security perimeter across all apps/properties.

But there's a third level of benefit of IAM that IT often overlooks: A consistent, flexible IAM foundation can contribute to the firm's overall digital agility.

Here's why: IAM systems have traditionally been embedded into apps and frameworks (think: React, Angular, JS, etc.). Using that approach, each app runs the risk of becoming an IAM silo unto itself. And when it comes time to integrate those apps with other identity-driven systems, the approach can create a massively inflexible infrastructure.

Worse, firms should expect that many of their custom apps will have to work alongside other enterprise apps — e.g., marketing, digital experience, privacy/governance, business systems, and of course, security and analytics. However, the reality is that the logical topology surrounding your IAM system will always be dynamic and distributed — plan for it. The nature of enterprise systems IAM needs to interface with will always change. But when business leaders don't plan a consistent IAM foundation, digital agility will be one of the big losers.

Identity Has Become a Foundational Component of Digital Transformation, IT Agility, and Infrastructure Modernization

Digital transformation initiatives are when progressive software-driven companies shift from rigid, monolithic IT infrastructures and apps into more componentized API-first architectures. These are more easily reassembled/rearchitected and reused (see this great blog about API strategies by Informatica). Component software also means that app updating can be done on a piece-part basis, without requiring the entire application to be retested and QA'd.

When shifting to an API-based strategy, there is often a simultaneous replatforming initiative for some (or all) of the components, shifting them into the cloud and/or onto serverless cloud platforms. These initiatives also help businesses respond more rapidly to fast-moving opportunities and/or competitive issues. The growth of API-first architectures and use of serverless execution platforms has been nearly geometric during the past few years.

Distributed and loosely coupled

In software design, a loosely coupled system is one where each component has, or makes use of, little or no knowledge of the other components. This could include the coupling of software classes, interfaces, data, and other SaaS services. Loose coupling is important because it allows you to rearchitect specific components in the future with minimal impact to other components.

Often, one of the loosely-coupled underpinning layers of these digital transformation initiatives is security and access management — certainly found at the application level, but also even at the component level. With potentially millions of such API-first distributed components being deployed, each component, app, and composite application must be reliably and consistently secured, embracing the capacity to be identity-aware.

Decoupling identity from the application and/or app component means avoiding inconsistent IAM stores/DBs, yet ensuring a consistent privacy model, reliable access, and a strong security perimeter.

An Identity-Centric Point-of-View: 

Your Identity Management functions should be componentized, programmable, and cloud-neutral

Many of today's IAM technologies are embedded in programming frameworks and therefore hardwired to apps. I believe these IAM functions must — and will — become decoupled from the apps they support. Decoupling IAM helps release customers from the bonds of vertical integration stacks that are inherently siloed, brittle, and fundamentally non-optimized for the complexity of today's identity needs.

IAM functions should also be released from mega-cloud lock-in. The market requires an IAM foundation that's open and customizable — rather than a foundation that binds customers to an Amazon, Azure, or Google agenda.

This matters because an IAM approach that's API-first, application-decoupled, and componentized also allows developers and their enterprises to rearchitect and dynamically deploy new updates, features, and functionality without disrupting the underlying identity infrastructure. That results in the ability to respond to business conditions and competitive situations more quickly and reliably.

“Using microservices in containers has also allowed us greater flexibility when deploying IAM solutions. Typically IAM solutions have featured larger, more monolithic services that are harder to scale and upgrade. Microservices allow the structuring of an application as a collection of loosely coupled services. This architecture then enables the continuous deployment of complex applications, as it is less complicated to update smaller services incrementally than larger ones. It also allows the scaling of particular components (e.g. databases, LDAP servers, etc.) to meet demand as required.”  ~ IAM DevOps in Capgemini, Terence Stamp

Some closing recommendations

For executives, technology agility equates to business agility. Work with your technical colleagues to understand what IAM underpinnings you currently have and how those will need to evolve to work alongside adjacent systems for marketing, digital experience, privacy/governance, business systems, and security and analytics. Urge technical partners to: 

• Seek to componentize applications, and underpin them with a consistent IAM infrastructure. Treat IAM as a reusable component service the way you use other reusable SaaS services (e.g., payments, databases).
• Measure and justify the benefits of IAM across your infrastructure. Collaborate with colleagues in security, customer experience, web, and CRM teams; assess where identity can yield quantifiable top-line revenue and competitiveness.
• Prioritize customer outcomes within digital transformation initiatives. Digital agility and transformation program outcomes must be driven by a focus on responsiveness to customer needs and expectations. Identity management foundations not only contribute to a consistent/reusable infrastructure but also help build a comprehensive customer 360°.
• Neutralize cloud vendor lock-in risk with an independent, cloud-neutral IAM system. Long-term agility and avoidance of high switching costs are further enabled by using an independent, cloud-neutral IAM service.

For technologists, it's time to apply IAM like other loosely-coupled SaaS services you commonly use. For example: 

• Use familiar API and microservices principles when adding IAM into your platform. Select a reusable, easily-integrated cloud IAM service that's compatible with a broad set of programming languages and frameworks.
• Reduce IAM time to production; simplify app reuse. Get your team started quickly with a solution offering SDKs, quickstarts, and implementation guidance.
• Consolidate user IAM systems and databases. Use an IAM solution offering a range of migration tools and customer DB connections to fit the user migration scenario best for you.

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.

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.