Manuscript ID : 1402021642147 Visit : 732 Page: 85 - 108

Article Type: Original Research

Presenting a Method for Agile Enterprise Architecture Modeling

Subject Areas : ICT

Ali Razi ¹ , Reza Rezaei ^{2
*} , Ahmad Ali Yazdanpanah ³

1 - Department of IT Management, Science and Research branch, Islamic Azad University, Tehran, Iran.
2 - گروه کامپیوتر، دانشکده فنی و مهندسی، واحد ساوه
3 - Faculty Member of Statistic Researches & Information Technology Group, Institute for Research & Planning in Higher Education (IRPHE), Ministry of Science, Research and Technology, Iran, Islamic Rep

Received: 2023-05-06 Accepted : 2024-03-16 Published : 2024-12-07

Keywords: Decision Model and Notation, Modeling Standards, Business Architecture Modeling, Agile Enterprise Architecture Modeling, Evaluating the Applicability and Simplicity.,

Abstract :

One of the important issues and concerns in agile enterprise architecture is the documenting and modeling of requirements and artifacts. Architectural models and documents should be produced and updated as necessary and while meeting the requirements and concerns of the stakeholders, they should be presented in the shortest time and at the lowest cost. On the other hand, methods and tools should be used that are applicable and simple, and while using agile practices and modeling standards, have the necessary comprehensiveness. Researches has been done regarding the modeling and documenting of agile enterprise architecture. Since there is no comprehensive, standard and minimal method for modeling and documenting agile enterprise architecture in related researches, therefore, in this paper, a method for modeling agile enterprise architecture is presented and evaluated by the combined (qualitative + quantitative) method. Qualitative evaluation is performed through a case study. For quantitative evaluation, the AHP method is used to weighting and ranking the criteria. Evaluation criteria are extracted based on library studies and experts' opinions. In order to quantitatively evaluate the proposed method, six criteria have been proposed in this paper, which are: production of required and necessary artifacts, reduction of modeling time, reduction of cost, improvement of stakeholders satisfaction, improvement of applicability and increase of simplicity, and criteria of production of required and necessary artifacts, has won the highest rank.

References:

[1]. A. Rüping, Agile Documentation: A Pattern Guide to Producing Lightweight Documents for Software Projects. Wiley; 1st edition, 2003.
[2]. J. M.Bass, “Artefacts and agile method tailoring in large-scale offshore software development programmes,” Information and Software Technology., vol. 75, pp. 1-16, July 2016.
[3]. A. Sadovykh, P. Desfray, B. Elvesæter, A. Berre, E. Landre, “Enterprise architecture modeling with SoaML using BMM and BPMN - MDA approach in practice,” Computer Science, 6th Central and Eastern European Software Engineering Conference, Oct 13-15, 2010, Moscow, Russia.
[4]. A. Zrnec, M. Bajec, M. Krisper, "Enterprise modelling with UML," Elektrotehni ski vestnik University of Ljubljana., vol. 68, pp. 109–114, 2001.
[5]. F. Armour, S. H. Kaisler, J. Getter, D. Pippin, “A UML-driven Enterprise Architecture Case Study,” Proceedings of the 36th Annual Hawaii International Conference, February, 2003.
[6]. A.Q. Gill, "agile enterprise architecture modelling: Evaluating the applicability and integration of six modelling standards," Information and Software Technology, vol. 67, pp. 196-206, November 2015.
]7[. راضی، علی، رضایی، رضا، یزدان پناه، احمد علی، "مدل سازی معماری سازمانی چابک: ارزیابی کاربردپذیری شش استاندارد مدل سازی بر مبنای چارچوب ملی معماری سازمانی ایران"، دو فصلنامه علمی فناوری اطلاعات و ارتباطات ایران، شماره های 47 و 48، 105_ 135، تهران، بهار و تابستان 1400.
[8]. Scott W. Ambler. Agile Modeling: Effective Practices for extreme Programming and the Unified Process , Published by John Wiley & Sons, Inc., New York, 2002, . [9]. J. Humble, D. Farley, Continuous Delivery. New York: Addison-Wesley Professional, 2010.
[10]. S. Yamamoto, Q. Zhia, Z. Zhoua, “Aspect Analysis towards ArchiMate Diagrams,” Procedia Computer Science., vol. 159, pp. 973-980, 2019.
[11]. F. Hasić, J. Vanthienen, “Complexity metrics for DMN decision models,” Computer Standards & Interfaces., vol. 65, pp. 15-37, July, 2019.
[12]. Scott W. Ambler. Agile Enterprise Architecture, 2021, .
[13]. R. Pichler, Agile Product Management with Scrum: Creating Products that Customers Love. New York: Addison-Wesley Professional; 1st edition, 2010.
[14]. F. Gampfer, “Managing Enterprise Architecture in Agile Environments,” Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2018, Bonn.
[15]. C. Finkelstein, Enterprise Architecture for Integration: Rapid Delivery Methods and Technologies (Artech House Mobile Communications Library). Artech House Print on Demand; 1st edition, 2006.
[16]. P. Clements et al, 2th Ed., Documenting Software Architectures Views and Beyond. United States of America: Pearson, 2011.
[17]. J. Patton, P. Economy, User Story Mapping: Discover the Whole Story, Build the Right Product. O'Reilly Media; 1st edition, 2014.
[18] M.Z., Muehlen, M. Indulska, G. Kamp, "Business Process and Business Rule Modeling Languages for Compliance Management: A Representational Analysis," in Research and Practice in Information Technology: The Twenty-Sixth International Conference on Conceptual Modeling, ER 2007, Auckland, New Zealand, November 5-9, 2007.
[19]. W., Wei, M., Indulska, S., Sadiq, “Guidelines for Business Rule Modeling Decisions,” Journal of Computer Information Systems., vol. 58, Issue 4, pp. 363-373, 2018.
[20]. M.z, Muehlen, M., Indulska, “Modeling languages for business processes and business rules: A representational analysis,” Information Systems., vol. 35, Issue 4, pp. 379–390, June, 2010.
[21]. H. Herbst, G. Knolmayer, T. Myrach, M. Schlesinger, “THE SPECIFICATION OF BUSINESS RULES: A COMPARISON OF SELECTED METHODOLOGIES,” Methods and Associated Tools for the Information Systems Life Cycle., pp. 29-46, September, 1994.
[22]. OMG, Decision Model and Notation 1.4 (DMN), 2022, .
[23]. E. Bazhenova, F. Zerbato, B. Oliboni, M. Weske, “From BPMN process models to DMN decision models,” Information Systems., vol. 83, pp. 69-88, July, 2019.
[24]. M. Häußler, S. Esser, A. Borrmann, “Code compliance checking of railway designs by integrating BIM, BPMN and DMN,” Automation in Construction., vol. 121, January, 2021, 103427.
[25]. I. Essefi, H. Rahmouni, M. Ladeb, “Integrated privacy decision in BPMN clinical care pathways models using DMN,” Procedia Computer Science., vol. 196, pp. 509-516, 2022.
[26]. M.D. Leoni, P. Felli, M. Montali, “Integrating BPMN and DMN: Modeling and Analysis,” Journal on Data Semantics., vol. 10, pp. 165-188, June, 2021.
[27]. OMG, ArchiMate 3.2, 2022, .
[28]. OMG, Unified Modeling Language 2.5 (UML), 2015, .
[29]. OMG, Business Process Model and Notation 2.0.2 (BPMN), 2013, .
[30]. G. Beydoun, G. Low, B. Henderson-Sellers, H. Mouratids, J.J. Gomez-Snaz, J. Pavon, C. Gonzalez-Perez, “FAML: a generic metamodel for MAS development,” IEEE Trans. Softw. Eng., vol. 35, Issue 6, pp. 841–863, Nov-Dec 2009.
[31]. OMG, Service Oriented Architecture Modeling Language 1.0.1 (SoaML), 2012, .
[32]. OMG, Business Motivation Model 1.3(BMM), 2015, .
]33[. صمدی اوانسر، عسگر، مقدمه ای بر معماری سازمانی (ویژه مدیران)، دبیرخانه شورای عالی اطلاع رسانی، تهران، ایران، 1384.
[34]. I. Band, H. Jonkers, E. Proper, D. Quartel, M. Lankhorst and M. Turner, "Using the TOGAF® 9.1 Framework with the ArchiMate® 3.0 Modeling Language," The Open Group, AUGUST 25, 2017.
[35]. M. Pankowska, “Business Models in CMMN, DMN and ArchiMate language,” Procedia Computer Science., vol. 164, pp. 11-18, 2019.
[36]. IBM Rational Unified Process (RUP), Business Modeling Discipline: Artifact Overview: Business Rules, 2001, .
[37]. P. Desfray, G. Raymond, Modeling Enterprise Architecture with TOGAF® A Practical Guide Using UML and BPMN. Morgan Kaufmann; 1st edition, 2014.
[38]. K. Figl, J. Mendling, G. Tokdemir, J. Vanthienend, “What we know and what we do not know about DMN,” Enterprise Modelling and Information Systems Architectures., vol. 13, No. 2, 2018.
[39]. A. Valencia-Parra, L. Parody, A.J. Varela-Vaca, I. Caballero, M.T. G´omez-L´opez, “DMN4DQ: When data quality meets DMN,” Decision Support Systems., vol. 141, February, 2021, 113450.
]40[. شمس علیئی، فریدون. مهجوریان، امیر و همکاران. چارچوب و روش شناسی معماری سازمانی ایران، نسخه 1، شورای اجرایی)عالی(فناوری اطلاعات کشور، کمیسیون توسعه دولت الکترونیکی، تهران، 1395، https://www.ieaf.ir/.
]41[. محمدی لرد، عبدالمحمود، فرآیندهای تحلیل شبکه‌ای (ANP) و سلسله مراتبی (AHP)به همراه معرفی نرم‌افزار Super Decision، تهران، انتشارات البرز فر دانش، 1388.
]42[. سرافرازی، اعظم، ایزدیار، صدیقه، حبیبی، آرش، تصمیم‌گیری چند معیاره فازی، تهران، انتشارات کتیبه گیل، 1393.
]43[. عطائی، محمد، تصمیم‌گیری چند معیاره، شاهرود، انتشارات دانشگاه صنعتی شاهرود، چاپ اول، 1389.
[44]. R., Attri, N., Dev, V., Sharma, “Interpretive Structural Modelling (ISM) approach: An Overview,” Research Journal of Management Sciences., vol. 2, Issue 2, pp. 3-8, February 2013.

Full-Text:

$G:\دوفصلنامه ارتباطات و فناوری اطلاعات\ITRC-Logo\English.png$

Journal of Information and

Communication Technology

Volume 16, Issue 61-62, Autumn and Winter 2024, pp. 85-108

Presenting a Method for Agile Enterprise Architecture Modeling

Ali Razi1, Reza Rezaei2¹, Ahmad Ali Yazdanpanah3

1 Department of IT Management, Science and Research branch, Islamic Azad University, Tehran, Iran

2 Department of Computer Engineering, Saveh Branch, Islamic Azad University, Saveh, Iran

3 Faculty Member of Statistic Researches & Information Technology Group,
Institute for Research & Planning in Higher Education (IRPHE),
Ministry of Science, Research and Technology, Tehran, Iran

Received: 06 May 2023, Revised: 03 March 2024, Accepted: 16 March 2024

Paper type: Research

Abstract

Keywords: Agile Enterprise Architecture Modeling, Agile Enterprise Architecture Documenting, Agile Enterprise Architecture Method, Minimum Viable Enterprise Architecture, Agile Enterprise Requirement Modeling, Evaluating Agile Modeling.

ارائه روشی برای مدل‌سازی معماری سازمانی چابک

علی راضی1 ، رضا رضایی2²، احمدعلی یزدان پناه3

1 دانشجوی رشته مدیریت فناوری اطلاعات، گروه مدیریت فناوری اطلاعات، دانشکده مدیریت و اقتصاد، واحد علوم و تحقیقات، دانشگاه آزاد اسلامی، تهران، ایران

2 گروه کامپیوتر، دانشکده فنی و مهندسی، واحد ساوه ،دانشگاه آزاد اسلامی، ساوه، ایران

3 استادیار موسسه پژوهش و برنامه‌ریزی آموزش عالی، موسسه پژوهش و برنامه‌ریزی آموزش عالی، تهران، ایران

تاریخ دریافت: 16/02/1402 تاریخ بازبینی: 13/12/1402 تاریخ پذیرش: 26/12/1402

نوع مقاله: پژوهشی

چکيده

یکی از مسائل و دغدغه‌های مهم در معماری سازمانی چابک، مستند سازی و مدل‌سازی نیازمندی‌ها و فرآورده‌ها است. مدل‌ها و مستندات معماری باید به اندازه و در حد ضرورت تولید و بروزرسانی شوند و ضمن رفع نیازمندی‌ها و دغدغه‌های ذینفعان، در کمترین زمان و با کمترین هزینه ارائه گردند. از طرف دیگر باید از روش‌ها و ابزارهایی استفاده نمود که کاربردپذیر و ساده بوده و ضمن بکارگیری روش‌های عملی چابک و استانداردهای مدل‌سازی جامعیت لازم را داشته باشند. تحقیقاتی در خصوص مدل‌سازی و مستندسازی معماری سازمانی چابک انجام شده است. از آنجایی‌که در تحقیقات مرتبط روشی جامع، استاندارد و کمینه برای مدل‌سازی و مستند معماری سازمانی چابک ارائه نشده، لذا در این مقاله روشی برای مدل‌سازی معماری سازمانی چابک ارائه گردیده و با روش ترکیبی (کیفی + کمی) ارزیابی می‌گردد. ارزیابی کیفی از طریق مطالعه موردی انجام می‌پذیرد. برای ارزیابی کمی از روش AHP برای وزن‌دهی و رتبه‌بندی معیارها استفاده می‌شود. معیارهای ارزیابی بر اساس مطالعات کتابخانه‌ای و نظرات خبرگان استخراج می‌گردند. برای ارزیابی کمی روش پیشنهادی در این مقاله شش معیار مطرح شده‌اند که عبارتند از: تولید فرآورده‌های مورد نیاز و ضروری، کاهش زمان مدل‌سازی، کاهش هزینه، بهبود رضایت ذینفعان، بهبود کاربردپذیری و افزایش سادگی که معیار تولید فرآورده‌های مورد نیاز و ضروری رتبه اول را کسب کرده است.

کلیدواژگان: مدل‌سازی معماری سازمانی چابک، مستندسازی معماری سازمانی چابک، روش معماری سازمانی چابک، حداقل معماری سازمانی قابل دوام، مدل‌سازی نیازمندی‌های سازمانی چابک، ارزیابی مدل‌سازی چابک.

[1] * Corresponding Author’s email: rezarezaei@iau-saveh.ac.ir

[2] * رایانامة نويسنده مسؤول: rezarezaei@iau-saveh.ac.ir

1- مقدمه

معماری سازمانی چابک از بیانیه چابک¹ و اصول حاکم بر آن متاثر است]1[. در معماری سازمانی چابک، ضروری است که مدل‌ها و فرآورده‌ها به اندازه و به جا تولید و بروزرسانی شوند]2[. مدل‌سازی معماری سازمانی چابک، مجموعه‌ای از اصول، ارزش‌ها و تجارب عملی چابک است که به ذینفعان معماری سازمانی کمک می‌کند که فرآورده‌ها و مدل‌های معماری سازمانی را به شکل تکاملی، تدریجی و ساده تولید و بروزرسانی نمایند]3[ و ]4[. نزدیک شدن به معماری تک صفحه‌ای یکی از اهداف مهم معماران سازمانی چابک است]5[. تحقیقاتی در خصوص ارائه روش‌ها، راهکارها و چارچوب‌ها در حوزه معماری سازمانی چابک و مدل‌سازی معماری سازمانی چابک انجام شده‌اند ]6[ تا ]13[. برخی از تحقیق‌ها بر مدل‌سازی استاندارد و ترکیب و بکارگیری استانداردهای مدل‌سازی نظیر: ]14[ ArchiMate²، ]15[ UML³، ]16[ ⁴BPMN، ]17[⁵FAML، ]18[ ⁶SoaML، ]19[ BMM⁷، ]20[ DMN⁸، ]21[ ⁹ CMMN و ]22[ ¹⁰SysML در معماری سازمانی تاکید کرده‌اند ]23[ و ]24[. با این حال با افزایش تعداد استانداردهای مدل‌سازی و به تبع آن افزایش تعداد عناصر و نمادهای آنها، این نگرانی و دغدغه ایجاد می‌شود که زمان تولید مدل‌ها و مستندات و حجم آنها افزایش یابد ]25[ و ]26[. ضمن اینکه ممکن است در یادگیری و آموزش استانداردها و پشتیبانی ابزارها پیچیدگی ایجاد شده و هزینه‌ها نیز افزایش یابند که این بر خلاف پارادایم حاکم در معماری سازمانی چابک است ]2[. برخی از معماران چابک با در نظر گرفتن اصول و قواعد مدل‌سازی و مستندسازی چابک و با توجه به وجود دید معمارانه و کلان‌نگر در معماری سازمانی از تعدد بکارگیری استانداردهای مختلف اجتناب کرده و سعی می‌کنند به ساده‌ترین روش و کمترین تعداد استاندارد، مدل‌های معماری را تولید نمایند ]27[ تا ]30[. از طرف دیگر برخی از معماران چابک نیز به دلیل تنوع نیازمندی‌های معماری و ایجاد زبان مشترک بین ذینفعان با تخصص‌ها و فرهنگ‌های مختلف بر بکارگیری و ترکیب حداکثری استانداردهای مدل‌سازی تاکید دارند ]7[. برخی دیگر از معماران چابک نیز بر کمینه کردن عناصر استانداردهای مدل‌سازی تمرکز کرده‌اند ]25[ و ]26[. برخی از تحقیق‌های انجام شده نیز بر بکارگیری اصول و تجارب عملی چابک در مدل‌سازی معماری سازمانی چابک تاکید کرده‌اند ]11 [تا ]13[. بسیاری از تحقیقات انجام شده فاقد جامعیت بوده و برای مدل‌سازی همه لایه‌های معماری سازمانی راه‌حل مشخصی ارائه نکرده‌اند ]31 [تا ]33[. همچنین در برخی از تحقیق‌های انجام شده مراحل و گام‌های اجرایی جهت تولید مدل‌ها و فرآورده‌ها مشخص نشده‌اند ]8[ و ]9[. طبق بیانیه چابک و اصول حاکم بر معماری سازمانی چابک، ضروری است مدل‌های معماری در کمترین زمان ممکن و با کمترین هزینه تولید و بروزرسانی شوند ]1 [و ]3[ و ]4[. همچنین سادگی و کاربردپذیری روش مدل‌سازی و ابزارهای مورد استفاده و بهبود رضایت ذینفعان معماری از مهمترین شاخص‌ها در مدل‌سازی معماری سازمانی چابک هستند ]2 [و ]23[. چارچوب‌ها و روش‌های چابک معماری سازمانی بر تمرکز بر مدل‌سازی وضعیت مطلوب معماری تاکید کرده‌اند ]34 [تا ]36[، با این حال اکثر روش‌ها و راهکارهای ارائه شده در این خصوص سکوت کرده‌اند. اما سوال اول اینکه آیا روشی برای مدل‌سازی معماری سازمانی چابک با ویژگی‌های زیر وجود دارد؟

· جامعیت (مدل‌سازی همه لایه‌های معماری سازمانی)

· تاکید و تمرکز بر مدل‌سازی معماری وضعیت مطلوب و گلوگاه‌های سازمان

· تعیین مراحل انجام مدل‌سازی و گام‌های هر مرحله

· تاکید بر مدل‌سازی استاندارد

· کمینه کردن نمادها و عناصر استانداردهای مدل‌سازی

· تولید فرآورده‌های ضروری و لازم و حذف فرآورده‌های غیر ضروری و زاید

· بکارگیری روش‌های عملی چابک

و سوال دوم اینکه در صورت وجود روشی با ویژگی‌های فوق، چگونه ارزیابی می‌شود؟

با توجه به اینکه تحقیقات انجام شده در خصوص روش‌ها و چارچوب‌های مدل‌سازی معماری سازمانی چابک، جامعیت لازم را برای پاسخگویی به سوالات مطرح شده ندارند لذا در این مقاله به آن پرداخته شده و یک روش برای مدل‌سازی معماری سازمانی چابک با ویژگی‌های اشاره شده ارائه و به روش ترکیبی¹¹ ارزیابی می‌گردد. در ادامه در بخش دوم پیشینه و زمینه تحقیق بررسی می‌گردد. در بخش سوم روش پیشنهادی تشریح می‌گردد. در بخش چهارم روش ارزیابی ارائه می‌گردد. در بخش پنجم ارزیابی روش پیشنهادی و تجزیه و تحلیل داده‌ها به روش ترکیبی انجام می‌شود. در بخش ششم روند انجام کار و نتایج حاصله بررسی گردیده و بحث و تحلیل انجام می‌پذیرد. در نهایت نتیجه گیری انجام شده و کارهای آینده معرفی می‌شوند.

2- پیشینه و زمینه تحقیق

در معماری سازمانی چابک، بر خلاف روش‌های سنتی و آبشاری بر تولید مدل‌ها و مستندات به اندازه و به شکل تکاملی و تدریجی تأکید شده است ]2[. تولید مدل‌ها در کمترین زمان، با کمترین هزینه، به ساده‌ترین روش ممکن و دستیابی به معماری تک‌صفحه‌ای از مهمترین اهداف معماران چابک است ]3[ تا ]5[. روش‌ها، راهکارها و چارچوب‌هایی برای مدل‌سازی معماری سازمانی چابک ارائه شده‌اند. برخی از تحقیقات انجام شده در این حوزه به ارائه راهکارهایی مبتنی بر بکارگیری تجارب عملی چابک¹² نظیر: تعریف تکرارها و اسپرینت‌ها، تحویل مداوم مدل‌ها و تعاملات نزدیک با مشتریان و ذینفعان پرداخته‌اند. با این حال در خصوص ارائه مراحل و گام‌های مدل‌سازی و نحوه تولید مدل‌ها و فرآورده‌ها راهکار خاصی ارائه نکرده‌اند.

برخی دیگر از محققان و صاحب‌نظران بر بکارگیری مدل‌سازی استاندارد و ترکیب استانداردهای خوش‌تعریف و شناخته شده برای مدل‌سازی معماری سازمانی چابک تاکید کرده‌اند. آنها اعتقاد دارند بکارگیری استانداردهای مدل‌سازی معروف در مدل‌سازی معماری سازمانی چابک سبب ایجاد درک و فهم مشترک بین ذینفعان معماری می‌گردد. تحقیق‌هایی در خصوص بکارگیری استاندارد ArchiMate در مدل‌سازی معماری سازمانی انجام شده است. برخی از تحقیقات نیز به ترکیب استاندارد ArchiMate با سایر استانداردهای مدل‌سازی نظیر UML، BPMN، FAML،SoaML وBMM ، DMN، CMMN و SysML پرداخته‌اند.

برخی از معماران چابک دغدغه دارند که با افزایش تعداد استانداردها و عناصر و نمادهای آنها در مدل‌سازی پیچیدگی ایجاد شده و زمان مستندسازی و هزینه‌ها افزایش یافته و یادگیری و پشتیبانی مدل‌ها نیز با چالش مواجه گردد. بر این اساس این دسته از معماران و مدل‌سازان، راهکارهایی را برای کمینه‌کردن عناصر استانداردهای مدل‌سازی ارائه کرده‌اند.

Medeiros و همکارانش یک رویکرد چابک برای مدل‌سازی معماری سازمانی ارائه کرده‌اند ]6[. در این روش بر تعریف اسپرینت‌ها، تحویل مداوم، تعاملات کوتاه و زیاد با مشتریان و بهبود سیستماتیک و بکارگیری استاندارد‌های ArchiMate و BPMN تاکید شده است. با این حال روشی برای کمینه‌کردن فرآورده‌ها و عناصر مدل‌سازی ارائه نشده است.

شیرازی و همکارانش چارچوبی برای معماری سازمانی چابک ارائه کرده‌اند ]8[. علی رغم تاکید بر روش‌های عملی چابک و چابک شدن مدیریت فرآیند معماری سازمانی روشی برای تولید مدل‌های چابک ارائه نشده است.

امیری در تحقیق خود چالش‌ها و نقاط ضعف روش‌های چابک را برای بکارگیری در معماری سازمانی بررسی کرده است]9[. با این حال در خصوص تولید فرآورده‌ها و مدل‌های چابک راهکاری ارائه نشده است.

راهکارها و روش‌های دیگری هم در حوزه معماری سازمانی چابک ارائه شده‌اند که علی رغم تاکید بر روش‌های عملی چابک و تاکید بر چابک شدن مدیریت فرآیند معماری سازمانی، روشی را برای تولید مدل‌های چابک ارائه نکرده‌اند ]7 [و ]10[ تا ]12[.

با توجه به تحقیق‌های انجام شده، نواقصی شامل عدم جامعیت برای مدل‌سازی همه لایه‌های معماری سازمانی، عدم کمینه کردن عناصر استانداردهای مدل‌سازی و فرآورده‌های معماری و عدم تعیین شفاف مراحل و گام‌های اجرایی برای مدل‌سازی، مشاهده می‌شود.

Werewka و همکارانش روشی را برای معماری سازمانی چابک مبتنی بر اسکرام ارائه کرده‌اند ]13[. برای مدل‌سازی، استاندارد ArchiMate به صورت تکرارپذیر پیشنهاد شده است. با این حال روشی برای کمینه کردن عناصر و فرآورده‌های معماری و بکارگیری تجارب عملی چابک ارائه نشده است.

Gill راهکاری مبتنی بر ترکیب شش استاندارد مدل‌سازی در معماری سازمانی ارائه کرده و با مطالعه موردی کاربردپذیری و یکپارچگی آن را ارزیابی کرده است]23[. در راهکار ارائه شده توسط Gill، مراحل وگام‌های انجام مدل‌سازی دقیقا مشخص نشده‌اند و در خصوص چابکی روند مدل‌سازی نیز راه‌حل مشخصی ارائه نشده است. همچنین تحقیق ایشان در خصوص مدل‌سازی قوانین و تصمیم‌های کسب‌وکار نیز قابل بهبود است.

Buchalcevova در تحقیق خود راهکاری برای خلاصه‌سازی و ساده‌سازی استاندارد ArchiMate برای مدل‌سازی سازمان‌های کوچک ارائه کرده است. علی رغم ارائه یک روش با مراحل و گام‎های مشخص، راه‌حل مشخصی برای بکارگیری تجارب عملی چابک ارائه نشده است]26[.

Zrnec و همکارانش و Armour و همکارانش در تحقیق‌های خود روشی برای بکارگیری عناصر استاندارد UML در مدل‌سازی سازمانی ارائه کرده‌اند اما در خصوص بکارگیری تجارب عملی چابک و تعیین مراحل و گام‌های مدل‌سازی راهکار مشخصی ارائه نشده است. ضمن اینکه عناصر استاندارد UML برای مدل‌سازی معماری نرم‌افزار طراحی شده‌اند و کمتر مقبولیت سازمانی دارند]27 [و ]28[.

Yamamoto و همکارانش در مقاله خود با استفاده از روش تحلیل جنبه‌گرا، راهکاری را برای ساده کردن بکارگیری استاندارد ArchiMate مطرح کرده و به روش مطالعه موردی ارزیابی نموده‌اند]25[. Yamamotoدر مقاله دیگر راهکاری برای مدل‌سازی سیستم سرویس هوش مصنوعی ارائه کرده است]29[. وی در مقاله دیگری راهکاری برای محدود کردن تعداد عناصر استاندارد ArchiMate برای مدل‌سازی یک شهر هوشمند ارائه کرده و از طریق مطالعه موردی آن را ارزیابی نموده است]30[. با این حال در خصوص بکارگیری تجارب عملی چابک راهکار مشخصی ارائه نشده است.

Aldea و همکارانش و Kitsios و همکارانش در تحقیق‌های خود روشی برای مدل‌سازی لایه استراتژی با عناصر استاندارد ArchiMate مطرح کرده‌اند با این حال در خصوص مدل‌سازی سایر لایه‌های معماری و بکارگیری تجارب عملی چابک راهکار مشخصی ارائه نکرده‌اند]31 [و ]32[.

Bhattacharya در تحقیق خود روشی برای مدل‌سازی لایه استراتژیک معماری با ترکیب دو استاندارد مدل‌سازی ارائه کرده است]33[. با این حال در خصوص مدل‌سازی سایر لایه‌های معماری و بکارگیری تجارب عملی چابک راهکار مشخصی ارائه نشده است.

Pankowska در تحقیق خود راهکاری برای مدل‌سازی معماری کسب‌وکار با ترکیب سه استاندارد مدل‌سازی ارائه کرده ولی راه‌حل چابکی برای بکارگیری آن مطرح نکرده است]39[. ضمن اینکه راهکاری برای مدل‌سازی سایر لایه‌های معماری سازمانی نیز ارائه نشده است. Pankowska در تحقیق دیگر نیز روشی برای مدل‌سازی چابک نیازمندی‌های سازمانی با ترکیب دو استاندارد مدل‌سازی ارائه و با یک مطالعه مورد برای فروشگاه آنلاین آن را ارزیابی کرده است]37[. با این حال برای مدل‌سازی همه لایه‌های معماری راه‌حل مشخصی وجود ندارد.

Sadovykh و همکارانش در تحقیق خود روشی را برای مدل‌سازی معماری با ترکیب سه استاندارد مدل‌سازی ارائه کرده‌اند]38[. در این تحقیق بر مدل‌سازی معماری سرویس‌گرا و همراستایی آن با حوزه کسب‌وکار و استراتژی تاکید شده است. با این حال در خصوص بکارگیری روش‌های عملی چابک و تعیین مراحل و گام‌های اجرا راهکاری ارائه نشده است.

Dingو همکارانش روشی را برای بومی‌سازی و مختصرسازی استاندارد ArchiMate برای مدل‌سازی لایه‌های نرم‌افزارهای کاربردی و زیرساخت فناوری ارائه کرده‌اند]42[. با این حال در خصوص تعیین مراحل و گام‌ها برای مدل‌سازی همه لایه‌های معماری راهکار مشخصی ارائه نشده ضمن اینکه در خصوص تجارب عملی چابک نیز روشی مطرح نشده است.

Kirikova در مقاله خود روشی را برای تولید مدل‌ها و فرآورده‌های سازمانی ارائه کرده است]43[. در خصوص بکارگیری استانداردهای مدل‌سازی و کمینه کردن فرآورده‌ها و عناصر استانداردهای مدل‌سازی روش خاصی ارائه نشده است.

Vernadat در مقاله خود کارهای تحقیقاتی انجام شده در مدل‌سازی سازمانی در طول چهار دهه گذشته را بررسی کرده است. وی اصول مدل‌سازی، ساختارها، زبان‌ها، چارچوب‌ها و استانداردهای مدل‌سازی را معرفی و تشریح نموده است. سپس در مورد تحولات آینده مدل‌سازی سازمانی در زمینه تولید هوشمند یا صنعت 4.0 بحث نموده است]44[. با این حال در خصوص مدل‌سازی معماری سازمانی چابک، راه‌حل مشخصی ارائه نشده است.

چارچوب‌های چابک معماری سازمانی بر تمرکز بر مدل‌سازی وضعیت مطلوب تاکید کرده‌اند]34 [و ]35[ و ]36[، با این حال تقریبا هیچ کدام از تحقیق‌های انجام شده برای این موضوع راه‌حل مشخصی ارائه نکرده‌اند. همچنین تحقیق‌های انجام شده برای ارزیابی راهکارها و روش‌ها از مطالعه موردی برای نشان دادن مدل‌های تولید شده استفاده کرده‌اند، اما ارزیابی کمی مبتنی بر شاخص‌های مدل‌سازی معماری سازمانی چابک و نظرات خبرگان، انجام نشده است. این در حالی است که ارزیابی کمی در کنار ارزیابی کیفی در پژوهش‌های مرتبط با معماری سازمانی حائز اهمیت است. برای ارزیابی کمی راه‌حل‌های ارائه شده در معماری سازمانی و از جمله مدل‌سازی معماری سازمانی چابک، روش‌های مختلفی وجود دارد. بکارگیری روش‌های تصمیم‌گیری چند‌ معیاره¹³ از قبیل AHP¹⁴، ¹⁵ANP و ... برای ارزیابی راهکارهای ارائه شده در معماری سازمانی و از جمله مدل‌سازی معماری سازمانی چابک مورد پذیرش هستند]45 [و ]46[.

بکارگیری شبکه‌های پتری¹⁶ ]47[ و نظریه صف¹⁷ ]48[، روش‌های دیگری برای ارزیابی کمی کارایی و قابلیت اطمینان راه‌حل‌های ارائه شده هستند. شبکه‌های پتری برای مدل‌سازی ریاضی فرآیندها و ارزیابی آن‌ها مفید هستند. نظریه صف نیز، برای مدل‌سازی ریاضی یک صف در انتظار، و تصمیم گیری در مورد منابع مورد نیاز آن کاربرد دارد. تحقیقاتی در خصوص بکارگیری شبکه‌های پتری در ارزیابی معماری و مدل‌سازی استاندارد انجام شده‌اند]49 [و ]50[ و ]51 [و ]52[. ]53 [و ]54[. با این حال بهبود و تکمیل آن‌ها در آن کارهای آینده ضروری هستند.

مدل‌سازی معماری سازمانی چابک دارای ویژگی‌هایی است که عبارتند از: جامعیت مدل‌سازی، تاکید و تمرکز بر مدل‌سازی معماری وضعیت مطلوب، تاکید و تمرکز بر مدل‌سازی گلوگاه‌های سازمان، تعیین مراحل انجام مدل‌سازی و گام‌های هر مرحله، تاکید بر مدل‌سازی استاندارد، کمینه‌سازی، تولید فرآورده‌های ضروری و لازم و حذف فرآورده‌های غیر ضروری و زاید، تعیین نقش مدل‌ساز چابک، برنامه‌ریزی تکرار و انتشار، مدل‌سازی نیازمندی‌های چابک و اولویت‌بندی مدل‎سازی طبق نیازمندی‌ها و دغدغه‌های ذینفعان ]1 [و ]2[ و ]5 [و ]23[ و ]34 [و ]36[.

از آنجاییکه در پیشینه تحقیق برخی از ویژگی‌های مدل‌سازی معماری سازمانی چابک توسط روش‌های ارائه شده پوشش داده نشده و یا به شکل ناقص پوشش داده شده‌اند، لذا ارائه یک روش جامع و کامل برای مدل‌سازی معماری سازمانی چابک برای پوشش کامل همه ویژگی‌های مورد نظر لازم و ضروری به نظر می‌رسد.

3- روش پیشنهادی

در این مقاله یک روش برای مدل‌سازی معماری سازمانی چابک با هدف پوشش نقایص پیشینه تحقیق ارائه می‌گردد. روش پیشنهادی بر اساس یک روش تحقیق تدوین و طراحی شده است. تحقیق انجام شده از نظر نتایج یا پیامد از نوع کاربردی، از نظر هدف از نوع توصیفی و به شکل مطالعه‌ موردی و از نظر روش و اجرا، ترکیبی (کیفی + کمی) است. همچنین تحقیق انجام شده از نوع پیمایشی نیز می‌باشد زیرا از ابزارهایی مثل پرسشنامه AHP و مصاحبه با خبرگان برای جمع آوری داده‌ها استفاده شده است. برای جمع آوری داده‌ها از روش‌هایی نظیر: مطالعات کتابخانه‌ای، فیش برداری اطلاعات از اینترنت و کتابخانه و افکارسنجی، مصاحبه و نظرسنجی از خبرگان به شکل تحقیق میدانی استفاده شده است. جامعه آماری تحقیق، محدود و شامل 12 نفر از خبرگان مدل‌سازی معماری سازمانی چابک است. برای نمونه‌گیری از روش‌نمونه گیری غیر تصادفی و از نوع نمونه‌گیری گلوله‌برفی و نمونه‌گیری قضاوتی استفاده شده است. سازمانی که به منظور اجرای مطالعه موردی بر اساس روش پیشنهادی برگزیده شده، شرکت مخابرات ایران است. سازمان مورد نظر یک سازمان ایرانی است و به معماری سازمانی در راستای اهداف و برنامه‌های دولت الکترونیک نیاز دارد. همچنین به دلیل اینکه در معرض تغییرات زیاد و مکرر محیطی، کسب‌وکار و فناورانه قرار گرفته، به معماری سازمانی چابک نیاز دارد. به دلیل وجود ذینفعان متنوع و متخصص در حوزه فناوری اطلاعات و ارتباطات در این شرکت و نیاز به تولید و بروزرسانی مستندات و مدل‌های معماری به شکل مختصر و مفید با کمترین هزینه و در کمترین زمان ممکن، به یک روش جامع، کامل، ساده و کاربردپذیر برای مدل‌سازی معماری سازمانی چابک نیاز دارد.

روش پیشنهادی برای پوشش همه ویژگی‌های مدل‌سازی معماری سازمانی چابک تدوین گردیده و بر مبنای اصول و ویژگی‌های زیر استوار است:

· جامعیت: روش پیشنهادی جامع است یعنی همه لایه‌ها و مراحل معماری سازمانی را برای مدل کردن چابک نیازمندی‌ها و فرآورده‌ها در نظر گرفته است.

· تعیین مراحل انجام مدل‌سازی و گام‌های هر مرحله: در روش پیشنهادی مراحل انجام مدل‌سازی معماری سازمانی چابک مشخص گردیده است. برای هر مرحله تعدادی گام در نظر گرفته شده است. همچنین مشخص شده است که از هر مرحله به کدام مراحل دیگر می‌توان حرکت کرد.

· تاکید بر مدل‌سازی استاندارد: در روش پیشنهادی بر مدل‌سازی استاندارد یعنی بکارگیری استانداردهای مدل‌سازی مشهور، شناخته شده و خوش تعریف تاکید شده است. بکارگیری مدل‌سازی استاندارد سبب ایجاد وحدت نظر و درک مشترک بین ذینفعان معماری سازمانی شده و از مدل‌سازی به شکل سلیقه‌ای جلوگیری می‌کند.

· کمینه کردن نمادها و عناصر استانداردهای مدل‌سازی: در روش پیشنهادی از همه عناصر و المان‌های استانداردهای مدل‌سازی استفاده نمی‌شود بلکه از عناصر مشخص و محدود برای تولید فرآورده‌های مورد نیاز استفاده می‌گردد. بکارگیری همه عناصر و المان‌های استانداردهای مدل‌سازی خود سبب پیچیدگی مدل‌سازی شده و چابکی را کاهش می‌دهد. در روش پیشنهادی در صورتی از المان‌ها و عناصر بیشتر برای مدل‌سازی استفاده می‌شود که نیاز به تولید فرآورده‌های با جزئیات بیشتر توسط ذینفعان تشخیص داده شود.

· تولید فرآورده‌های ضروری و لازم و حذف فرآورده‌های غیر ضروری و زاید: در روش پیشنهادی همه فرآورده‌های معماری سازمانی تولید نمی‌شوند بلکه مطابق با نیازمندی‌ها و دغدغه‌های ذینفعان معماری مهمترین آنها تولید و بروز می‌شوند.

· بکارگیری روش‌های عملی چابک: در روش پیشنهادی بر بکارگیری روش‌های عملی چابک از قبیل: برنامه‌ریزی تکرار، بکارگیری اپیک و استوری برای جمع‌آوری نیازمندی‌ها، تمرکز بیشتر بر معماری وضعیت مطلوب و نقاط کلیدی و گلوگاه‌های سازمان تاکید شده است.

در شکل 1 روش پیشنهادی و مراحل انجام آن نشان داده شده است. هر مرحله شامل اهداف، ورودی‌ها، فعالیت‌ها و خروجی‌هایی است.

مراحل روش پیشنهادی و گام‌های هر مرحله به شرح زیر هستند:

3-1- مرحله برنامه‌ریزی مدل‌سازی چابک

در این مرحله برنامه‌ریزی چابک انجام می‌شود و شامل گام‌هایی به شرح زیر است :

· تاکید و تمرکز بر معماری وضعیت مطلوب) مدل‌سازی وضعیت موجود در صورت نیاز و ضرورت انجام می‌شود(.

· تعیین گلوگاه‌های¹⁸ سازمان و اولویت‌بندی آنها و تمرکز بر مدل‌سازی آن‌ها متناسب با نظرات، نیازها و دغدغه‌های ذینفعان (گلوگاه‌های سازمان نقاط ضعیف، پرمخاطره و آسیب‌پذیر سازمان هستند.)

· تعیین محدوده معماری

· برنامه‌ریزی تکرار و انتشار (تعریف تکرارها و فرسنگ شمارها)

· تعیین و انتخاب ابزارهای مناسب و ساده برای مدل‌سازی متناسب با نظرات، نیازها و دغدغه‌های ذینفعان

· تعیین استانداردهای مدل‌سازی و عناصر مورد نیاز آنها

· اولویت‌بندی انجام مدل‌سازی

· تعیین و تعریف نقش مدل‌ساز چابک در تیم معماری

· تهیه لیست ذینفعان و انتظارات آن‌ها، ریسک‌ها، مقاومت‌ها و محدودیت‌ها

· اخذ مجوزها و تهیه منابع لازم جهت تسریع در امور

3-2- مرحله مدل‌سازی نیازمندی‌های معماری )وظیفه‌مندی و غیر وظیفه‌مندی(

در این مرحله نیازمندی‌های معماری جمع آوری و مدل می‌شوند. نیازمندی‌های معماری مطابق شکل 2 در قالب موضوع¹⁹، ابتکار²⁰، اپیک²¹ (مجموعه حماسی) و استوری²² (داستان کاربری) طبقه‌بندی و مدل‌سازی می‌شوند]55[. یک موضوع یک محدوده بزرگی از معماری است. یک ابتکار مجموعه‌ای از اپیک‌های مرتبط با هم است که به یک هدف مشترک منتهی می‌شوند. یک اپیک یک قطعه نیازمندی بزرگ و سطح بالاست. یک استوری هم یک درخواست و یا یک نیازمندی کوتاه است که توسط ذینفعان معماری مطرح می‌شود. به ازای هر استوری لازم است موارد زیر مشخص شوند:

· تعیین اولویت و اهمیت توسط ذینفعان (کم، خیلی کم، متوسط، زیاد، خیلی زیاد)

· تعیین میزان جزئیات مورد نیاز برای مدل‌سازی توسط ذینفعان (کم، خیلی کم، متوسط، زیاد، خیلی زیاد)

· تعیین نوع جمع آوری (مصاحبه، مشاهده، جلسات گروهی، طوفان فکری، نمونه‌سازی اولیه، نظرسنجی)

· تعیین نوع مستند کردن (در ابزار تالیف/مدل‌سازی، در قالب فایل کامپیوتری، نوشتن/ترسیم روی تخته وایت‌برد و تهیه عکس، نوشتن/ترسیم روی کاغذ و تهیه عکس)

3-3- مرحله مدل‌سازی سطح بالای معماری

در این مرحله مدل‌سازی سطح بالای معماری با تعریف لایه‌ها و مراحل کلان معماری انجام می‌شود. لایه‌ها معماری شامل لایه چشم‌انداز و استراتژی، لایه کسب‌وکار، لایه اطلاعات و داده، لایه نرم‌افزارهای کاربردی، لایه فناوری و لایه مدیریت نیازمندی‌ها هستند.

[1] Agile Manifesto

[2] Architecture-Animate

[3] Unified Modeling Language

[4] Business Process Model and Notation

[5] FAME [Framework for Agent-Oriented Method Engineering] Language

[6] Service Oriented Architecture Modeling Language

[7] Business Motivation Model

[8] Decision Model and Notation

[9] Case Management Model and Notation

[10] The Systems Modeling Language

[11] Mixed Method

[12] Agile Practices

[13] Multiple Attribute Decision-making (MADM)

[14] Analytical Hierarchy Process

[15] Analytical Network Process

[16] Petri Net

[17] Queueing Theory

[18] Bottleneck

[19] Theme

[20] Initiative

[21] Epic

[22] User Story

شکل 1. روش پیشنهادی و مراحل انجام آن

شکل 2. ساختار مدل‌سازی نیازمندی‌ها

3-4- مرحله مدل‌سازی چشم‌انداز معماری

در این مرحله با توجه به نیازمندی‌های جمع آوری شده، تمرکز بر مدل‌سازی اهداف و مدل‌سازی ذینفعان است. در صورت ناقص بودن نیازمندی‌ها برای مدل‌سازی این مرحله می‌توان به مرحله مدل‌سازی نیازمندی‌های معماری برگشت و اطلاعات و نیازمندی‌های تکمیلی را جمع آوری نمود.

· مدل‌کردن اهداف شامل: مدل بیانیه چشم‌انداز، مدل بیانیه ماموریت، مدل اهداف کوتاه مدت و بلند مدت و راهبردها و تاکتیک‌ها

· مدل‌سازی ذینفعان و مشخصات، نیازمندی‌ها و دغدغه‌های آنها

· در صورت نیاز ذینفعان به جزئیات بیشتر برای مدل‌سازی چشم‌انداز موارد دیگر نیز مدل می‌شوند، شامل :

· مدل‌سازی سیاست‌های سازمان

· مدل‌سازی پیشران‌های داخلی و خارجی

· مدل‌سازی اصول، محدودیت‌ها و ارزش‌ها

· مدل‌سازی دستاوردهای سازمان

· مدل‌سازی عوامل تاثیرگذار بر روند معماری سازمانی

· مدل‌سازی منابع مورد نیاز

3-5- مرحله مدل‌سازی معماری کسب‌وکار

در این مرحله با توجه به نیازمندی‌های جمع آوری شده، تمرکز بر مدل‌سازی کنشگران، کارکردها، فرآیندها و سرویس‌های کسب‌وکار و ارتباطات و تعاملات بین آن‌ها است. در صورت ناقص بودن نیازمندی‌ها برای مدل‌سازی این مرحله می‌توان به مرحله مدل‌سازی نیازمندی‌های معماری برگشت، و اطلاعات و نیازمندی‌های تکمیلی را جمع‌آوری نمود.

· مدل‌کردن کنشگران کسب‌وکار و ساختار سازمانی

· مدل‌کردن کارکردهای کسب‌وکار و دسته‌بندی و ارتباطات آنها

· مدل‌کردن فرآیندهای کسب‌وکار و دسته‌بندی و ارتباطات آنها

· مدل‌کردن سرویس‌های کسب‌وکار و دسته‌بندی و ارتباطات آنها

· مدل‌کردن ارتباطات بین کنشگران، کارکردها، فرآیندها و سرویس‌ها

· در صورت نیاز ذینفعان به جزئیات بیشتر برای مدل‌سازی معماری کسب‌وکار موارد دیگر نیز مدل می‌شوند، شامل:

· مدل‌سازی نقش‌های کسب‌وکار

· مدل‌سازی رابط‌های کسب‌وکار

· مدل‌سازی وقایع کسب‌وکار

· مدل‌سازی محصولات

· مدل‌سازی قراردادها

· مدل‌سازی جزئیات فرآیندهای کسب‌وکار و گردش کار و تعیین فعالیت‌ها، توالی، شروط، وقایع و نقش‌های مربوطه

· مدل‌سازی قوانین و تصمیم‌های کسب‌وکار مرتبط با هر فرآیند و تعیین سرویس‌های تصمیم‌گیری، جداول تصمیم، داده‌های ورودی، پایگاه دانش قوانین و تصمیم‌ها

3-6- مرحله مدل‌سازی معماری فناوری اطلاعات

در این مرحله با توجه به نیازمندی‌های جمع‌آوری شده، مدل‌سازی معماری فناوری اطلاعات انجام می‌شود. در صورت ناقص بودن نیازمندی‌ها برای مدل‌سازی این مرحله می‌توان به مرحله مدل‌سازی نیازمندی‌های معماری برگشت و اطلاعات و نیازمندی‌های تکمیلی را جمع‌آوری نمود. این مرحله خود شامل سه زیر مرحله است:

3-6-1- مرحله مدل‌سازی معماری داده

· مدل‌کردن معماری داده از طریق کلاس‌ها و موجودیت‌ها و بسته‌بندی آنها و تعیین صفات و متدهای هر کلاس و ارتباطات بین کلاس‌ها

· مدل‌کردن ارتباط کلاس‌ها با فرآیندها و کارکردهای کسب‌وکار

· در صورت نیاز ذینفعان به مدل‌سازی جزئیات معماری نرم‌افزارهای کاربردی موارد دیگر نیز مدل می‌شوند، شامل: مدل‌سازی جداول پایگاه داده

3-6-2- مرحله مدل‌سازی معماری نرم‌افزارهای کاربردی

· مدل‌کردن کردن نرم‌افزارهای کاربردی و عملکرد و وقایع هر نرم‌افزار و تعاملات و ارتباطات بین آنها

· در صورت نیاز ذینفعان به مدل‌سازی جزئیات معماری نرم‌افزارهای کاربردی موارد دیگر نیز مدل می‌شوند، شامل:

· مدل‌کردن جزئیات نرم‌افزارهای شی‌گرا و تعیین کلاس‌ها، مولفه‌ها و اشیاء و تعیین ارتباطات و تعاملات و متدهای مربوطه

· مدل‌سازی جزئیات معماری نرم‌افزارهای سرویس‌گرا و تعیین سرویس‌ها و مولفه‌ها و ارتباطات و تعاملات و متدهای مربوطه

· مدل‌سازی جزئیات معماری نرم‌افزارهای عامل‌گرا و تعیین عامل‌ها و مولفه‌ها و ارتباطات و تعاملات و متدهای مربوطه

3-6-3- مرحله مدل‌سازی معماری زیرساخت فناوری

· مدل‌سازی سرویس‌های زیرساختی و ارتباطات و تعاملات بین آنها

· مدل‌سازی فناوری‌ها و استانداردهای زیرساختی

· مدل‌سازی نودها، دستگاه‌ها و تجهیرات شبکه‌ای و ارتباطات و تعاملات بین آنها

· در صورت نیاز ذینفعان به مدل‌سازی جزئیات معماری نرم‌افزارهای کاربردی موارد دیگر نیز مدل می‌شوند، شامل:

· مدل‌کردن وقایع زیرساختی

· مدل‌سازی جزئیات مراکز داده‌ای و اتاق‌های سرور

3-7- مرحله یکپارچه‌سازی مدل‌ها

در این مرحله مدل‌های تهیه شده در مراحل قبل در قالب بلوک‌ها یا بسته‌های مرتبط با هم با قابلیت استفاده مجدد ادغام و یکپارچه می‌شوند. سپس مدل‌های یکپارچه شده در مخزن معماری درج و طبقه‌بندی می‌شوند. مدل‌های زاید و غیرقابل‌استفاده نیز از مخزن معماری حذف می‌شوند.

4- روش ارزیابی

در این مقاله ارزیابی به روش ترکیبی انجام می‌شود. مرسوم است که راه‌حل‌های ارائه شده در حوزه معماری سازمانی به خصوص در حوزه مدل‌سازی معماری سازمانی از طریق ارائه مطالعات موردی، بررسی و ارزیابی شوند. انجام یک مطالعه موردی¹ از طریق راه‌حل ارائه شده نشان خواهد داد که روش ارائه شده تا چه حد، می‌تواند در یک محک واقعی کاربردپذیری خود را بروز دهد. مطالعه موردی طبق روش مدل‌سازی معماری سازمانی چابک ارائه شده در بخش 3 در یک سازمان ایرانی انجام می‌شود. از آنجاییکه روش کیفی از طریق ارائه مطالعه موردی لازم بوده ولی کافی نیست لذا با استفاده از روش فرآیند تحلیل سلسله مراتبی (AHP) که یکی از روش‌های تصمیم گیری چند معیاره است، ارزیابی کمی طبق نظر خبرگان انجام می‌شود]56[ و ]57[.

مراحل قابل انجام با استفاده از روش AHP عبارتند از:

· تعیین تعدادی شاخص تاثیرگذار در مدل‌سازی معماری سازمانی چابک با استفاده از منابع کتابخانه‌ای و نظر خبرگان

· تعیین هدف تصمیم‌گیری

· انجام مقایسات زوجی شاخص‌ها توسط خبرگان

· انجام محاسبات وزنی برای تعیین اولویت شاخص‌ها

· ادغام وزن‌های نسبی به منظور رتبه‌بندی شاخص‌ها

· محاسبه نرخ ناسازگاری جهت تعیین قابل قبول بودن مقایسات

5- ارزیابی و تجزیه و تحلیل داده‌ها

5-1- ارزیابی کیفی

مطالعه موردی بر اساس روش پیشنهادی در شرکت مخابرات ایران انجام شده که خلاصه گزارش آن به شرح زیر است:

· مرحله برنامه‌ریزی مدل‌سازی چابک

برای انجام معماری به وضعیت مطلوب² آن توجه شده و از وضعیت موجود³ صرف نظر گردیده است. اداره تحول و توسعه پرتال‌های سازمانی که یکی از گلوگاه‌های سازمان است به عنوان نقطه شروع و محدوده اولیه معماری انتخاب گردید. سه تکرار پانزده روزه با هدف تولید و بروزرسانی مدل‌های معماری وضعیت مطلوب به صورت تکاملی و تدریجی تعریف شدند. طبق نظر و توافق ذینفعان برای تولید مدل‌ها از ترکیب دو نرم‌افزار MS Visio و Enterprise Architect استفاده گردید.

· مرحله مدل‌سازی نیازمندی‌های معماری )وظیفه‌مندی و غیروظیفه‌مندی(

در این مرحله، برای جمع‌آوری نیازمندی‌های معماری اعم از وظیفه‌مندی و غیر وظیفه‌مندی از روش‌های نمونه‌سازی اولیه، مشاهده، مصاحبه حضوری، جلسات گروهی و نظرسنجی استفاده شد. مطابق شکل 3 و با توجه به راه‌حل پیشنهادی، نیازمندی‌های حوزه بازاریابی و فروش غیرحضوری محصولات و خدمات مخابراتی استخراج و مدل شده‌اند. نیازمندی‌های وظیفه‌مندی و غیر وظیفه‌مندی تفکیک شده‌اند و به ازای هر کدام استوری‌های مربوطه استخراج و شماره گذاری شده‌اند. امنیت و دسترس پذیری نیازمندی‌های غیروظیفه مندی و فروش محصولات خانگی و تجاری مخابراتی به شکل غیرحضوری نیازمندی‌های وظیفه‌مندی استخراج‌شده در تکرارهای برنامه‌ریزی شده هستند. استوری‌های شماره 2، 8 و 9 توسط ذینفعان با اولویت بالا شناخته شده و نیاز به جزئیات مدل‌سازی برای آنها اعلام شده است که در شکل 3 مشخص شده‌اند.

· مرحله مدل‌سازی سطح بالای معماری

در این مرحله، لایه‌های کلان معماری شامل لایه چشم‌انداز و استراتژی، لایه کسب‌وکار، لایه داده، لایه نرم‌افزارهای کاربردی،

لایه فناوری و لایه مدیریت نیازمندی‌ها مطابق شکل 4 مدل گردیدند.

· مرحله مدل‌سازی چشم‌انداز معماری

در این مرحله، با توجه به راه‌حل پیشنهادی و بر اساس مستند استراتژیکی سازمان، مدل چشم‌انداز معماری شامل بیانیه چشم‌انداز، بیانیه ماموریت، هدف، مقصد، استراتژی‌ها و تاکتیک مطابق شکل 5 تدوین گردید. برای مدل‌سازی بیانیه چشم‌انداز، بیانیه ماموریت، هدف و مقصد از عنصر Goal استاندارد ArchiMate و برای مدل‌سازی استراتژی‌ها و تاکتیک‌ها نیز از عنصر Outcome استاندارد ArchiMate استفاده شد. ضمن اینکه برای دسته‌بندی نیز از عناصر Vision، Mission، Goal، Objective، Strategy و Tactic استاندارد BMM استفاده شد. برای مدل‌سازی ذینفعان نیز از عنصر Stakeholder استاندارد ArchiMate و برای مدل کردن دغدغه‌های ذینفعان از عنصر Driver استاندارد ArchiMate استفاده شد. از بکارگیری سایر عناصر استانداردهای ArchiMate و BMM صرف نظر شد. متن توضیحات مدل چشم‌انداز معماری کوتاه در نظر گرفته شده و از بیان توضیحات زیاد صرف نظر گردید.

· مرحله مدل‌سازی معماری کسب‌وکار

در این مرحله، با توجه به روش پیشنهادی و نیازمندی‌های جمع‌آوری شده مدل معماری کسب‌وکار تدوین گردید. برای مدل‌سازی کسب کار از عناصر کسب‌وکار استاندارد ArchiMate شامل: Business Actor، Business Interface، Business Event، Business Function، Business Process، Business Role و Business Collaboration استفاده گردیده و از بکارگیری سایر عناصر این استاندارد صرف نظر گردید. مدل معماری کسب‌وکار در شکل 6 نمایش داده شده است.

با توجه به نیاز و دغدغه‌های ذینفعان در خصوص مدل‌سازی جزئیات «تکمیل فرم درخواست» مطابق شکل 7 مدل‌سازی جزئیات فرآیند کسب‌وکار آن با عناصر استاندارد BPMN شامل: Pool، Lane، Activity، Gateway، Event و DataStore انجام گردید. از بکارگیری سایر عناصر استاندارد BPMN صرف نظر گردید.

[1] Case Study

[2] To Be

[3] AS IS

شکل 3. مدل نیازمندی‌های معماری

شکل 4. مدل سطح بالای معماری

شکل 5. مدل چشم‌انداز معماری

شکل 6. مدل معماری کسب‌وکار

شکل 7. مدل جزئیات کسب‌وکار فرآیند «تکمیل فرم درخواست» از خرید تلفن ثابت

با توجه به شکل 7 فعالیت «بررسی فرم درخواست» دارای قوانین و تصمیم‌هایی است که با توجه به نیاز و دغدغه‌های ذینفعان با جزئیات مدل گردید. برای مدل‌سازی آن از عناصر استاندارد DMN شامل: Decision، Business Knowledge، Input Data استفاده گردید. در شکل 8 مدل جزئیات قوانین کسب‌وکار فعالیت «بررسی فرم درخواست» نشان داده شده است. از بکارگیری سایر عناصر استاندارد DMN صرف نظر گردید.

· مرحله مدل‌سازی معماری داده

این مرحله یکی از مراحل مدل‌سازی معماری فناوری اطلاعات است. در این مرحله با توجه به روش پیشنهادی و نیازمندی‌های معماری با استفاده از عنصر Class استاندارد UML مدل معماری داده ترسیم گردید. عنصر Class استاندارد UML به پیمانکاران کمک می‌کند که به سرعت بتوانند مدل پایگاه داده‌ای و شئ‌گرا را ایجاد کرده و توسعه دهند. مدل معماری داده در شکل 9 نشان داده شده است.

شکل 8. مدل قوانین و تصمیم‌های بررسی فرم درخواست از فرآیند خرید تلفن ثابت

شکل 9. مدل معماری داده

· مرحله مدل‌سازی معماری نرم‌افزارهای کاربردی

این مرحله نیز یکی از مراحل مدل‌سازی معماری فناوری اطلاعات است. در این مرحله با توجه به روش پیشنهادی و نیازمندی‌های معماری مدل معماری نرم‌افزارهای کاربردی تدوین گردید. برای مدل‌سازی این لایه از عناصر استاندارد ArchiMate شامل: ApplicationComponent، ApplicationService، ApplicationEvent، ApplicationInteraction و ApplicationInterface استفاده گردید. از بکارگیری سایر عناصر استاندارد ArchiMate صرف نظر گردید. مدل معماری نرم‌افزارهای کاربردی در شکل 10 نمایش داده شده است.

· مرحله مدل‌سازی معماری زیرساخت فناوری

این مرحله نیز یکی از مراحل مدل‌سازی معماری فناوری اطلاعات است. در این مرحله با توجه به روش پیشنهادی و نیازمندی‌های معماری مدل معماری زیرساخت فناوری تدوین گردید. برای مدل‌سازی این لایه از عناصر استاندارد ArchiMate شامل: TechnologyInterface، CommunicationNetwork، Device، SystemSoftware و Groupingاستفاده گردید. از بکارگیری سایر عناصر استاندارد ArchiMate صرف نظر گردید. مدل معماری زیرساخت فناوری در شکل 11 نمایش داده شده است.

· مرحله یکپارچه سازی مدل‌ها

در این مرحله، مدل‌های تولید شده با هم در قالب شکل 4 ادغام گردیدند.

شکل 10. مدل معماری نرم‌افزارهای کاربردی

شکل 11. مدل معماری زیرساخت فناوری

5-2- ارزیابی کمی

جامعه آماری تحقیق محدود و شامل دوازده خبره در دسترس مدل‌سازی معماری سازمانی چابک است که به روش نمونه‌گیری گلوله‌برفی و روش نمونه‌گیری قضاوتی انتخاب گردیدند. ابزار جمع‌آوری داده‌ها، پرسشنامه و مصاحبه با خبرگان هستند. طبق منابع کتابخانه‌ای و تایید خبرگان، شش شاخص به شرح زیر استخراج گردیدند:

1. تولید فرآورده‌های مورد نیاز و ضروری ]1[ و ]4[ و ]5[

2. کاهش زمان مدل‌سازی ]1[ و ]3[

3. کاهش هزینه ]3[

4. بهبود رضایت ذینفعان ]1[ و ]3[

5. بهبود کاربردپذیری ]23[

6. افزایش سادگی ]1[ و ]2[

هدف این است که ببینیم از نظر خبرگان، راه‌حل پیشنهادی هر کدام از شاخص‌های ارزیابی را با چه وزن و رتبه‌ای محقق نموده است. برای انجام محاسبات از نرم‌افزارهای اکسل¹ و سوپردسیژن² استفاده شد. ابتدا مقایسات زوجی شاخص‌های ارزیابی توسط خبرگان انجام گردید. اين كار با انجام مقايسات دو به دو بين عناصر تصميم (مقايسه زوجي) و از طريق تخصيص امتيازات عددي كه نشان دهنده ارجحيت يا اهميت بين دو عنصر تصميم است، صورت مي‌گيرد. براي انجام اين كار معمولا از مقايسه گزينه‌ها با شاخص‌هاي i ام نسبت به گزينه‌ها يا شاخص‌هاي j ام استفاده مي‌شود كه در جدول 1 نحوه ارزش‌گذاري شاخص‌ها نسبت به هم نشان داده شده است.

در مرحله بعد مقایسات زوجی انجام شده توسط خبرگان با روش میانگین هندسی ادغام شدند که حاصل آن در جدول 2 نمایش داده شده است.

در مرحله بعد نرمال‌سازی انجام شده است. برای نرمال‌سازی مقایسات زوجی هر درایه را بر مجموع درایههای ستونش تقسیم می‌کنیم. ماتریس نرمال شده در جدول 3 نمایش داده شده است.

[1] MS Excel

[2] Super Decision

جدول 1. طیف 9 تایی عبارات کلامی روش AHP

ارزش ترجيحي	وضعيت مقايسه i نسبت به j	توضيح
1	اهميت برابر	گزينه يا شاخص i نسبت به j اهميت برابر دارند و يا ارجحيتي نسبت به هم ندارند.
3	نسبتاً مهم‌تر	گزينه يا شاخص i نسبت به j كمي مهمتر است.
5	مهم‌تر	گزينه يا شاخص i نسبت به j مهمتر است.
7	خيلي مهم‌تر	گزينه يا شاخص i داراي ارجحيت خيلي بيشتري از j است.
9	كاملاً مهم	گزينه يا شاخص مطلقاً i از j مهمتر و قابل مقايسه با j نيست.
2و4و6و8		ارزش‌هاي مياني بين ارزش‌هاي ترجيحي را نشان مي‌دهد.

جدول 2. مقایسات زوجی شاخص‌ها

	تولید فرآورده‌های مورد نیاز و ضروری	کاهش زمان مدل‌سازی	کاهش هزینه	بهبود رضایت ذینفعان	بهبود کاربردپذیری	افزایش سادگی
تولید فرآورده‌های مورد نیاز و ضروری	1	1.790	1.817	1.179	1.279	1.730
کاهش زمان مدل‌سازی	0.559	1	0.913	0.985	0.798	1.015
کاهش هزینه	0.550	1.096	1	1.490	0.896	0.949
بهبود رضایت ذینفعان	0.848	1.015	0.671	1	1.015	1.207
بهبود کاربردپذیری	0.782	1.253	1.116	0.985	1	1.249
افزایش سادگی	0.578	0.985	1.054	0.828	0.801	1

جدول 3. مقایسات نرمال

	تولید فرآورده‌های مورد نیاز و ضروری	کاهش زمان مدل‌سازی	کاهش هزینه	بهبود رضایت ذینفعان	بهبود کاربردپذیری	افزایش سادگی
تولید فرآورده‌های مورد نیاز و ضروری	0.232	0.251	0.277	0.182	0.221	0.242
کاهش زمان مدل‌سازی	0.129	0.140	0.139	0.152	0.138	0.142
کاهش هزینه	0.127	0.154	0.152	0.230	0.155	0.133
بهبود رضایت ذینفعان	0.197	0.142	0.102	0.155	0.175	0.169
بهبود کاربردپذیری	0.181	0.176	0.170	0.152	0.173	0.175
افزایش سادگی	0.134	0.138	0.160	0.128	0.138	0.140

در مرحله بعد وزن شاخص‌ها محاسبه گردید. برای محاسبه وزن شاخص‌ها از درایههای جدول 3 به صورت سطری میانگین حسابی گرفته شد. نتیجه در جدول 4 نمایش داده شده است.

با توجه به جدول 4، شاخص تولید فرآورده‌های مورد نیاز و ضروری با وزن 0.234 اولویت اول را کسب کرده است. شاخص‌های بهبود کاربردپذیری و کاهش هزینه به ترتیب با اوزان 0.171 و 0.159 اولویتهای دوم و سوم را کسب کرده‌اند. در شکل 12 وزن شاخص‌های ارزیابی نمایش داده شده است.

در مرحله آخر نرخ ناسازگاری مقایسه‌های زوجی جهت تعیین قابل قبول بودن مقایسه‌ها محاسبه گردید. وقتيكه تعداد مقايسه‌ها افزايش يابد اطمينان از سازگاري آن‌ها به راحتي ميسر نبوده و بايد با به كارگيري نرخ سازگاري به اين اعتماد دست يافت.

جدول 4. وزن شاخص‌ها

شاخص	وزن
تولید فرآورده‌های مورد نیاز و ضروری	0.234
کاهش زمان مدل‌سازی	0.140
کاهش هزینه	0.159
بهبود رضایت ذینفعان	0.157
بهبود کاربردپذیری	0.171
افزایش سادگی	0.140

تجربه نشان داده است كه اگر نرخ ناسازگاري كمتر از 10/0 باشد سازگاري مقايسه‌ها قابل قبول بوده و در غير اين صورت مقايسه‌ها بايد تجديد نظر شوند. مراحل زير براي محاسبه نرخ ناسازگاري انجام گردیدند:

· ماتريس مقايسه‌های زوجي در بردار ستوني «وزن نسبي» ضرب گردیده و بردار جديدي با عنوان بردار مجموع وزني¹ ایجاد گردید.

· عناصر بردار مجموع وزني بر بردار اولويت نسبي تقسيم گردیده و بردار سازگاري² ایجاد گردید.

· ميانگين عناصر بردار سازگاري محاسبه و بر اساس آن پارامتر lmax به دست آمد.

· شاخص سازگاري طبق رابطه 1 محاسبه گردید. n تعداد شاخص‌ها بوده که برابر 6 می‌باشد.

(1)

· نسبت سازگاري از تقسيم شاخص سازگاري بر شاخص تصادفي ³ طبق رابطه 2 به دست آمد. شاخص تصادفي از جدول 5 استخراج گردید.

(2)

[1] Weighted Sum Vector = WSV

[2] Consistency Index = CI

[3] Random Index = RI

شکل 12. وزن شاخص‌های ارزیابی

جدول 5. شاخص سازگاری تصادفي (RI)

15	14	13	12	11	10	9	8	7	6	5	4	3	2	n
1.59	1.57	1.56	1.48	1.51	1.49	1.45	1.41	1.32	1.24	1.12	0.9	0.58	0	RI

محاسبات نهایی نرخ ناسازگاری طبق مراحل قبل در جدول 6 نمایش داده شده است. نتایج نشان میدهد که نرخ ناسازگاری (RI) برابر با 0.009 بوده (که کمتر از 0.1 است) و نشان دهنده سازگاری قابل قبول مقایسه‌های زوجی انجام شده است.

6- بحث و تحلیل

در معماری سازمانی چابک مدل‌ها و مستندات به اندازه و به مقدارکافی تولید می‌شوند. روش‌ها و چارچوب‌هایی برای مدل‌سازی معماری سازمانی چابک ارائه شده‌اند که هر کدام دارای نواقصی هستند. در این مقاله روشی برای مدل‌سازی معماری سازمانی چابک جهت پوشش نواقص روش‌های موجود ارائه گردید. مطابق شکل 1 روش پیشنهادی و مراحل انجام آن پیشنهاد گردید. در روش پیشنهادی مدل‌سازی همه لایه‌های معماری در نظر گرفته شده است. مدل‌سازی بر وضعیت مطلوب و گلوگاه‌های سازمان متمرکز گردیده است. وضعیت موجود و سایر محدوده‌ها در صورت نیاز و دغدغه ذینفعان مدل می‌شوند. در روش پیشنهادی، مدل‌سازی به شکل تدریجی و از طریق تعریف تکرارها و با بکارگیری ابزارهای ساده صورت می‌گیرد. انتخاب ابزارها مطابق نظر ذینفعان معماری انجام می‌شود. طبق روش پیشنهادی و مطابق شکل 2 نیازمندی‌های معماری با روش‌های سریع از جمله مصاحبه و مشاهده جمع‌آوری و در قالب موضوع، ابتکار، اپیک و استوری مدل می‌شوند. نیازمندی‌ها توسط ذینفعان اولویت‌بندی شده و میزان جزئیات لازم برای مدل‌سازی آنها تعیین می‌شوند. در مرحله مدل‌سازی سطح بالای معماری، لایه‌های کلان معماری مدل می‌شوند. در مرحله مدل‌سازی چشم‌انداز معماری، تاکید بر مدل‌سازی اهداف و مدل‌سازی ذینفعان قرار گرفت و سایر موارد در صورت نیاز ذینفعان مدل می‌گردند و در غیر این صورت از مدل‌سازی آنها صرف نظر می‌شود. در مرحله مدل‌سازی معماری کسب‌وکار نیز تمرکز بر مدل‌سازی کنشگران، کارکردها، فرآیندها و سرویس‌های کسب‌وکار و ارتباطات بین آنهاست و سایر موارد در صورت نیاز ذینفعان مدل می‌گردند و در غیر این صورت از مدل‌سازی آنها صرف نظر می‌شود. در مرحله مدل‌سازی معماری داده، تاکید بر مدل‌سازی کلاس‌ها و جداول داده‌ای است تا به سرعت مورد بهره‌برداری پیمانکاران، طراحان و برنامه‌نویسان قرار بگیرد. در مرحله مدل‌سازی معماری نرم‌افزارهای کاربردی تمرکز بر مدل‌کردن کردن نرم‌افزارهای کاربردی و عملکرد و وقایع هر نرم‌افزار و تعاملات و ارتباطات بین آنها است. در صورت نیاز ذینفعان جزئیات معماری‌های شئ‌گرا، سرویس‌گرا و عامل‌گرا مدل می‌شوند و در غیر این صورت از مدل‌سازی جزئیات مربوطه صرف نظر می‌شود. در مرحله مدل‌سازی معماری زیر ساخت فناوری نیز تمرکز بر مدل‌سازی سرویس‌های زیرساختی، نودها، دستگاه‌ها و تجهیرات شبکه‌ای و ارتباطات و تعاملات بین آنها است و سایر موارد در صورت نیاز ذینفعان مدل می‌شوند. در نهایت در مرحله آخر مدل‌های تولید شده یکپارچه می‌گردند. در بخش چهارم روش ترکیبی(کیفی + کمی) برای ارزیابی روش پیشنهادی مطرح گردید. روش کیفی از طریق ارائه یک مطالعه موردی در یک سازمان ایرانی انجام پذیرفت. مدل‌های تولید شده به ازای مراحل روش پیشنهادی در شکل‌های 3 تا 11 نشان داده شده‌اند. در ارزیابی کمی با استفاده از روش AHP و طبق نظر دوازده خبره در دسترس، شش شاخص ارزیابی وزن‌دهی و اولویت‌بندی شدند. پرسشنامه مقایسات زوجی مطابق جدول 1 توسط خبرگان تکمیل گردید. برای انجام محاسبات ارزیابی از نرم‌افزارهای اکسل و سوپردسیژن استفاده شد. بر این اساس و طبق نظر خبرگان شاخص‌های تولید فرآورده‌های مورد نیاز و ضروری، بهبود کاربردپذیری، کاهش هزینه، بهبود رضایت ذینفعان، کاهش زمان مدل‌سازی و افزایش سادگی به ترتیب توسط روش پیشنهادی در این مقاله محقق شده‌اند. این اولویت‌بندی در شکل 12 نمایش داده شده است. روش پیشنهادی دارای جامعیت بوده زیرا همه لایه‌های معماری سازمانی را تحت پوشش قرار داده است. ضمن اینکه طبق شکل 1 مراحل انجام نیز مشخص شده‌اند.

جدول 6. نرخ ناسازگاری مقایسه‌های زوجی

شاخص	λ	λmax	I.I	R.I. I	R. I
تولید فرآورده‌های مورد نیاز و ضروری	6.059	6.054	0.011	1.24	0.009
کاهش زمان مدل‌سازی	6.054
کاهش هزینه	6.057
بهبود رضایت ذینفعان	6.041
بهبود کاربردپذیری	6.053
افزایش سادگی	6.059

ارزیابی کیفی نشان می‌دهد که ضمن استفاده از استانداردهای مدل‌سازی نظیر ArchiMate، UML، BPMN، DMN و BMM از همه عناصر آنها استفاده نشده بلکه نوعی کمینه‌سازی در استفاده از عناصر اعمال شده است. بر این اساس همه فرآورده‌های معماری نیز تولید نشده‌اند بلکه طبق روش پیشنهادی و نظر ذینفعان مهمترین آنها تولید شده‌اند. در روش پیشنهادی بر استفاده از روش‌های عملی چابک نظیر برنامه‌ریزی تکرار، اولویت‌بندی نیازمندی‌ها، استفاده از اپیک و استوری برای مدل‌سازی نیازمندی‌ها، برنامه‌ریز تکرار و استفاده از ابزارهای ساده تاکید شده است. در مطالعه موردی انجام پذیرفته طبق نظر ذینفعان از ابزارهای مدل‌سازی EA و Visio استفاده شد که سبب افزایش سرعت و بهبود رضایت ذینفعان گردید زیرا این دو ابزار مورد تایید آنان بوده است. همچنین تاکید و تمرکز بر مدل‌سازی وضعیت مطلوب و گلوگاه‌های سازمان سبب افزایش سرعت مدل‌سازی و کاهش حجم فرآورده‌ها و هزینه‌های تولید مدل‌ها گردید. ارزیابی کمی نیز نشان می‌دهد که طبق نظر خبرگان روش پیشنهادی در تولید فرآورده‌های مورد نیاز و ضروری موفق بوده است. همچنین در خصوص سایر شاخص‌های ارزیابی مدل‌سازی معماری سازمانی چابک یعنی بهبود کاربردپذیری، کاهش هزینه‌های تولید و بروزرسانی مدل‌ها، بهبود رضایت ذینفعان، کاهش زمان مدل‌سازی و افزایش سادگی، روش پیشنهادی موفق عمل نموده است. بدیهی است روش پیشنهادی در این مقاله تمام ابعاد و ویژگی‌های یک متدولوژی چابک را تبیین نمی‌کند و لذا نیاز است با روش‌های چابک دیگر ترکیب و بهره‌ برداری گردد.

7- نتیجه گیری

در این مقاله روشی برای مدل‌سازی معماری سازمانی چابک ارائه گردید و به روش ترکیبی مورد بررسی و ارزیابی قرار گرفت. روش‌ها و چارچوب‌های ارائه شده برای مدل‌سازی معماری سازمانی چابک دارای نواقصی هستند. در روش پیشنهادی در این مقاله هدف بر این بود که نواقص موجود پوشش داده شوند. راه‌حل ارائه شده در این مقاله مدل‌سازی همه لایه‌های معماری سازمانی را در نظر گرفته و به شکل تدریجی در قالب تکرارها، فرآورده‌های ضروری را تولید می‌نماید. در روش پیشنهادی این مقاله بر مدل‌سازی استاندارد تاکید شده ولی از همه عناصر آنها استفاده نمی‌شود. در روش پیشنهاد شده تمرکز مدل‌سازی بر وضعیت مطلوب و گلوگاه‌های سازمان است. وضعیت موجود معماری و نقاط عادی در صورت نیاز و دغدغه‌ی ذینفعان مدل می‌شوند. در روش ارائه شده بر بکارگیری تجارب عملی چابک، از جمله اولویت‌بندی نیازمندی‌ها، برنامه‌ریزی تکرار، استفاده از اپیک و استوری برای جمع آور نیازمندی‌ها، بکارگیری ابزارهای ساده برای مدل‌سازی و استفاده از روش‌های سریع جمع‌آوری نیازمندی‌ها تاکید شده است.

این مقاله همه ابعاد معماری سازمانی چابک پوشش قرار نمی‌دهد و لذا لازم است با سایر روش‌های چابک ترکیب گردد. روش ارائه شده در این مقاله به شکل ترکیبی (کیفی + کمی) مورد ارزیابی قرار گرفت. در روش کیفی مدل‌های نمونه برای لایه‌های مختلف معماری ترسیم و نشان داده شدند. نیازمندی‌های معماری با روش‌های سریع جمع‌آوری شده و به شکل تکرار پذیر در قالب موضوع، ابتکار، اپیک و استوری مدل گردیدند. برای مدل‌سازی از نرم‌افزارهای Enterprise Architect و MS Visio استفاده شد.

در روش کمی با استفاده از روش تصمیم‌گیری چند معیاره AHP و نرم‌افزارهای اکسل و سوپردسیژن ارزیابی انجام پذیرفت. تعداد شش شاخص چابکی با بررسی منابع کتابخانه‌ای استخراج و به تایید دوازده نفر خبره در دسترس مدل‌سازی معماری سازمانی چابک رسیدند. هدف از ارزیابی این بود که ببینیم از نظر خبرگان، راه‌حل پیشنهادی هر کدام از شاخص‌های ارزیابی را با چه وزن و رتبه‌ای محقق نموده است. که بر اساس نتایج حاصل شده شش شاخص، تولید فرآورده‌های مورد نیاز و ضروری، بهبود کاربردپذیری، کاهش هزینه، بهبود رضایت ذینفعان، کاهش زمان مدل‌سازی و افزایش سادگی به ترتیب وزن‌دهی و اولویت‌بندی گردیدند. در نهایت پیشنهادات برای پژوهش‌های آتی عبارتند از:

· برای مدل‌سازی نیازمندی‌های معماری روش‌های دیگر از جمله نمودار مورد کاربری(Use Case Diagram) در استاندارد UML و نمودار نیازمندی(Requirement Diagram) از استاندارد SysML مورد بررسی قرار گرفته و با روش ارائه شده در این مقاله مقایسه گردند.

· مدل‌سازی پیشامدها در معماری کسب‌وکار به روش پیشنهادی در این مقاله اضافه شود. عناصر استاندارد CMMN شامل: Case Plan Model، Task، Stage، Milestone، Event، Case File Item، Discretionary و ... جهت پوشش پیشامدها مورد بررسی قرار گیرند.

· برای مدل‌سازی اهداف (Goals Modeling) روش‌های دیگر مورد بررسی قرار گرفته و با روش ارائه شده در این مقاله مقایسه گردند.

· کارایی و قابلیت اطمینان روش ارائه شده با روش‌هایی نظیر شبکه‌های پتری و نظریه صف ارزیابی گردند.

مراجع

[1] Manifesto for Agile Software Development, 2001, <https://agilemanifesto.org/>.

[2] Scott W. Ambler. Agile Enterprise Architecture, 2021, <http://agiledata.org/essays/enterpriseArchitecture.html>.

[3] Scott W. Ambler. Agile Modeling: Effective Practices for extreme Programming and the Unified Process, Published by John Wiley & Sons, Inc., New York, 2002, <http://msoo.pbworks.com/f/Scott+W.+Ambler+-+Agile+Modeling.pdf>.

[4] Scott W. Ambler. The Agile Modeling, 2022, <https://agilemodeling.com>.

[5] Enterprise Architecture on a Page, 2023, <http://eaonapage.com/>.

[6] P. Medeiros, A. Santana, M. Lima, H. Moura, M.s, “An Agile Approach for Modeling Enterprise Architectures,” 23rd International Conference on Enterprise Information Systems, April 26–28, 2021.

[7] M. Hauder, S. Roth, C. Schulz, F. Matthes, “Agile Enterprise Architecture Management an Analysis on the Application of Agile Principles,” The Fourth International Symposium on Business Modeling and Software Design, June 24–26, 2014.

[8] H. M. Shirazi, B. D. Rouhani, M. M. Shirazi, “A Framework for Agile Enterprise Architecture,” International Journal of Intelligent Information Technology Application., vol. 2, Issue. 4, pp. 182-186, 2009.

[9] Z. A. Amiri, “CHALLENGES AND WEAKNESSES OF AGILE METHOD IN ENTERPRISE ARCHITECTURE,” International Journal of Computer Science & Engineering Survey (IJCSES)., vol. 3, No. 6, pp. 37-45, 2012.

[10] S. Buckl, F. Matthes, I. Monahov, S. Roth, C. Schulz, C. M. Schweda, “Towards an Agile Design of the Enterprise Architecture Management Function,” 15th IEEE International Enterprise Distributed Object Computing Conference Workshops, Aug. 29 - Sept. 2, 2011, Helsinki, Finland.

[11] A. Rasnacis, S. Berzisa, “Method for Adaptation and Implementation of Agile Project Management Methodology,” Procedia Computer Science., vol. 104, pp. 43-50, 2017.

[12] T. Kaddoumi, M. Watfa, “A Proposed Agile Enterprise Architecture Framework,” Sixth International Conference on Innovative Computing Technology (INTECH), Aug. 24-26, 2016, Dublin, Ireland.

[13] J. Werewka, A. Spiechowicz, “Enterprise Architecture Approach to SCRUM Processes, Sprint Retrospective Example,” Computer Science and Information Systems., vol. 11, pp. 1221-1228, 2017.

[14] OMG, ArchiMate 3.2, 2022, <https://pubs.opengroup.org/architecture/archimate3-doc/>.

[15] OMG, Unified Modeling Language 2.5 (UML), 2015, <http://www.omg.org/spec/UML/>.

[16] OMG, Business Process Model and Notation 2.0.2 (BPMN), 2013, <http://www.omg.org/spec/BPMN/index.htm>.

[17] G. Beydoun, G. Low, B. Henderson-Sellers, H. Mouratids, J.J. Gomez-Snaz, J. Pavon, C. Gonzalez-Perez, “FAML: a generic metamodel for MAS development,” IEEE Trans. Softw. Eng., vol. 35, Issue 6, pp. 841–863, Nov-Dec 2009.

[18] OMG, Service Oriented Architecture Modeling Language 1.0.1 (SoaML), 2012, <http://www.omg.org/spec/SoaML/>.

[19] OMG, Business Motivation Model 1.3(BMM), 2015, <http://www.omg.org/spec/BMM/>.

[20] OMG, Decision Model and Notation 1.4 (DMN), 2022, <http://www.omg.org/spec/DMN/>.

[21] OMG, Case Management Model and Notation 1.1(CMMN), 2016, <http://www.omg.org/spec/CMMN/>.

[22] OMG, Systems Modeling Language 1.5(SYSML), 2017, <http://www.omg.org/spec/SysML/>.

[23] A.Q. Gill, "agile enterprise architecture modelling: Evaluating the applicability and integration of six modelling standards," Information and Software Technology, vol. 67, pp. 196-206, November 2015.

[24] راضی، علی، رضایی، رضا، یزدان پناه، احمد علی، "مدل‌سازی معماری سازمانی چابک: ارزیابی کاربردپذیری شش استاندارد مدل‌سازی بر مبنای چارچوب ملی معماری سازمانی ایران"، دو فصلنامه علمی فناوری اطلاعات و ارتباطات ایران، شماره‌های 47 و 48، 105_ 135، تهران، بهار و تابستان 1400.

[25] S. Yamamoto, Q. Zhia, Z. Zhoua, “Aspect Analysis towards ArchiMate Diagrams,” Procedia Computer Science., vol. 159, pp. 973-980, 2019.

[26] A. Buchalcevova, “Using ArchiMate to model ISO/IEC 29110 standard for very small entities,” Computer Standards & Interfaces., vol. 65, pp. 103-121, 2019.

[27] A. Zrnec, M. Bajec, M. Krisper, "Enterprise modelling with UML," Elektrotehni ski vestnik University of Ljubljana., vol. 68, pp. 109–114, 2001.

[28] F. Armour, S. H. Kaisler, J. Getter, D. Pippin, “A UML-driven Enterprise Architecture Case Study,” Proceedings of the 36th Annual Hawaii International Conference, February, 2003.

[29] H. Takeuchi, S. Yamamoto, “AI Service System Development Using Enterprise Architecture Modeling,” Procedia Computer Science., vol. 159, pp. 923-932, 2019.

[30] S. Yamamoto, “Analysis of Smart City Reference Architecture by ArchiMate,” Procedia Computer Science., vol. 207, pp. 514-521, 2022.

[31] A. Aldea, M.E. Iacob, J.V Hillegersberg, D. Quartel, L. Bodenstaff, H. Franken, “Modelling strategy with ArchiMate,” Proceedings of the 30th Annual ACM Symposium on Applied Computing, Apr 13-17, 2015, Salamanca, Spain.

[32] F. C. Kitsios, M. Kyriakopoulou, M. Kamariotou, “Exploring Business Strategy Modelling with ArchiMate: A Case Study Approach,” Department of Applied Informatics, University of Macedonia, 2022.

[33] P. Bhattacharya, “Modelling Strategic Alignment of Business and IT through Enterprise Architecture: Augmenting ArchiMate with BMM,” Procedia Computer Science., vol. 121, pp. 80-88, 2017.

[34] The TOGAF® Standard,10th Edition, 2023, <https://www.opengroup.org/togaf/10thedition>.

[35] Open Agile Architecture, A Standard of The Open Group, 2020, <https://pubs.opengroup.org/architecture/o-aa-standard-single>.

[36] شمس علیئی، فریدون. مهجوریان، امیر و همکاران. چارچوب و روش شناسی معماری سازمانی ایران، نسخه 1، شورای اجرایی)عالی( فناوری اطلاعات کشور، کمیسیون توسعه دولت الکترونیکی، تهران، 1395، https://www.ieaf.ir/.

[37] M. Pankowska, “Business to System Requirements Agile Mapping,” 17th International Conference on e-Business and Telecommunications, July 8 - 10,2020.

[38] A. Sadovykh, P. Desfray, B. Elvesæter, A. Berre, E. Landre, “Enterprise architecture modeling with SoaML using BMM and BPMN - MDA approach in practice,” Computer Science, 6th Central and Eastern European Software Engineering Conference, Oct 13-15, 2010, Moscow, Russia.

[39] M. Pankowska, “Business Models in CMMN, DMN and ArchiMate language,” Procedia Computer Science., vol. 164, pp. 11-18, 2019.

[40] M.D. Leoni, P. Felli, M. Montali, “Integrating BPMN and DMN: Modeling and Analysis,” Journal on Data Semantics., vol. 10, pp. 165-188, June, 2021.

[41] P. Desfray, G. Raymond, Modeling Enterprise Architecture with TOGAF® A Practical Guide Using UML and BPMN. Morgan Kaufmann; 1st edition, 2014.

[42] B. Ding, T. Wu, Y. Yang, L. Dou, T. Jin, “ArchiMate Customization and Architecture Repository Management Practices: for a Technology-Intensive Enterprise,” Journal of Physics., vol. 1187, Issue. 4, 2019.

[43] M. Kirikova, “Variable Contents of Enterprise Models,” Procedia Computer Science., vol. 104, pp. 89-96, 2017.

[44] F. Vernadat, "Enterprise modelling: Research review and outlook," Computers in Industry, vol. 122, 103265, November 2020.

[45] شمس، فریدون، رضوی داوودی، مهسا، بدیع، کامبیز، "ارائه روشی جهت ارزیابی ویژگی‌های کیفی معماری سازمانی مبتنی بر"Fuzzy AHP ، نشریه مدیریت فناوری اطلاعات، دوره 2، شماره 4، از صفحه 79 تا صفحه 98، تهران، بهار و تابستان 1389.

[46] J. Lakhrouit, K. Ba"ina, “Evaluating enterprise architecture complexity using fuzzy AHP approach: Application to university information system,” IEEE/ACS 12th International Conference of Computer Systems and Applications (AICCSA), November 17-20, 2015.

[47] اسماعیلی، حمیدرضا، آل محمد، متین، اصول و مبانی شبکه‌های پتری، تهران، انتشارات موسسه فرهنگی هنری دیباگران تهران، چاپ اول، 1396.

[48] مدرس، محمد، تیموری، ابراهیم، نظریه صف، تهران، انتشارات دانشگاه علم و صنعت ایران، چاپ ششم، 1395.

[49] F. Basile, P. Chiacchio, D.D. Grosso, "A two-stage modelling architecture for distributed control of real-time industrial systems: Application of UML and Petri Net," Computer Standards & nterfaces, vol. 31, Issue 3, pp. 528-538, March 2009.

[50] T. Bouabana-Tebibel, S. H. Rubin, "An interleaving semantics for UML 2 interactions using Petri nets," Information Sciences, vol. 232, pp. 276-293, May 2013.

[51] N. Aoumeur, "Stepwise rigorous development of distributed agile information systems: from UML-diagrams to component-based Petri Nets," Enterprise Information Systems, vol. 2, No. 2, pp 125–160, May 2008.

[52] A. Alhroob, N. Yousef, "Transforming UML State Machine Diagram to High Level Petri Net Using Genetic Algorithm ," Lecture Notes on Software Engineering, vol. 2, No. 3, January 2014.

[53] S. Toghyani, A. Harounabadi, "Validation of enterprise architecture through colored Petri nets," Management Science Letters, vol. 5, pp. 311–320, March 2015.

[54] P. Szwed, “Verification of ArchiMate Behavioral Elements by Model Checking,” IFIP International Conference on Computer Information Systems and Industrial Management, September, 2015.

[55] Scott W. Ambler. User Stories: An Agile Introduction, 2022, <https://agilemodeling.com/artifacts/userstory.htm>.

[56] محمدی لرد، عبدالمحمود، فرآیندهای تحلیل شبکه‌ای (ANP) و سلسله مراتبی (AHP)به همراه معرفی نرم‌افزار Super Decision، تهران، انتشارات البرز فر دانش، 1388.

[57] عطائی، محمد، تصمیم‌گیری چند معیاره، شاهرود، انتشارات دانشگاه صنعتی شاهرود، چاپ اول، 1389.

An Information Architecture Framework for Utilizing Social Networks in Iranian Higher Education System
Print Date : 2019-11-08
The Impact of IQ Imbalance on the BER of Adaptive Modulation in the MIMO System
Print Date : 2019-11-08
Design and implementation of a fuzzy expert system for suspicious behavior detection in e-banking system
Print Date : 2019-11-08
A new reinforcement learning based multi-agent method for traffic shaping and buffer allocation in routers
Print Date : 2019-11-08
Evaluation of SIP signaling implementation using QoS parameters
Print Date : 2019-11-08
COBIT A Suitable Framework for Measuring IT Governance in Organizations
Print Date : 2019-11-08

Share To

Article Url

Presenting a Method for Agile Enterprise Architecture Modeling