ACTA UN IV ERSITA TIS LO D ZIEN SIS FOLIA OECONOM ICA 157, 2002
N igel M artin Shirley Gregor D ennis H a r t" C Y C L I C A L I G N M E N T A N D E L E C T R O N I C C O M M E R C E S Y S T E M S : T H E R O L E O F E N T E R P R I S E A R C H I T E C T U R E S A g ile e -c o m m e r c e s y s te m s a re re q u ir e d in a w o rld in w h ic h th e e n v ir o n m e n t a n d c o rp o r a te str a te g y c h a n g e rapidly. H o w e v e r str u c tu r e d fo r m a l a p p r o a c h e s su c h a s th o se p r o v id e d b y e n te r p ris e a r c h ite c tu r e s ( E A ) a r e still re q u ir e d fo r large, g lo b a l sy ste m s. It is s u g g e s te d th a t th e d e g r e e to w h ich an EA fr a m e w o r k a llo w s f o r a cy c lic a lig n m c n l p ro c e ss s h o u ld he a ssessed . T h is p r o c e s s in v o lv e s b o th in te g ra tio n a n d fe e d b a c k /e x c h a n g e m e c h a n is m s a m o n g the c o m p o n e n t p a r ts o f a n EA. A review o f se v e r a l p r o p r ie ta r y EA fr a m e w o r k s s h o w s a ll fr a m e w o r k s e x c e p t f o r th e Z a c h m a n a r c h ite c tu r e o ffe r s u p p o r t f o r a n in te g ra tin g stru ctu re. M o s t lin k th e ir c o n s titu e n t m o d e ls w ith fe e d b a c k a n d e x c h a n g e ch a n n els, th o u g h s o m e c h a n n e ls a re u n id ire c tio n a l. N o n e o f th e s e le c te d a rc h ite c tu re s, e x c e p t f o r ARI S, h a v e a d is c e r n ib le fe e d b a c k lo o p to c o r p o r a te re q u ir e m e n ts sp e c ific a tio n .
introduction
System s engineering processes that incorporate Enterprise A rchitecture (EA) concepts are sufficiently well understood for logical and physical system s to be designed and constructed. The enterprise architecture in its m ost sim ple form is a logical structure for classifying and organising the descriptive representations o f an enterprise that are ‘significant to the m anagem ent functions o f the enterprise (that is, planning, leading, organising and controlling)
School o f Business and Information Management, Australian National University, Canberra ACT 0200, Australia, E-mail: Niael.Mariiri@dcfcncc.gov.au
School o f Business and Information..., E-mail: Shirlcv.GregoKffanu.cdu.au (corresponding author)
as well as to the developm ent of the enterprise’s inform ation system s (Zachm an, 1996). There is evidence to suggest that enterprise architectures exhibit a strong practical application in com m ercial and governm ent entities (Zachm an, 1996).
U nfortunately, enterprise m anagem ent and system s engineering processes, by their nature, tend to be protracted, with longer and m ore com plex developm ent cycles than might be considered optimal in fast moving e-com m erce environm ents. For exam ple, som e recent views on e-com m erce developm ent m ethodologies (Pres-H eje and Baskerville, 2001) show tendencies tow ards am biguous and fluid user requirem ents specification, widespread prototyping, frequent system releases and parallel developm ent processes; all characteristics that do not fit well with the way in which enterprise architectures typically develop and evolve.
An exam ple from industry illustrates the m otivation for the current study. A large organization decided to im plem ent an enterprise-w ide system after m anagem ent adopted a new corporate e-com m erce strategy - virtualization of the organization (W assenaar, G regor and Sw agerm an, 2002). A formal plan was produced, a well-know n ERP vendor selected, a budget agreed and a firm of consultants engaged to oversee im plem entation. From this point on the details of an EA were defined. Tw o years into the project, organizational m anagem ent were told that it was not possible to com plete the project without investm ent of additional significant funds. At this point a m em ber of the senior m anagem ent group adm itted that they had very little choice but to allocate the extra funds - they no longer had any real understanding o f what was being done by the project team. M oreover, in the intervening two years the organizational environm ent had changed and variations to organizational strategies were required. The project team, however, were com pletely occupied with the original project specification, and were mostly unaw are o f any change in requirem ents. Proponents of some EA fram ew orks would argue that an EA in this situation would serve as a tool for some com m on understanding, allow ing two-way com m unication between system architects/builders and m anagem ents strategists. In this case, the EA did not fulfil this role.
O ur deduction is that an EA fram ew ork should allow for what we term a
cyclic alignm ent process. Any system constructed should be aligned with
corporate goals. In addition, this alignm ent must be regarded as a cyclic process in the e-com m erce environm ent. M anagem ent must have sufficient understanding on an ongoing basis of what is being im plem ented to ensure that corporate strategies are being attained, and project staff m ust have an ongoing understanding of any changes in corporate strategy.
Thus, our aim in this paper is to exam ine how enterprise architecture fram ew orks can assist with the rapid evolution o f e-com m erce system s that are aligned with corporate objectives. That is, how can an enterprise architecture support cyclic alignm ent? O ur study is significant as this aspect o f EA appears to have received relatively little attention.
The paper proceeds by first outlining the sparse literature that relates to the evaluation o f EA fram eworks and the concept o f cyclic alignm ent. A num ber of proprietary EA fram ew orks are then evaluated in term s o f attributes that can support cyclic alignm ent. The paper concludes with lessons learned from this evaluation of EA fram eworks.
C onceptual background
E v a l u a t i o n o f E A f r a m e w o r k s a n d c y c l ic a l i g n m e n t
An enterprise architecture for a particular organization will incorporate a num ber o f different m odelling tools or representations o f different aspects o f the organization com bined in a structured manner. The different representations or tools incorporated, and the m anner in which they are structured, will depend on the particular EA fram ework adopted by the organization. Exam ples o f proprietary fram ew orks include the Zachm an EA fram ew ork (Zachm an, 1996), CIM -O SA (K osanke and V lietstra, 1989), ARIS (Nagel, 2001), and the M eta Group EA (W estbrock, 1999).
We can find no previous work that proposes an overall set o f criteria for evaluation of EA fram ew orks in a system atic way. C riteria that have been used in the evaluation of other, lower-level, m odelling tools, include ontological com pleteness and clarity (W and and W eber, 1995), support o f principles o f good decom position (W eber, 1997), and sim plicity and understandability (N avathe,
1992).
W ith respect to EA fram eworks, Croteau et al. (2001) suggest “good enterprise alignability” as an additional criterion. The work o f these authors suggests that the EA construct must be capable o f facilitating enterprise alignm ent within the user context. Users must be able to use the EA to co-align business and inform ation system objectives. This is achieved through the interactive consideration and joint developm ent o f enterprise strategy and system s, allow ing both to be optim ally m atched.
A related concept is that o f “enterprise integration” (W eston, 1999; V ernadat, 2000).
W eston (1999) concluded that it has becom e possible for an enterprise to capture, develop and apply formal m odels of itself, and over successive time periods use these m odels to decide how it might respond to new opportunities and threats. This Integration Structure is then applied to the various real (e.g., operational or resources) and virtual (e.g., business or process) com ponents ot the enterprise to enable change. W eston’s research (1999) points to system com ponents that will be small- or large-grained depending on the function. In order to facilitate change and reuse, the com ponents will have an integration capability that will be capable o f registering and accessing integration services from the ‘Integration Infrastructure’. The Integration Structure and Infrastructure are highly com plem entary and equally required for system evolution. Figure 1 shows the Integration Structure and Infrastructure concepts.
W eston (1999) dem onstrated that the application o f an Integration Structure to Enterprise M odels enables rapid system design, reconfiguration and on-going system developm ent. The research shows that the result ol a m odel-driven, com ponent based approach to system s engineering is that the resultant system will have an inherent capability for radical or wide sw eeping change. The em bedded ‘change ethic’ should yield resource efficiencies, subject to well defined system decom position and com ponent design.
aysfem rf ft&übty configured.
kveiY-ctefmed таэзЫв сстрспепСэ
V ernadat (2000) supports the use of an Integration Platform or Structure and the associated Infrastructure. V ernadat (2000) also actively prom otes the use o f reconfigurable, distributed agent-based architectures or m odels. T his usage involves each model behaviour being im plem ented as an agent, and each model designed for easy m odification or expansion without recom pilation o f the whole model.
From the above we can see that EA fram eworks should offer support for alignm ent and integration. There is, however, com paratively little discussion of the processes that allow the EA fram ew orks to be used effectively in support o f these goals. Here we are talking about processes in the sense o f change m anagem ent processes, or system developm ent processes, rather than the actual business processes that are m odelled within a system.
W e propose that an additional construct, fe e d b a c k , m ust be considered when assessing support for cyclic alignm ent. Feedback and com m unication exchange m echanism s are needed in an EA to provide a conduit for evolving system s and translating virtual artefacts (e.g. corporate requirem ents) into physical artefacts (e.g. the deployed inform ation system ). T hese feedback and exchange m echanisms can be uni or bi-directional and can take the form o f services that allow inform ation to be passed between several views.
In the general system sense, Sahakin (1970) states that feedback and exchange m echanism s need to be capable o f ‘confirm ing know led ge’ and ‘facilitating corrective action’ where changes occur or faults m anifest. Sahakin (1970) also asserts that feedback and exchange o f inform ation m ight also facilitate judgem ent of the necessity for change based on consequences or outcom es from adopting the change.
Overall, any adopted feedback and exchange m echanism s should be optim ally connected to ensure sufficient cohesion with m inim al coupling or constraint. A llow ing the m echanism s to pursue and attain a suitable balance or equilibrium o f connectivity will ultim ately determ ine their success in evolving to the next stage of developm ent and m eeting environm ental change.
Figure 2 illustrates the need for feedback and com m unication exchange m echanism s in the process o f cyclic alignm ent involving an EA. It is necessary to com m unicate corporate requirem ents and constraints through to m odels constructed, but it is also necessary for inform ation about these constructed artefacts to be fed back, and understood, by corporate m anagem ent.
From the foregoing, we conclude that a good EA needs to be com plete, clear, well aligned, understandable and capable o f being evolved as the environm ent changes. Tw o attributes in particular are seen as necessary for cyclic alignm ent: (i) the inclusion of an integration structure and (ii) the
provision of feedback and exchange m echanism s. In the follow ing sections several EA fram ew orks are described and evaluated with respect to these attributes.
fE E M M C K O R REV ERSE T R A N S I T IO N
Figure 2 Feedback and exchange mechanisms needed lor cyclic alignment process
E nterprise architectures
T his section describes the features of a num ber of enterprise architecture fram eworks: Zachm an, CIM -O SA , ARIS and M GEA.
The Zachm an EA
Figure 3 shows the graphic depiction o f the Zachm an Enterprise Architecture Framework.
The Zachm an fram ew ork is built on the analogous structures that are found in the historical disciplines o f public and private sector building, construction and m anufacturing. These disciplines classify and organise their realised artefacts as the com plex products are produced. The fram ew ork depicts the design artefacts as the interconnecting relationship between the role players in the enterprise and the product abstractions.
The Zachm an fram ew ork tends to be generic in nature and may be applied to any enterprise in the private or public sector.
r
ENTERPRI SE A R CH IT ECT UR E - A F R A M E W O R K IU
DATA и * , , F U N C T IO N H tm N E T W O R K W h rff P E O P L E H k. T M E l»>w. MOTIV AT»ON » * , (CO N TEX TU AL)
ľlrnnnrt
to Iht Би
■
B tK M U Pertom» tba B n a ax il Oparalaa■w
Hoot * M at« t m m iВ
te Iba D o b t u g I t « Ы В л г а я G o ato 'S ra1
S C O P E (C O N TEX TU A L) П я а г т FWTlT» C. la«» el Ttunq fumc toti - C tm i ЫB u i n » » PfOC«*» Taea * Mate* B n a a u E real E n a » M a e * » * M a t - 5 ® e * C načal S maca at FaO w E N T E R P R IS E MODEL (C O N C E PT U A L ) O vm rt • g Semantic 11яМ Em i B u t n t u Entity Rem . Виетеаа ReUi.antłur
e g Busaieai Ptoevt? Medal
— Proc « S m o u Procaaa
VO - Businas» Reworoaa
Modr ■ Business location LM . Business i mtage
e g Wei* Fto* Medal
W or» a »< •» Pfbduci
а д Maat«! Scti*4uta
C »cic . Busanau Crete
• 4 b a m > P a n End - B u u m t OM actet Maana • Buwnama S m u g i t N T E R P » S € M ODEL (C O N C E P T U A L ) O m SY S T EM MODEL (LOGICAL) • g L е д к а ' П аи Modal EM • Data tm tv Rein • Dala ЙеЫюпагир a e Aj>p»e»ter> rc tu n . _ d b _ Ю . Uaa. Via an'
a g Dislrfeuted Srssen-. Node > IS Function IPnifM M i Sim» » Mr.i Lmfc . 1 me Сh a ra e .a rtd e t • 8 Н ш а п >-ла-ас« Pea»!» . Rota W tA . М и я Ы а t | Processing S v u d i n
ТЦГ
U yoa = Hrecessmg v y d áa « Busmess Aute Mede* S Y S T E M M ODEL (LOG ICA L) T E C H N O L O G Y MODEL (PH Y SICA L) tm U érr
a g Ptqraieal Oala Modal
±1
EM « Sagt-wm/Tafcle-elc 1 Rełn > РоеЦегЖеу Wc a g SyVam DesignJL
ргос » Сотрш ег F imcbon WO . Dala Elements'S * * a g 'eebnoiogy А г е М а о лN oat • Mantware Sratatr’
Softwei* Peogte • User Wort.. Sem« F a m a • g Coad**l Strúca»*
'Ч.
Т а м , E .acute • g R e t e ^ g rJÉL
E n d . Cm H » T E C H N O L O G Y M O D EL (PH Y SIC A L ) в * . U rr D ETAILED R E P R E S E N T A TIO N S (O U T O F -C O N T E X T ) Caniractmr а д Data D flM ior EM - Field Rain . »Mi.ii ш VO I C ^ M B t e a Slm< a s I łtla e r t b d K K l v t i Lmfc • Protocol* a g SecwMy Ar^>tociun1
Peoote . Idawfr Wot* . Job a g T e a m g D e M e nB
Таи* • M erne*C»c*a • MacTww Cycte
3
Maana « Step DETAILED R E P R E S E N TA TIO N S (O U T -O F C O N T E X T ) Ш -FU N C TIO N IN GE N T E R P R IS E • *O A TA FUNCTION * * K£TWO*iK e g OßSAKCATION « в SCHEOUlE • « .S T IW E S Y FU N C T Ю N IN G E N T E R P R IS E
Jo h n A. Z a c h m a n . Z a c h m a n In te rn a tio n a l (8 1 0 ) 2 3 1-0531
Figure 3 The Zachman Architecture Framework
-j vC C y cl ic al ig n m e n t an d ele ctro nic c o m m e rc e ...
C om puter Integrated M anufacture-O pen System s A rchitecture (C IM -O SA)
C IM -O SA is a enterprise operation im provem ent architecture configured as an integrated architecture (K osanke and Vlietstra, 1989). T he explicit description of the enterprise allows all internal and external processes and relationships to be mapped against the com plete system description. C IM -O SA is a guiding construct for the design and delivery of the com plete enterprise and all associated business functions (eg, m anufacture, m arketing, finance, adm inistration, etc). Figure 4 illustrates the CIM -O SA cuboid.
Gcneric Partial Particular
Building Models Model
[Blocks
Three Levels of Generieity
Siepwisc Instantiation
CIM -O SA has two m ajor constructs that support enterprise integration. The Integrating Infrastructure (II) provides application integration, while the M odelling Fram ew ork (M F) supports business integration. II provides four service sets as follows:
> Functional Services providing m anagem ent control and execution o f enterprise activities. These services integrate B usiness Process C ontrol, Activity C ontrol and Resource M anagem ent.
r Inform ation Services support inform ation processing for the enterprise. These services locate, access, store and m aintain inform ation and data sets. These services fuse enterprise wide information.
> C om m unication Services control Intra and Inter system com m unications. These services provide integrated com m unications across the enterprise. > Front F.nd Services provide the interface control betw een com m unications,
hum ans, m achines and applications. These services are interface controllers and form key integration nodes.
There are three specific m odelling levels that form part of the C IM -O SA fram ework:
> R equirem ents Definition Level that m odels business requirem ents for the com plete enterprise. These requirem ents are depicted in term s o f processes, inputs, outputs and procedural rules, describing what must be done in the business.
r Design Specification Level that models the design of the business processes and enterprise activities describing how the activities are perform ed. Param eters are specified, output size is defined and constraining factors exam ined.
> Im plem entation D escription Level is the ‘executable’ level that selects the entities (ie, personnel, program s, etc) required for the process at the requirem ent level. The entities are selected on the basis o f the design specifications and must be acquired if they are not resident. The flow dow n from requirem ents to im plem entation is underpinned by com puter program m ing (or softw are design).
The views that are facilitated by C IM -O SA are as follows:
> Function view is a depiction o f the enterprise in term s o f the structured business processes. Each process is constrained by its procedural rule set that is in turn defined by event triggers and results. A high level business process can be m ade up from a series of base level enterprise activities.
> Inform ation view is the aggregate o f all enterprise inform ation. The inform ation is decom posed into classes and enterprise inform ation objects, with object views and editions encapsulated in dom ains that are determ ined by the design. All inform ation is formed by inform ation elem ents, the sm allest addressable unit.
> R esource view contains all relevant inform ation about the enterprise resources, and is formed through the hierarchical assem bly o f m atching resources to enterprise requirem ents.
> O rganisational view contains the various responsibility assignm ents for the enterprise and allow s for view structuring in line with function, inform ation and resource allocation. Enterprise views will be generated in sequence with program sets supporting the enterprise design process.
C IM -O SA m akes the important point that people m ake enterprise system s work. People drive IT and m anufacturing system s and not the other way round. CIM -O SA provides for Business, Application and Physical integration in two m ajor environm ents:
> Integrated Enterprise E ngineering E nvironm ent is the im plem entation model that is com posed of the business processes and enterprise activities required to im plem ent CIM -O SA . The im plem ented C IM -O SA guidelines specify the requirem ents, design, im plem entation and release of the enterprise system. The model also includes the inform ation, resource and organisation views.
> Integrated Enterprise O peration E nvironm ent is the im plem entation model that is com posed o f the business processes and enterprise activities required to operate the com plete enterprise, and includes the relevant inform ation, resource and organisation views.
The creation and integration m echanism of the enterprise architecture is facilitated by the application of instantiation, derivation and generation being applied to all levels and views o f the CIM -O SA cuboid. The enterprise architecture is delivered by the ow ner and created by the enterprise user com m unity. The creation process is delivered using the II services that are vendor independent and provide application portability across the enterprise.
A rchitecture o f Integrated Inform ation System s (ARIS)
ARIS is com plem entary to Zachm an and is seen as a fram ew ork o f views that describe the enterprise and is fully integrated by the process oriented view (N agel, 2001). The business processes, functions, data, organisational structures and outputs are the respective ARIS views. The three active levels are the main
stages o f a softw are engineering lifecycle - requirem ents definition, design specification and build-im plem entation. Figure 5 shows the ARIS fram ew ork.
ORGANISATION VIEW Design Specification Implementation DATA VIEW (d Requirements Definition Requirements Definition Requirements Definition Design Specification О Design Specification J 1 Design Specification
Implementation Implementation Implementation
____ ^ L
PROCESS VIEW
Requirements Definition
Design Specification
Implementation
Figure 5 The ARIS Framework (Nagel, 2001)
FUNCTION VIEW
OUTPUT VIEW
ARIS has significant and direct concentration on business processing and accordingly, the process view prevails as the basis o f integration o f all elem ents in an Enterprise A rchitecture.
> Process view. T his view shows the relationships betw een enterprise objectives, activities, events docum ents, data, organisational units, resources and know ledge sets (ie structure, logic, time). The technology model that is most popularly deployed is Event-driven Process Chains. This model is used in docum enting processes in the popular SAP R/3 Enterprise System .
> Function view. Functions are used as descriptors for essential value creating activities for strategic business goals. Functions are the dynam ic portion of the business process and are described in functional analysis outputs.
> Data view. Data and inform ation are descriptors for the transform ation stages of the relevant business objects. Data can form business process inputs and outputs while each transform ing event can realise a data set. Entity-R elationship diagram s can be used to model the data view.
V O rganisation view. Organisational entities (ie, team , person, role, etc) are the m ajor com ponents o f this view, where com ponent arrangem ent is governed by structure, or hierarchical rules. This view show s the resource allocations required for delivery o f the tasks within each business process. > O utput view. An object-oriented outlook represents the ARIS output view.
This perspective captures the results of the business process and realises internal or product based results. This view also provides for product and service hierarchies.
ARIS also provides Description Levels that are m atched to the softw are engineering lifecycle. These levels are represented as follows:
> Problem D efinition - business problem is defined
> R equirem ent Definition - user-system requirem ents are defined in detail У Design Specification - system design docum ent is com piled into
a specification
> Im plem entation Description - the build strategy is com pletely described > Inform ation T echnology - the technology or system is realised
The process view is the ‘prim e integrator’ o f the ARIS house. T he process view integrates itself with the rem aining four views to deliver the com plex enterprise model. As noted earlier, the Event-driven process chains are the most popular m odelling technique. The process view is the ‘integration con cep t’ that supports the view and description level integration activities.
M ETA G roup Enterprise Architecture (MGEA)
The M ETA G roup (W estbrock. 1999) have proposed an enterprise architecture strategy that com m ences with a set o f com m on requirem ents and corporate vision, defines a set of guiding concepts, and establishes a set of dom ain architectures for enterprise growth and evolution. T he Enterprise Inform ation Architecture is platform ed on an existing base o f inform ation and infrastructure. Figure 6 illustrates the M GEA. The most com m on enterprise
architecture delivered by the strategy has two specific dom ains term ed B usiness and Inform ation Technology.
The Business dom ain encapsulates the O perational and Business architectures and the Inform ation architectures. The O perational and Business architectures hold the business models, business processes and organisation (hum an assets) artefacts. The Inform ation architecture defines the business language in term s o f defining and publishing the m eaning, source, and associated business rules for the im portant term s used in the enterprise. The Inform ation architecture also has the enterprise data m odels and relationships resident.
ENTERPRISE ARCHITECTURE
Business
Operational i Business Architectures
Business Models Business Processes Organisation Information Architectures Inforniatton Technology Technology Architectures System Portfolio
Figure 6 The MGEA Framework (W estbrock, 1999)
The Inform ation Technology dom ain encapsulates the Technical architecture and the System s Portfolio. The Technical architecture defines the principles, technologies, products and standards that support the inform ation environm ent. This includes the standard operating environm ents, reference m odels, and technical standards that underpin the environm ent. T he System s portfolio is the collection of all enteiprise inform ation system s and includes architectural principles, application strategies, all hardw are and softw are com ponents, environm ent gap analysis, and an evolution plan and investm ent strategy.
The driving m echanism for enterprise architecture creation, integration and deploym ent is the gap analysis function in the system s portfolio. T he gap analysis drives the evolution path by m easuring differences betw een the ‘as is’ and ‘to b e’ portfolio and im plem enting changes that address the gap. The gap analysis is also fed by the dom ain architectures so that changes in those dom ains are also reflected in the analysis and im plem entation activities. Figure 7 illustrates the EA creation process in M GEA.
Com parison oF FAS for cyclic alignm ent qualities
It was argued previously that the enterprise architecture process should be dynam ic and support feedback exchange and inform ation system s developm ent across the system life-cycle. Enterprise Integration (El) is likely not best platform ed on a static depiction or classification o f separated enterprise artefacts. Enterprise m odels should be capable of evolution in keeping with system and environm ental changes.
Each of the EAs described above was analysed in term s o f the attributes contributing to cyclic alignm ent capability: integration m echanism s and exchange and feedback m echanism s. Table 1 shows a sum m ary o f the results.
All the aforem entioned reference architectures, except for the Zachm an fram ew ork, have a com m on theme for their creation m echanism in the form o f an ‘integrating structure or view ’. Some o f the architectures link their constituent
m odels with feedback and exchange channels, although som e channels are unidirectional information flows. None of the selected architectures, except ARIS, have a discernible feedback loop to corporate requirem ents and constraints.
Table 1 Comparison o f EA frameworks for cyclic alignment support
Architecture T ype Integration M echanism Feedback and Exchange Channels Feedback to Corporate R equirem ents and Constraints Zachman Architecture Framework No evident integration mechanisms. Essentially a classification framework. No evident feedback and exchange channels.
No discernible feedback channels to Corporate Requirem ents and Constraints. C IM -O SA Integration
Infrastructure and Services integrate the Function, Information, Resource and Organisation views.
Integration Services channels pass information and feedback between views. No discernible feedback channels to C orporate Requirem ents and Constraints.
A RIS Process View integrates the Organisational, Data and Functional views.
Two way feedback between the Organisation. Data, Function and Process views.
Two way feedback channel between Process and the Organisational views (Requirements Definition). M G E A Integration Services (Gap Analysis, Migration Planning, Implementation Planning) integrate the requirements, architectures, information and infrastructure. Unidirectional feed forward channels aggregate requirements, architectures, information and infrastructure No discernible feedback channels to Corporate Requirem ents and Constraints.
C onclusions
The e-com m erce com m unity is under constant pressure to deliver new system s faster and with optim al perform ance. System s engineering standards, how ever, indicate the use o f formal developm ent m ethods that are m easured and structured, though they may lack the responsiveness and agility required to meet the faster paced e-C om m erce environm ent. In this system s developm ent environm ent there may be a positive role for EA with certain attributes.
T he literature and em pirical evidence suggest that m odelling tools should be evaluated with respect to ontological com pleteness and clarity, support for good decom position and sim plicity and understandability. For EA fram ew orks we should also look for enterprise alignm ent and integration capabilities. We suggest here additional criteria that assess the degree to which an EA fram ew ork allow s for a cyclic alignm ent process. This is a process in which corporate requirem ents are com m unicated throughout a developm ent project and acted upon in system construction, but in addition there are feedback m echanism s to allow understanding and learning to flow back to corporate m anagem ent in a cyclic process.
The ideal EA should be optim ally connective, yet not overly constraining in its structure. The EA should seek to strike a balance between structural m odular freedom and the alignm ent of m odels, purpose and enterprise goals. We have review ed several proprietary EA fram ew orks in term s o f the support they offer for integration and feedback m echanism s. All fram ew orks except for the Zachm an architecture offer support for an integrating structure. M ost link their constituent m odels with feedback and exchange channels, though som e channels are unidirectional. None o f the selected architectures, except for ARIS, has a discernible feedback loop to corporate requirem ents specification.
The apparent lack o f research into EA artefact or model connectivity provides an avenue for further research to determ ine the nature and utility o f feedback channels and exchanges, including their optim al structure and use.
R eferences
1. Croteau, А-M., Solomon, S., Raymond, L., and Bergeron, F. (2001). Organisational and Technological Infrastructures Alignment. Proceedings o f tlie 34lh H awaii International
Conference on System Sciences.
2. Karimi, J. and Konsynski, B.R. (1991). Globalisation and Information m anagement systems, Journal o f Management Information Systems, 4, 7-26.
3. Kosanke, K. and Vlietstra, J. (1989) CIM-OSA - Its goals, scope, contents and achievem ents, E SPRIT ' fi9: Proceedings o f the 6lh Annual ESPRIT Conference. Boston: Kluwcr Academic. 4. Nagel, C. (2001). Successfully Building Enterprise Architectures - How ARIS facilitates the
Zachman Framework, Leonardo Consulting White Paper.
5. Navathe, S.B. (1992). Evolution o f data modelling for databases, Comm unications o f ACM . 35. 112-23.
6. Pres-Heje, J. and Baskervillc, R. (2001). eMethodology: Toward a systems developm ent m ethodology for e-Business and e-Commerce applications” . In S. Elliot, K. V. Andersen, P. Swatman, S. Reich (Eds.). Developing a dynamic, integrative, m ulti-disciplinary research agenda in e-commerce/e-business, International Federation o f Information Processing.
7. Sahakian, W.S. (1970). Psychology o f learning: Systems, Models an d Theories. Chicago: Markham Publishing Company.
8. Vernadat, F.B. (2000). Enterprise Modelling and Integration: Myth or Reality, (adapted from Enterprise Modelling and Integration: Principles and Applications) (Vernadat, F.B.), Chapman and Hall, London, 1996.
9. Wand, Y. and Weber, R. (1995). On the deep structure ol Information Systems, Inform ation Systems Journal, 203-23.
10. W assenaar, A., Gregor, S. and Swagerman, D. (2002, to appear). ERP Implem entation management in different organizational and cultural settings, Proceedings o f European Conference on Accounting Information Systems, 23-24 April, Athens.
11. Weber, R. (1997). Ontological Foundations o f Information Systems. Coopers and Lybrand and the Accounting Association o f Australia and New Zealand, M elbourne, Australia
12. Westbrock, T. (1999). Managing change through Enterprise Architecture, Enterprise Architecture Strategies, Meta Group Practice, August.
13. Weston, R.H. (1999). Reconfigurable Component-based Systems and the Role ol Enterprise Engineering Concepts, MSI Research Institute Paper, Loughborough University. http://www.cit.gu.edu.au/~bernus/taskforce/m andate/w eston_12febr99/w eston_12tebr99.htm l) 14. Zachman, J.A. (1996). Enterprise Architecture - Issue o f the Century, Database
