Content thumbnail Building Digital Experience Platforms
AI Content Chat (Beta) logo

Building Digital Experience Platforms

Building Digital Experience Platforms A Guide to Developing Next-Generation Enterprise Applications — Shailesh Kumar Shivakumar Sourabhh Sethii

Building Digital Experience Platforms A Guide to Developing Next- Generation Enterprise Applications Shailesh Kumar Shivakumar Sourabhh Sethii

Building Digital Experience Platforms: A Guide to Developing Next-Generation Enterprise Applications Shailesh Kumar Shivakumar Sourabhh Sethii Bangalore, Karnataka, India Jammu, Jammu and Kashmir, India ISBN-13 (pbk): 978-1-4842-4302-2 ISBN-13 (electronic): 978-1-4842-4303-9 Library of Congress Control Number: 2019931830 Copyright © 2019 by Shailesh Kumar Shivakumar, Sourabhh Sethii This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein. Managing Director, Apress Media LLC: Welmoed Spahr Acquisitions Editor: Shiva Ramachandran Development Editor: Laura Berendson Coordinating Editor: Rita Fernando Cover designed by eStudioCalamar Cover image designed by Freepik ( Distributed to the book trade worldwide by Springer Science+Business Media New York, 233 Spring Street, 6th Floor, New York, NY 10013. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail orders-ny@springer-, or visit Apress Media, LLC is a California LLC and the sole member (owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance Inc is a Delaware corporation. For information on translations, please e-mail [email protected], or visit rights-permissions. Apress titles may be purchased in bulk for academic, corporate, or promotional use. eBook versions and licenses are also available for most titles. For more information, reference our Print and eBook Bulk Sales web page at Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub via the book’s product page, located at For more detailed information, please visit Printed on acid-free paper

I dedicate this book to . . . My parents, Shivakumara Setty V and Anasuya T M who blessed me with their love and strength, My wife, Chaitra Prabhudeva and my son Shishir who shared their time and support, My in-laws, Prabhudeva T M and Krishnaveni B who provided help and courage, and to all my school teachers to bestow lots of love and knowledge. —Shailesh Kumar Shivakumar To lovers of books . . . I hope this book aids you to get your work out to a wider audience. I would love nothing more than to see the book in the hands of people everywhere—students in the classroom, researchers, browsers in the bookstore, and professionals. That’s a great challenge, but it is certainly worth an attempt. —Sourabhh Sethii

Table of Contents About the Authors ��������������������������������������������������������������������������������������������������xvii About the Technical Reviewers ������������������������������������������������������������������������������xix Acknowledgments ��������������������������������������������������������������������������������������������������xxi Introduction ����������������������������������������������������������������������������������������������������������xxiii Part I: Requirements and Design ��������������������������������������������������������������������1 Chapter 1: Introduction to Digital Experience Platforms ������������������������������������������ 3 Boundaryless Banking Enabled by Digital Technologies ��������������������������������������������������������������� 4 Overview of DXP �������������������������������������������������������������������������������������������������������������������������� 4 Key Tenets of a DXP ����������������������������������������������������������������������������������������������������������������� 5 DXP Reference Architecture ���������������������������������������������������������������������������������������������������� 5 Evolution and Drivers for DXP ������������������������������������������������������������������������������������������������ 11 Overview of Banking Experience Platform ���������������������������������������������������������������������������������� 16 Key Tenets of Banking Experience Platform �������������������������������������������������������������������������� 16 High-Level Requirements of Banking Experience Platform ��������������������������������������������������� 17 Three Ps of BXP ��������������������������������������������������������������������������������������������������������������������� 21 Sample Technical Capabilities of Banking Experience Platform �������������������������������������������� 21 Sample Key Performance Indicators of Banking Experience Platform ���������������������������������� 24 Digital Imperatives for Modern Banks����������������������������������������������������������������������������������������� 25 Summary������������������������������������������������������������������������������������������������������������������������������������� 26 Chapter 2: Gathering Requirements ����������������������������������������������������������������������� 27 Functional Requirements ������������������������������������������������������������������������������������������������������������ 32 Experience Requirements ����������������������������������������������������������������������������������������������������������� 36 Seamless Experience on All Supported devices �������������������������������������������������������������������� 37 Seamless Experience on All Supported Browsers ����������������������������������������������������������������� 38 v

Table of ConTenTs Multilingual Requirements ���������������������������������������������������������������������������������������������������� 38 Navigation Elements, Menus, and Search ����������������������������������������������������������������������������� 39 Mobility Requirements ���������������������������������������������������������������������������������������������������������������� 41 Nonfunctional Requirements ������������������������������������������������������������������������������������������������������ 43 Scalability Requirements ������������������������������������������������������������������������������������������������������������ 44 Performance–Response Time, Throughput, Utilization, Static Volumetric ����������������������������������� 46 Performance Requirements ��������������������������������������������������������������������������������������������������� 46 Page Hits Analysis ����������������������������������������������������������������������������������������������������������������� 48 Maintenance Requirements �������������������������������������������������������������������������������������������������������� 50 Versioning ����������������������������������������������������������������������������������������������������������������������������������� 52 Rollout ����������������������������������������������������������������������������������������������������������������������������������������� 52 Security Requirements ���������������������������������������������������������������������������������������������������������������� 53 Disaster Recovery Requirements ������������������������������������������������������������������������������������������������ 57 Accessibility Consideration ��������������������������������������������������������������������������������������������������������� 58 Chapter Summary ����������������������������������������������������������������������������������������������������������������������� 59 Chapter 3: Design ��������������������������������������������������������������������������������������������������� 61 Building an Experience Platform ������������������������������������������������������������������������������������������������� 61 Digital Platform Strategy ������������������������������������������������������������������������������������������������������������� 65 Platform Design Phases �������������������������������������������������������������������������������������������������������������� 69 Design of Various Layers ������������������������������������������������������������������������������������������������������������� 70 Presentation Layer ���������������������������������������������������������������������������������������������������������������������� 72 Scripting Framework ������������������������������������������������������������������������������������������������������������� 74 UI Management ��������������������������������������������������������������������������������������������������������������������� 75 UI Deployment ����������������������������������������������������������������������������������������������������������������������� 76 Integration Layer ������������������������������������������������������������������������������������������������������������������������� 77 Loosely Coupled Integration and Highly Coupled Integration ������������������������������������������������ 78 Business Layer ���������������������������������������������������������������������������������������������������������������������������� 84 Data Layer ����������������������������������������������������������������������������������������������������������������������������������� 86 Middleware Layer ����������������������������������������������������������������������������������������������������������������������� 87 Social and Collaboration Design ������������������������������������������������������������������������������������������������� 89 vi

Table of ConTenTs IoT Integration Design ����������������������������������������������������������������������������������������������������������������� 93 IoT Case Study ����������������������������������������������������������������������������������������������������������������������� 95 Blockchain Design ���������������������������������������������������������������������������������������������������������������������� 96 What is Blockchain? �������������������������������������������������������������������������������������������������������������� 96 What Is a Distributed Ledger? ����������������������������������������������������������������������������������������������� 97 Smart Contract ���������������������������������������������������������������������������������������������������������������������� 97 Blockchain Platforms������������������������������������������������������������������������������������������������������������� 98 DXP and Blockchain Network ������������������������������������������������������������������������������������������������ 98 Blockchain Components �������������������������������������������������������������������������������������������������������� 99 Blockchain Case Study �������������������������������������������������������������������������������������������������������� 100 Big Data and NoSQL Design ������������������������������������������������������������������������������������������������������ 102 Big Data and NoSQL Integration ������������������������������������������������������������������������������������������ 102 Big Data and NoSQL Case Study ����������������������������������������������������������������������������������������� 105 AI Automation Design ���������������������������������������������������������������������������������������������������������������� 106 Determine Automation Goals ����������������������������������������������������������������������������������������������� 106 Steps to Build AI Automation Model ������������������������������������������������������������������������������������ 106 Chatbot Case Study ������������������������������������������������������������������������������������������������������������� 107 Enterprise Search Engine ���������������������������������������������������������������������������������������������������������� 109 Augmented – Virtual Reality Integration ����������������������������������������������������������������������������������� 111 Presentation Layer ��������������������������������������������������������������������������������������������������������������� 111 Integration Service Layer ���������������������������������������������������������������������������������������������������� 112 Recent Trends in DevOps ���������������������������������������������������������������������������������������������������������� 113 Containerization������������������������������������������������������������������������������������������������������������������� 113 DevOps – Continuous Integration (CI), Continuous Deployment (CD) ���������������������������������� 114 Chapter Summary ��������������������������������������������������������������������������������������������������������������������� 115 Part II: Development of the Banking Experience Platform �������������������������117 Chapter 4: User Interface Design �������������������������������������������������������������������������� 119 Key Features ����������������������������������������������������������������������������������������������������������������������������� 119 Simplified Approach ������������������������������������������������������������������������������������������������������������ 119 Intuitive Architecture ����������������������������������������������������������������������������������������������������������� 120 vii

Table of ConTenTs Dashboard ��������������������������������������������������������������������������������������������������������������������������� 120 Responsive Interface ����������������������������������������������������������������������������������������������������������� 120 Personalization �������������������������������������������������������������������������������������������������������������������� 121 Internationalization and Localization ����������������������������������������������������������������������������������� 122 Preferences ������������������������������������������������������������������������������������������������������������������������� 122 Integrated Analytics ������������������������������������������������������������������������������������������������������������� 122 Search Engine Optimization ������������������������������������������������������������������������������������������������ 123 User Interface Components������������������������������������������������������������������������������������������������������� 123 Pages ����������������������������������������������������������������������������������������������������������������������������������� 123 Layouts �������������������������������������������������������������������������������������������������������������������������������� 123 Navigational Router or Navigation Menu ����������������������������������������������������������������������������� 124 Presentation Component ����������������������������������������������������������������������������������������������������� 125 Design Goals ������������������������������������������������������������������������������������������������������������������������ 125 Communication Between Presentation Components ���������������������������������������������������������� 126 Hooks ����������������������������������������������������������������������������������������������������������������������������������� 127 Development Process ��������������������������������������������������������������������������������������������������������������� 127 Development Life Cycle ������������������������������������������������������������������������������������������������������������ 129 Architecture ������������������������������������������������������������������������������������������������������������������������������ 130 DXP UI Technology Stack ���������������������������������������������������������������������������������������������������������� 132 Angular Technology Stack ��������������������������������������������������������������������������������������������������������� 133 Angular Core ����������������������������������������������������������������������������������������������������������������������������� 134 Angular Support Library ������������������������������������������������������������������������������������������������������ 135 React Technology Stack ������������������������������������������������������������������������������������������������������������ 137 React ����������������������������������������������������������������������������������������������������������������������������������� 137 React Support Library ���������������������������������������������������������������������������������������������������������� 137 Evaluating UI frameworks ��������������������������������������������������������������������������������������������������������� 139 Data Flow����������������������������������������������������������������������������������������������������������������������������� 139 Language ����������������������������������������������������������������������������������������������������������������������������� 139 Performance ������������������������������������������������������������������������������������������������������������������������ 139 Best Practice ����������������������������������������������������������������������������������������������������������������������������� 140 BXP – Case Study ���������������������������������������������������������������������������������������������������������������������� 141 viii

Table of ConTenTs Consistency Across Locations ��������������������������������������������������������������������������������������������� 141 Consistency Across Application ������������������������������������������������������������������������������������������� 141 Unified and Collaborative Approach ������������������������������������������������������������������������������������ 142 BXP UI Layouts/Containers �������������������������������������������������������������������������������������������������� 142 BXP Dashboard �������������������������������������������������������������������������������������������������������������������� 142 Chapter Summary ��������������������������������������������������������������������������������������������������������������������� 147 Chapter 5: Designing the Integration Layer ���������������������������������������������������������� 149 Integration Consideration ���������������������������������������������������������������������������������������������������������� 150 Data Formats ���������������������������������������������������������������������������������������������������������������������������� 153 Integration Services ������������������������������������������������������������������������������������������������������������������ 155 Integration Styles, Protocols, Systems, and Patterns���������������������������������������������������������������� 157 Integration Styles ���������������������������������������������������������������������������������������������������������������� 157 Integration Protocols ����������������������������������������������������������������������������������������������������������� 158 Integration Systems������������������������������������������������������������������������������������������������������������� 161 Integration Patterns ������������������������������������������������������������������������������������������������������������� 162 Data Standards ������������������������������������������������������������������������������������������������������������������������� 164 Flexible Integration Middleware ������������������������������������������������������������������������������������������������ 165 EAI vs� SOA vs� ESB vs� Microservices �������������������������������������������������������������������������������� 165 Mutual Memorandum of Understanding (MOU) ������������������������������������������������������������������� 167 Service Protocol and Data Format ��������������������������������������������������������������������������������������� 167 API Management ����������������������������������������������������������������������������������������������������������������� 167 Why Do We Need Data Transformation Capabilities in DXP? ����������������������������������������������������� 167 Integration Technology Stack and Architecture ������������������������������������������������������������������������� 168 Monolithic ���������������������������������������������������������������������������������������������������������������������������� 168 Microservices ���������������������������������������������������������������������������������������������������������������������� 170 ESB and API Gateway ���������������������������������������������������������������������������������������������������������������� 170 Integration Security ������������������������������������������������������������������������������������������������������������������� 171 Authentication and Authorization ���������������������������������������������������������������������������������������� 171 Protocols ������������������������������������������������������������������������������������������������������������������������������ 171 Frameworks������������������������������������������������������������������������������������������������������������������������� 171 ix

Table of ConTenTs Integration Best Practices ��������������������������������������������������������������������������������������������������������� 173 BXP Case Study ������������������������������������������������������������������������������������������������������������������������� 176 Case Study Conclusion �������������������������������������������������������������������������������������������������������� 179 Chapter Summary ��������������������������������������������������������������������������������������������������������������������� 179 Part III: Securing the Banking Experience Platform �����������������������������������181 Chapter 6: DXP Security ��������������������������������������������������������������������������������������� 183 DXP Security Framework ���������������������������������������������������������������������������������������������������������� 183 DXP Layer-Wise Security ����������������������������������������������������������������������������������������������������� 184 Common Security Scenarios of DXP ����������������������������������������������������������������������������������������� 187 Password Standards ������������������������������������������������������������������������������������������������������������ 187 Session Management ���������������������������������������������������������������������������������������������������������� 188 Information Management ���������������������������������������������������������������������������������������������������� 188 Data Validation ��������������������������������������������������������������������������������������������������������������������� 189 Service Security Management �������������������������������������������������������������������������������������������� 189 Security Vulnerabilities and Best Practices of DXP ������������������������������������������������������������������� 190 Security Testing Framework for DXP����������������������������������������������������������������������������������������� 192 Secure Code Scanning �������������������������������������������������������������������������������������������������������� 193 General Web Security testing ���������������������������������������������������������������������������������������������� 194 Application-Specific Security Analysis �������������������������������������������������������������������������������� 195 Threat Profiling of Transaction Management in Banking DXP ��������������������������������������������� 195 Threat profiling of Fund Management in Banking DXP �������������������������������������������������������� 196 DXP Security Checklists ������������������������������������������������������������������������������������������������������������ 196 DXP Architecture and Design Phases Security Checklist ���������������������������������������������������� 196 DXP Information Management Security Checklist ��������������������������������������������������������������� 197 DXP Authentication and Session Management Checklist ���������������������������������������������������� 197 DXP Network Communication Management Security Checklist ������������������������������������������ 198 DXP Input Validation Security Checklist ������������������������������������������������������������������������������� 198 DXP Security Auditing and Logging Security Checklist ������������������������������������������������������� 199 Chapter Summary ��������������������������������������������������������������������������������������������������������������������� 199 x

Table of ConTenTs Chapter 7: DXP Information Security �������������������������������������������������������������������� 201 Information Security in DXP Solutions �������������������������������������������������������������������������������������� 201 Implementing Defense in Depth ������������������������������������������������������������������������������������������������ 202 Firewalls and Proxies ���������������������������������������������������������������������������������������������������������� 202 Server Hardware Level Protection ��������������������������������������������������������������������������������������� 202 Monitoring Infrastructure ���������������������������������������������������������������������������������������������������� 202 Backup Jobs and Synch Jobs ���������������������������������������������������������������������������������������������� 203 Disaster Recovery and Business Continuity Plan ���������������������������������������������������������������� 203 Implementing Information Security Policies ����������������������������������������������������������������������������� 203 Information Access Policies������������������������������������������������������������������������������������������������� 203 Protecting Private Data �������������������������������������������������������������������������������������������������������� 207 Information Security Best Practices������������������������������������������������������������������������������������������ 208 Privacy Best Practices ��������������������������������������������������������������������������������������������������������� 208 Authentication and Authorization ���������������������������������������������������������������������������������������� 208 Auditing and Logging ����������������������������������������������������������������������������������������������������������� 209 File Management ����������������������������������������������������������������������������������������������������������������� 209 Error Handling ��������������������������������������������������������������������������������������������������������������������� 209 Secure Software Development Life Cycle ��������������������������������������������������������������������������� 209 Secure Incident Management���������������������������������������������������������������������������������������������� 210 Database Level Security ������������������������������������������������������������������������������������������������������ 210 Sharing the Data with External Systems ����������������������������������������������������������������������������� 210 Security Awareness and Training ���������������������������������������������������������������������������������������� 210 Security Testing ������������������������������������������������������������������������������������������������������������������� 211 Cloud Testing ����������������������������������������������������������������������������������������������������������������������� 211 Chapter Summary ��������������������������������������������������������������������������������������������������������������������� 212 Part IV: Infrastructure and NFR for the Banking Experience Platform �������213 Chapter 8: Quality Attributes and Sizing of the DXP ��������������������������������������������� 215 Key Quality Attributes of DXP ���������������������������������������������������������������������������������������������������� 215 Quality Attributes Deep Dive ����������������������������������������������������������������������������������������������������� 217 Usability Requirements�������������������������������������������������������������������������������������������������������� 217 Security Requirements �������������������������������������������������������������������������������������������������������� 218 xi

Table of ConTenTs Reliability Requirements������������������������������������������������������������������������������������������������������ 219 Scalability Requirements ����������������������������������������������������������������������������������������������������� 219 Availability Requirements ���������������������������������������������������������������������������������������������������� 220 Archival and Retention Requirements ��������������������������������������������������������������������������������� 221 Logging and Auditing Requirements ����������������������������������������������������������������������������������� 221 Performance Requirements ������������������������������������������������������������������������������������������������� 222 Infrastructure Sizing of DXP ������������������������������������������������������������������������������������������������������ 222 Cloud Hosting of DXP Solution �������������������������������������������������������������������������������������������������� 224 Tiered Architecture �������������������������������������������������������������������������������������������������������������� 224 Cloud Deployment Considerations ��������������������������������������������������������������������������������������� 225 Cloud Deployment Model ����������������������������������������������������������������������������������������������������� 226 Disaster Recovery and Business Continuity for DXP Applications �������������������������������������������� 228 DR Planning ������������������������������������������������������������������������������������������������������������������������� 229 DR Implementation �������������������������������������������������������������������������������������������������������������� 230 DR Maintenance ������������������������������������������������������������������������������������������������������������������ 231 DR Strategy Document �������������������������������������������������������������������������������������������������������� 232 Chapter Summary ��������������������������������������������������������������������������������������������������������������������� 233 Chapter 9: DXP Performance Optimization ����������������������������������������������������������� 235 DXP Performance Optimization of Presentation Layer �������������������������������������������������������������� 235 User Experience������������������������������������������������������������������������������������������������������������������� 235 Performance Testing for DXP ���������������������������������������������������������������������������������������������������� 238 Performance Testing Activities �������������������������������������������������������������������������������������������� 238 Key Performance Metrics ���������������������������������������������������������������������������������������������������� 243 Performance Testing Framework ���������������������������������������������������������������������������������������������� 244 Identify Critical Transactions ����������������������������������������������������������������������������������������������� 245 Document Workload Model �������������������������������������������������������������������������������������������������� 245 Qualitative Assessment ������������������������������������������������������������������������������������������������������� 245 Quantitative Assessment ����������������������������������������������������������������������������������������������������� 246 Predict ��������������������������������������������������������������������������������������������������������������������������������� 247 Performance Debugging Framework ���������������������������������������������������������������������������������������� 247 Identify the Root Cause ������������������������������������������������������������������������������������������������������� 247 xii

Table of ConTenTs Optimize the Component/System/Layer ������������������������������������������������������������������������������ 251 Common Performance Problem Pattern ������������������������������������������������������������������������������ 252 Performance Case study ����������������������������������������������������������������������������������������������������������� 254 Application Context and Background ���������������������������������������������������������������������������������� 254 Performance Analysis ���������������������������������������������������������������������������������������������������������� 254 Recommendations and Improvements �������������������������������������������������������������������������������� 256 Chapter Summary ��������������������������������������������������������������������������������������������������������������������� 258 Chapter 10: Transforming Legacy Banking Applications to Banking Experience Platforms �������������������������������������������������������������������������������������������������������������� 261 Key Tenets of a Banking Experience Platform �������������������������������������������������������������������������� 262 Attributes of a Next-Generation Digital Bank����������������������������������������������������������������������� 263 DXP Features for Next-Generation Digital Bank ������������������������������������������������������������������ 265 Main Trends in Digital Banking ������������������������������������������������������������������������������������������������� 268 Technology-Related Trends ������������������������������������������������������������������������������������������������� 268 Business Process-Related Trends ��������������������������������������������������������������������������������������� 269 Digital Transformation of Traditional Banks to Digital Banks ���������������������������������������������������� 269 Reference Technology Architecture for a Digital Bank �������������������������������������������������������� 269 Reference Functional View of Digital Bank �������������������������������������������������������������������������� 273 Main Digital Transformation Methods ���������������������������������������������������������������������������������� 278 Digital Transformation Road Map ���������������������������������������������������������������������������������������� 288 Reimagining the Digital Banking Experience����������������������������������������������������������������������� 288 Chapter Summary ��������������������������������������������������������������������������������������������������������������������� 294 Part V: End to End Case Study ��������������������������������������������������������������������297 Chapter 11: End to End DXP Case Study ��������������������������������������������������������������� 299 Drivers and Key Requirements of the Dealer Platform Case Study������������������������������������������� 299 Architecting the Next-Generation Dealer platform �������������������������������������������������������������������� 300 Pain Point Analysis in Current Systems and Processes ������������������������������������������������������� 300 Solution Tenets of Next-Generation Dealer Platform ����������������������������������������������������������� 302 Solution Design Principles ��������������������������������������������������������������������������������������������������� 304 Persona-Based Information Architecture ���������������������������������������������������������������������������� 307 xiii

Table of ConTenTs Persona-Based Design and Information Architecture ��������������������������������������������������������� 308 Functional View of the Next-Generation Dealer Platform ���������������������������������������������������� 310 Seamless and Optimized Business Process ������������������������������������������������������������������������ 312 Open-Source-Based Next-Generation Deal Digital Platform ����������������������������������������������� 313 Innovations and Next-Generation Technologies in Dealer Platform ������������������������������������������ 318 Chapter Summary ��������������������������������������������������������������������������������������������������������������������� 320 Appendix A: Open-Source Tools and Frameworks ������������������������������������������������ 321 HTTP Accelerator ����������������������������������������������������������������������������������������������������������������������� 321 Web Server ������������������������������������������������������������������������������������������������������������������������������� 321 CSS Framework ������������������������������������������������������������������������������������������������������������������������ 322 Scripting Framework ���������������������������������������������������������������������������������������������������������������� 322 User Interface Management������������������������������������������������������������������������������������������������������ 323 Integration ��������������������������������������������������������������������������������������������������������������������������������� 324 Application Server ��������������������������������������������������������������������������������������������������������������������� 324 Server-Level Cache ������������������������������������������������������������������������������������������������������������������� 325 Content Management Systems ������������������������������������������������������������������������������������������������� 325 CMIS ������������������������������������������������������������������������������������������������������������������������������������������ 326 SQL Database ���������������������������������������������������������������������������������������������������������������������������� 326 NoSQL Database ����������������������������������������������������������������������������������������������������������������������� 326 IoT Framework �������������������������������������������������������������������������������������������������������������������������� 327 Distributed Data Streaming ������������������������������������������������������������������������������������������������������� 327 Analytics Engine ������������������������������������������������������������������������������������������������������������������������ 327 Distributed Processing �������������������������������������������������������������������������������������������������������������� 328 Machine Learning Library and Framework ������������������������������������������������������������������������������� 328 Blockchain Frameworks ����������������������������������������������������������������������������������������������������������� 329 Augmented and Virtual Reality �������������������������������������������������������������������������������������������������� 329 Enterprise Search Engine ���������������������������������������������������������������������������������������������������������� 330 Containerization ������������������������������������������������������������������������������������������������������������������������ 330 Containerization Orchestration ������������������������������������������������������������������������������������������������� 331 xiv

Table of ConTenTs Source Code Management �������������������������������������������������������������������������������������������������������� 331 Continuous Integration and Continuous Delivery ���������������������������������������������������������������������� 331 Appendix B: Sample Code ������������������������������������������������������������������������������������� 333 User Interface ��������������������������������������������������������������������������������������������������������������������������� 334 Integration ��������������������������������������������������������������������������������������������������������������������������������� 335 Data Mocking ���������������������������������������������������������������������������������������������������������������������������� 336 Implementation and Logic �������������������������������������������������������������������������������������������������������� 336 Deployment ������������������������������������������������������������������������������������������������������������������������������� 337 Development ����������������������������������������������������������������������������������������������������������������������������� 337 Production ��������������������������������������������������������������������������������������������������������������������������������� 338 Prerequisite ������������������������������������������������������������������������������������������������������������������������������� 338 API Specification and API Mocking ������������������������������������������������������������������������������������������� 339 Swagger-UI ������������������������������������������������������������������������������������������������������������������������������� 339 Swagger-Editor ������������������������������������������������������������������������������������������������������������������������� 340 Swagger-Server ������������������������������������������������������������������������������������������������������������������������ 342 UI Screen Mocking on Node-RED ���������������������������������������������������������������������������������������������� 342 Apache Camel ��������������������������������������������������������������������������������������������������������������������������� 346 Build Automation System ���������������������������������������������������������������������������������������������������������� 347 Run the Integration Application ������������������������������������������������������������������������������������������������� 354 Angular �������������������������������������������������������������������������������������������������������������������������������������� 355 Microservices Architecture ������������������������������������������������������������������������������������������������������� 357 Microservices Components ������������������������������������������������������������������������������������������������������� 358 Docker ��������������������������������������������������������������������������������������������������������������������������������������� 363 Components ������������������������������������������������������������������������������������������������������������������������������ 363 Summary����������������������������������������������������������������������������������������������������������������������������������� 364 Appendix C: Further Reading �������������������������������������������������������������������������������� 365 Index ��������������������������������������������������������������������������������������������������������������������� 367 xv

About the Authors Shailesh Kumar Shivakumar is an author, inventor and working as Practice Lead & Senior Technology Architect at Digital Practice of Infosys Limited. He is an award-winning digital technology practitioner with skills in technology and practice management and has experience in a wide spectrum of digital technologies, including enterprise portals, content systems, enterprise search, and other digital technologies. He has more than 17 years of industry experience and was the chief architect in building a digital platform that won the “Best Web Support Site 2013” global award. His areas of expertise include digital technologies, software engineering, performance engineering, and digital program management. He is a Guinness world record holder of participation for successfully developing a mobile application in a coding marathon. Shailesh is deeply focused on enterprise architecture, building alliance partnerships with product vendors, and has a proven track record of executing complex, large-scale digital programs. He successfully architected and led many engagements for Fortune 500 clients of Infosys and built globally deployed enterprise applications. He also headed a center-of- excellence for digital practice and developed several digital solutions and intellectual property to accelerate digital solution development. He led multiple thought-leadership and productivity improvement initiatives and was part of special interest groups related to emerging web technologies at his organization. Shailesh was awarded the prestigious “Albert Nelson Marquis Lifetime Achievement Award 2018” for excellence in technology and has received numerous honors and awards. He has won multiple awards including the prestigious Infosys Awards for Excellence 2013- 14 “Multi-talented thought leader” under the “Innovation – Thought leadership” category, “Brand ambassador award” for MFG unit, “Best employee award”, delivery excellency award and multiple spot awards, and received honors from executive vice chairman of his organization. He is featured as an “Infy star” in the Infosys Hall of fame and recently led a delivery team that won the “best project team” award at his organization. xvii

abouT The auThors Shailesh holds a Bachelor in Engineering in Computer Science and Engineering and is currently pursuing a doctoral degree in Computer Science. Shailesh has completed an executive management program from the Indian Institute of Management, Calcutta. Shailesh holds numerous professional certifications such as TOGAF 9 certification, Oracle Certified Master (OCM) in Java EE5 Enterprise Architect certification, IBM Certified SOA Solution Designer, and IBM Certified Solution Architect Cloud Computing Infrastructure. He is the sole author of four technical books on digital technologies, which were published by reputed publishers, and has published twelve technical white papers related to digital technologies. Shailesh is the sole inventor of two granted US patents (US9613341 and US10108601) and holds two more patent applications, and is a frequent speaker at events such as IEEE conferences and Oracle JavaOne. Shailesh has also published more than 10 research papers in various international journals. Sourabhh Sethii is a Technology Analyst at Infosys Technologies Limited. His areas of expertise include Blockchain, Internet of things (IoT), machine learning (ML), Java enterprise technology, front-end frameworks, and integration technology. He has hands-on experiences with many technologies like database integration, continuous integration, and security, along with performance analysis and web frameworks like Angular and Node. Sourabhh has worked on multiple domains such as banking, finance, and manufacturing. He has achieved multiple honors like “Most Valuable Player,” “Insta Awards,” and “Best Employee Award” from the heads of his unit in Infosys. He has published many technical white papers. Sourabhh holds Master degree in Software Systems specialized in Data Analytics from Bits Pilani, Rajasthan, India. xviii

About the Technical Reviewers George Koelsch is a retired system engineer who resides in West Virginia, after 33 years in the DC metro area. He started system engineering 42 years ago while in the US Army, and had continued that work for an additional 33 years as a contractor for the Federal Government. With a five-year stint as an Industrial Engineer at Michelin Tire Corporation, he learned to become an efficiency expert, which he then applied to system engineering and project management to tailor the lifecycle development process before his contemporaries in the DC area were doing it. In his spare time, he authored ten nonfiction articles on computers, coin collecting, stamp collecting, and high-energy physics. Apress published his book titled Requirements Writing for System Engineering in October 2016. He now focusses on writing, all his hobbies, and other projects he has time to work on now. Venkata Kakarlapudi is a Senior Technology Architect at Infosys Limited, with over 15 years of industry experience. His areas of expertise include Java, enterprise portals, and Web content management systems. He has experience of implementing multiple large-scale enterprise applications for Fortune 500 companies across geographies. He previously headed a center of excellence for enterprise portals at the digital experience practice in his organization and is part of the core architecture team. He holds an engineering degree in Mechanical Engineering and has completed an executive management program for IT executives from the Indian Institute of Management, Bangalore. xix

Acknowledgments Shailesh would like to acknowledge and thank Verma V.S.S.R.K for their valuable inputs and review comments. Shailesh would also like to recognize and thank Dr. P. V. Suresh for his constant encouragement and immense support. Sourabhh would like to thank his parents (Ritu Sethi and Sat Dev Sethi) and brother (Shrey Sethi), who were the guiding light behind him. The authors also like to immensely thank Mr. George Koelsch for his technical review; his feedback has added great value to the book. The authors want to sincerely acknowledge and thank profusely the Infosys team that includes the managers Jitin Singla, Saumitra Bhatnagar, Vivek Rastogi, Sarweshwar Panda, Sumit Arora, Aditya Kumar Soni, our colleagues and our friends who have facilitated us in accomplishing this task. Special thanks to Rahul Krishan for precious guidance and support. The authors would also like to convey sincere thanks to our mentor and friend Jasleen Khokhar, who read the manuscript at different stages as it evolved from shoot to bud, from flower to fruit. The authors would like to extend thanks to Anchit Madaan (Blockchain Core Team), Deepak Garg, Himanshu Arora, Jaskirat Singh, Babu Krishna Murthy, Kiran Korke, Nishant Satija (Digital Experience Team), and Arpit Kulshrestha. Our special thanks to Shivangi Ramachandran, Rita Fernando, and the editors, technical team, designers, and publishing team at Apress for providing all necessary and timely support in terms of review, guidance, and regular follow-ups. xxi

Introduction As enterprises embark on their digital transformation journey, they define the vision, road map, and objectives of the digital transformation programs. Digital transformation involves legacy modernization, reimagining digital experiences, implementing cloud- first and mobile-first models. Such digital transformation involves various challenges and risk factors including but not limited to niche technology stack, unavailability of skilled resources, long time to market, and such. Enterprises need to carefully evaluate technology trends and future outlook, and invest in the technology stack that caters to their current digital transformation goals as well as their long-term digital vision. Digital experience platforms (DXPs) are an integrated set of technologies and tools that provide best-of-breed modern digital technologies for enterprises. A DXP has a preintegrated set of technology stacks that addresses the risk related to a niche/ unproven technology stack and risky integrations. DXPs are designed on the platform philosophy so that they can be easily extended and scaled to meet future demands of scalability and onboard new innovations. A DXP is one of the most popular approaches for building an enterprise grade digital platform. A DXP provides a set of capabilities to quickly develop a personalized, secure, and scalable enterprise platform. DXPs are designed in such a way that they can incorporate modern digital technology to build next-generation enterprise applications. You can develop your own digital experience platform. The book looks at various open-source tools, technology, and frameworks that can be used for building DXPs. This book covers core concepts to build enterprise grade DXPs. Readers get a holistic view to build DXPs and will be able to transform existing applications to a DXP that is capable of incorporating emerging technologies in near future. DXPs are not just limited to a few commercial products. Enterprises can build their own experience platforms to meet their needs. This book discusses the methods and technology frameworks across various layers to design a DXP. We divided this book into five parts: requirements and design, development, security, infrastructure/NFR, and a case study to cover end-to-end DXP lifecycle scenarios. We discuss proven best practices, design methods, and technology frameworks along with contextual real-world case studies for each of the chapters. xxiii

InTroduCTIon In the requirements and design part, we introduce various concepts of DXPs and elaborate on requirements elaboration methods. We also provide an in-depth discussion of various design elements of DXPs such as UI design, integration design, and such. The chapters in this part cover the requirement gathering phases, functional requirements, and sample use case to develop your own DXP application; user experience requirements to develop your own user interface and mobility requirements to develop your own mobile experience; nonfunctional, social and collaboration, security, infrastructure, disaster recovery, and rollout requirements to develop your own digital experiences platform. This is the first step to develop and analyze the requirements to build an enterprise DXP. The design chapter covers the patterns and architectural strategy along with various layers of the DXP. This chapter also briefly discusses the integration of various emerging technologies such as IoT integration design, Blockchain design, big data, and NoSQL design, and AI automation design along with chatbot case studies, enterprise search engine capabilities, and introduction of augmented reality with DXP applications, along with recent trends in CICD (continuous integration and continuous deployment) using application containerization technique. The development part mainly discusses the detailed design and development of DXP layers such as the user interface layer and integration layer. The chapters in this part cover each and every aspect of developing the user interface using open-source web frameworks, modular UI components and key features, integration of UI components using open source ESB and integration frameworks, UI development lifecycle and best practices, along with a BXP (Banking experience platform) case study. In the security part, we provide an elaborate discussion of information security and overall security of DXPs. The chapters in this part cover the concepts and best practices while developing an application’s security, along with information security policy and principles. The infrastructure/NFR part discusses various quality and nonfunctional attributes such as performance, infrastructure sizing, and such. The chapters in this part cover the NFR(nonfunctional requirements), that is, scalability, availability, performance, modularity, extensibility, and security of the DXP’s application along with quality attributes such as usability, configurability, stability, interoperability, efficiency, flexibility, and maintainability of the platform. Finally, we wrap up with an elaborate digital transformation case study of a legacy system in the last chapter. The case study chapter provides insights into the digital transformation of a legacy application to a Digital experience platform. It covers concepts xxiv

InTroduCTIon like gamification, predictive analysis, dashboards, and chatbots; and technologies like artificial intelligence, Blockchain, and augmented reality are discussed in brief. The book can be used as a reference while using any existing DXP tools or for developing a new DXP from the ground up. Digital practitioners, web developers, and digital architects can leverage the best practices, methods, and technology frameworks discussed in this book. xxv

PART I Requirements and Design

CHAPTER 1 Introduction to Digital Experience Platforms The digital strategy of all organizations primarily focuses on providing rich and engaging user experience. Customer experience-focused strategy leads to increased customer engagement, which in turn increases key success metrics such as site traffic, repeated visits, conversion rate, and such. Digital experience platforms (DXPs) provide an integrated set of technologies built on platform philosophy to engage users throughout their journey. DXPs provide seamless user experience across all user touch points. A DXP is a convergence of all customer-centric technologies such as content management systems, portals, analytics, campaigns, targeting, search, mobile apps, and such. Industries dependent on digital technologies are undergoing rapid disruption mainly fuelled by changing tech-savvy customer expectations, disruption in digital technologies, and due to widespread popularity of mobile devices. Incumbent organizations are undertaking digital transformation exercises to meet the customer expectations and to stay competitive. Organizations can increase their online revenue through user engagement. User engagement also increases cross-sell and upsell opportunities, and increases user retention and lifetime value of a customer. © Shailesh Kumar Shivakumar, Sourabhh Sethii 2019 3 S. K. Shivakumar and S. Sethii, Building Digital Experience Platforms,

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms Boundaryless Banking Enabled by Digital Technologies Tech-savvy banking customers expect the banking experience to match or surpass the best experience of social media platforms, hence it is imperative for banks to understand the trends and enhance the banking experience. Digital banks enable a boundaryless and physical branchless experience supporting these features: • Mobile-first strategy enabled through mobile apps or mobile web platforms • Omnichannel experience (a seamless user experience on all supported devices and browsers) to provide optimal user experience on all access devices • Seamless and simplified processes across all touch points throughout the user journey • Relationship oriented by rewarding loyalty and sustaining long-term partnership with customers • Responsive to market disruptions, changing customer demands, and other requests • Digitized business models to foster the innovation • Rapid innovation in adding digital capabilities In the subsequent section we will briefly discuss DXPs. Overview of DXP DXPs are primarily user-centric engagement platforms that provide a unified view, with rich user interface for enhanced end-user experience. DXPs provide a platform-based approach to enable all the needed digital capabilities. In this book we explore various aspects of a digital experience platform such as user experience design, integration, security, and such. In this regard we will explore the concepts of DXP in understanding the background for using a DXP to build a banking experience platform. In this section we will provide details of the DXP. 4

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms Key Tenets of a DXP The key tenets of DXPs are defined as follows: • Platform orientation with an integrated set of technologies that provides capabilities for presentation, content management, commerce, marketing search, analytics, campaigns, and such. The platform model should also support future extensibility. • Lean and agile platforms with lightweight integration components. A lean model includes lightweight user experience integrated with lightweight service components. • An integrated and personalized view to provide a holistic view of all customer activities across all touch points. This can be achieved by information aggregation from multiple information sources and delivering personalized experiences. • Provide software as a service (SaaS) and cloud deployment option to provide the digital experience as a service. • Provide an integrated experience catering to various business channels such as marketing, sales, and services. • Self-service for end users and for business stakeholders to improve user experience and productivity. • Agility in developing new features and implementing changes for responding to changing market demands. DXP Reference Architecture The reference architecture provides the core services and components that are used in a typical digital experience platform. The services and components enable the needed business capability for the application using the DXP; we will elaborate each of these components in detail shortly. DXP reference architecture is shown in Figure 1-1. 5


Chapter 1 IntroduCtIon to dIgItal experIenCe platforms The core components of a typical DXP platform are as follows. We have identified the core components in each of the layers: • User touch points: This layer consists of various digital touch points the end user uses during the journey. The end user could use smartphones, desktops, tablets, third party services, or wearable and such devices to access the DXP services. Users expect device- optimized, seamless and personalized information access across all digital channels. All user access channels and devices come in this layer. • Presentation services: The DXP provides various presentation services to cater to a wide variety of digital touch points. This includes mobile apps for smartphones, UI frameworks, and responsive design for mobile web applications, web services for third party consumer, and A/B testing for presentation testing. Presentation services are mainly responsible for defining the user interface and user experience. We elaborate presentation services and user touch points in Chapter 4. • Lean portal services: In this category, the portal provides various complementary presentation capabilities such as personalized experience (user experience based on end user preferences and past history), consistent branding, unified view, forms (for user registration, queries, and such), search engine optimization (SEO) (to make web pages more visible), multilingual presentation, and such. • Lean portal services provide business-friendly controls to manage pages (page creation, layout, web analytics, navigation) and brands. • Lean portal services provide a single-stop-shop view of personalized content by aggregating information from various sources. • Web analytics provide vital real-time customer insights, and help in understanding customer activities and interests. These insights can be used for customer segmentation, trend analysis, and targeted content delivery/contextual recommendations. 7

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms • Content services: In this category, the DXP provides various content management services such as content authoring, content tagging, content publishing, content translation, and such. As the DXP provides an integrated set of features, support for various content types, content administration, content templates, content metadata, and other content related services will also be provided by the DXP. Other complimentary functionality such as document management services, digital asset management (DAM) services, content workflows, and metadata management are also included in this category. • Content services provide content lifecycle management features (content creation, content updates, content publishing, content translation) and support a wide variety of content. • Content services provide other features such as rich text editor, content workflows, and such. • Campaign and marketing services: One of the core features of a DXP is to enable digital marketing campaigns. To provide this, the DXP includes features such as campaign management (defining, launching, and monitoring campaigns), audience targeting (sending targeted information to the relevant audience), social media marketing, user segmentation (grouping users based on their interests, access patterns, and such), and customer data management (unified management of customer data across all customer touch points). A DXP provides campaign management features (campaign creation, campaign targeting) and user segmentation (categorizing end users based on demographics, interests and such) in this category. Customer data management (profile data, preferences data, transaction data, and navigation data) is used for understanding customers and provides targeted content. Customer data is used to provide a single view of customer data (activities, preferences, transactions, feed, etc.) in the dashboard. Other marketing functionality such as social media marketing is included as well. • Campaign and marketing services mainly deliver targeted content based on user attributes, preferences, analytics, and such. 8

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms • Analytics services: This includes web analytics-based tracking using predefined metrics, trend analysis, and predictive analytics. • Integration services: Enterprise integration is the most significant component of a DXP. In order to aggregate information from various information sources to provide a unified view, a DXP should support a variety of integration formats and should provide flexible and extensible integration features. Hence a DXP offers standards-based integration methods such as API support, modular services, services support, and plugin support. Most of the DXPs offer built-in support for microservices, REST (Representational State Transfer) and JSON (JavaScript Object Notation)-based services and adaptors for most popular enterprise interfaces (such as databases, enterprise resource planning [ERP], etc.) • The in-built adaptors and integrators improve the productivity of end users and optimize the return on investment (ROI) of the DXP. • DXPs provide standards-based integration options (such as REST- based integration, web services, and such), which can be leveraged for integrating with new products and technologies. • Social and collaboration services: In this category, a DXP provides various collaboration features such as forums, blog, wiki, chat, knowledge base, messengers, communities, calendars, email, and such. These features enable end users to share the information and facilitate a self-service model. The social capabilities enable users to collaborate, harness collective intelligence, socialize, and improve productivity. • Social and collaboration enable users to collaborate and engage customers at social touch points. • Workflow and orchestration: DXPs enable designing and implementing agile, automated, and dynamic business processes through workflow modeling, a configurable rules engine, and workflow governance. 9

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms • Search services: Information discovery is mainly enabled through search features such as site search, content search, and federated search. DXPs also support advanced search features such as result filtering or faceted searching. • Search services improve the user productivity through efficient information discovery. • Commerce services (Optional): Based on the usage domain, DXPs also provide various commerce services such as catalog management, order management, product information management (PIM), inventory management, etc. • Cognitive services (Optional): In this category we have services that leverage artificial intelligence (AI) and machine learning and natural language processing methods to provide personalization recommendations based on insights gathered. • Data services (Optional): This includes services related to data processing such as Big Data services, data migration-related services, and data transformation-related services. • Infrastructure services: In this category, a DXP offers various features such as support for on-premise deployment, cloud deployment, container deployment (deploy code base to run independently for increased robustness and failover), and multitenancy (a single codebase used for multiple-user groups). A DXP also supports other high availability features such as clustering, monitoring, etc. • Workflow and orchestration services: These services are mainly used for orchestration of business processes. This category includes components such as rules engine, workflow governance, and business process modeling tools. • Personalization services: Personalized delivery is an essential feature of any DXP. This module includes preference management, UI customization (ability for user to customize widgets, page layout), 10

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms notification management (alerting and notifying users), subscription management (enabling and disabling of subscriptions for the user), collaborative filtering (recommending products based on their attributes, behavior of similar customers, and such), and AI-based personalization (personalized based on matching learning of users’ interests and activities). • Security: In this category, a DXP offers various authentication and authorization features such as support for an access control list, public–private key infrastructure, web SSO (single sign-on); pluggable adapters, Lightweight Directory Access Protocol (LDAP) integration, Security Assertion Markup Language (SAML) integration, and NT LAN Manager (NTLM) integration. We discuss elaborate security features in Chapters 6 and 7. • DevOps: DXP methodology also supports and uses various open- source DevOps features such as Agile Delivery (such as Agile Management with Slack or Jira); continuous integration or CI (such as Jenkins); iterative testing; container deployment (Docker or Kubernetes); etc. • Other Services: It can also support third-party integration of open- source features available in the market, such as Rules Engine, Journey Analytics (Google web Analytics, Open Web Analytics, similar web, etc.), Appstore support/integration (Google Playstore/Apple appstore), IoT services (Iotivity), wearable services, and reporting services. Evolution and Drivers for DXP In this section we discuss the various stages of evolution of digital platforms and the key drivers of DXPs. Evolution of Digital Platforms Various stages of evolution of digital platforms are shown in Figure 1-2. 11

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms ͻ ĂƐŝĐĚŝŐŝƚĂůƚŽƵĐŚƉŽŝŶƚƐ tĞďƐŝƚĞ ͻ DƵůƚŝƉůĞƚĞĐŚŶŽůŽŐLJƐŝůŽƐ ͻ ŶƚĞƌƉƌŝƐĞƉŽƌƚĂůƐ dĞĐŚŶŽůŽŐLJ ͻ ŽŶƚĞŶƚŵĂŶĂŐĞŵĞŶƚƐLJƐƚĞŵƐ;D^Ϳ WůĂƚĨŽƌŵƐ ͻ ŶƚĞƌƉƌŝƐĞƐĞĂƌĐŚ ͻ ŽŶƚĞŶƚŵĂŶĂŐĞŵĞŶƚ͕ĞŽŵŵĞƌĐĞ ŽŵĂŝŶͲ^ƉĞĐŝĨŝĐ ͻ ŽŵĂŝŶͲƐƉĞĐŝĨŝĐĨĞĂƚƵƌĞƐ ŝŐŝƚĂůWůĂƚĨŽƌŵƐ ͻ dƌƵůLJĞŶŐĂŐŝŶŐĐƵƐƚŽŵĞƌĞdžƉĞƌŝĞŶĐĞ ͻ ŐŝůĞ͕ƐĞůĨͲƐĞƌǀŝĐĞ͕ŽŵŶŝĐŚĂŶŶĞůĞŶĂďůĞĚ yW ͻ /ŶƚĞŐƌĂƚĞĚƉůĂƚĨŽƌŵ͕ƵƐĞƌͲĐĞŶƚƌŝĐ͕ƉĞƌƐŽŶĂůŝnjĞĚ Figure 1-2. Digital platform evolution The evolution of the digital eco system is depicted in Figure 1-2. During initial stages, web sites were mainly used for information delivery. Web sites needed to be integrated with multiple backend systems and services needed for the business. The next stage of the digital ecosystem was technology platforms such as enterprise portals, CMS, search engines, analytics engines, and such. These technology platforms addressed specific concerns of the enterprise applications. For instance, enterprise portals mainly addressed concerns related to presentation, information aggregation, and personalization; CMS managed the end-to-end lifecycle of content and search engines handled the indexing and searching related concerns. In this scenario we needed multiple enterprise products to build a digital solution. The next step in the evolution was domain-specific digital platforms. For instance, CMS-specific digital platforms provided basic presentation, basic search and ready-to-use integrators/plugins for search engines, and campaign management systems. Similarly, e-commerce platforms provided storefront portals and basic content management capabilities. These prebuilt/out-of-the-box capabilities built around the core capabilities reduced the number of products and technologies that need to be integrated. 12

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms Digital experience platforms are the next step in the evolution journey. DXPs provide a preintegrated stack to use and extend for any enterprise digital solution. Some of the challenges addressed by DXPs are shown in Table 1-1. Table 1-1. DXP Challenges and Solutions Challenge Description How DXP Addresses It technology • too many products and technologies • dxps provide preintegrated stack and complexity for adding to the overall technology provide all necessary capabilities for building enterprise complexity. building enterprise digital solutions. application • too many integrations involved products. performance • traditional web platforms tend • dxps are built on a lean model and availability to be “heavy” for installation and offering lean uI frameworks/products challenges maintenance, and pose performance for rich user experience needs. challenges. • Cloud-native dxps are well equipped • too much integration is also causing to handle the availability and on- performance, scalability and demand scalability challenges. availability issues. productivity • the inherent complexity of the • dxps can be configured and extended challenges traditional platforms is resulting in to build needed capabilities. greater time for implementation. • preintegrated technology stack • missing common, reusable and development tools improve component and frameworks. productivity. not aligned with • traditional digital technologies • dxps can be used to implement digital overall digital and products pose challenges strategy, as it provides all the necessary strategy in fully implementing digital building blocks of digital technologies strategy elements such as mobility with extensible architecture. enablement, analytics, and cloud • dxps support and provide modern digital technologies such as collaboration tools, aI tools, and mobile apps. high maintenance • high software licensing and support • a dxp is a single, modern product and infrastructure costs. offering combined functionalities in an cost • high development, testing, and skill overall digital space. costs involved. 13

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms Business Drivers for DXP Listed in Table 1-2 are the key business drivers across various industry verticals. We will elaborate on these in the contextual case studies in coming chapters. Table 1-2. DXP Drivers and Business Scenarios Vertical/Industry Domain Drivers and Key Business Scenarios retail and digital commerce • lightweight and agile platforms with hyperpersonalization, catering to customer intent to drive conversions • user journey optimization and user engagement across all digital touch points and access channels • Integration of online (chat, call center, web, mobile, and offline channels (brick-and-mortar stores) • aI (artificial intelligence) and machine learning-based predictive analytics, recommendations, and personalization • unified view of customer actions and information • other features are conversational commerce, virtual assistants, augmented reality, marketplace integration, apI-based backend integration (also known as “headless” mode), and multitenancy model. marketing and sales • Campaign management • personalized/targeted content delivery • Customer segmentation • Configurable and extensible product • social marketing • Brand management • micro site management • Campaign management (continued) 14

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms Table 1-2. (continued) Vertical/Industry Domain Drivers and Key Business Scenarios Insurance • product comparison tools • mobile apps that provide services related to quotes, claims, service requests, policy management • Customer self-service related to policy management, service requests, payment and profile management • advanced analytics for fraud detection • Campaign management, lead management manufacturing • Convergence of B2C (business to consumer) and B2B (business to business) channels • Information delivery • Collaboration • unified dashboard view Customer service • self-service • Knowledge management • search and information discovery • Collaboration tools and collective intelligence harnessing tools such as wikis, blogs, forums, communities • aI-based virtual personal assistants (Vpas), chatbots • machine-learning based contextual recommendations • social media integration Common business drivers • lower operational cost and continuous improvement across all verticals • data-driven decision making • self-service • faster time to market through agile delivery and maximal reuse of out-of-the-box platform components • agile delivery • frictionless and automated processes and improved productivity 15

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms We have detailed various digital transformation case studies and scenarios for a DXP. In subsequent sections we will look at the details of banking experience platform as an example implementation of a DXP. DXP principles can be applied to design other experience platforms as well. Overview of Banking Experience Platform We will look at the core features of the banking experience platform. Note the banking experience platform referred to in this book mainly refers to the retail/consumer banking solution used by banking customers. Key Tenets of Banking Experience Platform The primary motivation of a banking experience platform is to provide a holistic and engaging user experience for the online customers of the bank. This book elaborates on building a banking experience platform to fulfill this vision. The primary tenets of a banking experience platform are as shown in Table 1-3. We will elaborate on these platform tenets in Chapters 3, 4, and 5. Table 1-3. Key Tenets of a banking Experience Platform Key Tenets of banking Attributes experience platform Integrated view single-stop-shop experience, aggregation of data from all interfaces personalized experience relevant and contextual information delivery, role-based access Intuitive user experience Interactive and response user interface, omnichannel access self-service enhanced information discovery, smart search, comparison tools, calculators, decision-aiding tools secured transactions easy to use, and simplified and secured transactions 16

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms The main features of a future-state banking XP is depicted in Figure 1-3. hƐĞƌ džƉĞƌŝĞŶĐĞ ŽŶƚĞŶƚ ŽůůĂďŽƌĂƚŝŽŶ ^ĞĐƵƌŝƚLJ DŽďŝůŝƚLJ 'ŽǀĞƌŶĂŶĐĞΘ ůĞƌƚƐΘ ^ĞƌǀŝĐĞ tŽƌŬĨůŽǁƐ EŽƚŝĨŝĐĂƚŝŽŶƐ /ŶƚĞŐƌĂƚŝŽŶ ZĞƉŽƌƚƐΘ Z^^&ĞĞĚƐ ^^K/ŶƚĞŐƌĂƚŝŽŶ >W ĂƐŚďŽĂƌĚ /ŶƚĞŐƌĂƚŝŽŶ ^ĞĂƌĐŚ ŶĂůLJƚŝĐƐ &ƵƚƵƌĞ^ƚĂƚĞ ĂŶŬŝŶŐyW Figure 1-3. Key features of a modern banking experience platform As depicted in the diagram, a future state banking XP needs a responsive and omnichannel-enabled use experience, engaging content. Collaboration features such as chat, blogs, and forums enable active participation of end users. The banking XP should ease the integration with security systems and provide service-based interfaces for consumers. The platform should provide timely alerts and intuitive visualizations (charts, reports, dashboards) to help the customer in decision making. Search is the key information discovery tool for the banking XP. Analytics enablement helps in personalization of the user experience. High-Level Requirements of Banking Experience Platform Table 1-4 shows the high-level requirements of a banking XP categorized into main categories. We discuss these requirements in Chapter 2. 17

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms Table 1-4. High-Level Requirements of a Banking Experience Platform Requirement Category for High-Level Requirements Banking XP user experience Customer-centric design, lightweight/lean uI, responsive uI elements, mobile apps, dashboard uI, simple and easy-to-use interfaces, high usability, intuitive information architecture, personalization security authentication, authorization, sso, flexible login methods, multifactor authentication, adaptive authentication, auditing enterprise integration Integration with needed enterprise interfaces such as core banking systems, commerce platforms, erp systems, enterprise services and interfaces, light- weight services user engagement features personalization, profile management, gamification (using gaming concepts such as points, scores, and badges to enhance and encourage user participation), contextual content delivery, social media integration, self-service tools, analytics, collaboration (chat, blog, wiki, forums, document sharing, etc.), dashboard views, profile management, review and rating, alerts/notification, localization and such self-service tools reports, search, calculator (related to loans, policies, etc.), tools (such as risk profiling tool, budget planning tool, need analysis tool), incident management optimized processes Quicker registration, account opening process, bill payment process, funds transfer process analytics Customer behavior insights, navigation patterns, metrics-based tracking, user segmentation, anytime anywhere availability Cloud enabled, platform accessible on all devices and browsers, disaster recovery capabilities Content management Campaigns, web content, promotion content, publishing, content workflows 18

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms The sample objectives for a banking XP are shown in Figure 1-4. /ŵƉƌŽǀĞŽŶůŝŶĞƌĞǀĞŶƵĞ /ŵƉƌŽǀĞĐƵƐƚŽŵĞƌƐĂƚŝƐĨĂĐƚŝŽŶ &ĂĐŝůŝƚĂƚĞŐƌŽǁƚŚŽĨĚŝŐŝƚĂůĐŚĂŶŶĞůƐ ƌĞĂƚĞĐŽŵƉĞƚŝƚŝǀĞĂĚǀĂŶƚĂŐĞŝŶ ĚŝŐŝƚĂůƐƉĂĐĞ /ŶƚĞŐƌĂƚĞǁŝƚŚƉĂƌƚŶĞƌƐŝƚĞƐ ƵƐŝŶĞƐƐ ZĞĚƵĐĞƚŝŵĞƚŽŵĂƌŬĞƚ >ŽǁĞƌĐŽƐƚŽĨŵĂŝŶƚĞŶĂŶĐĞ ŽďũĞĐƚŝǀĞƐ džƚĞŶƐŝďůĞĂŶĚƐĐĂůĂďůĞ ZĞĚƵĐĞĚŝŶĐŝĚĞŶƚǀŽůƵŵĞ͕ ƉůĂƚĨŽƌŵ ƚŝĐŬĞƚǀŽůƵŵĞ KƉĞŶƐƚĂŶĚĂƌĚƐ ƵƚŽŵĂƚĞĚŵĂŝŶƚĞŶĂŶĐĞ DŝĐƌŽƐĞƌǀŝĐĞƐďĂƐĞĚƐĞƌǀŝĐĞ WƌŽĚƵĐƚŝǀŝƚLJŝŵƉƌŽǀĞŵĞŶƚ ĂƌĐŚŝƚĞĐƚƵƌĞ ƵƐŝŶĞƐƐƉƌŽĐĞƐƐ >ŽŽƐĞůLJĐŽƵƉůĞĚ ŽƉƚŝŵŝnjĂƚŝŽŶ &ĂƵůƚƚŽůĞƌĂŶƚĂŶĚŚŝŐŚůLJ ĂǀĂŝůĂďůĞ KƉƚŝŵŝnjĞĚƉĞƌĨŽƌŵĂŶĐĞ KƉĞƌĂƚŝŽŶĂů dĞĐŚŶŽůŽŐLJ ŽďũĞĐƚŝǀĞƐ ŽďũĞĐƚŝǀĞƐ Figure 1-4. Key objectives of a banking experience platform Sample reference architecture of a banking XP is given in Figure 1-5. 19

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms orm f t a l ience p er xp g e in nk a f a b e o ur t c ite h c r ence a fer e R e 1-5. ur ig F 20

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms The banking XP is typically a layered system providing a loosely coupled platform. The platform will be used by customers, admin, and bank staff. The core platform consists of three layers: presentation layer, business layer, and integration layer. The presentation layer provides user interface components such as widgets, pages, web analytics, localization, personalization, and visualization components. These components define and impact the end-user experience. The business layer consists of core business components to implement the business logic, transactions, and workflows and provide collaboration features. The integration layer provides integrators and plugins to interact with enterprise interfaces through lightweight services. Enterprise interfaces include customer relationship management, wealth management systems, content management system, document management system, search engine, enterprise services, enterprise resource planning, core banking system, enterprise service bus, etc. The platform also provides various utilities and accelerators such as loggers, caching components, and taxonomy and exception handlers. Three Ps of BXP The three Ps of BXP are as follows: • Purpose: Customer satisfaction, customer retention, growth of digital services, integration with other partners, reduce time to market. • Process: Banking organization assessment of each major value stream to make sure each step is valuable, capable, available, adequate, flexible, and that all the steps are linked by flow, pull, and leveling. • People: Bank customers, admin, and bank staff. Sample Technical Capabilities of Banking Experience Platform Table 1-5 is a sample list of technical capabilities for a banking XP: 21

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms Table 1-5. Technical Capabilities of a Banking Experience Platform Capability Group Capabilities presentation • mobile-first components • responsive and interactive user interaction elements • user experience management • Consistent user experience across channels • Intuitive dashboard providing unified view of transactions across all channels • Intuitive visualizations (charts, graphs, reports) • omnichannel access • Web analytics • a/B testing • Web analytics personalization • user profiling • segmentation • analytics-driven personalization • targeted marketing security • Identity management • single sign-on (sso) • encryption • adaptive security • multifactor authentication • fraud detection • flexible authentication methods • data security (continued) 22

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms Table 1-5. (continued) Capability Group Capabilities Web content • Common content types, templates, and workflows management • taxonomy and metadata management • Content preview • Content Versioning and life cycle management • federation and syndication • digital marketing Intelligent information • Indexing access • search • Information access administration • federated search • standard connectors • Content query Integration • managed service consumption • Information aggregation from all relevant data sources (transactions, risk score, etc.) • data consumption • Information aggregation across all channels and touch points • transactions transaction • secured transaction manager management • payment manager • funds transfer (continued) 23

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms Table 1-5. (continued) Capability Group Capabilities enterprise Integration • light weight services layer (microservices) • services-based integration. • partner integration (third-party apI) social and collaboration • social listening • forums, chats, communities • external social media collaboration • training and self-learning content other features • transaction reporting • search • tools (forecasting tools, comparison tools, reporting tools, self-service tools) • enhanced analytics (what-if scenarios analysis tools, smart recommendations, cross-sell insights) • Well defined governance and processes • defining single source of truth • Incident management • gamification • Cloud enablement • use of aI features such as chatbot (rule-based chatbot or predictive- based chatbot), recommendation, data analytics, and such Sample Key Performance Indicators of Banking Experience Platform In order to measure the success of the banking XP, we use following key performance indicators (KPIs): • Increased business transactions: The enhanced banking XP should make it easier for online banking customers to carry out transactions. 24

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms • Improved user satisfaction: The banking XP should improve the usability thereby improving the overall user experience. • Faster time to market: The banking XP should provide optimized processes and reusable technical building blocks that reduce launch time of new releases. • Reliability, availability, and performance: The banking XP should provide a reliable and highly available platform to provide an enhanced user experience. Digital Imperatives for Modern Banks Disruptions in digital technologies are impacting modern banks. Banks are heavily adopting digital technologies to remain competitive. Given below are the key digital imperatives for modern banks: • A mobile device is the primary access channel for accessing web applications. So banks should provide mobile friendly web or apps for mobile platforms. • Digital banks are one of the emerging trends, wherein the banks provide branchless digital banks that solely rely on digital channels. • Increasing use of gamification concepts by rewarding banking customers for their online transactions and activities. • Increasing use of AI tools such as chat bots, personalized recommendations, etc. • Money management tools (such as spend analyzers, budget planner, debt analyzer) and self-service tools are increasingly used in digital banks to aid customer decision making and to minimize information clutter. • Digital payments and digital wallets are some of the features gaining momentum in digital banking channels. • Social banking that actively leverages social and collaboration features is one of the most popular features in the digital bank. • Optimized and simplified processes (such as 1-step registration, or a simplified customer acquisition process) 25

Chapter 1 IntroduCtIon to dIgItal experIenCe platforms Summary • Digital experience platforms (DXPs) manage the business processes and decrease time required from development to production. • DXPs provide cost effective digital services to customers. • Multiple technologies, lean structure, and digital touch points collaboratively enhance the overall digital experience. A DXP is a highly flexible way to develop as well as interact with digital services. • The main idea or methodology behind the DXP is it has lean structure, which delivers maximum to the end customer with minimum cost on the resources. • DXPs make the complete production and digital service delivery process efficient. Different technologies optimize and speed up the process. • A DXP can manage employees and customers of organizations on a single platform. • A DXP can be single point for organizations to digitize business process. • A DXP provides holistic user experience to all the stakeholders of organization. 26

CHAPTER 2 Gathering Requirements Requirement gathering is one of the critical functions to ensure the success of a system and platform. Digital Experience Platform (DXP) certifies the successful delivery of the project that covers omnichannel as well as crossed-channel requirements. A DXP focuses on developing and delivering a platform where an application is developed once and deployed everywhere. A DXP provides omnichannel capabilities by providing reusability of user interface (UI) components (also called widgets or portlets) and manageable content. A DXP supports native applications. Besides functionality typically delivered by these web-based UI components, content is made reusable between channels, that is, Web, mobile device, tablet, interactive voice response (IVR), and automatic teller machines (ATMs), etc. and platforms, that is, Web, Android, iOS, etc. as shown in Figure 2-1. ATM IOS Desktop DXP Mobile Android IVR Figure 2-1. Omnichannel © Shailesh Kumar Shivakumar, Sourabhh Sethii 2019 27 S. K. Shivakumar and S. Sethii, Building Digital Experience Platforms,

Chapter 2 GatherinG requirements The requirement elicitation and elaboration process enhances DXP application requirement gathering and analysis. Requirement elicitation and elaboration is the process of gathering and analyzing requirements. In this process, the developer along with the system engineer interact with the systems, stakeholders, documents, and case study of existing applications along with proof of concepts done by teams. These requirement elicitation and elaboration methods are best suited for gathering digital platform requirements, but there are other methods also that can be used for requirement elicitation and elaboration. • Requirement workshops: Workshops are beneficial on the grounds that business analysts want to take stakeholders’ opinions and consensus. Workshops could be combined with brainstorms for discovering requirements, where ground rules are predetermined at the outset of the workshop. • Workshops help business analysts to build mock-ups or prototypes for refining and validating requirements. • Workshops could also include a walk-through for reviewing requirements. • Stakeholder interviews: Stakeholder interviews can lead toward success of the application, although stakeholders come in all shapes and sizes. The motive of the interview is to talk with those people who will spend most of the time using the things you plan to design, though it would help to first determine what that thing actually is. • Documentation study: It helps to understand the existing systems and challenges, so that they are incorporated in the new system. For example, understanding existing systems and their configurations helps us to integrate the existing system’s components with the 28

Chapter 2 GatherinG requirements DXP application. It further assists in maintaining the integrity of the system, as well as aiding understanding of the requirements. • AS-IS system study: You should go through other existing applications in the organization; it will further assist you to incorporate the existing service with the DXP applications. You should model the user journey and do pain point analysis, which help you to understand the pain points faced by customers in the existing system. Process study that is studying and analyzing the domain and process involved in the domain. Study activities include management, and the technical and professional people who are familiar with the processes involved in the systems. The gathered information is used to identify existing gaps, which helps you to optimize the business process. • PoCs (proof of concepts): Proof of concept is also known as proof of principle. A PoC is a small exercise to test the design or idea. PoCs help the team to understand functionality and estimate complexity, which will further aid in developing the DXP application. • Benchmarking competitor sites: The purpose of benchmarking is to interpret and gain a level of insight that allows you to evolve a digital strategy based on competitor insight. It helps you to understand the potential customer and further aids in estimating performance and capacity-related requirements. • Questionnaires: An effective questionnaire helps you to decide the actual user requirements. The answers can be used to analyze the results. When the number of stake holders is greater, or the resources and funds are less, then a questionnaire is the best method to analyze the requirements. The questionnaire should be well defined and effective. All the questions should be relevant to the requirements. 29

Chapter 2 GatherinG requirements Figure 2-2. Requirement elaboration Figure 2-3 will help you to understand the elaboration phases and associated requirements. For example, functional requirements can be gathered through requirement workshops, system study, and stakeholder interviews. 30

Chapter 2 GatherinG requirements Requirement Stakeholder Documentation AS-IS POCs Bench marking Workshops Interviews Study System Study (Proof Competitor Sites of Concepts) Functional Requirements Experience Gathering Requirements Gathering Mobility Requirements • Requirement workshops • Requirement workshops • Requirement workshops • Stakeholder interviews • Stakeholder interviews • Stakeholder interviews • AS-IS system study • Bench marking competitor • PoCs (Proof of Concepts) sites Accessibility and Social and Security Non-Functional collaboration Gathering Requirements Gathering Requirements Gathering • Requirement workshops • Stakeholder interviews • Stakeholder interviews • Stakeholder interviews • Documentation study • AS-IS system study • Information and integration • PoCs (Proof of Concepts) • PoCs (Proof of Concepts) system study • Documentation study Figure 2-3. Requirement gathering You will look into banking experience platform (BXP) use cases throughout this chapter. Now we would look into use case as well as user stories, describes the system interaction with the environment and actors; it contains a detailed description of the following objectives, which provide detailed descriptions about how a user interacts with the system and how the system will respond to the user’s action. • Actors • Preconditions • Postconditions • Alternative paths • Main scenario A use case captures all the possible ways the user and system interact and a detailed description about goals and results. We prefer use case over user stories (also called scenarios). User stories are simplified descriptions of the user’s requirements, and are based on the 3Cs: card, conversation, and conformation. • Card: User story written as cards, and each user story has a short description about the story. 31

Chapter 2 GatherinG requirements • Conversation: Requirements are gathered and refined through the continuous conversation between the users and development teams. Ideas and implementation design are acknowledged during the meeting with stakeholders. • Conformation: Acceptance criteria of the user story are acknowledged during discussion about requirements with stakeholders. The user of the system confirms the conditions in which working software would be accepted or rejected. User stories are easy to read, but a platform approach needs a more granular approach and detailed description about how the system will act. While doing use case analysis, we are designing a functional flow that meets the user’s need. The digital platform-based approach is different than agile-based projects in terms of number of technology, framework, and systems involved in it; hence, behavior of the system should be analyzed in detail so that you are able to integrate and implement multiple technology, framework, and system efficiently and effectively. In this chapter, you will examine the prospects of a DXP’s requirements. • Functional requirements • Experience requirements • Mobility requirements • Security requirements • Nonfunctional requirements • Accessibility requirements • Social and collaboration requirements Let’s begin with the functional requirements for a BXP. Functional Requirements The purpose of the functional requirements or functional specification document (FSD) is to understand the business requirement, develop a digital experience platform for an organization, and serve the needs of the client by workflow optimization and innovation of the business process. 32

Chapter 2 GatherinG requirements An insight into the BXP use case of account and transaction in an ABC online banking portal is shown in Tables 2-1 and 2-2. Table 2-1. Account Use Case Details Use Case ID: 1 Use Case Name: Accounts Date Created: XX-XX-XXXX Last Revision Date: XX-XX- XXXX User goals: to be able to view the account details Primary actors: 1. Logged-in customer of the aBC bank Secondary actors: 1. master data management mDm) system 2. Core banking system (CBs) Description: Customer can view account details on dashboard on landing page, along with user profile data. Trigger: Customer wants account summary to be displayed on the screen. Customer should also be able to view details of account statement along with aggregated balance of all the accounts held. Preconditions: 1. Customer should be an existing registered customer. 2. Customer will be logged in to aBC online banking application. Postconditions: 1. all accounts of the customer are displayed on the screen. Functional flow: Following are the points to be considered for displaying account summary. Account Summary 1. Customer logs in with user iD and password. 2. Customer clicks on accounts ui component on left-hand side of the landing page. 3. all accounts list will be displayed with the balance, along with aggregated available balance of saving/current accounts and outstanding balance of account and transaction details. • For example, savings account will show consolidated balance of all saving accounts along with individual savings account number, and current account will show consolidated balance of all current accounts along with individual current account number. (continued) 33

Chapter 2 GatherinG requirements Table 2-1. (continued) Use Case ID: 1 Use Case Name: Accounts Date Created: XX-XX-XXXX Last Revision Date: XX-XX- XXXX Exceptional flow: Backend system is not responding. 1. When back-end systems are not working, the ui component will show a human understandable error message to customer. 2. the error message that will be displayed is “Sorry our systems are not working; please log in after some time.” Assumptions: na Validations: 1. account status validation: One holds many accounts in a bank; the system will display those accounts that have view permission, as per following table. Value (Sent in web-service Validation response) Open View DOrm View unCL not applicable inOp View CLOs not applicable preCreateD not applicable Track changes: na Out of scope: na 34

Chapter 2 GatherinG requirements Table 2-2. Transaction Use Case Details Use Case ID: 2 Use Case Name: Transactions Date Created: XX-XX-XXXX Last Revision Date: XX-XX- XXXX User goals: to be able to view the transaction history Primary actors: 1. Logged-in customer of the aBC bank Secondary actors: 1. Core banking system (CBs) 2. simple mail transport protocol (smtp) Description: Customer can view the ministatement. Customer can download or e-mail statement. Trigger: By default, customer wants ministatement displayed on the screen. Customer should be able to download statement on their machine. Preconditions: 1. Customer should be an existing registered customer. 2. Customer will be logged in to the aBC online banking site. 3. Customer has selected the account to view statement and account details. Postconditions: 1. mini or detailed statement is displayed on the screen. 2. Detailed statement is downloaded in pDF format. Functional flow: Following are the points to be considered for transaction details: account statement 1. after login, customer will be landed on dashboard. 2. Dashboard will contain the transaction ui component (widget), which will display ministatement. 3. ministatement will have details of last ten transactions. 4. ministatement will be displayed on the screen with following details: date, expense type, description, credit or debited amount, and balance. 5. Customer can filter the transactions by selecting From date and to date to display detailed statement. (continued) 35

Chapter 2 GatherinG requirements Table 2-2. (continued) Use Case ID: 2 Use Case Name: Transactions Date Created: XX-XX-XXXX Last Revision Date: XX-XX- XXXX Alternative Flow: 1. Customer can choose to send the statement via e-mail or download it in excel or pDF format; respective buttons will be provided. Exceptional Flow: 1. if there is no transaction in the account, appropriate message will be displayed: “Transaction details are not available for this account.” 2. Backend system and web-service calls are not responding. 3. error message will be displayed: “Sorry our systems are not working; please log in after some time.” Assumptions: na Validations: 1. From date cannot be prior to account opening date and to date cannot be greater than today’s date. 2. From date and to date period is six months. Business rules: 1. maximum period to display or download or mail a statement is six months at a time. Track changes: na Out of scope: na The use case shown in Tables 2-1 and 2-2 should help you understand how the BXP application interacts with multiple systems and platforms to provide an omnichannel experience to the bank’s customers. The BXP interacts with the MDM system, core banking system, and SMTP mail server and provides cross-channel capabilities where the user can log in to the BXP from a mobile device or desktop and get the same experiences across all platforms. Experience Requirements Let’s look at experience requirement for a BXP. The purpose of the experience requirements is to understand workflow across all channels, to provide a seamless and smooth user experience to the customer. Experience requirement help you to 36

Chapter 2 GatherinG requirements choose a technology stack for the DXP. The user story is the best option while gathering experience requirements, because the experience specifications of the application are explained from a business point of view. Business and management will explain the specific features and channels that they want to provide to their users. The DXP is designed for the entire user journey. The DXP provides a better user experience with your organization through multiple channels. You should understand when and why users move across channels, which further helps you to design efficient and smooth user experiences. The DXP should provide zero or minimal overhead while transiting from one channel to another. Seamless Experience on All Supported devices The user interacts with the application from multiple channels, that is, Web, mobile device, tablet, e-mail, chatbot, and IVR, etc. (as shown in Table 2-3). Experiencing failure on any channel reflects a bad experience as a whole. You should consider the workflow by considering all channels supported by your organization. You need to consider touch points requirements across all channels. For example, consider a scenario where a user makes a service request using a web application on a desktop, but is unable to complete the process or is confined due to any personal reason. The user can still continue the process on their mobile device. If they can pick up from where they left off, their user experience will be seamless. Table 2-3. Device Support User Story Name Device Support trigger Customer wishes to access a banking portal from different devices, that is, mobile, tablet, or desktop. script a customer can access the banking portal application on a mobile device, tablet, or desktop. a person will be able to continue an action that is left off in a previous session, irrespective of the device that person was working on. acceptance the customer will be able to access the BXp application on a mobile device, tablet, criteria or desktop. 37

Chapter 2 GatherinG requirements Seamless Experience on All Supported Browsers The user can interact with your application from multiple web browsers. Therefore, once the application is developed, it is supported across all the latest browsers: that is, IE 10 and above, Chrome 2.0 and above, Firefox, etc. See Table 2-4. Table 2-4. Browsers Support User Story Name Browsers Support trigger Customers can log in to the application from different browsers. script a customer can log in to the BXp application through the following browsers: • ie 10 and above • Chrome • Firefox acceptance criteria the customer will be able to access the banking portal on ie, Chrome, or Firefox. Multilingual Requirements You need to consider language criteria on the basis of business requirement while developing a DXP application. A DXP provides the capability to store language preference in user preference. On the basis of language preference, content will be shown to the user. See Table 2-5. Table 2-5. Language Support User Story Name Language Support trigger the customer can select the language of the content. script a customer can select the preferred language while registering into the BXp portal. One can select from the following languages: • english • hindi • German • French after login to the BXp portal, one would get the content according to one’s preferred language. acceptance criteria the customer is able to get content on the basis of preferred language. 38

Chapter 2 GatherinG requirements Navigation Elements, Menus, and Search An experience is either a website or a mobile application. Each of these experiences consists of pages. A page consists of containers and UI components. The visible elements of an experience are the pages, the containers, and the UI component. Pages have containers and UI component as children. Containers can have other containers or UI component as children. A page has an associated URL, stored in a link. The UI component displays the content or functionality. Containers group UI components together in a visual layout. We will go through these components in detail in Chapter 4. Navigational routers and elements help to navigate from one location to another, to enhance the user experience. Navigation routers are able to provide menus in an efficient and interesting way, and search capability enhances the accessibility features. DXP search capability helps you to find the intent of the user, to provide the most precise result. These components help to provide information in an appealing as well as an organized way. An example is a banking dashboard, where the user is able to get frequently visited UI components, that is, user details, accounts, and transactions related to a specific account on one single page. You should consider the user experience journey before developing UI components. Every user story is bifurcated into individual functionality, and these individual functionalities are considered to be one UI component. For example, in the case of the dashboard user story in Table 2-6, Account is considered one functionality and Transaction is considered another functionality; that means creating two UI components: one for accounts and another for transactions. Table 2-6. Dashboard User Story Name ABC Bank’s Dashboard trigger as a customer, one wishes to view account summary and transaction statement on one’s dashboard after login to the banking portal. script as a customer, after login to the portal one can see a navigational plane on the left hand-side and component plane on the right-hand side. as a customer, one can navigate to another page through the navigational router plane. account and transaction are presented in the component plane on the right-hand side. acceptance criteria the customer is able to get frequently visited ui components, that is, user details, accounts, and transactions related to a specific account on one single page. 39

Chapter 2 GatherinG requirements The navigational router will be the dashboard, whereas user details, account, and transaction will be different UI components in multiple containers, as you see in Figures 2-4 and 2-5. Searching and filtering transactions enhance accessibility. DXP Page Layout Container Presentation Presentation Component A Component B Presentation Presentation Component C Component D Figure 2-4. User interface components Figure 2-5. BXP dashboard We will go through the BXP dashboard in detail in Chapter 4. 40

Chapter 2 GatherinG requirements Mobility Requirements Nowadays you should be future ready. BXPs support native applications, that is, a smartphone application developed specifically for a mobile operating system as well as hybrid applications (i.e., a hybrid application at its core is websites packed into a native wrapper). You have to consider mobility requirements while developing the DXP application. Table 2-7. Mobility User Story Name Mobility trigger the customer should be able to access the BXp application on android and iOs platforms along with web support. script as a customer, one will be able to download a BXp mobile application from iOs app-store and android play store. acceptance the customer will be able to download the BXp application to a mobile device and criteria be able to access all functionality provided on a web application through the mobile application. The DXP supports responsive, native as well as hybrid applications approach. While designing a responsive application, you need to consider the mobile-first approach. From a general point of view, mobile designing is the hardest as compared with other devices, in view of the small screen to which you can provide essential features. In an opposite approach, if you design the all-inclusive right from the start, the core and supplementary elements merge and it will become difficult to distinguish and separate. Mobile first is equivalent to content first, due to limited screen size and bandwidth; therefore you should prioritize content. A responsive web approach would have a lack of interaction with mobile features like sensors, camera, etc. Native applications and hybrid applications provide additional features to interact with device hardware, for example, fingerprint readers, camera, etc. Consider a scenario where you want to give a notification feature to your user: a native application or hybrid application is configured with push notifications features, so whenever a user does a transaction, these applications push notification to the user’s mobile device. A hybrid application has the advantage of a single code base, which makes it compatible with all browsers and 41

Chapter 2 GatherinG requirements devices, whereas a native application has the advantage of providing a highly interactive and rich experience, and exploiting the entire native device features such as sensors and camera, etc., and provides high performance over responsive and hybrid applications. Most Valuable Player Responsive Web Native Hybrid Application Application Application • Advantages • Advantages • Advantages 1. Capability to view in 1. Push notification 1. One code base mobile browsers 2. Interaction with 2. Save time and device hardware money • Disadvantages • Disadvantages • Disadvantages 1. Push notification 1. More than one code 1. Performance 2. Interaction with base device hardware 2. Cost more and Increase build effort Figure 2-6. Responsive vs. native vs. hybrid You need to go through the usage of the application because a hybrid application is a web application (shown in Figure 2-7), built using HTML 5 and JavaScript’s wrapped-in native container, which loads most of the information on the page as the user navigates through the application, whereas native applications instead download most of the content when the user first installs the application. 42

Chapter 2 GatherinG requirements Figure 2-7. BXP mobile dashboard (Left: dashboard view; Right: navigation view) The native application has the best performance and highest security. The performance of the application as well as the user experience vary significantly, based on the development framework chosen, along with the native application approach, the overall performance, and security improves. Nonfunctional Requirements Nonfunctional requirements (NFRs)—also known as quality attributes—decide the robustness and long-term success of the DXP. The quality attributes such as scalability, usability, reliability, availability, maintainability, and performance are the key NFRs that help us to define, track, and measure the success metrics of the digital platform. 43

Chapter 2 GatherinG requirements There are other NFRs also, like serviceability, security, regulatory, environmental, data integrity, usability, interoperability, etc., but RAM (reliability, availability, and maintainability) is most pertinent to a DXP. These requirements help to understand the operations of the system rather than specific behavior. Consider a scenario where you have created a web application to have an eye- catching and adaptive UI design. But what if it is not able to handle appropriate traffic? A digital experience platform ensures that balance between utility of the service (functionality) delivered and warranty, that is, whether it is fit for use. The perfect balance between functionality and its use creates maximum value to customer. Scalability Requirements Scalability requirements ensure maximum operating capacity of an application and determine whether the current infrastructure is sufficient to run the application. This provides a holistic view of the number of concurrent users that an application can support, and ensures scalability so that application can support and allow more users to access than its current operating capacity. It is necessary to look into the scalability requirements, as mentioned in the scalability user story in Table 2-8. Table 2-8. Scalability User Story Name Scalability trigger the DXp application should be scalable and load should be distributed across geographical locations. script as a product owner, the DXp application will support 10,000 concurrent users per hour and 1,000,000 transactions per hour. the application should be robust so that it will be able to handle a heavy request load. Geographical load should be distributed across locations so that the application will be available across all geographical locations. acceptance the DXp application is able to support 10,000 concurrent users with 1,000,000 criteria transactions per hour across all geographical locations. 44

Chapter 2 GatherinG requirements When you need to determine the number of real simultaneous users that the application can support, you first need to calculate the maximum throughput. Maximum throughput is calculated by running a few emulated users with zero think time. That means each user sends a request, receives a response, and immediately loops back to send the next request. • Maximum users the application has to support: Once you have the maximum throughput, you can use Little’s Law to estimate the number of maximum concurrent users that the application can support. N = X / λ N is the number of concurrent users. λ is the average arrival rate. X is the throughput. • Maximum concurrent users: If the application has ab average interarrival time of 5 seconds, using Little’s Law we can now compute N (number of users) as: N = X /λ = 2015 * 5 = 10075 users. Your application running on the same infrastructure can support more than 10,000 concurrent users with an interarrival time of 5 seconds. • Maximum concurrent volume: You need to calculate maximum concurrent users per hour that need to be supported by the application. • After estimating the concurrent user and load supported by the DXP application on the particular infrastructure, you can decide to scale your infrastructure accordingly. • User growth rate: You need to estimate percentage increase in user traffic per year so that you are able to scale up your infrastructure in the future. 45

Chapter 2 GatherinG requirements • Content growth rate: You need to estimate percentage increase in content volume per year; that will help you to analyze your load capacity per year. • Average session time: It is the average amount of session time for a user, and helps you to analyze and estimate in-memory support required in the near future. • Geographic (Geo)-specific load: Globally available applications should distribute load across geographical locations. Performance, availability, and scalability should be specified for each geographical location. • Peak volume or traffic time: The maximum amount of users that should be supported by the application at peak business hours. • Data volume: As data volume keeps changing and it depends upon load and usage of the application, you should estimate the average amount of data that should be handled by the DXP application, which will let you estimate the disk space requirement in the near future. Performance–Response Time, Throughput, Utilization, Static Volumetric It is essential to check your industry standards for measuring application performance. Results should be collected from real browsers, which will assist you in checking the page load time on different browsers and operating systems. Gain insight into the performance requirements and testing approaches. Before beginning with load testing, you need to determine page response time applicable to the business process and whether response time is justifiable and achievable. Performance Requirements You need to consider and build workload profiles for the user stories as mentioned in Table 2-9, and associated workload profile related to use case mentioned in Table 2-10. 46

Chapter 2 GatherinG requirements Table 2-9. Performance User Story Name Performance trigger the DXp application should be able to respond within 3 seconds. script as a product owner, the DXp application will respond to each and every customer request made through the customer’s browser within 3 seconds. acceptance the DXp application is be able to respond within 3 seconds. criteria Table 2-10. Workload Profile FSD’s Use Case Daily Total Pages Time account 20,000 Login, Dashboard (navigational router and 3 sec. account component). transactions 15,000 Login, Dashboard (navigational router and 3 sec. transaction component) Once all loads have been considered, then infrequent or inappropriate workloads can be eliminated. Page Response Time at Normal and Peak Loads In supporting 10,000 users, the DXP should certify that performance should not fall below the mentioned level. • 80% of all pages for customers respond in 3 seconds or less. • Transaction and Account pages should respond in 3 seconds or less. In Figure 2-8 and Table 2-11, consider the following: • Peak load: When the maximum number of users engages with your application, as shown in Figure 2-8: Peak Load • Normal load: When frequent users engage with your application, as shown in Figure 2-8: Normal Load 47

Chapter 2 GatherinG requirements Table 2-11. Peak Load and Normal Load Analysis Page/Response time. Peak Load (Seconds) Normal Load (Seconds) transaction 3 2.3 account 3 2 Dashboard 6 4 6 Peak Load. 4 Normal Load. Work Load. 3 4.5 Daily 3 2.6 2.6 2.6 2 1 1.5 9 10 12 15 18 20 22 3 Time of Day. Figure 2-8. Normal load and peak load When defining the workload for a new application and no existing workload data exists while the system is being developed, the temptation is to specify a high peak workload. Page Hits Analysis You need to consider page response time at normal and peak load for various geographical locations, where you are providing business to your users. This will help you to understand and divide the loads according to the available infrastructure on the basis of workload profile. • Page response time at normal and peak loads for (Hypertext Transfer Protocol) HTTP or (Hypertext Transfer Protocol Secure) HTTPs pages 48

Chapter 2 GatherinG requirements Pages load = resource download + service calls • Where resource download is average time taken to download resources like Cascading Style Sheets (CSS), Hypertext Markup Language (HTML), scripts, and images, etc.; and service call is average time required by the web services to return data from the server. • You need to build a service call workload profile for all the services calls impacting the particular page. • Transaction time: The average time taken for key transactions, for example, average time taken by account and transaction services to fetch the data as well as other resources (e.g., CSS, HTML, scripts, and images). • Search completion time: The average time taken by the search module to provide the top ten results. Performance Testing: The DXP application must fit performance levels and delivery times on the agreed SLA (service level agreement) for stress testing to be planned and performed. • Load testing and stress testing will be performed on the BXP portal pages to certify that the critical performance requirements are met. • The pages will be performance tuned to guarantee that the response time is within 2 to 4 seconds for all the pages under average production load. • The target CPU utilization will be under 25%. • The LoadRunner application will be used to perform load testing. 49

Chapter 2 GatherinG requirements Maintenance Requirements You should be bringing its rich experience in successful execution of large-scale portal engagements in continuous application or system SLA monitoring and maintenance. You should be building robust monitoring applications to confirm that the application maintains the SLA related to performance, availability, and scalability: • Real-time application SLA monitoring components check the live production BXP web pages. The frequency of page URLs can be configured. • Automatic alerts and notification through e-mail or page when the page or system performance falls below a preconfigured threshold value. • System health-check or heartbeat monitoring to ping the availability of the portal system and all interfacing systems, to ensure that they are responding within good response time. Automatic notification gets trigged if any system is down. • Web analytics will be configured to monitor the business-critical process or activities in real time. This includes activities such as page load time, search processing time, etc. Additionally, reports will be designed to display the monitoring data, based on requirements. 50

Chapter 2 GatherinG requirements Table 2-12. Monitoring User Story Name Monitoring trigger the DXp application should be monitored. script as a product owner, i want real time monitoring of the application so that if the system fails, automatic alerts and notification will be sent through e-mail, which ensures 24/7 availability of the application. Business critical process should be monitored 24/7. acceptance the DXp application is monitored. criteria Table 2-13. Serviceability User Story Name Serviceability trigger the DXp application should be serviced. script as a product owner, i want to service the DXp application for system cleanup. maintenance activity should be scheduled so that back jobs perform system cleanup and take backup. acceptance the DXp application will be serviced and regular backup maintained. criteria Table 2-14. Maintenance User Story Name Maintenance trigger the DXp application should be maintained through versioning. script as a product owner, i want to maintain the DXp application through a version control system so that incremental changes are released to the production environment. Bug fixes should be published thought a rollout and change request mechanism to ensure smooth and effective rollout of the bug fix release to the production environment. acceptance the DXp application is maintained through versioning. criteria 51

Chapter 2 GatherinG requirements Versioning For Source Code Management (SCM), we can use versioning tools such as CVS, MS Source Safe, Git, and SVN for versioning control of the application. Rollout Once the system is developed and moved to the production environment, rollout of new functionality goes through rollout protocols and procedures. These aid in analyzing the changes involved in moving to production, and help ensure smooth and effective rollout of new functionality. • Rollout of any new functionality and bug fixes goes through the change management process after assessing the impact to cost and schedule. • Rollout includes rollout release name, rollout details, device support, release history, and defect reports. • Release name: Name to identify release, such as an internal code name or build version • Rollout details: A timestamp indicating the last rollout event for each release • Device support: A summary of the application device compatibility, including supported devices • Release history: A list of all previous releases with version code details, rollout history, and release notes, which contains all of the aforementioned details along with defect or testing reports. 52

Chapter 2 GatherinG requirements • Defect management and reports: You should follow a proven defect management process for a BXP. It has the ability to tailor the process to align with the current process or objectives. The key elements of the defect management process involve the following areas: • Set up and customize defect tool • Define defect lifecycle flow • Define and publish defect classification • Identify key stakeholders and their responsibilities • Go through defect triage process • Manage defect resolution • Report and escalate procedures • Conduct root cause analysis of defects • Defect classification and turnaround time will be decided during the test strategy phase. Security Requirements Security is a main concern while developing an application. You ought to consider all the aspects revolving around security. DXP security enhances the user experience and ensure data integrity, authenticity, and authorization. A banking experience platform is always vulnerable to attacks. You need to go through the requirements while designing a banking portal. 53

Chapter 2 GatherinG requirements Table 2-15. Session Management Use Case Use Case ID: 3 Use Case Name: Session Management Date Created: XX-XX-XXXX Last Revision Date: XX-XX-XXXX User Goals: 1. to log in to online banking portal of aBC Bank 2. to log out from online banking portal of aBC Bank Primary Actors: 1. existing customer of the bank 2. e-banking application – BXp Trigger: 1. Logout from online banking portal after clicking on logout button or automatic session timeout after defined time limit Preconditions: 1. Customer of aBC Bank is registered with internet banking portal. 2. Customer logs into internet banking portal of aBC Bank. Postconditions: 1. system will be logged out from the online banking portal of aBC Bank. Functional Flow: 1. Customer logs into aBC online banking portal. 2. Customer will be landed to the Dashboard. 3. in case customer wants to log out from online banking portal, customer should click on logout option on landing page at any point in time. 4. Customer will be logged out from the present page, and home page will be displayed on the screen. 5. after 5 minutes of idle time, portal will invalidate a session and login page will be displayed on screen. Exceptional Flow: 1. When backend systems are not working, ui component will show human understandable error message to customer: “sorry our systems are not working; please log in after some time.” Assumptions: na Validations: session timeout after 5 minutes of idle time, portal will invalidate a session, and session timeout is configurable. Track Changes: na Out of Scope: na 54

Chapter 2 GatherinG requirements • Session Management Considerations: a. It depends upon the business requirements of the user whether you want in-memory token session management or database token session management (also called Java Database Connectivity [JDBC] token management). JDBC token management is helpful in case of clustering the BXP application; in in-memory token session management, you need to replicate the session token across all clustered environment using JGroups or other open-source cache replicating techniques. b. You need to decide the idle time of a session on the basis of business requirements. Idle time of a session will automatically log out the user from the server after a specified time. It also requires checking authenticity, authorization, and integrity of data while designing the UI layer as well as backend integrations. Look into the BXP authenticity and authorization user story in the ABC online banking portal (Table 2-16). Table 2-16. Authenticity and Authorization User Story Name Authenticity and Authorization trigger Customer should be authenticated and authorized. script as a customer, one would be logged in using two-factor authentication, so that authorized data for that customer should be accessible. the following items should be masked: • mobile device number • ssn • account number acceptance an authorized and authenticated customer is able to access the BXp application. criteria 55

Chapter 2 GatherinG requirements • Authentication Consideration: a. You should always opt for two-factor authentication. There are multiple two-factor authentications. • Username / Password + one-time password (OTP). • Username / Password + RSA public key cryptography algorithm- based questions and answers. • Both: In this case, if the system finds an irregularity or unusual pattern during login, the system can trigger OTP and RSA questions after login; this eliminates vulnerability and provides high security. b. Number and password masking: You should mask the password and numbers, for example, mobile device number and account number. c. Cross-site request forgery (CSRF): is an attack that forces an end user to execute unwanted actions on a web application in which they are currently authenticated. You need to implement Open Web Application Security Project (OWASP) CSRFGuard; that would protect the application from CSRF attack. Table 2-17. Integrity User Story Name Integrity trigger DXp application should provide data integrity while retaining data interoperability between client and server. script as a product owner, i want to maintain the integrity of data while retaining data interoperability between client and server, so that the communication channel will be secured. tokens should be used and passed with data for transmitting information between client and server. acceptance DXp application provides data integrity while retaining data interoperability between Criteria client and server. 56

Chapter 2 GatherinG requirements • Service calls—data interoperability: a. JSON Web Tokens (JWTs) are used for transmitting information between parties as JSON objects. This information can be secured by using a secret key using a hash-based message authentication code (HMAC algorithms or a public or private key pair using RSA algorithms). JWTs ensure the integrity of data transferred as well. b. Cross-site scripting (XSS) filters: You use the validation library to verify web service application programming interface (API) requests in line with (Java Specification Requests) JSR standards. XSS filters match suspicious content in data requests and reject them if there are matches. Disaster Recovery Requirements Disaster can be any situation that makes an organization’s operations prone to risk; it can be of any type, for example, natural disaster, equipment failure, or cyberattacks. Disaster recovery (DR) requirements help to continue business operations as normally as possible. You need to find the recovery point objective (RPO) and recovery time objective (RTO) for their DXP application. The RPO is the maximum duration of an application (age of Files, Database, User Sessions and Caches) that an organization must recover from backup for normal operation to resume after a disaster: for example, a DXP application has an RPO of 2 hours, and then the system must back up at least every 2 hours. The RTO is the maximum duration of time for an organization to recover an application from backup storage: for example, if the organization has an RTO of 1 hour, it will not be down for longer than that. Table 2-18 contains the disaster recovery requirements. Table 2-18. Disaster Recovery User Story Name Disaster Recovery trigger the DXp application should be able to recover in case of any disaster. script as a product owner, i want the DXp application to have an rpO of 2 hours, so that the application will back up every 2 hours and will reinstate the application to the backup point. acceptance Criteria the DXp application is recovered in 1 hour. 57

Chapter 2 GatherinG requirements RTO and RPO help you make disaster recovery strategies. • Identify the threats related to your application. • Identify relevant infrastructure documents, for example, utility diagrams, HVAC diagrams, network diagrams, and equipment configurations. Accessibility Consideration You can boost the DXP capabilities by including accessibility best practice that removes barriers that prevent interaction with a web application. You need to consider the different aspects of accessibility requirements. Following is a list of factors that help your business use case to ensure web accessibility. Including these requirements while preparing a use case will improve search engine optimization (SEO), interoperability and quality, and reduce web application development, maintenance time, effort, and server load, etc. • Provide equivalent alternatives to auditory and visual content. • Provide clear navigation mechanisms. • Create tables that transform gracefully. • All functionality will be available from the keyboard. • Text content will be readable and understandable. • Provide enough time for the user to read. • Content must be robust enough, as it will be accessed and interpreted by a wide variety of devices and technology. You must check and consider the aforementioned points before developing an application, or else it will be difficult for one or more than one group to access the web content. 58

Chapter 2 GatherinG requirements Chapter Summary • This chapter covered almost every aspect of DXP applications requirements: functional, experience, mobility, security, nonfunctional, and accessibility requirements. • Experience requirements cover the following user stories along with their considerations. • Device support user story • Language support user story • Dashboard user story • Security requirements cover the following use case and user stories along with their considerations. • Session management use case • Authenticity and authorization user story • Integrity user story • Maintenances requirements cover the following user stories along with their considerations. • Monitoring user story • Serviceability user story • Maintenance user story • Banking experience platform requirements have been covered, which in turn should aid you to go through your own requirements before developing a DXP application. 59

CHAPTER 3 Design After going through the DXP requirements in Chapter 2, we will now look into designing and building a Digital Experience Platform in detail. As the world moves toward a modern digital economy, the use of DXP is meant to provide an ecosystem for product and service innovations, in addition to providing a space for the organization’s activities. Building an Experience Platform We will look at the design of the following layers in detail throughout this chapter. • Presentation layer • Business layer • Integration layer • Data layer • Middleware layer We will also look into integration of the following cutting-edge digital technology. • Social and collaboration design • IoT integration design • Blockchain design • AI automation design • Big data and NoSQL design • Enterprise search engine design • Augmented reality design • Recent trends in DevOps © Shailesh Kumar Shivakumar, Sourabhh Sethii 2019 61 S. K. Shivakumar and S. Sethii, Building Digital Experience Platforms,

Chapter 3 Design DXP design principle works on creating brand value, using visual design, interaction design, along with information architecture, as shown in Figure 3-1. Four principles for designing a digital experience platform are as follows: • Brand Value: Social platforms help your organization to promote and position your brand to social media channels like Facebook, Instagram, LinkedIn, etc. Social platforms have fast gained adoption, considering there is a strong social incentive to use them. When people are utilizing an application to reach out to you, then you should build social networks. For that, you need to choose a solution that incorporates microblogging, social networking, dynamic profiles, and automated activity feeds. You need to decide on many factors on which social software solutions will be integrated with DXP. You can integrate wiki for information sharing, Facebook authentication, and social feed APIs to integrate user social interaction with DXP that will further enhance the user experience so that one can interact with your brand across every digital touch point. • Interaction Design: Interaction design is design where one defines the structure and behavior of interactive systems. DXP user interface (UI) design helps you to create an interface design in such a way that makes the state of the underlying system easy to use and understand. User behavior is carefully examined, which ensures smooth navigational and application usability design along with seamless workflow across all channels and touch points. • Visual Design: DXP’s focus on visual helps you to build an elegant and jazzy UI using the latest Material CSS Design approach. This principle ensures the proper usage of imagery, color, typography, and form to enhance usability and improve the user experience. • Information architecture: DXP enables you to use information architecture (IA) to get insight from every customer interaction on every touch point such as desktop applications, Internet of things (IoT) devices, interactive voice response (IVR), and mobile applications into a single customer view. The IA principle is to ensure that data analytics and continuous learning and improvement approaches will help you understand the data generated through 62

Chapter 3 Design these touch points. Data acquired from these touch points are used to do prediction followed by classification, detection, automation and recommendation systems, using AI/ML concepts and algorithms. Touchpoints User Behavioral Design Social Platforms Brand Value Interaction Design Application and Navigation Design DXP User Interface Design Visual Design Information Continuous Learning and Architecture Improvement Graphic Design Data Figure 3-1. DXP customer-centric design principle DXP has a six-layered approach, as shown in Figure 3-2, to achieve the four principles shown in Figure 3-1. That is to achieve a seamless experience across all digital touch points using the platform approach (touch points, UI, integration, continuous learning and improvement, data analytics and data delivery, and infrastructure). • Touch points: Touch points are also called interaction channels. Each organization needs to understand their own digital strategy, as this will help to understand their touch point needs and create brand value. • User interface: Interactive and intuitive UI help your organization enhance the usability of your products and services. • Continuous learning and improvement: Continuous learning helps you to improve their business process and optimize business workflow, for example, chatbot or AI automation using machine learning (ML) algorithms and neural networks help you to automate and optimize their business process. DXP is designed to understand the context through transaction and learning engines where you can use different ML algorithms to solve problems related to prediction, 63

Chapter 3 Design time-series analysis, recommendation, etc. You can design the experience platform by continuous learning of user experience and understanding the intent of your customer, through which you can innovate their services and products. • API ecosystem (integration): The API ecosystem is playing a critical role in creating digital business and a huge digital economy. API helps you to turn a business and organization into a platform. API is game changing while integrating and connecting systems, data, IoT, and algorithms. In the present world, where the economy runs by API ecosystems, for example, Uber used Google API to build a new business platform; while buying a movie ticket online, one uses API to verify a customer’s debit or credit card information. The API ecosystem is playing a vital role in enabling emerging technologies like AI, blockchain, and IoT to connect with each other and build smart applications and devices. • Intuitive data: Data helps you to get insight and recognize patterns, and display reports on the basis of latest trends that are used for predictive analysis, user behavior analytics, and advanced data analytics that extract value from a particular size of data sets. For example, you can use an open-source NoSQL database that gives better performance in storing a huge amount of data and provides analysis and reporting features as well. A DXP is also designed with the consideration of customer experience management (CXM) and customer relationship management (CRM). DXPs get insight about what a customer thinks about a brand, and help an organization to know about their customers. We will get insight about interaction through touch points, further tracking of pages, and UI components, so that the organization is able to track user experience to provide a better experience to the customer. • Fast delivery (infrastructure): Infrastructure depends upon many factors, whether one wants a hassle free and application-focused platform, such as cloud infrastructure or wants their own data centers and virtualized server. Cloud infrastructure provide faster delivery capabilities. The application should be cloud ready, as cloud-based technology will help to grow the infrastructure quickly. 64

Chapter 3 Design Experience Digital Touchpoints User Interface Integration Platform Continuous Learning And Improvement Data Infrastructure Figure 3-2. DXP DXP key focus areas are platform principles that enhance the following key areas: • Reusability of components • Extensibility of components • Robustness and scalability of platform • Quality focus on performance, security, and availability Digital Platform Strategy Digital platform strategy is to design an ecosystem that gains insight, delivers service faster, and provides consistent experience across all channels. A DXP-based organization has an innate innovation capability. The platform approach helps to provide limitless digital capabilities along with providing a more innovative approach to solving issues related to additional debt and cost such as inventory, staff, billing, and management. Table 3-1 will help you to establish the relationship between DXP design principle and its strategy and platform approach to achieve it. 65

Chapter 3 Design Table 3-1. Digital Platform principle and Strategy Digital Experience Platform Design Principle Digital Platform Strategy 1. t ouch points, for example, • Brand value • selection of touch points. desktop, mobile, tablets, smart • Visual design • Workflow across touch points so that devices like amazon fire stick, • interaction design user gets a seamless experience alexa, etc. across all devices. • User interface 2. Continuous learning and • information • Continuous improvement, which improvement architecture includes usage and implementation • selection of ML algorithms of a chatbot, prediction analysis, time • selection of neural networks series analysis, etc. like rnn, ann, etc. • selection of artificial intelligence (ai) api like tensorflow, pytorch, etc. 3. Data. • information • intuitive data includes pattern • Database Design architecture analysis, data storage strategy, • Database selection that is, choosing nosQL and sQL databases, and designing data scalability approach. 4. integration • interaction design • api ecosystem includes strategy • api gateway to choose microservices approach • esB approach or monolithic services approach, • Microservices or monolithic choosing esB and gateways for api approach integration. • infrastructure • information • Fast delivery infrastructure, which architecture includes platform security scalability and deployment approach. Digital platform strategy, as provided in Table 3-1 helps one to build their own DXP for their organization. Let’s look into mapping of these principles to DXP strategy and design as shown in Figure 3-3. 66

Chapter 3 Design • Touch point selection and design: You select the touch point that helps you to provide interactive services through channels such as IoT devices, Web, and mobile, as shown in Figure 3-3. Augmented reality (AR), virtual reality (VR), and IVR are by-products built on top of these touch points to make your application intelligent and interactive. • Integration (API ecosystem) design: Integration of data from the different services (such as web API), databases (transactional and nontransactional), devices (data collected from IoT devices and smart devices through data pipeline), and systems (such as a blockchain ecosystem) help to build an integration ecosystem using an enterprise service bus (ESB) and API gateways so that multiple systems, devices, and applications connect and transfer information irrespective of technology, protocols, and frameworks used. • Continuous learning and improvement design: Continuous learning and improvement helps you to include AI and ML capability in your organization, as shown in Figure 3-3. Natural language processing (NLP) provides capabilities so that you can build efficient search engines for the organization; chatbot to deal with repetitive problems faced by user in interactive way; and if-else analysis to predict, train, and test ML and AI models built for the organization to solve day-to- day problems. Across industries, one can turn their application to AI/ ML-driven smart applications that help to drive automation using devices such as IoT devices, mobile phones, etc. We will look into the libraries and frameworks used to develop it in AI automation design and Big data and NoSQL design in this chapter. • Data design: Data pipelines, and database design and approaches help you to provide big data analysis capability to your business. AI-ML is so powerful in terms of what it can do but it needs tons of data to learn, hence to manage the data in real-time you should use a distributed data approach, hence data pipelines are introduced. • Infrastructure design: Digital strategies need to engage users with a high-performing experience regardless of the location where it is deployed. You can use cloud infrastructure or standalone server 67

Chapter 3 Design infrastructure, according to the application design and development approach you take while building the DXP. The cloud and container architectures power the DXP’s application; we will look at containerization in brief in the Containerization section. • DevOps: DevOps (development operations) such as continuous development, integration, deployment and delivery help you to develop and deliver faster on a DXP. As shown in Figure 3-3, an application incorporating continuous learning strategy, intuitive data strategy, and API integration strategy is built and deployed using an agile approach using DevOps. Figure 3-3. Digital platform strategy 68

Chapter 3 Design Platform Design Phases Designing a platform involves software development life cycle (SDLC) phases. It ensures quality, reduces cost, and saves time. SDLC phases are essential for the success of organizational DXP management strategy. Five phases are: explore and elaborate, design, prototype, validation, and delivery, as shown in Figure 3-4. You explore requirements and elaborate those requirements, build your design and on the bases of your design build your prototype, validate the prototype, and reiterate the process until the business requirements are fulfilled, and then deliver the application after ensuring quality and testing. • Explore and elaborate requirements: Investment and DXP strategy cannot be estimated accurately until the requirements are clear. You need to understand the intention and problem statement, as we observed in Chapter 2 in detail. • Design: On the basis of digital requirements, you will work on strategic designs. We will look into strategic design for application development in detail in this chapter. Keep all stakeholders engaged in the design process. • Prototype: Model the requirement. After creating strategic designs, you build prototypes, which helps your organization to make new innovations in products and services with optimized processes. • Validation: Always conduct acceptance testing. Once a prototype is built, it is validated on the basis of design: whether the prototype is appropriate according to requirements or not. • Delivery: Once the prototype is validated according to functional requirements as well as nonfunctional requirements (NFRs), test scenarios are tested. After passing unit testing, integration testing, user acceptance testing, and preproduction tests, it will be moved to production. 69

Chapter 3 Design Explore and Elaborate Requirements Design Prototype Validation Delivery Figure 3-4. Platform design phases Design of Various Layers A DXP is a flexible platform that has the capabilities of rapid development and innovations. A DXP has a web application with a content management system (CMS) and provides features such as marketing, targeting, personalization, commerce, etc. You can build web applications, mobile applications, chatbots, AR, VR, AI, and enterprise search engine components for devices such as tablets, mobile, desktop, and IoT, as shown in the presentation layer in Figure 3-5. These applications on different devices are connected through the integration layer; you can choose architecture type such as microservices or monolithic application, and services built are exposed using an ESB and API gateway. Business logic is implemented while accessing data from the data access layer and exposed using the integration layer, as shown in the figure. The middleware layer is responsible for implementing NFRs such as reliability, security, accessibility, and scalability, etc. 70

Chapter 3 Design Figure 3-5. Design of various layers 71

Chapter 3 Design Each layer is important while designing a DXP’s application. The presentation layer helps you to decide user experience on user interaction points (touch points). The service layer is responsible for data interoperability. The business layer helps yours organization to separate business logic from other logics and validations. The data access layer manages and stores the data into databases, files, warehouse (which is central repositories of integrated data from one or more data sources), and data lakes (which are storage repositories that have huge amounts of raw data). DXP design helps enterprises to design end-to-end holistic solutions that help business to maximize scalable and operational capabilities. We will look at these layers in detail in the next sections. Presentation Layer The presentation layer comprises user experience as well as UI. This layer helps you to understand the basic requirements as well as complexity of the application. User experience can make or break a brand’s value. You need to consider the channels or touch points while designing the user experience journey, as shown in Figure 3-6. Figure 3-6. Touch points DXPs incorporate the design thinking approach to decide the touch points and user experience journey. This process consists of five stages: understand, define, design, prototype, and test. • Understand: In this stage you gather the information to understand the problem you are solving using these touch points. Your assumptions become clear about the solution and you are able to get insight of the user’s need regarding touch points and channels. 72

Chapter 3 Design • Define: During this stage you put all the information gathered from the last stage in one place. You will analyze the observation and be able to define the problem clearly. You will have all the minute details required to design optimized workflow for the organization using the mentioned touch points and applications in Figure 3-6. • Design: Having collecting all the information from the last two stages, you can start thinking about and identifying new solutions to the problem statement created during the design stage. In this stage you will be able to understand the technology stack and touch points needed to solve the problem, along with mockup user experience screens and UI components for touch points selected to provide a solution to the problem. • Prototype: In the prototype stage, you create the inexpensive, scaled- down version with minimal features so that you can investigate the problem and its solution. You can consider this as a proof-of- concepts phase. • Test: In this stage, you test the prototyped version of the solution. It is an iterative process; the result generated in this phase can redefine the problem and help redesign the solution. Chapter 4 covers designing of the UI layer for mobile, tablet, and desktop in detail. Chatbot, VR, AR, Alexa, and voice assistance, as shown in Figure 3-6, enhance the user experience journey; these are the by-products (application) that are indirectly connected to the DXP’s web application build for mobile, tablet, and desktop devices. IoT devices are considered smart devices that sense the user’s input through sensors and pass the input to IoT boards; on the basis of input, further application would take action on the input and provide the appropriate output. We look into designing chatbot, VR, AR, Alexa, voice assistance, and IoT in detail in subsequent parts of this chapter. While designing the presentation layer for a web application, you need to consider the different approaches. You look into the approaches like mobile first or desktop first. The DXP’s design will follow the mobile first approach, as thinking mobile first will help you to design the content, which is really important for the application. 73

Chapter 3 Design Scripting Framework Degree of modularity and maintainability should be considered while deciding the scripting frameworks to be used by your web application, for example, Angular or React Figure 3-7). Both are technology stack-adapted, component-based, modular programming approaches but both have advantages as well as limitations. For example, React has the advantage of virtual DOM (Document Object Model), which handles memory management efficiently, whereas Angular has the advantage of two-way binding. CSS framework Scripting framework Desktop Bootstrap • Angular Foundation • React Bulma Mobile Material Semantic UI • React Native • Native Scripts • Ionic Figure 3-7. CSS and scripting React Native or Native Scripts are used for developing a hybrid application for mobile and tablet. A React or Angular technology stack along with CSS frameworks like Bootstrap, Foundation, etc. provide responsive UI that works on a mobile as well as a tablet’s browsers. We look into these CSS and scripting technology stacks in Chapter 4 in details. 74

Chapter 3 Design UI Management UI management provides the capability to organize and handle your UI scripts. It will help you to manage UI components and dependencies, and you can chose appropriate package manager, module bundler, task runner, and testing frameworks from Figure 3-8. • Package manager: A JS package manager will help you to manage a package dependency that is installing, configuring, and removing dependency modules from a UI project. • Module bundler: Using a bundler is the process of combining a group of modules (dependency) into a single unit in a specific order. You can use Webpack, Rollup, or Browserify as a module. • Task runner: A task runner will help you to maintain their UI code by running different tasks like watching the files, minifying the files, lining JavaScript files, etc. You can use one of the task runners such as Grunt or Gulp, as shown in Figure 3-8. • Testing: A JS testing framework will allow you to perform cross- browser testing; some frameworks provide both test environment and testing structure to your UI application. You can use the frameworks to generate, display, and monitor test results. The testing framework can be used in both environments: test-driven development (TDD), a process for when you write and run your tests, and behavior-driven development (BDD,) which lets you define application behavior in plain English text. Steps to decide the UI design are as follows: 1. Select compatible CSS and scripting framework and technology stack (see Figure 3-7), appropriate package manager such as Yarn, NPM, or Bower, etc. (see Figure 3-8. 2. Select appropriate module bundler. 3. Select task runner, if needed. 4. Select testing framework such as Mocha, Jest, Jasmine, Cucumber, or Karma (see Figure 3-8) according to your chosen scripting technology stack such as Angular technology stack (ATS) or React technology stack (RTS). 75

Chapter 3 Design Mocha NPM Webpack Grunt Jest Yarn Browserify Gulp Jasmine Package Manager Module Bundler Task Runner Testing Cucumber Bower Rollup Karma Figure 3-8. User Interface (UI) Management UI Deployment After building the DXP’s UI application, you can deploy static content to the web server. The web server takes care of load balancing, proxy serving, web serving, security controls, and monitoring services. Web and Http caches store the static items like HTML pages, images, etc. so that the application is able to deliver static content faster. You can use many options to deploy your static content, as stated in Figure 3-9. 76

Chapter 3 Design Figure 3-9. HTTP accelerator, web cache, and web server Varnish cache along with the web server is a unique combination that will deliver content faster. You can choose any web server such as Microsoft IIS, Nginx, or Apache web server according to your needs and requirements. As shown in Figure 3-9, the client requests to Varnish and Varnish replies static content to the client or passes the request to the web server if the requested content is not cached in the Varnish cache. Varnish along with the web server is able to provide load balancing, proxy server, web serving, security controls, and monitoring services features. Integration Layer The DXP’s integration design integrates data, applications, and people together through a common business process, for example, information portals, common business functions, service-oriented architecture (SOA), or distributed business processes. There are two types of integration: loosely coupled and highly coupled. 77

Chapter 3 Design Loosely Coupled Integration and Highly Coupled Integration The loosely coupled principle reduces speculation between components and applications regarding their exchange of information in the form of messages (Figure 3- 11). Messages are sent in a particular format such as JSON or XML. It is asynchronized, whereas tightly coupled solutions are synchronized in nature and create interruptions when changes are required (Figure 3-10). Before an exchange of data message, the system establishes connection using Connect and Ack (acknowledge) messages. Integration approaches have evolved significantly from RPC (remote procedure call) and RMI (c), supported with many platforms and frameworks like CORBA, Java RMI, RPC- Web services, SOAP services, monolithic REST services, and microservices. Figure 3-10. Highly coupled Figure 3-11. Loosely coupled Integration helps you to integrate multiple platform using integration patterns and solutions. Key integration patterns are as follows: • Channel patterns: These patterns provide the way to transport the message across a channel. Patterns such as point-to-point channels, publish-subscribe channels, message bus, etc. are shown as message channel in Figure 3-12. 78

Chapter 3 Design • Routing patterns: These patterns provide the way to route a message from sender to receiver, shown as Message Routing in Figure 3-12. These patterns consume the message from one channel and send it to another channel without modification on the basis of a set of conditions. • Transformation patterns: These patterns change the content of a message, for example, XML to JSON conversion (also known as message translation). • Endpoint patterns: It is a messaging system so that a client can consume or produced messages. It defines endpoints, which are consumed by other applications. It has Message Endpoints, Message Gateways, and Message Dispatcher, as shown in Figure 3-12. • Management Patterns: These patterns help to deal with errors, performance analysis, and logging in the application. • Message construct: It has the message encapsulated with data, along with message events. It is responsible for construction of the message and holding the return address. Figure 3-12. Integration Components and Patterns 79

Chapter 3 Design The patterns mentioned will help to build services and solve integration problems from End-point A (application A) to End-point B (application B). These patterns encapsulate the design knowledge; hence, irrespective of any integration technology, it will help to solve the integration problem. We look at the following message patterns and message components in detail in Chapter 5. • Message • Message channel • Pipes and filters • Message router • Message translator • Message endpoint Following are different integration architectures: for example, information portals, common business functions, and distributed business processes architectures, which help you to solve common problems of integrations such as aggregator pattern architectures, B2B (business to business) architectures, and service bus architectures (SOA). • Aggregator pattern architectures: There are many business processes where you should to access more than one system to answer a question to perform a single business function in an organization. Hence, information portals aggregate the information from multiple sources to display a holistic view. For example, you need to get data from business process 1, business process 2, and business process 3, aggregate the data from all processes, and display it on the dashboard, as shown in Figure 3-13. 80

Chapter 3 Design Figure 3-13. Aggregator pattern • Business to business (B2B) architectures: There can be a scenario where you need to integrate business functions or processes available from third-party suppliers or business partners; for example, a bank provides billing and recharge functionality, hence the bank needs to integrate utility services from third-party suppliers. In this architecture we are integrating two system or business processes outside the organization. These systems are directly communicating with each other. • Service bus architectures (SOA): Shared business processes and functions also referred to as services. Once an organization collects a set of services, service bus architectures provide tools that make calling an external service almost as simple as using conventional methods. In this architecture all the services are communicating with the DXP’s application using a common bus, as shown in Figure 3- 14. Services from external system 1, external system 2, and external system 3 communicate with the bus, and these services are exposed to the DXP application via common bus. 81

Chapter 3 Design Figure 3-14. Service bus architectures (SOA) Chapter 5 covers designing of the integration layer in detail. Integration deals with data interoperability between different applications within or outside an organization, using different protocols and data formats. We delve into micro services, REST services, ESB, and API gateways in Chapter 5. Figure 3-15. Integration The DXP’s architecture supports microservices and monolithic services architecture because it makes integration structure more flexible, as it structures the application into multiple modular services. ESB and API gateway help you to scale your services build 82

Chapter 3 Design using microservices and monolithic architecture as shown in Figure 3-15. Microservices are lightweight services running as a separate process; each service inculcates a separate business capability in it. The advantages of microservices over monolithic applications are as follows: • Services communicate using REST. • Services are loosely coupled. • Scaling is easier. • You can achieve isolation of services: if one service fails, another would continue. You can build these microservices using containerization and orchestrate using Kubernetes. The advantages of microservices build using Kubernetes and containers are as follows: • Number of services can be deployed and delivered quickly. • Services built on Kubernetes can be deployed across different environments. Test environments like SIT, UAT, or preproduction can be cheaply and quickly created with a Kubernetes cluster. Steps to design the integration layer are as follows: 1. Select the appropriate architecture type such as microservices or monolithic services architecture. 2. Select the appropriate messaging pattern for the business process to be integrated. 3. Select the appropriate framework that satisfies the business needs; for example: • Apache camel can be used as mini-ESB for large scale applications. • Apache CXF can be used as service framework for medium scale applications. • Spring Boot along with Apache camel can be used for microservices. 83

Chapter 3 Design 4. Get mutual consensus on authentication details, data formats, services endpoints, and services protocols from all systems participating in integration; for example: • Get the data formats details, like services integrated will have XML or JSON. • Get the service endpoints and details like service URLs, and port number and its invocation type (verb) or method; for example, POST, GET, PUT, DELETE. • Get the service protocols details such as RESTful or RESTless. • Get the authentication details and encryption-decryption algorithm used to secure data while communicating with two systems; for example, authentication token passed along with these services. Business Layer A DXP provides a separate layer for business logic so that integration and application logic won’t be able to hamper business logic. As shown in Figure 3-1, the business layer has a business controller, business validation, and data transfer object (DTO) Figure 3-16. Business layer The business controller is responsible for receiving and replying to requests. It is responsible for the following: • Redirection: You can redirect the control of an application to business services. 84

Chapter 3 Design • Business logging: You can log the request and response in the business controller of the application. • Authorization: You can integrate authorization logic, which will check the user’s authorization to access the data from a particular business controller. Business validation or services are responsible for filtering and processing a DTO received from the data access layer on the bases of business rules and logic. After processing, objects are sent back to a particular business controller, which has initiated the request for business services. Business services are responsible for the following: • Model binding: Data received from Data access layer will be mapped to business services. • Business rules validation: Business rules and checks like null pointer exception and blank check, etc. are validated in business services. The data transfer object interacts with the data layer (database). Records stored in a database are mapped to entity objects, and entity objects are requested to appropriate tables in the data repository. Entity objects are then sent back to business services where objects are processed, then these processed objects are sent back to the business controller, as shown in Figure 3-17. The business controller redirect to appropriate business services, and business services access the data received from the DTO and data access object (DAO) of the data access layer. 85

Chapter 3 Design Figure 3-17. Business layer to data access layer Data Layer The data access layer is responsible for simplified access to data stored in databases, as shown in Figure 3-17. This layer contains a DTO, which is a mapping to the table; every column in the table is a member of the DTO. The DAO (data access object) helps you to create, delete, modify, or search for an entity using a simple object. The DAO design pattern is used to implement the data persistence layer. It is based on abstraction and encapsulation design, as it protects other parts of the application from any change in the data layer, for example, change of database from MySQL 86

Chapter 3 Design to PostgreSql or from database to file system. As an example, a DXP’s application authenticates a user by utilizing the database but it is later decided to go for SSO (single sign-on) using LDAP and SAML. It would be safe if the user were using DAO to access data from the database, as the user only needs to make changes on the data access layer. Java-based projects use JPA and hibernate framework to access data from the databases. You can access data from files, data lakes, NoSQL databases, SQL databases, etc., as shown in Figure 3-18. Figure 3-18. Data Middleware Layer Middleware is an infrastructure that helps to deploy and manage complex business applications. Components of a DXP’s applications may be developed using various programming languages, protocols, and frameworks. Middleware provides the services and helps in implementing NFRs (Figure 3-19) such as transaction concurrency transaction monitoring, security authentication and authorization, transaction logging, transaction auditing, and distributed processing. Figure 3-19. Middleware components 87

Chapter 3 Design Middleware represents a collection of interconnected components that are distributed across different locations and provides features like reliability, scalability, and maintainability. Therefore, middleware makes application access easier. It provides load balancing servers, web servers, and application servers. CMS facilitates middleware infrastructure and supports application development and delivery. Figure 3-20. Middleware layer You should look into the various components of the middleware layer carefully while developing and deploying your DXP’s application, such as application monitoring, server monitoring, application logging, server logging, and auditing. As shown in Figure 3-20, the UI (front-end) applications will be deployed on a web server and the backend applications will be deployed on the application server. Backend applications have different layers and components, such as authentication and authorization, logging, and auditing. • Application monitoring ensures that application processes perform in an appropriate manner. • Server monitoring ensures health and availability of the server and OS; that includes bandwidth, CPU utilization, memory utilization, and disk utilization. 88

Chapter 3 Design • Application logging ensures that logging errors, information events, and warning are appended into log files. Logging helps to check the issues reported by any users. • Server logging retains the logging errors and information events and warnings generated by the server. The server monitors its own list of activities. • Auditing ensures that all the activities done by a user on an application are logged in the auditing file or database. • Transaction processing initiates and interacts with the integration layer and business layer. It ensures the reliability and consistency of any kind of transaction that takes place in the system; in case of failure, it will roll back the failed transaction. Social and Collaboration Design You can integrate collaboration tools like Gerrit, Jira, Rocket Chat, Slack, and Yammer with the DXP application. These tools have RESTful APIs available, which can be integrated easily with the DXP application. You can integrate with social platforms, for example, Twitter and Facebook. These tools have authentication API available, so that you can authenticate the application using these APIs. You can use Facebook and Twitter APIs to integrate tweets and posts in your own application, as shown in Figure 3-21. The DXP UI layer gets the authenticating details from the user, and these authentication details are passed to a third-party social platform such as Facebook or Twitter. These platforms provide an access token to further interact with these platforms and get the users data to your DXP application. 89

Chapter 3 Design Figure 3-21. Social integration Collaboration is all about conversations between people to get to a goal. It is about cross-questioning, collecting answers, and getting feedbacks. It is all about social interaction, one of the ways that work gets done. The traditional way of business collaboration was e-mail with attachments, but collaboration was slow, difficult, and inefficient. Therefore, to solve the collaboration problem, social software solutions, based on microblogging, social networking, and wikis were integrated with DXP. 90

Chapter 3 Design Figure 3-22. Social and collaboration requirements Social software applications like Instagram, Facebook, and Twitter have fast gained adoption, considering there is a strong social incentive to use them. When people are utilizing an application to reach out to you, then you should build social networks for that; you need to choose a solution that incorporates microblogging, social networking, dynamic profiles, and automated activity feeds. You need to decide on many factors on which social software solutions will be integrated with a DXP. You can integrate wiki for information sharing, Facebook authentication, and feed APIs to integrate user social interaction with the DXP; that will further enhance the user experience. You can implement a rule-based chatbot for automating frequently asked queries by the user. • Live chat: Live chat is one of the customer servicing tools. It provides chatting capabilities in real time via a chat window placed in the website or mobile application. 91

Chapter 3 Design • Chatbot: You can integrate a chat engine with a DXP application. Chatbot engines are of two types: rule-based engine and ML prediction- based engine. It depends upon your requirements and workflow which engine you want to integrate with DXP, as shown in Table 3-2. Table 3-2. ChatBot Engine Usage Facebook Bot Facebook messenger interaction slack Bot automate developer team interaction Chat fuel Bot for marketing, sales, and support Dialog flow ai based bot • Wiki: You can integrate an open-source enterprise wiki—for example, TWiki—with a DXP application, which will enhance collaboration of teamwork together seamlessly and productively. • Blog: You can integrate a blogs framework, for example, WordPress with a DXP application where people can share knowledge between teams. • Calendar: You can integrate a Google calendar API with a DXP, so that you can plan your work and interact with the Google calendar. • Forums: A forum is a type of message board, divided into topic folders, where you can publish posts and reply to posts from other team members, for example, vanilla forums. • KM portal: Knowledge management portals are considered to be virtual workplaces that promote knowledge sharing among different categories of end users and provide access to stored structured data and organize unstructured data, for example, Plumtree and Woolmani. You can integrate this portal with a DXP to manage an organization’s knowledge. • External integration with FB, LinkedIn, and Twitter feeds: You can integrate social media API to a DXP application where you can integrate feeds and SSO authentication. 92

Chapter 3 Design IoT Integration Design IoT is another fast-growing technology, which can assist you to build and implement a data gathering network to improve systems and establish a new channel for interaction. DXP is a platform that is capable of quickly adapting emerging technology to address major challenges. DXP is leading organizations toward innovation, which helps businesses with intelligence and advice. IoT systems use sensors to provide operational insights from the data. Intelligence is added by integrating the analytics and ML into IoT devices. The IoT is effectively connecting the digital world to the physical world. It helps to communicate and integrate information systems and the fields’ data, and it is possible to use this data in real time. The IoT is mainly divided into three layers as shown in Figure 3-23: physical sensing layer, IoT Integration layer (also called as middle layer), and IoT application layer. • Physical sensing layer: Physical sensing includes sensors, for example, temperature, proximity, pressure, etc.; and development boards also called prototyping boards to acquire data from the environment, like Arduino, Raspberry, Edison etc. Along with mobile phones and their sensors like microphone to get voice commands, proximity, accelerometer, and other sensors can be grouped as passive or active (passive sensors don’t require external power sources, whereas active sensors require external power to sense the external environment). Analog sensors produce a continues signal, whereas digital sensors produce a discrete signal. • IoT integration layer: The IoT integration layer integrates the data collected from a device to a NoSQL database along with a distributed computing platform like Apache Spark and Hadoop. Data acquired from sensors can be stored in the cloud and can be used later to create dashboards. The IoT integration layer is also called the middleware layer. This layer ensures security, quality of service (QOS), and provides IoT gateways as well. You can implement this layer in your DXP application by integrating IoT frameworks such as Iotivity, AllJoyn, Eclipse-Kura, etc. 93

Chapter 3 Design Figure 3-23. IoT integration • IoT application layer: The IoT application layer collates the data and applies ML capability to the data taken from the devices. Insights, predictions along with appropriate data, and web services are exposed to the UI dashboards and analytics application. Frameworks like Apache Spark and Apache Kafka help to manage IoT data in real time; they provide data pipelines and steaming mode to get insights 94

Chapter 3 Design from an IoT application for the organization. In the layer, you can use TensorFlow, Apache OpenNLP, Apache Tika, and other ML and NLP libraries for sentiment analysis, image analysis, document analysis, time-services analysis, and other processing. IoT data can help recognize trends common in a machine that help us to understand the breakdown of applications. At each layer in the design, you can run various ML libraries as needed. In Figure 3- 23, IoT Integration has four open-source software components designed to collect the data from external environment (i.e., sensors and boards); data stores (i.e., NoSQL databases); management (i.e., integration of IoT framework and platform), which provides the communication to collect data from a group of sensors from multiple locations, visualization (UI applications), and manipulation (ML) of time series IoT data in an easy and scalable manner. IoT frameworks like ARIoT, AllJoyn, Iotivity, etc. have implemented SOA, which is beneficial in IoT integration. These frameworks provide data interoperable capabilities, the API layer. Physically sensed activities generate the events, and these events are sent via the communication protocol such as MQTT to the service (middleware) layer. These events are pushed via the event bus to a REST API and then the update is reflected on web portals and mobiles devices. IoT Case Study Integration of technology such as AI/ML and big data along with blockchain will prove to be extremely useful for IoT use cases in the near future. The following use cases will help you to understand the IoT applications and implementation so you are able to implement IoT-based applications in your organization. • Asset tracking: Logistics organization already has tracking assets using IoT. Organizations can have real-time access to the appropriate location of the assets. You can attach tagging sensors with the assets that will improve efficiency, as it will resolve the problem of locating the assets. IoT-enabled things assist people to improve productivity. • Smart cities and real-time streaming data: Smart cities are based on connected technology that makes cities more progressive and have data to get insight that can help in improving safety, economy, and quality of life. Real-time data streaming through streaming 95

Chapter 3 Design engines, data pipelines, and IoT will lead us toward smart cities. A citywide information network could be linked to sensors and a digital experience platform that enables the city to provide automated street lighting, waste management, digital bus routes, and smart parking. • Digital wallets: The IoT can extend the capabilities to automate payments through devices such as digital wallets, which can be attached to each device. For example, digital wallets attached to cars can pay for fuel charges, road taxes, etc. • IoT smart payment contract: Smart contracts are computer programs that verify and enforce the negotiation of a contract. Data captured from IoT devices can execute the smart contract and the system would deduct the payment by coordinating with the bank. • Banking through wearable: The ecosystem of IoT is growing day by day. Many banks have started providing services through wearables like the Apple watch, etc. Applications could be built for already existing wearable devices for contactless digital payments. Integration of IoT devices with a digital experience platform enhances usability. Blockchain Design Blockchain could be used to record transactions or events, which would be replicated exactly across all the nodes in a network. Every node would have a copy of records that cannot be edited or deleted. We will look into Blockchain concepts, smart contracts, the Blockchain platform and its design components, along with a use case study in this section. Let’s look into Blockchain concepts using a book and library analogy. What is Blockchain? Here is an attempt to understand blockchain with the analogy of book and library. It is a known fact that an accounting book is called a ledger, every page in the ledger is connected to other pages in sequential order, and these pages contain transactions. Pages can be considered as blocks and the book can be considered as a blockchain. 96

Chapter 3 Design What Is a Distributed Ledger? A replicated and consistent version of a ledger is distributed across libraries. Libraries can check and validate the authenticity and consistency of a book by observing, comparing, and taking consensus from other libraries. If a ledger is distributed across libraries, this can be considered a prefect analogy of a distributed ledger. A distributed ledger wouldn’t have central trust authority. Libraries are considered as nodes. Each node has a consistent version of a ledger. Transactions are added in blocks and blocks are added in the ledger, with the consensus of nodes participating in blockchain network (Figure 3-24). Figure 3-24. Blockchain Smart Contract Smart contracts are self-executing computer programs with an agreement between the participants on assets, and this contract exists across a distributed and decentralized blockchain network. For example, in a banking use-case, an account can be considered as an asset, whereas banks and account holders are the participants. Participants are the users of the blockchain network. Participants can write a smart contract with predefined agreements on assets. On the basis of transactions done by participants in the network, 97

Chapter 3 Design the smart contract is executed; all the events along with the transaction are recorded in the network and stored in a blockchain. These transactions are appended in the blockchain, hence immutable in nature. Blockchain Platforms A DXP provides the capabilities to deploy and integrate the different components of the DXP application with the blockchain platforms, that is, Hyperledger, Etherum, Multichain, Hydrachain, Corda, Openchain, Quorum, and IOTA, as shown in Figure 3- 24. DXP and Blockchain Network Three kinds of networks are involved while integrating blockchain with a DXP, as shown in the following design. • Enterprise network: Existing applications reside in your enterprise network, which contains the organization’s data that may be deployed on stand-alone infrastructure or cloud infrastructure, as shown in Figure 3-25. • Public network: An organization’s data is exposed using REST APIs to the public network, where users (analyst, administrator, auditor, operator, business user) of the application can utilize the authorized data after authentication in the form of an analytic chart, monitoring services, API management, and Blockchain explorer (see Figure 3-25. • Blockchain network: The blockchain network consists of blockchain components, that is, smart contract, ledger and transaction, e-certificate, membership services, public–private key infrastructure, and interoperation, that contain events and communication protocols (see Figure 3-25). Blockchain is of two types, that is, public blockchain and private blockchain. In case of a public blockchain, anyone can be allowed to participate in the network, can execute the network, and maintain the ledger; in a private blockchain, identity services maintain the roles and responsibilities, so that only members of the blockchain can execute the network and maintain the ledger. In addition, a DXP supports integration of an open- source private business blockchain network. 98

Chapter 3 Design Blockchain Components A blockchain platform has multiple components to establish and manage a blockchain network and deploy smart contracts on it. We will look into these components as follows, such as consensus layer, smart contact layer, network communication layer, data store layer, crypto layer, and services such as identify management and API management, as shown in Figure 3-25. • The Consensus layer is responsible for collecting valid transactions in a block and appending a new block in the blockchain network after taking consensus from the node participating in the network. You can use different kinds of consensus algorithms (POW, POS, DPOS, POA, PBFT, BFT) according to the chosen blockchain platform. • The Smart contract layer is responsible for processing transaction requests and determining if transactions are valid or invalid by executing business logic. The smart contract is developed and deployed by the blockchain developer in the blockchain network. • The Communication layer is responsible for peer-to-peer message transport between the nodes that are participating in the network. It supports the interoperation among different blockchain instances. • The Data store layer allows different data stores to be used by other components in modules. • The Crypto layer contains different crypto algorithms to be swapped out without affecting other modules and layers. • The Identify services contains E-certificates and public key infrastructure (PKI), which establishes the trust during setup of blockchain instances. It interacts with member services for enrollment and registration of identities or system entities during network operation. It also provides authentication and authorization to access the events and transactions in the blockchain network. • Data services and API managements enable clients and other DXP applications to interact with the blockchain application and network. 99

Chapter 3 Design Figure 3-25. Blockchain architecture Blockchain Case Study There are many use cases that can be solved using blockchain or distributed ledger technology, which can ensure immutability and transparency of records in the ledger and provide a common platform for users across industries and organizations. Use cases such as KYC, EHR, digital identity, POE (proof of existence), claim management, etc. are explained in brief in following section. • Know your customer (KYC): The blockchain-based KYC process using digital identity helps banks to know their customers. A digital signature is created and stored in a blockchain-based system; data is linked with the customer’s digital signature, which is decrypted with the customer’s private key. • Electronic healthcare records (EHR): Blockchain is used to provide patients an ecosystem to control and store their health records in a blockchain network. Patients could give or revoke permission to share their medical record with a medical institution and doctors, although every medical institution would be appending medical records and tests in the user’s blockchain in a distributed ledger. 100

Chapter 3 Design • Digital identity: A blockchain-based data encryption digital identity management platform could defend against identity theft. One could choose which data to share with whom across different channels. • Letter of credit: You can use blockchain and deploy a letter of credit as a smart contract between the bankers or investors and the supplier to guarantee payment. If the products and services are delivered according to the buyer with all specified conditions in the smart contract, the contract gets executed based on the documents submitted by the various parties verifying that the letter of credit conditions meet specified shipment deadlines and conditions. This can be automated through program logic in the smart contract to indicate and check compliance or noncompliance. • Proof of existence: PoE is also called an authenticity of a file or record on a blockchain. The publisher or creator of the document uploads the file along with its hash to the blockchain network; the verifier can check its authenticity by uploading the document. The blockchain application calculates the hash of the document uploaded by the verifier and matches the hash calculated with the hash of the document available in the blockchain network. • Claim management: You can easily audit and maintain transparency while making claims. A smart contract can be modeled according to claim process and deployed on the blockchain network. Claim smart contracts automatically and securely complete all the steps involved from automating coverage verification to claims validation. • Loyalty and rewards: A blockchain-based loyalty and rewards platform provides and maintains transparency among stake holders. Multiple reward programs and cards are merged in one platform and then rewards can be used anywhere without any restrictions. 101

Chapter 3 Design Big Data and NoSQL Design Big data analytics can provide and uncover the patterns hidden in your organization data. You can integrate actionable insights with DXP and create efficient data streams that can learn, predict, and take action by connecting DXP with multiple data sources, and then apply ML algorithms for better understanding of their own customer. Big Data and NoSQL Integration Big data solutions are built using open-source projects like Apache Spark, Hadoop, and Kafka, to name a few, which help you to collect data from multiple data sources and provide distributed processing, and usage of ML algorithms and data visualization methods help you to analyze big data that helps management as well, as shown in Figure 3-26. We will look into big data components such as ETL, ML models for efficient steaming of predictive data models, search and query web services, and usage of NoSQL databases in this section. • Extract, transform, and load (ETL): • You can load data from multiple data source using open-source big data streaming engines such as Apache Spark. It can access multiple data sources including the Hadoop Distributed File System (HDFS), NoSQL database, and SQL-databases. • Collection of elements of your dataset that will be stored in memory or disk across a cluster of machines • A data frame is created to help process large data sets easily. Spark’s dataset and data frame provide an API that allows developers to easily express transformations on domain objects. • Train and test predictive data model: • You can use different kinds of ML algorithms (supervised learning, unsupervised learning, or reinforcement learning) depending upon the nature of problem. 102

Chapter 3 Design • You can use Spark’s ML.lib or other ML libraries such as Tensorflow, PyTorch, etc. that allows data scientists to focus on their data problems and models instead of solving the complexities of distributed data, such as infrastructure and configurations, etc. • Machine learning algorithms involve a sequence of tasks, including preprocessing, feature extraction, and model fitting, in identifying outliers. In the case of Apache Spark, ML Pipeline is a high-level API for ML provided by Spark that provides a sequence of stages handled with distributed processing capabilities. • Data streams and processing: • Data stream processing helps data engineers and data scientist to process real-time data from sources including stream engines such as Apache Kafka, Rabbit MQ, Redis Simple Message Queue (RSMQ) and Flume. • Search and query web services: • Processed data can be pushed out to file systems, databases, and live dashboards using web services. • Web services are exposed to the UI dashboard, as shown in Figure 3- 26. You can trigger a query using a Web API. These WEB APIs further interact with an ML-based trained model; the model loads and processes the real-time data and returns prediction results back to databases and UI dashboards. 103

Chapter 3 Design Figure 3-26. Big data and NoSQL • NoSQL database: • A NoSQL database is recommended with an analytics application, which receives huge amount of data in real time and needs to update the dashboard with the latest data. Searching and querying a NoSQL database is more efficient than an SQL database. Table 3-3 lists the advantages of using NoSQL in big data solutions. 104

Chapter 3 Design Table 3-3. SQL vs. NoSQL SQL NoSQL relational database no relational database Fixed schema Dynamic schema it is a table-based database. it can be a collection of key-value pairs, documents, and graph databases. MysQL, sQL server; etc. Mongo db, Couch db; etc. it has defined sQL language to define it has unstructured query language used to query the data and manipulate the data. from collection of documents. Vertically scalable horizontally scalable it is used with transaction-based it is used with mobile applications, real-time analytics, systems and solutions. and content management systems, etc. • Containerization: • The application is built using a variety of frameworks, libraries, tools, and technology, which is encapsulated in a single container along with its environment. The application container is deployed on multiple virtual machines (VMs), cloud infrastructure, or on a standalone machine. Big Data and NoSQL Case Study Let’s look into big data use cases that can be achieved by the aforementioned design. • IoT model-based algorithm: An organization can use an IoT model along with ML algorithms to learn from historic events and make smart decisions. This helps financial institutions to make smarter investments. You can make innovative use of big data and IoT. For example, a bank can use behavior analysis to analyze customers’ visits and money transactions from different bank branches; integrating these analyses into the business model helps to create customer-centric deals, personalized offers, etc. 105

Chapter 3 Design • Employee engagement: You can apply big data analysis to track performance of employees. Analytics could ensure and understand employee productivity. AI Automation Design AI automation is comprised of traditional automation and robotics process automation (RPA); RPA is an emerging technology. Traditional automation is the automation of any type of repetitive task. It is usually found in a workflow-based application, whereas RPA allows organizations to automate tasks like the way human beings interact across the system and application. The main goal of RPA is to replace repetitive tasks performed by humans with a virtual workforce. AI has been categorized and grouped, such as RPA, speech reorganization, NLP, deep learning, ML, and chatbot (virtual bot). You need to determine the automation goals, followed by building the AI model. Determine Automation Goals You need to decide an automation strategy that clearly sets out how and where you apply automation. After determining the automation strategy, you can map it with predefined automation systems, which will further help to decide the framework and algorithms to be integrated with DXP, for example, NLP-based solutions or data prediction-based solutions. Steps to Build AI Automation Model The approach to build an AI model is as follows, where you create training and test data sets and apply ML algorithms or neural network algorithms to build an AI model. You have five steps: data preprocessing, build the model, train the model, test the model, and improve or tune the model on the basis of expected results from the model, as shown in Figure 3-27. • Data preprocessing: Data preprocessing is the initial step toward building an AI-based model. Datasets are loaded, cleaned, and processed according to the problem statement. • Build the model: The model is built using ML, deep learning algorithms, and neural networks concepts, which further use ML libraries, for example, tensorflow, pytorch, etc. 106

Chapter 3 Design • Train the model: The training data set is identified and used to prepare a model. • Test the model: This is a new dataset, different than the training set; you gather predictions from the trained model with the inputs from the test dataset and compare them with the withheld output values of the test set. • Improve and tune the model: You can adjust various parameters and tune the weights to improve the model built. Figure 3-27. AI automation model Chatbot Case Study Most common AI solutions are built using Tensorflow, Python, and Spark. AI strategy helps to solve defined business problems, with a defined data set to solve the problems. Chatbots are programs built with NLP, which is supposed to solve domain-specific problems and query request by simulating human conversation. There are three components: presentation layer; bot layer, which has the bot framework or engine; and transaction and data processing system, which interact with the DXP to integrate the existing system with the chatbot engine, as shown in Figure 3-28. • Presentation layer: The chat interface can be a custom UI (e.g., Angular, React) and native mobile application. You can interact with this layer using text, voice, and visual. Inputs are sent to the backend layer using web socket communication and REST APIs. • Bot engine: This is an open-source bot framework used to create the bot model for specific use cases and domains to understand the intent of the user. The bot framework has capabilities to process, understand, and generate language that is NLP, NLU, and NLG as follows. • NLP (natural language processing): This component understands the text or voice and understands the intent of the user. 107

Chapter 3 Design • NLU (natural language understanding): This component helps your application to understand the intent and take action on it. After understating the intent, you can call APIs to interact with the external system and get or put information in other systems. • NLG (natural language generation): After understating intent and getting external information from other systems and databases, you need to generate the resultant message and send it back to the client. • You can use open-source bot frameworks such as botpress,, etc. or use chatbot platform services like chatfuel, dialogflow, etc. to build a chatbot, or you can your create a custom framework using ML and NLP libraries with the help of a recurrent neural network and bag-of-words model. • Integration with legacy system: If you are building a chatbot for a business, then most likely you are working with CRM, ERP (enterprise resource planning), and core banking, etc. You need to integrate the chatbot with an external system using REST APIs (external). Figure 3-28. Chatbot Integration with DXP 108

Chapter 3 Design Enterprise Search Engine An enterprise search engine is used to search content from multiple sources (databases, files, and intranet) within the organization. Components of a search engine are as follows: • Processing: Diversified data loaded from different sources will have different formats. This component processes the incoming documents to plain text and normalizes to improve precision and recall value, which includes stemming, that is, reducing words to their stem such as “texting” becomes “text”; lemmatization, which is the process to reduce the word into its base dictionary word such as “studies” becomes “study”; part of speech tagging, etc. An analyzer is used to analyze data and give back meaningful terms or words. • Indexing: Processed text is stored in an index, which is used for quick lookup and will be handled by indexer. The dictionary contains an index of all unique words as well as information about their ranking. • Query processing: A user from the web application executes the query. The query is broken into terms and operators using a query parser and analyzer. • Matching: The processed query is compared with the stored indexes in the dictionary. Now, we look at an enterprise search engine in detail, based on Apache Lucene and its technology stacks: Elastic Stack and Solr Stack. Apache Lucene is able to achieve fast search responses because it searches indexes instead of searching whole text. • Elastic Stack: The Elastic technology stack has multiple components available to build solutions on top of it, such as Beats, Logstash, Elasticsearch, and Kibana, as shown in Figure 3-29, are as follows: • Beats collects the data and parses it and pushes it to Elasticsearch for log analysis. Log analysis can be achieved using Logstash and Kibana. • Logstash can connect to a variety of sources such as Web API, social services, IoT sensors, and databases and data streams like Kafka or Redis, which collect the data and pipeline to Elasticsearch. 109

Chapter 3 Design Figure 3-29. Elastic Stack • Elasticsearch is a search server based on Apache Lucene. It provides distributed full-text search engine capabilities with RESTful web services. It stores and indexes the data. • Kibana visually explores the data by querying Elasticsearch, or you can use their custom UI to fulfill the search requirements on the basis of their domain and fields. It is an analytics and visualization platform, which provides dashboards and charts for visualizing the data as per the search query. Elastic stack can be deployed on Elastic Cloud or can be deployed as a standalone cluster. It can be used in e-commerce applications for filtering the data by end user, such as filtering by brand name and other features of the product. It can also be used for application performance monitoring (APM); log data from the application server can be loaded to Elasticsearch using Beats, and key performance indicators (KPIs) analysis will be displayed on the dashboard using Kibana. • SolrStack: The Solr technology stack has multiple components available to build solutions on top of it, such as Logstash, Apache Solr, and Banana as shown in Figure 3-30: • Apache Solr collects the data from different data sources through the connectors; the data source can be data streams, files, application databases and documents, etc. Solr provides the parameters required (data) for visualization to Banana. 110

Chapter 3 Design • Banana is a fork project of Kibana, which works with Apache Solr and provides visualization and exploration capability. It provides rich and flexible UI, which enables the user to develop an end-to- end search application. It also has a tabular display to drill down to the documents in a result set. Figure 3-30. Solr Stack You can create custom UI components according to their domain needs. Solr Stack can be deployed as standalone or in cluster mode. Augmented – Virtual Reality Integration Augmented reality comprises two layers: presentation layer and integration service layer, as shown in Figure 3-31. Presentation Layer You can integrate AVR frameworks such as ARcore, ARkit, etc. with the DXP core presentation layer, which provides augmentative and virtual reality integration with mobile, web, and desktop applications. AR works on two core applications: marker- based AR application and position-based AR application (also called markerless AR). 111

Chapter 3 Design • In a marker-based AR application, the image you want to recognize is provided and you know exactly about the thing to be searched using the camera’s data (frame). It is like detecting the hard-coded things in your application. • In a position-based AR application, the image is not available beforehand; you have to recognize and identify features like color, pattern, edge, etc., which exist in the camera frame. In this application, different sensors are required to recognize position and orientation. Integration Service Layer After recognizing features and patterns, you need to integrate them with AI-based algorithms along with integration frameworks such as cloud-based integration or ESB- based integration as per your existing application, so that you will be capable of getting data from the existing DXP’s application, as shown in Figure 3-31. Once the features and pattern have been extracted by frame, appropriate programming action can be taken to get the objects on the screen using its camera. Figure 3-31. Augmented reality integration 112

Chapter 3 Design Recent Trends in DevOps Let’s look into the recent trends in DevOps, where applications are built using the containerization approach and deployed on a cluster of nodes using Kubernetes, as shown in Figure 3-32. Containerization An end-to-end application can be developed and encapsulated in a single container along with its components such as files, environment variables, libraries, and OS necessary to run the application. The complete set of components in a single container is called an image. The container engine is responsible for deploying these images on hosts. Containers can run inside VMs, physical machines, or public and private cloud. This implies that a host machine can have multiple OS supporting containers that share same physical resources. Docker is the most common and leading containerization system. This approach helps you to scale and increase your storage when it demands. Features of the container are as follows: • The required configuration files along with libraries are available in the container. • Containers are more lightweight than a VM. This makes your application portable, hence it is easily built and deployed. 113

Chapter 3 Design Figure 3-32. Containerization and DevOps DevOps – Continuous Integration (CI), Continuous Deployment (CD) DevOps consists of the tasks that manages orchestration and cluster management. It also provides features like scalability and load balancing for containerized application. You develop the application and push the source code in an SCM repository such as SVN or Git, and use CI and CD methodologies to automate the deployment process. You can use Jenkins to build the container images; these images are deployed on multiple Docker clusters using Kubernetes or Docker Swarm. • Kubernetes: Kubernetes is an open-source system for automating deployment, scaling, and management of containerized application. It also distributes the load among containers. • Swarm: Swarm is used for managing a cluster of Docker engines. 114

Chapter 3 Design Chapter Summary • We went through different DXP layers and designing of those layers in brief to develop an end-to-end enterprise solution. • We also went through integration of cutting-edge digital technology like Blockchain, IoT, AI, big data, and AR. • We went through a variety of open-source frameworks to develop a digital experience platform. • We looked into the latest trending concept of containerization to develop a solution that can be hosted on any machine, irrespective of OS. 115

PART II Development of the Banking Experience Platform

CHAPTER 4 User Interface Design As we are heading toward an open-source digital experience platform, DXP’s provide collaborative user interface. This chapter provides DXP user interface (UI) concepts and shows how to develop intuitive and interactive UI designs. In this chapter we look at: • The key features of DXP UI • Architecture and frameworks used in developing DXP UI • Designing pages and layouts, UI components (such as a widget or port-let), and hooks to integrate with backend services, etc. • Technology stack to develop a DXP UI • Case study - Banking experience platform Let’s begin by looking at the key features of a DXP UI. Key Features DXP user interfaces are built upon the modern web development approach, using the latest web frameworks and library. Let’s delve into the digital experience features and then look into the approach to design and develop the UI. Simplified Approach A DXP provides a reusable and intuitive UI. It provides techniques to help create a fancy, and at the same time elegant, UI and enhance the user experience (UX). The object- oriented programming approach makes the components reusable and is developer friendly. © Shailesh Kumar Shivakumar, Sourabhh Sethii 2019 119 S. K. Shivakumar and S. Sethii, Building Digital Experience Platforms,

Chapter 4 User InterfaCe DesIgn Intuitive Architecture A DXP’s information architecture provides content in an organized and intuitive way. Navigating through the application enhances the UX journey. It makes the application simpler and more intuitive to use and the longer visitors stay, the more likely they are going to engage with the content and maximize the chance of buying services or products. Dashboard A dashboard is an organized way to provide and present information in an intuitive manner. The dashboard helps in visualizing, tracking, and analyzing data and displays key performance indicators (KPIs), metrics, and key data points to monitor accounts, business processes, department reports, etc. For example, in a banking experience platform, you can analyze account statements and track income expenditures from account statements. Behind the scenes, DXP architecture integrates multiple data sources, for example, files, attachments, services, systems, etc., and provides a single source of data as REST APIs, which integrate with the dashboard and display all data in the form of tables, line charts, bar charts and gauges, etc. A data dashboard is the most efficient way to track multiple data sources because it provides a central location for businesses or users to monitor and analyze data. Responsive Interface Grid system layout of a DXP handles the responsiveness of the application, on desktop, mobile, as well as tablets. DXPs work on a mobile-first approach to implement responsive features. The mobile-first approach is the best strategy in the market to make adaptive designs. In the mobile-first approach, content or information is prioritized and sorted into primary, secondary, and tertiary content, for example, the home page should have a company logo and links to products or services. As everything wouldn’t fit into a smart phone screen, the DXP provides the ability to prioritize the content as per business requirements. In Figure 4-1, the desktop screen has six UI components: components 1 and 2 are primary content, component 3 is secondary content, and components 4, 5 and 6 are tertiary content. As the resolution of the screen changes, these components start getting wrapped as per the priority of the content, as shown in Figure 4-2. Components 4, 5 and 6 where horizontally aligned, but the mobile view is wrapped up and these components are vertically aligned. 120

Chapter 4 User InterfaCe DesIgn 1 2 3 4 5 6 Figure 4-1. Desktop screen 1 2 1 2 3 3 4 5 4 5 6 6 Figure 4-2. Left: tablet and Right: mobile Personalization Business stakeholders or administrators can provide customizing ability to the user; thereafter the user can also customize the look and feel of the page from predefined templates. A user of the system can decide the content and layout of the application. Business owners or stakeholders can make use of predictive content personalization based on Artificial intelligence (AI)-based predictive algorithms in which similar content, product, and services are displayed on the basis of their previous interaction 121

Chapter 4 User InterfaCe DesIgn with application location-based personalization on the basis of location of the business unit. For example, if you log in from one part of the country, the content, services, and products displayed will be different than if you log in from another part of the country. Also, time-based personalization (i.e., theme and advertisement) will change as per time of the day; for example, if you log in at morning time, theme and advertisement will be different than if you log in at evening time. Internationalization and Localization We can choose our own language from the list of provided locales, as most UI frameworks support internationalization (i.e. i18n). i18n is the process of developing you application in a way that can accommodated multiple languages and localization (i.e. i10n). i10n is the process of adapting i18n to enable usability in a culture. The process of developing UIs should be done in such a way that they can be localized for language and culture easily. The user can select a language among different languages by selecting the appropriate locale (language), and content is displayed as per selected locale. Preferences The DXP presentation component (such as a widget or portlet) provides editable features to make UI integration flexible. For example, REST service call endpoints can be editable from the UI itself. A preference is a key value pair. Preference is stored as metadata, which helps the DXP to make the UI customizable, for example, title, description, etc. are customizable as per business requirement changes. All UI components have names, which can be programmatically determined; this makes presentational component robust in nature. Integrated Analytics When you are designing a portal, you need to pay attention to analytics to understand user behavior and patterns. There could be a scenario where you want to track click events and user behavior. Analytics helps you understand the potential customer. Google Analytics makes it easy to record click events. The DXP provides the ways to integrate the analytics framework (e.g., Google analytics, Adobe analytics, etc.). 122

Chapter 4 User InterfaCe DesIgn Search Engine Optimization Search engine optimization (SEO) is the way to drive traffic. The UI and UX make or break the first experience. If you don’t have SEO, it is hard to find your applications on search engines. On the other hand, if you don’t have a rich user interface, you don’t get interaction and leads. The DXP uses best practice while developing UI to make it SEO friendly. The DXP provides keyword tagging features (i.e., title tagging, metatagging). User Interface Components A DXP page typically includes a header with a logo, a navigation menu, presentation component, container area, and footer. Pages A web application contains a set of pages that are used to display the application. A page contains different layouts as per the experience requirement, for example, one-column layout, two-column layout, three-column layout, etc. Layouts A DXP provides a responsive layout that is used while designing the UX on pages. It is a predefined structured template on which the UI designer can drag and drop presentation components. • Navigation layout: It usually contains three areas: Top (containing logo area and user area), navigation side as shown as container in Figure 4-3, and as Presentation component, as shown in Figure 4-3. The layout is designed based on Bootstrap. There are no restrictions on what layouts or UI (presentation) components are included in any area. • Light box layout: It overlays the page and can be shown and hidden based on click events. It is provided to the user in a sub flow without leaving the current page, enhancing the UX. 123

Chapter 4 User InterfaCe DesIgn • Carousel layout: It provides the facility for transition between the areas (slides) of a layout, only showing one area at a time. It can be configured for auto play so it loops through the slides once it is loaded. • Columns layout: It provides the basic grid functionality. The layout is built on Bootstrap columns and Cascading Style Sheets (CSS) classes. You can configure the column widths by using CSS classes. DXP Page Layout Container Presentation Presentation Component A Component B Presentation Presentation Component C Component D Figure 4-3. User interface components Navigational Router or Navigation Menu A consistent navigational router is one of the components that provides users with a sense of orientation and guides them through the application. 124

Chapter 4 User InterfaCe DesIgn Presentation Component Presentation component (such as a widget or portlet) are independent mini user interface applications usually separated as per use cases or user story. For example, an account summary component to view account details and a bill pay component to pay bill payment of registered payees are two separate presentation components. These components (portlet or widget) have self-sufficient functionality and work independent of each other. Design Goals While deigning the presentation component, model-view-controller (MVC) and model- view- viewmodel (MVVM) patterns are used because these architectural patterns provide control over business logic implemented on UI and also provide control over the workflow of the UI application. The MVC pattern has three components: model, view and controller: • Model will bond with view as well as controller, as shown in Figure 4- 4. • View is the user interface that binds the model with the Document Object Model (DOM) and display data to the user, and also enables the user to modify the model. • Controllers are responsible for controlling the flow of the application; if you make a web services request, the controller is responsible for providing a response back to the application. MVC and MVVM patterns provide the following features to your application and help to achieve goals like upgradable, extendable, lean, and testable: • Upgradable and extendable presentation components. This can be achieved through API and object-oriented features of the framework. As shown in Figure 4-4, the UI component can extend to the base component; hence, if upgrading the framework, your functionality will not be impacted in the UI component. You can implement common functionality in the base components and other UI components can use it simply by extending the base components. 125

Chapter 4 User InterfaCe DesIgn Figure 4-4. MVC architecture • Portlets should be independent of each other, as per digital experience platform business requirement. Angular framework or React library along with Flux library makes a lean-structured presentation layer. Presentation components should be of high quality and should be well tested. Quality is achieved thoroughly and efficiently by testing presentation components using a test-driven approach. Therefore, framework and libraries like Karma, Jasmine, Mocha, Chai, etc., help to achieve high quality. Communication Between Presentation Components Sometimes it is vital that one presentation component responds to an action made in another presentation component. For example, after a user has selected a different account from the account list component, the transaction list is updated to show transactions related to that particular selected account in the transaction list component, as shown in Figure 4-5. If presentation components are on the same page, this can be 126

Chapter 4 User InterfaCe DesIgn achieved using a broadcast observable design pattern to ensure smooth communication between different components. A broadcast enables you to capture and handle events triggered in one component and actions performed in another component. Figure 4-5. Communication between presentation components Hooks Hooks are created so that flexibility of work can be maintained between front-end and back-end developers. Hooks are defined services from which back-end integration takes place using REST service calls. A hook itself does no processing—it just calls the hook’s implementation, passes the data, and accepts data back from the implementation. This allows exchange of data between back-end and front-end applications. A hook has been defined in the service files to handle data coming from the back-end, and vice-a-versa. When the developer implements a REST service, then the hook data points will be replaced by actual REST service endpoints. Development Process A DXP provides a simplified and structured UI development approach. Figure 4-6 outlines the UI development processes. 127

Chapter 4 User InterfaCe DesIgn Figure 4-6. User Interface (Visual) development process DXP UI design constitutes of research and strategy of the following process: 1. Structure: Build basic UX structure. The structure is designed in such a way that it can incorporate the digital strategy of the brand. Contents are classified according to the digital strategy of the organization so that they can provide products and services to users of the application. Templates and models are built to understand the needs of digitization. 2. Layout: Select layout on the basis of the UX structure. Once a model and templates are selected or built, you need to check and research the business needs to build wireframes for the application. These wireframes can be built using a predefined layout, and these layouts are reusable basic structures built by considering usability by the user. 3. Interaction: Classify the content on the basis of the digital strategy of the organization. After building the wireframe layout, content is structured in the layout so that it enhances the relevancies of the content. Content is classified in these layouts, which increases the utility of the application. 128

Chapter 4 User InterfaCe DesIgn 4. Visual design: Selection of color coding and arrangement of Visual aids. After building layout and classifying content, you need to consider the themes, color coding, color palettes, and mood boards, which are an arrangement of images, materials, and pieces of text that enhance the UX design. Development Life Cycle The development life cycle is as follows: 1. Designing: Prototype: As shown in Figure 4-7, While designing the User Interface(UI), UI Prototyping and UI Wireframe are essential step towards the success of User Interface Development. While prototyping the UI, you should take care of structuring and layout of the content. Best strategy and processes should be considered (e.g., interactive screen mock-ups as per the mobile-first approach strategy that focuses on the interface and content priority as per mobile screen and then desktop) so that the content should be presented in a meaningful sequence. UI Wireframe Designing Or Prototyping UI Screens UI User Interface Implementing Development Scripting Unit Testing Test Release Build Figure 4-7. User Interface Development life cycle 129

Chapter 4 User InterfaCe DesIgn 2. Implementing: Construct UI: You construct the UI and presentation components using layout, containers, pages, and UI elements with reference to the wireframe built in the designing phase. These layout, container, and presentation components consist of HTML and JavaScript’s (also called ECMAScript). Presentation components should be structured and encapsulated in containers and layout from the list of predefined layouts as shown in Figure 4-3. Implement Business logic: UI components (view) built are mapped to JavaScript’s controllers (controllers) using a model, which helps to control the application and implement bossiness logic on the basic of any change that happens to the model. 3. Testing: Unit testing: The developer can test the presentation components with different scenarios or test cases using different testing frameworks (e.g., Karma, Jasmine, Mocha, Chai, etc.). 4. Release: While releasing code, you have to manage the dependent libraries and third-party API used to develop the application. Hence build is a process to assemble packages and manage the code efficiently. Build: Build your application with a module bundler (e.g., Webpack) and package manager like Node Package Manager (NPM). You can use other package mangers like Yarn or Bower, but NPM has been widely accepted by the front-end developer community. These bundlers and package mangers help in packaging a complex and large scale application’s code as a single unit. Architecture A DXP is a platform for building a client application in HTML and Java Script (also called ECMAscript). It implements the core functionality as a set of Java Script libraries that you import into your application. It helps in organizing your code into distinct 130

Chapter 4 User InterfaCe DesIgn functional modules referred to as presentation components (widget or portlet), which help in managing development of a complex application. This technique lets you take advantage of lazy loading, that is, loading modules on demand in order to minimize the amount of code that needs to be loaded at startup. UI architecture is built on the MVC or MVVM architectural pattern. MVVM is recognized as a web architectural-based pattern. • The model represents the data and binds with the view. • The view is where you represent UI elements, for example, textboxes, buttons, input, etc. • ViewModel represents the UI-related logic where you can do conditional checks or update certain parts of the web application. As shown in Figure 4-8, the model will bind with View (HTML template) and ViewModel (components’ scripts). Events fired in the view can be recognized in a components’ scripts and any change in a components’ script will be reflected in the view or vice versa. This will help you to maintain the state of the application; in this case you have control over your business logic on UI. Figure 4-8. Component architecture 131

Chapter 4 User InterfaCe DesIgn Reusable data or logics can be separate reusable components, which can be shared by injecting into presentation components; this can be achieved using dependency injection. Angular uses a module loader to load all components, modules, and services, rather than explicitly putting script tags into the UI (presentation) component’s template HTML. The presentation component only needs to know about its immediate dependent libraries. Dependency of imported libraries are loaded automatically. The presentation component consists of HTML (templates) and controller components. Data binding between controller and HTML enables you to synchronize application state (model) and the view. In the case of unidirectional data binding, any change in the state of the application updates the view; and in the case of two-way data binding, it binds properties and events together as a single entity so that any change in the model updates the view and vice versa. As shown in Figure 4-8, event binding makes your application respond to user input by updating the application model and data associated with the model. Property binding interpolates values that are computed from the application model into the view (HTML) DXP UI Technology Stack DXP technology stacks are a combination of different frameworks and programming languages used to create a flexible, responsive UI that is mobile and desktop compatible. Multiple technology stacks are available to implement the DXP’s presentation layer. Each layer of the application builds on the features of the one below it. Figure 4-9 shows the major building blocks of a DXP’s UI technology stack, and you can add other custom packages using a package manager, for example, NPM, Bower, etc. 132

Chapter 4 User InterfaCe DesIgn Platform Web Mobile (Android/IOS) Web Mobile (Android/IOS) UI Angular Material NativeScriptUI Elements Semantic UI React Native UI Elements Script Angular React Mobx-Redux-Flux Test Karma-Mocha-Chai NativeScript Jest React Native Jasmine Application Application Build Webpack Webpack Technology Stack Angular Technology Stack React Technology Stack Figure 4-9. Technology stack Presentation components are built on well-known, proven standards and technology stacks. Let’s begin by looking at the Angular technology stack to implement the DXP’s presentation layer. Angular Technology Stack The Angular technology stack (ATS) consists of multiple frameworks and libraries (Angular Core, Angular Material UI, Bootstrap, Swagger, Jasmine, Webpack, etc.). 133

Chapter 4 User InterfaCe DesIgn Angular Core The Angular framework is leveraged to provide many features to speed up UI development: • Cross platform: Angular provides the ability to reuse your code to build an application for any development target. It is a progressive web application approach that loads like a normal web application but also provides features and functionality like push notification and device hardware access traditionally available only to native mobile applications. It has the capability of a hybrid web application, which works on desktops and mobile devices across multiple browsers. • Development friendly: Angular serves the first view of your application on the Node.js server, instantly rendering HTML while developing the application. • Code splitting: Angular loads scripts quickly with the router component, which delivers automatic code splitting so users only load code required to render the view the user has requested. • Productivity: The Angular command-line interface (CLI) tool quickly creates UI views with simple and powerful templates. • Test-driven approach: With a library like Karma and a framework like Jasmine, you can know if you’ve broken anything every time you save the code while developing the application. • Server-side rendering: Angular provides server-side rendering by using Angular Universal, a technology that runs applications on the server. Angular Universal generates static application pages on the server through a process called server-side rendering (SSR). It enables the web crawler to index your application and optimize your application so it will be easily searchable, linkable, and navigable for web crawlers. • Angular APIs: Angular has an extensive set of APIs that are flexible and customizable. When we say API, it does not mean REST APIs. API refers to any programming interface. For example, 134

Chapter 4 User InterfaCe DesIgn Angular Support Library The Angular support library includes the following: Material UI Angular Material is Bootstrap components written in Angular by using Google’s Material Design specification. All the UI (presentation) components such as accordion, table, gauge, charts, etc. have been split into separate importable modules, which are reusable across applications. As shown in Figure 4-9, Angular Material provides UI capability to the ATS. Bootstrap Twitter Bootstrap is used while developing the UI (presentation) component of a DXP to speed up development. However, a DXP is lean and flexible, hence the entire template HTML is customizable. It is possible to use another CSS framework as per business requirement. It works on the mobile-first approach to implement responsive features. SASS (Syntactically Awesome Style Sheets) – CSS Preprocessor SASS provides a simpler, more elegant, syntax for CSS and implements various features that are useful for creating and managing CSS, such as nested rules, variables, mixins, selector inheritance, and many more. It also helps to keep everything organized and allows you to create style sheets faster. Swagger Swagger helps you to mock the web services. The UI (presentation) component has service data hooks that communicate with a server through a REST API. All the REST APIs are defined in Swagger. Code generated by Swagger provides a simple and well- defined interface to the REST APIs. This enables fast development, as the developer can see from the data module documentation exactly which methods are available, what parameters are accepted, and the JSON in which the data is returned. 135

Chapter 4 User InterfaCe DesIgn NativeScript NativeScript creates the native application iOS and Android Apps with Angular. It provides the abstractions needed to access the underlying native platforms; for example, it provides a JavaScript API that translates application JavaScript code into native (iOS or Android) gestures API calls. It provides modules to access native device and platform capabilities. As shown in Figure 4-9, it provides Native Mobile application building capability to the angular Technology stack. Karma-Mocha-Chai Testing a web application is not as simple as testing a back-end application because you have to test front-end code on multiple browsers and their versions. Karm, Mocha, and Chai help you to test your code on multiple browsers. Karma runs the test, whereas Mocha and Chai are used to write the test. Karma allows you to test your code on browsers and devices; it starts the browser and runs the test on it. Chai and Mocha provide an assertion library that can be integrated with any JavaScript testing framework. They provide testing capability to the ATS. Jasmine Jasmine is a behavior-driven development framework for testing Java Script code. It is used to test behavior of the functionality written in JavaScript. It has simple syntax so that you can easily write test cases. Webpack Webpack is a static module bundler. When Webpack processes your application, it internally builds a dependency graph that maps every module yours project needs and generates one or more bundles. It provides application-building capability to both the Angular technology stack (ATS) and React technology stack (RTS). Gulp Gulp is used as a default build tool for UI (presentation) and themes development. It helps in automating build tasks like building CSS, HTML, and ECMAScript along with other tasks like minification, watching changes in source code, linting for errors, etc. 136

Chapter 4 User InterfaCe DesIgn NPM DXP UI (presentation) component development relies on NPM (Node Package Manager) so that you can incorporate other NPM packages into your development process. It provides package management capabilities to both the ATS and RTS. React Technology Stack The RTS consists of multiple libraries such as React, Semantic UI, React Native, Redux, MobX, and Flux. You can make your own framework using these libraries. React React is a component-based JavaScript library for building a UI that deals with the view in the MVC. The React library is leveraged to provide many features to build a dynamic user interface: • Server-side rendering: Next.js is the framework for the server-side rendering of a React-based application. It provides a flexible way to completely or partially render your application and optimize it so it will be easily searchable, linkable, and navigable for web crawlers. • Performance: Virtual DOM in React makes the UX better and it works faster. • Reusable component: This component has its own logic and controls its own rendering, and can be reused wherever you need. Code re-se helps to make your apps easier to develop and easier to maintain. React Support Library The React support library includes the following: Elemental UI or Semantic UI Semantic UI is React’s official integration CSS framework that helps create beautiful, responsive layouts using HTML. It uses simple phrases called behaviors that trigger functionality. As shown in Figure 4-9, Semantic UI provides UI capability to the RTS, but you can use other CSS frameworks (e.g., Elemental UI, which is the UI toolkit for a React- based application). 137

Chapter 4 User InterfaCe DesIgn React Native React Native is a platform for creating a native mobile application using React. It provides a set of React components that bind to their native mobile counterpart; it also provides features to create your own components and bind them to native mobile code. As shown in Figure 4-9, it provides native mobile application-building capability to the RTS. Redux-MobX Redux is a simple state management engine for JavaScript. Redux helps you to write applications that behave consistently, and run in different environments (client, server, and native). MobX is a simple, scalable state management solution. MobX is just a library to solve state management problems, not an architecture or even state container in itself. MobX is used for small-scale project, whereas Redux is mainly used for complex and large-scale projects. MobX has more than one store for data storage, whereas Redux has only one large store for data storage. Redux and MobX both are the libraries that are used to manage the application state in one way or the other. These libraries are mainly combined with front-end libraries like React to develop the UIs more interactively and to show changing data over time. Flux Flux is the application architecture that Facebook uses for building client-side web applications; it’s a pattern rather than a formal framework. It is a kind of architecture that complements React and the concept of unidirectional data flow. It is the data layer in JavaScript applications and building client-side web applications. React takes care of V or the view part in MVC, whereas Flux is a programming pattern that takes care of the M in MVC. Jest Jest is used by Facebook to test all JavaScript code including React applications. As shown in Figure 4-9, it provides testing capability to the RTS. 138

Chapter 4 User InterfaCe DesIgn Evaluating UI frameworks To evaluate UI frameworks, you should consider the following: Data Flow The main difference between Angular and React is the way of handling data and managing the state of application. Angular is a fully featured MVC framework. React is just more of a ‘V’ in the MVC. Angular allows two-way data binding, while React allows one-way data binding. Unidirectional data flow, also called one-way data binding, means any changes you make to the model affect the view, but not the other way around. This way, the data only flows in one direction, whereas with two-way or bidirectional data binding any changes you make to the model affect the view, and vice versa; hence with React, state management is provided and managed by a third-party library (Flux, Redux, MobX). Angular is capable of managing state itself, but React needs to integrate with other third-party libraries. Angular has more features out of the box than React. Language Angular is a JS framework build using typescripts, whereas React is a JavaScript library but recommends using JSX(XML syntax to JavaScript). Instead of writing the traditional way—a classical approach of separating markup (HTML) and logic (JS)—React combines them in the components using an XML-like language that allows you to write markup directly in your JavaScript code. Performance DOM is the Data Object Model of the DXP application. Angular uses the browser’s DOM, while React uses a virtual DOM. A virtual DOM is a simplified version; therefore, by using a virtual DOM you can change any element very quickly without rendering the whole DOM. Therefore, React has better performance over Angular. Both technology stacks are flexible and powerful. Their usage depends upon the business application. Both accomplish the same thing but React needs the support of an additional library that provides framework capabilities to the RTS; otherwise it is ideal for a logicless application. 139

Chapter 4 User InterfaCe DesIgn Best Practice A UI should be perceivable, operable, understandable, and robust. You should keep the main menu structure simple and consistent across layouts, and make sure it’s intuitive and easy to use. While keeping the layout simple, also make sure different elements are easily identifiable as primary buttons, secondary buttons, action items, or menu. You should group menu navigation based on user needs and mental model. Organize content into relevant groups and categories to increase its relevance: Perceivable: • You should review all color and contrast settings. • You should check alternative text applied to all nontext content. • You should provide a media alternative and description to each and every component. • Your content should be presented in a meaningful sequence. • Color is not the only visual means for conveying information; you should also check the shape, size, and content, and include animation. Operable: • Ensure navigation is consistent across pages and layouts, making users’ navigation easy. Match the navigation flow with the user mental model. • Content should be operable through a keyboard interface. • Check for missing headings and blank labels. • The purpose of each link should be determined from the link text alone. • Ensure focusable components receive focus in a meaningful order and a focus indicator is visible. Understandable: • Consistent navigation should be within a set of web pages. • Changing the setting of a UI component should not automatically cause a change of context. 140

Chapter 4 User InterfaCe DesIgn • Input errors should be identified, and suggestions should be clearly described and provided to the user in text. • Rewritten site content to a lower reading level. • Provide customized content, based on the user’s product and web application usage patterns. • Ensure the error messages are easy to understand, and display the solution to the problem. Robust: • All UI components should have names, which can be programmatically determined. BXP – Case Study A banking experience platform is the technology-driven platform that links multiple technologies into one. A BXP solution is more about optimizing, rebuilding, and connecting multiple platforms. Consistency Across Locations BXP features like localization (i.e., l10n) and internationalization (i.e., i18n) provide one front end that is applicable to all the countries, thereby providing consistency across different regions and countries. The current banking application has multiple screens to support functionality for bill payments and managing payees where there are separate and multiple interactions (screen) for money movement workflow. The BXP provides a solution where there is a single logical user flow for any kind of money movements. Consistency Across Application One of the key aspects of the UX design process is to ensure consistency from a usability and design perspective throughout the application. In the existing application, setting or editing addresses, e-mails, and phone numbers followed different patterns and hence wasn’t intuitive to users. The BXP provides a consistent design approach for all the scenarios. 141

Chapter 4 User InterfaCe DesIgn Unified and Collaborative Approach The BXP provides a single platform for retail banking customers as well as business banking customers. Hence, it reduces the bank’s operational cost to maintain different applications for different types of users. The BXP enables customers to define smart actions that help them easily automate manual tasks. BXP UI Layouts/Containers Layouts or containers are used to create structure for presentation components: • Navigation layout: It usually contains three areas: top (containing logo area and user area), side, and content, as shown in Figure 4-10. The layout is designed based on Bootstrap. There are no restrictions on what layouts or UI (presentation) components are included in any area. • Columns layout: It provides the basic grid functionality. The layout is built on Bootstrap columns CSS classes. You can configure the column widths by using CSS classes. BXP Dashboard The BXP dashboard is a user interface that organizes and presents information in an intuitive and interactive manner. The dashboard visually tracks, analyzes, and displays all linked accounts and transactions to monitor accounts and manage wealth. For example, in a BXP application you can analyze account statements and transactions by filtering transactions on the dashboard. Behind the scenes, a dashboard connects to multiple data sources and APIs, but on the surface displays all this data in the form of tables, line charts, bar charts, and gauges. A data dashboard is the most efficient way to track multiple accounts and transactions, because it provides a central location for retail as well as business banking users to monitor and analyze their wealth. Problem: XYZ bank wants a responsive design to display accounts and transactions in the user’s dashboard. 142

Chapter 4 User InterfaCe DesIgn Solution: The BXP provides an extensive set of layout to model presentation components. As shown in Figures 4-10 and 4-11, we have used navigation layout along with two columns structures that contain the account summary presentation component and transaction presentation component. The Account Summary UI component displays various accounts one holds with XYZ bank along with summarized details. The transaction UI component displays transactions associated with the account. Figure 4-10. BXP dashboard 143

Chapter 4 User InterfaCe DesIgn Figure 4-11. BXP mobile dashboard (Left: dashboard view; Right: navigation view) The side panel displays other UI views associated with the BXP application. The BXP provides the user with role-based featured UI (Presentation) components, as mentioned in Table 4-1. For example, retail banking users can only access those components with access to the retail banking group. Business banking users can access the business banking group’s components. 144

Chapter 4 User InterfaCe DesIgn Table 4-1. Role-Based Components User or Role UI Components retail banking UI Login component, profile component, account summary component, payments components component, transactions component, manage payee component Business banking Login component, profile component, account summary component, payments UI components component, transactions component, authorizations, batch upload component, manage payment orders component, draft payment orders component, manage payee component Wealth portfolio details component, portfolio summary component, portfolio management UI transactions, portfolio performance valuation component components Bill payment UI third-party integration UI component, mobile recharge UI component, manage components biller UI component e commerce UI add biller’s component, manage biller’s component components BXP UI (presentation) retail banking components, which enhance user experiences, are mentioned in Table 4-2. 145

Chapter 4 User InterfaCe DesIgn Table 4-2. BXP UI Components UI Components Functionality Features Login User to be authenticated User is authenticated using username and password. with username and User is taken to specific page after logging in. password. profile Display read-only It displays personal information about the end user. information about the logged-in user. account Display summary of It displays aggregated balances of all accounts, debit summary user’s account, credit cards, credit cards. card, debit cards. transactions Display overview of User is able to see most recent transaction for user’s selected account particular selected account. transactions. User is able to load transactions incrementally. User is able to filter credit or debit transactions. User is able to search transactions. If the number of applicable transactions is greater than the value defined for display in the components’ preferences, then by using lazy loading functionality more transactions will be fetched from back end and be displayed under the list. Manage payee User is able to add new It provides ability for the user to create, search, edit payee and edit existing manual payee. payees. Manage payment User is able to view It provides ability to load payment orders orders the payments orders incrementally and access all payment orders applicable to the current through indexed pages. User is able to view and edit user’s entity. scheduled payment order, etc. 146

Chapter 4 User InterfaCe DesIgn The BXP provides digital banking capability to move toward a DXP. It provides capability for building and managing a banking application using open-source technology. You can create a personalized dashboard based on the modular and flexible structure of a DXP. This will help to create a personalized UX. It helps banks to optimize and revolutionize their business processes, for instance, it provides easy registration process ability by integrating with KYC (know-your-customer) services, which enhances the registration process. Chapter Summary • The testing framework helps to analyze the code as per functional requirement and enhance usability. Therefore a DXP is intended to highlight the strategy that is currently being used for creating enriched and intuitive UI design. • The DXP technology stack plays a vital role while designing the user interface. It provides information architecture and it helps in prototyping and keeping the main menu structure simple and consistent across layouts, making sure it’s intuitive and easy to use. Layout ensures consistent layout with proper same or similar content categorization for finding or searching. While keeping the layout simple, also make sure different elements are easily identifiable. • Mobility ensures a website, when used across devices and platforms, gives similar or same experiences including mobile apps and where possible makes it easy for customers to continue with their actions across platforms. Content provides customized content, based on users’ product and website usage patterns; it ensure the error messages are easy to understand and display a solution to the problem. • A DXP also ensures context-based, relevant information is displayed at the appropriate places. Navigation is consistent across pages and layouts, making user navigation easy. As shown in Figures 4-10 and Figure 4-11, the Transaction component has fewer fields in mobile view compared with desktop view. In mobile view, less important information would wrap up. • DXP concepts provide the comprehensive view to develop next- generation digital applications that are pertinent across all domains. 147

CHAPTER 5 Designing the Integration Layer After going through extensive UI concepts, now we look into the integration layer, which helps us to integrate with the DXP UI and further enhance DXP capabilities with a lean and flexible integration platform. Existing systems are integrated with the maintainable and scalable integration layer. The key features of the DXP integration layer are the following: • Various types of integration platform. • Architecture and frameworks used in integration layers. • Technology stack to develop integration layer. • Case study – banking experience platform. At the outset, we take into the picture the introduction and features of the DXP integration layer. DXP integration concepts help you make effective decisions on Web API (application program interface) management tools to integrate services with the DXP UI. According to the business requirement, the API management tool can be used and integrated with the DXP. Business requirements can help you to focus on understanding the basic requirements of the integration, for example, some requirements focus on portal and some on analytics services, so decisions should be made as per the requirement. © Shailesh Kumar Shivakumar, Sourabhh Sethii 2019 149 S. K. Shivakumar and S. Sethii, Building Digital Experience Platforms,

Chapter 5 Designing the integration Layer DXP integration concepts will address frequently asked questions in Integration Style, Integration System and services Sections of this Chapter on integration platform, such as the following: • Will the business requirement focus on management of existing services using API gateways? • Will the business requirement focus on REST (Representational State Transfer) services or will the requirement need to use other service protocols such as Simple Object Access Protocol (SOAP) or Java Message Service (JMS)? • Will the business requirement need flexible configuration, routing options, and user management (authorization) using different authentication and security standards (for example, Open Authorization (Oauth), Lightweight Directory Access Protocol (LDAP), Security Assertion Markup Language (SAML), Kerberos, etc.? • Will the business requirement need a caching mechanism? • Will the business requirement need event-driven architecture or synchronous HTTP calls? • Will the business requirement need an API management solution on premise or on the cloud platform? Integration Consideration A DXP takes into account the current environmental factors, which are systems already available in the environment of the organization such as customer relationship management (CRM), enterprise resource planning (ERP), other services, databases, content management system (CMS), rules engine, and solution gaps; and coexistence expectation, which tries to address the collaborated solution for the organization in the most cost-effective way. Hence while designing the digital platform, the approach is to design an integration layer that covers below mentioned points: • Minimize the risk of transition: The integration layer should be loosely coupled so that if any kind of transition or migration happens in any application in the DXP, it would not impact other services or applications. 150

Chapter 5 Designing the integration Layer • Maximize business value: Microservices over monolithic service architecture will provide maximum business value by breaking down functionality to the most basic level and then abstracting the related services. • Lower the total cost of ownership and management: Microservices architecture will increase the decoupling and separation of concern, hence the code base would be easier to manage as each service in the application would be independent of other services and thus it would be easier to add new feature or functionality to the platform. Conversely, in monolithic architecture, adding a new functionality will require smoke testing of the whole application. • Interface details: Go through the interface details, for example, API’s operations, inputs, outputs, and underlying types such as XML or JSON, which helps you to integrate the existing or third-party APIs with the DXP application. • Data requirements: A DXP consumes data in any format such as XML or JSON using any service protocol such as RESTLESS-SOAP or JMS, but interacts in RESTFUL-JSON within an application. RESTFUL-JSON interaction makes the application’s integration layer flexible and lightweight. REST services are architectural style. REST uses HTTP protocol and HTTP methods like GET, POST, PUT, and DELETE to communicate between client (Angular application) and server (integration) application; whereas, as SOAP is a message exchange style between client and server, SOAP services are Remote Procedural Call (RPC) architecture style, which would have service metadata (i.e., contracts) to communicate between client and server. • Restless: These services work with resources as well as its operations such as PUT, POST, DELETE etc. You need to identify the services and operations attached to REST Service, for example, operations such as SaveTransation(), GetTransaction(), DeleteTransaction(), UpdateTransaction() on transaction services. A service contract has to be shared with the client; the client will use these details to call the services. 151

Chapter 5 Designing the integration Layer • Restful: These services work with resources instead of operations. Communication between client and server happens using a Unified Resource Identifier (URI) over HTTP protocol using HTTP methods such as GET whenever someone needs to get the representation of an existing resource. PUT is used to add a new resource into the system. POST is to modify the existing resource, and DELETE is to remove the resource from the system. • While calling SOAP services from the client, the dispatcher in the web services would first deserialize the SOAP message, and then identify the operation from the message to be performed. Actions are mapped with the service methods, but while calling Restful services you have to identify the resources like a transaction, then the HTTP method (GET, PUT, POST, and DELETE) will identify the method to be called. Each method in web services is mapped with the HTTP method. • Integrating methods: Integration methods are decided on the basis of available interface and requirements of the integration patterns. We further explore integration methods in detail in this chapter. • Security: API layer security would raise the accessibility of the service calls. You need to ensure that only authenticated users of the application can access the API. It will differ on the basic of architectural pattern. • Monolithic architecture: In this architecture, the entire application is a process; the security module is implemented to provide authentication and authorization to the user. When a user logs in to the application, the security module of the application authenticates the user. After verifying the user details, a session is created for the user and a unique session ID is provided with the session. The session stores login user information such as name, permissions, and roles. The server is responsible for managing the session, and sends the session ID to the client and back to the server in subsequent requests. This session ID would be used to verify the user details. 152

Chapter 5 Designing the integration Layer • Microservices architecture: In this architecture, the application is split into multiple microservice processes, and each process holds the business logic of that particular module. Each microservice needs to be authenticated and authorized; hence, the logic of authentication and authorization wouldn’t be implemented in every microservice. To overcome this issue, a client application such as an Angular application can access the services through an API gateway where each of the services are registered and controlled. Authentication and authorization modules would be implemented in the API gateway, and all the microservices are registered with the API gateway. The API gateway is exposed to the client application and is responsible for routing requests to the appropriate microservices after verifying the user details. • Legacy modernization: You need to check whether the system has to interact with the legacy system, because the integration method and interface will differ and should be considered while designing the application. Data Formats Data formats the integration layer. There are mainly three types of data format, flat, relational, and hierarchal, but it is recommended to use the hierarchal data format because of its efficient structure. • Flat: It has one record per row, but there is a chance of duplicate entry in these things. The flat data format is not recommended in an integration system, but it is used in file systems and databases because it contains additional payload. In the following example, Account ID and Name are redundant in every row for a particular account ID, hence increasing the payload while transporting data in the network and therefore increasing the bandwidth. Account ID Account Name Transaction Type Transaction Amount Currency aBCBanK1234 sourabhhsethii neFt 1250 inr aBCBanK1234 sourabhhsethii rtgs 850 UsD 153

Chapter 5 Designing the integration Layer • Relational: This data format is used in Soap protocol to pass payloads that contain relational data in the SOAP envelop in XML format, such as account number and transactions. In the following example, account tags hold transactions in it. ABCBANK1234 Sourabhh Sethii NEFT 1250 INR RTGS 850 USD • Hierarchal: Hierarchal structure provides a lightweight and efficient structure to API providers to communicate between different systems, of which Restful-JSON data hooks are the best example, which helps us to quickly create and solve complex data transformation issues. { "account": "ABCBANK1234", "transaction": [{ "Type": "NEFT", "Amount": "1250", "Currency": "INR" }, 154

Chapter 5 Designing the integration Layer { "Type": "RTGS", "Amount": "850", "Currency": "USD" } ] } Integration Services In today’s technological world, there is a need to integrate multiple systems with the DXP. There are multiple platforms and design patterns to support in-built capability and pluggable features, to support DXPs and digital solutions where you integrate these services with the UI layer without changing the existing systems. This further enhances the capability and flexibility of the DXP. A DXP enhances the digital capability by supporting various integration services and styles that cover requirements from small-scale business to large-scale business, as shown in Figure 5-1. Services- Social Micro Based API Gateway Integration Services Integration Integration Services Marketplace In-Built Enterprise Pluggable Integration Connectors Service Bus Adaptors (ESB) Figure 5-1. Integration services Integration services supported by DXP and its capabilities are mentioned in Table 5- 1. 155

Chapter 5 Designing the integration Layer Table 5-1. Integration Services and Capabilities Integration Services Capabilities services-based integration restful and restless (soap) service integration provides digital integration capabilities. it has small-scale to large-scale application data delivery and integration capabilities. api gateway integration an api gateway is an api delivery-based application system used to interact with multiple applications. DXp integration with an api gateway system enhances secure and flexible data delivery, and integration with existing applications. social integration the DXp integrates with social collaboration platforms such as, Facebook, twitter, instagram, and many more. it consumes their api and integrates the data in the DXp’s application. Microservices integration Microservices are designed in such a way that every individual service is independently deployable, small and modular services in which services run as a unique process and communicate and deliver data efficiently between the multiple systems to serve a business goal. Marketplace integration Marketplace integration helps business users to integrate with multiple channels: to buy or sell their services and products on different channels while consuming a single service. esB (enterprise service bus) esB is used in medium-scale to large-scale business requirements where multiple systems inter with each other, for example, a banking domain. in-built Connectors an in-built connector has capabilities to connect a DXp’s application to multiple components, such as a JDBC connector used to access a database or grpC connectors used to do remote procedure calls, etc. pluggable adapters integration frameworks have various pluggable adaptors such as JMs adapter, data stream adaptors, etc. these adapters are used to access and convert data from one form to another form. you can access data streams using these adaptors. 156

Chapter 5 Designing the integration Layer Integration Styles, Protocols, Systems, and Patterns A DXP supports multiple design patterns and integration platforms as mentioned previously. Integration patterns supported and their implementation models are described in the consecutive segments of this chapter. Integration Styles There are different types of styles to consume data, for example, RPCs (remote procedure calls) and messaging file transfer, database, RMI (remote method invocation), that help to integrate multiple applications so that they can exchange data or information with each other. Remote procedure calls • gRPC (remote procedure calls): gRPC is a modern open-source high- performance RPC framework that can run in any environment. It can efficiently connect services in and across data centers, with pluggable support for load balancing, tracing, health checking, and authentication. It is also capable of browsers to back-end services connecting devices and mobile applications. Hyperledger fabric blockchain project uses gRPC to communicate to the blockchain network. Messaging File Transfer • JMS: It is used to send messages between applications; it is asynchronous in nature, which means the client is not required to send a request, and the message will arrive automatically to the client. It is of two types. One is the point-to-point messaging domain, where one message is delivered to one receiver only and a queue is used to achieve that. The other is the publisher-subscriber messaging domain, which is like broadcasting in that one message is delivered to all the subscribers; to achieve that, a destination called a topic is used to hold and deliver messages. • MQTT (Message Queuing Telemetry Transport): MQTT is a publisher-subscriber based messaging protocol that works on top of the (Transmission Control Protocol/Internet Protocol) TCP/IP protocol. It is designed for constrained devices with low bandwidth. It is best suited for IoT-based applications, as it allows you to send commands to controls, and to read and publish from IoT sensors. 157

Chapter 5 Designing the integration Layer Database • The application stores data in a database; you can integrate databases and consumes the shared data. You can integrate your application to SQL as well as NoSQL databases as per use case requirement. File Transfer • You can consume data from the files. Applications produce files of shared data for other applications to consume, and consume files that others have produced. Integration Protocols Integration protocols (also called web services protocols) define the structure and definition of message transfer between two applications. SOAP It is a messaging protocol exchanging information while implementing web services. It uses the XML message format and works with HTTP protocol for message transmission. The message format mainly contains three elements: envelop, header, and body. An example of a typical SOAP envelope would be the following: POST /Transaction HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: 200 SOAPAction: "" 2000 158

Chapter 5 Designing the integration Layer XML_RPC XML_RPC is an RPC protocol that uses the XML format to encapsulate the message and send it over HTTP protocol. An example of a typical XML-RPC request is: account.getBalance Sourabh_Sethi An example of a typical XML-RPC response is: 2000 USD JSON-RPC It is an RPC encoded in JSON format, as shown in the following example. It is a simple and lightweight protocol, and the DXP can consume data in any format but expose and interact in this protocol with other applications. An example of a typical JSON-RPC request would be: { "account": "ABCBANK1234", } 159

Chapter 5 Designing the integration Layer An example of a typical JSON-RPC response is: { "account": "ABCBANK1234", "transaction": [{ "Type": "NEFT", "Amount": "1250", "Currency": "INR" }, { "Type": "RTGS", "Amount": "850", "Currency": "USD" } ] } JSON-WSP It is same as the JSON-RPC protocol but has a service description specification with documentation method, name, and description provided along with requested details, as shown in the following example. An example of a typical JSON-WSP request is: { "type": "jsonwsp/request", "version": "1.0", "methodname": "getTransactions", "args": { "account": "Sourabh_Sethi } } 160

Chapter 5 Designing the integration Layer An example of a typical JSON-WSP response is: { "type": "jsonwsp/response", "version": "1.0", "servicename": "Transaction", "methodname": "getTransaction", "result": [{ "username": "Sourabh_sethi", "transaction_id": 123456, "amount": "200", "type": "credit" }, { "username": "Sourabh_sethi", "transaction_id": 123457, "amount": "1200", "type": "debit" }] } Integration Systems Integration systems consist of messages and their transformation from one form to another. We look into messaging systems, their construction, and transformation in this section. Messaging Systems A messaging system defines the message format and its transformation capabilities, where messaging channels are defined as per the service that contains the exchange in a piece of information. Pipe, filter, and routers perform the complex processing on a message or exchange (also called a piece of information), whereas filtered and processed data is passed to other messaging system with the help of routers. Messaging endpoints are the connections to a messaging channel to send and receive messages. 161

Chapter 5 Designing the integration Layer Message Routing Message routing is used to handle the scenarios where a single logical service is interacting with multiple existing systems using the list of dynamically specified recipients. Message routing is used along with a splitter, where one processes the exchange if it contains multiple recipients, each of which may have to be processed in a different way; after processing, one combines the results of individual related exchanges using an aggregator. Message Construction and Transformation Event messaging is used to transfer events from one application to another application, which is identified by a correlation identifier that contains a return address and is handled by a request reply message. Messages are wrapped in an envelope so that the existing system participating in a messaging system can establish a secure message header encryption method. Content filter and claim check patterns deal with the volumes of data, where large messages are handled but one is interested only in few data items from the entire message. Integration Patterns Integration patterns are the solution to commonly occurring integration problems, which are mainly divided as channel pattern (how messages are transported across channels), routing pattern (how messages routed between sender and receiver), transformation pattern (transformation of messages as per sender and receiver), and endpoints (how messages are consumed and exposed). Pattern – Simple (Internal) Integration The publisher–subscriber design pattern ensures that multiple applications consume the message at a time. Information standardization is based on source and synchronization of target systems with data required for its processing. The main focus is to synchronize information based on business events, thus removing any processing delays and overcoming the pain of managing a batch window. 162

Chapter 5 Designing the integration Layer The proxy design pattern provides a single point of entry to the target application; in addition, it supports policy implementation and ensures compliance monitoring. It reduces time of solution, price of integration, and testing efforts. Point to point ensures that one application would consume the message at a time. For example, it is used in RPC to transfer data. Pattern – Rich Integration Interaction Model Service and semantics standardization is mainly focused on abstracting the complexities by targeting flexible and loosely coupled connections. Composite service is focused on building flexibility into the services themselves in each of the dimensions of policy, process, and structure by hiding the multiple fine- grained services exposed by legacy systems and creating business-aligned coarse- grained services. Process Service is similar to composite service but with larger scope. Its focus is on hosting end-to-end business processes involving systems and people, which represents an end-to-end business capability delivered by business. Pattern – Multichannel Application Interaction Model Multichannel services provide faster response to business change requiring the support of new channels; consistency of capability and information is delivered to all channels. Multichannel and differentiated services provide faster response to business change requiring the support of new channels; consistency of capability and information is delivered to all channels. In addition, they provide added value to the privileged consumer while minimizing the price. The focus is on consistency across divergent interaction methods and technologies, building a generally related body of services and addressing specific issues of security and versioning. Pattern – External Partner Integration Interaction Model The focus is predominantly on security, closely followed by protocol translation, QoS, and semantic adaptation. Third-party applications are integrated with the DXP’s application. 163

Chapter 5 Designing the integration Layer Pattern – Event-Driven Adaptive Enterprise Handling opportunity, disruption, and threat: The focus is to capture events from multiple, loosely coupled systems and analyze them based on the situational, temporal context such as time-series analysis of system threats, system logs, etc. and respond based on the predefined rules. End-to-end process visibility with KPI monitoring: The focus is to capture events from multiple loosely coupled systems and analyze it based on the situational, temporal context such as time-series analysis of their key business metric and create visibility into key business processes. Data Standards Data standardization would help you to develop and agree on the most appropriate standards for the business requirement from various protocols and architecture, which further constitutes different payload types and data structures or formats. You can use a serialization mechanism to handle inconsistency of data structures and their varying payloads, which would translate data from one data structure to another and deserialize it, that is, extracting the data structure from data itself. Serialization is the process of converting an object into a stream of bytes to store the object or transmit it to memory, a database, or a file. It saves the state of an object so that it will be able to recreate it. The reverse process is called deserialization. The most commonly used protocol and architectural pattern are SOAP and REST, respectively. SOAP is a protocol, which has a WSDL file and contains information about web services and the location of the server. It uses service interface to expose its functionality and it requires more bandwidth. To make data communication and transformation more flexible and light, REST was introduced, which contains features like stateless, cacheable, layered, uniform interface. REST is lightweight and mostly contains JSON messages, therefore the size of the message is much smaller than with SOAP. The DXP integration layer consumes the data in any format but provides RESTFUL-JSON services to the DXP UI layer, which ensures lightweight and flexible data interoperability. 164

Chapter 5 Designing the integration Layer Flexible Integration Middleware The DXP concept is to support different middleware integration frameworks, which makes the DXP integration layer flexible so that the data and message are exchanged with multiple systems, irrespective of the technology and framework used in existing systems. Delving into the methodological world of services and integration of services along with to fulfill the integration requirement of EAI (enterprise application integration), ESB was introduced. It was considered as a central hub for integrating services but it is a single point of failure. So, to eliminate this issue, SOA (service oriented architecture) was introduced that, further enhanced with an ESB, has the flexible and distributed capabilities to solve the integration problems by implementing EIP (Enterprise Integration Patterns). Nowadays we are moving toward the microservices that build on lean structure, where services are developed, deployed, scaled, and maintained independently, which further enhances the business requirement, and time to production or market is reduced significantly. EAI vs. SOA vs. ESB vs. Microservices ESB and microservices are models based on SOA. The service-oriented model is an implementation to achieve enterprise application integration. • EAI is a framework that connects and integrates the different application and data source in an organization to simplify the business process. • The EAI framework provides cross-platform and cross-language integration to simplify the business service by exchanging information between the different applications. • SOA is an integration paradigm that is based on design principle of architectural interoperable services, which deals with data sources, software, and message processing. • ESB is a software architecture that provides integration of enterprise applications and services for complex architectures. 165

Chapter 5 Designing the integration Layer • ESB focuses on interaction and communication between components, to handle data transfer or message exchange between services. ESB is capable of transforming message data into a format that the application understands. In Figure 5-2, multiple applications are communicating and exchanging data in different formats using broker message communication. Figure 5-2. ESB Key requirements to fulfill the integration layer objectives are as follows: 166

Chapter 5 Designing the integration Layer Mutual Memorandum of Understanding (MOU) Service contracts or an MOU are useful before developing integration services, so as to ensure QoS, security, and scalability of services. Initially, the MOU was defined with a SOAP interface. Several frameworks and tools supported SOAP, but nowadays after the increasing popularity of Restful services, Swagger is becoming the most vital standard for defining, implementing, discovering, and testing REST services. Swagger-enabled API provides interactive documentation and software developer’s kit (SDK) generation capabilities. Service Protocol and Data Format While developing services, you should check the service communication endpoints, for example, HTTP endpoints for HTTP protocol-based applications; JMS endpoints for JMS applications; machine-to-machine (M2M) data transfer protocol (MQTT) endpoints for MQTT-based applications; and data format, for example, XML and JSON requirements. API Management API gateways are used to manage API. You have to consider the requirement, whether services are developed to use within the application or would be used by multiple applications across an organization. Why Do We Need Data Transformation Capabilities in DXP? In a business organization there are multiple applications interacting with each other, therefore the data will be organized and structured in different forms. For example, old systems are built on SOAP architecture but a DXP consumes REST services; hence, to make an old system compatible with a new modernized system, we need data transformation capabilities, whereas the DXP integration layer is capable of integrating with other systems irrespective of technology and framework. The DXP integration layer is capable of consuming data in any format and converts the data as per the DXP UI 167

Chapter 5 Designing the integration Layer requirements, that is, data can be in any format. For example, SOAP, XML, JSON, REST, comma-separated values, MS-Excels, databases, etc. would be transformed as per the DXP UI requirement, for example, Restful-JSON. However, without changing existing systems we can consume the services from the existing system and transform the data as per the DXP UI requirement, which makes the DXP integration lean and flexible. Integration Technology Stack and Architecture The integration technology stack depends upon integration architectural patterns, which are monolithic and microservices architecture. You would choose for your application while developing the DXP’s integration layer. Monolithic A monolithic architectural integration technology stack contains one of the integration frameworks according to your integration requirements, such as Apache Camel or other integration framework, as listed in Figure 5-3. These integration frameworks consume the data API from other third-party applications, transform the data according to the client application, and expose the API to the client application. Services such as mobile services, portal services, OTP services, ERP services, master data management (MDM) services, etc. are part of one single application. Figure 5-3. Monolithic integration 168

Chapter 5 Designing the integration Layer The API gateway exposes the services to the client application; the authentication and authorization module is part of the integration platform. The integration layer consists of API providers and API consumers. The API consumer consumes data and messages from other applications and implements authentication and authorization using respective modules, along with the integration logic and business logic related to particular services as per the API provider, which is consumed by the DXP UI layer (mobile and desktop client applications), other applications and platforms such as a blockchain network, IoT platforms, and AI platforms. Multiple integration services like social media services, analytics services, OTP services, and third-party services are consumed by the API consumer, whereas the API provider provides transformed API to the DXP client application. As shown in Figure 5-4, API consumers are responsible for consuming the data and consumed data is transformed by the integration layer, and API providers are responsible for exposing services to the UI layer. Figure 5-4. DXP monolithic integration 169

Chapter 5 Designing the integration Layer Microservices The microservices architectural integration technology stack contains a suite of small services, each running its own process and communicating with lightweight mechanisms on an individual port number. One service would contain one business capability, as shown in Figure 5-5. OTP services have OTP capabilities; similarly, other services have their own process and lifecycle. These services are separately deployable, hence a faster release cycle. You can use different microservices frameworks such as SpringBoot, Lagom, etc., as shown in Figure 5-5. Figure 5-5. Microservices ESB and API Gateway An ESB would be used for integration, orchestration of multiple services into one service, routing of services, and event handling and monitoring. An ESB is based on service-oriented architecture, which is an efficient service delivery platform. On top of an ESB, you could use a service gateway for security, policy enforcement, and exposing services as an open API to external consumers (public). A service gateway manages your integration services built with an ESB. 170

Chapter 5 Designing the integration Layer It is recommended that web services need to be pushed via an API gateway. The API gateway ensures security, as it uses open standard authentication frameworks and protocols such as SAML, Kerberos, Oauth, etc. Integration Security Security is the main concern when exposing an API to a client application over web. There are multiple frameworks and protocols that provide different aspects of security such as authentication, authorization, and integrity. Authentication and Authorization You can use different frameworks and protocols to authenticate and authorize the user on the basis of tokens and session to access the application, as per the requirements. We will become familiar with these frameworks and protocols in the following subsections. Protocols Authentication protocols are a type of cryptography protocols designed for transfer of authentication data between two entities in a secure way. Single-sign-on (SSO) can be achieved using these frameworks, where the user presents information (user ID and password) once and gets an access token that is valid to access all connected applications in the environment for a particular session. For example, Kerberos, NTLM, OpenID, and SAML are the most common protocols, which provide features like SSO by providing an access token that is valid for all the applications integrated with these protocol. This access token contains the authentication and authorization information of the user for a particular session. Frameworks You can use authentication and authorization frameworks like Oauth, Spring Security, etc. These frameworks provide a mechanism to integrate existing protocols and provide security implementation to your application. You can also use two-factor authentication (2FA) frameworks such as Google Authenticator, one-time password (OTP) authentication on mobile, Duo, Authy 2FA, etc. with other security frameworks to provide an additional level of security to the user. 171

Chapter 5 Designing the integration Layer Session Management Session management is a way to manage the state of the application. A DXP uses HTTP protocol to provide data and persistence services to applications because HTTP is a stateless protocol; stateless means that the server can send client requests to any node in the clusters while load balancing the application. Each time, a user’s request is independent because there is no state; a user request can be distributed to any server, so the way to maintain the state of the application between client and server is to use the session on the server side to save the user state because the server is stateful. There are different mechanisms to maintain the state of the application, such as session stickiness, session replication, and shared or centralized session. We can use sticky session to ensure that all requests from the specific user are sent to the particular server through a load balancer. But in case that particular server goes down, and the load balancer is forced suddenly to shift the user to a different server, all of the user’s session data would be lost. To overcome this problem, a session replication mechanism can be used;: that means each instance saves all the session data and synchronizes through the network using a library such as Jgroups, Hazelcast, Redis, etc. but synchronizing session data causes network bandwidth overhead. To overcome this problem, you can use a centralized session storage mechanism; that means whenever a user accesses any services, user data can be obtained from shared session storage. In some use cases this scheme works excellently and can be achieved using the JDBC (database) session storage mechanism so that all servers can access the same session object stored in the database. Token Management It is recommended to use session management at the server because the servers’ applications are stateful, and tokens management at the client to store user login status. Tokens are held by the users themselves and are stored in the browser cache or in the form of cookies. Each time a request is sent to the server, the server can check the identity of the user and determine whether it has access to the requested resource. As the token is used to determine identity, the content of the token needs to be encrypted to avoid security attacks; this can be achieved using standards like Java Web Token (JWT) which is open-standard (RFC 7519) and defines the token format and contents. It can encrypt content using various asymmetric and symmetric encryptions as per requirement. This ensures the integrity of data transferred between two parties, that is, client application and server application. 172

Chapter 5 Designing the integration Layer Integration Best Practices You should follow best practices while developing the integration layer as mentioned in Table 5-2. Table 5-2. Best Practices Area Best practice 1 service design • services must be designed to behave as stateless services, since there is no grid technology at this point. • services must not persist any session-related information or transient state of the request in memory, that is, use of shared variables or local cache must be avoided completely. • services must be designed to handle duplicates. if for some reason the same request message is transmitted twice, the service must enforce the messaging semantics in order to identify the duplicates and reject them. • it is possible that there could be multiple instances of the service operation running concurrently. service must share resources (file handles, socket connections, etc.) in a thread-safe manner, avoiding deadlocks. • if an exception occurs in a subprocess, then the typical practice is to propagate that exception to the parent process either through a “generate error” activity or “rethrow” exception. But, if the sub process is nested deep below from the main process, this could cause a problem since every subprocess must rethrow the error. it is a known fact that rethrow of exceptions is costly, since the entire copy of the stack must be embedded with each throw. hence, it is recommended that we report these exceptions by setting flags like “exception=true” and exiting the process with proper error handling. this should be propagated to the parent process in an optimal manner. (continued) 173

Chapter 5 Designing the integration Layer Table 5-2. (continued) Area Best practice 2 process and • avoid extensive “call process” hopping, or a long chain of process activity design calls for a single end-to-end integration. • prefer process starters over wait-for activities and allow for parallel processing. process starter fits better for BusinessWorks (BW’s) threading model because flow control is not available for wait-for activities. • reduce the number of activities, if possible. • each task requires overhead and reduces performance. • For example: if data could be mapped in a soap request activity, do not use a mapper activity only to map data for the soap request. • Database operation • Database operation in a nontransaction group • set maximum db connections = engine thread count value and set in admin. • Database operations in a transaction group • set maximum db connections = total number of expected concurrent transaction groups. • these parameters should be controlled through the flow control properties. • Use Batching instead of statement when possible to improve latency. • indexing is a must. 3 global variables • global variables (gVs) are kept in the memory in an XML structure and user does not need to worry about these getting stale. • remove unused gVs periodically. • gVs are read-only, hence could be accessed concurrently. no synchronized access required. • accessing the last element takes longer than the first element. so, remove unused gVs and arrange the rest from most frequently used (MFU) to least frequently used (LFU). 4 transport options • http is better performing than JMs on BW; soap protocol adds significant overhead, whether the transport is http or JMs. • soap over http has better throughput than soap over JMs. (continued) 174

Chapter 5 Designing the integration Layer Table 5-2. (continued) Area Best practice 5 Version control of as a