Design Decisions - A RCHITECTURE D ESIGN

5.2 A RCHITECTURE D ESIGN

5.2.2 Design Decisions

To achieve the desired goals and align based on architectural significant requirements (ASRs) there are design approaches used to fulfill one or more ASRs and concerns. These are then applied to the architectural view of the system. These approaches usually depend on basic software engineering knowledge and enterprise architecture principles. It often involves applying heuristics as well. Therefore, the strategies and approaches adopted in an architectural view are called “design decisions” (Hofmeister, et al., 2007).

Here are the design decisions made during the process.

1. Some of the monolithic and legacy applications designated for end-users were selected as candidates for splitting to microservices so that it is effective to develop and maintain the solutions.

2. To make the user experience alike and seamless in the UI, it was agreed to use the mobile-first UI approach to keep the elements similar in mobile and web user-interface. Most of the components of the web and mobile UI can be

shared. Mobile and Web client enables users to use the system with much higher freedom.

3. All microservices have their own/semi-own database and data integrity must be maintained.

4. To ensure the service availability, there is a provision of load balancers and auto-scaling for all microservices, API gateway, UI applications, and Integration layer.

5. Enterprise Integration Patterns continues to play a critical role in integrations/communication between the applications due to the existence of old and legacy applications as it easies migration (Claus & Pooyan, 2016) and (Bogner, et al., 2018) suggests EI patterns bring expertise in integrations. All interactions and integrations outside the context area are limited to the API gateway or Integration layer. Integrations to legacy and third-party systems are handled using the integration layer as it needs transforming and which does not influence the microservices. In addition, it enables the capability to withstand fault tolerance and queue mechanism. Message-based integrations are preferred wherever possible to ensure, message delivery.

6. To ensure secure processing and data flow all information should be processed within the application in a highly secure way, hence secure protocols like traffic over SSL are used, HTTPS, SFTP and so on. Use of Pipelines and Continuous Deployments to keep the deployments automated, and use of auto-scaling to ensure requests are honored if the load increases.

7. Providing a secure API Gateway to the applications ensuring Authorization and Authentication. All requests authenticate via an authentication layer via tokens at the API gateway.

Overall, the design decisions enable the use of a Hybrid pattern of architecture using EIP, SOA, and microservices to transform the enterprise application landscape. API gateway is preferred to manage the APIs.

40 5.3 Functional View of the Artifact

Based on the above architecture significant requirements and design decisions the following reference artifact is created which can be referred to, in the same kind of transformation projects. This view in Figure 18 consists of functional elements, responsibilities, and interfaces. It also explains the primary interactions.

Figure 16: Functional view of the Artifact

On a high level, the functional view can explain the functional requirements and design decisions taken based on ASRs. FLATS is the flat file transfer communication between the systems. SOAP-based and REST-based Web Services API are used to manage the communication between the systems. It enables exchanging structured information in standard formats between the systems, which are understood if the support exists. Here

based on the SOA and MSA principles, a system is split into several services connected to an API gateway. Web UI and Mobile applications consume the same API endpoints to provide seamless offerings. A lightweight service layer handles Enterprise integrations, which is also responsible for interactions with legacy systems and other monolithic applications. The interaction and communication between the microservices can leverage both service orchestration and choreography. In most cases, for large and complex enterprises service orchestration is always better since it gives the advantages of message queues, fault tolerance, and central control and monitoring capabilities. However, to keep the properties of MSA, coordination between microservices is preferred if the context as the same and data is isolated. Legacy applications and traditional monolithic web applications can use enterprise integration patterns, which makes it easier to integrate and deliver business processes efficiently. This resonates with the Hybrid pattern of architecture using EIP, SOA, and MSA to take advantage of all.

Another key aspect of Microservices architecture, which has been taken into use while designing the overall architecture, is an API gateway. As the services grow

reasonably in microservices architecture, it becomes difficult to manage and maintain them without a centralized control layer. The services are usually loosely coupled, they need to be secured and managed so that access is fast and easy. A client can connect to one gateway to access all the services needed, this simplifies the overall network architecture as well. Routing and Security are key aspects of using the API gateway. All requests to different microservices are handled in a secure way, which is common to all types of requests. It runs in front of microservices and acts as a gatekeeper. As the use of API and services grows, there is also a strong demand to have some kind of API Lifecycle

management, which is now a crucial part of the API gateway. In some cases where API evolves to new versions based on feature iterations and application lifecycle, the goal is to keep the newer versions of API that can support backward compatibility and offer

customers to use different versions of API when needed. Monitoring and Analytics is an important aspect of microservices, measurement of metrics is key to understand the performance and service usage. Since all requests go through API gateway, its obvious place. It allows rate limiting and throttling features too. Some other features are input validation and response transformation if needed. Due to the microservices architecture principles, the decoupled nature of services result in several smaller resources, but the API gateway helps to manage these services.

6 DEMONSTRATION OF SOLUTION

The objective of this section is to demonstrate the use of the artifact to solve the above-described project landscape problem of enterprise architecture, therefore the utility of the artifact is strongly linked to the project that is has led to the creation of the reference artifact and strategy, which can be used in enterprises facing same challenges in their architectural goals. The artifact is created based on the research and applies well in this case. Hence based on the project requirements, and created artifact Figure.19 here is the proposed solution, which uses the artifact created in the design science research.

Some other requirements and decision decisions are taken into account during the demonstration of the solution using the created artifact.

1. Service availability should have high availability of more than 99.8%

2. Analytics reports should be available from Legacy, 3rd party and new microservices.

3. Analytics Platform enables the reports to be shown in a user interface, however, the data must be fed to the analytics platform. Here the platform is based on Azure cloud and Power BI. Data from modern microservices is directly moved to the analytics platform storage, however, the challenge remains where the reports are needed from legacy and third-party systems. Hence, the integration layer ensures data delivery to the Analytics platform from legacy and third-party systems after an optional transformation.

The utility of the artifact as shown in Figure 19 is, the use of modern strategies and design decisions to the architecture, and overall the process transforms the enterprise architecture and enables it to use the capabilities of SOA, MSA, and EIP. To keep the user experience seamless the frontend capabilities of the applications are planned to renew to modern web applications, which can be built on the concept of the mobile-first user interface. This expands the product offering to all kinds of devices such as mobile, tablets and web desktops. Microservices are independent however; some grouping has been done based on the product domain and offerings.

The idea is also to keep some shared microservices such as user service, which can be utilized among all services. Data for the Analytics platform is directly sent from the microservices database, which then processes the reports needed to be published at the API gateway for UI applications to consume.

Figure 17: Demonstration of the solution: Proposed Architecture based on the artifact

Figure 19 also demonstrates that other third parties and legacy applications use the lightweight service bus to feed the data to the analytics platform via service layer data transformation. Data operations and transactions among domain microservices are avoided, and they are mostly done using the service orchestration. In general, the utility of the artifact enables us to address the concerns and ASRs. The deployment itself is based on the high-availability model and auto-scaling is enabled to ensure the performance of the application in case the load increases. Service bus deployment uses clustering and load balancing to improve the scalability by keeping the load distributed across the application nodes. The transformation project starts with phase 1 where the basic environment setup including API gateway, few microservices and service bus with integrations to existing legacy and third-party systems have been used to highlight a proof of concept. Overall, the system looks promising and further phases of the transformation project progress.

7 EVALUATION

Design science research model suggests that theoretical constructs and artifact produced during the process should be evaluated to demonstrate how well does the artifact solve the objectives i.e. appropriateness and utility of their usage. (Hevner, et al., 2004) In this thesis, the evaluation is based on the objectives and ASRs based on (Hofmeister, et al., 2007) principles of architecture validation and on the principles of SOA, MSA, and EIP.

The purpose of this evaluation is to provide an understanding of the efficiency and effectiveness of an artifact. The target of the study is not only to understand the underlying problems and existing solutions available to the problems but also to contribute towards science with an artifact, which is adding value and helping other organizations to modernize their enterprise systems and architecture. However, the research and the artifact created could have some unforeseen consequences as the research done has some constraints and the problem-based research motivations.

Based on the guidelines of Design Science Research, we explained the artifact designed and it’s utility towards the problem. The solution is now taken into development and pilot done in order to understand how the concept works in real life because the complete implementation of the architectural artifact would probably take years. The idea is to understand if the proof of concept solves the problem statement and how well it solves the problem in question. When evaluating the architectural artifact created in this research project there were three iterations done to evaluate and test the pilot of the solution.

Overall solution and skeleton of the architecture worked well when tested migration of services from monolithic applications to services. Modernized UI application uses a Secured API gateway to connect with different services available and integrates with other applications via a light integration service bus, which takes care of integrating the information via message queues for services and using other EIPs. However, during the iterations of the architectural design process and evaluation, few observations needed attention and iteration of the design process.

The list of these observations is mentioned below:

1. With an increase in services and components, there comes a notion of scaling and automation; however, more services and resources were an obvious result of the modernization process. This adds more costs and moving parts in the overall

enterprise architecture. Monitoring each component needs extra efforts, built-in mechanisms such as Logging as a Service and Centralized monitoring, and built-in analytics of the services and traffic.

2. Some services initially were planned based on a high-level domain understanding, but later it became evident that to design the artifact it is important to clearly specify the service – business domain contexts. The services must be built accordingly keeping in mind cohesiveness and level of interactions and communication between the services. If the services are not designed carefully, the communication costs can grow high; causing performance issues and leading to re-designing costs.

3. It is found that SOA is less expensive and interaction friendly as it does not give high communication costs if compared to MSA.

8 DISCUSSION

To understand the overall benefit of this modernization, one must understand the challenges and problems in enterprise architecture and monolithic applications that have been developed a long time ago. Often these legacy systems are composed of old technologies and typically a centralized way and single unit application. As discussed this style has led several organizations to move towards service-oriented architectures and microservices. This thesis explained the problems and challenges faced by an enterprise to maintain its enterprise architecture and difficulties in modernizing its application to serve business and customer requirements with a more agile way of delivery model. The research highlights key and important strategies, solutions and patterns available for the enterprises to modernize the landscape. It also discusses SOA and MSA in detail and their commonalities and differences; keeping in mind the application of these features to create a novel artifact “architectural strategy and design to modernize the enterprise legacy architecture”. Communications and interactions being an important part of enterprise architecture, the area is well understood and clearly states that SOA prefers orchestration whereas MSA prefers choreography. However, there has to be a balance when designing a hybrid system, which takes advantage of both SOA and MSA. It is also evident that Microservices are very helpful with scalability, maintainability, and ease of deployments.

However, abundant choreography could increase the communication costs within services if not designed carefully. The challenge related to monoliths with limited capability of modern integrations is well solved with the created artifact enabling an easy migration from both sides using MSA and SOA. SOA supports easy migration and MSA helps with the splitting of monoliths into smaller course-grained services.

It enables to build real-time integrated and modern applications, which are easy to develop, deploy and maintain in the future keeping in mind scalability and high availability of the services. Mobile solutions are an important part of the artifact generated; the proposed artifact enables us to move towards mobile-first development strategy in business-critical applications without disturbing the operations. With a balanced hybrid, the flavor of SOA and MSA, performance and interoperability of applications is also well addressed. The artifact tends to do architectural simplification and keep the product portfolio simple, and flexibility to develop and maintain applications over time.

9 CONCLUSIONS

This research was conducted according to the design science guidelines (Hevner, et al., 2004) and design science process model (Peffers, et al., 2007) to develop a software artifact embedding a process that helps the designers modernize the enterprise architecture and its applications from legacy and monolith system while ensuring a good integration solution based on recurring solutions captured in the research. The research aimed to study the problem in a structured and deep-dive approach and finds the solutions available for the problem.

SOA tends to be more popular in enterprises to enable service-based architecture, however, MSA is evolving fast. Both SOA and MSA have their pros and cons, which must be kept in mind while designing a solution. In general, Microservices are a variant of SOA.

However, SOA is about the orchestration of services whereas MSA, on the other hand, relies more on independent small components, which can rely on self-coordination or orchestration. Therefore, this research illustrates use both SOA and MSA to its advantages and find a trade-off that can enable enterprises to benefit from both strategies as a hybrid architecture design that can solve the challenges of modern enterprise architecture.

It was also found that Enterprise Integration Patterns (EIP) continues to serve as a key reference point for integration needs. Overall, the new architecture was evaluated by conducting a small project and results were good in terms that it is possible to solve the problems of enterprises related to legacy apps and integrations. During the architecture design iteration process and evaluation of the artifact, there were some observations made and they helped to improve the overall solution as a whole.

The research can be further extended on how the overall implementation goes and how well it fits towards to goal of digital modernization of enterprise architectures. Further research could also focus on the role of modern architecture in the Internet of Things (IoT) era, as organizations tend to move toward that direction with 5G around the corner. It could also help the organizations if the research provides a strong base for large organizations to modernize the systems for the next generation to come.

10 REFERENCES

Arsanjani, A., 2004. Service-oriented modeling and architecture. IBM developer works.

Baskerville, R., Baiyere, A., Gregor, S. & Hevner, A., 2018. Design Science Research Contributions: Finding a Balance between Artifact and Theory. Journal of the Association for Information Systems, Issue 19, pp. 358-376..

Bih, J., 2006. Service oriented architecture (SOA) a new paradigm to implement dynamic e-business solutions. , Ubiquity.

Bogner, J., Zimmermann, A. & Wagner, S., 2018. Analyzing the Relevance of SOA Patterns for Microservice-Based Systems. 9-16, ZEUS Workshop.

Cerny, T., Donahoo, M. & Pechanec, J., 2017. Disambiguation and comparison of soa, microservices and self-contained systems. ACM: In Proceedings of the International Conference on Research in Adaptive and Convergent Systems, ( ), pp. 228-235.

Cerny, T., Donahoo, M. & Trnka, M., 2018. Contextual Understanding of Microservice Architecture: Current and Future Directions. ACM SIGAPP Applied Computing Review, 17(4), pp. 29-45.

Claus, P. & Pooyan, J., 2016. Microservices: A Systematic Mapping Study. , CLOSER.

Dragoni, N. et al., 2017. Microservices: yesterday, today, and tomorrow. In Present and ulterior software engineering Springer, Cham, pp. 195-216.

Endrei, M., Ang, J., Arsanjani, A. & Chua, S., 2004. Patterns: service-oriented architecture and web services. s.l.:IBM Corporation, International Technical Support Organization.

Fowler, M. & Lewis, J., 2014. Microservices. [Online]

Available at: https://martinfowler.com/articles/microservices.html [Accessed 1 12 2019].

Henttonen, K., Matinlassi, M., Niemela, E. & Kanstrén, T., 2007. Integrability and Extensibility Evaluation from Software Architectural Models- A Case Study. The Open Software Engineering Journal, pp. 1-20.

Hevner, A., March, S., Park, J. & Ram, S., 2004. Design science in information systems research. MIS quarterly, pp. 75-105.

Hofmeister, C. et al., 2007. A general model of software architecture design derived from five industrial approaches. Journal of Systems and Software, Elsevier Science Inc, 80(1), pp. 106-126.

Hohpe, G. & Woolf, B., 2012. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Boston, MA, USA: Pearson Education Inc..

Hunold, S. et al., 2008. Transformation of legacy software into client/server applications through pattern-based rearchitecturing. s.l., 32nd Annual IEEE International Computer Software and Applications Conference (pp. 303-310). IEEE..

IBM, 2010. EGL Programmer's Guide Introduction to SOA [Online]

https://www.ibm.com/support/knowledgecenter/SSMQ79_9.5.1/com.ibm.egl.pg.doc/topics

In document Modernization of enterprise systems (sivua 41-0)