Enterprise Architecture Concepts

Activity Model of the process of the transformation programme

1. The scope of the assignment

This assignment asks you to create a process model of the Methodology that you proposed in form of a Dynamic Business Model, describig the way the Federal Government could go about initiating and orchestrating the Energy Transition Plan

Your process model should describe the main activities, which the government (and other participants in the programme) should perform to implement the energy transition in Astralia. (Do not make the mistake of trying to describe how an end user can move to adopt a given emission reduction technology, that may be interesting but it is not the question in this assignment).

The purpose of the model is to ascertain what are the activities involved in the process(es) of the Programme Entity, and what or who is responsible for performing those activities (the programme would have multiple contributors)

Please model the above process in form of an activity model. The preferred notation for this activity model will be IDEF0. You could use the BPMN language as an alternative, although you would have to study how BPMN can be used for activity modelling (which is not the usual application of BPMN!).

2. The form of the assignment

You need to develop an IDEF0 (or BPMN) model of the above process.

Resources to learn IDEF0 (available on the course website):

(i) The original article by Ross, D. (1977). Structured Analysis (SA): A Language for Communicating Ideas. IEEE Transactions on Software Engineering, SE-3, 1 (Jan. 1977). 16-34. [Note: IDEF0 is the same as SADT's ‘Actigrams', you can ignore datagrams.]

(ii) HAIS/Ch10 (IDEF0 and IDEF3 - you only need to study IDEF0)

(iii) Introduction to SADT (this is an old document which explains how teams use SADT (actigrams and datagrams, but you only need actigrams)

(iv) ... other IDEF0 tutorials are available on the www

A brief example of an IDEF0 activity model is below

Since most students would have no experience with activity modelling, below is an example as well as advice, regarding how you could proceed.

3. Example Activity model: 'Material request processing'

The top level diagram is called the A-0 diagram (read: 'A-minus-zero' diagram). A- 0 defines the context and contains only one activity box (see Fig.1). ['A' stands for 'Activity']

In your assignment the A-0 diagram must be accompanied by text that explains:
- Who prepared the model
- For what purpose (is this the documentation of an existing process? or an individual proposal about what the process should be? or an agreed process to be implemented? or ...)
- The background that makes the reader accept that the process modelled is based on sound knowledge (e.g. the process is the adaptation of some standard process, or of some other best practice reference model (e.g., in this case the process is a refinement of the transformation process described in your dynamic business model).

The first decomposition of this activity is the 'A0 diagram'

(read: the ‘A-zero' diagram) that contains activity boxes A1, A2, A3 etc...

On the next page (Fig.2) you will find an 'A0 diagram' of the activity called 'Process material requests'.

If you wanted to further decompose an activity present in A0, such as A2 (‘Resolve request problems'), then that would be on a separate A2 diagram with the title ‘Resolve request problems' in which boxes 1,2,3 represent activities A21, A22, A23, A24,...

Notice that every arrow - except those whose ends are enclosed in brackets ‘( )'

- continues on A-0. Arrow continuity is generally to be enforced on IDEF0 diagrams. The ‘( )' is the notation for a 'tunnelled arrow' which means that the input/output/control/mechanism (ICOM) is there, but on the diagram above you did not consider it relevant to show for someone to understand the context.

Tunnelling should be used sparingly, usually to avoid crowding the diagram.

The little 'squiggly line' symbol is very useful to show which text belongs to which arrow.

All Inputs enter from the left (normal inputs that the activity transforms), and control inputs (inputs that influence the activity but are not transformed) enter from the top. Inputs can be objects or information. Mechnisms and the resources that actually perform the activity [alone or if there are several then together] enter from the bottom. On high level diagrams the mechanisms are usually complete organisations or organisational entities or perhaps complete systems, but on lower level diagrams they can be human roles or machines (however, given the high level view of this assgnment it is unlikely that you will get to such detail).

All Outputs (objects or information) leave on the right. This is a convention to make reading IDEF0 diagrams easier. It happens that the input and the output are the same kind of object, but in different state, and the name of the corresponding arrows should reflect this difference.

Important: the boxes represent activities and the arrows represent interfaces between them. An activity diagram does not intend to say anything about when the activities are performed. E.g., the above A0 diagram (Fig.2) represents activities (activity types to be precise), instances of which are, or may be, performed in parallell. We say that an IDEF0 diagram represents the 'functional architecture' of a system.
Also note that strictly speaking the Mechanisms need not be represented in the requirements specification phase, since ‘who does what' is a preliminary (architectural) design decision. However, often there is no choice, or the IDEF0 diagram just specifies a very high level decision, e.g. 'Data Systems' in the above diagram has no structure - i.e. the components of the 'Data System' will only be decided by preliminary design. So, in the assignment you are free to use Mechanisms, in addition to I,C and O arrows.

Finally, it must be kept in mind that when an IDEF0 diagram is developed, the diagram is intended for someone to read and interpret what the author of the diagram intended to say. Even with more formal specifications, it is important that symbols that are not further specified are 'grounded' in reality in the way they were intended. For this reason every 'terminal symbol' needs some textual explanation, or other illustration, to make the meaning obvious to the reader; e.g. in reallife practice FEO ('For Explanation Only') figures, diagrams and pictures etc. are also used instead of just text.

A note about Control arrows: (i) Every activity mush have at least one control;

(ii) There are various kinds of control that guide the process: the control may be an order or request, a policy or set of principles, the description of a procedure to be followed, a reference model, or an event.

Mechanisms must have the ability to interpret the control (e.g., mechanism must understand instructions on the level of detail they are given, or conversely, instructions must be specified in a manner and to the level of detail that is comprehensible by the chosen mechanism).

4. What to submit

Please submit a pdf file, which includes:

- Coverpage

- an A-0 ('A-minus-zero') context diagram with accompanying text (say a paragraph), stating the author, purpose and status of the model,

- an A0 diagram, which is the decomposition of the single activity box shown on the A-0 diagram. Provide a short explanatory text, as if using the diagram as a presentation slide to explain the process to someone,

- the decomposition of at least one activity from A0 (e.g. an A2 diagram), with a short explanatory text, again as if you were using the diagram as a slide to explain the details of the process to someone.

Note: to draw an IDEF0 diagram, you can use Visio (which has a built-in IDEF0 tempate), or just hand draw neatly and scan. You may also be able to find free drawing tools as well, but do not spend too much time searching. (If you draw by hand, you are well advised to use paper and pencil, the eraser will be needed frequently!)

In the same way as in Assignment 1, you may (if you wish), work in a group (maximum 3 students in a group, and only one student from the group should submit).

Attachment:- feedback.pdf