I attended a talk in 2017 where the speaker reminded us that some of the most resilient, dependable and performant software that powers business (and not just the internet), was written in the Cobol programming language over 30 years ago. He was speaking specifically about banking applications that move money around in serious volumes. He pointed out that these applications had one interesting thing in common: a commitment to modular design.
The goal of that speaker was to raise the alarm. He was seeing a dangerous trend away from good design when it comes to the platforms that power our businesses. The good news, in his opinion, was that we collectively knew the better path, but we had wandered off of it. Now our software resembles what has come to be called "balls of mud". If you have ever had to untangle a big ball of string lights or the dozens of cables heading into or out of your computer ... you get the picture. Paralyzing complexity is ultimately the result.
Platform Complexity: How Did We Get Here?
I think it is safe to say that, somewhere along the way, we abandoned the tried and true design principles that, compared to today's platforms, produced software that performed better, was easier to change and maintain and that gave it a longer lifespan.
The Opportunity
- Deliver solutions at 10x the velocity and a fraction of the cost
- Demystify technology and empower business teams
- Design solutions from the customer-inwards
- Leverage data and enable fact-based optimization
- Optimize daily
What happened to the way we design software and build platforms?
The "web" happened. Digital transformation happened. Technology labour shortages happened. Perhaps the most notable cause has been what we call the emergence of of the "Business/IT Divide". More on this later... but if you buy our point-of-view that IT and the "business" are separated by a wide gulf - then it makes it easier to understand what went so horribly wrong with many of our platforms. More importantly,finding a way to bridge this divide will help us get back to better technology, higher velocity and better agility. Let's add to this the prospect of getting back to affordable technology initiatives - development efforts that can be accurately estimated that don't make us feel like we have to dip into a bottomless pot of money.
Opening the doors to productive collaboration between the Business and IT - and helping these teams build exceptional digital experiences over top of a rich layer of automation is what brought the Korio team together. We believe that the technology side of our businesses can be done better, faster and cheaper. We have witnessed a distressing rise in budgets - usually brought by consultants - and we want no part of that. We formed our group around a mission to empower Marketers, Product Teams and Operations to take back control of the business - in the name of the customers they serve. We want the members of these teams to become comfortable with technology through a healthier partnership with IT.
We have some work ahead of us. To use the tired analogy: we think it might be time to hit the reset button.
Over the last decade it feels to us that the exponential increase in demand for applications has resulted in a massive influx of developers into the typical enterprise. Pair this with a tremendous amount of pressure placed on our developer teams by our colleagues in Marketing, Product and Operations (aka "the business"), and you have a recipe for bad software.
The engineers that, in the past, would have been given ample time to architect an elegant solution, were simply overwhelmed. This situation wasn't helped by the fact that the herds of new developers coming into the labour market were all about pounding out web pages as fast they could type.
Let's be honest. Corners were cut.
Building the Ivory Tower and Deepening the IT/Business Divide
The biggest downside of all this - if you look beyond the offense we may have caused the technology purists among us - is the crushing gridlock it has caused. Our colleagues in the customer-facing parts of the business - the folks with real revenue targets - are not loving this. They simply can't get the software they need to keep up with the rising bar of customer expectations.
The implications of this apparent state of gridlock, unfortunately, is that we in IT tend to fall back into a defensive posture that, very quickly, turns us into purists in the worst sort of way. Brick by frustrating brick, we build our Ivory Tower so we have something to hide behind.
At Korio, we are deeply concerned about this growing divide. We focus exclusively on helping companies get better at digital - particularly businesses that are struggling in their digital channels. Usually, to these companies, fixing the mess that is their current plaform will also seem prohibitively expensive. The companies most in need tend to be mid-sized or larger. If your business is a smaller startup or was purely digital from the outset, then you probably won't feel quite as hobbled by these technology "balls of mud". In fact you are probably sitting in a position to take market share from the gridlocked mid-market players because you probably haven't had enough time (or money) to create much of a mess.
The Challenge
- Deep divide between "the business" and IT, and getting deeper
- Dangerous abdication to IT or consultants when it comes to "all things digital"
- Paralyzing complexity in our platforms
- Over-fixation on technical elegance with virtually no pay-back
- Platform designed with the end customer as an after-thought
To us, it has become apparent that our collective approach to building technology platforms needs a re-think. Digital Transformation seems to have given us this opportunity for a do-over. What has become equally apparent is that the first few steps in this transformation need to be done right. If we get it wrong - and we see a lot of this - you may actually be heading right back into a deeper and more troubling IT/business divide.
The popular but often misguided approach to transformation is for the front line folks, who are closest to the customer, to become deeply spooked by technology just when we need them to step up. This fear causes significant detachment from transformation efforts and, ultimately, dysfunction. In our experience, it usually amounts to ceding far too much control to the IT department or consultants. This is disturbing for a number of reasons, not the least of which is that technology should be feeling more accessible these days, not less. Those of us in IT are complicit in this - perhaps unknowingly - because we are just trying to recover from our own tangled-string-of-lights problem. Our typical response - though technically elegant - usually amounts to an over-correction. The response is usually one of over-building something in-house or licensing and integrating a long list of 3rd party applications. Both approaches risk whipsawing us back into a state of equal complexity and business paralysis.
To be fair, in general, we are seeing a response from technologists that acknowledges the importance of better architecture but that often comes with a pedantic interpretation of how to get back to a better technology foundation. We urge caution here. The one aspect we can all probably get behind, however, is modularity. If we are truly struggling with transformation (or anything, for that matter) breaking things into smaller pieces seems to make a lot of sense. Related to this point: if you have ever had the good fortune of producing some work-product through a truly Agile approach, you will understand the near-perfect results that can be achieved by keeping things small while working incrementally and iteratively.
Unfortunately modularity does not work well for most consultants, integrators or purveyors of ERP, CRM or any other mega-system. Nor does the the notion of being incremental or iterative. They simply can't make money in a world made of small solutions that are incrementally devised, built, deployed and optimized. As a side note: we as consultants need to be better. We need to find a new business model that doesn't depend on large black-box contracts that leave us throwing solutions back over the wall at project conclusion. If we do it right, the tech isn't that hard and clients that are committed to winning in digital channels should have the chops to do it themselves. Our job as consultants - and leaders in the business - is to enable the teams that are closest to the customer - giving them full ownership and confidence.
The Better Response: Architect From the Customer Inwards
Again, in order to break the gridlock that makes our technology unmanageable we do need to go back to principles of modular platform architectures. There should be no question about this.
For now, if you like to refer to these as microservices, that will work. Unfortunately, microservices, as a term, carries a lot of baggage - and this baggage has proven to be dangerously distracting.
The most notable baggage, in our opinion, is caused by that overly-pedantic interpretation of what actually goes into a microservice. Technology purists will fixate on, as an example, things like component isolation all the way down through the microservice stack. We see this as missing the point and, from a logical standpoing, technically impossible... but still we seem bent on trying.
In our opinion, this narrative on how to build the best modular and elegant platform has been dominated by the technologists. We think this needs to change. To us, the benefits of going back to modularity and getting to microservices needs to be elevated to a business strategy. It is that important.
In our experience, when transformation is done right, it is because it starts with the customer, their journeys and then the optimal design of those journeys directly dictates the technology architecture. Rarely do we see this done with the level of continuity or connectedness that is necessary to introduce differentiating and sustainable digital capabilities. Sure, there will be an initiative that maps customer journeys and that seeks to understand what a truly differentiating journey looks like. Usually these journey maps are committed to paper and Powerpoint. Excitement ensues and then... nothing. It truly doesn't have to be this way.
Customer journeys or flows that create value for customers and stakeholders gives us - without exception - the best way to think about how we architect, build and maintain our platforms. If your colleagues in IT feel differently - push back. This is too important.
We have noticed that one of the side effects of the complexity of our current systems and the purist response is that we intimidate and shut-out our partners in the business. It doesn't have to go this way and, if it does, it usually guarantees failure and another ball of mud.
Instead, commit to using customer value creation and differentiating journeys to drive the architecture behind your next platform. We will be posting more on this in the weeks to come.
Unleashing The Power of Your Business Architecture, Modularity, Small Autonomous Teams
At risk of putting too fine a point to it: building your technology from the customer inwards produces software that is easier to conceive of, build, measure and optimize. The elemenents of the architecture are named and designed around concepts that emerge from the voice of the customer and the language of the business - not the language of an engineer.
This idea is not new and it certainly isn't something we invented at Korio. Decades ago Eric Evans - who coined the phrase "ball of mud" -
saw the challenges of exclusively designing systems around the engineer's interpretation of the business problem. He created a
movement called Domain Driven Design
and sought to (re)establish business stakeholders as the "domain experts". He also impressed on us the importance of establishing
the language of the business as the basis for the technical vocabulary used to describe software solutions. At Korio we see the power of this idea and discipline
and we encourage our clients to apply it at every opportunity.
At risk of over-simplifying, here is how we do it.
The Solution
- Start with a Business Architecture that models the creation of value
- Introduce Small Autonomous Teams that own complete segments of those value-creating flows
- Invite technologists onto Small Autonomous Teams
- Build solutions incrementally and based on the Business Architecture
- Leverage modular design principles (aka "microservices") to break the gridlock
- Acknowledge that getting to a winning digital platform is not a project, it is a way of being
- Commit to data and fact-based optimization
First, we reaffirm with our clients that transformation, when done with truly modular components, can be done incrementally and inexpensively. Second, we work hard to convince their various teams that technology is not (and cannot become) an obscure Black Art. To combat this we create and empower Small Autonomous Teams - one per major segment of the value-creating flow of the business. Next, we give them the tools to map how value is created for customers. We call these Value Maps, but you can think of them as highly structured customer journey maps. Taken together, these maps form the centerpiece of what is being called a business architecture. Finally - and this is the magical part - we show how these maps become the software.
Imagine, for example, a Small Autonomous Team who owns the "lead-to-conversion" segment of the overall journey. When members of that team come in to work every day, their mission is to delight customers and drive up conversions. Now, appreciate the power handed to that team if their models of the optimal flows or journeys and related analytics can simply become the software.
This connected-ness and clear traceability from the customer to the business idea to working software is tremendously powerful.
The technology required to make this happen is actually not that hard. This is because the hard stuff has, over the last few decades, settled into patterns. Once you recognize these patterns you can leverage them to get to market faster. Our Small Autonomous Teams, including its IT members - must know how to recognize these patterns and how they simplify solution development. Above all, they must recognize and resist the tempation to "hand off" architecture and implementation to IT.
In our experience, abdicating your platform architecture to IT - usually over concerns about security, scalability and resilience - is going to cause problems. It will foil your efforts to position your optimal business architecture as the primary driver. You will lose that simplicity and clear traceability between the business idea and the solution. The cost of abdication is simply too high for virtually no benefit. Sure, security is critical - but the technology and standards available to us are also sufficiently mature that it doesn't need a magical architecture to make sure it works. In fact, we want way less magic in our platforms, particularly when it comes to security. What we have learned, the hard way, is that one developer's magic is the next developer's hell. The same holds true for platform scalability and resilience. These are largely well-patterned commodities at this point - particularly for those of us focused on the mid-market. Google and Facebook need some magic in order to scale, the rest of us almost never do.
At Korio, with the tools we give our clients, the journey-based models literally can generate 95% of the code required to bring your digital platform to market. This is because we worked to recognize the patterns and embed these patterns in modeling tools and code generators. No self-respecting software engineer wants to code that kind of boilerplate so these "low-code" solutions should make sense to everyone. We should have better things to do than re-thinking and re-coding how someone enters a birthdate or picks a product from a list.
Even without those tools, the models can be conveyed into an architecure that can be built out effectively and in a manner that, with care, can stay connected to your business architecture.
The real power of modular architectures designed around customer journeys comes just after initial launch. After launch, and with the proper analytics stack, the team starts to see the true power of integrated metrics - a platform feature that is facilitated by desinging measures around the actual value-creating flows of the business. This data both empowers and brings focus to these teams so that they can fully own speedy and fact-based optimization of your systems.
Once your Small Autonomous Teams find their rhythm and continuously work to optimize their modest slice of the overall system, you will see that modularity brings an imrpressive level of simplicity to your digital existence. Simplicy, in turn, results in a system that is much easier to maintain and improve. Simplicity also breaks the stranglehold that consultants or unaffordable and hard-to-retain engineering talent may hold over you.
Good luck on your big journey to going small.
