Every project execution generally begins with a great sense of enthusiasm. A sense of creating new excites the project team. There is involvement but tend to look away from the potential blockages in executing the project. In this blog, I shall attempt to identify the critical aspects of the project execution, if left unattended have the capability to explode like a bomb. So, let’s begin the task of spotting the bombs :smile:
The critical aspects can be grouped as:
- Architecture of the solution – end to end
- Choice of the User Interface
- Low level design
- Business Logic – development and enablement
- Performance
- Code Reuse
Descend to a level deeper ->
- Architecture of the solution – end to end
Some of the important aspects to be addressed in this step can be stated as common sense, but as everyone has experiences it’s not so common, in practice.
- Try your best of depict the solution in form of UML diagrams: Use Case Diagram, System diagram and Sequence Diagram.
- Clearly define the Communication channel from the user/frontend to the backend database and vice versa. It is not enough, to simply draw a line from the UI to the backend database. It requires the architect to clearly depict the form and mode of data flow.
- The communication channel needs to identify if the data will flow as RAW data or will it be encapsulated in a service and navigate through the network. It should also state if the communication channel needs to be secure ex: SSL
- In the solution spanning across systems, middleware is a critical system. As an architect it is not a foregone conclusion to always suggest a Middleware. An insightful architect will always access the need and the benefits of having the middleware as part of the solution.
- Identify the endpoint of the solution. The access – points in the UI, middleware and backend. This will bring more clarity to the envisaged solution.
- If the solution is to be processed into steps (BPM), identify the steps and the relevant flow. It would be recommended to use any eclipse/web tool to depict this as an Activity diagram.
2. Choice of the User Interface
User Interface is generally considered as a default choice. Now, you may ask, how is it defaulted? It is generally defaulted based on the IT department which is responsible to implement the project or the preference of the project team. Hmm, doesn’t seem like the best practice. The factors which should influence the architect/team in identifying the Best Suited UI are:
- Recommendations of the vendors like SAP
- Skillsets of the project team. Now, in my opinion this should be the least priority as customers concern isn’t the project team skill but the solution to his problem. If the skills are not available, then hire them.
- The cost of the infrastructure and the necessary license. In terms of cost of the project, this information will be very important for the customer. A proprietary technology will always impact the customer’s budget.
- Future of the UI or the lack of it.
3. Low level design
Perform the necessary tasks of low level design like No. of views and components. Also identify the utility components and the interface between components. An additional effort to depict the same in terms of Component diagram and dependency diagram will provide more clarity to the developers and customer.
Explore the opportunities for easier maintenance of the application by customers using Configurations/Property files.
4. Business Logic – development and enablement
- As per MVC paradigm, business logic should be loosely coupled from the view. But, the decision still remains, whether it should be loosely coupled from the backend. The technical team should decide if the business logic of the application should be close/inside the backend.
- From my experience, again this decision is usually defaulted based on the situation discussed in point 2(Choice of the User Interface). An ABAP team, generally wishes to encapsulate all the logic in functions as the team is more comfortable with ABAP functions than the OOPs classes.
- The need of the hour is to push for better practice and handling the data in ABAP classes is definitely a step in the right direction.
- In Java/Open-source world, the choices are plenty. So a choice with effort and skillset of the team could be a reasonable factor in deciding the solution. Still, the customer benefit has to be at the core of the decision.
5. Performance
The least mis-understood requirement. It is always, the least response time per request w.r.t the data handled in the request. Still the decision has to be taken as whether the request should be sent to server at every action or should data can be cached as trade-off to provide a better performance, in a real time environment.
6. Code Reuse
The benefit of the performing the above steps efficiently, will be availability of re-usable components and application. The scope should not be limited to the specific application and efforts should be put to ensure standards to facilitate usage across applications and technologies.
Please share your feedback and lets strive to build better solutions.
Regards,
Sharath
