Business Transformation Projects: The Role of a Transcendent Software Engineering Concept (RoTSEC)

Business Transformation Projects: The Role of a Transcendent Software Engineering Concept (RoTSEC)

DOI: 10.4018/978-1-6684-6620-9.ch015
OnDemand:
(Individual Chapters)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

The hyper evolution of technologies is a major problem for transformation projects because such projects take a long time to terminate. That is why there is a need to find transcendent technological artefacts for all technology generations. The role of a transcendent software engineering concept (RoTSEC) is central for implementation projects in general and is also especially crucial for business transformation projects (or simply projects) because transformation phases incur major changes in the existing sets of the archaically defined requirements, development, and platform models. Software engineering (SE) is probably the riskiest part of a project because it consists of many related complex factors and dependencies, for example, the need for SE's artefacts to interact between various actors like project management, business users, business architects, implementation developers, and other project actors.
Chapter Preview
Top

Introduction

This chapter keywords clearly show the complexity and the need of having a holistic Project approach in order to scope its strategic goals and objectives. That is achieved by defining a generic and standardized Enterprise Architecture (EA) based RoTSEC that can be used in any final application (or business) domain, like finance, education, industry, finance, or any other. Where RP’s main concerns are reversing common Source Code Components (SCC), business models, algorithmic codebases, and data structures refinements. These operations are carried out mainly in phases B and C, as shown in Figure 1. An RP can be conducted using a polytechnical mathematical (or simply a Polymathic) model or the AHMM4SE, which uses a transcendent approach, that refers to surpassing the complexity of heterogenous approaches and ensures its integrity.

Figure 1.

The architecture development cycle

978-1-6684-6620-9.ch015.f01
Source: The Open Group (2011a)

The proposed Polymathic AHMM4SE, supports the iterative transformation of a legacy system, using standard methodologies, like The Open Group’s (TOG) Architecture Framework’s (TOGAF) Architecture Development Method (ADM) as shown in Figure 1.

Figure 2.

The project’s construct

978-1-6684-6620-9.ch015.f02

Like in all Information and Communications Systems’ (ICS) related development works, the recommended approach is a cyclic one, which is based on Project’s implementation phases, that includes the SEP and RP. RPs are performed mainly for SCCs that include: 1) Refinement; 2) Development and Operations (DevOps); 3) Automated tests and qualifications; and 4) Modelling and design activities. The RoTSEC proposes an efficient use of RP, which might face complexities due to: 1) The implementation of complex and heterogenous software components; and 2) Their maintenance (Koenig, Rustan, & Leino, 2016). In this chapter the RoTSEC was applied on a concrete Project in the form of a Proof of Concept (PoC), that is related to a leading European Bank. The mentioned Project was mainly used to support an SEP/RP transformation process of the Bank’s legacy framework which is based on an International Business Machine (IBM) Mainframe and Java Extended Edition (JEE) 1st tier concept and architecture. The used EA methodology was TOGAF and its main iterative dynamic cycle manager the ADM; where the modelling language was ArchiMate. The ADM manages the underlying design, DevOps and governance activities. As shown in Figure 2, such a Project needs a qualified EA specialists, Managers (or Architect of Adaptive Business Information System-AofABIS)) and an RP capable team; this team was the main weak point which proves that the SEP is the most critical one. Although the main focus of the ADM was on the implementation of the organization’s (simply the Entity) refactored EA patterns and SCCs, the ADM also was responsible of storing and managing the Entity’s Enterprise Continuum with the transformed Building Blocks (BB); knowing that there are two types of BBs: 1) Architecture BBs (ABB); and 2) Software BBs (SBB), which englobe the SCC libraries (The Open Group, 2011a). As shown in Figure 2, The RoTSEC based Framework’s Interaction includes: 1) Decision Making System (DMS); 2) Knowledge Management System (KMS); 3) Critical Success Factors (CSF) (and areas Critical Success Areas-CSA) Management System (CSFMS); and 4) An inhouse implemented RoTSEC. To prove RoTSEC’s feasibility the author uses his unique adapted PoC and Research and Development Process (RDP).

Top

The Research And Development Process

RP based legacy ICS transformation initiatives have generated create a paradigmatic shift in the domains of SE innovation, delivering agile implementation models. Legacy systems distributed across various ICS nodes, use a whole set of heterogenous technologies and methodologies. The transformation of ICS artefacts in the form of Project BBs is a major paradigm shift in the ICS industry, that is supported by RoTSEC’s Evolution using RP (PERP). As shown in Figure 3, the PERP focuses on the refactoring of SCCs.

Complete Chapter List

Search this Book:
Reset