CC BY-NC-ND
38
Architectural Solution as a tool for planning and approval of changes in projects for information systems implementation and customization
Igor V. Ilyin
Professor, Director of Graduate School of Business Technologies Peter the Great St. Petersburg Polytechnic University
Address: 29, Polytechnicheskaya Street, St. Petersburg, 195251, Russian Federation E-mail: [email protected]
Anastasiia A. Grigoreva
Doctoral Student, Graduate School of Business Technologies Peter the Great St. Petersburg Polytechnic University
Address: 29, Polytechnicheskaya Street, St. Petersburg, 195251, Russian Federation E-mail: [email protected]
Igor M. Zapivakhin
Consultant on Integration, SOLMIX Consulting LLC; Master Student, Graduate School of Business Technologies Peter the Great St. Petersburg Polytechnic University
Address: 29, Polytechnicheskaya Street, St. Petersburg, 195251, Russian Federation E-mail: [email protected]
Abstract
The agile project management approach has been considered to be one of the most popular approaches for developing IT solutions. Use of this approach allows us to change the requirements at any stage of the IT project, and one of the twelve principles of Agile Manifesto, - "Simplicity", - promotes the use of a minimum amount of project documentation. One of the disadvantages limiting the implementation in such resource-intensive projects as Information Systems Projects (ISP) is the risk of exceeding budgets and time limits. Therefore it is highly important to develop such a tool that will contribute in discussion and approval process with the customer before changes are started so as to minimize the possibilities of changes at further stages of the project.
This article investigates the possibility of applying holistic methods of the Enterprise Architecture (EA) in order to support solutions design during an Information System Project, in particular, in the form of documentation at the stage before implementation planning. The main aim of our research is to develop a tool that will help the customer to understand the planned changes and will contribute in that their influence on the already existing EA is taken into account. This article first reviews standards of IT project management in the context of recommendations for "conceptual project" outcomes. Next, the results of interviews conducted with IT consultants are presented. The proposed Architectural Solution (AS) is a document that completes the stage of design and coordinating IT changes. It is based on the application of methods and models from the field of EA. We believe this solution may be a sufficient document for coordinating projects that are conducted under agile philosophy.
Key words: Architectural Solution, IT project management, agile development methods, conceptual project, IT solution, information system, Enterprise Architecture, modelling language.
Citation: Ilyin I.V., Grigoreva A.A., Zapivakhin I.M. (2017) Architectural Solution as a tool for planning and approval of changes in projects for information systems implementation and customization. Business Informatics, no. 2 (40), pp. 68-78. DOI: 10.17323/1998-0663.2017.2.68.78.
Introduction
Effective IT project management is one of the key factors that influences the quality of ending IT solutions [1]. In current practice, various life cycle models of information system (IS) development are used and combined. Also, a tendency has been observed towards the application of agile development methods in software productions. One feature of agile development methods is the lack of any requirement to consecutively complete the stages of project execution, with interim outcomes recorded in the form of project documentation [2]. Rejection of interim project documentation is not fully justified by the risk of increased expenditures on project management, which is relevant for the contractor, as the customer is able to modify customer requirements even in late stages of development [3]. At the same time, excessive documentation also negatively affects project expenditures.
In the competitive environment of consulting firms, when each strives to satisfy customers' requirements to the greatest extent and adapt to the current situation, project management is viewed by contractors as a sequence of "black boxes", the contents of which are opened during transition to the next phase of the project. According to the Capability Maturity Model Integration (CMMI) model, companies like this hold a position no higher than the third maturity level [4].
In the same time, the quality of project management processes is negatively influenced by the absence of the project execution team's understanding of the general decomposed scheme of the customer company business processes and their integration. For example, a specialist responsible for the automation and support of one company process may not understand how a "subordinate" process is related to and influences other linked business processes. In further IS use, disregard for these peculiarities can lead to uncontrolled changes in linked processes that were considered autonomous in the project's execution phase. In our opinion, the abovementioned problems may be prevented in the stage of planning, design and approval of project changes.
The aim of this study is to develop a tool that would allow consulting companies to get customer approval for planned IT changes within IS project before theier real implementation, taking into account and coordinating both parties' comprehension of the aggregated diagram of the business processes.
This article is structured as follows.
The first part provides a brief review of IT project management standards containing recommendations
and drafts of IT project documentation. This is followed by the outcome of interviews with representatives of consulting companies involved in SAP ERP/CRM/ BI-based solutions development. In the second part, the concept of an Architectural Solution (AS) is introduced and recommendations for its documentation are put forward. In the third part, a test of the proposed solution is applied in the form of case study from retail company practice. The article concludes with research findings and lays the path for future research.
1. Research methods
This study employed a qualitative method of data collection, summarization and analysis. Qualitative research methods, unlike quantitative methods, are aimed at a profound understanding of the situation in the context of myriad interrelationships among events and phenomena. Qualitative methods (analyses of scientific papers and literature content, interviews for a detailed understanding of the situation, observation of behavior, etc.) are recommended in the work [5] as the most appropriate approach to the development of new methods in the information system area.
1.1. Literature review
In analysis of literature in the field of IT project management, we have also included Enterprise Architecture Management (EAM) research literature, as Enterprise Architecture (EA) projects are considered by researchers to be a kind of IS projects upon condition that ending solutions provide system support to several organization's functional areas [6].
We have identified a line of research dedicated to the analysis of factors that influence communications during IT projects execution [7—12] within the design team and with key involved stakeholders, while the project's Enterprise Architect role [8, 9], that is, the representative of the contracted company, is considered to be responsible for the maintenance of effective communications between business stakeholders and IT team.
As a tool for the support of the effective communications between IT and business stakeholders, the authors [9, 10] have examined Enterprise Architecture models. In work [12] they comply with three primary objectives: documentation, analysis and planning enterprise aggregate design. It is noted in [13] that the design and state-of-the-art maintenance of models require significant effort and expense, therefore the production of models of the required level of detailing must serve the
purpose of the analysis [14] and meet the informational needs of the stakeholders but not to the purpose of just being.
Among the works of Russian researchers, it is important to note a work [15] that introduces the concept of an EAM solution. The documented EAM solution contains three parts: the methodological block, the technological block and the support and maintenance block. Such an idea serves the goals of documentation necessary for the execution and submission of architectural product documentation, including the description of the customer's organizational processes and the integration of the solution with diverse company processes, as well as the transfer of recommendations on the support and maintenance of the implemented solution.
The documentation requirements in the context of an agile approach to software product development were considered in the works [16, 17], which recognize the necessity of the creation of solution designs in documentary form. The factors critical for the success of IT projects managed under agile principles are analyzed in the works [18, 19].
To sum up, as a result of the literature review, it is established that one of the factors that influences the success of IT projects (particularly projects managed with an agile approach) is communications during project activity between IT specialists (the project contractor) and stakeholders of various functional areas of the customer company. The maintenance of effective communications and execution of IT projects facilitates the creation of presentation materials and documents. So far, we have revealed a shortage of research focused on the development of design documentation in the planning and design solution approval phase. In our opinion, this subject is given unjustifiably little attention, as competent approval of planned changes in EA before their implementation phase decreases the likelihood of the introduction of later project changes, thus influencing IS project total cost.
1.2. Evaluation of the current situation in the area of IT solution documentation
This part of the article is dedicated to a review of solution design documentation practices and standards, which are used in IS-configured projects.
ADM TOGAF. The Open Group consortium develops a set of independent standards in the EA area [20]. One of them is the Architecture Development Method;
its cycle is depicted in Figure 1. The primary document of the architectural project (A-F ADM phases) is the Architecture Definition Document (ADD). This document describes various artifacts and perspectives of EA as building blocks for the creation of a holistic conception of architecture organization. The sections contained in the document include the project scope, goals and objectives, architectural principles, current and target architectures in business, application, data and technological segments, a gap analysis, as well as transition architecture creation and management.
' \ Architecture
Preliminary ) proiect
A. \ \
Architecture p--^---^
vision J g ^
— I Business
'k V architecture 1 '
Fig. 1. EA development method and TOGAF Architectural Project [20]
RUP (Rational Unified Process) [21] supports an iterative software development approach that subdivides the software creation process into four main milestones: Inception, Elaboration, Construction, and Transition. Discussion and implemented solution choice is held in the Elaboration phase. A combination of eight documents, which conclude this phase, are established in the approach.
The GOST R ISO/IEC 12207-2010 standard [22] regulates the life cycle process of the software development and thus is the process standard. As indicated in the document, "the standard does not establish documentation
requirements in terms of its naming, format, specific content and recording media. These decisions are to be made by users of the standard" [22]. Annex C (Cyrillic: B) of the GOST R ISO/IEC 15271-02 standard bears the title "Classification of process output outcomes" and determines the process output outcomes that should be documented according to the requirements or recommendations of GOST R ISO/IEC 12207. The development stage allows for the creation of 37 documents (plans, protocols, descriptions, procedures, etc.).
To conclude, the analysis of existing standards and approaches to IT project management presented earlier as well discussed in works [23—26], revealed their redundancy and inflexibility in the creation of documentation of every project phase. The choice of what and what not to document is at the discretion of the business customer and IT solutions contractor. Not one document proposed in the considered IT related standards can be used as wholly sufficient in IT project management because they mostly were developed with the aim of complementing one another. The design of total EA according to ADD TOGAF is an excessively resource-draining process and is incompatible with agile philosophy.
1.3. Outcomes of interviews with consulting IT firms
Following the analysis of information from theoretical sources, we held interviews with representatives of Russian IT companies (KORUS, NOVARDIS, SOLMIX) on the subject of difficulties faced by IT teams during IS project execution. Interviews were held with consultants and market leaders about SAP ERP/CRM/ BI based solutions. Interviews were conducted with leaders and managers who are in charge of communications with high-level stakeholders as well as field consultants responsible for more technical issues: system requirements gathering, their processing and transfer for further development. In total, 12 people participated in the interviews.
In terms of particularly significant threats for IT projects, respondents cited the probability that projects may exceed budgets and timelines (11 out of 12). Specialists also described problems in getting approval for design changes caused by the customer's incomprehension of planned changes (7 out of 12), the problem of identifying and considering all interrelated processes during the development of local solutions, as well as problems with workflow, as large public enterprises are demanding of the workflow that frequently are based on government standards or internal strict methods. A total
rejection of creating design documentation during the implementation of ERP-based solutions seems highly unrealistic to specialists (12 out of 12).
The interviews established the need for the creation of a tool that in its documentary will be capable of recording planned system changes and will be comprehensible to the customer, by taking into account the influence of ongoing changes in linked business processes.
2. Architectural Solution
In the first part of the article, it was revealed that, on the one hand, multiple different approaches to IT project management exist in practice, as well as a range of supportive documents, each of which cannot be used in agile project management as a single document fully describing changes in IS. On the other hand, IT consultants have revealed difficulties in getting customers approval for changes at the design solution phase due to customers' frequent incomprehension of ongoing changes and lack of consideration of all processes addressed by the new solution.
2.1. Architectural Solution conception
In this part of the article, we introduce a new definition of the Architectural Solution (AS).
The Architectural Solution of an enterprise is an architectural domain model chosen and approved by all participating company business processes owners, which ensures maximum business competitiveness in a context of company resource limitations.
An architectural model is a holistic enterprise systems description characterized by a synergic effect achieved through its business and IT elements [27].
The Architectural Solution is aimed at resolving a specific business issue, taking user and organization management needs into consideration, and is unique to each organization. A documented AS confirmed with customer concludes the design, planning and change approval stage in IS implementation / customization projects. The AS approval is not so much about receiving the necessary signatures, than achieving the customer's comprehension of ongoing EA changes and their consequences.
AS is a much narrower concept than Enterprise Architecture (EA). Indeed, the EA target state is reached due to the implementation of a set of specific ASs, and they constitute the value of EA as a management tool for governing organizational changes.
In order to meet AS understandability requirements for business stakeholders who are not IT specialists, it is recommended to use visualization tools according to EA management practice, as well as explanations in natural language. Corporate architectural solutions, unlike software architecture models (systems), cannot be written exclusively in formal modeling and programming languages, as they are aimed at performing immediate business objectives and should be comprehensible to internal end-users and business stakeholders. Diagrams and descriptions should not be too complex, formal or otherwise inaccessible.
It is important to note a difference from the concept of "Solution Architecture", which is target system architecture: architecture that implies a technical description of solution structure.
2.2. Documented AS
Generally, all fundamental project changes during IS implementation / customization are approved by the customer through the signing of corresponding documentation. The main task of the documentation is to describe and fix planned changes approved by the customer.
The AS document may be structured in the following manner:
♦ the introductory part, process goals and objectives;
♦ the list of process requirements, i.e. business, functional and user requirements (the list of requirements may vary depending on project goals);
♦ the process model, input and output data: a visualized part of the processes, such as an activity diagram;
♦ the supporting systems model: set of systems, supporting the business processes, as well as infrastructure and information for IT specialists;
♦ a description of how an executed process affects linked business processes on an informational level;
♦ information received from the customer about planned tactical transformations in business activity and the considered domain.
After the execution and implementation of IS changes, it is recommended to add information about what was done more or less incorrectly to the "AS" document, why this happened and how to manage this mistake from now on.
This document structure is an expanded version of a conceptual project from IT company practice (sections formerly not included in this document are indicated
in cursive). The additions are based on the Enterprise Architecture best practices and frameworks. As it was previously mentioned, EA management functions include modelling and documentation of EA state and IS systems to support organization's evaluation and transformation, decision-making process, means of facilitating cooperation between the design team and the customer. Modelling in different views makes description comprehensible to a wide range of specialists [9, 12].
As it was previously mentioned, EA management functions include modelling and documentation of EA state and IS systems to support organization's evaluation and transformation, decision-making process, means of facilitating cooperation between the design team and the customer.
In conclusion we can infer that better comprehension of ongoing changes from the customer's point of view may be achieved by implementing approaches from Enterprise Architecture management in IS implementation / customization project communications. This will facilitate the communication of all relevant information on affected business processes and, in the long run, will lower the likelihood of changes introduced at later phases of the project. It is largely argued, that changes in later stages in IS project frequently occur because the influence of a certain business process to related processes was not taken into account during development.
3. Case study in retail: Online purchase on credit
The example presented in this section describes a retail case study about a new business process integration in the existing informational infrastructure project and the possibilities to use AS in the stage of the planning of changes in the customer system.
The primary activity of Household Appliances Company Ltd. is online sales of domestic appliances to retail customers. The company took the decision to offer customers the option of making orders on the online store and purchasing on credit. Formerly, purchases on credit were only available at distribution centers. By offering new services, the company intended to boost sales. Additionally, credit insitutions and banks (external stakeholders) participated in the process's execution, are motivated by the interest earned from credit sales.
Household Appliances Company Ltd. chose a contractor for the changes from among external IT companies with the main objective of integrating the new
process with the existing IS. After performing an on-site examination and gathering the new domain requirements, the IT specialists produced a document that should confirm the ongoing changes.
The "Solution Design" document structure was:
1) an introduction with a description of project goals and objectives, as well as expected outcomes;
2) a description of requirements, both high-level organization's principles and requirements and middle-level requirements related to the most important functions, systems, and reports;
3) a description of business processes (business part);
4) a description for IT specialists (functional system requirements).
Let's highlight the main points and analyze features. A large part of solution design is essentially a collection of requirements and expected outcome of a project. The expected outcomes of the project are determined based on information received from the customer and are found in "achievement of project goals". Project goals include an increase in the number of customers buying goods on credit and the expected outcome from implementation, measured by key performance indicators.
The AS concept proposed earlier contains a section that takes connections with related business processes into account. In the given example, after an analysis
of Home Appliances Company Ltd., IT specialists revealed that the implemented online credit business process significantly overlaps the retail sales process in the online store. Considering that the description of the old process already exists and is used by the company when doing business, it does not have to be included in the AS model. Figure 2 depicts the AS business layer, which describes only the missing elements of the new online credit business process. The graphic model was executed in an Archi environment. The existing retail sales process in the online store is highlighted by the dark background.
In order to execute the new process and implement it in existing IS design, it is necessary to re-design the company IS, adding a new functionality and after that to integrate it with an external credit broker system. On Figure 3, existing systems and their functionality are highlighted by dark background, while light grey background designates new IS elements, the developed functionality and services executed with the help of the new functionality.
Figure 4presents the hardware and software of the customer company, which will remain almost untouched by the implemented process. Changes highlighted by dark background refer to database expansion through the addition of tables containing customer data. Also the integration with an external broker system is added via the SOAP API method for messaging exchange.
„ Œ Customer
/ ^ ^ / Selling and lending i
Delivery A service J
Confirmation O of the terms of the ■ contract
Bank
Sending O money to Jhe bank „
Delivery
hi
Product is delivered
Point u of delivery of goods
Fig. 2. Business description of the "Online purchase on credit" Architectural Solution
Fig. 3. Informational description of the "Online purchase on credit" Architectural Solution
Conclusion
In this article, we have introduced the authors' definition of an Architectural Solution as an architectural model of a set domain approved by participating business processes owners and aimed at the solution of specific business objectives. Then, we presented the AS documentary form as a tool for approval of ongoing changes in Enterprise Architecture design with an emphasis on the high- and middle-level data visualization and the provision of information on related and affected business processes. The "AS" tool complements existing design documentation practice in the area of IS configuration through EAM approaches. Testing and ap-
plication of the proposed solution was conducted in the implementation of a new process of "online credit" in the existing IS design. The AS model was presented in three sections: business, information, and technological levels. The proposed solution may be used by consulting firms adhering to agile principles during project management in the areas of IS implementation / customization, and as a document in the IT solution design approval stage, minimizing the likelihood of changes in later stages of the project.
In terms of limitations, it should be noted that the design, planning and approval stage involves discussion and a choice among several alternatives; however, this
Fig. 4. Hardware and software description of the "Online purchase on credit" Architectural Solution
article does not cover the issue of several solutions parallel discussions and, consequently, the modelling of several AS. This issue should be addressed in the context of the situation, depending on the customer EA maturity [28] and the specific project requirements. Additionally, this article does not cover the issue of how to identify related processes that will be affected during AS implementation in the existing IS, which may become the subject of further study.
Acknowledgements
We would like to express our gratitude to the European Union for support of the Joint Programs and Framework for Doctoral Education in Software Engineering, "Pathways to PhD" (PWs@PhD) (http://fase.it.lut. fi/), as well as all universities participating in the project from Finland, Germany, the UK, Denmark, Russia and Jordan, for the opportunity to discuss the results of this study. ■
References
1. Munns A.K., Bjeirmi B.F. (1996) The role of project management in achieving project success. International Journal of Project Management, vol. 14, no. 2. pp. 81-87.
2. Fowler M., Highsmith J. (2001) The Agile manifesto. Software Development, vol. 9, no. 8, pp. 28-35.
3. Kumar G., Bhatia P.K. (2012) Impact of Agile methodology on software development process. International Journal of Computer Technology and Electronics Engineering, vol. 2, no. 4, pp. 46-50.
4. Team C.P. (2006) CMMI for Development. Version 1.2.
5. Baskerville R., Myers M.D. (2004) Special issue on action research in information systems: Making IS research relevant to practice: Foreword. MIS Quarterly, vol. 28, no. 3. pp. 329-335.
6. Pulkkinen M. (2008) Enterprise Architecture as a collaboration tool. PhD thesis. Jyvaskyla, Finland: University of Jyvaskyla.
7. van der Raadt B., Schouten S., van Vliet H. (2008) Stakeholder perception of enterprise architecture. Proceedings of Second European Conference on Software Architecture (ECSA 2008). Paphos, Cyprus, 29 September — 01 October 2008. Springer Berlin Heidelberg, pp. 19-34.
8. Smolander K., Paivarinta T. (2002) Describing and communicating software architecture in practice: Observations on stakeholders and rationale. Proceedings of the Fourteenth International Conference on Advanced Information Systems Engineering (CAiSE '02). Toronto, Canada, 27—31 May 2002. Springer Berlin Heidelberg, pp. 117-133.
9. Hirvonen A., Oyj T., Pulkkinen M. (2003) Evaluation of enterprise IT architecture solutions: How can an ICT consultant tell what is best for you? Proceedings of 10th European Conference on IT Evaluation. Madrid, 25—26 September 2003. P. 327-337.
10. Sebastian R. (2011) Changing roles of the clients, architects and contractors through BIM. Engineering, Construction and Architectural Management, vol. 18, no. 2, pp. 176-187.
11. Nakakawa A., Bommel P., Proper H.A. (2010) Challenges of involving stakeholders when creating enterprise architecture. Proceedings of 5th SIKS/BENAIS Conference on Enterprise Information Systems. Eindhoven, The Netherlands, 16November 2010, pp. 43-55.
12. Aier S., Gleichauf B. (2015) Application of enterprise models for engineering enterprise transformation. Enterprise Modelling and Information Systems Architectures, vol. 5, no. 1, pp. 58-75.
13. Aier S., Kurpjuweit S., Riege C., Saat J. (2008) Stakeholderorientierte dokumentation und analyse der unternehmensarchitektur. INFORMATIK 2008: Beherrschbare Systeme — dank Informatik, München, 8—13 September 2008, pp. 559-565.
14. Johnson P., Johansson E., Sommestad T., Ullberg J. (2007) A tool for Enterprise Architecture analysis. Proceedings of the 11th IEEE International Enterprise Distributed Object Computing Conference (EDOC 2007), Annapolis, Maryland, USA, 15—19 October 2007, pp. 142-142.
15. Koznov D.V., Arzumanyan M.Yu., Orlov Yu.V., Derevyanko M.A., Romanovsky K.Yu., Sidorina A.A. (2015) Specifics of projects in the area of Enterprise Architecture development. Business Informatics, no. 4 (34), pp. 15-23.
16. Mazni O., Sharifah-Lailee S.A., Azman Y. (2010). Agile documents: Toward successful creation of effective documentation. Proceedings of the 11th International Conference on Agile Software Development (XP 2010), Trondheim, Norway, 1—4 June 2010, pp. 196-201.
17. RÜping A. (2005). Agile documentation: A pattern guide to producing lightweight documents for software projects. John Wiley & Sons.
18. Chow T., Cao D.B. (2008) A survey study of critical success factors in agile software projects. Journal of Systems and Software, vol. 81, no. 6, pp. 961-971.
19. Power D.J., Sohal A.S., Rahman S.U. (2001) Critical success factors in agile supply chain management. An empirical study. International Journal of Physical Distribution and Logistics Management, vol. 31, no. 4, pp. 247-265.
20. The Open Group (2017) The Open Group Architecture Framework (TOGAF). Version 9 "Enterprise Edition". Available at: http:// www.opengroup.org/togaf/ (accessed 13 January 2004).
21. West D. (2002) Planning a project with the Rational Unified Process. Rational Whitepaper.
22. GOST R ISO/IEC 12207-2010 (2010) Informatsionnaya tekhnologiya. Sistemnaya iprogrammnaya inzheneriya. Protsessy zhiznennogo tsikla programmnykh sredstv [System and software engineering. Software life cycle processes]. Moscow: Standardinform (in Russian).
23. Bentley C. (2010). Prince2: A practical handbook. Routledge.
24. Wideman R.M. (2002) Comparing PRINCE2® with PMBoK®. Vancouver, Canada: AEW Services.
25. GOST 34.601-90 (1990) AS. Stadiisozdaniya [Automated systems. Stages of development.]. Moscow: Standardinform (in Russian).
26. Bourque P., Fairley R.E. (2014) Guide to the software engineering body of knowledge (SWEBOK (R)). Version 3.0. IEEE Computer Society Press.
27. Lankhorst M.M. (2004) Enterprise Architecture modelling - the issue of integration. Advanced Engineering Informatics, vol. 18, no. 4, pp. 205-216.
28. Ilyin I.V., Levina A.I. (2015) Upravlenie zrelost'yu biznes arkhitektury predpriyatiya [Business architecture maturity management]. St. Petersburg State Polytechnical University Journal. Economics, no. 2 (216), pp. 109-117 (in Russian).
Архитектурное Решение как инструмент планирования и согласования изменений в проектах внедрения и кастомизации информационных систем
И.В. Ильин
доктор экономических наук, профессор, директор Высшей школы технологий управления бизнесом, Санкт-Петербургский политехнический университет Петра Великого Адрес: 195251, г. Санкт-Петербург, ул. Политехническая, д. 29 E-mail: [email protected]
А.А. Григорьева
аспирант Высшей школы технологий управления бизнесом, Санкт-Петербургский политехнический университет Петра Великого Адрес: 195251, г. Санкт-Петербург, ул. Политехническая, д. 29 E-mail: [email protected]
И.М. Запивахин
консультант по интеграции ООО «СОЛМИКСКонсалтинг»; студент магистратуры Высшей школы технологий управления бизнесом, Санкт-Петербургский политехнический университет Петра Великого Адрес: 195251, г. Санкт-Петербург, ул. Политехническая, д. 29 E-mail: [email protected]
Аннотация
В настоящее время среди специалистов сферы ИТ выявлены предпочтения к использованию на практике семейства гибких (agile) методологий управления проектами. Использование данных методологий подразумевает возможность внесения изменений в требования к ИТ-решению на любом этапе, а один из принципов Agile Manifestó, — «Простота», — декларирует использование минимума проектной документации. Недостаток данного подхода при ведении таких ресурсозатратных проектов, как проекты в области настройки информационных систем (ИС) заключается в рисках исполнителя не соблюсти временные и бюджетные рамки проекта. Возникает необходимость в создании инструмента, который будет согласовать планы на разработку до ее непосредственной реализации таким образом, чтобы свести к минимуму вероятность внесения изменений на более поздних этапах проекта.
В статье представлены результаты исследования возможности применения холистических методов визуализации из области управления архитектурой предприятия (АП) (Enterprise Architecture Management, EAM) к сопровождению проектных работ по внедрению и кастомизации ИС, в частности, к составлению документации на стадии планирования и согласования ИТ-решений. Цель работы — разработать инструмент, который будет способствовать пониманию заказчиком планируемых изменений, и обеспечит учет их влияния на уже существующую АП. В данной статье анализируются стандарты к управлению ИТ-проектами в части рекомендаций по составлению проектной документации этапа «концептуальный проект», а также приводятся результаты опросов ИТ-консультантов. Предложено Архитектурное Решение (АР) — документ, завершающий стадию планирования и согласования ИТ-изменений, который базируется на использовании методов и моделей из области АП. Данное решение при agile-философии ведения ИТ-проектов может являться достаточным документом этапа согласования планов на проект.
Ключевые слова: Архитектурное Решение, управление ИТ-проектами, гибкие методологии разработки, концептуальный проект, ИТ-решение, информационная система, архитектура предприятия, язык моделирования.
Цитирование: Ilyin I.V., Grigoreva A.A., Zapivakhin I.M. Architectural Solution as a tool for planning and approval of changes in projects for information systems implementation and customization // Business Informatics. 2017. No. 2 (40). P. 68-78. DOI: 10.17323/1998-0663.2017.2.68.78.
БИЗНЕС-ИНФОРМАТИКА № 2(40) - 2017
Литература
1. Munns A.K., Bjeirmi B.F. The role of project management in achieving project success // International Journal of Project Management. 1996. Vol. 14. No. 2. P. 81-87.
2. Fowler M., Highsmith J. The Agile manifesto // Software Development. 2001. Vol. 9. No. 8. P. 28-35.
3. Kumar G., Bhatia P.K. Impact of Agile methodology on software development process // International Journal of Computer Technology and Electronics Engineering. 2012. Vol. 2. No. 4. P. 46-50.
4. Team C.P. CMMI for Development. Version 1.2. 2006.
5. Baskerville R., Myers M.D. Special issue on action research in information systems: Making IS research relevant to practice: Foreword // MIS Quarterly. 2004. Vol. 28. No. 3. P. 329-335.
6. Pulkkinen M. Enterprise Architecture as a collaboration tool. PhD thesis. Jyvaskyla, Finland: University of Jyvaskyla, 2008.
7. van der Raadt B., Schouten S., van Vliet H. Stakeholder perception of enterprise architecture // Second European Conference on Software Architecture (ECSA 2008). Paphos, Cyprus, 29 September - 01 October 2008. Springer Berlin Heidelberg, 2008. P. 19-34.
8. Smolander K., Paivarinta T. Describing and communicating software architecture in practice: Observations on stakeholders and rationale // The Fourteenth International Conference on Advanced Information Systems Engineering (CAiSE '02). Toronto, Canada, 27-31 May 2002. Springer Berlin Heidelberg, 2002. P. 117-133.
9. Hirvonen A., Oyj T., Pulkkinen M. Evaluation of enterprise IT architecture solutions: How can an ICT consultant tell what is best for you? // 10th European Conference on IT Evaluation. Madrid, 25-26 September 2003. P. 327-337.
10. Sebastian R. Changing roles of the clients, architects and contractors through BIM // Engineering, Construction and Architectural Management. 2011. Vol. 18. No. 2. P. 176-187.
11. Nakakawa A., Bommel P., Proper H.A. Challenges of involving stakeholders when creating enterprise architecture // 5th SIKS/BENAIS Conference on Enterprise Information Systems. Eindhoven, The Netherlands, 16 November 2010. P. 43-55.
12. Aier S., Gleichauf B. Application of enterprise models for engineering enterprise transformation // Enterprise Modelling and Information Systems Architectures. 2015. Vol. 5. No. 1. P. 58-75.
13. Aier S., Kurpjuweit S., Riege C., Saat J. Stakeholderorientierte dokumentation und analyse der unternehmensarchitektur // INFORMATIK 2008: Beherrschbare Systeme - dank Informatik. München, 8-13 September 2008. P. 559-565.
14. Johnson P., Johansson E., Sommestad T., Ullberg J. A tool for Enterprise Architecture analysis // 11th IEEE International Enterprise Distributed Object Computing Conference (EDOC 2007). Annapolis, Maryland, USA. 15-19 October 2007. P. 142-142.
15. Specifics of projects in the area of Enterprise Architecture development / D.V. Koznov et [al.] // Business Informatics. 2015. No. 4 (34). P. 15-23.
16. Mazni O., Sharifah-Lailee S.A., Azman Y. Agile documents: Toward successful creation of effective documentation // 11th International Conference on Agile Software Development (XP 2010). Trondheim, Norway. 1-4 June 2010. P. 196-201.
17. Rüping A. Agile documentation: A pattern guide to producing lightweight documents for software projects. John Wiley & Sons, 2005.
18. Chow T., Cao D.B. A survey study of critical success factors in agile software projects // Journal of Systems and Software. 2008. Vol. 81. No. 6. P. 961-971.
19. Power D.J., Sohal A.S., Rahman S.U. Critical success factors in agile supply chain management. An empirical study // International Journal of Physical Distribution and Logistics Management. 2001. Vol. 31. No. 4. P. 247-265.
20. The Open Group Architecture Framework (TOGAF). Version 9 "Enterprise Edition". [Электронный ресурс]: http://www.opengroup. org/togaf/ (дата обращения 15.03.2017).
21. West D. Planning a project with the rational unified process. Rational Whitepaper, 2002.
22. ГОСТ Р ИСО/МЭК 12207-2010. Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств. М.: Стандартинформ, 2010.
23. Bentley C. Prince2: A practical handbook. Routledge, 2010.
24. Wideman R.M. Comparing PRINCE2® with PMBoK®. Vancouver, Canada: AEW Services, 2002.
25. ГОСТ 34.601-90. АС. Стадии создания. М.: Стандартинформ, 1990.
26. Bourque P., Fairley R.E. Guide to the software engineering body of knowledge (SWEBOK (R)). Version 3.0. IEEE Computer Society Press, 2014.
27. Lankhorst M.M. Enterprise Architecture modelling - the issue of integration // Advanced Engineering Informatics. 2004. Vol. 18. No. 4. P. 205-216.
28. Ильин И.В., Левина А.И. Управление зрелостью бизнес архитектуры предприятия // Научно-технические ведомости Санкт-Петербургского государственного политехнического университета. Экономические науки. 2015. № 2 (216). С. 109-117.
БИЗНЕС-ИНФОРМАТИКА № 2(40) - 2017
