GDPR Architects Executive Summary Architects Plans Testing

Spring Replacement (The Elephant in The Room)
Introduction
Spring Framework is appealing to certain IT audience and it is still used by a lot of companies. Our team consider Spring Framework is as the expression goes: "There is an elephant in the room." We believe we have homegrown alternative which can use any existing Spring code. The goal of any framework is to address Usability, Security, Loosely Coupled, Transparency, Refactoring, Performance, Redundancy, Errors, Scalability, Expandability, Latency, Flexibility, Intelligence, Reliability and Availability. Plus no use of XML documents as ways to control the flow of running applications. Another important point is that Spring code lacks Intelligence.

Our Main Concern:
The main drawback of Spring Framework is that Spring structure (the controllers-dependences-DAO-MVC-services-Hibernate-Description) would grow out of control and maintenance becomes almost impossible. As for reusability, we do not believe reusability is practical nor cost effective. Our main concern is that different team members may view Spring structure and processes differently and that is not a good practice and source of conflicts and errors.

Spring Code Conversion:
We have a section at the end of this page presenting step-by-step Spring Code Conversion.

Use Case:
              Spring Replacement with Our Business Intelligence Framework (BIF)


Description:
Looking at Spring buzzword such as Aspect Oriented Programming (AOP), Dependency Injection, Inversion of control (LoC), IoC Container, setter-based injection, interface-based injection, constructor-based injection, XML Configuration using p-namespace, Programmatic Transaction Management, Declarative Transaction Management, ..etc, sadly these buzzwords may have different meaning to different people. Therefore, Spring beginners or critics may have a case.

Briefly Describe This Use Case
Our Spring Framework Replacement must appeal to Spring Framework Fan Club and its conversion should be automated and it should not be a costly task in term of the learning curve, time and effort. The replacement effort should be worth the effort and time spent in the conversion.

What is Business Intelligence Framework (BIF)?
In a nutshell, BIF is a pyramid structure of processes. It is composed of:

       Marco Decisions - Top Management
       Micro Decisions - Business Process
       Process - Architectural Structure
       Code - Development and Testing

Primary Actor:
Clients, managers, architects, developer, testers and any Spring users or fan.

Goals:
How to convince Spring Fan Club with all their code developed and tested, that our conversion is: first worth reading or searching, secondly it is worth considering, then lastly converting to a homegrown reusable system. BIF addresses every level of management including development.

Conversion:
Our Spring Conversion uses "Bottom-Up", where Spring code conversion can be accomplished with automation and it would be tested with minimum effort. The Conversion starts with code and build the Processes, the Micro Decisions and the Macro Decisions.

Analysis
How can a framework link all management levels from the CEO's Macro Decisions which include the company future to the developers' code. To make our presentation more clear let look at the following example. How can CEO of company or a branch within a company build a running website with all its security, customer service and functionalities with a GUI tool. The lesson we can learn from the invention of the computer mouse, where the computer mouse was created to make using computers and software as easy as pushing mouse button. Our BIF would have a GUI interface for CEO to build and run a functional website which would present the company products and services. Such a GUI tools also would provide guidelines from services such as CRM, BI and Analytics and other CEO services. They would help CEO strategically decide on what must be done.

Looking at present day Spring framework, the GUI tools we are proposing would be used by the clients stakeholders and their supporting technical teams.

Our analysis is based on creating cloud based and loosely coupled maps which are controlled by the Dynamic Business Rules. System admin would be able to edit the Dynamic Business Rules using GUI editor to changes values and processes and their execution sequences. All are supported by Common, Utilities, and services modules or components.

Architect
Our BIF Architect view from 2,000 foot is what Figure #1 presents.

2000 ft view of BIF Architect
2,000 Foot View of BIF Architect Diagram - Figure #1

Decision Support System (DSS) - Dashboard would help with decision making based on Analytics and CRM services. CEO would be working with GUI DSS interface and making decisions and changes in real-time. The GUI interface is to help the CEO and the supporting staff in building a running application based on all existing frontend templates available to choose from. The decisions pyramid is levels of maps, where the top level is supported by the one below.

Architect Components:
Our architect is structured as the following cloud based and loosely coupled componets:

       Admin GUI Editor
       Dynamic Business Rules
       Management Tracking
       Marco Decisions - Top management decisions
       Micro Decisions - Business Process and analysis
       Business Objects (MVC) - instantiate services
       Services - use engines
       Engines - each performs one task
       Development - Java Code
       Database Adapters - abstract factories and factories
       Web Services - to handle the outside world
       Utilities
       Commons
       Reports
       Errors and Exception handlers
       Logging
       Testing - including user, integration, auto testing ..etc
       Statistics - system performance

All these structured components are controlled by the business rules which is plain text and NOT XML.

BIF Architect
BIF Architect Components Diagram

BIF components are grouped as follows:

       1. Mapping of Maps (Java HashMap)
       2. Editing and running Dynamic Business Rules
       3. Database Adapters
       4. Supporting Services
       5. Logging and Tracking of errors and exceptions
       6. Management Tracking
       7. Web Services
       8. Testing

The main execution is:

       Loop through the Macro Decision map
       For every value in Macro Decision map is a Micro Decision (Business processes) Map
       For every value in Micro Decision map is to instantiate a Business Object
       Every Business Object will instantiate a number of Service Objects
       Business Objects are developed for different tiers in the MVC structure
       Security should be applied to Business Objects based in on which server-tier they are running in
       Each Service Object will instantiate a number of Engine Objects
       Each Engine Object will run its Java code

The Dynamic Business Main task is to provide:

       The latest values (calculation, comparison. etc ) and constants
       Execution Sequences of services
       Score and weight for Intelligent (Think in Abstract) decision making
       Latest validation criteria
       Latest decision values for Intelligent (Think in Abstract) decision making
       Dictionary of values for parsing business values

Management Tracking:
Each process would be logged, and tracked for statistics and management tracking. This would help evaluate the system performance as will as any bottleneck code modules. Such tracking should be turned On/Off as needed.

Documentation:
We view management and documentation as important pillars in any project. Documentation is a tool for reusability, tracking, training, audit trial, as well as lessons to learn. We recommend that the project documentation is composed of the following:

       JavaDoc - for code documentation
       Build-in Templates: which would be filled out by the users.
       Free Hands: where users to give their own document and feedbacks.

Supporting Services:
They are used for saving redundancies in the development of components.
Reports are also part of tracking as well as supporting services.

Testing:
Testing, test plans and automatic testing should available for managers to schedule and run.
Testing processes and values should be automated the same way as dynamic business rules.
Different type of test should part of testing plans.

Addressing Security:
Security is handled by having all components posted be on the application servers and connected to the database servers. They also can be part of the Baronet. Business Objects may use different server-tier and security must be applied.

As for Web Services, it should handle the communication with outside world and store data in the database.

Quickest Example:
The quickest example to illustrate how our DSS system works in real-time. Let us assume that based on our Analytics-CRM services which is recommending that the company needs to run a promotion and certain items to be put on sale (reduce by 50% in prices) in the next two weeks. Such decision created in Macro Decision level would not require any changes in any of the lower levels include Java code. With same talk, if the business analyst decides to add an additional Micro Decision to an existing Macro Decision. If the newly added Micro Decision is composed of the existing processes (different in sequence of execution), then the analyst would be able to add such changes and no changes would be required by any of the other levels. With help with DSS interface, CEO decision would be translated in real-time to changes in the company's portals with 50% promotion without any changes in the other three levels.

We added Dynamic Business Rules to help make the system dynamic and changes in any rules would not require any code change.

Spring Code Conversion:
We recommend that the conversion team should develop automated parsers which would parse the Spring files and create a map of the Spring folder structure of who is doing what. Such a map can be used to identify the following:

       DAO
       Services
       Engines
       Business Objects
       Supporting services
       Commons
       Properties

The steps for Spring conversion is done as follows:

       Develop the Map structure
       Build a conversion map
       Build small pilot project
       Test the pilot project
       Lessons Learn
       Start the main conversion



       Facebook Facebook Facebook Facebook Facebook
About us Contact Site Map Support Privacy Terms All rights reserved