Revenge of the Spaghetti Monster
Mar 18, 2015
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 were running on one machine. It’s, typically, the Classic Spaghetti recipe that we see a lot from the 1st platform of Mainframe and Terminal.
From the Spaghetti ‘un-architecture,’ as we would call it nowadays, we went to the layered n-tier architecture. This matched the 2nd 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. It’s a clear separation of functionalities and focus, but still often too tightly integrated for real remixing, cross channel.
Now we enter(ed) 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 our own Sogeti VINT Labs, and Gartner calls it: “Nexus of Forces.” This is a 3rd platform (as IDC calls it) 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 that we should start with to know if anything can connect to anything?
About a year or two ago, I stumbled upon Node.js, which triggered me on to 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 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 how 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. Such networks can even have hierarchy by including other networks, as if those sub-networks were nodes themselves.
Networks like these are not tightly integrated and are not stacked in layers. Networks like these are loosely coupled by clearly described interfaces, called Application Programmer Interfaces (APIs), which are remixed into solutions by third parties. These include all kinds of solutions that the creator of the node didn’t even have to think about … APIs to build anything. API is the new App, so to say… quite literally, in this case.
The 3rd 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 APIs enough to keep a clear overview and nice separation that we could even start to call architecture?
The key is to keep track of versions and dependencies, something we tend to forget in our current landscape as well. Making meshes of nodes requires a good insight into the dependencies and usage of services. This is needed far beyond your own organization’s borders. Insight is necessary in 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 widely enough to become the foundation of the 3rd platform design guide and prevent the ‘un-architecture’ of the spaghetti of the 1st wave.