An important aspect of the Enlightenment (from 1600 onward) was the concept that science and technology would usher in a new age of prosperity, peace and happiness. This philosophical revolution in the West was also strongly associated with the concept of the individual, as expressed in the United States Declaration of Independence:

"We hold these truths to be self-evident, that all men are created equal, that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness. — That to secure these rights, Governments are instituted among Men, deriving their just powers from the consent of the governed, — That whenever any Form of Government becomes destructive of these ends, it is the Right of the People to alter or to abolish it, and to institute new Government, laying its foundation on such principles and organizing its powers in such form, as to them shall seem most likely to effect their Safety and Happiness."

In classical times in Egypt and Greece, the prosperity of society was greatly dependent on slavery: cheap labour. It enabled the city states to devote more resources to philosophical, artistic, and military advancements. It is estimated that 30-40% of the labour force in Ancient Greece consisted of slaves!

In a way the robotisation of modern society is creating a new class of "slaves": worker entities without intrinsic rights (although in ancient times the level of rights of slaves varied considerably), never complaining, able to work around the clock as long as they are properly maintained.

But an important element in the equation is not often discussed: who actually owns the value of these assets? In ancient times you were able to buy a slave or obtain one through some other means (indenture, as a punishment, conquest etc.). The slave would then be your asset. In our times we see a different ownership model. Robots (as a generic term for machines that perform labour in the broadest sense) are owned by a very small set of corporations, to be "leased out" to organisations or individuals. In other words: the actual value of the asset is reaped by those few real owners. The rest of us can only pay-for-use, and are completely dependent on the actual owners as to the price they charge for use.

It is very easy to understand that this construct is not sustainable. It is already clearly demonstrating that it results in a growing inequality in wealth. This has been demonstrated historically to lead to instability and eventually revolutions.

Elon Musk told the US–Saudi Investment Forum that advanced AI and humanoid robots will make human work “optional” within 10–20 years, end poverty, and make money “irrelevant,” predicting a major societal shift driven by automation.

Quotes like the one above are commonly heard from the parties expected to profit most from these technological developments. History teaches us that things usually do not develop in this manner. A brief period of wealth concentration is followed by a destructive upheaval resulting in a slight (and temporary!) redistribution of wealth. An example is the French revolution.

In France just before the Revolution of 1789, the proportion of national wealth held by the top 10 percent was about 90 percent, and the fraction possessed by the top 1 percent was as much as 60 percent.  After the Revolution, the proportion held by the top 10 percent fell slightly due to the redistribution of land belonging to the aristocracy and clergy in favour of the bourgeoisie (a little over 9 percent). - Thomas Piketty

Might we say that the seeming luxury of these robotic "slaves" has a rippling effect in making ourselves into slaves?

A sustainable model will need to be created, with the actual ownership of automated support in the hands of the people that use that support, with actual value (as in marketability).

Estimated reading time: 8 minutes

New Year in The Netherlands has always had a problematic association for me because of an experience I had as a small child. My parents and I stayed at my grandmother's for the occasion, and I was put to bed on New Year's Eve being to young to be able to stay up.

At midnight hell broke loose. The room in the apartment of my grandmother where I slept looked out over the sports grounds where the main fireworks event took place each year.

It was the most terrifying thing I had experienced in my short stay on this planet. Things were exploding, burning, and everybody seemed to be screaming, and I was choked by a pungent smoke.

Maybe my parents had tried to explain to me what would be happening. I cannot remember. I do remember that I was alone and terrified for a few moments that felt to me like a very long time before my mother came in and attempted to comfort me.

That night was the first time I realised that life was finite, that there was something that could never be avoided: I would eventually die. The absoluteness of it felt like it was crushing me, and all joy was extinguished for several days.

To deal with the weight of this awareness, I, as many children do in some way or another, started looking for a way out, and entertained various fantasies on the problem. They converged in one that persisted for many years: I would upload my consciousness into some kind of machine that I would launch into orbit. That way I would be completely liberated from this world. I would live as pure consciousness, without a body that could become sick, age and die, looking out over the world and using all kinds of sensors to see what was happening. But never, ever, partaking.

This fantasy, I later realised, fitted in quite nicely with the Zeitgeist, the spirit of my time. For many thousands of years humanity was more aligned with the feminine aspect. Speculative as it may be (we are talking about interpreting sparse information from thousands of years ago!) there is a strong case for a long period of feminine focus. The shift away from the feminine principle as embodied in many artefacts depicting the Goddess was reflected in the rise of new embodiments of a more masculine principle.

Whether Marija Gimbutas' idea of a relatively peaceful co-existence of groups of people was a correct interpretation of artefacts (for example, a relative sparseness of weapons or defensive structures), even a modern scholar like Harari concluded that battle, war, power structures and a growing unequal distribution of wealth seems to coincide with the rise of the farmer cultures and the decline of hunter-gatherers. The 4000 year old stele of Hammurabi almost exclusively dealt with ownership and the legal ramifications of it (be it animals, houses, ground or women), like it was a relatively new concept that needed to be evangelised.

Male gods like the Greek god Zeus (who was promoted from an obscure local meadow spirit to the head of the Greek pantheon), were originally subordinate to female Goddesses like Gaia, Rhea, Demeter ("The Mother") or Hecate. Whole pantheons were uprooted to reflect the shift.

These male gods reflected aspects of a more modern perspective on life. Humans as the "rulers" of Earth, the pinnacle of evolution, entitled to rule because of unique properties that fundamentally separated us from nature and animals. Our intelligence, the faculty of "rational" thought, seemed to unlock the carefully guarded secrets that in previous aeons were under the auspices of the sacred feminine.

Separated from nature, those mental concepts of power and control were more and more externalised into tools, weapons and later: machines. Weaving was done by hands. It was much more productive (another masculine "value") to use machines to do it: faster, less errors. And the machines themselves were, of course, "owned" by someone. And machines, other than slaves, never complained.

We even started building machines that were called "intelligent": computers that could do seemingly very smart things. And these computers would be doubling their power each year! The possibilities were staggering! Intelligence was felt to be a set of algorithms, a disembodied processing power, a kind of hyper-charged clockwork or engine but now using this new and mesmerising power: electricity, power that could move with the speed of light.

The great Alan Turing did a nice thought experiment around the year 1936, called the Turing Machine. This concept was one of the fundamental ideas that led to the modern computer (in fact I noted in several articles that maybe it was not so much that idea but the idea of the Meme Machine put forward by Vannevar Bush in 1945). It was an idealised, "bodiless" thought construct. It did not live (or was thought to live) in the physical world, but instead was more like a mathematical thought experiment, much as the thought experiment that led to the special theory of relativity, done by Alfred Einstein in 1905.

The Turing Machine was a machine with "infinite" memory (which Alan Turing labelled a "tape"). One could write, read, and erase strings from this tape. However, as conceptualised by Alan Turing, this writing and so on was frictionless and immediate. The machine, so to say, did not have a body. The infinite operations it was able to do generated no heat.

In reality, all functioning systems generate heat. This is a consequence of the second law of thermodynamics which states that in any closed system entropy can never decrease. So as soon as you embody this mathematical concept of a Turing Machine (or any machine for that matter) in the physical world, these limits arise. This has led to the formulation of the second law of computing, the Landauer's Principle, which relates computing (let us say the manipulation of bits) to entropy, and the real, physical world limitations that arise from that.

The concept of mind, consciousness or intelligence as something that is disembodied, is actually one that is intimately related to Western culture. Maybe you find the concept obvious. That shows how it is part of the Zeitgeist. We talk about "pure consciousness" (as if any relationship with the physical somehow dirties it, makes it "impure"!).

Western Culture, which may be seen as originating in the Middle East (Sumer), was intimately associated with a revolutionary human invention: writing. Communication based on complex symbolic language has always been a distinguishing characteristic of being human. In fact some argue that being human means using language.

Language enables us to create purely fictional narratives, of which "fake news" is just another label. In a way "fake news" is a human trait. In fact humans have devised elaborate cosmologies in their religions that are difficult to relate to anything tangible, visible or measurable.

Computers run "software": an almost purely virtual power, consisting of instructions for processing units (processors). The instructions and the processing hardware are in no way aware of each other. The instructions are at the most hampered by the set of instructions that the hardware allows, but apart from that it knows nothing whatsoever about the processing unit: nothing about its layout, nothing about how it is connected through a data bus, and certainly nothing at all about their environment. Not only is there no feedback awareness, there is also no way the processing instructions can access and modify (adapt) the hardware it runs on. There is no body awareness in computers. There is also no awareness, and certainly no feedback from that awareness, of the increased entropy that is the inevitable result of all the computing being done.

Living beings, from the smallest units such as bacteria to complex multicellular life-forms as ourselves, all seem to have this one thing in common: they have awareness of their own body in its environment: proprioception. Also plants seem to have this innate ability.

What if intelligence, consciousness if you want, is intimately related to this awareness? What if the entire concept of "disembodied" intelligence is fundamentally flawed and can only lead to madness? Is it even possible to create "intelligence" that has no body?

The concept of intelligence, and certainly of consciousness, is by no means explained or understood. It eludes us to find a unified theory of consciousness. But whatever that theory will contain if it will ever come to be, I believe that an essential part of it is the fact that to be conscious is to have a body, to be aware of that body, and for that body to be aware of itself and its environment. We urgently need to step away from the idea that “intelligence” is disembodied and lives in purely idealised state or in the form of mathematical equations.

Related links:

• The Responsible Architect
• The Live Domain
• WHAT DO YOU THINK ABOUT MACHINES THAT THINK? | Edge.org
• There is no architecture. Only mirrors
• Digital Twins Done Right

Estimated reading time: 5 minutes

My gosh, everyone is now writing about Digital Twins! I should be delighted, you'd assume. Someone within Gartner must have resonated with some article of mine from 20 or some years ago…

A few examples:

• 1991: A simulator of complex ecosystems
• 1996: Buffered Database Communication (sorry, only in Dutch)
• … and many more I fear

Well, not really.

In the first place, I fear they may not have really read some article by me or otherwise they would not have made a thinking error that in my opinion is fundamental. In the second place I more and more start to believe that for a great idea, the worst thing that can happen is for it to be hyped by Gartner. Or anyone for that matter. Everyone jumping on the bandwagon, and no-one taking the time to really understand what it means, and most of all totally lacking any heuristics on how to successfully and properly apply it in practice.

We've seen this happen with the Internet (or rather, the World Wide Web), Java, or for that matter, even the personal computer and its reincarnation in our smartphones. I won't go into that, except to remind you to see Alan Kay explaining what the personal computer was supposed to be:

Computing as a language extension should enable us to do something an order of magnitude greater than we could already do, a human talent described by Alfred Korzybski as "time binding".

Now we seem to finally come to the realisation that to better understand Complex Systems (capitals intended) we need to re-create them. But that is exactly what humans have been doing since the invention of language: re-creating the world in our imaginations, in our fantasies, stories, dreams and hopes! We forgot the original vision behind the modern computer and now "rediscover" aspects of it. And in the rediscovery much of the essence is lost in translation. There is a gaping black hole in the whole concept of Digital Twins.

Laziness? Stupidity? Lack of time?

Gartner positions Digital Twins by associating it with another hyped concept: Internet of Things (IoT). This is about the increased computerisation of physical things: anything from coffee makers to buildings all the way to entire cities. By computerising these "things" they can be represented in software, and this representation is what is referred to as "Digital Twins". By internalising them as a so-called replica of the actual thing, we can connect them, reason about them, assess them, all in the "IoT". This implies that a growing percentage of the entire internet will be these actual representations of physical objects.

But that internal representation of real world things is what language was about in the first place. Human language creates symbolic representations of things. We did this on our computing platforms but as a rule this was only in a very limited and crippled form: as data. Even John von Neumann would be horrified to see that after 70 years his article on the design of a programmable computer was still almost literally applied — and that no-one seemed to have read the second part of the paper in which he explains that it should not actually have been done this way but for lack of advanced enough hardware.

The use of computers as an enhancement device of the human faculty of language, a symbolic manipulator, requires us to not literally represent "real" things (let's not go into a Wittgensteinian discussion on the definition), but to mirror them. In mirroring we change the objects. Slightly. Yes there are coffee machines. But when we actually mirror a coffee machine, the internal representation is deceivingly morphed. We have a coffee machine, but more importantly: we have coffee. Coffee becomes alive. Living coffee (in the internal representation of course) has a goal in life: to make itself. In the best way possible, for the human that wants to drink it. Every human has distinct taste, so this is a learning process. And the mistake that the Digital Twin advocates make is that all this knowledge is represented in either the coffee machine (imagine, it needing to remember all the different tastes of its users!) or in some kind of massive sphere that is mined for "knowledge". This is not scalable (please read "Scale" by Geoffrey West, or anything from Nora Bateson on complex systems to understand this).

The concept of mirroring, when applied to Digital Twins, implies that we mirror not only the physical things. They are to be endowed with behaviour, a goal in life. A door knows how to open and close itself, in all kinds of different scenarios such as giving access to the room for a meeting, or giving access in case of fire. This mirroring applies the pattern that I have called The Active Passive Pattern: active objects in the internal software representation become passive and vice-versa.

Digital Twins should not only be about physical things that have been endowed with chips and sensors. It should be about everything, physical things but also concepts that have meaning in the human world. A meeting is not a physical thing, but it should be part of the system: it will hold itself, invite attendees, ask the room to help, etc. 

Digital Twins should be the Mirrored World.

Related articles:

• The Mirrored World
• TOGAF ADM Revised
• Computable.nl | Strategie | Strategie | SOA versnelt aanvraag uitkering
• There is no architecture. Only mirrors
• WHAT DO YOU THINK ABOUT MACHINES THAT THINK? | Edge.org

PETER BELANGER/INTEL

Intel’s Bold Plan to Reinvent Computer Memory (and Keep It a Secret)

Wired, March 2017

We all read John von Neumann’s groundbreaking paper “First Draft of a Report on the EDVAC” back when it was published in 1945, did we not (just joking)?

You should. And read it well, because not many people did (I know of no-one). OK, I admit that some of the mathematics is above me as well, but one thing stuck with me: there are two ways of building a programmable computer. One is how we started doing it, which has become known as the “von Neumann architecture”: a memory unit and a processing unit, and a speeding cycle between the two, transferred through a bus.

We’ve all seen Alan Kay’s famous cardboard model of what a modern computer could look like, from 1965, did we?

As we all did (OK I’ll stop here, but I am not kidding: you should have read them!), Alan Kay had read the article by Gordon Moore (inspired by Doug Englebart already in 1959), about cramming more processors on an Integrated Circuit:

The complexity for minimum component costs has increased at a rate of roughly a factor of two per year. Certainly over the short term this rate can be expected to continue, if not to increase. Over the longer term, the rate of increase is a bit more uncertain, although there is no reason to believe it will not remain nearly constant for at least 10 years.

Gordon Moore, 1964

Useless, Alan Kay reasoned, to think about what computers can do now. We should be thinking about what they might be able to do 10 years from now, because it is almost unfathomable! And the Dynabook was a concept born from that daydreaming. A machine with a radio inside, able to communicate with similar devices in a world-spanning peer-to-peer network. How about that!

I fear that Alan Kay may be one of the very few who realised the consequence of Moore’s Law (as it was named in 1975). And now here we are, more than half a century later, and still we believe that von Neumann’s first proposal is the only way to build computers! And we still believe that creating the tools to tap that power should be built based on that architecture (memory-processor = data-functions)!

Change is inevitable. Even though Alan Kay’s vision from 1965 is still not really realised, it might be coming near now. Developments in hardware like memory and processors really start showing the shortcomings of the “first” von Neumann architecture. Massive parallelism, but especially memory that is so fast that the difference between memory and disk is disappearing, and memory that is persistent, is changing the game in a fundamental way. New computer architectures are desperately needed.

Intel’s 3D XPoint promises memory that is more than a 1000 times faster than flash, and stores more than 10 times more than DRAM. Memory and storage will no longer be different, databases are a thing of the past (everything can be done in-memory, just think about this!).

The main problem of the technological focus of computers is precisely that: that it is seen as a technology.

Because of that, technologically savvy people are attracted to it, and arising problems in all areas of life are discussed within a technological mindset.

Our current society is very much coloured by technology. Johan Huizinga, a Dutch historian and one of the founders of modern cultural history, pointed out the dangers of this focus in several works of cultural criticism during the rise of National Socialism in Germany.

Technology is usually seen as an antithesis to life, although not necessarily so (please review some of the talks of Kevin Kelly). When a technological mindset is applied to problems of society or politics, the attitude quickly becomes one of "designing solutions". We "design" a set of laws, a computer system, a business, a medication, a treatment plan — anything to create a desired future. We feel that if we do this, we are in control. The leading metaphor of modern "western" society is that of the "successful person": life is what you make of it, failure is a personal choice, freedom is the highest value. Even our own identity became a design target.

That this strategy usually fails does not seem to teach us a lesson.

Certainly, I completely agree that human beings evolve through learning. That the focus of human evolution has shifted to the mental plane, at least to a large extend, I do not contend. But the essence of that uniquely human trait, our mind, is not knowledge or even the power that some associate with it.

The essence of our mind is that it is a communicating device.

Through our mind and its defining human characteristic: language, the human species is doing something quite extraordinary. It is almost creating a new life form, one that has been called noosphere by Teilhard de Chardin. We can view the invention of the modern computer, and the revolution that is taking place as a result of that, as an extension of the linguistic ability of the human species.

The power of human language is extended in the history of the human species by several developments:

1. The invention of drawing and writing
2. The invention of the modern printing press (movable type)
3. The invention of the modern computer

Each of these developments had dramatic effects. We know that the invention of writing more or less coincides with the first city-states and the rise of the upper-class. It coincides with concepts of ownership (like land, cattle, and women), codified law, but also the concept of time-keeping and even devices to help measure time in a fixed and location-independent way.

It is no different with the invention of the printing press, which, as we know, made knowledge suddenly widely available.

However, the invention of the modern computer is still taking place. We are in the middle of it. Our society is going through fundamental upheavals.

Computers are not about technology. They are about language.

Estimated reading time: 8 minutes

Realising a consistent approach in your implementation projects is quite a challenge. One of the tools I have applied successfully is to introduce some kind of reference architecture or a reference model, or even better: both, in a reference implementation. This document outlines a high-level application architecture that I have found to be very useful in building such a reference implementation.

Goal

I try to provide an umbrella presentation of application architecture principles. Target audience: solution architects, developers and information analysts.

Architectural Styles

Every system is developed according to one or more architectural styles — whether explicitly or implicitly, consciously or not, consistently or not. It is never that there is no architecture. In fact even in organisations investing heavily in modelling architecture most of the architecture will always remain "undiscovered". A pragmatic approach has shown to be most effective: discovering and uncovering gradually, based on pragmatic and strategic considerations.

The goal is to apply these styles consciously and consistently, thereby reaping the benefits and manage the implications of using a specific style.

Theoretical Foundation

The architectural styles are made explicit based on the dissertation of Roy Fielding (2000): Architectural Styles and the Design of Network-based Software Architectures: https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.

This dissertation was the foundation of the definition of RESTful services that have become the de-facto standard for service connectivity, especially for front-end services.

Over the years I have found his overview of architectural styles (not just the RESTful ones!) very useful. Especially for a business-centred architecture it is possible to very succinctly define which style should be used in what part of the architecture (primarily front-end, service layer, business component, back-end connectivity).

Business Services

Business services are about the "how and what?". Business logic is the core of any system. “Splintering” of business logic is a known and pervasive problem:

• Functional changes have unpredictable side-effects all over the place
• Identical functionality is replicated all over the place

Therefore: isolate business logic in one location. This is a logical structuring of the business. It is structured around two aspects:

1. Business Objects
2. Business Functions/Processes/Interactions

This isolation is quite pervasive: efforts should be made to avoid including all kinds of "technology" into this component. It should be able to "simulate" the business without needing concepts like computers, networks, databases or such.

Domain Model

The Domain is the component containing the business logic. This component is by itself capable of executing all desired functionality (business processes). It is a relatively isolated component, in that it is able to do that even if completely disconnected from the other parts of the architecture.

It consists of a set of business concepts that together are reflections of the "real" world of the business. If you are a car leasing company, your business domain consists of Car, Driver, Contract, etc. By including the behaviour in this model, you avoid creating this as a data model or in a set of hard-to-integrate business functions.

These domain objects are related 1-1 to Business Services in a service layer, or, as I prefer to call it, a service landscape. The Domain Model is implemented in these Business Services.

Architectural Styles for the Domain Model

Several styles come into play for this component, however the main one I prefer is Peer-to-peer.

• Architectural Styles: Peer-to-peer (Fielding). Also see Domain Model(Fowler)
• Distributed Objects (Fielding) for connecting Business Services
  • (Mutual) connections through remoting
  • Light-weight message queues
  • Micro-services to contain the objects
  • Bidirectional relations are only allowed within packages
  • Package dependencies always unidirectional
• C2 (Fielding, more on this later) for firing events when something relevant happens (i.e. state changes)
  • Objects know nothing about (potential) subscribers on this events

Technical Services

Business Services are Central (satellite model, explained in many other articles).

• Outside-in: messaging (receiver known to sender)
• Inside-out: events (receiver unknown to sender)

Any change entering through a technical service on the perimeter primarily updates a business service. This guarantees any change to be dealt with by the business logic concerned (Larman: Expert Pattern). The business object then propagates the change to subscribers, but (and this is essential) never explicitly doing that. The change is propagated "indirectly" through firing an event into the blue. The event source has no awareness about any possible event sinks.

Example scenario:

1. Database (Technical Component) updates Contract::contractDate (Business Service)
2. Technical service sends a message first to Business Service Contract
3. Contract fires change event and optionally executes additional business logic
4. Synchronization services propagate for example to another database

The following sources introduced this architectural style:

• Hexagonal Model (Alistair Cockburn) - 1997
• Satellite Model (Rob Vens) - 1998

Role of Technical Services

Note that the approach introduced in this article is especially effective in a micro-service landscape, although still very useful in an architecture with services that are more coarse-grained.

Technical services should be viewed as a synchronization mechanism between the Domain Model and the “real world”. The "real" world is kept in sync with the internal software representation (see: Through the Looking Glass).

For this synchronisation, technical components are created:

• Web (or other) front-ends
• Databases
• Security components
• Etc.

Also known as Integration Services

• http://www.opengroup.org/soa/source-book/soa_refarch/p13.htm

Technical Services are (extremely!) simple, parametrised, standard components (framework) and thus are either used/procured (for example Spring, or an Oracle database adapter) or built only once, carefully documented and thoroughly tested to be used intensively within projects. (Extreme) light-weight, performance and bug-free are keywords when thinking about Technical Services.

Business Services ⇄ Technical Services

• Architectural style: C2 (Fielding)
• From business to technical (inside-out): notifications (events) - indirect
• From technical to business (outside-in): requests (messages) - direct
• Conceptually asynchronous (synchronous is an implementation decision, not a design decision)
• No direct link with Technical Components allowed (i.e. database, front-end): always go through Technical Services

Technical services are usually chained:

• Technical Component ⇄ TS1 ⇄ TS2 ⇄ TS3 ⇄ Business Service

Each technical service should responsible for only one integration aspect (for example data aggregation + caching), thereby creating services that are small, easy to understand and maintain, with well-defined interfaces.

Kinds of Technical Services

Below is a model of possible technical services from the Open Group, where they are referred to as Integration Services. Again, these components are used as the glue layer between business services and technology such as front-ends, legacy systems or databases. Other categorisations are possible as well. Note that these components should not be confused with Hohpe's Integration Patterns.

Architectural Style for all Technical Services

The main style here is Uniform Interface (Fielding). Publishing of events and/or subscribing to events by Technical Services is also possible (C2 style). Technical Services are instantiated/parametrised, not programmed. Specific technical services can introduce new styles.

Front-end Connectivity

Front-end should be viewed as a kind of Technical Component, with which you connect (as any Technical C0mponent) through Technical Services. The architectural style here is: Layered-Client-Cache-Stateless-Server (+ Uniform Interface) (Fielding) = REST architectural style.

Spring REST Controllers for example can function as REST resource.

Business Service lookup can be done lightweight (HATEOAS), the original directory services concept has proved to be too heavy-weight.

Framework guidelines

Note that part of the architecture will evolve into a framework, and it should. Framework development should however not be a goal in itself. This has proven to be an anti-pattern in many organisations. But especially because the glue layers are so exquisitely simple, they are the ideal candidates for framework inclusion.

Integration Layer controllers all inherit from a generic Controller. This results in ca. 90% code reuse.

For example (code in generic Controller class):

this.linkBusinessServiceWithTechnicalComponent(businessService, technicalComponent); 

This instantiates and parametrises an integration adapter that takes care of the interface to the technical component. Adapters are only procured, or developed for the framework (not by developers in the projects). Projects only reuse them. Integration Layer Controllers can also been viewed as containers for adapters.

Connecting Persistency

Usually Business Services still fetch data “directly” from databases or legacy (PL/SQL, JPA). Similar to front-end connecting this should be implemented with Technical Services taking care of persistency-as-a-service. This results in an almost complete independence from physical databases and legacy systems, enabling migration and clean-up. For this existing services need to be modified or refactored, which often feels like a daunting task.

Technical Components

What are Technical Components?

Examples:

• Databases
• Web front-end
• Security servers (for example Keycloak)
• External systems in general (Salesforce, SAP, etc.)

These are isolated or wrapped by providing them with:

• “well-defined” service interfaces
• “connectors” (sockets) to connect with

Like domain objects they are completely client-agnostic. The basic strategy is to leave them be as much as possible. If the above-mentioned styles are used you will find you are almost able to completely isolate them, which means that, at least functionally, you are able to migrate them to your leisure.

Related articles:

• Grass-roots architecture governance
• The satellite model
• Service Architecture Framework
• eXploratory Modelling Explained
• Why You Should Avoid a Canonical Data Model

The invention of the modern computer can be seen as a fundamental paradigm shift. But contrary to what the technology geeks want to make us believe, it is not about technology, digital content, the internet, or electronic devices.

Since it can (and in a few decades, will) be seen as fundamental, and since we are still in the thick of it, it is very hard to realise the implications of this revolution. We are part of the "Zeitgeist", and being immersed in it, only rare individuals are able to see further. Because of that, we are slowly starting to exploit some of the aspects of this invention, but mostly in the context of the familiar concepts dating from before the invention. New things are possible, but it needs a generation to grow up with the new invention as an intrinsic part of their world to truly see them. In the meantime we are acting as car builders did when building the new cars, based on the blueprint in their minds of the stage coach.

It was motorised. But it was still based on the concept of the old stagecoach blueprint, needing a driver, and passengers in a slightly more comfortable compartment. It took several years for the concept to grow mature enough to make the leap to placing the driver inside the compartment, making it possible to move oneself to ever distant destinations.

We do not need a driver anymore. Such as the mail man. They are obsolete.

But do we really understand the impact and extent of this change? I don't think so.

What about 3D printing? We do not need factories, at least not for a great deal of stuff. Even buildings can be printed. Factories, and the entire delivery-chain surrounding them, are becoming obsolete. Not fast, not tomorrow. But that is not because the change is gradual, it is because we are still not ready to embrace this change.

But how is Facebook different? Do we need a company, a mega-company at that, to communicate with people all over the world? Why not directly link with the people of our choice? Why not set up peer-to-peer networks without a middle man, without a controlling agency? Why not make it easier to manage all these privacy concerns and security leaks, by assigning ownership of information about ourselves to ourselves? My phone already "knows" where you are, you have a link to the network where I can reach you, circumventing any middle man such as WhatsApp or Facebook. Any device using the internet has its own address where it can be reached.

To me many of the so-called "services" all these companies are providing feel like opportunities created by the immaturity of the technology, the newness of it all, the lack of heuristics and "embedding" in society.

THE EDGE QUESTION—2015
WHAT DO YOU THINK ABOUT MACHINES THAT THINK?

But wait! Should we also ask what machines that think, or, "AIs", might be thinking about? Do they want, do they expect civil rights? Do they have feelings? What kind of government (for us) would an AI choose? What kind of society would they want to structure for themselves? Or is "their" society "our" society? Will we, and the AIs, include each other within our respective circles of empathy?

Source: edge.org

Interessante en actuele discussie over de opkomende realisatie dat computers toch wel eens "intelligent" zouden kunnen worden.

Zoals we weten werd al in 1972 door mensen als Marvin Minsky, Allen Newell en Herbert Simon "voorspeld" dat computers in 1989 intelligenter dan mensen zouden zijn geworden. Niet helemaal uitgekomen, en ik denk eerlijk gezegd dat het misschien wel mogelijk is dat computers een bepaalde vorm van intelligentie kunnen ontwikkelen, maar ik denk niet dat wij mensen dat kunnen. We begrijpen nauwelijks wat denken is, of wat intelligentie is. Het lijkt veel meer zo te zijn dat "intelligent" gedrag het resultaat is van een complex proces, ingebed in een sociale en biologische omgeving waar wij mee in verbinding staan door middel van onze zintuigen.

De angst voor "overname" door computers, waar o.a. Stephen Hawking ook bang voor lijkt te zijn ("en hij zal het wel weten") maakt het moeilijk om hier helderheid in te krijgen. In ieder geval zullen computers zoals wij die nu programmeren niet snel intelligent worden. Moderne programmeertalen zijn namelijk sequentieel, niet in staat om met complexiteit om te gaan, en heel erg procedureel: doe dit, doe dat. Dat staat even ver van intelligentie als een waterstof atoom van leven.

This is the Dutch translation of the article: "Software is not a product".

Het is een alomtegenwoordig idee: software is een "ding". Het wordt ge-engineerd, gebouwd. Als het klaar is bewonder je het eindresultaat zoals een kunstenaar zijn werkstuk.

Om het beter te doen, denk je na over het verbeteren van je bouwprocessen. Je speelt leentjebuur bij industrieën als de automobiel industrie (Toyota met zijn Lean methode bijvoorbeeld). Je richt projecten in en je worstelt met het verbeteren van je controle over die projecten.

We willen betere dingen bouwen, en het bouwen zelf verbeteren.

Het lijkt niet veel te helpen. Projecten falen. Het is niet schaalbaar, niet uitbreidbaar, niet flexibel. Nieuwe methodes komen opdagen, met veel beloftes die niets waarmaken. Wat is er toch aan de hand? Waarom is het zo moeilijk om ICT te doen?

De reden is eenvoudig. De oorzaak is een eenvoudig maar duivels bedrieglijke cognitieve vergissing: software is niet een product. Het is geen ding.

Deze simpele realisatie doet de mist verbazend snel optrekken. Het is een fundamentele heroriëntatie van software.

Het heet niet voor niets "soft-ware". Software is niet tastbaar. Al onze pogingen om het wel zo te doen lijken zullen onontkoombaar mislukken vanwege zijn fundamentele natuur.

Ik wil voorstellen dat we stoppen met software te zien als het resultaat van ons werk, maar om het proces als zodanig te gaan zien. Hoe lopen we in sync met onze gebruikers, met de business, zodat we onze werkwijze kunnen verbeteren en het noodzakelijke concurrentievoordeel kunnen behalen. In die zienswijze is software een nevenproduct van dit steeds verbeterende en evoluerende proces, dat al onze kennis en begrip in zich vat, en dat net zo efficiënt en doeltreffend blijkt te zijn voor welk nieuw product dan ook wat we bedenken. Het zijn de organisatie met zijn mensen waar het om gaat, wat het verschil maakt. We wisten dat altijd eigenlijk al. Dus waarom richten we onze aandacht daar niet op? We wisten altijd al dat ICT een partner moest zijn voor de business, op een fundamenteel andere manier dan dat HR of catering dat zijn. Waarom niet deze redenering blijven volgen en ontdekken dat uiteindelijk de intelligentie van het bedrijf niet zit in zijn software, maar in de manier waarop het die software tot stand brengt?

Om Agile en Lean principes toe te passen op het proces als het werkelijke, uiteindelijke, product, maakt het een stuk makkelijker. Een auto is niet vergelijkbaar met software. Een auto is ontworpen en ge-engineerd op de tekentafel. Software niet. Het materialiseert door eindeloze iteraties, het is nooit "af", het is een zich voortdurend ontwikkelende entiteit. Wat nog belangrijker is: het evolueert samen met de organisatie en zijn omgeving.

Het product van ICT is het proces. Software systemen zijn bijproducten. Door te focussen op het verbeteren van de kwaliteit van processen verbetert de kwaliteit van de bijproducten het best.

Dit is de Engelse vertaling van het artikel: "Software is geen product".

The idea is ubiquitous: software is a "thing". You engineer it, you build it. When you are done you appraise the end-result as a master artist views his piece.

To do it better, you think about improving your build processes. You borrow from industries like the automobile industry (Toyota and its Lean method for example). You define projects and wrestle to improve your control over it.

We want to build better things, and to build it better.

It seems not to help. Projects fail. Software fails. It is not scalable, not extensible, not flexible. New methods gain ground, promising a lot, delivering nothing. What could be wrong? Why is it so hard to do ICT?

The reason is simple. The reason is a simple but devilishly deceiving cognitive error: software is not a product. It is not a thing.

This simple turn-around suddenly clears the fog in a surprising way. It is a fundamental reorientation of software.

It is not called "soft" ware for nothing. Software is not tangible. All our efforts to make it so or to make it more so will inevitably fail because of its fundamental nature.

What I would like to propose is to stop viewing software as the result product of our work, but to view the process as such. How we walk in sync with our users, with the business, to improve the way of working and gain the necessary competitive edge. Within this world view software is a by-product of this ever-improving and evolving process, which incorporates all our knowledge and understanding, and which will prove as efficient and effective for any new "product" we may envision as it was for the existing ones. It is the organisation and its people that matter, that make the difference. We all knew that. So why not turn the attention to that? We all know that ICT should be a partner in business, in a fundamentally different way than HR or catering are. Why not take this to its inevitable conclusion and realise that ultimately the intelligent enterprise rests its intelligence not in its software but in the way it realises that software?

To apply Agile and Lean principles to the process as the ultimate product, makes it so much easier to apply it. An automobile is not comparable to software. An automobile is designed and engineered on the drawing board. Software is not. It materialises through endless iterations, it is never "done", it is an evolving entity and what's more important: it evolves together with the enterprise and its environment.

The product of ICT is the process. Software systems are by-products. By focussing on improving the quality of processes, the quality of the by-products will improve more effectively.