|
 |
|
|
|
Summary:
In reality, any process is a scenario that expresses the system's behavior. The process is made of service exchanges that take place between objects, through connected service points. Consequently, process reengineering means modifying scenarios and services to reach a required services level (we call it "rendered service"). Knowledge objects support processes Amarco requires that any process be mapped on conceptual objects or knowledge objects. This organizational framework is absent in today's analyzes that focus on process without taking into account the entities that perform the process. The conceptual objects bring the required support to analyze, (re)design processes, expose clearly the changes as service change. They make visible the borders between the cooperating entities. For Amarco, any outside entity that interacts with the system under study is a "user". Processes begin with requests for services from external systems (users). Qualities of Service for scenarios When we map service points to objects, we can define services qualities (time, cost) for the services executed in server service points. The rendered service of a scenario will be then the sum of the individual service qualities. We can thus analyze and show how the quality of service (QoS) of a scenario evolves in time. That means that we can see clearly the weight of each service in the overall service quality of the scenario.
Amarco - tool to master the complexity of systems Amarco is a kind of state of mind that helps master the complexity of systems. Each analysis is based on three fundamental elements: objects, service points and services. The iterations External architecture - Internal architecture limit the details that are visible at a precise moment. Hiding the details of the structure of an object helps understand its services. There is no "pollution" with details when you try to see what an object or a system is supposed to do. The service point can be taken for a "function", but there is an immediate advantage that the service points notion has over that of function: we know immediately what object requires a function and what object fulfills a function. So we know which objects are connected together and how. This simple remark can bring a lot of light in current function oriented diagrams. Note : Just take a look at any "functional diagram" you know already. You can not say if the arrows indicate a service request, or a service rendered. These are the main reasons for all communication errors (misunderstandings), at any level! The scenarios are based on requested and rendered services that belong to service points. At the same time, each requested service in a component object corresponds to one or multiple scenarios that perform in the internal architecture of the object. That means that each rendered service at the boundary of the system depends of a chain of internal scenarios. For example, in the authorization system case, a rendered service "system unavailable" may mean: authorization server unavailable, or authorization network unavailable, or black box error etc.
That infers that we can imagine automatic systems that may verify the scenario dependence, to see what requested and rendered services where used in all scenarios that depict system behavior. So this system may find the corresponding services that were not used. You may also take a look at our discussion about the functional view and how our tool Amarco Repository helps map it on systems (objects). |
 |
|
|||||||||||||
|
||||||||||||||||
Process reengineering with Amarco
