Environment is an active process. A flock is not a big bird. Emergent behavior is distributed. Think small.

Hieronymus Bosch

Software technologies have evolved from assemblers, to procedure programming, to object-oriented software. Goal-oriented direct model-driven services, semantic agents, and multi-agent systems are the next software paradigm.

Some principles for multi-agent systems include:

1. Agents should correspond to “things” in a problem domain rather than to abstract functions
2. Agents should be small in mass, time (able to forget), and scope (avoid global knowledge action)
3. Multi-agent systems should be decentralized (with no single point of control/failure)
4. Agents should be neither homogeneous nor incompatible but diverse
5. Agent communities should include a dissipative mechanism (entropy leak)
6. Agents should have ways of caching and sharing what they learn about their environment
7. Agents should plan and execute concurrently rather than sequentially.

Declaring knowledge about data, processes, rules, services and goals separately from application code to enable sharable, adaptive, autonomic, and autonomous solutions.

Almost Human

Goal-oriented software engineering separates knowledge (i.e., semantic models) about what to do from how to do it. Goals identify targets for a process, or portion of a process. Plans get selected dynamically to achieve goals. Self management within the business process logic allows dynamic restructuring of goals and plans at run time as well as adaptation of process behavior to prevailing run-time conditions and business contexts.

Autonomous solutions have the ability to independently perform some processing toward achieving or maintaining one or more goal. They are self-contained systems that function independently of other components or systems by acquiring, processing and acting on environmental information.

Autonomic computing systems have the ability to self-regulate a goal/plan hierarchy to make automatic adjustments in real-time in accordance with changing environment using closed control loops without the need for any direct intervention.

Webs of meanings and knowledge. Constraint-based, direct model execution systems that know and can share what they know. Architectures of learning that perform better with use and scale.

Three stages of semantic solution envisioning

The diagram above depicts three stages of semantic solution envisioning. Business capability exploration focuses on reaching agreement about goals, constraints, and the basic concepts and terms that different groups use. Different stakeholders express their requirements in their own language. Solution exploration defines needed capabilities and concept computing solution patterns. Semantic software design is knowledge-centric, iterative and incremental. Changes in ontology, data, rules, workflow, user experience, etc, can automatically update system functionality, without impacting underlying legacy systems and databases.

The process of semantic solution development is declarative, direct execution model-driven, and knowledge-centric and rather than being procedural, specification waterfall translation-driven, and document centric. Build cycles are fast, iterative, non-invasive. Semantic solution development typically entails less time, cost, and risk to deploy, maintain, and upgrade.

Knowledge is extracted and modeled separately from documents, schemas, or program code so it can be managed integrally across these different forms of expression, shared easily between applications (knowledge-as-a-service), aligned and harmonized across boundaries, and evolved. Requirements, policies, and solution patterns expressed as semantic models that execute directly can be updated with new knowledge as the application runs.

Semantic solutions emerge from a techno-social collaboration that also supports do-it-yourself development. The development process is business and user driven versus IT and developer driven. The collective knowledge developed is interpretable by different human stakeholder as well as machine executable. Different skills are key including domain expertise, concept computing architecture, knowledge modeling, and (smart) user experience design.

Data-centric, constraint-based declarative processes trump procedural algorithms.

Complex reasoning at scale demands declarative processing

In software, we can trade processing cycles (time) for storage (space). For example, imagine an algorithm where every possible input combination, processing sequence, and output variation had been pre-computed and that the results of all these possible states had been stored. Next time there would be no need to (re)execute the program because all possible inputs and results have already been computed and declared. You simply look up the result by specifying the variables that constrain the space of possible outcomes. Nothing could be faster.

Historically, the cost of computation favored executing algorithms over and over, rather than providing the semantic bandwidth and memory to access and store all possible permutations in a declarative knowledge mesh. That was then.

Today, computing economics have reversed. Massive memory and parallel processing is cheap and getting cheaper. Massive declarative knowledge-based computing is now economical.

But, there’s an even more compelling reason why the shift is happening now — new capabiities.
Declarative systems allow applications that can learn, evolve, and use knowledge in ways the system designer could not foresee.

How is this possible?

• Declarative languages specify “what” is to be done. Declarative representations are like a glass box with knowledge visible in a format that can be accessed, manipulated, decomposed, analyzed, and added to by independent reasoners.
• Imperative (procedural) languages, on the other hand, encode “how” to achieve a particular result, step by step. Procedural representations are like a black box with knowledge fixed and locked inside an algorithm. Procedural systems do the same thing every time and cannot learn from experience. Making changes requires rebuilding data stores and rewriting algorithms off-line.

The ability of a system to scale-down, scale-up, scale-out, and scale-in.

Four dimensions of scalability

Scalability is the ability of a system, network, or process to handle a growing amount of work in a capable manner, and its ability to be further empowered to accommodate that growth. For example to handle more users, more data and sources, greater knowledge intensivity of decision making, increasing process dynamics, infrastructure expansion, and system adaptivity.

Architectures for the next stage of the internet will evolve along four key dimensions of scalability:

Scale-down
As Richard Feynman said, “There is plenty of room at the bottom!” Scale-down architecture is about maximizing feature density and performance, and minimizing power consumption. Approaches include nano-technology, atomic transistors, atomic storage, and quantum computing.

Scale-up
Scale-up architecture (or vertical scaling) is about maximizing device capacity. It adds more processing power, memory, storage, and bandwidth on top of a centralized computing architecture. Typically, scaling up uses more expensive, platform-specific, symmetric multiprocessing hardware. It’s like a fork lift to increase capacity and performance.

Scale-out
Scale out architecture (or horizontal scaling) is about maximizing system capacity. It adds multiple instances of the process architecture enabling the system to address vastly more subjects, services, things. Processors perform essentially the same task but address different portions of the total workload, typically using commodity Intel/AMD hardware and platform independent open source software.

Scale-in
Scale in architecture is about maximizing system density and minimizing end-to-end latency. Scale-in architecture differs from the old compute-centric model, where data lives on the disk in a deep storage hierarchy and gets moved to and from the CPU as needed. The new scale-in architecture is data-centric. Multi-threading within and across muti-core processors enables massive parallelism. Data lives in persistent memory. Many CPUs surround and use in-memory data in a shallow flat storage hierarchy where each memory location is addressable by every process thread.

Scale-in architecture is data-centric

Scale-in architecture empowers concept computing — a dimension of increasing knowledge intensivity of process, decision-making and user experience. From a big data perspective, it allows addition of new data elements, aggregation of context, and on the fly modification of schemas without the necessity of off-line rebuilds such as are needed to modify data warehouses and NOSQL processes at scale. From a business perspective scaling-in enables “systems that know” where changes to business requirements, policies, laws, logic etc can be managed flexibly and separately from data sources and operations. Scale-in architecture is a prerequisite for cognitive computing and systems that can learn and improve performance with use and scale.

These four dimensions of scalability are key to building smart, high-performing processes of any size, any complexity, any level of knowledge intensivity, and which can learn and grow live to quickly adapt to changing requirements and implement scale-free (or scale-invariant) business models.