= Modeling and keeping solutions aligned =
Concept created 25.1.2009 by Jan R. based on FRAME concept.
Here i am going to eplain the ideology which needs to be used to have the separate
concepts aligned with the big picture. The concepts are separated between main
categories, sub-categories, integrating and supporting.
* Main-concept-category (later MCC) is the high-level idea which combines the sub-
categories together. Idea for this is to explain how the concept fits to the big
picture and who is responsible for the concept.
* Sub-concept-category (later SCC) is the building block for the MCC. The sub-
category will descripe an information context in detail and give details about the
roles, knowledge-lifecycle and the integrating/supporting concept connections.
* Integrating-concept (later IC) is the building block which connects to the other
SCCs in and out of the MCC. So that we can explain the infomation flow and
permissions between concepts.
* Supporting-concept (later SC) is the supportive building block of the SCC and
with these we can define the general information context in detail. This gives us
the possibility to understand if this context is indeed SC or SCC. This would help
us to manage these blocks better. The idea with SC is also to create SCCs more
rapidly and then also simplyfy the concepts. But in this we need to concentrate on
defining the context in exact detail.
== Principles of modeling and using a concept ==
A Concept is a data-structure for representing a stereotyped situation or
information object. Each concept includes different type of information which can
be used to present the concept to wide variety of people.
Information about:
* How to use the concept, the knowledge-lifecycle.
* The default values which reprecent the most common situations, generalizations
for the situation or information object.
* What to do if these expectations are not met or confirmed.
* Possible operating limits and capabilities of the concept.
* Responsibilities between operators, supporters and owners.
* Presentation of the concept and its information in form of reports, searches,
collected information views (Dashboard) to the people who are responsible.
* What can we expect to happen next, this is the continual-inprovement roadmap.
=== Knowledge-Lifecycle ===
How do we control the information flow or life-cycle we present in this concept.
* Do we set validation rules and then define the information stages and make sure
that the information inserted follows the life-cycle.
* How about situations where the information is not automatically created, do we
create this information using deadlines or events that control the generation of
the information in pre-defined set of rules.
* If we mix these above cases, is there a possibility that the other way of
generating information or knowledge overrides the other? Do we need to set usage
rules or functionalities to prevent dataloss?
* What happens when the concept is changed to another and more evolved concept, do
we keep the previous information or do we keep it separate and then make sure its
compararable to the new concept. This comparison can be done using transformation
rules and calculation matrix.
=== The default values ===
The default values are attached loosely to the concepts, so that they can be
easily displaced by new values that fit better the current situation. They thus
can serve also as "variables" or as special cases for "reasoning by example," or
as "textbook cases," and often make the use of logical quantifiers unnecessary.
* "variables" = f.ex fields which affect the total hours worked. The way to
calculate this is always constant but the values can be variable by situation.
* "reasoning by example" = f.ex default values when creating new Computer CI to
the system. Certain default values are applied to the fields.
* "textbook cases" = f.ex default values will be defined by use-case or predefined
process.
=== Concept expectations ===
We need to define the conditions, which trigger the change process for the
concept. If the concept becomes legacy then we need to know about it as soon as
possible so that we can trigger the improvement process for the concept. There
might be different expectation rules and change triggers. Here are some examples:
* Information is not relevant anymore to the people using or requiring it.
* Information is not maintainable or is corrupted easily.
* The information is not detailed enough.
* Re-using the information is not possible anymore between the ICs. So change in
one SCC creates a requirement in the other SCC.
* The MCC changes and we need to define the SCC to match the different concept
conditions.
=== Concept operating limits and capabilities ===
=== Continual-improvement roadmap ===
The idea behind this is to have process of making improvements on the concept in a
controlled way using the change concept model. The trigger here is situation and
the need to adapt to a new environment with the concept.
The concepts are linked to a concept portfolio. When a proposed concept or a
concept building block cannot be made to fit reality or we cannot find suitable
conditions to match the operating or supporting needs � this portfolio provides a
replacement concept or building block. These building blocks make possible other
ways to represent the concept. This way we will always have an backup-plan to keep
the concepts in operation.
