Metapattern > getting started
[A]lready existing applications can usually be accommodated, for example by including each as a difference and labeling it accordingly with a particular context. Once it is part of the interdependent infrastructure, such applications are easier to integrate. Essentially, they should lose their isolated character, benefiting from and contributing to interdependence.
in: Ontology for interdependency: steps to an ecology of information management
It may sound paradoxical, but innovation with Metapattern will get you the highest mileage from legacy ‘systems.’ Reconceptualizing each existing system as a specific context already goes a long way to disambiguate at the level of necessary integration. After securing such (initial) overall order, you may then analyse real differences (for which separate contexts should be maintained) and duplicates (where contexts could, and should, be merged).
in: note 23.15
On the conceptual side, Metapattern is a powerful metamodel. Its conceptual results need to be translated into construction/implementation models required to switch focus to tool technology.
in: Metapattern as context orientation: meeting Odell's challenge of object orientation
It is possible to change information types, it is possible to change information relationships, and it is possible to change primitive information. Through its “forgiveness” to errors, Metapattern supports development by trial, thereby avoiding the many pitfalls of the blueprint approach to complex information systems. Cohesion may grow gradually, as insight into the pluriformity of concepts grows. Any unsuccessful trial can easily be controlled by correcting the errors encountered.
in: The pattern of metapattern: ontological formalization of context and time for open interconnection
Metapattern’s context orientation is not only richer for conceptual modeling, it’s also a rigorous frame of reference for better implementation tools/components for the precision of behavioral differentiation.
in: Metapattern as context orientation: meeting Odell's challenge of object orientation
As the conceptual model controls many decisions about implementation, it also contains transformation concepts.
in: Metapattern as context orientation: meeting Odell's challenge of object orientation
Metapattern invites development of conceptually-equivalent models; they are simultaneously highly-differentiated with respect to implementation as concrete information sets. As such, Metapattern is also a tool for bridging the gap between conceptual and implementation models. As stated earlier, some important implementation issues can already be “prepared” in the conceptual model through the use of transformation concepts.
in: Metapattern as context orientation: meeting Odell's challenge of object orientation
It works like modeling toward an asymptote. The ascent is quite steep, i.e. very soon hardly any additional assumptions are required. The practical relevance […] for information systems is huge. It is possible to eliminate semantic redundancy resulting in higher quality and lower costs.
in: On "nil" modality and Metapattern
Metapattern can also ‘hide’ how different it can eventually work out. For nobody likes a revolution. At least, nobody does whom I know in business and government which of course constitute the relevant audiences. It therefore is a crucial aspect of its design that Metapattern, at first, may appear not quite different, but actually quite the same. Metapattern supports finely tuned evolution.
in: On metapattern and other themes in information management
In terms of planned change, […] in a most practical sense it is precisely the discontinuity of making multiple contexts explicit that allows for … minimal disturbance of continuity when moving to a higher level of information management.
in: On metapattern and other themes in information management
Legacy systems with all their original details (!) can be unambiguously included in an overall networked configuration when each such system is considered as a wholesale context. Such straightforward initial migration for metainformation, only, serves as the basis for subsequent, step-by-step integration for information and applications proper.
in: On metapattern and other themes in information management
A rational dilemma of diffusing any critical innovation is that more variety can never be explained from … less variety. So, for Metapattern I am drawn to somewhat similar conceptual frameworks, or even problem statements. In fact, I’d rather not be too original at all. What I’m hoping for is to establish relevant correspondences, i.e. a persuasive metaphor.
Met An intermediary metasystematics hebben we een stevig fundament gelegd voor beheer van een modellenfamilie.
[W]hat we model must also be practically feasible. So, we have to reckon with distributed information. At the time of design, even especially so, we have to have — from acknowledging to establishing — a federation of information sets (also read: registers) in mind.
in: Perspectivism in federated practice
Please note, with context as a structural (meta)concept, and time, too, for that matter, there is also the best chance to continue to use existing tools; what then needs to be added, only, is a separate means for their integration.
in: note 53.15
[D]istinguishing between two extreme uses for Metapattern provides
guidance, sort of iterating between them. By way of preview, on the one
side Metapattern facilitates modeling an integrated order —
almost — purely conceptually. Such use might be characterized as
practicing idealized design (an attitude coined by Russell Ackoff).
Then, you try not to let any technology, or whatever, come in your way.
It is practicing philosophy, really. On the other side there are, here
and now, real “integration problems.” It means that you
have to start from applications, systems and databases that actually
exist and in most cases, if not all, will surely continue to be used
for some time. While the result of idealized design may help to set a
longer-term goal, and you would therefore be strategically disoriented
without it, in real practice it is not what gets you off the mark
today. For that, as you are only too well aware of, separate
inventories of metadata need to be merged and information (I suppose
you would call them: data) reported comprehensively.
Here again I have trouble finding an equivalent term in English. I find
is has to sound right, too. The Dutch term is rotonde. The
emphasis is on the middle syllable. A ‘rotonde’ is where
traffic enters and goes around until it exits. On the average, drivers
benefit from the device for streamlining traffic flow. […] Would
you call it a roundabout […]? […]
What I mean by ‘informatierotonde,’ [i.e., an information
roundabout,] is that operational databases can be connected to it on
the basis of a model of identifiers for the concepts of interest for
comprehensive reporting. To start with/from, having copies of databases
available is fine, if not preferable. The idea is that nothing is
changed for and/or in the databases involved. Of course, this is not at
all a new idea. But supporting the interconnection with
Metapattern/KnitbITS is, and it does appear to make a difference.
[…]
Applying an ‘informatierotonde’ ma[kes] comparisons between
contents of […] different databases possible. The resulting
overview point[s] to which values for which attributes should be
adjusted for the operationally still separate databases and their
applications to subsequently operate in managed harmony. Of course, it
is some way removed from, say, proper integration. But an
‘informatierotonde’ will get an organization at least
already a surprisingly long way, even very quickly and at hardly any
costs (of course saving much more in the process).
in: note 71.6
I can only strongly recommend starting with an information
roundabout. Of course, since decades already we are trying to align
differences by making translation explicit, that is, putting something
like a value-here:value-there table in between. Thereby solving one
problem, however, creates the next when such tables et cetera take up
definitive positions, that is, effectively adding to the number of
applications/systems. A solution of value-translation should be
temporary.
Now, an information roundabout is really not different from a set of
such tables, at least to begin with. In fact, it also should’t,
as that is what usually counts as the immediate problem. Yes, it aims
to generalize (which also has been done before).
I would say the main feature of an information roundabout as I favor it
is its orientation at contextualization. At the start, that is,
interconnecting databases-as-they-are, Metapattern is only crudely
relevant. You might ask, why bother? Gradually, on the side of the
information roundabout contextual differentiation at the scale of
integrated order may be enhanced, with corresponding modifications made
to connected applications (thereby more and more changing into mutually
interdependent constituting elements for the integrated order for which
an idealized design serves as its goal to aim at). It is of course
contingent what the optimal order (in time) is for approaching the
relevant integrated order (as a result). My general idea of an
optimally controlled change process facilitating information
communiting/traffic is one of morphing an information roundabout. By
the way, there is no rule that says you can only start with one
information roundabout.
in: note 71.8
Are you perhaps saying that a new difficulty crops up? If so, you are right. However, there is no avoiding it. If anything, Metapattern helps you to recognize and address it. Take whatever number of non-overlapping contextually differentiated descriptions. Doesn’t non-overlapping means that it has become impossible to tell which descriptions pertain to which object? Yes. Luckily, though, objects change from one behavior to the next. That is, from earlier behavior(s) we can — almost always — infer the object a subsequent behavior should be attributed to. And then we create ‘behaviors’ especially for that purpose of attribution, for example ‘fitting’ objects with unique identifiers. Now applications with, in terms of Metapattern, each a limited horizon have issued particular sets of identifiers. Let’s take persons as an example. How can we tell for establishing an integrated order that id-x from database A refers to the same person as id-y from database B? Often, there are some common properties registered in both. The non-overlapping criterion does not hold for so-called legacy databases. No, what actually does overlap never offers “certainty,” at least no absolute certainty (which is, of course, a main reason for increasing integrated order). If the lack of “certainty” is your point, not just theoretically but especially in practice, I even strongly agree. However, comparing contents — when persons are relevant ‘objects,’ usually name and address are available from databases — may already go a long way (and, by the way, that is precisely what an information roundabout at first helps to analyze et cetera). Then, in many cases you can be certain enough to proceed (and some mistakes will creep through; negative effects can be minimized when the persons involved are made part of the quality feed-back loop, and you may have to come up with something to get them to respond; and, anyway, such negative effects are far less than would continue to o ccur through use of strictly separate databases). Inevitably there will be cases, though, where you have to contact people and make further inquiries. Miss-spelling of names, whatever. […] People are glad to hear from you, that you take care. [… M]istakes [get] fewer and fewer, so they need to make fewer and fewer calls. And as a matter of “certainty,” too, :-) there is no alternative, and as soon as an id-for-integrated-order adequately connects the contextually differentiated behavioral descriptions for ‘its’ object, changing and/or adding such descriptions continues ‘normally.’
in: note 71.10
Interconnecting databases without practical limit requires us to be able to collect different meanings while both being able to unambiguously tell them apart and likewise interconnect them.
in: note 71.10
[I propose] to interconnect legacy databases — with everybody relieved not having to tamper with them — via an information roundabout with an added database supplying necessary and sufficient information keys with, where applicable, relationships between them.
in: note 71.36
Luckily, shifting to another paradigm doesn’t have to be an all-out occurrence pinpointed in time. Preferably not, even. But without making a start somewhere, it will of course never happen. In my considered judgment, setting up an information roundabout is a very powerful way to get the shift going.
in: note 71.40
[S]etting up an information roundabout is critically important in a planned change sense[.]
in: note 71.40
You might be able to start change ‘under the radar,’ i.e., without formal permission.
in: note 71.40
Again, at the moment I find an information roundabout ideally suited. Get results at hardly any costs[. People] then might get a taste for more. Anyway, there is definitely no quicker way to get proper results than by coming to grips with real information requirements, and everything falling short of the scale of integrated order can only fail, slowly and expensively so.
in: note 71.40