Physical Activity Name

Post Reply
DavidScott
Posts: 1
Joined: 16 Feb 2011, 12:56

Why does the Physical Activity name keep reverting to ::Business Activity Name.

Also I may be taking the wrong approach so input would be helpful. I am currently creating a Business Activity to represent the high level process and then the Physical Activity to represent the instance. E.g. For an example the Business Activity could be Create Vehicle (it's a one person job!) and there are Physical Activities of Create Car and Create Van. The activity takes the same tasks it just needs different physical tools.

regards
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Thanks for your post.

Out of the box, Essential Architecture manager generates the names of Physical Activities are automatically from the Business Activity that is being performed and the Actor that is performing it by playing a Role.

Some background to the meta model should help.

As with the other layers, the Business Layer of the Essential Meta Model is divided into the Conceptual View (the what) the Logical View (the how) and the Physical View (actual people, locations etc.)
The difference between Business Processes and Business Activities is to some extent a question of granularity but the activities have specific semantics. Activities are the atomic constructs from which we can define business process flows - the steps in a process. These activities are sometimes referred to as elementary business processes - processes that are performed by one person at one location at one time.
Therefore, a business process can be defined in terms of a flow of steps that are either other processes or business activities.
Activities themselves can be further captured in more detail by describing the Tasks that are performed to execute the Activity.

Business Processes, Activities and Tasks describe increasing levels of detail but all exist in the Logical View, which describes how things are to be done - it's about design.
Each Business Process or Activity (or Task) is related to a Business Capability in order to model WHAT that process does. This enables us to understand accurately that two processes are fundamentally doing the same thing even if they have radically different names and are performed in radically different ways. Business Capabilities are managed in the Conceptual View.
In this approach, each different way we have of doing something is captured as a separate Business Process (Activity). We often use something in the name to help distinguish them. E.g. paraphrasing your example, we might have 'Build Car by Hand' and 'Build Car using Robots' which both build a car but do so in different ways.

Looking at your example more directly, it's a modelling decision as to whether the Capability is Create Vehicle with Processes for Create Car and Create Van or whether there is a difference at the 'WHAT' level (conceptual) between creating a van and a car, but assuming that there isn't, we might have Create Vehicle as a capability and then Create Car and Create Van as Processes (I'm thinking that these feel a bit complex to be an Activity!)

Physical Processes and Activities capture specific performance of the logical processes by teams (Group) or individual Actors. An Actor (which can be a group or an individual) plays a Role in order to perform a process at specific locations and so on. Capturing this level of information enables us to identify inconsistencies between the design of the processes and the roles that should perform them and the actuality of the Actors who are performing them and lots of other dependencies/insights.

To make modelling as a efficient, easy and consistent as possible, each Physical Process has its name automatically generated from the combination of the Process that is being performed, by whom (Actor) and the Role that they are playing in order to perform it.

Note that unlike the logical layer (which is about HOW = design), Physical Processes and Activities have no definition of the flow of steps that are performed (how they work). This 'how' is defined by the Business Process/Business Activity that they are related to. When we find that we have 2 physical processes being performed by 2 different Actors, each connected to the same logical process, e.g. 'Build Car', this tells us that each Actor is building the car in the same way. If we later find out that Actor A builds them by hand and Actor B builds them using robots, we need to define 2 separate Logical Business Processes to describe the 'how' of building a car by hand and using robots - or if we're not sure of the specific differences yet, to model that these 2 physical processes are performed in a different way.

<EDIT>
I am tempted to suggest that in your example, Create Van and Create Car are probably different processes, even if the steps are the same at a certain level of granularity because the output is different - and certain because they have different Application and Technology requirements/support (the physical tools). Remember Technology doesn't have to be Information Technology and Applications are about the behaviour. Using a tool is an application of it whether it's a spanner or SAP). I realise that that might seem a bit abstract at first, but it works very nicely. In such cases, we capture this by relating the logical Business Processes to the Application Services (tools in this example) that are used to support the execution of the process.
This is really a modelling question and it may be that the Create Van and Create Car processes are the same, logically. In which case, we can still distinguish between the tools (applications and technology) as we relate Physical Processes to the Application Providers that are actually being used. (Application Providers are the actual applications that 'provide' the Application Services that we've identified). It's through this approach that we can understand the different applications that are used to support different teams when the perform the same processes. e.g. one finance team might use Sage for their invoicing process, whereas another team in the organisation might use SAP to perform logically the same process.

If there is something different in the 'how' of Build Car and Build Van, we define a logical Process (or Activity) for each of these, then we can define Physical Processes (or Activities) to capture who is performing 'Build Car' and 'Build Van' and where.

If not, and the 'how' is the same for building a car as building a van, then we can define a single logical Process Build Vehicle, and then define Physical Processes to capture the van building team performing 'Build Van' and the car building team performing 'Build Car'. Then we can define the relationships to the van building tools (Application Provider) and the car building tools (Application Provider) (each of which are providing the vehicle building tools Application Service, perhaps) to understand the different tools requirements that the Physical Processes or Activities have.
<END OF EDIT>
Hope this helps - great question!

Jonathan
Essential Project Team
Post Reply