Disclaimer: This series is made possible by Smart eTailer Technologies commitment to "help innovators succeed through the relentless pursuit of efficiencies".
Daedulus is the platform built by, and upon which the B2B and B2C SaaS products offered by the sponsor are hosted. As the Principal Solution Architect, I have been invited to share with the wider community details of a journey we made, the benefits we realised and the approach we took primarily to manage the complexity of maintaining a reliable distributed system.
Introduction
We work in a creative industry, continually searching for better ways to help others optimise their daily lives. We are enablers. Advancements in, and the correct application of our technologies can open doors for brilliant minds to step through and hopefully make the world a better place.
It's quite a responsibility and sometimes we can all be guilty of losing sight of the bigger picture; endlessly looking to add the latest and greatest to our toolbox in an attempt to discover better ways of working.
Our relentless search most certainly has merit, but after having picked up and then dropped so many 'revolutionary' technologies over the years, I wonder if we actually reached a saturation point long ago; 'old' often repackaged as the new 'new' for the next generation to buy. If so, let us take a moment to reflect, and perhaps take inspiration from what many of us already have.
Microsoft Excel has been with us for more than 30 years and could arguably be considered one of the most important, successful software development platforms ever written. It brings event driven, functional programming to the uninitiated and every day, empowers millions of business people to develop their own programs. It's inexpensive, scarily simple to use, reliable and remarkably capable.
Perhaps one of the reasons it has proven so popular could be that it brings the Business Expert as close as possible to the Developer by making it much easier for them to be one in the same?
The Agile Manifesto popped up around 20 years ago to make a few observations and suggestions as to how our development efforts might be better served. In part, they too suggested we aim to put the business experts at the heart of the development process with the main focus being on improving communication. I've most often observed 'agile' energy being spent trying to transfer domain knowledge to programmers as they 'iterate'. While not explicitly written, I hope it is not unfair to represent the signatories of the manifesto as having suggested that while there are undoubted trade offs, likely it would be best for the practitioner to take on the cognitive overhead of picking up the missing expertise ... for this is why we have iterations, and must accept we'll always know more at the end of a project than at the beginning?
Interestingly, I've never witnessed anyone try to do it the other way around though, and I find that incredible given the obvious propensity for development talent to come and go so quickly. I'd imagine the most focused, rooted cog will nearly always be our Domain Expert, so what is stopping business giving them the knowledge to write the programs they need?
Domain Driven Design is another example of a paradigm with similar ambition, and there are numerous others all apparently gaining traction. What I find interesting about DDD, is that it identifies that domain experts are likely to be very busy people who are basically keeping the business going. Perhaps therein lies the answer to my earlier question ... they simply don't have time to constantly keep abreast of hundreds of different short-lived technologies; their time is better spent elsewhere while you waste yours?
While it is unfortunate so much 'Agile' process and fake-expertise has popped up over the years and tarnished the movement, I'd hope we can all applaud the original sentiment of the manifesto and practices such as DDD, for communication failures undoubtedly lead to inefficiencies and quite often the inability to realise full value.
Personally, I'm not sure I buy the whole Domain Expert thing; perhaps she's a bit of a fallacy for most of us? If so, are we really practicing what we think we are?
As someone who tends to operate in the space between techies and business people, I'd observe that the likelihood of finding a Domain Expert is about the same as finding an expert programmer. Sure they exist, but they are by no means everywhere and by definition must be declining as a percentage of the industries overall growing population. Indeed, I'd respectfully suggest most of us are now just trying to figure stuff out as it comes along, rather than knowing exactly how/what to do at any given moment? Perhaps this is why we all need to "embrace change" so much? A relatively immature industry that operates empirically and comes with a high barrier to entry doesn't sound particularly optimal and this gives me hope that there is much opportunity for improvement still waiting to be discovered.
So 20 years on from the early adopters and there is plenty of evidence of both success and failure. DDD is certainly gaining more traction in our brave new Microservice world, and perhaps we'll look back in 10 years time and see a similar picture there; experts succeeding, others failing. Unless we have a plethora of domain experts (business and development) at hand, can any development process that revolves around such a premise ever reach terminal-efficiency, or will the paradigms that look to embrace change so much, dog-food?
I ask these questions not knowing the answers, and quite open to discovering that the world I have been exposed to is very different to that in which you operate. Ironically, if I'm going to, I'll probably only understand that when I get to the end of my journey.
So I return to one of my original thoughts ... what is stopping business giving them (the business experts) the knowledge to write the programs they need?
Is it us? Have we made stuff far too complicated for most use cases?
What if we turn 180 degrees and, much like Excel, succeed in taking away the barriers that are stopping the Domain Expert becoming the Programmer? Would this actually free up the techies to solely focus once again on their domain of expertise; the place they can add most value?
Project Daedulus is an ambitious attempt to take much of what makes Excel so incredibly useful and apply those learnings to less obvious domains. We have not built distributed spreadsheets, we are building a cloud native platform upon which business experts describe their Information Systems and simply let us take care of all the difficult technical stuff to 'make it work'. As experts in distributed computing, we believe there are incredible efficiencies to be realised if we can solve the common technical problems faced by many 'new' development efforts, and empower businesses to start their development efforts way ahead of ground zero.
I'd like to talk a lot more about the technical side of what we have tried, failed and succeeded at, but only if there is an audience interested in hearing it. We don't have all the answers and continue to relentlessly pursue yet more efficiencies, but if you would like to hear the detail, please add your Like/Comments and I am certain our sponsor would be more than happy to share with you.
Top comments (0)