International Journal of Production ResearchVol. 47, No. 17, 1 September 2009, 4813–4832
A decision support framework for collaborative networks
Ovidiu Noran*
School of ICT, Griffith University, Brisbane, Australia
(Revision received April 2009)
Collaborative networks (CNs) enhance the preparedness of their participants topromptly form virtual organisations (VOs) that are able to successfully tender forlarge scale and distributed projects. However, the CN efficiency essentiallydepends on the ability of its managers to match and customise available referencemodels and often, also to create new project activities. Thus, given a particularVO creation project, the CN managers must promptly infer ‘what needs to bedone’ (discover the project processes) and how to best communicate their‘justified beliefs’ to the CN members involved. This paper proposes a frameworkfor a decision support system that can help managers and enterprise architectsdiscover/update the main activities and aspects that need to be modelled forvarious enterprise task types, with special emphasis on the creation of VOs. Theframework content is also briefly explained ‘by example’, in the context of a real-world scenario.
Keywords: collaborative networks; virtual organisation; decision support system
1. Introduction
Collaborative networks (CNs) allow their members to promptly create virtual organisa-tions (VOs) able to bid for projects whose requirements exceed the competencies of theindividual CN participants. Although most CNs maintain pools of reference models, VOprojects often require their customisation and sometimes, the creation of new specificproject processes altogether. This involves understanding the current situation, choosingthe right alternative from a set of plausible scenarios, planning the transition from presentto future states, informed selections from available technologies and other useful artefactsand importantly, communicating and justifying the decisions to the rest of the CNorganisation(s) involved. Many modern support systems such as executive dashboards,although based on decision support system (DSS) principles (Volonino and Watson 1991),focus on presenting information, rather than on actively assisting in the decision-makingprocess.
This paper aims to contribute to the CN and VO body of knowledge by describinga decision support system framework based on analysing the interactions between CNmembers involved in an enterprise architecture (EA) project in the context of their lifecycles, using elements of main architectural frameworks (AFs). The paper starts bydescribing the theoretical model underlying the proposed framework and then it describesthe main components of the framework, also considering mainstream decision support
The first component of the meta-methodology is a succession of steps and sub-stepsleading to the creation of the required VO creation/operation method and several usefulby-products (models and other documents). Guidance assisting the accomplishment ofthe steps and sub-steps has also been developed.
Step 1: Identify a list of entities relevant to the EA project. If projects are set up to buildthe target entity (entities), include them in the list.
Step 2: Create a business model showing the relations between the identified entitiesat each life cycle phase. Reassess the need for each entity presence and the extent of its lifecycle to be represented in this model.
Step 3: Using the life cycle diagram of each target entity in turn, infer a set of activitiesdescribing the creation of that entity and the roles played in it by other entities. Detail theactivities to the necessary level.
The following sub-steps are applicable to all main steps:
Sub-step a: Identify a suitable MF if applicable. Choose the aspects to model, dependingon the meta-methodology step. Resolve any aspect dependencies.
Sub-step b: Choose whether to represent only the present (AS-IS), future (TO-BE), orboth states. If both, choose whether to represent them separately, or combined.
Sub-step c: Choose modelling formalism(s) depending on the aspect(s) selected and onmodelling best-practice criteria, such as: previously used in the modelling, specialisation,prerequisites, potential multiple use, part of a family, family integration. Choose modellingtool depending on formalism and other factors (such as belonging to a suite, availability,existing skills to use it, etc.).
2.2 A structured repository
Several additional models need to be created during the application of the meta-methodology in order to obtain the main deliverable. This task is facilitated by usingappropriate references models and modelling languages, tools, methods, etc. depending onthe specific project requirements and according to best practice principles. Architectureframeworks (AFs) typically contain the required artefacts; however, the question is: whatcombination of AF components is optimal for the specific task – and in view of theparticipating organisations’ competencies? The user (e.g., enterprise architect, CIO, etc.)needs to be informed about the available AF elements’ coverage and intendedapplicability, in order to be able to make decisions later on (based on his/her existing/gained knowledge) about using some elements in preference to others. Thus, the relevantAF elements need first to be assessed in respect to their scope, prerequisites, etc. and thenorganised into a coherent structure using a set of consistent criteria; typically, this can beprovided by a reference AF.
In previous research, a pool of AF elements (hereafter called ‘structured repository’(SR)) has been created by assessing and decomposing mainstream AFs in respect to a fixedreference, namely ISO15704 Annex A (GERAM1), which has been found to contain mostof the criteria necessary for the classification of the resulting AF elements. PERA2, GRAI-GIM3, CIMOSA4, ARIS5, Zachman6 and DoDAF7 (formerly C4ISR) have been analysed
International Journal of Production Research 4815
Downloaded By: [Griffith University Library] At: 04:56 27 February 2010
using GERAM, while others such as TEAF8, FEAF9, TOGAF10 are in the process ofassessed, decomposed and added to the repository.
The AF elements represented in the repository contain attributes deemed necessary fortheir selection, including possible prerequisites and aspect coverage factors weightedfor specific life cycle phases. These are necessary because, for example, a particularAF element may have very good coverage of, e.g., the organisational aspect at therequirements life cycle phase, but weaker coverage at the architectural design phase, andmay also require selecting other AF elements (in this example, element(s) that providedecisional aspect coverage) as a prerequisite. In addition, from the assessment andclassification work it has been concluded that several AF elements may be usable fora particular aspect, life cycle phase, etc. Therefore, ranked selection lists should be used,giving the user the possibility to review and select AF elements by accepting or overridingelement ordering in the lists.
3. The decision support framework
Knowledge is present in all organisations in various forms: explicit, tacit, descriptive,procedural, reasoning, etc. Knowledge is also continuously produced (or ‘converted’(Nonaka and Takeuchi 1995)) in the organisations, often as a consequence of knowledge-intensive decision-making processes (Holsapple and Whinston 1996).
Knowledge is recognised by the management as a major enabler of organisationalagility (i.e., capability to respond timely to environmental changes), hence survival andcompetitiveness. Knowledge must be properly managed to ensure its full potential isrealised; thus, knowledge capturing, representation and processing (including the selectionof appropriate supporting technology and infrastructure (Davenport and Prusak 1998)) isa major concern of management. The use of enterprise-wide management and executiveinformation systems (MIS and EIS), expert systems, DSS and their business performance-related derivatives (such as balanced scorecards and executive dashboards) promotesorganisational learning resulting in improved decision-making that will enrich and refinethe existing body of knowledge (Klein and Methlie 1995, Power and Karpathi 1998).
Enterprise engineering tasks, whether in a CNO environment or not, often presenta semi-structured character. This is because they describe change processes of inherentlycomplex present and future organisations, and also because typically, insufficientinformation is available. This requires the management to make ‘semi-programmed’decisions (Simon 1977), which are difficult to completely encode in a program but can befacilitated by a DSS (Keen and Scott-Morton 1978).
Previous research has been aimed at assisting the enterprise architect and otherstakeholders decide on future alternatives and on change processes supporting transitionto the chosen future state. As research progressed, it has become obvious that animportant practical application of the research would be to define the principles andarchitectural design of a support system for EE.
3.1 Requirements
A successful decision support system that is initially aimed at the executive level (executiveIS) is likely to gradually expand into an enterprise-wide system embraced atseveral organisational levels, thus becoming an everyone’s (or an enterprise) IS
International Journal of Production Research 4817
Downloaded By: [Griffith University Library] At: 04:56 27 February 2010
(Wheeler et al. 1993). This beneficial possibility can be accommodated by devisinga scalable system that can start desktop-based (Power 2002) and is subsequently able toexpand to enterprise-wide level.
A system guiding EE tasks should be cooperative and interactive, allowing the decisionmaker to use his/her own insights to modify and/or refine the solutions provided by thesystem (Turban 1995). For example, users should be able to review and overridethe ordering in the ranked lists containing elements suitable for the EE problem at hand.Thus, during the interaction with the system, the user could accept the highest-rankedelement currently proposed, or select another element – thus overriding the suggestion.Interactivity and cooperation would trigger user buy-in and ownership, thus increasing theacceptance of the system; equally important, it would put to use natural knowledgemanagement skills and talents that cannot be programmed into a machine (Holsapple andWhinston 1996).
The user should be able to mark important decision points during the con-sultation process and return to these if the decisions made result in unsatisfactoryprojected outcomes. This would allow simulation of various scenarios and cycle untila suitable solution was obtained, in a process similar to that described by Hattenschwiler(1999).
Widely recognised requirements for DSS such as robustness, ease of use and control,simplicity, and sufficient relevant detail (Little 1970) can be satisfied by using trustedoff-the-shelf products that provide the necessary infrastructure, such as, e.g., web-based‘shells’ or ‘wrappers’ with a highly configurable graphical user interface. This wouldallow focusing the effort towards the knowledge base development and user interfaceimprovement, rather than on implementation details. A modular pattern of the systemcomprising a loosely coupled structured repository (preferably in a plain text contentformat) and solution generator would make the system easy to maintain, debug andupgrade.
The proposed system would also satisfy the requirements defined by Finlay (1994),namely help detect existing/imminent problems, model a problem situation to clarify it,provide the means to consider various options and help with implementation of change.Thus, the system would suggest modelling of the existing situation within an EE project if:(a) the AS-IS was not properly understood by the stakeholders; and/or (b) if the chosenfuture state could be obtained by evolving the present rather than by design from scratch.Deep understanding of the present situation by the management can often lead to thediscovery of existing problems that could not be seen before due to complexity, lack ofmodels and/or poor choice of modelling formalisms. Modelling of the future state wouldalways be necessary, with several options typically needing to be considered. This may notnecessarily result in several separate models, as combined representation of the present andfuture states is also possible if found to be feasible.
The main deliverable of the system is guidance in defining the change processes neededto migrate from the present situation to the selected future state. As with all the othercomponents, the system would not create all the activities out of ‘thin air’, but rather guidethe user in creating them based on existing domain knowledge and the models created inthe previous steps.
The main contributions of the system from the management point of view would be:(a) basing the entire approach on a life cycle (rather than snapshot) paradigm, appropriatefor the dynamic character of organisations; and (b) suggesting areas that need to berepresented in the change process as well as other additional models that would enable
4818 O. Noran
Downloaded By: [Griffith University Library] At: 04:56 27 February 2010
the present and/or the future and how to do it (separately or in a combined form) could
take the following form:
IF (TO-BE obtainable from AS-IS ) OR (AS-IS not understood)ð Þ
THEN model AS-ISð Þð1Þ
Thus, if the future state can be evolved from the AS-IS, or if the present state of the
participants is not fully understood, then model the AS-IS state. This IF/THEN structure
can be simulated using modules similar to the formalism and tool elements, where the
outcomes are the IF part, the module content is the THEN part, and prerequisites are any
dependencies. Example:
module several TO-BE f
type rule simulator == for example
prerequisites (separate AS-IS TO-BE)
outcomes (undecided TO-BE)
g
ð2Þ
Thus, if the stakeholders are undecided, or in disagreement (e.g., due to lack of common
understanding of the representation) about the TO-BE state, then the AS-IS and TO-BE
states need to be represented separately.Simon’s (1977) programmable and non-programmable decisions are reflected in this
DSS by static/dynamic facts and by user choices, respectively. The system can also support
so-called semi-programmed decisions (Simon 1977) by being interactive and allowing the
user to address the part of the problem that cannot be structured.The proposed system assists in all decision-making phases identified by Simon (1977),
i.e., intelligence gathering (via AS-IS modelling), design (via TO-BE modelling of several
scenarios), choice (via WHAT-IF simulation) and review (via the analysis of the various
scenario results). The decision maker should be able to understand the alternatives, make
Figure 4. Decision support system structure and typical outcomes of a consultation.
4820 O. Noran
Downloaded By: [Griffith University Library] At: 04:56 27 February 2010
the choice, and explain the decision to the upper and lower echelons using appropriatemodelling formalisms (selected with the assistance of the system’s logic).
In terms of Holsapple and Whinston’s (1996) classification, the proposed architecturehas a compound character, i.e., rule-oriented and solver-oriented. This is because thesystem will seek to apply elements of best practice (contained in fixed facts) and userinsights (run-time asserted facts and other user overrides) to construct a set of solutions,ordered by their suitability and presented in a form that will facilitate decision-making(Mallach 1994).
The steps and sub-steps of the underlying meta-methodology have been incorporatedas rules in the knowledge base. The inference engine can be selected off-the-shelfas long as it meets the specifications (rule-based, platform independent, etc.) andperformance requirements resulting from the architectural design of the decision supportsystem. A possible structure and typical deliverables of the proposed system is presentedin Figure 4.
3.3 Possible implementation
Currently, the bulk of the research work is directed towards: (a) extending and refining thestructured repository; (b) refining and better integrating the meta-methodology steps; and(c) developing the support system framework and testing it in real world case studies.According to current best practice, it has been considered that the architectural design ofthe system can be undertaken largely independent of its implementation and the testing ofthe support system logic can be achieved by simulation until it has reached a satisfactorylevel of maturity.
Nevertheless, small-scale pilot implementations of the DSS have been attempted usingvarious expert system shells, e.g., JESS (Friedman-Hill 2003, 2007). Such implementationshave typically comprised a (thin) client – server paradigm, using platform-independentapplet/servlet technologies, with a knowledge base containing a limited number of rules inorder to control the number of variables during testing.
4. Testing the framework: a case study
The proposed framework was tested in real-life case studies by using the rules and AFelements present in the knowledge base to simulate the behaviour of a fully implementedsupport system. The case study selected for this paper shows how a system based on theproposed framework can guide CN participants in constructing a VO in a timely manner.Interestingly, it also supports the applicability of the principles outlined in the frameworkto areas other than manufacturing.
4.1 Background
Faculty FAC within university U contains several schools (A to D), with schools A and Bhaving the same profile. School A is based at two campuses located at L1 and L2, whileschool B is based on a campus located at L3 (see the AS-IS in Figure 5). Schools A and B,although very similar, are confronted with discrepancies in their products and resources,such as programmes offered, allocated budget, postgraduate scholarship number andconditions, academic staff profile and availability, etc. This situation causes additional
International Journal of Production Research 4821
Downloaded By: [Griffith University Library] At: 04:56 27 February 2010
2009costs, difficulty in student administration and course/programme maintenance, competi-
tion for postgraduate students and staff perceptions of unequal academic and professionalstanding between campuses.
Most of these issues could be addressed if schools A and B formed a VO (calledunified school (US) in the TO-BE state shown in Figure 5) with cross-campusmanagement. The VO thus created would ensure consistency in the product deliveredand in the policies governing resource allocation to the US campuses at L1, L2
and L3. The individual campuses are set to retain much of their internal decisionaland organisational structure except for the highest layer, which will be replacedby the VO governance structure. The common ICT infrastructure of the camp-uses was to support their interoperability within the VO (Camarinha-Matos andAfsarmanesh 1999).
4.2 Specific features of the VO formation scenario
In this situation, the function of breeding environment (BE) is performed by the facultyFAC, which contains several schools forming VOs as necessary. One of the schoolsparticipating in an internal VO formation project (school A in Figure 5) is identified as thelead partner. In the current situation, partners A and B have come together at the initiative
of the BE and the lead partner (A), for the purpose of an on-going VO project.Importantly, the partners will cease to operate independently during the life of this VO.Thus, to the outside environment A and B will appear to have merged.
The audience of the VO project deliverables was to be initially the management of U,FAC, A and B (head of school, school committee, faculty dean, and board etc.) andsubsequently the staff of the organisations involved.
4.3 Framework application
The following sections simulated a cooperation of the user (e.g., enterprise architect) withthe support system. Note that the intention of the system is to use and convert the user’sdomain (and typically tacit) knowledge to new knowledge, expressed in an explicit form(via models).
Figure 5. AS-IS and TO-BE states of the proposed VO creation project.
4822 O. Noran
Downloaded By: [Griffith University Library] At: 04:56 27 February 2010
frame, a simple graphical editor was chosen in preference, being aware that it is up to the
user to check consistency across models (this would be impossible to achieve for complex
models). Some skills in using the GRAI-Grid formalism were present in the organisation.
They were used to construct the AS-IS and TO-BE decisional models as suggested by the
system rules.The AS-IS decisional model has shown in more detail some problems that have
triggered the EE project, such as a high degree of turbulence and a lack of clear and
effective strategy within the organisation. Thus, the head of school (HOS) in the role of
planner had to put out ‘fires’ (product/resource discrepancies requiring immediate
reconciliation) on a short-term basis, rather than having strategies in place to avoid the
cause of such problems. This appeared in the form of decisional frameworks (DFs) flowing
from planning towards products and resources at all horizons (denoting direct influence
at all levels from the HOS). The AS-IS decisional model has also shown a lack of
sufficient financial and decisional independence of the schools A and B and a shortage of
information crucial to long-term strategy making (shown by several DFs coming from
outside the school and by limited external information flow within the organisation).The TO-BE decisional model (see Figure 9) has attempted to address these problems
by confining the authoritarian role of the HOS to the strategic level, by increasing
the financial and decisional independence of the target VO (US), and by providing
the necessary external information to US for the purpose of strategy making and self-
governance. This is reflected in a lesser number of horizontal DFs originating from
planning, less DFs coming from outside (especially U) and increased number of
information flows. Other existing external DFs have been relocated to other decision
centres (DCs) so as to minimise turbulence and allow better self-governance.
Figure 8. Business model expressing entity roles in accomplishing the EE project.
International Journal of Production Research 4825
Downloaded By: [Griffith University Library] At: 04:56 27 February 2010
Since differences between the various TO-BE scenarios have only showed up in theorganisational structure derived from the decisional model, i.e., the allocation of thevarious human resource groups to the DCs, modelling the organisational structure wasinstrumental in distinguishing between the available TO-BE options. This observation hasalso served to further refine knowledge base rules in the structured repository.
Step 3: The set of activities describing the project accomplishment.This step represents the main purpose of the support system, resulting in a set of
activities describing how to accomplish the EE project (here, the VO creation and partialoperation). The step is accomplished by ‘reading’ the life cycle diagram of the entitiesto be designed and operated (US and ITM) and their relations with the other entitiesshown in Figure 8. The set of activities obtained is then refined and decomposed intosub-activities, using views of the selected MF (here, GERA).
Sub-step a: Aspects: functional and life cycle, but use other categories to detail activities.Motivation: the main deliverable is an activity model, hence functional. However, theactivities must be detailed using aspects from the SR and views from the selected AF, inthis case management/service with human vs machine and software vs hardware aspects(full justification for this choice is available in Noran 2007).
Sub-step b: Choose to represent both AS-IS and TO-BE states in a unified representa-tion. Motivation: the activity model is expressing the transition from AS-IS to TO-BE, thusboth states should be represented; here, separate views did not justify the consistencyoverhead.
Figure 9. Preferred TO-BE decisional and organisational situation (GRAI-Grid model).
4826 O. Noran
Downloaded By: [Griffith University Library] At: 04:56 27 February 2010
for a basic explanation of its elements). Select AI0Win tool (KBSI 2008). Motivation:
UML and IDEF0 are both suitable; UML ranks higher than IDEF0, due to integratedmetamodel present and wider tool support. However, in this case, the availability of theAI0Win modelling tool and of the IDEF0 skills was an overriding factor. AI0Win is alsosemi-integrated13 with information/resources modelling (‘SmartER’) and behaviourmodelling (‘ProSIM’) tools, similar to a ‘suite’, thus ensuring some degree of modelconsistency. Therefore, overall IDEF0 and AI0Win were considered a suitable choice inthis particular case.
4.3.1 Creating the activity types in Step 3
A set of activities must be inferred for each life cycle phase represented in the businessmodel. Thus, the functional model can be initiated by creating one main activity foreach life cycle phase identified in the business model (such as shown in Figure 11).The modelling formalism (language) chosen to represent the model will assist indeveloping the model. For example, IDEF0 requires that inputs, controls, outputs andmechanisms (also called ICOMs) are defined for these activities (see Figure 10; notethat inputs can be omitted if justified). Therefore, the user has to give considerationto what is used in the activity, what controls it, what is produced by the activity andwho/what executes it. This information can be construed from the roles shown in thebusiness model and domain knowledge of the enterprise architect and participatingstakeholders.
Each activity must be recursively decomposed down to a level where it can bedirectly executed14; this can be assisted by a ‘checklist’ of views used in previous stepsand/or the chosen MF (if any) and/or available in the MFs contained in the SR.For example, if GERA’s MF is chosen, the checklist contains function, information,resources, organisation, management vs production/service, human roles and hardware/software.
Note that not all views and aspects are always relevant. Examples: (1) early life cyclephases (e.g., identification, concept) require few, or just one aspect; and (2) the humanaspect may only be visible and relevant starting from the preliminary/detailed designphases, such as illustrated in the structure shown in Figure 6, left.
4.4 Example: creating the second level of the functional model
Figure 8 shows that the US entity is influenced by the university U, across campusconsistency (ACC) project and by the project that builds it, namely ITM.
The first phase in the life cycle of US is the identification of the need for this artefact.However, in this case, domain knowledge obtained from stakeholders has established thatthis phase has already been accomplished by U, i.e., the PVC has determined the need fora unified school and mandated its creation; thus, in this case identification has occurredexternally and does not need to be represented in the activity model.
The concept phase is accomplished under the control of the mandate from PVC, ACCreviews that show what needs to be addressed and university U’s policies. The work todefine the concept of US is carried out by a working party composed of staff belongingto U, the majority of which are also staffing the ITM project. No inputs are present.The outputs reflect the creation and refinement of the US concept, such as goals,objectives and responsibilities of the US.
The main changes brought by the ITM project are in the management area. Thus, therequirements definition process needs to investigate suitable management structures and inaddition, make needed corrections to the US concept. For this purpose the requirementsactivity needed to contain the creation and use of the business model (Figure 8) and thedecisional/organisational structures (whose selected TO-BE state is shown in Figure 9).Such sub-activities are shown in Figure 12.
In this case study, only organisational models were able to discern between variousTO-BE states. Therefore, the preliminary design phase must develop models showing
Figure 11. IDEF0 activity model for the VO creation and operation (2nd level).
4828 O. Noran
Downloaded By: [Griffith University Library] At: 04:56 27 February 2010
organisational structures that reflect various scenarios and seek stakeholders’ selection ofthe most suitable solution. The detailed design activity was also decomposed according
to the GERA implementation criterion, showing management vs production/service and
human roles. Further decompositions then discerned between hardware and software-oriented activities. Detailed descriptions of the activity model creation and structure is
beyond the space available and purpose of this paper and is contained in Noran (2006a,b,
2007).
5. Conclusions and further work
CN management involves complexity, politics, and uncertainty. A DSS can help managersunderstand and isolate problems, examine scenarios, predict outcomes and thus make
informed decisions. In this regard, the proposed support system framework has several
distinctive features:
. it is supported by an original and tested theoretical concept;
. it is based on a life cycle paradigm, appropriate for the dynamic nature of
organisations;. it uses mainstream AF elements (while neutral in respect to any AF);. it suggests areas that need to be represented in the change process via suitable
models that assist managers and enable them to unambiguously communicate
their vision to the rest of the organisation.
An essential success factor of a system based on this framework is the domain knowledge
owned by the stakeholders. The proposed system cannot effectively assist the decision-making process within a business or collaborative network whose management lacks
Figure 12. Possible decomposition of the requirements activity (3rd level IDEF0 model).
International Journal of Production Research 4829
Downloaded By: [Griffith University Library] At: 04:56 27 February 2010
a basic understanding of the way ‘things work’. However, as such knowledge is alsoessential for the survival of the business and network, it is bound to exist in some (perhapstacit) form in the average company. The system can help elicit, formalise and use thisknowledge to support and optimise decision-making.
While test results have been encouraging thus far, substantial work lays ahead. Theframework must be tested, refined and extended. Pilot implementations and further casestudies will greatly assist towards these endeavours.
Acknowledgement
Part of this work has been supported by a New Researcher Grant within Griffith University,Australia.
Notes
1. The Generalised Enterprise Reference Architecture and Methodology (ISO/TC184 2000).2. The Purdue Enterprise Architecture Framework (Williams 1994).3. Graphs with Results and Activities Interrelated (Doumeingts et al. 1998).4. Open System Architecture for Computer Integrated Manufacturing (CIMOSA Association
1996).5. ARchitecture for Information Systems (Scheer 1992, 1999).6. The Zachman Architecture Framework (Zachman 1987).7. Department of Defence Architecture Framework (DoD Architecture Framework Working
Group 2004).8. Treasury Enterprise Architecture Framework (Treasury CIO Council 2000).9. Federal Enterprise Architecture Framework.
10. The Open Group Enterprise Architecture Framework (The Open Group 2006).11. For a relevant example of reference models being used in EE see Noran (2006b).12. Generalised Enterprise Reference Architecture (ISO/TC184 2000). Note that a more specialised
framework described in Zwegers et al. (2002) was also usable.13. ‘full’ integration would be based on a common underlying metamodel for all IDEF languages;
this is currently not available.14. When to stop decomposing? One factor in establishing the necessary level of granularity of an
activity are the capabilities/qualifications of the resource (human and/or machine) that willexecute the activity in question
References
Camarinha-Matos, L.M. and Afsarmanesh, H., 1999. Infrastructures for virtual enterprises. Norwell,
MA: Kluwer Academic Publishers.
CIMOSA Association. 1996. CIMOSA – open system architecture for CIM. Technical baseline,
ver 3.2. Private publication.
Davenport, T. and Prusak, L., 1998. Working knowledge. Boston, MA: Harvard Business School
Press.
DoD Architecture Framework Working Group. 2004. DoD architecture framework version 1.0
[online]. Available from: http://www.dod.mil/cio-nii/docs/DoDAF_v1_Volume_I.pdf
and http://www.dod.mil/cio-nii/docs/DoDAF_v1_Volume_II.pdf [Accessed 14 February
2007].Doumeingts, G., Vallespir, B., and Chen, D., 1998. GRAI grid decisional modelling. In: P. Bernus,
K. Mertins and G. Schmidt, eds. Handbook on architectures of information systems.
Heidelberg, Germany: Springer Verlag, 313–339.
4830 O. Noran
Downloaded By: [Griffith University Library] At: 04:56 27 February 2010
Finlay, P.N., 1994. Introducing decision support systems. Manchester, UK: Blackwell Publishing.Friedman-Hill, E., 2003. Jess in action: java rule-based systems. Cherokee Station, NY: Manning
Publications.Friedman-Hill, E., 2007. JESS – The rule engine for the Java platform [online]. Available from:
http://herzberg.ca.sandia.gov/jess/ [Accessed 14 February 2007].GRAISoft, 2002. IMAGIM software product [online]. Available from http://www.graisoft.com
[Accessed 3 August 2002].Hattenschwiler, P., 1999. Neues anwenderfreundliches konzept der entscheidungsunterstutzung.
Gutes entscheiden in wirtschaft, politik und gesellschaft. Zurich: vdf Hochschulverlag AG.Holsapple, C.W. and Whinston, A.B., 1996. Decision support systems: a knowledge-based approach.
St. Paul, MN: West Publishing.ISO/TC184. 2000. Annex A: GERAM. ISO/IS 15704: industrial automation systems – requirements
for enterprise-reference architectures and methodologies. Geneva: International Organization
for Standardization.Kalpic, B. and Bernus, P., 2006. Business process modeling through the knowledge management
perspective. Journal of Knowledge Management, 10 (3), 40–56.KBSI. 2008. AI0Win software product [online]. Available from: http://www.kbsi.com/Software/
KBSI/AI0WIN.htm [Accessed 31 October 2008].
Keen, P.G.W. and Scott-Morton, M.S., 1978. Decision support systems: an organizational
perspective. Reading, MA: Addison-Wesley.
Klein, M. and Methlie, L.B., 1995. Knowledge-based decision support systems with applications in
business. Chichester, UK: John Wiley & Sons.Little, J.D.C., 1970. Models and managers: the concept of a decision calculus. Management Science,
16 (8), B466–B485.Mallach, E.G., 1994. Understanding decision support and expert systems. Homewood, IL: Richard D.
Irwin.Marakas, G.M., 1999. Decision support systems in the twenty-first century. Upper Saddle River, N.J.:
Prentice Hall.NIST. 1993. Integration definition for function modelling (IDEF0). Federal Information Processing
Standards Publication, report number FIPS PUB 183. Computer Systems Laboratory,
National Institute of Standards and Technology.Nonaka, I. and Takeuchi, H., 1995. The knowledge-creating company. How Japanese companies
create the dynamics of innovation. Oxford, UK: Oxford University Press.Noran, O., 2004a. A meta-methodology for collaborative networked organisations. Thesis (PhD)
unpublished. School of CIT, Griffith University, Australia.Noran, O., 2004b. Towards a meta-methodology for collaborative networked organisations. In: L.
Camarinha-Matos, ed. Virtual enterprises and collaborative networks. Nowell, MA: Kluwer
Academic Publishers, 71–78. [Proceedings of the 5th IFIP working conference on virtual
enterprises – PROVE 04, Toulouse, France.].Noran, O., 2006a. Refining a meta-methodology for collaborative networked organisations: a case
study. International Journal of Networking and Virtual Organisations, 3 (4), 359–377.Noran, O., 2006b. Using reference models in enterprise architecture: an example. In: P. Fettke and
P. Loos, eds. Reference modeling for business systems analysis. Hershey, PA: Idea Group,
141–165.Noran, O., 2007. Discovering and modelling enterprise engineering project processes. In: P. Saha, ed.
Enterprise systems architecture in practice. Hershey, PA: IDEA Group, 39–61.Power, D.J. and Karpathi, S., 1998. The changing technological context of decision support systems.
In: D. Berkeley et al., eds. Context-sensitive decision support systems. London: Chapman &
Hall, 41–54.Power, D., 2002. Decision support systems. Concepts and resources for managers. Vol. 2007,
Westport, CT: Quorum Books.Scheer, A.-W., 1992. Architecture for integrated information systems. Berlin: Springer-Verlag.
International Journal of Production Research 4831
Downloaded By: [Griffith University Library] At: 04:56 27 February 2010
www.eaframeworks.com/TEAF/teaf.doc [Accessed 14 February 2007].Turban, E., 1995. Decision support and expert systems: management support systems. Englewood
Cliffs, NJ: Prentice Hall.
Volonino, L. and Watson, H.J., 1991. The strategic business objectives method for guidingexecutive information systems development. Journal of Management Information Systems,7 (3), 27–39.
Wheeler, F.P., Chang, S.H., and Thomas, R.J., 1993. Moving from an executive information system
to everyone’s information system: lessons from a case study. Journal of InformationTechnology, 8 (3), 177–183.
Williams, T.J., 1994. The Purdue Enterprise reference architecture. Computers in Industry, 24 (2–3),
141–158.Zachman, J.A., 1987. A framework for information systems architecture. IBM Systems Journal,
26 (3), 276–292.
Zwegers, A., Tølle, M., and Vesterager, J., 2002. VERAM: virtual enterprise reference architectureand methodology. In: I. Karvoinen et al., eds. Proceedings of global engineering andmanufacturing in enterprise networks (Globemen). VTT Symposium 224, Helsinki, Finland,1738.
4832 O. Noran
Downloaded By: [Griffith University Library] At: 04:56 27 February 2010
