CC BY
100
CD CD
O >
" ENTERPRISE ARCHITECTURE AS AN
APPROACH TO THE DEVELOPMENT OF INFORMATION SYSTEMS
Milosav N. Majstorovica, Rajko M. Terzicb
° a College of Information Technology, Belgrade, Republic of Serbia, of e-mail: [email protected], w ORCID iD: fl http://orcid.org/0000-0003-0787-7625
^ b Institute of Public Health, Belgrade, Republic of Serbia, O e-mail: [email protected], ^ ORCID iD: http://orcid.org/0000-0003-0772-8291
0 http://dx.doi.org/10.5937/vojtehg66-15850 z
1 FIELD: Computer Sciences, Informatics, Information Systems uj ARTICLE TYPE: Review Paper ^ ARTICLE LANGUAGE: English
Abstract:
The link between business and information technology (IT) has been a constant topic in both academic and industrial circles for more than 30 years. Alignment (compliance) between business and IT is generally seen as an important component and a basis for optimizing the performance of AS any organization. Due to constant changes in the IT world as well as in o modern business, the work on the alignment of business and IT is gaining
2 in importance. The cause of the alignment problem lies primarily in different levels of business abstraction and IT concepts. In order to solve
>o
x this problem, for a long time, the current approach to the development of
i- information systems (IS) is based on the so-called enterprise architecture
° (EA). In this paper, a review of literature dealing with EA is given. The
o focus of the literature review was the identification of works dealing with
> motivational aspects for the use of EA as well as those that deal more
closely with the process of development of EA using general and domain specific frameworks. The aim was also to give an insight into the current picture of academic research in this field and the use of EA in order to solve the problems of business and IT alignment. This overview can be a starting point for participants in EA development using existing frameworks as well as for developing specific frameworks that would be applied in specific domains.
Key words: business and IT alignment, information systems, enterprise architecture, enterprise architecture frameworks, TOGAF.
Introduction
For more than two decades, the need for aligning IT possibilities with business needs has been considered as one of the key issues in IT
oo
CO
CO
management (Majstorovic, 2016). In order to solve this problem, an § approach to IS development based on EA has been used for a long time o (Gregor et al, 2007). In (Krstajic et al, 2014), the EA-based approach is used as a direction for business and IT alignment in the domain of insurance industry.
Architecture is needed to manage the complexity of any large organization or system (Lankhorst, 2013). However, the notion of 'architecture' in many areas is not unambiguous. Most often, the architecture of a system implies its structure and functions. In (IEEE Computer Society, 2000, p. 14), the following definition is provided: "Architecture is a fundamental organization of the system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution." In this paper, the e organization means a collection of organizational units that have a pole common set of goals and represent a specific organizational system. EA & is defined in the literature differently. Thus, in (Lankhorst, 2013, p.3) EA 73 is defined as: "a coherent whole of principles, methods and models used in designing organizational structure, business processes and infrastructure." §
Cp CO
O
In (Kappelman & Zachman, 2013), EA is defined as a set of concepts and practices based on a holistic view of the system, principles and common languages, and long-standing disciplines of engineering and architecture. The work places EA as an architecture of the entire organization, including its IT. It also describes the ontology required for the holistic definition and presentation of architecture, and highlights the significant challenges facing IT professionals and researchers. Finally, 2 EA is said to be one of the critical tools for organizational success, and will play an increasingly important role in increasing demands for speed, agility, synergy, efficiency, quality and complexity.
So, EA describes and model elements of the organization, and shows how they are organized and connected, and how they function as a whole. EA itself is not an artifact, but produces artifacts (eg. models) ^ that illustrate the existing and future (desired) state of the organization 2 (Seppanen, 2008). Although EA has been a very important field of research for a long time (Zachman, 1987), (Lankhorst, 2013), (ObjectWatch, 2007), (Kappelman & Zachman, 2013), there is still no full consensus on EA terminology, concepts, approaches and outcomes, ie. results of development of EA. In any case, although EA was primarily related to the architecture and development of information systems (IS), today it is an approach for a comprehensive modeling of enterprise architecture, in which standard IS components are provided, as well as
CD CD
"o >
03
o CM
of
UJ
a.
Z) O
o <
o
X
o
LU
H ^
a. <
H
<
CD >o
X LU H O
O >
organizational and software models architectures through which an IS is implemented.
Below, attention is first paid to the development of EA. Since EA development is more efficient with the use of the framework, the paper gives a concise overview of literature that deals with frameworks that provide wider functionality as well as with those developed for specific fields, i.e. specific application domains. A special chapter is dedicated to the TOGAF Framework, the most widely used, industrial framework for EA and its key element - Architecture Development Method (ADM), which specifies the process for the development of EA (The Open Group, 2011). At the end of the paper, a conclusion is made indicating the basic contributions of this paper and the possible directions for further research.
Development of EA
Development of EA is a continuous process that involves the development, implementation, application and propagation of results. This process should be aligned with the internal development of the organization, as well as with its environment. This includes both the strategic and operational activities of the organization. Although architecture involves relatively stable parts of business and technology, it must be adapted to change; therefore, architecture products (artifacts) have a temporary status. Namely, architecture changes due to changes in the environment and new technical possibilities that affect the essential goals of the business system and the way in which these goals are achieved. Good architecture must clearly show the relation between the architectural decisions and business goals of the organization (Lankhorst, 2013). In the EA development, it is necessary to make a more or less abstract representation of the organization's positional and future state, as well as a road map that will enable the transformation from the current situation to a future one. The development and transformation process of EA is illustrated in Figure 1 (Majstorovic et al, 2016a).
The EA of a future situation is based on the mission, vision, strategy and business goals of the organization. So, business is the driver and gives guidance for the development of EA. Creating a road map for translating an existing state into a future (desired) state involves a multitude of projects thet alter the existing EA, i.e. make its transformation. In this way, projects represent the implementation of changes in the organization, i.e. destination EA.
Figure 1 - EA development and transformation process Puc. 1 - Процесс развития и трансформации EA Слика 1 - Развоj и процес трансформаци]е EA
The most important feature of EA is that it represents a comprehensive view of the organization. Thus, it includes different domains in the organization, and should represent the optimal solution in the context of the entire organization, i.e. both its parts and the whole. In order to achieve the desired quality of EA, an approach is needed which will enable the necessary understanding and communication of all involved participants from different domains. Unlike, for example, architecture in construction, which has a thousand years of history, and in which common language and culture has been developed and established, such a general framework in business and IT is still missing (Lankhorst, 2013). In current practice, there are various descriptions, specification languages, i.e. various models, techniques and tools for EA development. The next part of the paper will focus more on EA frameworks which provide a mechanism, i.e. give guidelines, models, methods, techniques for the most successful development of EA.
EA Frameworks
Creating an enterprise architecture is more effective with the use of a framework that helps define areas to be covered by architecture and categorize artifacts for delivery, thus providing an organized and logical approach for EA creators. The EA frameworks contain a set of models, principles, and methods used to implement EA. They establish a link between EA artifacts and provide a common vocabulary for all stakeholders in the context of EA.
The established role and importance of the EA development framework have contributed to the development of multiple frameworks in the context of general and specific approaches. Below is a review of
CD CD
"o >
03
o CM
of
UJ
a.
Z) O O
_l <
o
X
o
UJ
H ^
a. <
H
<
CD >o
X UJ
H O
O >
some papers dealing with EA approaches, a brief overview of the most important frameworks and methods for developing EA.
Most of today's frameworks were created as the upgrading of the Zahman framework (Zachman, 1987). This framework represents a simple logical structure for the classification and organization of descriptive views of the organization, which are significant for the management and development of the system within the organization. This framework is focused on the structure of the view of the organization rather than on providing a process or methodology for creating an architecture. The organization is represented with a matrix of six columns and rows. The columns have the following attributes (different aspects of understanding the organization): what, how, where, who, when and why. The matrix rows represent the roles in the design process, and in a broader sense provide the taxonomy of the company and represent different observation views: the planner, the owner, the designer, the contractor, the programmer and the user. In this way, the Zahman framework enables: a good classification of the views of all interested participants in the organization, filling the cells of the array with artifacts, horizontally (between different perspectives) and vertically (from concepts to technical implementation) linking matrix cells, checking the completeness of descriptive views of complex business systems. The benefits of the Zahman framework are (Lankhorst, 2013): easy understandability; a comprehensive view of the organization; it is defined independently of tools or methodologies; any concept, or problem, can be mapped to a suitable place in the matrix. The most commonly encountered problems of applying the Zahman framework are (Lankhorst, 2013), (Fatolahi & Shams, 2006): a lack of methodologies that cover all aspects of the framework; the lack of robust rules for linking cell frames; the lack of popular notations for modeling all column frames; a large number of cells, which is an obstacle for practical application. Despite these shortcomings, the Zahman framework is still very much used, and Zahman's work has brought challenges and vision of the organization's architecture for the next twenty years. The challenges involved, above all, management of complexity in distributed systems.
The Zahman framework for EA had a major impact on the first attempt of the US Defense Department to create an EA. This effort is known as the Technical Framework for Information Management (TAFIM, 1994). The TAFIM EA promised that technical projects would be better offset (adjusted) to business needs.
The TAFIM was then submitted to The Open Group and thus converted into a standard known as The Open Group Architecture
Framework (TOGAF) (The Open Group, 2011). Although originally conceived as a general framework and methodology for the development o of technical architecture, TOGAF evaluated the framework and method " for the development of the organization's architecture, and the most widely used framework for EA in industry (Cameron & McMillan, 2013). e TOGAF standard models for EA contain four main domains: business, applications, data and technology. The TOGAF framework is based on certain key concepts and methodologies for the development of architecture (ADM). ADM can be viewed as a process or tool for creating e an EA. TOGAF ADM is cyclic and it contains 8 phases, which include defining, planning, implementing, managing the current basic architecture, and developing a migration plan in a future destination architecture. Along with ADM, the TOGAF standard contains a general e dictionary, appropriate products and recommended standards for assistance in implementing EA.
In April 1999, the CIO (Chief Information Officers), a council formed by the chief executives responsible for IT in state institutions, launched a project called The Federal Enterprise Architecture Framework (FEAF) (Urbaczewski, Mrdalj, 2006). New ideas in this project were related to <§ segmentation of architectures in large enterprises, and one of the main reasons for the implementation of FEAF was to achieve seamless integration of different architectures that existed in several federal agencies. This should have given citizens and clients a better, faster and cheaper access to information (Cameron & McMillan, 2013). In 2002, FEAF was renamed to FEA - Federal Enterprise Architecture. In 2005, FEA was the dominant EA approach in the public sector. 2
The GARTNER organization, with its dominant approach to the private sector, looked at EA as a continuous process involving the assessment of the current state of architecture, defining goals for building the future situation, and managing the entire portfolio throughout the process (Gartner, 2005). According to GARTNER, EA is more a strategy than an engineering discipline used to build a consolidated view of the organization, which aligns the business needs of the organization. 2
The previously presented EA approaches are very different. The answer to the question "Which approach is best for a specific company?" is not unambiguous. In (ObjectWatch, 2007), a comparison of these approaches was made using 12 criteria, giving a score of 1 to 4 (4 is the best estimate). According to this comparison, none of the compared EA approaches is complete; each of them has its advantages and disadvantages and they are complementary to one another.
ro
o
CD CD
"o >
03
o CM
of
UJ
a.
Z) O O
_l <
o
X
o
UJ
H ^
a. <
H
<
CD >o
X LU H O
O >
However, it has been shown that the previously presented EA approaches are not sufficient to cover the domain companies providing Information and Communications Technology services. Thus, the New Generation Operation System and Software (NGOSS) program appeared in the field of telecommunications. The NGOSS program is developed by Telemanagement Forum (TMF), an international telecommunications association, and it represents EA for the telecommunications domain (http://www.tmforum.org/browse.aspx).
NGOSS represents a reference architecture for the telecommunications industry. It contains a set of frames that represent a generic classification scheme for design, as well as a display of a complex domain such as a telecom domain. The Business Process Framework - Enhanced Telecom Operations Map (eTOM) defines all major business processes inside and outside the company (TM Forum. The Business Process Framework). The company's information framework - known as SID (Shared Information and Data Model) -provides a comprehensive general information model for completing telecom activities in the company (TM Forum. The Information Framework). The application framework, known as the TAM (Telecom Application Map), is designed to be used by all participants in the software chain of Telekom. The eTOM provides a framework for telecom processes and the TAM framework for telecom applications (TM Forum. The Application Framework).
Telemanagement Forum has changed the NGOSS name for the industry standard to the name of Frameworx. All developments regarding the further development of this industry standard for telecommunications, can be monitored by the members of the TMF Association via the website (http://www.tmforum.org/browse.aspx).
In 2006, ACORD (Association for Cooperative Operations Research and Development), formed by insurance organizations from around the world, defined the strategy of developing the business architecture of insurance companies. The main result of this activity is the ACORD Framework - a framework that provides the architectural basis for insurance companies, to quickly and easily prepare and implement the changes necessary for successful business in a dynamic market (Gregory, 2005).
The ACORD framework provides insurance companies with a robust, detailed, consolidated and complete set of models that support business process innovation, transformation and efficiency improvements. Five basic components - models are (Jones et al, 2010): (1) A common vocabulary of all terms that exist and are used in the
ecosystem of insurance - Business Dictionary. The main purpose of this §
01
o oo
!± Ci
vocabulary is to improve communication by standardizing the name of the term in the business and unambiguous mutual communication of working teams; (2) Model of basic functionalities in the business of insurance companies - Business Capability Model. This model provides e multi-level decomposition of business areas up to the level of business processes. Functions are located at higher levels of hierarchical decomposition and include all the standard functions that exist in insurance companies; (3) Information model which is the reference e model for realization of business applications of the insurance company -Information Model. It is a detailed model that represents a conceptual overview of the insurance industry. It is based on UML (Unified Modeling
ro
Language) and covers all functional areas of the company and provides e communication of other XML (extensible Markup Language), EDI -g (Electronic Data Interchange) and XBRL (extensible Business Reporting & Language) standards with ACORD standards; (4) A data model 73 specifically designed to meet the needs of the business data architecture of the insurance company - Data Model, represents the logical level of the entity-realatioship model. It serves primarily as a basis for the <§ physical model of the relational database and data warehouse model (Data Warehouse); (5) A comprehensive model of components that form business processes with a detailed definition of interfaces and services across the value chain in insurance companies - Component Model.
o
(Cvetkovic et al, 2013) offered an approach to solving the problems of business and IT alignment in complex companies, with a special 2 emphasis on the application in the domain of insurance industry, based on EA using TOGAF, TMF and ACORD frameworks. The specification of the future state of the insurance company (IC) is provided through TOGAF architectural layers. The IC business process map is used by lu using the structure of the TMF framework for business processes - eTOM and the basic functionality framework for the ACORD framework for the ^ insurance domain. (Cvetkovic et al, 2016) presented a methodological 2 framework for the construction of an EA insurance company, which is obtained by combining TOGAF, ACORD, and TMF accesses. The application of this methodological framework enabled a comprehensive business specification IC, which was the basis for specifying IT concepts in the domain concerned. Below is a more detailed TOGAF framework, as one of the most widely used general frameworks for the development of EA (ITpreneurs, 2013).
CD CD
"o >
03
o CM
of
UJ
a.
Z) O O
_l <
o
X
o
UJ
H ^
a. <
H
<
CD >o
X LU H O
O >
TOGAF - The Open Group Architectural Framework
TOGAF is an open, industrial framework for the architecture of an organization (The Open Group, 2011). It was originally conceived as a general framework and methodology for the development of technical architecture, but it was evaluated in the framework and method for the development of an enterprise architecture. The framework is described through a set of documents on the Open Group public web server (The Open Group, nd), and can be freely used in organizations that want the development of EA.
The TOGAF framework supports four architectural domains that represent EA components:
- Business architecture defines business strategy, management and key business processes.
- Data architecture describes the structure of logical and physical data sets and data management resources.
- Application architecture provides a sketch of individual applications, their layout, interaction, and their relationship with the organization's central business processes.
- The technology architecture describes the software and hardware functionalities that are necessary to support the development and deployment of business, data and application services. It includes: ICT (information communication technology) infrastructure, computer networks, communications, technological standards, etc.
Figure 2 shows the architectural domains of EA.
TOGAF is based on the next mission and strategy (State of Utah, 2007):
- Mission: Creating a system that will allow the free flow of information (Holmes, 2002), (Solomon & Blevins, 2003).
- Strategy: Firstly, working with users in order to capture, understand and deal with current and emerging requirements, establish policy, and exchange best practices. Second, work with suppliers, consortia and standardization bodies in order to develop consensus and facilitate interoperability.
Figure 2 - Architectural domain of EA Puc. 2 - Архитектурный домен EA Слика 2 - Архитектурални домени EA
TOGAF contains three main sections (Minoli, 2008):
- TOGAF method for the development of EA (TOGAF Architecture Development Method - ADM), which defines how to implement EA for a specific organization, which will reflect specific business needs.
- Enterprise Continuum, a repository of all architectural artifacts (models, templates, architectural descriptions, etc.) that exist both in a specific organization and in wider IT industry, and at the disposal of the development of architectures. At the appropriate places around TOGAF ADM, there are reminders of which architectural resources should be used.
- TOGAF Resource Base, which is a set of resources (guidelines, templates, additional information, etc.) that helps architects in the use of ADM.
oo со со
о oo со ci
Ci
E
<u
(Л (Л
ro E
<u E
Ci
<u >
cu
T3
о ro о
Ci !i го
го ф
о ф
о
го ф
<л Ci CD с
ш
■о >
о о <л
Below is a more detailed overview of the TOGAF method for the development of EA.
CD CD
"5 >
03
o CM
of
UJ
a.
Z) O
o <
o
X
o
UJ
H >-
OH <
H
<
CD >o
X UJ
H O
O >
TOGAF method for the development of EA
The TOGAF Architecture Development Method (ADM) is a cyclical process for the development of architecture. ADM involves the establishment of a framework of architecture, the development of content architecture, the transition and management of the implementation of architectures. All these activities are carried out within the iterative cycle of the continuous definition of architecture and its realization, which enables organizations to transform their enterprises in a controlled manner in order to fulfill business goals and new possibilities (The Open Group, 2011).
Figure 3 shows the architecture development cycle according to the TOGAF ADM method. Below are brief description of ADM phases.
The Preliminary Phase describes the preparation and initiation of architectural creation activities, including the adaptation of TOGAF and the definition of architectural principles.
Phase A: The Architecture Vision describes the initial phase of the architecture development cycle. It includes:
- information on defining the scope of the architecture development initiative,
- identification of stakeholders,
- creating the architecture vision,
- obtaining consent to continue the work on developing EA.
Phase B: Business Architecture describes the development of a business architecture that supports a harmonized vision of architecture. The phase shows how an organization meets its business objectives. The phase includes the following:
- business goals and tasks,
- business functions, services, processes and roles,
- correlation of the organization and functions,
- confirm business context,
- defining current and future architecture,
- execution of gap analysis,
- creating a report on business architecture.
Phase C: Information System Architecture describes the development of an information system architecture that supports a harmonized vision of architecture. The phase shows how IT systems
fulfill the business goals of the organization and display application
systems and data architecture.
01
ó
00
01 !±
Phase D: Technology Architecture describes the development of a technology architecture that supports a harmonized vision of e architecture. This is the systemic basis of the IT system. It includes:
- hardware, software and communication technology,
- links between technologies,
- principles of design, management and evolution of technology.
Phase E: Opportunities and Solutions analyze different implementation capabilities, identify initial implementation projects and supplies for architecture defined in previous phases. The phase includes:
- access decisions (purchase or development, outsource, commercially available software, and open source solutions),
- priority assessment,
- dependence identification.
<u E ü
<D >
<U T3
Phase F: Migration Planning defines a transition from an existing 2 to a destination architecture, through the finalization of a detailed implementation and migration plan. It produces an implementation road map, and other relevant analyzes, such as costs and benefits, and risk assessment for major projects.
ro <u
o <u
Phase G: Implementation Governance provides architectural control over implementation. It defines architectural limitations of % implementation projects, and establishes contracts, or agreements. In cooperation with the project management department, it oversees work on the implementation in order to achieve general consent.
o
LU
Phase H: Architecture Change Management establishes procedures for managing changes in the process of developing a new architecture. The phase ensures that architectural changes are managed o in a cohesive and architecturally consistent manner. It establishes and supports EA in order to provide flexibility, which will enable rapid development, in response to technological changes and the business environment of the organization concerned.
CD CD
О >
О CM
DC LLJ
DC ZD О
о <
с;
Z X О ш
i>-
DC <
(Л <
-J
О >о
X ш н
о
о >
Figure 3 - Cycle of architecture development Puc. 3 - Цикл развития архитектуры Слика 3 - Циклус развода архитектуре
Requirements Management determines the process of managing §
CO
the architecture requirements through ADM. As Figure 3 shows, this ó phase is at the center of the ADM method, which means that ADM is continually driven by the demand management process. The objectives of this phase are: e
Ensure that the process of managing the requirements is sustainable and pervasive through all relevant ADM phases.
Management of architectural requirements identified through the execution of any ADM cycle, or phase. e
Ensuring that relevant architectural requirements are available for each stage during its execution.
The TOGAF ADM process can be adapted for different usage scenarios. In (The Open Group, 2011) are given guidelines for ADM e
process adaptation, as well as techniques for architecture development. °
Conclusion
oo
co p
ro
In order to solve the problem of business and IT alignment, for a long time the current approach to development of the IS has been based on EA (Gregor et al 2007). In the review papers related to EA § (ObjectWatch, 2007), (Urbaczewski, Mrdalj, 2006), (Cameron & McMillan, 2013) the analysis of methodologies and frameworks was not performed in the context of business and IT alignment. Also, frameworks for specific business domains are not specifically considered.
The aim of this paper is to provide an overview of the current picture of academic research in this field and the use of EA in order to solve the problems of business settlement and IT. In accordance with this, the g paper discusses the general framework for the development of EA, as well as the frameworks developed for specific business domains, such as the ICT (TMF framework) and the insurance industry (ACORD framework). The TOGAF framework is particularly presented as one of w the most widely used general frameworks for the development of EA (ITpreneurs, 2013). As shown in (Cvetkovic et al, 2016), a combination of TOGAF frameworks with specific domain frameworks can build a methodological framework for the development of EA specific business areas. The review given in this paper can be a starting point for the participants in the development of EA using existing frameworks, as well as for the development of specific frameworks that would be applied in specific domains.
In the specific application domain, such as service-oriented business, the problem may be the operationalization of a general framework such as TOGAF itself. Also, a large number of domain
o
CD CD
"5 >
03
o CM
of
UJ
a.
Z) O
o <
o
X
o
UJ
H >-
OH <
H
<
CD >o
X UJ
H O
O >
frameworks and standards bring the problem of organizing the development of ISs that are based on them. Bearing this in mind, further work is planned to explore the relationship between business models and EAs in order to alleviate these problems. During this work, it is desirable to formalize business models so that the elements of various EA development frameworks are adequately used. To this end, (Majstorovic et al, 2016b) has developed a service-oriented business (SOB) metamodel that represents a unique conceptualization and contributes to a more precise definition of the SOB concepts.
References
Cameron, H.B., & McMillan, E. 2013. Analyzing the Current Trends in Enterprise Architecture Frameworks. Journal of Enterprise Architecture, 9(1), pp.60-71.
Cvetkovic, R., Krstajic, D., & Majstorovic, M. 2013. Problem poravnanja IT-a i poslovanja kod osiguravajucih kompanija. In: Festival informatickih dostignuca - INFOFEST, 2013-09-29, Budva/Milocer, pp.189-196 (in Serbian).
Cvetkovic, R., Majstorovic, M., & Krstajic, D. 2016. Sveobuhvatnom specifikacijom ka boljem poravnanju IT i poslovanja osiguravajuce kompanije. In: Regionalna naucno strucna konferencija "INFOFEST PULSE", 2016-09-25, Budva, pp.138-145 (in Serbian).
Fatolahi, A., & Shams, F. 2006. An investigation into applying UML to the Zachman framework. Information Systems Frontiers, 8(2), pp.133-143. Available at: http://dx.doi.org/10.1007/s10796-006-7977-8.
-Gartner Inc. 2005. Gartner Enterprise Architecture Process: Evolution 2005.Stamford: Gartner Inc.
Gregor, S., Hart, D., & Martin, N. 2007. Enterprise architectures: Enablers of business strategy and IS/IT alignment in government. Information Technology & People, 20(2), pp.96-120. Available at:
http://dx.doi.org/10.1108/09593840710758031.
Gregory, A.M. 2005. The Business Information Revolution: Making the Case for ACORD Standards. New York: ACORD.
Holmes, P. 2002. An Introduction to Boundaryless Information Flow. [ebook]. San Francisco: Open Group. Available at: http://pubs.opengroup.org/onlinepubs/007679899/toc.pdf. Accessed:
12.10.2015.
-IEEE Computer Society. 2000. 1471-2000 - IEEE Recommended Practice for Architecture description of Software-Intensive Systems. [e-book]. New York: IEEE. Available at: http://dx.doi.org/10.1109/IEEESTD.2000.91944.
-ITpreneurs. 2013. Architecting the Family: TOGAF and Major IT Frameworks. [e-book]. Rotterdam: ITpreneurs. Available at: http://mailing.itpreneurs.com/Newsflash/TOGAF/Whitepaper-Architecture-with-TOGAF.pdf. Accessed: 05.12.2016.
00
01
E
<D
Jones, D.F., Schmitz, D., France, N., & Orlandi, M. 2010. The ACORD §
>>>>>> ' m
Capability Model. [e-book]. ACORD Corporation. Available at: o file:///C:/Users/Intel/Downloads/yHQOSJ9UQUqUWEfU683qgA.pdf. Accessed: 10.11. 2017.
Kappelman, L.A., & Zachman, J.A. 2013. The Enterprise and Its Architecture: Ontology & Challenges. Journal of Computer Information Systems, 53(4), pp.87-95. Available at: £
http://dx.doi.org/10.1080/08874417.2013.11645654.
Krstajic, D., Cvetkovic, R., & Majstorovic, M. 2014. Towards the alignment m of business and IT in insurance company. International Journal of Scientific and E Research Publications, 4(3), pp.1-7. Available at: http://www.ijsrp.org/research-paper-0314.php?rp=P272363.
Lankhorst, M. 2013. Enterprise Architecture at Work, 3rd ed. [e-book]. Berlin - Heidelberg: Springer-Verlag. Available at: http://dx.doi.org/10.1007/978- | 3-642-29651-2.
Majstorovic, M. 2016. Business and IT alignment. Vojnotehnicki glasnik/Military Technical Courier, 64(2), pp.496-512. Available at: http://dx.doi.org/10.5937/vojtehg64-9263.
Majstorovic, M., Regodic, D., & Grubor, G. 2016a. Metamodel of a Service-Oriented Business. In: Sinteza 2016: International Scientific Conference on ICT and E-Business Related Research, 2016-04-22, Belgrade, pp.36-43. Available § at: http://dx.doi.org/10.15308/Sinteza-2016-36-43.
Majstorovic, M., Regodic, D., Majstorovic, G., Krstajic, D., & Cvetkovic, R. 2016b. Sinergija arhitekture organizacije i upravljanja poslovnim procesima. In: YUINFO, 2016-02-28, Kopaonik, pp.58-63 (in Serbian). «
Minoli, D. 2008. Enterprise architecture A to Z: Frameworks, business process modeling, SOA, and infrastructure technology. CRC Press, Taylor & Francis Group. ISBN 9780849385179.
-ObjectWatch Inc. 2007. A Comparison of the Top Four Enterprise- ü Architecture Methodologies. Houston, Texas: Object Watch Inc.
Seppänen, V. Interconnections and differences between EA and SOA in government ICT development. [Internet]. Available at: https://www.researchgate.net/publication/228820389_Interconnections_and_Diff w erences_between_EA_and_SOA_in_Government_ICT_development. Accessed: 05.06.2017. -o
Solomon, E., & Blevins, T.J. 2003. Boundaryless Information Flow o Reference Architecture. [e-book]. San Francisco: The Open Group. Available at: http://www.opengroup.org/cio/ReferenceArc-Final1.pdf. Accessed: 02.10.2015.
-State of Utah. 2007. EA Framework Research and Analysis. Salt Lake City: State of Utah Department of Technology Services.
-The Open Group. 2011. TOGAF® Version 9.1, Document Number: G116. [e-book]. Available at:
https://www.opengroup.org/architecture/togaf91/downloads.htm. Accessed: 05.11.2016.
o
<u
o
CD
0
01
ф -The Open Group. TOGAF® - the Enterprise Architecture standard used by
the world's leading organizations to improve business efficiency. [Internet]. Available at: http://www.opengroup.org/togaf/ Accessed: 15.11.2016. со -TM Forum. The Information Framework (SID). [Internet]. Available at:
ъ https://www.tmforum.org/information-framework-sid/. Accessed: 15.10.2016. > -TM Forum. The Application Framework (TAM). [Internet]. Available at:
https://www.tmforum.org/application-framework/. Accessed: 10.10.2016.
-TM Forum. The Business Process Framework (eTOM). [Internet]. ш Available at: https://www.tmforum.org/business-process-framework/. Accessed: ÔE 02.10.2016.
0 Urbaczewski, L., & Mrdalj, S. 2006. A Comparison of Enterprise ^ Architecture Frameworks. Issues in Information Systems, 7(2), pp.18-23. < -U.S. Department of Defense. 1994. Technical Architecture Framework for
Information Management (TAFIM), 1(8), Version 2.0. Reston, VA: DISA Center CH for Architecture. ш Zachman, J.A. 1987. A Framework for Information Systems
>- Architecture. IBM Systems Journal, 26(3), pp.276-292. Available at: http://dx.doi.org/10.1147/sj.263.0276.
АРХИТЕКТУРА ОРГАНИЗАЦИИ КАК ДОСТУП К РАЗВИТИЮ ИНФОРМАЦИОННЫХ СИСТЕМ
Милосав Н. Майсторовича, Райко М. Терзичб w а Колледж информационных технологий, г. Белград, Республика Сербия,
fj б Городской институт общественного здравоохранения,
1 G г. Белград, Республика Сербия
ОБЛАСТЬ: компьютерные науки, информатика, информационные
X системы
ш ВИД СТАТЬИ: обзорная статья
О
О >
ЯЗЫК СТАТЬИ: английский
O Резюме:
Связь между бизнесом и информационными технологиями (ИТ) на протяжении последних тридцати лет является самой актуальной темой как в академических, так и в промышленных кругах. Выравнивание (согласованность) бизнеса и ИТ является важным компонентом и фундаментом для оптимизации деловых процессов каждой организации. В связи с постоянным развитием как в области ИТ, так и в области организации бизнеса, выравнивание бизнеса и ИТ становится все более востребованной деятельностью. Основная причина проблем выравнивания прежде всего заключается в различных уровнях абстракции бизнеса и ИТ концептов. В целях решения данной проблемы, на протяжении долгого времени разрабатывается новый метод развития информационных систем (ИС), основанный на так называемой архитектуре организации (АО).
Сажетак:
оо со
Е ф
го
В данной статье представлен обзор научной литературы, § посвященной вопросам АО. В данном обзоре литературы о большое внимание посвящено работам, представляющим мотивационные аспекты применения АО, а также работам, представляющим процессы развития АО при применении обобщенных и специальных рамок доменов, а также использования АО в целях решения проблемы выравнивания ^ бизнеса и ИТ. Данный обзор может служить отправной точкой в развитии АО при применении существующих рамок, а также в развитии специальных рамок, которые можно было бы применять в специальных доменах.
Ключевые слова: выравнивание бизнеса и ИТ, информационные системы, архитектура организации, рамки развития АО, ф ТОвЛЕ. ¡|
АРХИТЕКТУРА ОРГАНИЗАЦШЕ КАО ПРИСТУП ЗА РАЗВОJ 1 ИНФОРМАЦИОНИХ СИСТЕМА -ё
Милосав Н. Ма]сторови^а, Раjко М. Терзи^6 а Висока школа струковних студи]а за информационе технологи]е,
Београд, Република Ср6и]а о
6 Градски завод за ]авно здравее, Београд, Република Ср6и]а §
ОБЛАСТ: рачунарске науке, информатика, информациони системи го
ВРСТА ЧЛАНКА: прегледни чланак иЕЗИК ЧЛАНКА: енглески
го ф
Веза измену пословаша и информационе технологие (ИТ) више од 30 година стална }е тема, како у академским, тако и у о индустри}ским круговима. Поравнаше (усаглашеност) пословаша и ИТ-а генерално се види као важна компонента и основа за оптимизаци}у пословних перформанси било ко}е организаци]е. С обзиром на сталне промене, како у ИТ свету, тако и у савременом пословашу, рад на поравнашу пословаша и ИТ све више доби}а на знача}у. Узрок проблема поравнаша }е, пре свега, у различитим нивоима апстракци]а пословаша и ИТ концепата. Ради решаваша овог проблема веЬ дуже време }е актуелан приступ разво}у информационих система (ИС), заснован на тзв. архитектури организаци}е (АО). У раду }е презентован преглед литературе ко}а се бави АО, а фокус }е на идентификации радова ко]и се баве мотивационим аспектима за коришЯеше АО, као и онима ко}и детал>ни]е обращу процес разво]а АО уз коришЯеше општих и доменски специфичних оквира. При томе, цил>}е да се прикажу тренутна академска истраживаша из ове области и коришЯеша АО ради решаваша проблема поравнаша пословаша и ИТ. Ова] преглед може бити стартна тачка учесницима у разво}у АО, уз
го ф
<л ф
'
С
Ш
ф коришЯеке посто}еЬих оквира, као и за pa3eoj посебних оквира щи
би се примеривали у специфичним доменима.
со Къучне речи: поравнаъе пословаъа и ИТ, информациони
ю системи, архитектура организаци}е, оквири за развоj АО,
о >
о см
(Л <
-J
О ■О
X ш I-
О
О >
TOGAF.
Paper received on / Дата получения работы / Датум приема чланка: 28.11.2017. Manuscript corrections submitted on / Дата получения исправленной версии работы /
^ Датум достав^а^а исправки рукописа: 15.12.2017. ^ Paper accepted for publishing on / Дата окончательного согласования работы / Датум з коначног прихвата^а чланка за об]ав^ива^е: 17.12.2017.
и © 2018 The Authors. Published by Vojnotehnicki glasnik / Military Technical Courier ^ (www.vtg.mod.gov.rs, втг.мо.упр.срб). This article is an open access article distributed under the О terms and conditions of the Creative Commons Attribution license (http://creativecommons.org/licenses/by/3.0/rs/).
yj © 2018 Авторы. Опубликовано в «Военно-технический вестник / Vojnotehnicki glasnik / Military Technical Courier» (www.vtg.mod.gov.rs, втг.мо.упр.срб). Данная статья в открытом доступе и >- распространяется в соответствии с лицензией «Creative Commons» <; (http://creativecommons.org/licenses/by/3.0/rs/).
© 2018 Аутори. Обjавио Воjнотехнички гласник / Vojnotehnicki glasnik / Military Technical Courier (www.vtg.mod.gov.rs, втг.мо.упр.срб). Ово jе чланак отвореног приступа и дистрибуира се у складу са Creative Commons licencom (http://creativecommons.org/licenses/by/3.0/rs/).
lg) 0
