= 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 subcategories 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 subcategory 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.