ZapThink’s Final Idées Fortes

After a dozen years and almost 300 ZapFlashes, I have reached my penultimate issue for ZapThink. I’ll be moving onto new adventures in 2014, but not before assembling just a bit more wisdom for the tens of thousands of followers of this little newsletter.

The next and final ZapFlash later this month will of necessity be our annual retrospective and predictions for the upcoming year. But for this issue, I have decided to return to a theme from 2002, the first year of the ZapFlash: idées fortes, or powerful ideas. The original Web Services Idées Fortes article from September of that year called out asynchrony, loose coupling, and coarse granularity as the idées fortes of Web Services – and to this day, those three core architectural principles are still foundational to today’s Cloudified distributed computing world.

But in the intervening decade, ZapThink has covered immense swaths of territory. We’ve followed SOA up one hill and down the other side. We’ve focused the architect’s eye on the Cloud. We’ve hammered out the notion of enterprise as complex system, exhibiting the emergent property of business agility. We’ve done our best to tie all the various threads of change facing enterprise IT into our ZapThink 2020 vision.

Today, then, we can survey the ground we’ve covered and distill new idées fortes for the 2010s – the core architectural threads that have tied together ZapThink’s thinking over the last twelve years.

Idée Forte #1: Cloud Friendliness/REST-based SOA

As enterprises struggle with middleware-centric, Web Services-based SOA, they eventually move to next generation, RESTful approaches. SOA still calls for an intermediary, but now it’s stateless and exposes functionality via RESTful URIs. The REST-based SOA intermediary is policy-driven and provides a loosely coupled Business Service abstraction, but because it is stateless, it requires a RESTful approach to state that separates application state from resource state.

As it happens, this approach to state enables the intermediary to run in a Cloud instance in such a way that allows for automated recovery from failure, an essential Cloud best practice. It’s also possible for the elasticity of the Cloud to provide horizontal scalability and decentralization to the SOA intermediary. In other words, by solving some of the issues with traditional ESBs, we get Cloud friendliness as a side benefit – or vice versa, depending on how you approach the problem. But however you look at this idée forte, the end result supports Integration-as-a-Service: not the “middleware in the Cloud” Cloudwashing that some vendors are promoting, but the Cloud friendly Integration-as-a-Service that is well on its way to becoming the crux of the enterprise integration story.

Cloud friendliness, however, is more than REST-Based SOA and Integration-as-a-Service. You must also have a Cloud friendly approach to data. Since Cloud environments are inherently partition tolerant, we must trade off basic availability and eventual consistency. Typically we want our Cloud environments to be basically available, and hence we must live with eventual consistency. But there’s more to this story: data immutability. If we entirely forego UPDATEs and DELETEs, then we no longer have to worry about blocking our reads or writes, improving performance for highly distributed, eventually consistent databases like the ones we want to run in the Cloud. Data immutability is also the key to real time Big Data analytics, thus opening the doors to a range of entirely new possibilities.

Idée Forte #2: HATEOAS and Next Generation APIs

Hypermedia as the Engine of Application State (HATEOAS) is the most important RESTful constraint, because it drives Hypermedia-Oriented Architecture (HOA) and the separation of application and resource state. Not only does HATEOAS open up new, Cloud-friendly approaches to Business Process Management (BPM), but it also redefines the notion of an Application Programming Interface (API).

REST’s uniform interface, of course, dramatically simplifies the notion of an API. Instead of Web Services’ custom operations which cause no end of trouble, REST provides the same verbs for interacting with any resource: GET, POST, PUT, and DELETE if we’re using HTTP as the transport protocol. But HATEOAS takes this API simplification one step further, because it calls for hypermedia-based discovery.

Start with an initial URI, which we logically call a bookmark. From there, any arbitrary piece of software serving as the client should be able to query the current URI (either for the bookmark or for a subsequent hyperlink) for instructions on what to do next. All retrieved representations should be fully self-descriptive (another REST constraint), thus providing all the necessary metadata to the client to facilitate the ongoing interaction. Straightforward in its way, but for developers used to traditionally static APIs, this HOA approach is a mind-bender.

One of the most important benefits of hypermedia-based discovery is how it deals with changing functionality. Fundamentally, we have the freedom to update or version resources without having to change the URIs we use to access them. In fact, we should never change the URIs – they should be as immutable as our data. Combine immutable URIs with the extreme late binding on the REST-based SOA intermediary, and we’ve built a shockingly flexible approach for solving diverse, dynamic integration challenges. In other words, we’ve taken the loose coupling idée forte to the next level.

Idée Forte #3: Declarative Programming Driving Next-Generation Governance

The declarative programming model separates logic from control flow. SQL describes database query logic, while the inner workings of the database are independent of individual queries. HTML describes the structure of Web pages, but the code inside the browser can render any HTML file. Extend this separation to the functionality of our enterprise technology infrastructure: policy-driven behavior where we represent the policies as metadata.

Of all the Web Services standards, in fact, the ones that drive this metadata representation of policies are perhaps the most powerful: WS-Policy, WS-SecurityPolicy, and a handful of others. But regardless of whether you’re using these XML-based standards, JSON-based policy representations, or some other format, representing policies as metadata is the first step in supporting policy change. Change a policy, change a behavior – theoretically of any element of our IT infrastructure.

While first-generation SOA focused on simple message routing and security policies, the declarative model has come into its own in the Cloud. When we say the Cloud operational environment is fully automated, what we mean is that the consumers of the Cloud may control every aspect of the Cloud declaratively – either via user interfaces or through APIs. Hard-code capabilities that change infrequently. Shift all dynamic behavior to the policy metadata.

Policies, of course, are the technical foundation of governance, which ZapThink defines as creating, communicating, and enforcing the policies that are important to the organization. And while many policies constrain and drive human behavior, the full spectrum of policies in the enterprise go from business-centric to technology-centric. As our technology improves, we’re better able to automate the communication and enforcement of policies, leading to a dynamic, technology-enabled approach to governance we call next-generation governance.

Idée Forte #4: Ubiquitous Cloud

Many people mischaracterize Cloud Computing as next-generation managed hosting: essentially, automated data centers on steroids. But in fact, there’s nothing in the definition of the Cloud that requires Cloud resources to be in data centers. On the contrary, if we free the Cloud from the data center, we can extend it to the entire Internet of Things (IoT).

This notion of the Ubiquitous Cloud is far more powerful than simply an extension of a buzzword, or it wouldn’t be an idée forte. What the Cloud brings to the IoT is the notion of user-driven automated provisioning of virtual resources. The IoT no longer consists of static endpoints. Instead, we have a way of provisioning, managing, and deprovisioning them that can potentially help us solve the knottiest of IoT problems: how to secure it.

We’ll never find our way out of the IoT security morass, however, until we take control of our identities – and by “we,” I mean the users of technology to whom those identities belong. After all, our identities don’t belong to the credit reporting bureaus, NSAs, and Facebooks of the world. They belong to us. We must develop the technology – and the will – to treat identity itself as provisionable Cloud resource.

Idée Forte #5: Human-Driven Semantics

ZapThink likens today’s semantics challenges to the pot of gold under the rainbow: seemingly within our grasp, and yet always just out of reach. True, there has been much progress with standards like the Resource Description Framework (RDF) and innumerable semantic models for every industry and governmental domain on the planet. But we still don’t have a clue how to build technology that seamlessly automates semantic interoperability beyond simple, specific situations.

The problem, of course, is that semantics is context dependent. Human meaning is inherently vague and ambiguous, and those vagaries never resolve themselves until we focus our communication on a particular context. To address these challenges, standards efforts have sought to strip all vagueness and ambiguity out of language in order to give our computers a basis for communication. But in so doing, we lose the subtleties of human meaning so important to the way people communicate.

The only way we can achieve real progress with semantics is to reverse our approach. Instead of trying to shoehorn human communication into the world of ones and zeroes that characterize computer interactions, we must embrace a human-driven approach to semantics. Give up on championing impossibly rigid data models. Instead, allow for separate data domains that are loosely coupled from one another. Instead of requiring strongly typed schemas at runtime, allow for loose typing that encourages flexibility in the representations of data. Underspecify at design time whenever possible. Embrace differently structured data. After all, we don’t serve our data. Our data serve us.

The ZapThink Take

As with all powerful ideas, these idées fortes are works in progress. If anything, they bring up more questions than answers. Yes, we’ve made substantial progress so far this century, and hopefully ZapThink has been a part of that success. But there’s much more work to do.

As with all good endings, this one is actually more of a beginning. These idées fortes are starting points to ongoing discussions and ongoing research. At the center of ZapThink 2020 is the principle of continuous transformation. You ain’t seen nothin’ yet!