An Architectural Framework for the Improvement of the Ultra-Large-Scale Systems Interoperability

Transcription

1 An Architectural Framework for the Improvement of the Ultra-Large-Scale Systems Interoperability S. Shervin Ostadzadeh 1 and Fereidoon Shams 2 1 Computer Engineering Dept., Science and Research Branch, Islamic Azad University, Tehran, Iran 2 Computer Engineering Dept., Shahid Beheshti University, Tehran, Iran Abstract - With a trend towards becoming more and more information based, enterprises constantly attempt to go beyond the accomplishments of each other by improving their information activities. This attempt depends on increasingly complex systems that will exceed the size of current systems and systems of systems by every measure. These systems are called Ultra-Large-Scale (ULS) systems. The sheer scale of ULS systems will change everything, necessitating that we broaden our understanding of software architectures and the ways we structure them. In this paper, we clarify the lack of an architectural framework for the ULS interoperability and suggest some early considerations towards proposing an architectural framework to improve the interoperability of ULS systems. Keywords: Ultra-Large-Scale Systems, Interoperability, Architectural Framework, Software Architecture, Software Engineering 1 Introduction Software Engineering faces a lot of challenges nowadays, however, fundamental gaps in our current understanding of software and software development at the scale of Ultra-Large-Scale [27] Software-Intensive systems (ULSSIS) remains one important challenge that present serious obstacles in the technically and economically effective achievement of the Software Engineering goals. This is due to the fact that proper development of ULSSIS would have substantial impact on software engineering activities. As systems grow larger and more complex, which eventually become ULSSIS, unprecedented demands on software architecture will emerge. The software architecture of a program or computing system is the structure or structures of the system, which comprises software elements, the externally visible properties of those elements, and the relationships among them [2]. In other words, software architecture characterizes the structure of a system. In general, architecture is 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 [17]. According to ISO [16], an architecture represents a description of the basic arrangement and connectivity of parts of a system (either a physical or a conceptual object or entity), which is expected to create a comprehensive overview of the entire system when put together [8]. It should be noted that handling this large amount of information is quite challenging and needs a well-developed framework. This challenge will be intensified in ULS systems due to their large scale. Nowadays, various Information Systems Architecture (ISA) frameworks have been proposed; among them are Zachman Framework [28, 35], FEAF 1 [9], TEAF 2 [10], TOGAF 3 [23], E2AF 4 [26] and C4ISR [6]. Unfortunately, they do not provide all the required support for ULSSIS. The inability of current ISA frameworks to meet the demands of these systems, calls for breakthrough research in an ultra-large-scale architectural framework [27]. This paper presents an initial work on applying an architectural framework in ULS systems interoperability, which we believe has the potential to lead to the required breakthroughs. The rest of the paper is organized as follows. In Section 2, we introduce some basic concepts and principles. Next, we present an interoperability model overview in section 3. We discuss our proposed approach in section 4. Finally, we make conclusions and provide some comments for the future work. 2 Basic concepts and definitions In this section we briefly introduce some basic concepts and principles. We assume these remarks are necessary for the readers to clearly understand what we mean by the concepts used in this paper. 1 Federal Enterprise Architecture Framework 2 Treasury Enterprise Architecture Framework 3 The Open Group Architecture Framework 4 Extended Enterprise Architecture Framework

2 2.1 Ultra-Large-Scale systems In 2006, SEI [27] published a report about some systems which were called as Ultra-Large-Scale systems. These systems will go far beyond the size of current systems and system of systems by every measure, such as, the number of the lines of code; the number of people employing the system for different purposes; amount of data stored, accessed, manipulated, and refined; the number of connections and interdependencies among software components; and the number of hardware elements. There are some characteristics of ULS systems that will be revealed because of their scale [14, 27]: (1) decentralization; (2) inherently conflicting, unknowable, and diverse requirements; (3) continuous evolution and deployment; (4) heterogeneous, inconsistent, and changing elements; (5) erosion of the people/system boundary; (6) normal failures; (7) new paradigms for acquisition and policy. These characteristics undermine current, widely used, information systems framework and establish the basis for the technical challenges associated with ULS systems. 2.2 Interoperability The definitions on interoperability have been reviewed in [30, 31]. Broadly speaking, interoperability has the meaning of coexistence, autonomy and federated environment, whereas integration refers more to the concepts of coordination, coherence and uniformization [8]. Regarding the degree of coupling, when the components are totally dependent on each other and inseparable, the system is called tightly coupled or fully integrated. On the contrary, the components in a loosely coupled system (such as ULS systems) are connected via a communication network that makes the interactions possible. The components in these systems can exchange data/services while preserving locally their own logic of operations. This is called interoperability. Another point of view is given by ISO [32]. Two systems are considered as integrated if there is a detailed standard format for all constituent components. Interoperability is more related to the unified approach where there is a common meta-level structure across constituent models, providing a means for establishing semantic equivalence or the federated approach where models must dynamically accommodate rather than having a predetermined meta-model [8]. 2.3 Enterprise architecture According to ISO [16], an enterprise is one or more organizations sharing a definite mission, goals and objectives to offer an output such as a product or a service. An enterprise consists of people, information, and technologies; performs business functions; has a defined organizational structure that is commonly distributed in multiple locations; responds to internal and external events; has a purpose for its activities; provides specific services and products to its customers [25]. According to ISO [16], an architecture is a description of the basic arrangement and connectivity of parts of a system (either a physical or a conceptual object or entity). Enterprise Architecture (EA) is a comprehensive view of an enterprise. EA shows the primary components of an enterprise and depicts how these components interact with or relate to each other. EA typically encompasses an overview of the entire information system in an enterprise; including the software, hardware, and information architectures. In this sense, EA is a meta-architecture. As regards, EA contains different views of an enterprise, including, work, function, process, and information, it is at the highest level in the architecture pyramid. According to the IFAC IFIP Task Force [33] and ISO [16] there are two types of architectures that deal with enterprise integration: (1) System architecture (sometimes referred to as Type 1 architecture) that deals with the design of a system; (2) Enterprise-reference architecture (sometimes referred to as Type 2 architecture) that deals with the organization of the development and the implementation of a project such as an enterprise integration or other enterprise development program. In other words, Type 1 architecture describes a system or sub-system regarding its structure and behavior. However, Type 2 architecture implies a framework that organizes necessary concepts and activities/tasks to design and build a system [8]. Zachman Framework falls into the Type 2 architecture. 2.4 Zachman framework In 1987, an IBM researcher, named John A. Zachman, proposed a framework for Information System Architecture [35], which is now called Zachman Framework (ZF) [28]. A framework is a classification schema that defines a set of categories into which various things can be arranged. An enterprise architecture framework is a way of organizing and classifying the types of information that must be created and used for the enterprise architecture. Zachman states that "The Framework for Enterprise Architecture is a two dimensional classification scheme for descriptive representations of an Enterprise" [37]. ZF is a two dimensional information matrix consisting of 6 rows and 6 columns. Figure 1 depicts Zachman Framework.

3 Zachman Framework Data Function Network People Time Motivation Planner Owner Designer Builder Contractor Functioning Enterprise Figure 1: The Zachman Framework The rows describe the perspectives of various stakeholders. These rows starting from the top include: Planner (Scope); Owner (Enterprise Model); Designer (System Model); Builder (Technology Model); Contractor (Detail Representation); and Functioning Enterprise. The columns describe various abstractions that define each perspective. These abstractions are based on six questions that one usually asks when s/he wants to understand a thing. The columns include: Data (What is it made of?); Function (How does it work?); Network (Where are the elements?); People (Who does what work?); Time (When do things happen?); and Motivation (Why do things happen?). To find complete cell definitions of ZF refer to [36]. 3 Interoperability models Since the beginning of the last decade, most recent work on architecture development is focused on careful planning and improving an enterprise interoperability framework. Conventionally, such a framework is primarily concerned with establishing a mechanism to describe the concepts, the problem and the knowledge on enterprise interoperability in a more structured manner. This section will survey some recent interoperability models. Figure 2: LISI Reference Model [6] must cover all four enabling attributes of interoperability known as PAID, namely, Procedures, Applications, Infrastructure, and Data. The LISI approach is focused on developing interoperability in US military sector. It is also used as a basis to elaborate other interoperability maturity models such as Organizational Maturity Model [34] and Enterprise Interoperability Maturity Model in ATHENA Integrated Project [1]. 3.2 IDEAS interoperability model The IDEAS Interoperability Framework (fig. 3) was developed by IDEAS project on the basis of ECMA/NIST Toaster Model, ISO 19101, ISO and was augmented through the quality attributes and intended to reflect the view that "interoperability is achieved on multiple levels: inter-enterprise coordination, business process integration, semantic application integration, syntactical application integration and physical integration" [15]. 3.1 LISI reference model The LISI [6] (Levels of Information Systems Interoperability) approach developed by C4ISR Architecture Working Group (AWG) during 1997, is a framework to provide the US Department of Defense (DoD) with a maturity model and a process for determining joint interoperability needs, assessing the ability of the information systems to meet those needs, and selecting pragmatic solutions and a transition path for achieving higher states of capability and interoperability. Figure 2 depicts the LISI Reference Model. A critical element of interoperability assurance is a clear prescription of the common suite of requisite capabilities that must be inherent to all information systems that desire to interoperate at a selected level of sophistication [8]. Each level s prescription of capabilities Figure 3: IDEAS Interoperability Framework [15].

4 In the business layer, all issues related to the organization and the management of an enterprise are addressed. The business model is the description of the commercial relationships between an enterprise and the way it offers products or services to the market. The knowledge layer is concerned with acquiring, structuring and representing the collective/personal knowledge of an enterprise. The ICT system layer is concerned with the ICT solutions that allow an enterprise to operate, make decisions and exchange information within and outside its boundaries. The semantic dimension cuts across the business, knowledge and ICT layers. Quality attributes are a supplementary dimension of the framework. The considered attributes are: (1) Security; (2) Scalability; (3) Portability; (4) Performance; (5) Availability and (6) Evolution. 3.3 ATHENA interoperability framework The ATHENA Interoperability Framework (AIF) [1] is structured into three levels: (1) The Conceptual level is used for identification of research requirements and integrates research results; (2) The Applicative level is used for the transfer of knowledge regarding application of integration technologies; and (3) The Technical level is used for technology testing based on profiles and integrates prototypes. Figure 4 depicts the AIF. The ATHENA Interoperability Framework and the IDEAS Interoperability Framework are considered complementary [8]. At each level of AIF, one can use the IDEAS interoperability framework to structure interoperability issues into three layers (business, knowledge and ICT) and a semantic dimension. 3.4 Other relevant interoperability models In the UK, the e-government Unit7 (egu), has based its technical guidance on the e-government Interoperability Framework (e-gif) [11]. e-gif mandates sets of specifications and policies for any cross-agency collaboration and for e-government service delivery. Figure 4: ATHENA Interoperability Framework The European Interoperability Framework [12, 13] aims at supporting the European Union s strategy of providing user-centered e-government services by defining as the overarching set of policies, standards and guidelines, which describe the way in which organizations have agreed, or should agree, to do business with each other. The E-health interoperability framework [21] developed by NEHTA (National E-Health Transition Authority) initiatives in Australia, brings together organizational, information and technical aspects relating to the delivery of interoperability across health organizations. The NATO C3 Interoperability Environment (NIE) [19] encompasses the standards, the products and the agreements adopted by the Alliance to ensure C3 interoperability. It serves as the basis for the development and evolution of C3 Systems. Clark and Jones [34] proposed the Organizational Interoperability Maturity Model (OIM), which extends the LISI model into the more abstract layers of command and control support. Five levels of organizational maturity, describing the ability to interoperate, are defined. These include: (1) Independent; (2) Ad-hoc; (3) Collaborative; (4) Combined; and (5) Unified. Layers of Coalition Interoperability (LCI) [29] is a framework to deal with possible measures of merit to be used to deal with the various layers of semantic interoperability in coalition operations. The models previously discussed address a range of interoperability issues from technical to coalition organizational. SEI has developed the System of Systems Interoperability (SOSI) [18], which addresses technical interoperability (also covered by LISI, LCI, and NATO C3) and operational interoperability (also covered by OIM and LCI). However, SOSI goes a step further to address programmatic concerns between organizations building and maintaining interoperable systems. SOSI introduces three types of interoperability: (1) Programmatic, interoperability between different program offices. (2) Constructive, interoperability between the organizations that are responsible for the construction (and maintenance) of a system. (3) Operational, interoperability between the systems. 4 ULS interoperability framework It is clear now that current approaches for defining, developing, deploying, operating, acquiring, and evolving ULS systems, as described in SEI report [27], will not suffice. We can consider ULS systems as cities or socio-

5 technical ecosystems, while our current knowledge and practices are geared toward creating individual buildings or species. This leads us to define a research discipline that is needed for new solutions. In this section, we investigate the use of an architectural framework in order to improve ULS interoperability framework. 4.1 The problem The scale of complexity and uncertainty in ULS system Design will be so great to resist treatments by traditional interoperability methods. According to SEI report [27], this is a new perspective: architecture is not purely a technical plan for producing a single system or closely related family of systems, but a structuring of the design spaces that a complex design process at an industrial scale will explore over time. Note that although breaking up an architecture into design spaces and striving for a set of coherent and effective design rules would seem to imply a significant degree of control of the overall design and production process, the design spaces, design rules, and the organizations will be continually adjusting and adapting to both internal and external forces. The criticality of the research is justified by the fact that handling the large volume of information available in ULS systems is only feasible by utilizing a well-developed interoperability framework. A potential framework should broaden the traditional interoperability framework to include people and organizations; social, cognitive, and economic considerations; and design structures such as design rules and government policies. The research should center on the development of an architectural framework to improve ultra-large-scale systems interoperability. We pose this question: "Given the issues regarding the design of all levels of ultra-largescale architectures, how can we organize and classify the types of information that must be created and used in order to improve ULS interoperability?" sometimes also live within the city, in a ULS system, sometimes a person will act in the role of a traditional user, sometimes in a supporting role as a maintainer of the system health, and sometimes as a change agent adding and repairing the functions of the system. Assuming people to be part of the ULS system means that a new perspective has to be taken into account: Culture. Figure 5 depicts an extension to SOSI model to achieve ULS system socio-technical characteristics. 4.3 The proposed framework Figure 6 depicts our proposed framework to improve ULS interoperability. As depicted, the framework applies Zachman Framework perspectives and abstractions in conjunction with the ULS interoperability model. Zachman Framework is often referenced as a standard approach for expressing the basic elements of information system architecture, and is widely accepted as the main framework in ISA. In our work, we apply Zachman Framework as an initial start, and try to revise it by adding the required support for the special characteristics of the ultra-large-scale interoperability model. The proposed framework should be a spectrum of technologies and methods with software engineering, economics, human factors, cognitive psychology, sociology, systems engineering, and business policy. The proposed framework uses three basic dimensions: (1) The abstract dimension is based on six general questions required to understand interoperability; (2) The perspective dimension is based on interoperability concerns in an enterprise; and (3) The final dimension is based on interoperability barriers in a socio-technical system of systems. Current research shows that the problem stated in the previous paragraph is inherently broader and deeper than some of current successful ISA frameworks (such as Zachman Framework) [3, 4, 7, 20, 22]. 4.2 Socio: the new concern The SOSI can be consider as a significant initiative for ULS systems, however, as mentioned in SEI report [27], people will not just be users of a ULS system, rather, they will be part of its overall behavior. In addition, the boundary between the system and user/developer roles will blur. Just as people who maintain and modify a city, Figure 5: ULS Interoperability Model

6 The interoperability abstracts define the contents of interoperations: Data (What?): The interoperability of data handles information finding and sharing from heterogeneous data sources. These data sources possibly exist within different machines running different operating and data management systems. Function (How?): The interoperability of function takes care of identifying, composing and making various application functions work together. Network (Where?): The study of interconnecting the internal networks of companies is essential in a networked enterprise. This facilitates the creation of a common network for the whole enterprise. This type of interoperability focuses on the geometry or connectivity of the system's physical nodes. People (Who?): It focuses on the people and the manuals and the operating instructions or models they use to interoperate their tasks/duties. Conceptual: It focuses on the artifacts that conceptually define the interoperability from the enterprise owners' perspective. Logical: It describes the artifacts that design the way interoperability will be realized systematically, quite independently of any technologies. Physical: It focuses on the artifacts that define the interoperability implementation based on the general technological constraints being employed. Out-of-Context: It describes the artifacts that specify the implementations for specific technological products being used for the interoperability. The interoperability barriers address a range of interoperability issues from operational to cultural. In order to achieve Ultra-Large-Scale interoperation among systems, a set of cultural, management, constructive, and operational activities have to be implemented in a consistent manner. These activities require adding new and upgraded systems to a growing interoperability web: Time (When?): It is concerned with the life cycles, the timing and the schedules that are used to interoperate activities. Motivation (Why?): It focuses on goals, plans and rules that prescribe policies and ends which guide the enterprise interoperability. Operational issues define the activities within the executing system and between the executing system and its environment, including the interoperation with other systems. Constructive issues define the activities that develop or evolve system interoperability. The interoperability perspectives define various concerns of interoperation: Programmatic issues define the activities that manage the acquisition of system interoperability. Contextual: It describes the artifacts that provide the boundaries for the interoperability. Cultural issues define the activities that sustain the ULS system socio-technical characteristics. Figure 6: An ULS Interoperability Framework.

7 [3] S. Blanchette, et al. "U.S. Army Workshop on Exploring Enterprise, System of Systems, System, and Software Architectures". SEI, Carnegie Mellon University, USA, [4] P. J. Boxer, and S. Garcia. "Enterprise Architecture for Complex System-of-Systems Contexts"; 3rd Annual IEEE International Systems Conference, Vancouver, Canada, [5] Architecture Working Group (AWG). "C4ISR Architecture Framework, Version 2.0". USA Department of Defense (DoD), Figure 7: Data/Logical/Constructive Cell Together, the abstract, perspective and barrier dimensions constitute the ULS interoperability framework. The two dimensional matrix (abstract perspective) defines the contents of interoperations that take place in various levels of system perspectives. The third dimension enables to capture and to structure the type of interoperation. For example, Data/Logical/Constructive (fig. 7) represents the data that can be used for constructive interoperations in logical (system's designer) perspective. 5 Conclusions In this paper, an architectural framework to improve ULS interoperability was proposed. The framework allows software architects to model various aspects of Ultra- Large-Scale systems interoperability. The proposed framework presents a classification schema for descriptive representation of a ULS system. The goal is that the framework be used to complement a full-structural model within the Ultra-Large-Scale interoperability. In particular, this approach will enable architects to: (1) design all levels of ULS architectures; (2) represent and analyze ULS interoperability; and (3) determine and manage ULS requirements. In the future work, one is expected to propose a methodology to help architectures model the framework cells. 6 References [1] ATHENA. "Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications". FP IST1, [2] L. Bass, P. Clements, and R. Kazman. "Software Architecture in Practice". SEI Series in Software Architecture, Addison-Wesley Professional, [6] Architecture Working Group (AWG). "Levels of Information Systems Interoperability (LISI)". USA Department of Defense (DoD), [7] P. Clements. "Exploring Enterprise, System of Systems, and System and Software Architectures". SEI Webinar, Carnegie Mellon University, USA, [8] D. Chen, et al. "Architectures for enterprise integration and interoperability: Past, present and future"; Comput Industry (Ind), [9] Chief Information Officers (CIO) Council. "Federal Enterprise Architecture Framework, Version 1.1" [10] Department of the Treasury. "Treasury Enterprise Architecture Framework, Version 1" [11] egovernment Unit. "egovernment Interoperability Framework (egif), version 6.1" [12] EIF. "European Interoperability Framework". Brussels, [13] EIF. "European Interoperability Framework for PAN- European egovernment Services, Version 4.2" [14] G. Goth. "Ultra-Large System: Redefining Software Engineering"; IEEE Software Journal, Vol. 25, Issue 3, 91 94, [15] IDEAS. "IDEAS: Interoperability Development for Enterprise Application and Software Roadmaps" [16] ISO "Industrial Automation Systems Requirements for Enterprise-reference Architectures and Methodologies" [17] IEEE Standards board. "Recommended Practice for Architectural Description of Software-Intensive Systems". IEEE-Std

8 [18] E. Morris, et al. "System of Systems Interoperability". SEI, Carnegie Mellon University, USA, [19] NC3A. "NATO C3 Technical Architecture Reference Model for Interoperability". NATO Consultation, Command, and Control Agency, [20] NECSI. "Characteristics of Systems of Systems". NECSI: Complex Physical, Biological and Social Systems Project, [21] NEHTA. "Towards an Interoperability Framework, Version 1.8" [22] ODUSD. "Systems and Software Engineering: Systems Engineering Guide for Systems of Systems, Version 1.0". USA, [23] Open Group. "The Open Group Architecture Framework (TOGAF), Version 9.0". USA, [24] S. S. Ostadzadeh, et al. "A Method for Consistent Modeling of Zachman Framework"; Advances and Innovations in Systems, Computing Sciences and Software Engineering, Springer, , International Journal of Computer Integrated Manufacturing, , [32] ISO "Industrial Automation Systems Concepts and Rules for Enterprise Models". ISO TC184/SC5/WG1, [33] IFAC IFIP Task Force. "GERAM: Generalized Enterprise Reference Architecture and Methodology, Version 1.6.3". IFAC IFIP Task Force on Architecture for Enterprise Integration, [34] T. Clark, and R. Jones. "Organizational Interoperability Maturity Model for C2". Department of Defense, Canberra, Australia, [35] J. A. Zachman. "A Framework for Information Systems Architecture"; IBM Systems Journal, Vol. 26, No. 3, , [36] J. A. Zachman. "The Framework for Enterprise Architecture Cell Definitions". ZIFA, [37] J. A. Zachman. "The Zachman Framework: A Primer for Enterprise Engineering and Manufacturing" [25] S. S. Ostadzadeh, et al. "An MDA-Based Generic Framework to Address Various Aspects of Enterprise Architecture"; Advances in Computer and Information Sciences and Engineering, Springer, , [26] J. Schekkerman. "Extended Enterprise Architecture Framework Essentials Guide, Version 1.5". Institute For Enterprise Architecture Developments (IFEAD), [27] SEI. "Ultra-Large-Scale Systems: Software Challenge of the Future". Carnegie Mellon University, USA, [28] J. F. Sowa, and J. A. Zachman. "Extending and Formalizing the Framework for Information Systems Architecture"; IBM Systems Journal, Vol. 31, No. 3, , [29] A. Tolk. "Beyond Technical Interoperability: Introducing a Reference Model for Measures of Merit for Coalition Interoperability"; Proc. 8 th ICCRTS, USA, [30] D. Chen, and F. Vernadat. "Enterprise interoperability: a standardisation view"; Kluwer Academic Publishers, , [31] D. Chen, and F. Vernadat. "Standards on enterprise integration and engineering a state of the art";