From Generalisation to Specialisation?

Introduction
I am a big believer in the importance of managing boundaries versus controlling the internals. This works for business and technology. We have been compentising electronics, software and technology in general for a long time. In a similar manner organisations have transformed, or are in the process of transforming, from silo-based to process aligned, to being component/capability modelled and implemented.

The reason for this transformation is applicable to technology and business: Scarcity of resources. A scarcity in business resources (or a need to divert those resources from operations to innovation for example) will drive a discussion on business reengineering and outsourcing; in the same way we will find that a scarcity in, or commoditisation of, computing resources will drive the specialisation of technical components. It is my belief that an era of unprecedented growth in processing capability enabled by CMOS scaling has driven the current generalisation in technology - but more on that later.

Benefits

1. Component substitution. If the boundary is well-managed, using a contract that specifies the qualities of service and interaction, then a new component can be implemented as long as it provides the same set of interoperability services.
2. Component relocation. If the component manages it's "own internals" then it isn't bound (or at least less so) to a common infrastructure with the consuming component. This principle has driven a lot of out-sourcing thinking i.e. re-engineer the boundary and then relocate the function.
3. Reduction in complexity. It is easier to manage the boundaries than to manage the entire ecosystem. If the component manages its own internals against the agreed qualities of service in the contract then we achieve simplification and a subsequent reduction in cost.
   

Challenges

1. Duplication of function. There is the possibility that function is duplicated, which can result in an increased cost to business. We can counter this by providing components focussed on the provision of services to other components i.e. the common functions are grouped into a component (with the other relevant assets and resources) to provide the "duplicated" function.
2. "Mind the gap". If the ecosystem isn't well defined then there exists the possibility that the sum of component services is less than the whole or what was expected. For example - an outsourced HR operation may perform the HR functions well but the human element of caring for employees could disappear.
3. Blackbox vs Whitebox. Is it sufficient to consume a service or do we also need to know how that service was produced? Does a consuming component have the right to know how the service or product was produced? For example: was it produced using ethical labour practices? Is it sufficient to specify this in the qualities of service? How does this impede on the right of an organisation to execute its business in a manner free of external control?
   

Applied to technology
As a previously mentioned, I believe excessive resources drive generalisation but we are now in a transition era where CMOS-scaling following Moore's Law is reaching the limit of what is technically viable (vs technically feasible, which it still is). The power and cooling of semiconductors is become excessive when compared to the benefits achieved. We will have to leverage a range of new innovations to continue delivering the system level performance we have become accustomed to until the replacement technologies (nanotechnology and quantum computing) are mainstream. We will have to innovate the way chips are packaged, the architecture of the systems built with them and the software that runs on them. Furthermore, we have to optimise more than just the semiconductor technologies, but also the architectures and software that surround them.

We will see another drive towards specialisation - specialisation of computing nodes; specialisation of components within datacenters; and specialisation of datacenters themselves. There is a common thread that drives this specialisation - and that is the power and cooling of these components, as well as the complexity of managing them, has caused business to hit the wall!

Component specialisation
I believe that a technical component, specialised in this way, would exhibit the following characteristics:

1. Well managed cluster of resources that have a lot of the capabilities that you would normally find in systems management (workload optimisation, availability, restart, recovery etc) but, internal to itself.
2. The component would present a very simple interface for the consumption of services.
3. Contracts specified for each interaction between components. The component contract would include service qualities as well as the services themselves. These qualities would include aspects of latency as well as the usual set of non-functional requirements.

Choreography and Collaboration
As we move up the stack; one of the biggest issues to solve in my own mind what is the best architectural model for collaboration: hierarchical or peer-to-peer. Most of our control systems are hierarchies, whilst effective they introduce a strict top-down control structure – each level of control is further decomposed into subsequent choreographies. This can result in a brittle architecture where a single weak-link can cause the system to fail – as well as introducing dependencies that are difficult to replace.

An ideal situation would be peer-to-peer where a consuming component request a set of services, based on the desired qualities. These services are then delivered by the best-matched candidate, who in itself requests services. This results in an ecosystem of service provides and consumers.

The ecosystem may in itself display characteristics of the hierarchical architecture, but this would be by consequence rather than design.

Granularity, Ecosystems and Cross-border Operation
Another question on my mind is whether all components are equal or whether components need to be matched within an environment than enables their communication and collaboration. A real world example would be: the semiconductors within my mobile phone collaborate to deliver a composed set of services. The phone uses these services to provide another set of services. Multiple phones collaborate to enable communication within an environment that transports the cellular signal. Therefore components seem to exist within an ecosystem that enables their communication at a specific level of granularity.

What characteristics would the ecosystem display?

1. The ecosystem would enable communication, or at the very least transport of that communication content.
2. An ecosystem could provide a set of base services that enable components to locate each other, as well as common services like naming.

Is the ecosystem therefore just another component? Hmmm …..

Conclusion
I believe that the time has come (again) for purpose built components optimised for designated tasks.