Aligning agile software development with enterprise architecture framework Karolis Noreika Saulius Gudas Kaunas, Lithuania Institute of Data Science and Digital Technologies E-mail: knoreikos@gmail.com Vilnius University Vilnius, Lithuania E-mail: saulius.gudas@mii.vu.lt Abstract. The effectiveness of internal processes is a key in either decommission the system or accept the extremely costly modern day economy for companies of all sizes. This also includes support of it (i.e. mainframe systems in financial institutions). the effectiveness in software development management and its alignment with business goals both short and long term. But it is Enterprise architecture is a well-defined practice for not always easy to align IT development with organizational goals. conducting enterprise analysis, design, planning, and imple- This paper suggests a method for aligning modern software mentation, using a comprehensive approach at all times, for development approaches with enterprise architecture frameworks. the successful development and execution of strategy [3]. The agile methodology life cycle could be structured and aligned Keywords: agile software development, business and IT with TOGAF life cycle, which is a standard for enterprise alignment, enterprise architecture framework, TOGAF architecture development. TOGAF is a framework – a detailed method – for designing, planning, implementing, and I. INTRODUCTION governing an enterprise architecture [4], [10]. Agile approach is a popular software development This paper proposes a methodology for how agile methodology. Agile approach currently is being adopted to methodology life cycle can be aligned with TOGAF enterprise business strategy execution, decision making to achieve architecture framework. strategic goals. Companies are “going agile” [1] in order to improve productivity of software teams as well as business II. AGILITY IN BUSINESS MANAGEMENT AND SOFTWARE teams making business decisions. “Going agile” is a big DEVELOPMENT organizational change. It means that employees in all levels of Agile approach allows business representatives to see the organization will need to adapt to the new way of working, value of the software product being developed faster which is getting the results of their daily duties evaluated compared to traditional software development. Traditional or much faster than in the traditional way of working. However, “waterfall” software development dates back to around when “going agile”, the overall goals of the organization are 1970ties when the development of large enterprise IT systems not always supported with an organizational change. There are was started to be described in a scientific way [5]. researches that emphasize the importance of supporting the agile way of working from organizational perspective The waterfall methodology utilizes the idea that each (provide appropriate physical atmosphere, work environment phase in software development is sequential and cannot that encourages creativity) [2]. The gaps between business and repeat. The agile methodology promotes the idea of repeated IT strategies appear. It might result in not sufficient quality of and iterative steps, which are explained in Fig. 1 below. software products, that are not in line with overall goals of the organization both short and long term. Eventually the misalignment becomes so significant that organizations get into a position when there is no way back – Fig. 1. THE CONCEPTUAL DIAGRAM OF THE AGILE SOFTWARE DEVELOPMENT © 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0) 98 Fig. 1 explains how the software product is being developed information/knowledge flows. The detailed description of after the business need is received. It contains the whole agile each of the elements is in table 1 below. life cycle which is organized by having different TABLE 1. DESCRIPTION OF AGILE LIFE CYCLE ELEMENTS Step/ Step/element Step/element description element name no. 1 Data flow no. 1 The data flow, containing the information needed for understanding the business need, problem. It is transformed into product backlog item (element no. 2) 2 Product backlog List of features and requirements that the solution should have once completed. items 3 Data flow no. 2 An incoming data flow for the next element in the life cycle – sprint backlog (element no. 4). It contains the features that software should contain after development iteration – sprint. 4 Sprint backlog List of features that will be developed in the next sprint. Sprint is a time frame with a list of features described and approved by business and IT representatives. 5 Data flow no. 3 Once the high level features to be developed in the next sprint are agreed upon – the details must be clarified to the level needed in order to accomplish the business needs. This data flow contains the sprint backlog items or features explained in smaller pieces of information or requirements – user stories. 6 User stories The detailed requirements are worked on – analyzed by the development team so that both IT and business representatives understands the problem each user story would solve. 7 Data flow no. 4 The detailed user stories are placed in some software tool that would allow keeping track of the progress of development of user stories. 8 Sprints/ This is the most beneficial part of the agile life cycle. It is a method of constantly developing development small part of the overall software solution and getting the feedback fast. Each sprint consists of: a) Design – designing the user interface, business rules placed in the solution. b) Build (develop) – coding, styling, working on the solution from development perspective. c) Test – test the developed solution against the requirements. d) Review – review the solution test findings and decide what to improve. e) Launch – after the items that were agreed to be developed at the end of sprint are verified against the solution itself and the found changes that were necessary to do are done, the project team decides should the solution at current stage be deployed into production (or live) environment, where it could be already used by business representatives. Note: agile promotes the approach that the project team should be able to continue the iterative development for indefinite amount of time. Therefore, the number of sprints with the same phases as mentioned above could continue indefinitely. 9 Data flow no. 5 The information gathered from the business need at the beginning of the project and throughout development phase aggregated to prepare the demo of the solution. 10 Demo The demo for the solution is a system presentation conducted to all relevant stakeholders. 11 Data flow no. 6 The decision after the demo whether the solution should be included into production environment or should the development continue with taking the next set of requirements made. 12 Repeat or close As Agile methodology describes – self-organizing team should be capable of keeping the development accepted efficiency for product development indefinitely. This means that if business managers decide – the team should be able to repeat the whole cycle indefinite amount of times until the repetition does not increase the value significantly. If the decision is made to close the project – the agile life cycle is completed. 13 Data flow no. 7 If it is decided to continue development – the next set of requirements is taken from the product backlog items list (element no. 2) and the agile life cycle is repeated. There are a lot of details and techniques how agile life multiple projects in same business area (i.e. store related cycle should be managed to achieve the best efficiency [6], documents in single repository, have same classification of [7], [8], but this is not a subject of this paper. them, etc.) The business side in the enterprises is also starting to take decision based on agile methodology, although it is However, running a successful business is not only about often perceived as a part of startup culture – i.e. not something doing software development in an agile way. Often IT established and large organizations would do. Table 2 below development is ahead of business decisions where to come up represents the comparison of agile and traditional approach on with a suitable software solution development teams needs business decision making in agile and traditional ways. quick decisions by business that might be applicable across 99 TABLE 2. AGILE AND TRADITIONAL DECISION MAKING COMPARISON Methodology Flexibility Risk Adapting to Amount of data needed to change make decision Agile (including Higher Higher Faster Smaller variations) Traditional Lower Lower Slower Larger Agile methodology could be applied to business decision also one of key aspects to have for the agile development making by mapping the agile phases to decision making teams to be successful and self-organizing. process – i.e. limit the information needed to make decision could be compared to sprint backlog. Having a deadline for a 3) Competitive potential – focuses on utilizing emerging decision could be understood as the date for demo. Adjust to IT capabilities to impact new products and services also to new information on the decision could be understood as influence key attributes of strategy (distinct competences) as review part of sprint. well as form new relationships (business governance). This perspective also allows the changing of business strategy via III. IDENTIFICATION OF GAPS BETWEEN BUSINESS emerging IT capabilities. The role of the management is of AND IT STRATEGIES business visionary who dictates how emerging IT competences and functionality would impact the business A. Business and IT alignment model strategy. The role of IT manager is of the one who identifies The business and IT alignment model was created by and interprets the trend in the IT environment to assist the Henderson and improved by Venkatraman to represent business managers to understand the potential opportunities business strategy alignment with IT strategy thus providing and threats from an IT perspective and handle them analysis method aimed for competitive advantage [9]. Fig. 2 accordingly. below represents the strategic alignment model. 4) Service level – this perspective focuses on building world class IT team. Therefore, the role of IT manager is also of a business leadership with tasks of making the internal business succeed with the operating guidelines from top management. B. TOGAF TOGAF is framework for designing, planning, implementing, and governing an enterprise information technology architecture. The TOGAF standard includes a content framework to drive the Architecture Development Method (ADM). TOGAF is an iterative process model (enterprise architecture development life cycle) supported by best practices and a re-usable set of existing architecture Fig. 2. THE BUSINESS AND IT ALIGNMENT MODEL assets. TOGAF supports Capability-Based Planning of There are four domain alignment perspectives where each enterprise architecture [10]. focuses on different aspect of alignment between the business The TOGAF framework is presented in Fig. 3 below. and IT alignment, i.e.: 1) Strategy execution – business strategy is the driver for organization design changes and the logic of IT infrastructure. In this perspective, the top management of the organization dictates the strategy of the company and the IT management is the strategy implementer. 2) Technology potential – business strategy is the driver for change, however it is closely aligned with IT strategy as well, therefore the IT systems are more aligned with IT strategy and also business strategy. The top management should provide the vision of the technology to articulate the logic and choices to IT strategy what would best support the chosen business strategy. The role of IT manager in this perspective should be of the technology architect – the IT manager should efficiently and effectively design and also implement information system infrastructure that is consistent with the IT strategy. This alignment perspective could be used for aligning business and IT strategy along with IT systems in an agile way as vision is 100 Enterprise architecture development life cycle (defined in TOGAF) could be used for analysis of the agile software development approach. The TOGAF life cycle in Fig. 3 was transformed to a schematic view of a table (Fig. 4) in which the columns represent the phases of TOGAF enterprise architecture development life cycle and agile methodology life cycle and the activities in the intersecting sections – the phases of agile development (design, build, test and deploy) [11]. This approach could be used into applying agile way of working for building up and aligning with enterprise architecture implementation that TOGAF provides. Although companies can change strategies quickly, they then face the big slowdown of executing one or several strategies. For enterprise architects, this has traditionally meant defining a new target state, comparing it with the current state, and then developing a road map. But this multistep process is now perceived as taking too long — by the time EA has all of these documented and approved, the business will have moved on [12]. Fig. 3. ENTERPRISE ARCHITECTURE DEVELOPMENT LIFE CYCLE TOGAF (https://www.opengroup.org/togaf) Fig. 4. TOGAF ENTERPRISE ARCHITECTURE FRAMEWORK AND AGILE METHODOLOGY ALIGNMENT MODEL IV. ALIGNING AGILE LIFE CYCLE WITH ENTERPRISE (also called stakeholders, subject matter experts or in agile – ARCHITECTURE FRAMEWORK product owners) represent the business only fragmentally – whenever there is a question regarding IT and business It is a common belief that TOGAF and also other large alignment – it is solved on ad-hoc basis, but a long term IT enterprise architecture frameworks are “waterfall”. This is a and business strategy should be capable of answering these common misinterpretation largely due to these models questions on a higher – strategic – level which is orchestrated encompassing all related IT activities and not specific. But by using the TOGAF methodology. basically all these enterprise architecture frameworks are sets of tools, similar like agile where one also should choose the The idea behind mapping TOGAF to agile life cycle is use tools and methods suitable for each specific case. A problem the strategic vision that TOGAF provides by using its in large organizations is that there are different levels of framework and utilize the benefits of agile continuous maturity of agile of different teams. Business representatives 101 improvement and “inspect and adapt” approach. The technology advances to the cloud based solutions more and suggested mapping is displayed in Fig. 5. more companies are concerned about the safety of the data in the cloud based systems. Combining these concerns with the When TOGAF is used for overall overview on the agreed service level agreements provided by external vendors enterprise architecture and agile is used for project’s not being maintained for enterprises to run their operations iterations, the business gets benefit from even faster deliveries smoothly (i.e. important IT system being outsourced is not and projects are aligned with business goals at all times. working part of the day due to agreed service level agreement V. CASE STUDY breached) might lead to decisions to insource the IT and IS infrastructure. But the cost of such decisions is very dependent Large enterprises often combine the IT infrastructure „in- on the level of alignment between IT and business strategy and house“ together with outsourcing it. It could be only storing the less is the alignment, the bigger are the costs. Whenever part of data or all the data of the enterprise. These decisions an enterprise is faced with such decision, it is very important are made according to IT strategy mostly and not always these to keep the alignment between business and IT strategies decisions are aligned with business strategy. As the moving on. Fig. 5. THE SIMPLIFIED MAPPING OF TOGAF TO AGILE LIFE CYCLE By using the TOGAF enterprise architecture framework The case where such suggestion was made was about large and agile methodology alignment suggested in chapter 4, the enterprise moving over 2000 servers of different purposes company facing such decision might significantly reduce the from outsource to in-house. When using the suggested method cost and impact of the migration from outsource provider to of enterprise architecture framework TOGAF being aligned in-house solution by constantly aligning the enterprise with agile methodology the implementation of the change architecture which TOGAF describes with the constant could have taken at least 10 % less effort both in terms of cost feedback, “inspect and adapt” approach that agile promotes. and time needed for the change as the comparison of activities 102 by using only agile methods and the suggested method REFERENCES showed. Also it is worth noting that this situation could have [1] M. Pikkarainen, J. Haikara, O. Salo, P. Abrahamsson, J. Still, been avoided if all the tools and methodologies mentioned in Pikkarainen, M., Haikara, J., Salo, O. et al. “Empir Software Eng” this paper were used: IT and business alignment model for (2008) 13: 303. https://doi.org/10.1007/s10664-008-9065-9 overseeing the potential IT infrastructure decisions, TOGAF [2] Crawford, Broderick & León de la Barra, Claudio & Soto, Ricardo & for overseeing enterprise architecture and the TOGAF and Misra, Sanjay & Monfroy, Eric. (2013). “Agile Software Development: agile alignment model suggested by this paper which helps to It Is about Knowledge Management and Creativity”. ICEIS 2013 - Proceedings of the 15th International Conference on Enterprise see the potential gaps between agile software development Information Systems. 2. 10.5220/0004447802650272. and business strategy much faster. [3] Federation of EA Professional Organizations, "Common Perspectives on Enterprise Architecture," Architecture and Governance Magazine, VI. CONCLUSIONS Issue 9-4, November 2013 (2013). The agile way of working is something that in some [4] Dirk Draheim, Gerald Weber “Trends in Enterprise Application enterprises is new but others are already very far away in Architecture” 2nd International Conference, TEAA 2006, Berlin, implementing this approach into daily decision making Germany, November 29 - December 1, 2006, Revised Selected Papers process both business and software development. These [5] Winston Royce, “Managing the Development of Large Software Systems”, Proc. Westcon, IEEE CS Press, 1970, pp. 328-339 decisions need to be constantly aligned with the overall [6] Jeffrey Verret “Implementing Agile Methodology: Challenges and business strategy to have the effective enterprise run Best Practices” University of Oregon (2018) smoothly. Therefore, it is very important to align the [7] Darrell K. Rigby, Jeff Sutherland, Hirotaka Takeuchi “Embracing enterprise architecture of the organization with agile approach Agile” Harvard Business Review 2016, pp.40–48 to make the most benefit of enterprise architecture framework [8] Zamudio, Lizbeth & Aguilar, José & Tripp-Barba, Carolina & Misra, like TOGAF, which provides the tools to ensure business and Sanjay. (2017). A Requirements Engineering Techniques Review in IT alignment whereas agile provides the speed and the Agile Software Development Methods. 683-698. 10.1007/978-3-319- possibility to adapt to changes. Method, suggested in this 62404-4_50. paper, supports utilization of those mentioned benefits from [9] Henderson, John and Venkatraman, N.” Strategic alignment: A model both tools and allows to improve not only software for organization transformation via information technology” Working Paper 3223-90. Massachusetts Institute of Technology, 1990, 458 p. development process which agile supports, but also keep the ISBN 9781245057264. alignment between IT and business strategy by constantly [10] The TOGAF® Standard, Version 9.2 keeping IT projects aligned with business strategy which https://www.opengroup.org/togaf TOGAF supports to make sure right solutions are developed [11] BPM utils.com Enterprise Agile solution Delivery Framework 2017 and aligned with long term goals of the enterprise. The [12] Henry Peyret “EA Methodologies Enlarge To Address The New proposed approach could be further improved through the use Business Landscape”, 2013 on different types of organizations (i.e. financial, trade, http://entreprise-agile.com/ForresterEA.pdf manufacturing) and adapting it in a generalized way for further usage. 103