SYSTEM ARCHITECTURE AND ENTERPRISE ARCHITECTURE: A JUXTA POSITION? # S.J. Benade 1* & L. Pretorius 2

Transcription

1 SYSTEM RCHITECTURE ND ENTERPRISE RCHITECTURE: JUXT POSITION? # S.J. Bende 1* & L. Pretorius 2 Grdute School of Technology Mngement University of Pretori, South fric 1 siebert.bende@up.c.z; 2 leon.pretorius@up.c.z BSTRCT systems pproch to creting system is discussed. The system engineering process, nd specificlly the system rchitecture process, is formulted nd pplied to typicl (physicl) system, enterprise, nd project. These led to the concepts of system rchitecture (S), enterprise rchitecture (E), nd project rchitecture (P) respectively. Similrities nd inter-reltionships mong these rchitectures nd relted methodologies re investigted, seeking better interction mong them. Work is proposed s n importnt conceptul building-block of these rchitectures, properly defined s ctivity with ssocited inputs, outputs, governnces, nd mechnisms. Techniques such s functionl nlysis, process modelling, nd tsk nlysis re used to demonstrte the interreltionships mong these pprently unrelted orgnistionl perspectives of product, process, nd project. OPSOMMING n Stelselbendering tot die drstelling vn n stelsel word bespreek. Die stelselingenieurswese,en spesifiek die stelselrgitektuurproses, word geformuleer en toegeps op n tipiese (fisiese) stelsel, onderneming, en projek. Dit lei tot die konsepte vn stelselrgitektuur (S), ondernemingsrgitektuur (O), en projekrgitektuur (P). Ooreenkomste en verwntskppe tussen hierdie rgitekture word ontleed om beter onderlinge interksie te bewerkstellig. n Belngrike konseptuele bousteen vn hierdie rgitekture word voorgestel s werk, behoorlik gedefinieer s ktiwiteit met geprdgnde insette, uitsette, kontroles, en megnismes. Tegnieke soos funksionele nlise, prosesmodellering, en tknlise word gebruik om die onderlinge verbnde tussen hierdie skynbr onverwnte orgnistoriese perspektiewe vn produk, projek, en proses, te demonstreer. * Corresponding uthor. # This rticle is n extended version of pper presented t the 2011 ISEM conference. South fricn Journl of Industril Engineering, July 2012, Vol 23 (2): pp 29-46

2 1. INTRODUCTION System rchitecture (S) nd enterprise rchitecture (E) in technology-bsed enterprises re explored, giving specil ttention to the interction between these two worlds. The question posed is whether the concepts re fundmentlly the sme, competing, or perhps independent. The concepts re compred in terms of purpose, origin, structure, nd utilistion. The question origintes from the relity tht S nd E re often perceived in business nd industry to be completely different nd unrelted. The concepts re linked to different fields of study nd different professions. The uthors ddress E s the creting system, nd S s the creted system. In simple terms, S cn be seen s description of the high-level functions nd sub-systems of to-be-developed system in its intended opertionl environment. The primry function of S is to enhnce the understnding nd high-level definition of complicted nd often high-tech systems, nd to direct the subsequent development process. There is some controversy in industry nd cdemi bout whether or not S is new development in the domin of system engineering (SE). rguments rnge from whether S should be performed before, be integrl to, or be done in ddition to the SE process. The question often sked in industry is whether cumbersome effort such s S is required t ll. Enterprise rchitecture is typiclly described s model of the enterprise (orgnistion) in terms of business processes, informtion, nd required resources. These business processes re seen s the vehicle to crete nd deliver vlue to customers. This business process definition lso seeks to bridge the divide between the business nd ICT functions of the enterprise. Tody, despite ll the powerful ICT nd other technologies vilble, orgnistions bttle to bridge the divide between the business-side of business nd the ICT-side of business. In the finl nlysis, this ppers to be people issue, not technology issue. S nd E inititives re often lunched independently in compnies. Different project tems rgue bout which project S or E dd more vlue to the enterprise. Prticipnts do not lwys pprecite tht they re working on either the creted system or the creting system within the sme orgnistionl system. The interction between the project nd the enterprise is further nlysed. Trditionlly, projects were seen s subsets of compnies. However, lrge multi-enterprise nd multintionl projects (progrmmes) turned this notion round. In fct, compnies re often founded during, or s result of, lrge projects. Technologies, knowledge, skills, nd tools required to execute S projects to meet the needs of customers re often ignored during enterprise improvement efforts. Compny process stndrdistion nd integrtion, s well s IT enblement, re often the min focl points, nd s result significnt integrtion opportunities re lost. These two pproches re often seen s being in conflict, nd fil s result of resistnce to both chnge nd collbortion. lthough both pproches could be highly technologicl, they impct the individul nd thus the totl enterprise. systems pproch towrds the cretion of ny system is proposed nd demonstrted on high level. The bsic SE process, s defined by the Interntionl Council on System Engineering (INCOSE), is used s point of deprture [1]. The S process (rchitecting) is further formulted nd pplied to typicl (physicl) system, enterprise, nd project. The resultnt concepts of S, E, nd project rchitecture (P) re described nd compred. There re vrious similrities nd differences tht should be ctered for. Similrities nd inter-reltionships mong these concepts re nlysed, nd proposed s point of deprture to improve nd better integrte the enterprise. The focus is on the technology-bsed enterprise. However, the principles nd processes presented could be vluble to ny orgnistion. The notion of work (ctivity, process, function, tsk, etc.) is proposed s common denomintor nd conceptul building-block of these systems. Work is further defined s executed on system or by system. The fully-defined 30

3 ctivity, in IDEF0 (Integrted Definition Lnguge for Functionl Modeling) formt [2], is described nd pplied to the product (system), enterprise, nd project rens. Functionl nlysis in the S domin is used to crete functionl brekdown structure, describing the functions tht the to-be developed system needs to perform. Business process modelling in the E domin cretes business process model tht describes the processes to be executed in the orgnistion, nd typiclly forms prt of the so-clled enterprises business rchitecture. Tsk nlysis is done to define the work required on project, nd typiclly leds to the cretion of sttement of work, work brekdown structure, criticl pth, etc. The nlyses of work, whether to be done on or by system, re used to explin the inter-reltionships mong these pprently unrelted orgnistionl perspectives. These different perspectives, often perceived nd mnged s independent systems, need to be understood nd integrted. nlysing different definitions nd pproches to system rchitecture indictes n inclintion either towrds (physicl) systems, or more likely, towrds orgnistions. Secondly, vriety of definitions highlight the process to crete, s well s the structure (configurtion) s key prmeters to describe rchitectures. Improving meningful interction between cquisition nd supplier orgnistions cn be found in the better understnding of the system (nd enterprise) rchitectures of both orgnistions. The evolution of INCOSE, the system engineering frternity, over severl yers is significnt, s it hs shifted from focusing on the deliverble system to including the full orgnistionl perspective in reltion to key processes. The importnce of the mke/buy decision becomes pprent. The strtegic nture of the decision, nd its effect on ssocited rchitectures, is ddressed. Technology (existing nd new) is highlighted s key driver in rchitecting. Process models re further developed to demonstrte the interction mong product, process, nd project. 2. RESERCH PPROCH The reserch ws done s n explortory study ddressing the formultion, structure, nd use of system rchitectures nd enterprise rchitectures nd their interreltionships. Inter-reltionships were nlysed, nd high-level conceptul business process model ws developed in n effort to understnd nd depict these inter-reltionships better. similr model ws originlly developed by the uthors to fcilitte work sessions during business redesign nd modelling inititives in industry nd in the cdemic environment. The notion of process ws rediscovered s the golden thred or common denomintor running through the enterprise, systems (products nd relted services), nd projects. Different process perspectives were nlysed nd further developed. Similrities were identified mong the enterprise, system, nd project environments. The chllenge of creting vlue for customers vs. creting new cpbility within the vlue chin ws nlysed. Finlly, the role of process ws lso compred with the fundmentl rchitecture design process. The literture survey is presented in sections 3 to 8, followed discussion of the min contributions in sections 9 nd 10. The rticle concludes with section 11. n intensive literture study ws conducted to enhnce the understnding of wht S nd E ment to the leding uthors nd reserchers in these fields. number of Msters theses, of which the corresponding uthor ws the study leder, were used s building blocks to highlight nd vlidte further some of the concepts nd findings of this reserch. Severl issues directed the literture survey, strting with the definitions nd the reltionship between the fields of S nd E in section 3. Tht section highlights the confusion in cdemi nd industry bout the fields of S nd E. For exmple, 31

4 technology is discussed when ICT is ment, nd rchitecture described by system engineer will most probbly men system (physicl or softwre) rchitecture, not E. rchitecture for business consultnt would men E, not S; nd so forth. Furthermore, rchitectures re often defined in terms of wht they do, not wht they re. Section 4 introduces prominent theoreticl frmeworks tht highlight the different perspectives on structure, content, nd rchitecture use. In section 5 we discuss the reltionship between the creted nd creting systems. They re highly interrelted, nd require in-depth nlysis. Section 6 motivtes the ide tht mke/buy decisions extend the boundry of the enterprise, nd tht the resultnt effect on to-be-developed rchitectures nd procurement processes needs to be properly understood. Section 7 provides vlue-chin perspective of n enterprise, in order to introduce the rgument in sections 9 nd 10. Section 8 concludes with the literture on IDEF (Integrted Definition Lnguge for Functionl Modeling) s n nlytic tool to compre product, process, nd project. 3. ORIGINS OF SYSTEM RCHITECTURE ND ENTERPRISE RCHITECTURE 3.1 The mening nd definition of system rchitecture The mening, definition, nd prctice of S re nlysed nd discussed in this section. It is importnt to understnd wht system rchitecture is nd wht it does, becuse this provides foundtion for the subsequent rgument. Webster s Dictionry [3] defines rchitecture s the rt, science or prctice of designing nd building structures. The structure should be coherent nd unifying. Blnchrd [4], describes system rchitecture s follows: n rchitecture dels with top-level description of system structure (configurtion), its opertionl interfces, nticipted utiliztion profiles (mission scenrios), nd the environment within which it is to operte; then, it describes how these vrious requirements for the system interct. This leds to the description of the functionl rchitecture, which evolves from the functionl nlysis nd its description of the system in functionl terms. Mrtin [5], describes it s The highestlevel concept of system in its environment. It dels with system structure, opertionl interfces, profiles of use, nd how the elements of system interct with ech other. It cn lso be defined in terms of scenrios long with expected behviour for ech scenrio; sttes, modes nd configurtion of system elements. Gilb [6] defines sytem rchitecture s set of rtifcts creted by rchitecture Engineering. systems rchitecture is strtegic frmework nd consists of models, stndrds nd design constrints specifying mndtory nd recommended best prctice for implementing nd mintining systems. Mier & Rechtin [7], define rchitecture s The structure in terms of components, connections, nd constrints of product, process, or element. They emphsise tht the core of rchitecting is system conceptulistion, which is often more rt thn science. They lso suggest tht, to formulte good definition, one should consider wht n rchitecture is suppose to do: providing informtion tht defines system s vlue, cost, nd risk sufficiently for the purposes of the system s sponsor. n rchitecture should help client to mke decisions bout building systems. When the client mkes cquisition decisions, rchitecture hs been done (perhps unconsiously nd perhps bdly, but done). The rchitecture Working Group of IEEE (WG) [8] defined rchitecture s The fundmentl orgniztion of system embodied in its components, their reltionships to ech other nd to the environment nd the principles guiding its design nd evolution. The INCOSE Systems rchitecture Working Group (SWG) [9] defined the rchitecture of system: The fundmentl nd unifying system structure defined in terms of system elements, interfces, processes, constrints, nd behviors. These two definitions re quite similr. Muller [10] proposes tht system rchitecting is mens to crete systems efficient ndeffective, by supplying overview, by gurding consistency nd integrity, nd by 32

5 blncing. In other words the system rchitect helps the development tem to find its wy in rther complex, dynmic nd uncertin world. In summry then, these definitions hve four common focl points: the opertionl or business context within which the to-be-developed system will function; the process to crete system rchitecture; the structure of the rchitecture itself; nd the use of the rchitecture. Tble 1 ws developed by the uthors. It compres the emphsis plced on different spects of SYSTEM RCHITECTUREby different uthors nd working groups in the field of S. The scle goes from open, to x, then X, then XX. The scle is reltive, nd seeks to give n indiction of emphsis. It is evident from the bove discussion tht uthors focus on different spects of S. It is thus importnt, when the term system rchitecture is used, tht the intended mening is clerly defined nd communicted. Tble 1: comprison of system rchitecture definition 3.2 The mening nd definition of enterprise rchitecture There re vriety of pproches, definitions, nd perceptions bout E. When one speks bout E, people often understnd it to men only the IT-side of the business the enterprise IT rchitecture. Sometimes people only focus on business processes nd ignore the rest of the E. Often E is perceived to be highly technicl nd detiled inititive; the strtegic core of it is ignored. The mening, definition, nd process of E re ddressed in the next sections. It is importnt to develop common understnding of wht n E is nd wht it cn be used for, before ny such inititive is undertken. The uthors perceive E to be specil kind of S, or the ppliction of S to the orgnistion. Dickinson [11] sttes, We need some wy to see the essentil business without seeing the implementtion thereof. He emphsises the need to model the business to estblish understnding nd mke decisions before the business hs been (or should be) fully implemented. Boshof [12] suggests tht theory, concepts nd frmeworks re essentil tools for orgnising fcts. How we observe the fcts is function of the theory, concepts nd frmeworks we use. This seems trivil point, but it is often the origin of our misunderstnding, prejudice, nd inbility to fully collborte. This problem could be ddressed by formulting relevnt theories, concepts nd frmeworks nd incorporting them into E. Steyn [13] sttes tht enterprise design denotes process tht reconciles the strtegiclly desirble with the economiclly fesible. He proposes tht sound fundmentl system design process be pplied to the enterprise; hence the design or rchitecting of the enterprise. Lwler & Howell-Brber [14] rgue tht Business Enterprise rchitecture defines the design of the detiled tsks of the business processes, the business policies (e.g. mngement of met-dt), nd the informtion technologies included in n IT infrstructure, bsed on the definition of wht firm does s business. They further emphsise tht it is importnt to note tht enterprise rchitecture (including services) is 33

6 bsed on business decisions or definition of business strtegy, nd not on technicl decisions or (IT) technology strtegy. ccording to Mier & Rechtin [7], Peter Weil of MIT defines E s follows: The orgnizing logic of key business processes nd IT cpbilities reflect the integrtion nd stndrdiztion requirements of the firm s operting model. s previously discussed, Muller [10] proposes tht system rchitecting is mens to crete systems efficiently nd effectively, by supplying overview, by gurding consistency nd integrity, nd by blncing. It is importnt to relise tht he uses the sme description for the rchitecting process nd purpose of S in generl, nd for E. 3.3 Why system rchitecture? ccording to Muller [10], it is often esier to understnd system rchitecture in terms of wht it does thn wht it is. S opertes in the grey nd fuzzy world between the problem orgnistion nd the solution orgnistion. number of interctions between the orgnistion tht experiences problem or sees business opportunity nd orgnistion(s) tht could potentilly provide solution re shown in Figure 1 below. The interctions described re by no mens ment to be complete, but merely highlight importnt processes leding to S. They immeditely suggest tht system rchitecture should be both rt nd science, nd tht it is more thn merely technicl specifiction of some system (solution). 34 Figure 1: System rchitecture interctions mong orgnistions 3.4 The origin nd development of enterprise rchitecture E originted from, nd is influenced by, number of business res: the mnufcturing industry, with mteril requirements plnning (MRP) nd lter mnufcturing resource plnning (MRP II). These pproches developed into the so-clled supply chin or vlue chin (Porter et l). Not only were the incoming logistics nd internl opertions considered, but lso the flow of mteril to nd from customers. The second origin of E growth is to be found in process modelling nd design pproches, such s business process re-engineering (Hmmer et l). These pproches seek to depict the enterprise in terms of business processes, leding to process improvements nd end-toend process integrtion. Corporte nd process governnce, orgnistionl dptbility, nd IM/IT system integrtion were typicl considertions. Orgnistions were consequently often restructured to become fltter (with fewer mngement lyers), nd were lbelled process-centred or process-oriented orgnistions. third development is type of bckwrd integrtion, where softwre developers im to understnd nd serve the business world better with functioning nd vlue-dding softwre solutions (business pplictions). It is well-known fct tht enterprise integrtion softwre (such s ERP) is often considered to be filure by business users nd owners. This is in spite of the current phenomenl technologicl cpbilities tht were not vilble 10 to 15 yers go. ccording to Mier & Rechtin [7], the strtegy n IT system embodies should be tht of the orgniztion it belongs to s whole, not tht of just the IT

7 controlling orgniztion. This sounds obvious, but the chllenge to close the gret divide between the business nd IM/IT side of the enterprise still confronts us. This issue cn lso be trced bck to Boshoff [12], who sttes tht how we observe fcts is function of the theory, concepts, nd frmeworks we use. Clerly, the point of deprture nd the prdigms guiding the thinking nd priorities of business people nd IT people re different. Trends in the project mngement field hve significnt effect on orgnistions tody nd thus on developments of E. This is often not fully relised by E prctioners or IM/IT ppliction developers. E inititives nd typicl ERP types of systems primrily revolved round process-oriented orgnistions. Project mngement softwre trditionlly focused on mnging project, not the orgnistion. Most work in orgnistions tody is plnned nd executed round projects. Even the so-clled process-orientted orgnistions re to considerble extent run s projects. Steyn et l stte tht the chllenge tody is not only to mnge single project, but to run ny number of projects s portfolio of projects [15]. Projects re to be identified, scoped, pproved, lunched, nd then mnged. Decisionmking processes, the use of scrce resources, nd re-prioritistion of projects re typicl chllenges in the project-portfolio ren. Business strtegy implementtion is often mnged s project nd no longer by deprtment. Project mngement, nd specificlly portfolio mngement, hs become vitl ingredient of strtegic mngement nd, consequently, lso of E. It is interesting to relise tht typicl E endevours re run s projects s well cse of one hnd wshing the other. There is developing trend tht some orgnistions re orgnised in terms of projects, leding to the so-clled projectcentred orgnistion. The link to E is cler. Mier & Rechtin [7] describe the strtegic rchitecting of progrmmes elegntly, by emphsising the importnce of orgnistionl context nd overll business strtegy in selecting progrmmes. 4. THEORETICL FRMEWORKS In the previous section, the definition nd mening of rchitectures were nlysed nd discussed s foundtion for lter rgument. number of theoreticl frmeworks re ddressed in the prgrphs below, shedding more light on the structure, content, nd use of rchitectures. 4.1 System rchitecture frmeworks It is interesting to note tht the system engineering frternity e.g., INCOSE nd the system rchitecting group of IEEE present their high-level rchitecture definitions nd frmeworks primrily in process formt, while they re focused on delivering systems (products nd relted services) to customers. ccording to Blnchrd [4], Eisner [16], Mier & Rechtin [7] nd others, n importnt point of deprture is tht S is n integrl prt of the SE process. The process to crete system rchitecture is clled system rchitecting. It is, in essence, conceptulising process tht ids in decision mking. Muller [10] suggests: System rchitecting is mens to crete systems efficient nd effective, by supplying overview, by gurding consistency nd integrity, nd by blncing. In other words the system rchitect helps the development tem to find its wy in rther complex, dynmic nd uncertin world. Process groups of the ISO/IEC Stndrd The SE Hndbook of INCOSE [1] includes the process groups defined in ISO/IEC15288: 2008 Stndrd s their officil definition, s shown in Figure 2. This is very positive development, since there exist wide vriety of definitions to define SE nd relted processes, often leding to confusion. This lck of stndrdistion lso negtively impcts development of model-bsed SE process. s 35

8 36 Figure 2: Process groups of the ISO/IEC 15288:2008 Stndrd This definition strted off by focusing on the technicl processes (systems perspective), evolving to include project processes, nd finlly including orgnistionl processes. However, the uthors believe tht prts of the technicl processes re not elegntly defined, since no cler distinction is mde between system design nd mnufcturing. Both re ctered for merely s implementtion. Overll, the demrction of the process groups is meningful. S frmework s defined by Eisner ccording to Eisner [16], the development of bsic rchitecture is the centrepiece of the totl systems engineering process. It is fundmentlly synthesis procedure, nd normlly requires: the formultion of lterntive system rchitectures; nd nlysis of the postulted rchitectures to verify tht they stisfy system requirements. This sttement suggests tht S is t the core of, nd integrl to, the SE process. The SE process is defined by different uthors nd other references in terms of the purpose of the overll SE process nd the constituent sub-processes. Therefore S is lso defined in terms of the hosting SE process. This notion is echoed by Blnchrd, Mrtin, Mier & Rechtin, nd others. From list of thirty-two suggested SE sub-processes, Eisner [16] identified eight s representing the S process: requirements nlysis nd lloction; functionl nlysis nd decomposition; rchitecture design nd synthesis; lterntive nlysis nd evlution; technicl performnce mngement; life-cycle costing; risk nlysis; nd concurrent engineering. S frmework s defined by Mier & Rechtin On more philosophicl level, Mier & Rechtin [7] define the foundtion of modern S s follows: systems pproch; purpose orienttion; modeling methodology;

9 ultr qulity implementtion; nd certifiction. This definition is more bout high-level purpose nd pproch. Ech one of the foundtion elements implies specific process. significnt prt of S processes is bsed on heuristics, not nturl sciences lone. This signifies the importnce of S s rt, not only s science. 4.2 Enterprise rchitecture: The bsic building blocks ccording to Bende [17], n E is typiclly prtitioned into four conceptul building blocks: enterprise business rchitecture (EB), enterprise informtion rchitecture (EI), ppliction portfolio (EP), nd enterprise IT rchitecture (EIT) schemticlly shown in Figure 3. The building blocks, neither physicl nor clerly demrcted, re inseprble, nd should be treted s perspectives of the enterprise rther thn s sub-systems. This E pproch ws studied nd pplied to vrious projects during the lte 1990s by the corresponding uthor. The pproch is loosely bsed on mteril from Zchmn [18] nd on his well-known Zchmn frmework. The focus of this pper is, however, on the EB, nd specificlly on business processes. s with ny design (or model), the context is extremely importnt. In this cse the strtegic business context is the guiding one. Zchmn [18] emphsises tht E offers n ontology (structure nd definition), not methodology. This implies tht the different E pproches explin wht n E should encompss, but not how to crete it. In this cse, the process of system engineering is very useful. Figure 3: Enterprise rchitecture building blocks One of the chllenges of E is the conflict between existing processes, knowledge, nd innovtion. Mrtin [5] suggests tht innovtion nd efficiency don t hve to be t odds. He unveils new wy of thinking tht blnces the explortion of new knowledge (innovtion) with the exploittion of current knowledge (efficiency) to regulrly generte brekthroughs nd crete vlue for compnies. Design thinking focuses on ccelerting the pce t which knowledge dvnces from mystery (n unexplinble problem) to heuristic ( rule of thumb tht guides us towrd solution) to lgorithm ( replicble success formul). s knowledge moves through this knowledge funnel, productivity grows nd costs drop. But design- thinking orgnistions don t stop there. They use the efficiencies they generte to constntly tckle new mysteries nd explore potentil brekthroughs. This is fresh wy to look t the lerning orgnistion nd to chllenge the fer of chnge. This pproch is importnt, since this rticle revolves round the design of systems nd enterprises, thus encourging design thinking. 4.3 Enterprise rchitecture frmeworks nd stndrds There is vriety of E frmeworks, stndrds, nd prctices in the literture nd industry. Most E frmeworks refer bck to Zchmn, or resemble his frmework. They re often derivtives of one nother. Well-known E frmeworks referred to in the INCOSE Hndbook [1] include DODF [19], TOGF, nd MODF. Figure 4 shows the Ministry of Defence rchitecture frmework (MODF) s n illustrtion. 37

10 Figure 4: Ministry of Defence rchitecture frmework (MODF) E frmeworks support the notion of different views of the sme enterprise, i.e. not subsystems.ll prticipting orgnistions should hve n E of some sort, to mke the definition, integrtion, nd chnge of work effective nd efficient. It is importnt to relise tht E frmeworks, such s the Zchmn frmework, provide fundmentl ontology, not methodology. Ontology refers to the structure (configurtion), definition, nd description of n rchitecture. The process to crete n rchitecture, or to populte ll the E elements, requires methodology. The discipline of system engineering (nd specificlly S) pproches rchitecture primrily s process to crete system. This is fundmentlly different point of deprture. The uthors believe tht understnding both E nd S, nd leverging their strengths, could led to new insights nd vlue. 5. THE RELTIONSHIP BETWEEN CRETED ND CRETING SYSTEMS The work tht should be done to cquire system nd relted services forms n integrl prt of the cpbility (technology nd others) tht the enterprise s creting system should possess to be successful. This is the primry reltionship between the creted nd creting systems. The system (or service) creted in n enterprise cn hve fr-reching effect on the enterprise in terms of wht should be done nd how it should be done. This is even more so when to-be-creted systems re high-tech, complex, lrge, nd expensive. Often, personnel perceive the orgnistionl structure s the wy tht they do business. But this is seldom the cse. Executing business processes (cross orgnistionl boundries), or working on projects, normlly leds to the cretion of vlue nd deliverbles to customers. When nlysing the bove-mentioned definitions of S nd E, the similrities re obvious. The underlying (common) question is how to specify, design, nd relise system. This issue is elegntly described by Steyn [13] in terms of the process of designing business. The enterprise s the creting system ws ddressed in prgrph 3.4. The process used by the enterprise to crete, for exmple, systems for customers, could be system engineering. The fct tht E does not provide methodology to crete n enterprise ws highlighted. To estblish system, including the enterprise s system, requires n ontology nd methodology. The meningful interction between E nd S now becomes pprent. 6. MKE/BUY DECISIONS LEDING TO THE EXTENDED ENTERPRISE Historiclly, decision tht hd to be mde ws whether component or product should be mnufctured within the orgnistion or procured from suitble supplier. ccording to 38

11 Bordmn & Turner [20], the notion of mke or buy hs much wider impliction tody. For ny business process, the question is whether it should be performed in the compny or outsourced. This immeditely rises the question of how to mke this decision, nd ccording to which set of criteri. One could pproch this from life-cycle perspective: tht is, ctivities in ny system life-cycle phse could be cndidte for outsourcing. ccording to the uthors, t lest four importnt res should be considered when mke/buy decisions re mde: existing nd required technologies; system development nd relted resources; system mnufcturing nd relted resources; nd system support nd relted resources. Vrious combintions of outsourcing re possible, mking contrcting nd project control very chllenging. It is not only the exchnge of products, but lso the exchnge of services nd informtion tht hs become prmount. Configurtion mngement becomes n importnt issue needing creful definition nd mngement. Meningful service-level greements should be entered into. This leds to the concept of the extended enterprise. The chllenge is to contrct nd mnge the processes externl to n orgnistion so tht the qulity of the processes is cceptble, nd the end-result cn be semlessly integrted into the orgnistion s own internl processes, thus stisfying its customers. The qulity of suppliers is often to be found in the wy processes re executed, not just in their endproducts (deliverbles). It is essentil tht the S ctivities for ech project should be crefully identified, defined, nd contrcted to prticipting orgnistions. The efficiency of this orgnistionl interction, specificlly in the informtion nd services ge, hs become huge business chllenge. Mss customistion nd chnging technologies, for exmple, nd the extreme pressure to respond to chnge (throughout the totl vlue chin) mkes the use of greed-upon rchitecture frmeworks nd implementtion prctices the next business chllenge. 7. ORGNISTIONS IN THE VLUE CHIN The fundmentl views of the user/owner, the designer, nd the builder were the point of deprture for Zchmn nd subsequent E uthors nd reserchers. These views still provide very useful insights tody. 7.1 The customer orgnistion One of the fundmentl principles of S is tht system should be designed within context. ccording to Blnchrd & Fbrycky [21], system is lwys prt of bigger system. The customer orgnistion typiclly inludes the owner nd (end-) user of the to-be-developed system. The system will typiclly be specified nd finlly ccepted nd implemented ccording to specifiction(s). The new system will thus contribute towrds the cpbility of the orgnistion. The MODF cn help n orgnistion to understnd its customer or enduser better, hence creting better fit regrding the new system to be implemented. The functions ( work ) required of the new system re the key interction between the customer orgnistion nd the designer orgnistion. 7.2 The designer orgnistion The successful development of required system for the customer environment is the key cpbility of the designer orgnistion. Understnding nd designing the required functions ( work ) of the new system is essentil for the designer orgnistion. The bsence of good requirements mngement remins one of the most common cuses of project filure. The work tht the new system is supposed to perform is often not properly understood by designers, even though system design constitutes the primry output of the design orgnistion [5]. The design should include definitions of the product nd of the mnufcturing, operting, nd support processes. These definitions re different views of the system definition, not subsets of it. The concept of n integrted product definition is essentil to the rgument. 39

12 7.3 The builder orgnistion The new system should be built ccording to its design. This is only plusible if the design includes the mnufcturing definition, s noted in the previous prgrph. Idelly, the builder orgnistion should hve prticiptedin the design of the system [1], [22]. Typiclly, the mnufcturing process nd mnufcturing system should be specified nd designed with the mnufcturbility of the system in mind. 7.4 The support orgnistion Support, in essence, comprises supply nd mintennce. The erly prticiption of the support orgnistion(s) is criticl, especilly for complex systems. Effective fult dignosis nd corrective ction re essentil to mintin complex systems in the user environment. It is crucil to design such complex systems to enble efficient support, since it is generlly significnt chllenge to dd this feture lter. Consequently, the support process nd - system should be designed to be n integrl prt of the overll system definition. The work to be done eventully to support the system is criticl. Support ctivities could be executed by the customer orgnistion, design/builder orgnistions, nd other suppliers [19]. It is impertive tht mke/buy decisions in the support environment be considered crefully. 8. WORK S COMMON DENOMINTOR MONG DIFFERENT RCHITECTURES The definition nd execution of work is n importnt ingredient in the product/system ren, the project world, nd the enterprise. Work cn be done on or by systems. When work is defined, the next logicl step is to define the resources required to execute the work. The resources re then orgnised into meningful structure, configurtion, or rchitecture. This very bsic logic is eqully pplicble to the product/system design ren (i.e. S), the plnning nd execution of projects (i.e. PM), nd in the design nd structuring of enterprises (i.e. E). Becuse it ppered to be rther trivil point, the commonlity of work is often overlooked. Work is defined nd modelled in similr wys in these res. The Integrted Definition Lnguge for Functionl Modelling (IDEF) is briefly described in the next section (refer lso to the IDEF website) [2]. ccording to the IDEF methodology, shown in Figure 5, n ctivity nd its ssocited objects (inputs, outputs, controls, nd mechnisms) re defined. ny number of ctivities cn be strung together to crete process. 40 Figure 5: IDEF Model The focus of this rticle is on the IDEF0 formt only. The bsic logic of n IDEF0 model is the following: Inputs get processed to crete meningful outputs. The vlue of the outputs should be more thn the inputs. The ctivity should be executed within the boundries of defined controls or governnce. The ctivity gets executed by certin defined mechnisms. The inputs nd outputs must futhermore dhere to specified qulity requirements. This specific representtion of n ctivity nd its ssocited inputs, controls, outputs nd mechnisms (ICOMs) is shown in Figure 6, nd is n exmple of IDEF0. The inputs nd

13 outputs re rrnged in sequence to give exmples of different ctivities (processes). This fully-defined ctivity (i.e. ctivity nd relted ICOMS) cn be seen nd used s bsic building block of the product/system, the project, nd the enterprise. The rgument cn clerly be expnded to use IDEF3 formt, where time nd sequence re lso nlysed nd modelled, or IDEF1X, where object trnsformtion ( dt modelling ) is done. Figure 6: IDEF0 digrm showing ctivity nd ssocited ICOMs The literture survey ddressed definitions in, nd reltionships between, the fields of S nd E. Prominent theoreticl frmeworks of E nd S were discussed. The close reltionship between the creted nd creting system ws nlysed. Then mke/buy decisions, extending the boundry of the enterprise, were discussed. The creted nd creting system nd mke/buy decisions re two sides of the sme coin, since they both represent the orgnistion nd the output of the orgnistion. vlue-chin perspective of the enterprise nd the relted supply chin ws presented. The importnce of greeing on S ctivities mongst prticipting orgnistions ws emphsised. It ws concluded tht both the creted nd creting system require n E ontology nd methodology to be meningfully estblished. ll of the bove, if not properly mnged, could contribute to the so-clled frgmented orgnistion. The min contribution of this reserch is presented in sections 9 nd THE DEFINITION OF WORK FOR PRODUCT, PROCESS, ND PROJECT Orgnistions re negtively ffected by the confusion in cdemi nd the industry bout the fields of S nd E. The chllenge of orgnistionl frgmenttion ws previously referred to. The concept of work is investigted nd proposed s point of deprture for enhncing the integrtion of enterprises, nd specificlly ddressing the product, process, nd project perspectives. The interction nd intersection of product/system, (business) process, nd project is importnt views of the orgnistion, especilly in the technology-bsed enterprise. The different res re shown in Figure 7,with some typicl ctivities, key chrcterisitcs, nd issues relted to ech re. 9.1 Product/System: Functionl nlysis leding to functionl rchitecture Products/Systems nd services re typiclly creted by executing product/system development process (often clled the first cretion), nd then performing the mnufcturing process (the so-clled second cretion). One of the erly steps in the design process is the functionl nlysis, where problems nd user requirements re nlysed nd required system functions re identified nd defined [21]. function is defined s required cpbility. functionl system brekdown (FBS) is then typiclly creted, leding to the cretion of the functionl system rchitecture. 41

14 Figure 7: Product, process nd project domins The functionl nlysis is the first step towrds creting potentil solution, nd therefore synthesis. To put function into ction, suitble mechnism (resource) needs to be llocted. n executble process cn thus be creted. Potentil resources (sub-systems) re llocted to functions. The functionl definition constitutes the processes (work) tht the to-be-developed system must perform. Subsequently, system requirements re llocted to resources (sub-systems). These sub-systems re orgnised into meningful structure, leding to the S. These ctivities re typiclly done during the preliminry design phse (ccording to the SE process), nd the output of this phse is consequently clled the llocted bseline. Blnchrd [4] sttes: The functionl nlysis cn fcilitte n openrchitecture pproch to system design. good comprehensive functionl description of the system, with the interfces well defined (qulittively nd quntittively), cn led to structure tht will not only llow for the rpid identifiction of resource requirements, but lso permit the possible incorportion of new technologies lter. functionl brekdown cn be presented in hierrchicl form or process form - e.g., IDEF or functionl flow block digrmme (FFBD) formt. Figure 8 shows the ctivity in principle s function of system in IDEF0 formt. 42 Figure 8: ctivitymodel s function of product 9.2 Process: Business process modelling s input to n enterprise rchitecture Processes re defined, stndrdised, nd executed in enterprises to sustin qulity of work nd crete the end result (deliverbles). Orgnistionl design, business design, or E re typiclly done through (business) process nlysis, modelling, nd design to define how work should be done in the orgnistion. End-to-end process integrtion is strived for.

15 These business process model(s) form the bckbone of the to-be-designed enterprise. Subsequently, potentil resources (mechnisms) re identified nd llocted to specific processes. These mechnisms cn be people, softwre, hrdwre, IM/IT systems, etc. Figure 9 schemticlly shows typicl IDEF0 ctivity model. Business objects re furthermore identified nd orgnised into business object models or simply into dt models (e.g. IDEF1X). These business process nd business object models provide the core inputs towrds defining the enterprise. The typicl enterprise rchitecture building blocks, s shown erlier in Figure 3, re creted. ll of these models re creted within the strtegic context of the compny. Figure 9: ctivity model s business process 9.3 Project: Tsk nlysis leding to project brekdown structure Project mngement is used to structure, mnge, nd outsource work in order to crete deliverbles for customers effectively nd efficiently [15]. s previously discussed, most work executed in compnies tody is mnged s projects; hence the importnce of project mngement. The full definition of required work is given in sttement of work (SOW), work brekdown structure (WBS), nd different types of tsk nlysis/models - e.g., criticl pth nlysis, project schedules, nd long-led item schedules. Most inititives to develop, implement, or chnge n S or n E re typiclly done s projects to mke it more mngeble. The project mngement perspective on S nd E is importnt nd is shown schemticlly in Figure 10. The ctivity in the process model is expressed s work in project, nd it therefore forms prt of the WBS nd SOW. Resources llocted to the WBS eventully constitute the project brekdown structure (PBS). The PBS is temporry orgnistionl structure until the project hs been completed nd discontinued. Figure 10: ctivity model s work pckge of project l 43

16 9.4 Comprison of product, process, nd project The uthors suggest tht the definition of work in the bove-mentioned res of product/system design, E, nd project plnning is essentil for design ctivities, nd thtthe design processes re similr. The typicl design ctivities tht is, system requirements nlysis nd definition, design process (synthesis nd nlysis), methods of presenttion, lloction of requirements nd resources to processes, nd finl structuring of resources into system rchitecture- re shown nd compred in Tble 2. Tble 2: Product, process, nd project in terms of design ctivites 10. PROCESS MODEL OF THE TECHNOLOGY-BSED ENTERPRISE generic business process model, s shown in Figure 11, ws developed by the corresponding uthor while executing vrious projects nd performing consulting role between 1995 nd The model ws lter successfully used to define processes, informtion, nd required IT systems in n cdemic environment s well. The model is presented in IDEF0 formt, nd ws found vluble s communiction tool in the technology-bsed enterprise to crete common understnding between different project tems. It is used to bring together S nd E tems to discuss business processes nd required resources/technologies, met-dt, required informtion nd informtion flows, etc. The key processes of creting vlue for customers vs. creting new cpbility within the enterprise nd prticipting supply chin were nlysed. The process of perform technology mngement s shown in Figure 11, process 4, is closely relted to the cretion of new cpbility within the technology-bsed orgnistion. This formlly ddresses the sustinbility of the enterprise from technology point of view. Obviously not ll new cpbilities re technology-relted. The model is not ment to be complete: it merely shows some importnt processes nd ICOMs. It is lso not proposed s the finl nswer, but rther s point of deprture nd discussion. It is lso vluble for identifying required process controls nd for designing nd implementing meningful governnce rchitecture. The model clerly needs to be expnded, depending on the purpose nd nture of the S or E project. l 44

17 Figure 11: High-level business process model of technology-bsed enterprise The fundmentl design process proposed by INCOSE, Steyn, nd vrious others cn be pplied to different to-be-developed systems, be they products, projects, or enterprises. However, the process should be crefully nd thoroughly tilored to meet the specific circumstnce in the best wy. (Refer to Tble 1, where similrities, differences, nd importnt interctions mong the concepts re described). Business consultnts, project mngers, nd system designers re typiclly trpped within their respective understnding of work s business process, WBS, nd function of product (refer to Figures 8, 9, nd 10). It ws found very useful to generlise work nd model in similr fshion using, for exmple, IDEF0. This notion of work is essentil to define nd model ny system, nd cn ct s powerful integrtion mechnism. The IDEF modelling methodology, lthough reltively old, is very useful to model work, nd so ct s n importnt input to S. ny rchitecture should be developed within n greed-upon strtegic context. This sounds obvious, but filing to do so is often the cuse of project filure. This problem is often present during product design, business process redesign, nd enterprise rchitecture projects. Whether rchitecting is perceived to be similr to design (with its origin in the physicl system development ren) or to the estblishment of n orgnistion, ppered to significntly influence the thinking processes of people. The concepts of S nd E should not be perceived s independent, but s collbortive. They re in fct highly inter-relted, nd re useful in both creted nd creting systems. Indeed, they could be juxt-posed. In the spirit of good SE, S, nd E, they should be llowed to interct nd influence one nother positively. Reclling the words of Mrtin: Innovtion nd efficiency don t hve to be t odds. It is sometimes not obvious wht rchitectures relly men. In n cquisition nd supply reltionship ( greement processes ccording to the INCOSE Hndbook) two orgnistions intimtely interct. The output of the supplier orgnistion ( the product ) forms prt of the new cpbility of the cquisition orgnistion. Hence, when understnding both orgnistions, the required interction nd resultnt rchitectures cn be more useful. Following on this rgument, the mke/buy decision is criticl to defining internl nd externl opertions nd ssocited required cpbilities (technologies). S nd 45

18 E frmeworks nd prctices re essentil to the true integrtion of externl opertions nd deliverbles into the vlue chin, nd thus to creting mximum vlue for customers. It is essentil tht the S ctivities for ech project should be crefully identified, defined, nd contrcted to prticipting prties, nd should therefore be crefully tilored. Competitive compnies re likely to become genuine lerning orgnistions, mstering the rt of S nd E nd cretively mnging the interction mong them. However, the bility to implement S nd E successfully is just s chllenging nd s importnt s the underpinning theory. REFERENCES [1] INCOSE Systems engineering hndbook: guide for system life cycle processes nd ctivities, INCOSE-TP , Interntionl Council on Systems Engineering. [2] IDEF. IDEF process modelling methodology. [3] Webster's Dictionry. [4] Blnchrd, B.S System engineering mngement, 4 th ed., Wiley & Sons Inc. [5] Mrtin, J.N Systems engineering guidebook: process for developing systems nd products, CRC Press. [6] Gilb, T Competitive engineering: hndbook for systems engineering, requirements engineering, nd softwre engineering using Plnguge, Elsevier/Butterworth-Heinemnn. [7] Mier, M. & Rechtin, E The rt of systems rchitecting, 3 rd ed., CRC Press. [8] IEEE. IEEE rchitecture Working Group. [9] INCOSE, INCOSE System rchitecture Working Group. [10] Muller, G System rchitecture book, 18 th ed., Embedded Systems Technology. [11] Dickinson, B Creting customer focused orgniztions, LCI Press. [12] Boshoff, W Fitting business to the potentil of computing, in Business Processs Re- Engineering Seminr, Johnnesburg: Microdt. [13] Steyn, H Design nd entrepreneurship: concise guide to design with specil focus on the design of business, Pretori: MultiMedi ccess. [14] Lwler, J.P. & Howell-Brber, H Service-oriented rchitecture: SO strtegy, methodology nd technology, uerbch Publictions, Tylor & Frncis Group. [15] Steyn, H. Crruthers, M. et l Project mngement: multi-disciplinry pproch, 2 nd ed, Pretori: FPM Publishing. [16] Eisner, H Essentils of project nd systems engineering mngement, 3 rd ed., Wiley & Sons. [17] Bende, S.J The ppliction of systems-engineering principles on orgnistionl level, S Trnsctions of IEEE, ugust [18] Zchmn, J Zchmn Seminr, Sndton, South fric. [19] DoDF. Deprtment of Defense rchitecture Frmework (DoDF version 2.02), DoDF [20] Bordmn, J.T. & Turner, M.J From mke buy to mke disciples: rchitecting the extended enterprise, School of Systems nd Enterprises, Steven Institute of Technology, MS thesis. [21] Blnchrd, B.S. & Fbrycky, W.J Systems engineering nd nlysis, 5 th ed., Prentice Hll. [22] ISO Systems nd softwre engineering rchitecture description, ISO, ISO [23] Bende, S.J. & Pretorius, L System rchitecture nd enterprise rchitecture, competing concepts?, in ISEM Conference Proceedings, Stellenbosch. [24] Gilb, T Systems rchitecture: view bsed on multiple impcts, in Fifth Europen Systems Engineering Conference, Scotlnd. 46