Most Read This Week
Enterprise Cloud Computing
ZapThink’s Final Idées Fortes
The core architectural threads that have tied together ZapThink’s thinking over the last twelve years
By: Jason Bloomberg
Dec. 5, 2013 08:45 AM
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 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
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
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
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
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 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!
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads