Over the weekend my friend and industry colleague JP Rangaswami wrote an insightful post that pondered how we have gone about delivering on customer experiences as connected to our back-end capabilities. Specifically, he explored an issue that is increasingly challenging many of the large-company CIOs I speak with these days: That the present rates of change demanded of the accumulation of 20-30 years of legacy business systems is greatly exceeding the ability of our enterprises and associated software “stacks” to deliver on them, particularly as cloud, social, and mobile dramatically transform computing today.
The problem lies in our classical views of enterprise architecture and business architecture both. But JP puts it more poetically:
Development backlogs are endemic, as the sheer complexity of the grown-like-Topsy stack slows the process of change and makes it considerably more expensive to change. The stack has begun to fossilise, just at the time when businesses are hungrier for growth, when the need to deliver customer-facing, often customer-touching, applications is an imperative.
Which makes me wonder. What Tainter wrote about societies, what Shirky wrote about companies, are we about to witness something analogous in the systems world? A collapse of a monolith, consumed by its own growth and complexity? As against the simpler, fractal approach of ecosystems?
This fractal aspect of user systems, Web 2.0, and SOA is one that I deeply explored in the 2005-2007 timeframe, and my ideas on this even made the cover story of the SOA/Web Services Journal at one point. This is when we began to see successful, composite systems sprouting up “in the wild” that were eminently natural and highly successful, such as Amazon’s, Flickr’s, and many others. Innovative new open API-based businesses had definitively emerged and shown us — in fact, virtually proved to anyone willing to observe — that business/technology ecosystems could be routinely produced that were far more successful than the ones virtually any traditional business had managed to produce for itself internally with methods like SOA. It was clear something important and new was happening and we tried to learn from it.
The signature lesson in this time period was that being “in the business” of ecosystems, at multiple levels, was the key to resilience, growth, and sustainability. It’s still a far cry from how most organizations are structured today, but I do see the first hints that this is starting to change. Companies like Best Buy and Sears have been getting the message among the old guard firms and looking at integration, partnership, and engagement as an open network activity.
The Web has also shown us that complexity, as important as it is to address and resolve the many inherent vagaries of dealing with the real world, is largely the enemy, whenever it exists needlessly. Our assumptions of where the complexity should be, in the transports for example, was wrong. It was in the ecosystem itself and we paid dearly for half a decade (and running) based on that misapprehension. But we’ve learned. SOAP usage has almost completely shifted to REST, complex WS-* stacks have largely moved on to simple standards and methods like Web-Oriented Architecture.
But technical discussions obscure the very important truths about what we’ve learned in the interim between the “aha” moment when we realized that what was happening so successfully “out there” was something that would make us just as successful inside our organizations, for internal and customer-facing needs both. After all, this holistic ‘integratedness’ — usually triggered via our connections to the Internet — was a part of our businesses increasingly and we simply had to realize this and engage as Internet natives. But back then, Andrew McAfee worried that focusing on the plumbing was the wrong emphasis to have on the exciting changes taking place, and he was largely right from a communication perspective.
However, building fractal architectures that addresses the old and the new isn’t as easy as just deciding to cast off the old, less effecive ways, as JP notes:
What I’d established in my own mind was a growing belief that the issue was to do with rates of change and costs of change. Vertical integration paid off when the rate of change was low. Networked small-pieces approaches paid off when the rate of change was high.
We are clearly living in times of much greater rates of change. Unfortunately, the old systems, the old architectures, the old business “stack” is often running the core of the business. It’s usually deeply vertically integrated, and not made of small networked pieces, loosely joined that are truly agile, deeply harness innovation on the edge, and turn IT into a profit center instead of a cost center.
So, while I have a lot more to say about this, because I believe that social business context will be at the root of the future of our how we design our products, services, processes, and workplaces, below are a few basic rules you can take away that if you stay true to, can indeed help you make the transition to the future. Note that customer and worker experiences are outside the scope of this, this has more to do with the new business stack below the social layer:
4 Ways to Create Sustainable Business Ecosystems
If resilient, networked, recomposable, open business capabilities are the future of business and IT architecture, getting there then requires a substantial change in stance:
- Open Your Business Stack. To everyone, internally and externally, generally in the order of the systems and data that are most often requested for integration. Make it easy for anyone to onboard themselves and use the simplest and most egalitarian technology possible to deeply connect the world to your business. Self-onboarding is crucial because it enables the killer asymmetric business advantage of systems that respond to external engagement best: Export most of the change effort to outside your organization and impose it on those that wish to participate and integrate with you. Enterprises that close the “clue gap” with Big Data will have an enormous advantage.
- Go Into the Business of Ecosystems. Stand behind your open supply chain: Invest in it for the long term, market it, evangelize it, support it, and stand behind it like your customers — again, internally or externally — will be building world changing products and services from them (if you do this, the track record is that they will.) Be fair and generous with your IP and enterprise data; you are under-utilizing it by several orders of magnitude until you do this, leaving much or even most of the potential of your business on the floor. Worse, until you treat it like a business, you won’t get external contributions to enrich your ecosystem that will drive down the cost of change while greatly increasing the velocity of new solutions and local adaptations.
- Begin Fractal Reconciliation of Your Classical Systems. While hanging a trendy Web API off an ancient COBOL accounting system might be a step in the right direction, long-term success will mean going well behind the API. The existing business/IT landscape must be converged and rationalized so they themselves are made of “networked small pieces” that are faster to change as well as more resilient and responsive to being so much more connected (and therefore useful and valuable) to the world.
- Spin Up New 21st Century Business Models. All new possibilities, many of which will be foreign to non-digital native firms, are reachable once you have created a fractal enterprise stack. Dominating classes of data, metered business knowledge, all new monetization methods, and more become possible once the three transformations above have started.
Unfortunately, after having advised and directly assisted many large companies in doing much of what I’m describing here over the years, it’s clear that most organizations are at a major disadvantage in making this transformation. The organizational will required is actually quite low, since most of this is fairly easy to do now with cloud technologies, increasingly capable technology partners, and the latest development stacks. Instead, it’s the understanding of how important it is to kill excessive complexity and focus on ways of thinking about business and technical architecture that will propel companies into bright futures.
We must leave behind vertical integration and radically collapse the size of our seams (APIs) in our businesses, while radically increasing the number of useful endpoints such that we look at them as the very fundament of our enterprises. The benchmark for success is how many others are depending on your ecosystem for their own success. Starting now, the activity in your organization must be focused on optimizing for growth of this number. That is the only way we’ll ensure we’re building businesses that are the most relevant, meaningful, and valuable to us going forward. The enterprises that don’t simply won’t survive in their present form. I believe that much is at stake here. Unfortunately, the “cultural gap” John Hagel wrote of back when this conversation started between the enterprise crowd and the Internet crowd is still much too large and is still hindering the move forward for many organizations.
I look forward to continuing this discussion and exploring just how much we’ve recently learned about the future of business and enterprise architecture.