Revenge of the Spaghetti Monster

The software that was created in the beginning of the computing era wasn’t really structured and built under architecture. There were no guiding principles and everything was very tightly integrated. Data, logic, interaction and view all running on one machine. Typically, the Classic Spaghetti recipe we see a lot from the 1^st platform of Mainframe and Terminal.

From the Spaghetti un-architecture, as we would call it nowadays, we went to layered n-tier architecture. This matched the 2^nd platform of Client and Server very well and was called Lasagna with reference and respect to the first paradigm. A nice separation between persistent storage centrally on the server, with some business logic on top, was interacting with the client view and manipulation. A clear separation of functionalities and focus, but still often too tightly integrated for real remixing cross channel.

Now we have entered a new paradigm of interconnectivity often referred to by Cognizant as SMAC (Social, Mobile, Analytics, Cloud). Things (as in the Internet of Things) made it SMACT, according to Sogeti ViNT Labs and Gartner calls it: “Nexus of Forces”. This is a 3^rd platform (by IDC) of interconnectivity where we are not just meshing up some data to a view. We are mixing and matching any data and all kinds of logic from any source that could be used and remixed towards any touch point like mobile, web and desktop. And even further to other physical displays like car, TV and billboards. But what is the architectural principle we should start with if anything can connect to anything?

About a year or four ago I stumbled upon Node.js, which triggered me on two different aspects. For one it was amazing to see how far JavaScript stretched to become an object-oriented language for both client and server. But more relevant for this post: it was the name of this server sided scripting. Node. A node that was, and is, focused around an essential functionality. Limited, but very valuable.

Being small and limited by focus and functionality it is somewhat like the App is in relation to the more classical and typically bigger Applications. The Node is the tiny source or small interconnector in bigger and more complex networks. Those networks are built like a graph with Nodes and Links. Networks that can even have hierarchy by including other networks as if those sub-networks were nodes themselves.

Networks like this are not tightly integrated, are not stacked in layers. Networks like this are loosely coupled by clearly described interfaces, Application Programmer Interfaces. API’s to be remixed into solutions by third parties. All kinds of solutions that the creator of the node didn’t even have to think about. API’s to build anything. API is the new App so to say. Quite literally in this case.

The 3^rd platform is this mesh; it is this nested and interconnected graph with sub-graphs where everything is coupled, but only loosely. And based on clear interfaces. Now think of the links as spaghetti and of the nodes as meat. Are we back where we started? Or are API’s enough to keep a clear overview and nice separation we could even start to call architecture?

The key is to keep track of versions and dependencies, something we tend to forget with our current landscape as well. Making meshes of nodes requires a good insight in the dependencies and usage of services. This is needed far beyond your own organizations borders. Insight is necessary over all services across organizations.

True transparency and solid governance in an open, sharable and searchable format is mandatory for this to be valid as maintainable, stable mesh architecture. This can only be successful with an open standard, and that will take time to evolve and become adopted wide enough to become the foundation of the 3^rd platform design guide and prevent the un-architecture of the spaghetti of the 1^st wave.