Activity Model of the methodology to introduce Cloud Computing IT services for government

Assessment (2/3 combined) 7301ICT (Enterprise Architecture Concepts) Activity Model of the methodology to introduce Cloud Computing IT services for government

1. The scope of the assignment

This assignment asks you to create a process model of the Methodology that was proposed in form of a Dynamic Business Model (see Appendix). The model was discussed in the week 8 lecture. The Video recording of the explanation of this model, and the associated Powerpoint file are available on the course website.

There are many ways to model processes, depending on the reason for creating the model.

In this case the purpose of the model is to ascertain what are the activities involved in the process(es) of the Project Entity, and what or who is responsible for performing those activities. Therefore you are asked to model the process as an activity model. The preferred notation for this activity model will be IDEF0. You could use the BPMN, although you would have to study how BPMN can be used for activity modelling (which is not the usual application of BPMN!).

Note that professional project management tools, such as Primavera Project Portfolio Management or Microsoft Project have built-in facilities to create activity models, however, an initial, IDEF0 model can be useful for discussion of the overall process.

The development of this model would typically be performed by the programme manager during the programme’s initial stage, and once agreed, this would then be transferred into a prortolio / program / project management tool, for continuous / ongoing maintenance and refinement.

2. The form of the assignment

You are asked to develop an IDEF0 (or BPMN) model that describes the process of introducing Cloud Computing (CC) IT Services.

The process you are modeling would include the establishement of the CC programme and its projects, which in the end define and create new systems or transform existing ones.

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

Resources to learn IDEF0 (available on 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’

(ii) HAIS/Ch10 (IDEF) (iii) Introduction to SADT

(Other tutorials are available on the www)

Example Activity model: 'Material request processing'

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

The context diagram must be accompanied by text that says:

• who prepared the model • for what purpose (documentation of existing process? individual

proposal about what the process should be? agreed process to be implemented? etc.)

• if it is a change of process relative to how things are currently done, then the value proposition (why will this process be better then the original one).

• the background that makes the reader accept that the process modelled is based on sound knowledge (e.g. th eprocess is the adaptation of a standard process, or of some other best practice reference model).

Figure 1. A-0 Process Material Requests (explanation: A-0 is the ‘context diagram’)

The first decomposition of this activity is the 'A0 diagram' (read: ‘A-zero’) 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 decompose A2, then that would be on an A2 diagram with boxes 1,2,3 representing activities A21, A22, A23, A24,...

Figure 2. A0 Process Material Request (explanation : this is the decompositin of ‘Process Material Request’)

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 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, controls enter from the top, resources (called ‘Mechanisms’) that can DO that activity [alone or if there are several then together] enter from the bottom. All Outputs leave on the right. This is a convention to make reading IDEF0 diagrams easier.

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 in prelininary 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 way to make the meaning obvious to the reader; e.g. in practice FEO ('For Explanation Only') figures, diagrams, etc. are also used.

Notes 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, the description of a procedure to be followed, 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 to the chosen mechanism).

3. What to submit

Please submit a pdf file, which includes:

• Coverpage

• an A-0 ('A-minus-zero') context diagram with accompanying text, 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 you were 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/BMPN diagram, you can use Visio, or just hand draw and scan. You may be able to find other free drawing tools as well. (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).

APPENDIX