Enterprise Architecture (EA) is serious business designed to analyse, design, plan and in turn implement the findings to successfully execute on business strategies. It is about defining a symbiotic relationship in how information, business and technology will flow together.
It’s a must for any business serious about keeping up with the changing tides of technology. These tides owing to paradigm shifts in our exciting technological landscape as we dig deep to find efficiencies in anything and everything. The ownership then resting on the broad and bold shoulders of our technology integrator’s to build applications fast and reliably, but how?
One such paradigm shift has been the case for Microservices, an architectural style that fosters building a software system as a collection of independent autonomous services (developed, deployed, and scaled independently) that are loosely coupled.¹ Unlike Monoliths, services don’t share the same execution run time, instead leveraging containerisation from Docker | Kubernetes.
All of which is a stark difference to the monoliths which have existed in our Banking and Government sectors for 30+ years. Where a change in one line of code can take down a whole organisations intertwined, highly coupled service offerings, ouch. The technical debt caused by monoliths overtime, lack of agility and costly deployment cycles makes one understand why, in modern software architectural circles, microservices have controlled conversation.
So why was all of that important?
Well, the world of Distributed Ledger Technology (DLT) is touted as forward thinking, adaptive, streamlined but I argue this vehemently in regards to how project teams are going about delivering on their promises — they are monoliths. Stuck without a clue how to achieve the buzz word salad they defined in their whitepaper, and made far worse by the marketing material which hyped it beyond technical recognition.
You see, FinTech’s have been gaining incredible ground on the incumbents because they are nimble, face less regulation due to size, and don’t have expensive assets to maintain. Exactly what one would assume a DLT based project team situation to be — sleek, slick, and nimble. Chopping at the heels of the SAP’s, Microsoft’s and Amazon’s of the world with cash to boot.
However, all that glitters is not gold. It is the above combined with my experience consulting a number of projects which has lead me down this dark and dreary path, fighting to define use case first, searching for a viable business model, all in all asking project teams to walk before they try run. It has been as if once the Initial Coin Offering (ICO) capital raise finished they thought they were done, they had achieved greatness. Well, they were wrong.
“It is at this very moment reality sets in, development teams formed and the whitepaper which was the glittery shining light that promised architectural aristocracy, world leading tech, rainbows and unicorns mounted on the top of artificial intelligence — was nothing more than a black hole of assumptions, which became unanswered questions and now just brave faces.”
The advent of Distributed Ledger Technology (DLT) has been more than just a technological revolution. Disparate industry verticals have found a nexus, forming alliances in pursuit of a utopian future where the concept of ‘trust’ is unequivocally embedded irrespective of the rationality of the actor in question.
It is a humble yet significant testament to 40 years of research and development. A cumulation of computer science and economic theories to which all now form part of our everyday lives without notice.
Unashamedly many tout the outcomes of such innovation and achievement as the panacea which will bring Governments to account, financial servicing to all two billion left unbanked, power to the contemporary anarchists and libertarian schools of thought and of course the ability to breed crypto kitties. It comes down to this, the ability to not only ‘trust’ but independently ‘verify’.
Hint: only one above is true at present, the rest, end state goals for the individual promoter of each train of thought.
So irrespective of whether we reach the pearly gates presented at many conferences by the exceptionally enthusiastic, there is undoubtedly success across a number of facets of Distributed Ledger Technology projects we must acknowledge:
The continued exposure of the untamed hyperbole has at least brought about awareness while we continue to push toward adoption of cryptocurrency. It’s the one use case which is undeniable, the ability to transaction globally, in seconds, for less than cents, on a network which hasn’t skipped a beat in over 10 years. No bank can say the same for their services like Bitcoin can, it’s unparalleled.
A large number of jobs have been created as part of this economy, remote work featuring very commonly. A technology based on distributed, decentralised principles with companies following suit enacting Conway’s Law cue ConsenSys.
The sheer volume of project teams which has risen from the success of Ethereum (Smart Contracts) and tokenisation has lead to incredible amounts of research in computer science fields including: cryptographic primitives, distributed networking, game theory, so on and so forth.
Start up’s are inherently nimble, yet they lack the key ingredient to getting off the ground — cash. As part of the token economy that has formed, a by product has been the ability to raise capital, quickly.
Though I am against the way Initial Coin Offerings (ICO’s) have fueled greed and scams, paid for by uneducated speculators wanting to make perceived ‘easy money’ on secondary markets. I do support the concept of the ability to ‘raise’ through a raft of capital alternatives — in a financially, and time sensitive manner.
So where are we going with all of this well…
Irrespective of the wins defined above, the current project teams flooding the Blockchain arena can only currently be defined as insane, following a cookie cutter approach on the road to…something.
“Insanity is doing the same thing over and over and expecting different results” — Albert Einstein
These teams follow the same sequence of events time and time again forgetting they were funded to build a product, a service offering. Not to please uneducated speculators trying to make back last months pay cheque on secondary trading markets. They focus on exchange listings, more they do developing a viable business plan.
A plan which nearly in every project has none of the following:
This one hurts the most, the industry formed on open source code, and therefore without continued business (revenue) in some form whether it be consulting to assist integration or a commercial off the shelf (COTS) offering. They have nothing!
The whitepaper defines a token, with no intrinsic value, and a poorly formed economic model, yet no sight of where once the kitty runs dry they will be funded from to continue development and expansion.
I can guarantee it will run dry too, flying around the world to “network” isn’t exactly cheap.
There is more to defining the ICT development than selecting a language to develop in and making it known. Again, forged on transparency not one team has explained their approach to get from A to B in depth or even consideration for:
We are stuck as a community, yes WE!
This community was forged on bringing together unknown parties to be collaborative, to define and build technological services which aimed to improve business processes, gave back human rights to those without identity, and much much more. So whats the way forward…
We are brought up to understand that making mistakes is OK, and it is! We just need to own them. We cannot continue to give praise where it simply is not due, we need to be critical to tease out the kinks and improve the outcomes for all.
This isn’t about success of just one team, or many, it’s about the collective industry and how the broad use cases could improve a number areas of business and human livelihood.
It’s time we stopped teams from biting off more than they can chew. You see as much as we are taught to make mistakes, we are also taught to have dreams, a vision of the utopian outlook of me, of you. There’s no faster way to stifle innovation than to say you can’t do it. But there is better ways we can support the success of such and create the collective mechanisms to drive home delivery.
The teams currently are funded completely upfront, this needs to change. As per the series funding in an Initial Public Offering (IPO) model, it requires a business to meet ‘goals’. If they are successful in achieving the goals, then they have reason to ask kindly for more, to go bigger, to get better.
It’s a simple yet effective way of keeping teams honest, ensuring they budget, and have to run a BUSINESS not just a frat house of wining and dining across the globe hidden behind Medium posts like this stating success is around the corner.
The same thinking for piece meal funding, is how white and yellow papers should be posed, providing transparency of the stage gates in greater detail. To show the thinking, then continuous improvement via blog’s and marketing about the changes as they occur in thinking, and market research comes to light.
Then let’s move the thinking to development teams, we need the skills within not just consulted to — skin in the game kind of thinking.
They need to take a greater architectural approach — actually stop and think. Orchestration, Management, API, Proxies, Monitoring, Testing, the whole kit and caboodle delivered at a MVP level prior to funding. How will we achieve the symbiotic relationship between business, data, and ICT as we spoke of earlier?
The yellow brick road currently being followed by many, is simply not a recipe for success. A big name individual, a grandiose budget and some marketing magicians simply will not develop revolutionary tech and the suggestions above to solve such are just that, they are not comprehensive or conclusive, just a trigger point to start a greater discussion.
There is always ways we can improve, I am of the belief we are really close with how funding, marketing, and the ‘start up’ elements come together to being standardised as a viable way forward for other projects to follow.
However, we have considerable ways to go when it comes to the actual product, teams intend to deliver. We need more real world accounts from architects, developers, CIO to CTO’s who have walked this fragile path. Maybe some candid accounts combined with some actual legal regulation will deter those with just money in their eyes. As DLT tech has drawn us all in, but it’s cheeky little secret is that it’s complex — just like Microservices are to get right.
The ease of capital raising has brought a number of let’s say ‘unprepared’ teams into the spot light. It’s blatantly obviously, all that glitters in this space isn’t gold, but that’s ok. Rome wasn’t built in a day, and neither will the future of payments, identity and supply chain management.
By at least taking a piecemeal approach we inadvertently define projects in bite size chunks, microservices one could say. A service for a function, owned by a team, independent of others, yet required for the end to end flow to be successful. The greatest challenge of microservices is communication between the functional parts, that’s called team work from a project sense. We are all part of this team!
Step by step, I will continue to support, develop tools and content, and provide candid advice to those taking the leap. Let’s support each other, to now get the second part of this equation right. To be that microservices team building collective greatness.
Thanks for reading,
¹ Microservices for the Enterprise — Kasun Indrasiri et al. 2018.
Create your free account to unlock your custom reading experience.