The Gravity of Decentralization
Designing business architectures (models & systems) is an increasing challenge. Centralized business architectures are a legacy of the industrial era. But the recent downturn has revealed new decentralized systems that promise to enable new business models and evolve the old. We are just beginning to explore the practice of decentralization and the new gravity it creates.
This post explores key benefits of cost and risk reduction:
- Capital Expense: Smart Build vs. Dumb Build
- Operating Expense: Centralized Complexity vs. Decentralized Service
- Market Risk: Centralized Liquidity vs. Decentralized Standardization
- Operational Risk: Centralized Security vs. Decentralized Defense
Identifying these benefits should help understanding how to achieve balance between centralized and decentralized gravitational forces.
Capital Expense: Smart build vs. dumb build
Centralized infrastructures (bandwidth, storage & processing) require significant up-front capital investment, justified by "smart build." They rely on "smart" forecasting of capacity requirements to determine what to build in advance of immediate delivery (spot markets). But in absence of forward markets (like futures, only over the counter) to lock in future prices and quantities, and only rudimentary vehicles to pre-sell capacity -- determining requisite supply is done without market data. In addition, IP traffic, which drives investment in capacity to support it, is notoriously bursty and diverse. Sheer complexity and absence of market data make forecasting and planning an art rather than science.
Also, centralized infrastructures rely heavily on economies of scale in both system economics and business models. The upgrade path isn't granular, at best its at the line card level for routers and servers. In the economics of bandwidth builds rights of way and spectrum licenses are the largest costs. This cost is also the largest speculation of future capacity, both in the lag time until monetized and the volume of capacity it represents. Spectrum speculation also relies on the pricing of an intangible asset, driven by market participants compelled to bid to maintain competitive in a market they already sunk significant costs in. Spectrum speculation recently resulted in $150 billion of spend – before the investment of another $150 billion in tangible asset infrastructure; larger than the addressable market.
The second largest cost, digging the trench are the largest costs, compels telecoms to lay as many fiber strands in the trench as they can. Remaining dark. Supply and demand cannot be balanced, and excess capacity inventory is a service requirement. The result is continual glut or failure to meet customer demands. This is fine when capital markets appreciate excess capacity inventory, but otherwise its punishing model.
Dumb builds of decentralized infrastructure do not rely on central planning/forecasting. Capital risks and burdens are pushed to the customer: forecasting individual requirements, upgrade/migration paths and up-front investment. Intangible assets that only serve the purpose of creating barriers to entry for competitors, such as spectrum speculation, can be avoided costs through models such as Open Spectrum.
In addition, decentralized infrastructures can be more granular. Manufacturing of equipment for these infrastructures remains centralized, but there is less risk in the model. Forecasting a diverse network's requirements is several orders of magnitude greater in complexity than forecasting customer units. Manufacturing systems are also built to take advantage of economies of scale, scope and speed. Capital markets understand the mature model of manufacturing capacity & inventory to more adequately assess inherent risks.
Operating Expense: Centralized Complexity vs. Decentralized Self-Service
Centralized business architectures cannot scale when it comes to providing service. Centrally planned automation of functions and processes become rapidly obsolete in a turbulent environment. Inevitably to maintain service, people are thrown at the problem. And people don’t scale. Large centralized IT administration, network administration, customer support centers result in large Sales, General & Administration costs (e.g. 25% of revenues in the telecom industry). What’s worse, service is significantly impersonal and these jobs strain the limits of satisfaction, creating a dysfunctional cycle of quality degradation.
Decentralized business architectures empower customers to serve themselves and provide communities of support. Obviously this results in less cost and enables scale. But the power of self-service, whether for purchasing, provisioning or support cannot be overstated. Provided self-service is simple, providing otherwise internal information to the customer as well as control instills trust and satisfaction.
Market Risk: Centralized Liquidity vs. Decentralized Standardization
As we learned in developing the first B2B marketplaces, liquid emerging markets take time to develop. Marketplaces and market makers must bear significant risks to establish a market. Despite the benefits by design, providing centralized alternatives to the entropy of existing relationships is an inorganic development. Before centralized markets take hold, competing standard alternatives arise in decentralized fashion. Over the counter markets of buyers and sellers with existing relationships transact directly at first.
The role of decentralization in market development is the creation of standards for transactions as a bridge to centralized mature marketplaces. Creating standardized definitions of price, quantity, quality and contracts for goods accelerates over the counter liquidity and creates pockets of price transparency. As the market unfolds, conversations drive convergence of standards and invites participants organically.
Physical liquidity grows and demands risk management in the form of forward and futures markets. These markets demand centralization for both price transparency and liquidity to prevent manipulation The point of describing how market emerge in decentralized form and then transition to centralization – but this process is important to understand in the tech industry as it transitions to datacommodity industry through the adoption of utility models.
Operational Risk: Centralized Security vs. Decentralized Defense
Similar to the challenge of scaling service is scaling security. The diversity of threats and complexity of managing them makes large scale centralized security untenable. Like fighting the adaptive threats of Spam through designing new filters, centrally designed security solutions fail to keep up with environmental changes. Further, security requires expertise and there is a limited pool of human capital to provide it. As companies scale their openness to the environment to take advantage of Internet infrastructure, so to scale the demands to secure. The problem is if the costs to insure security run in parallel and even past the value of what they protect, innovation and infrastructure will be hampered by the security overhead.
Countering the trend of security overhead are emerging autonomic security solutions, for example those of Sana Security. Inspired by the design of the immunity systems in our own bodies, they provide a complex adaptive system that adapts to dynamic threats.
While security systems designers scramble to meet this escalating challenge, many would do well to reassess their fundamental design approach. The unfortunate fact is that the prevailing method of security systems design contains at least one fatal flaw: It assumes that system designers can adequately anticipate and create appropriate responses for every type of security breach possible within the system.
|
From an article by founder Steven Hofmeyr…
It's only human to think that we've anticipated all of the ways the systems we design can be compromised. After all, if we designed the system, then we must know it inside and out, right? The truth is that that vast majority of engineers and analysts cannot possibly predict the wide variety of viruses, worms and hacker attacks that could cripple their systems in the space of a few minutes…
To counter hackers' ability to stay one jump ahead of system designers, security managers are beginning to move beyond firewalls and IDSs [intrusion detection systems] to incorporate a set of technologies known as adaptive detection and response (ADR) systems. These systems deploy highly sophisticated monitoring agents to track operations at targeted file and operating system levels (similar to the way that the human body monitors its own layers of systems). Unlike IDSs, which look for known system and network threats, ADRs first build a complete profile of normal system operations, then continually monitor for any change in the underlying patterns of the system or network. |
Now decentralized architectures cannot be applied everywhere, but the decentralized autonomic approach to security certainly has a prominent role in reducing risk and enabling scale.
Balancing Business Architectures
As the tech industry undertakes its fundamental shift to utility service, the gravity of decentralization is breaking down centralized industrial era structures. The Frontiers of System Economics are being explored. System architectures previously focused on economies of scale and speed increasingly shifts to realize scope and span. Business models undertake a similar shift.
The cost reduction benefits of decentralized architectures, as pointed out by Kevin Werbach are too prominent bottom-line benefits to be ignored. So too are the benefits of risk reduction. The challenge in truly understanding the right balance between centralized and decentralized business architectures is that we are just beginning to explore the top-line benefits of decentralization. The top-line benefits of centralized forms of scalable enhancement of existing revenue and generating new lines of revenue are well known. But the top-line benefits of decentralization will have to be the topic of a future post.
11:57:25 AM 
|
