GENERAL ARTICLES

 

System architecture and enterprise architecture: a juxta position?^#

 

 

S.J. Benade ^{I, *}; L. Pretorius^II

^IGraduate School of Technology Management University of Pretoria, South Africa. siebert.benade@up.ac.za
^IIGraduate School of Technology Management University of Pretoria, South Africa. leon.pretorius@up.ac.za

 

 

---

ABSTRACT

A systems approach to creating a system is discussed. The system engineering process, and specifically the system architecture process, is formulated and applied to a typical (physical) system, enterprise, and project. These lead to the concepts of system architecture (SA), enterprise architecture (EA), and project architecture (PA) respectively. Similarities and inter-relationships among these architectures and related methodologies are investigated, seeking better interaction among them. 'Work' is proposed as an important conceptual building-block of these architectures, properly defined as activity with associated inputs, outputs, governances, and mechanisms. Techniques such as functional analysis, process modelling, and task analysis are used to demonstrate the interrelationships among these apparently unrelated organisational perspectives of product, process, and project.

---

OPSOMMING

'n Stelselbenadering tot die daarstelling van 'n stelsel word bespreek. Die stelselingenieurs-wese,en spesifiek die stelselargitektuurproses, word geformuleer en toegepas op 'n tipiese (fisiese) stelsel, onderneming, en projek. Dit lei tot die konsepte van stelselargitektuur (SA), ondernemingsargitektuur (OA), en projekargitektuur (PA). Ooreenkomste en verwant-skappe tussen hierdie argitekture word ontleed om beter onderlinge interaksie te bewerkstellig. 'n Belangrike konseptuele bousteen van hierdie argitekture word voorgestel as 'werk', behoorlik gedefinieer as aktiwiteit met gepaardgaande insette, uitsette, kontroles, en meganismes. Tegnieke soos funksionele analise, prosesmodellering, en taakanalise word gebruik om die onderlinge verbande tussen hierdie skynbaar onverwante organisatoriese perspektiewe van produk, projek, en proses, te demonstreer.

---

 

 

1. INTRODUCTION

System architecture (SA) and enterprise architecture (EA) in technology-based enterprises are explored, giving special attention to the interaction between these two worlds. The question posed is whether the concepts are fundamentally the same, competing, or perhaps independent. The concepts are compared in terms of purpose, origin, structure, and utilisation. The question originates from the reality that SA and EA are often perceived in business and industry to be completely different and unrelated. The concepts are linked to different fields of study and different professions. The authors address EA as the creating system, and SA as the created system.

In simple terms, SA can be seen as a description of the high-level functions and sub-systems of a 'to-be-developed' system in its intended operational environment. The primary function of SA is to enhance the understanding and high-level definition of complicated and often high-tech systems, and to direct the subsequent development process. There is some controversy in industry and academia about whether or not SA is a new development in the domain of system engineering (SE). Arguments range from whether SA should be performed before, be integral to, or be done in addition to the SE process. The question often asked in industry is whether a cumbersome effort such as SA is required at all.

Enterprise architecture is typically described as a model of the enterprise (organisation) in terms of business processes, information, and required resources. These business processes are seen as the vehicle to create and deliver value to customers. This business process definition also seeks to bridge the divide between the business and ICT functions of the enterprise. Today, despite all the powerful ICT and other technologies available, organisations battle to bridge the divide between the 'business-side of business' and the 'ICT-side of business'. In the final analysis, this appears to be a people issue, not a technology issue.

SA and EA initiatives are often launched independently in companies. Different project teams argue about which project - SA or EA - add more value to the enterprise. Participants do not always appreciate that they are working on either the created system or the creating system within the same organisational system.

The interaction between the project and the enterprise is further analysed. Traditionally, projects were seen as subsets of companies. However, large multi-enterprise and multinational projects (programmes) turned this notion around. In fact, companies are often founded during, or as a result of, large projects. Technologies, knowledge, skills, and tools required to execute SA projects to meet the needs of customers are often ignored during enterprise improvement efforts. Company process standardisation and integration, as well as IT enablement, are often the main focal points, and as a result significant integration opportunities are lost. These two approaches are often seen as being in conflict, and fail as a result of resistance to both change and collaboration. Although both approaches could be highly technological, they impact the individual and thus the total enterprise. A systems approach towards the creation of any system is proposed and demonstrated on a high level. The basic SE process, as defined by the International Council on System Engineering (INCOSE), is used as a point of departure [1].

The SA process (architecting) is further formulated and applied to a typical (physical) system, enterprise, and project. The resultant concepts of SA, EA, and project architecture (PA) are described and compared. There are various similarities and differences that should be catered for. Similarities and inter-relationships among these concepts are analysed, and proposed as a point of departure to improve and better integrate the enterprise. The focus is on the technology-based enterprise. However, the principles and processes presented could be valuable to any organisation. The notion of "work" (activity, process, function, task, etc.) is proposed as a common denominator and a conceptual building-block of these systems. Work is further defined as executed on a system or by a system. The 'fully-defined- activity', in IDEF0 (Integrated Definition Language for Functional Modeling) format [2], is described and applied to the product (system), enterprise, and project arenas.

Functional analysis in the SA domain is used to create a functional breakdown structure, describing the functions that the to-be-developed system needs to perform. Business process modelling in the EA domain creates a business process model that describes the processes to be executed in the organisation, and typically forms part of the so-called enterprises business architecture. Task analysis is done to define the work required on a project, and typically leads to the creation of a statement of work, work breakdown structure, critical path, etc. The analyses of work, whether to be done on or by a system, are used to explain the inter-relationships among these apparently unrelated organisational perspectives. These different perspectives, often perceived and managed as independent systems, need to be understood and integrated.

Analysing different definitions and approaches to system architecture indicates an inclination either towards (physical) systems, or more likely, towards organisations. Secondly, a variety of definitions highlight the process to create, as well as the structure (configuration) as key parameters to describe architectures. Improving meaningful interaction between acquisition and supplier organisations can be found in the better understanding of the system (and enterprise) architectures of both organisations. The evolution of INCOSE, the system engineering fraternity, over several years is significant, as it has shifted from focusing on the deliverable system to including the full organisational perspective in relation to key processes. The importance of the 'make/buy' decision becomes apparent. The strategic nature of the decision, and its effect on associated architectures, is addressed. Technology (existing and new) is highlighted as a key driver in architecting. Process models are further developed to demonstrate the interaction among product, process, and project.

 

2. RESEARCH APPROACH

• The research was done as an exploratory study addressing the formulation, structure, and use of system architectures and enterprise architectures and their interrelationships.
• Inter-relationships were analysed, and a high-level conceptual business process model was developed in an effort to understand and depict these inter-relationships better. A similar model was originally developed by the authors to facilitate work sessions during business redesign and modelling initiatives in industry and in the academic environment.
• The notion of 'process' was rediscovered as the 'golden thread' or common denominator running through the enterprise, systems (products and related services), and projects. Different process perspectives were analysed and further developed. Similarities were identified among the enterprise, system, and project environments.
• The challenge of 'creating value for customers' vs. 'creating new capability' within the value chain was analysed.
• Finally, the role of 'process' was also compared with the fundamental architecture design process.

The literature survey is presented in sections 3 to 8, followed a discussion of the main contributions in sections 9 and 10. The article concludes with section 11.

An intensive literature study was conducted to enhance the understanding of what SA and EA meant to the leading authors and researchers in these fields. A number of Masters theses, of which the corresponding author was the study leader, were used as building blocks to highlight and validate further some of the concepts and findings of this research. Several issues directed the literature survey, starting with the definitions and the relationship between the fields of SA and EA in section 3. That section highlights the confusion in academia and industry about the fields of SA and EA. For example,-

'technology' is discussed when ICT is meant, and architecture described by a system engineer will most probably mean system (physical or software) architecture, not EA. Architecture for a business consultant would mean EA, not SA; and so forth. Furthermore, architectures are often defined in terms of what they do, not what they are.

Section 4 introduces prominent theoretical frameworks that highlight the different perspectives on structure, content, and architecture use. In section 5 we discuss the relationship between the created and creating systems. They are highly interrelated, and require in-depth analysis. Section 6 motivates the idea that make/buy decisions extend the boundary of the enterprise, and that the resultant effect on to-be-developed architectures and procurement processes needs to be properly understood.

Section 7 provides a value-chain perspective of an enterprise, in order to introduce the argument in sections 9 and 10. Section 8 concludes with the literature on IDEF (Integrated Definition Language for Functional Modeling) as an analytic tool to compare product, process, and project.

 

3. ORIGINS OF SYSTEM ARCHITECTURE AND ENTERPRISE ARCHITECTURE

3.1 The meaning and definition of system architecture

The meaning, definition, and practice of SA are analysed and discussed in this section. It is important to understand what a system architecture is and what it does, because this provides a foundation for the subsequent argument.

Webster's Dictionary [3] defines architecture as "the art, science or practice of designing and building structures. The structure should be coherent and unifying". Blanchard [4], describes a system architecture as follows: "An architecture deals with a top-level description of system structure (configuration), its operational interfaces, anticipated utilization profiles (mission scenarios), and the environment within which it is to operate; then, it describes how these various requirements for the system interact. This leads to the description of the functional architecture, which evolves from the functional analysis and its description of the system in functional terms". Martin [5], describes it as "The highest-level concept of a system in its environment. It deals with a system structure, operational interfaces, profiles of use, and how the elements of a system interact with each other. It can also be defined in terms of scenarios along with expected behaviour for each scenario; states, modes and configuration of system elements". Gilb [6] defines sytem architecture as "a set of artifacts created by Architecture Engineering. A systems architecture is a strategic framework and consists of models, standards and design constraints specifying mandatory and recommended best practice for implementing and maintaining systems".

Maier & Rechtin [7], define architecture as "The structure - in terms of components, connections, and constraints - of a product, process, or element". They emphasise that the core of architecting is system conceptualisation, which is often more art than science. They also suggest that, to formulate a good definition, one should consider what an architecture is suppose to do: "providing information that defines a system's value, cost, and risk sufficiently for the purposes of the system's sponsor. An architecture should help a client to make decisions about building systems. When the client makes acquisition decisions, architecture has been done (perhaps unconsiously and perhaps badly, but done)".

The Architecture Working Group of IEEE (AWG) [8] defined architecture as "The fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution". The INCOSE Systems Architecture Working Group (SAWG) [9] defined the architecture of a system: "The fundamental and unifying system structure defined in terms of system elements, interfaces, processes, constraints, and behaviors". These two definitions are quite similar. Muller [10] proposes that "system architecting is a means to create systems efficient andeffective, by supplying overview, by guarding consistency and integrity, and by- balancing. In other words the system architect helps the development team to find its way in a rather complex, dynamic and uncertain world".

In summary then, these definitions have four common focal points: the operational or business context within which the to-be-developed system will function; the process to create a system architecture; the structure of the architecture itself; and the use of the architecture.

Table 1 was developed by the authors. It compares the emphasis placed on different aspects of SYSTEM ARCHITECTUREby different authors and working groups in the field of SA. The scale goes from open, to x, then X, then XX. The scale is relative, and seeks to give an indication of emphasis. It is evident from the above discussion that authors focus on different aspects of SA. It is thus important, when the term 'system architecture'is used, that the intended meaning is clearly defined and communicated.

 

 

3.2 The meaning and definition of enterprise architecture

There are a variety of approaches, definitions, and perceptions about EA. When one speaks about EA, people often understand it to mean only the IT-side of the business - the enterprise IT architecture. Sometimes people only focus on business processes and ignore the rest of the EA. Often EA is perceived to be a highly technical and detailed initiative; the strategic core of it is ignored. The meaning, definition, and process of EA are addressed in the next sections. It is important to develop a common understanding of what an EA is and what it can be used for, before any such initiative is undertaken. The authors perceive EA to be a 'special kind' of SA, or the 'application of SA to the organisation'.

Dickinson [11] states, "We need some way to 'see' the essential business without seeing the implementation thereof". He emphasises the need to model the business to establish understanding and make decisions before the business has been (or should be) fully implemented. Boshof [12] suggests that "theory, concepts and frameworks are essential tools for organising facts. How we observe the facts is a function of the theory, concepts and frameworks we use". This seems a trivial point, but it is often the origin of our misunderstanding, prejudice, and inability to fully collaborate. This problem could be addressed by formulating relevant 'theories, concepts and frameworks' and incorporating them into EA. Steyn [13] states that enterprise design denotes a process that reconciles the strategically desirable with the economically feasible. He proposes that a "sound fundamental system design process" be applied to the enterprise; hence the design or architecting of the enterprise. Lawler & Howell-Barber [14] argue that "Business Enterprise Architecture defines the design of the detailed tasks of the business processes, the business policies (e.g. management of meta-data), and the information technologies included in an IT infrastructure, based on the definition of what a firm does as a business". They further emphasise that "it is important to note that enterprise architecture (including services) is- based on business decisions or a definition of business strategy, and not on technical decisions or (IT) technology strategy". According to Maier & Rechtin [7], Peter Weil of MIT defines EA as follows: "The organizing logic of key business processes and IT capabilities reflect the integration and standardization requirements of the firm's operating model". As previously discussed, Muller [10] proposes that "system architecting is a means to create systems efficiently and effectively, by supplying overview, by guarding consistency and integrity, and by balancing". It is important to realise that he uses the same description for the architecting process and purpose of SA in general, and for EA.

3.3 Why system architecture?

According to Muller [10], it is often easier to understand system architecture in terms of what it does than what it is. SA'operates' in the grey and fuzzy world between the 'problem organisation' and the 'solution organisation'. A number of interactions between the organisation that experiences a problem or sees a business opportunity and organisation(s) that could potentially provide a solution are shown in Figure 1 below. The interactions described are by no means meant to be complete, but merely highlight important processes leading to SA. They immediately suggest that system architecture should be both art and science, and that it is more than merely a technical specification of some system (solution).

 

 

3.4 The origin and development of enterprise architecture

EA originated from, and is influenced by, a number of business areas: the manufacturing industry, with material requirements planning (MRP) and later manufacturing resource planning (MRP II). These approaches developed into the so-called supply chain or value chain (Porter et al). Not only were the incoming logistics and internal operations considered, but also the flow of material to and from customers.

The second origin of EA growth is to be found in process modelling and design approaches, such as business process re-engineering (Hammer et al). These approaches seek to depict the enterprise in terms of business processes, leading to process improvements and 'end-to-end' process integration. Corporate and process governance, organisational adaptability, and IM/IT system integration were typical considerations. Organisations were consequently often restructured to become 'flatter' (with fewer management layers), and were labelled process-centred or process-oriented organisations.

A third development is a type of backward integration, where software developers aim to understand and serve the business world better with 'functioning and value-adding' software solutions (business applications). It is a well-known fact that enterprise integration software (such as ERP) is often considered to be a failure by business users and owners. This is in spite of the current phenomenal technological capabilities that were not available 10 to 15 years ago. According to Maier & Rechtin [7], "the strategy an IT system embodies should be that of the organization it belongs to as a whole, not that of just the IT- controlling organization". This sounds obvious, but the challenge to close the great divide between the business and IM/IT side of the enterprise still confronts us. This issue can also be traced back to Boshoff [12], who states that how we observe facts is a function of the theory, concepts, and frameworks we use. Clearly, the point of departure and the paradigms guiding the thinking and priorities of 'business people' and 'IT people' are different.

Trends in the project management field have a significant effect on organisations today and thus on developments of EA. This is often not fully realised by EA practioners or IM/IT application developers. EA initiatives and typical ERP types of systems primarily revolved around process-oriented organisations. Project management software traditionally focused on managing a project, not the organisation. Most work in organisations today is planned and executed around projects. Even the so-called process-orientated organisations are to a considerable extent run as projects. Steyn et al state that the challenge today is not only to manage a single project, but to run any number of projects as a 'portfolio of projects' [15]. Projects are to be identified, scoped, approved, launched, and then managed. Decision-making processes, the use of scarce resources, and re-prioritisation of projects are typical challenges in the project-portfolio arena. Business strategy implementation is often managed as a project and no longer by department. Project management, and specifically portfolio management, has become a vital ingredient of strategic management and, consequently, also of EA. It is interesting to realise that typical EA endeavours are run as projects as well - a case of one hand washing the other. There is a developing trend that some organisations are organised in terms of projects, leading to the so-called 'project-centred' organisation. The link to EA is clear. Maier & Rechtin [7] describe the strategic architecting of programmes elegantly, by emphasising the importance of organisational context and overall business strategy in selecting programmes.

 

4. THEORETICAL FRAMEWORKS

In the previous section, the definition and meaning of architectures were analysed and discussed as a foundation for later argument. A number of theoretical frameworks are addressed in the paragraphs below, shedding more light on the structure, content, and use of architectures.

4.1 System architecture frameworks

It is interesting to note that the system engineering fraternity - e.g., INCOSE and the system architecting group of IEEE - present their high-level architecture definitions and frameworks primarily in 'process format', while they are focused on delivering 'systems' (products and related services) to customers. According to Blanchard [4], Eisner [16], Maier & Rechtin [7] and others, an important point of departure is that SA is an integral part of the SE process.

The process to create a system architecture is called system architecting. It is, in essence, a conceptualising process that aids in decision making. Muller [10] suggests: "System architecting is a means to create systems efficient and effective, by supplying overview, by guarding consistency and integrity, and by balancing. In other words the system architect helps the development team to find its way in a rather complex, dynamic and uncertain world".

• Process groups of the ISO/IEC 15288 Standard

The SE Handbook of INCOSE [1] includes the process groups defined in ISO/IEC15288: 2008 Standard as their official definition, as shown in Figure 2. This is a very positive development, since there exist a wide variety of definitions to define SE and related processes, often leading to confusion. This lack of standardisation also negatively impacts development of a model-based SE process.

 

 

This definition started off by focusing on the technical processes (systems perspective), evolving to include project processes, and finally including organisational processes. However, the authors believe that parts of the technical processes are not elegantly defined, since no clear distinction is made between system design and manufacturing. Both are catered for merely as 'implementation'. Overall, the demarcation of the process groups is meaningful.

• SA framework as defined by Eisner

According to Eisner [16], the development of a basic architecture is the centrepiece of the total systems engineering process. It is fundamentally a synthesis procedure, and normally requires:

> the formulation of alternative system architectures; and

> analysis of the postulated architectures to verify that they satisfy system requirements.

This statement suggests that SA is at the core of, and integral to, the SE process. The SE process is defined by different authors and other references in terms of the purpose of the overall SE process and the constituent sub-processes. Therefore SA is also defined in terms of the 'hosting' SE process. This notion is echoed by Blanchard, Martin, Maier & Rechtin, and others. From a list of thirty-two suggested SE sub-processes, Eisner [16] identified eight as representing the SA process:

> requirements analysis and allocation;

> functional analysis and decomposition;

> architecture design and synthesis;

> alternative analysis and evaluation;

> technical performance management;

> life-cycle costing;

> risk analysis; and

> concurrent engineering.

• SA framework as defined by Maier & Rechtin

On a more philosophical level, Maier & Rechtin [7] define the foundation of modern SA as follows:

> a systems approach;

> purpose orientation;

> modeling methodology;

> ultra quality implementation; and

> certification.

This definition is more about a high-level purpose and approach. Each one of the 'foundation elements' implies a specific process. A significant part of SA processes is based on heuristics, not natural sciences alone. This signifies the importance of SA as art, not only as science.

4.2 Enterprise architecture: The basic building blocks

According to Benade [17], an EA is typically partitioned into four conceptual building blocks: enterprise business architecture (EBA), enterprise information architecture (EIA), application portfolio (EAP), and enterprise IT architecture (EITA) - schematically shown in Figure 3. The building blocks, neither physical nor clearly demarcated, are inseparable, and should be treated as 'perspectives' of the enterprise rather than as sub-systems. This EA approach was studied and applied to various projects during the late 1990s by the corresponding author. The approach is loosely based on material from Zachman [18] and on his well-known Zachman framework. The focus of this paper is, however, on the EBA, and specifically on business processes. As with any design (or model), the context is extremely important. In this case the 'strategic business context' is the guiding one. Zachman [18] emphasises that EA offers an ontology (structure and definition), not a methodology. This implies that the different EA approaches explain what an EA should encompass, but not how to create it. In this case, the process of system engineering is very useful.

 

 

One of the challenges of EA is the conflict between existing processes, knowledge, and innovation. Martin [5] suggests that "innovation and efficiency don't have to be at odds". He unveils a new way of thinking that "balances the exploration of new knowledge (innovation) with the exploitation of current knowledge (efficiency) to regularly generate breakthroughs and create value for companies. Design thinking focuses on accelerating the pace at which knowledge advances from mystery (an unexplainable problem) to heuristic (a rule of thumb that guides us toward a solution) to algorithm (a replicable success formula). As knowledge moves through this knowledge funnel, productivity grows and costs drop. But design- thinking organisations don't stop there. They use the efficiencies they generate to constantly tackle new mysteries and explore potential breakthroughs". This is a fresh way to look at the learning organisation and to challenge the fear of change. This approach is important, since this article revolves around the design of systems and enterprises, thus encouraging 'design thinking'.

4.3 Enterprise architecture frameworks and standards

There is a variety of EA frameworks, standards, and practices in the literature and industry. Most EA frameworks refer back to Zachman, or resemble his framework. They are often derivatives of one another. Well-known EA frameworks referred to in the INCOSE Handbook [1] include DODAF [19], TOGAF, and MODAF. Figure 4 shows the Ministry of Defence architecture framework (MODAF) as an illustration.

 

 

EA frameworks support the notion of different 'views' of the same enterprise, i.e. not subsystems.All participating organisations should have an EA of some sort, to make the definition, integration, and change of 'work' effective and efficient.

It is important to realise that EA frameworks, such as the Zachman framework, provide a fundamental ontology, not a methodology. Ontology refers to the structure (configuration), definition, and description of an architecture. The process to create an architecture, or to 'populate all the EA elements', requires a methodology. The discipline of system engineering (and specifically SA) approaches architecture primarily as a 'process to create a system'. This is a fundamentally different point of departure. The authors believe that understanding both EA and SA, and leveraging their strengths, could lead to new insights and value.

 

5. THE RELATIONSHIP BETWEEN CREATED AND CREATING SYSTEMS

The 'work' that should be done to acquire a system and related services forms an integral part of the capability (technology and others) that the enterprise as 'creating system'should possess to be successful. This is the primary relationship between the created and creating systems. The system (or service) 'created' in an enterprise can have a far-reaching effect on the enterprise in terms of what should be done and how it should be done. This is even more so when 'to-be-created' systems are high-tech, complex, large, and expensive. Often, personnel perceive the organisational structure as the way that they do business. But this is seldom the case. Executing business processes (across organisational boundaries), or working on projects, normally leads to the creation of value and deliverables to customers. When analysing the above-mentioned definitions of SA and EA, the similarities are obvious. The underlying (common) question is how to specify, design, and realise a system. This issue is elegantly described by Steyn [13] in terms of the process of designing a business.

The enterprise as the creating system was addressed in paragraph 3.4. The process used by the enterprise to create, for example, systems for customers, could be system engineering. The fact that EA does not provide a methodology to create an enterprise was highlighted. To establish a system, including the enterprise as system, requires an ontology and a methodology. The meaningful interaction between EA and SA now becomes apparent.

 

6. MAKE/BUY DECISIONS LEADING TO THE EXTENDED ENTERPRISE

Historically, a decision that had to be made was whether a component or product should be manufactured within the organisation or procured from a suitable supplier. According to-

Boardman & Turner [20], the notion of 'make or buy' has a much wider implication today. For any business process, the question is whether it should be performed in the company or outsourced. This immediately raises the question of how to make this decision, and according to which set of criteria. One could approach this from a life-cycle perspective: that is, activities in any system life-cycle phase could be a candidate for outsourcing. According to the authors, at least four important areas should be considered when make/buy decisions are made:

> existing and required technologies;

> system development and related resources;

> system manufacturing and related resources; and

> system support and related resources.

Various combinations of outsourcing are possible, making contracting and project control very challenging. It is not only the exchange of products, but also the exchange of services and information that has become paramount. Configuration management becomes an important issue needing careful definition and management. Meaningful service-level agreements should be entered into. This leads to the concept of the 'extended enterprise'. The challenge is to contract and manage the processes external to an organisation so that the quality of the processes is acceptable, and the end-result can be seamlessly integrated into the organisation's own internal processes, thus satisfying its customers. The quality of suppliers is often to be found in the way processes are executed, not just in their end-products (deliverables). It is essential that the SA activities for each project should be carefully identified, defined, and contracted to participating organisations.

The efficiency of this organisational interaction, specifically in the information and services age, has become a huge business challenge. Mass customisation and changing technologies, for example, and the extreme pressure to respond to change (throughout the total value chain) makes the use of agreed-upon architecture frameworks and implementation practices the next business challenge.

 

7. ORGANISATIONS IN THE VALUE CHAIN

The fundamental views of the user/owner, the designer, and the builder were the point of departure for Zachman and subsequent EA authors and researchers. These views still provide very useful insights today.

7.1 The customer organisation

One of the fundamental principles of SA is that a system should be designed within context. According to Blanchard & Fabrycky [21], a system is always part of a bigger system. The customer organisation typically inludes the owner and (end-) user of the 'to-be-developed system'. The system will typically be specified and finally accepted and implemented according to specification(s). The new system will thus contribute towards the capability of the organisation. The MODAF can help an organisation to understand its customer or end-user better, hence creating a better 'fit' regarding the new system to be implemented. The functions ('work') required of the new system are the key interaction between the customer organisation and the designer organisation.

7.2 The designer organisation

The successful development of a required system for the customer environment is the key capability of the designer organisation. Understanding and designing the required functions ('work') of the new system is essential for the designer organisation. The absence of good requirements management remains one of the most common causes of project failure. The 'work' that the new system is supposed to perform is often not properly understood by designers, even though system design constitutes the primary output of the design organisation [5]. The design should include definitions of the product and of the manufacturing, operating, and support processes. These definitions are different views of the system definition, not subsets of it. The concept of an integrated product definition is essential to the argument.

7.3 The builder organisation

The new system should be built according to its design. This is only plausible if the design includes the manufacturing definition, as noted in the previous paragraph. Ideally, the builder organisation should have participatedin the design of the system [1], [22]. Typically, the manufacturing process and manufacturing system should be specified and designed with the manufacturability of the system in mind.

7.4 The support organisation

Support, in essence, comprises supply and maintenance. The early participation of the support organisation(s) is critical, especially for complex systems. Effective fault diagnosis and corrective action are essential to maintain complex systems in the user environment. It is crucial to design such complex systems to enable efficient support, since it is generally a significant challenge to add this feature later. Consequently, the support process and -system should be designed to be an integral part of the overall system definition. The 'work' to be done eventually to support the system is critical. Support activities could be executed by the customer organisation, design/builder organisations, and other suppliers [19]. It is imperative that make/buy decisions in the support environment be considered carefully.

 

8. 'WORK' AS COMMON DENOMINATOR AMONG DIFFERENT ARCHITECTURES

The definition and execution of 'work' is an important ingredient in the product/system arena, the project world, and the enterprise. Work can be done on or by systems. When work is defined, the next logical step is to define the resources required to execute the work. The resources are then organised into a meaningful structure, configuration, or architecture. This very basic logic is equally applicable to the product/system design arena (i.e. SA), the planning and execution of projects (i.e. PM), and in the design and structuring of enterprises (i.e. EA). Because it appeared to be a rather trivial point, the commonality of work is often overlooked. Work is defined and modelled in similar ways in these areas. The 'Integrated Definition Language for Functional Modelling' (IDEF) is briefly described in the next section (refer also to the IDEF website) [2]. According to the IDEF methodology, shown in Figure 5, an activity and its associated objects (inputs, outputs, controls, and mechanisms) are defined. Any number of activities can be strung together to create a process.

 

 

The focus of this article is on the IDEF0 format only. The basic logic of an IDEF0 model is the following:

> Inputs get processed to create meaningful outputs.

> The value of the outputs should be more than the inputs.

> The activity should be executed within the boundaries of defined controls or governance.

> The activity gets executed by certain defined mechanisms.

> The inputs and outputs must futhermore adhere to specified quality requirements.

This specific representation of an activity and its associated inputs, controls, outputs and mechanisms (ICOMs) is shown in Figure 6, and is an example of IDEF0. The inputs and- outputs are arranged in sequence to give examples of different activities (processes). This 'fully-defined activity' (i.e. activity and related ICOMS) can be seen and used as a basic building block of the product/system, the project, and the enterprise. The argument can clearly be expanded to use IDEF3 format, where time and sequence are also analysed and modelled, or IDEF1X, where object transformation ('data modelling') is done.

 

 

The literature survey addressed definitions in, and relationships between, the fields of SA and EA. Prominent theoretical frameworks of EA and SA were discussed. The close relationship between the created and creating system was analysed. Then make/buy decisions, extending the boundary of the enterprise, were discussed. The created and creating system and make/buy decisions are two sides of the same coin, since they both represent the organisation and the output of the organisation. A value-chain perspective of the enterprise and the related supply chain was presented. The importance of agreeing on SA activities amongst participating organisations was emphasised. It was concluded that both the created and creating system require an EA ontology and methodology to be meaningfully established. All of the above, if not properly managed, could contribute to the so-called 'fragmented organisation'. The main contribution of this research is presented in sections 9 and 10.

 

9. THE DEFINITION OF 'WORK' FOR PRODUCT, PROCESS, AND PROJECT

Organisations are negatively affected by the confusion in academia and the industry about the fields of SA and EA. The challenge of organisational fragmentation was previously referred to. The concept of 'work' is investigated and proposed as a point of departure for enhancing the integration of enterprises, and specifically addressing the product, process, and project perspectives.

The interaction and intersection of product/system, (business) process, and project is important views of the organisation, especially in the technology-based enterprise. The different areas are shown in Figure 7, with some typical activities, key characterisitcs, and issues related to each area.

 

 

9.1 Product/System: Functional analysis leading to a functional architecture

Products/Systems and services are typically created by executing a product/system development process (often called the first creation), and then performing the manufacturing process (the so-called second creation). One of the early steps in the design process is the functional analysis, where problems and user requirements are analysed and required system functions are identified and defined [21]. A function is defined as a required capability. A functional system breakdown (FBS) is then typically created, leading to the creation of the functional system architecture.

The functional analysis is the first step towards creating a potential solution, and therefore a synthesis. To put a function into action, a suitable mechanism (resource) needs to be allocated. An executable process can thus be created. Potential resources (sub-systems) are allocated to functions. The functional definition constitutes the processes (work) that the to-be-developed system must perform. Subsequently, system requirements are allocated to resources (sub-systems). These sub-systems are organised into a meaningful structure, leading to the SA. These activities are typically done during the preliminary design phase (according to the SE process), and the output of this phase is consequently called the 'allocated baseline'. Blanchard [4] states: "The functional analysis can facilitate an open-architecture approach to system design. A good comprehensive functional description of the system, with the interfaces well defined (qualitatively and quantitatively), can lead to a structure that will not only allow for the rapid identification of resource requirements, but also permit the possible incorporation of new technologies later". A functional breakdown can be presented in hierarchical form or process form - e.g., IDEF or functional flow block diagramme (FFBD) format. Figure 8 shows the activity in principle as 'function of system' in IDEFO format.

 

 

9.2 Process: Business process modelling as input to an enterprise architecture

Processes are defined, standardised, and executed in enterprises to sustain quality of work and create the end result (deliverables). Organisational design, business design, or EA are typically done through (business) process analysis, modelling, and design to define how work should be done in the organisation. End-to-end process integration is strived for.

These business process model(s) form the backbone of the to-be-designed enterprise. Subsequently, potential resources (mechanisms) are identified and allocated to specific processes. These mechanisms can be people, software, hardware, IM/IT systems, etc. Figure 9 schematically shows a typical IDEF0 activity model. Business objects are furthermore identified and organised into business object models or simply into data models (e.g. IDEF1X). These business process and business object models provide the core inputs towards defining the enterprise. The typical enterprise architecture building blocks, as shown earlier in Figure 3, are created. All of these models are created within the strategic context of the company.

 

 

9.3 Project: Task analysis leading to a project breakdown structure

Project management is used to structure, manage, and outsource work in order to create deliverables for customers effectively and efficiently [15]. As previously discussed, most work executed in companies today is managed as projects; hence the importance of project management. The full definition of required work is given in a statement of work (SOW), work breakdown structure (WBS), and different types of task analysis/models - e.g., critical path analysis, project schedules, and long-lead item schedules. Most initiatives to develop, implement, or change an SA or an EA are typically done as projects to make it more manageable. The project management perspective on SA and EA is important and is shown schematically in Figure 10. The activity in the process model is expressed as 'work' in a project, and it therefore forms part of the WBS and SOW. Resources allocated to the WBS eventually constitute the project breakdown structure (PBS). The PBS is a temporary organisational structure until the project has been completed and discontinued.

 

 

9.4 Comparison of product, process, and project

The authors suggest that the definition of 'work' in the above-mentioned areas of product/system design, EA, and project planning is essential for design activities, and thatthe design processes are similar. The typical design activities - that is, system requirements analysis and definition, design process (synthesis and analysis), methods of presentation, allocation of requirements and resources to processes, and final structuring of resources into a system architecture- are shown and compared in Table 2.

 

 

10. PROCESS MODEL OF THE TECHNOLOGY-BASED ENTERPRISE

A generic business process model, as shown in Figure 11, was developed by the corresponding author while executing various projects and performing a consulting role between 1995 and 2002. The model was later successfully used to define processes, information, and required IT systems in an academic environment as well. The model is presented in IDEF0 format, and was found valuable as a communication tool in the technology-based enterprise to create common understanding between different project teams. It is used to bring together SA and EA teams to discuss business processes and required resources/technologies, meta-data, required information and information flows, etc.

 

 

The key processes of 'creating value for customers' vs. 'creating new capability' within the enterprise and participating supply chain were analysed. The process of 'perform technology management' as shown in Figure 11, process 4, is closely related to the 'creation of new capability' within the technology-based organisation. This formally addresses the sustainability of the enterprise from a technology point of view. Obviously not all 'new capabilities' are technology-related.

The model is not meant to be complete: it merely shows some important processes and ICOMs. It is also not proposed as the final answer, but rather as a point of departure and discussion. It is also valuable for identifying required process controls and for designing and implementing a meaningful governance architecture. The model clearly needs to be expanded, depending on the purpose and nature of the SA or EA project.

The fundamental design process proposed by INCOSE, Steyn, and various others can be applied to different to-be-developed systems, be they products, projects, or enterprises. However, the process should be carefully and thoroughly tailored to meet the specific circumstance in the best way. (Refer to Table 1, where similarities, differences, and important interactions among the concepts are described). Business consultants, project managers, and system designers are typically 'trapped' within their respective understanding of work as business process, WBS, and function of a product (refer to Figures 8, 9, and 10). It was found very useful to generalise work and model in a similar fashion using, for example, IDEF0. This notion of 'work' is essential to define and model any system, and can act as a powerful integration mechanism. The IDEF modelling methodology, although relatively old, is very useful to model 'work', and so act as an important input to SA.

Any architecture should be developed within an agreed-upon strategic context. This sounds obvious, but failing to do so is often the cause of project failure. This problem is often present during product design, business process redesign, and enterprise architecture projects.

Whether architecting is perceived to be similar to design (with its origin in the physical system development arena) or to the establishment of an organisation, appeared to significantly influence the thinking processes of people. The concepts of SA and EA should not be perceived as independent, but as collaborative. They are in fact highly inter-related, and are useful in both created and creating systems. Indeed, they could be juxta-posed. In the spirit of good SE, SA, and EA, they should be allowed to interact and influence one another positively. Recalling the words of Martin: "Innovation and efficiency don't have to be at odds". It is sometimes not obvious what architectures really mean. In an acquisition and supply relationship ('agreement processes' according to the INCOSE Handbook) two organisations 'intimately' interact. The output of the supplier organisation ('the product') forms part of the new capability of the acquisition organisation. Hence, when understanding both organisations, the required interaction and resultant architectures can be more useful. Following on this argument, the make/buy decision is critical to defining internal and external operations and associated required capabilities (technologies). SA and EA frameworks and practices are essential to the true integration of external operations and deliverables into the value chain, and thus to creating maximum value for customers.

It is essential that the SA activities for each project should be carefully identified, defined, and contracted to participating parties, and should therefore be carefully tailored.

Competitive companies are likely to become genuine learning organisations, mastering the art of SA and EA and creatively managing the interaction among them. However, the ability to implement SA and EA successfully is just as challenging and as important as the underpinning theory.

 

REFERENCES

[1] INCOSE. 2011. Systems engineering handbook: A guide for system life cycle processes and activities, INCOSE-TP-2003-002-03.2.1, International Council on Systems Engineering.         [ Links ]

[2] IDEF. IDEF process modelling methodology. http://www.IDEF.com.         [ Links ]

[3] Webster's Dictionary.         [ Links ]

[4] Blanchard, B.S. 2008. System engineering management, 4^th ed., Wiley & Sons Inc.         [ Links ]

[5] Martin, J.N. 1997. Systems engineering guidebook: A process for developing systems and products, CRC Press.         [ Links ]

[6] Gilb, T. 2005. Competitive engineering: A handbook for systems engineering, requirements engineering, and software engineering using Planguage, Elsevier/Butterworth-Heinemann.         [ Links ]

[7] Maier, M. & Rechtin, E. 2009. The art of systems architecting, 3^rd ed., CRC Press.         [ Links ]

[8] IEEE. IEEE Architecture Working Group.         [ Links ]

[9] INCOSE, INCOSE System Architecture Working Group.         [ Links ]

[10] Muller, G. 2011.System architecture book, 18^th ed., Embedded Systems Technology.         [ Links ]

[11] Dickinson, B. 1998. Creating customer focused organizations, LCI Press.         [ Links ]

[12] Boshoff, W. 1997. Fitting business to the potential of computing, in Business Processs Re-Engineering Seminar, Johannesburg: Microdata.         [ Links ]

[13] Steyn, H. 2007. Design and entrepreneurship: A concise guide to design with a special focus on the design of business, Pretoria: MultiMedia Access.         [ Links ]

[14] Lawler, J.P. & Howell-Barber, H. 2008. Service-oriented architecture: SOA strategy, methodology and technology, Auerbach Publications, Taylor & Francis Group.         [ Links ]

[15] Steyn, H. Carruthers, M. et al. 2008. Project management: A multi-disciplinary approach, 2^nd ed, Pretoria: FPM Publishing.         [ Links ]

[16] Eisner, H. 2008. Essentials of project and systems engineering management, 3^rd ed., Wiley & Sons.         [ Links ]

[17] Benade, S.J. 2005. The application of systems-engineering principles on organisational level, SA Transactions of IEEE, August 2005.         [ Links ]

[18] Zachman, J. 2009. Zachman Seminar, Sandton, South Africa.         [ Links ]

[19] DoDAF. Department of Defense Architecture Framework (DoDAF version 2.02), DoDAF 2.02.         [ Links ]

[20] Boardman, J.T. & Turner, M.J. 2009. From make buy to make disciples: Architecting the extended enterprise, School of Systems and Enterprises, Steven Institute of Technology, MS thesis.         [ Links ]

[21] Blanchard, B.S. & Fabrycky, W.J. 2010. Systems engineering and analysis, 5^th ed., Prentice Hall.         [ Links ] [22] ISO. 2011. Systems and software engineering - architecture description, ISO, ISO 42010.         [ Links ]

[23] Benade, S.J. & Pretorius, L. 2011. System architecture and enterprise architecture, competing concepts?, in ISEM Conference Proceedings, Stellenbosch.         [ Links ]

[24] Gilb, T. 2006. Systems architecture: A view based on multiple impacts, in Fifth European Systems Engineering Conference, Scotland.         [ Links ]

 

 

* Corresponding author.
# This article is an extended version of a paper presented at the 2011 ISEM conference.