In an enterprise system architecture, there will be plenty of applications doing a specific assigned responsibilities.
How many Applications in an enterprise business setup
For example, in an e-commerce business application architecture there will be individual application ranging from:
- website application accepting customers orders,
- payment application doing payment transactions,
- inventory application providing up to date stock of the products being sold,
- delivery systems responsible for customer order delivery tracking,
- customer support application dealing with cancellations, complaints
- and many other applications.
And of some such applications in any Enterprise IT Solutions are home grown, while other being third party apps brought from different software vendors, to be used AS IS and rest will have some kind of customization here and there to meet the business needs.
When active development is going on in any system, at times there will discussion on which application should do a specific functionality.
For example, if Application A (e.g., a website) is getting data from Application B and if there is need to reformat the data to be displayed in Application A, then you should always ask a question whose responsibility it is to reformat the data.
In the current context the responsibility of reformatting as per the need Application A should remain with Application A boundary. Such application specific requirements should be addressed within themselves.
Importance of correct Responsibility assignment to an Application
For whatever reason if you ask Application B to reformat the data, then Application B is bound to change whenever formatting requirements changes in Application A. Such formatting requirements are bound to change often based the user feedback.
Not just that, other users of Application B might be impacted by such frequent changes and Application B will become more fragile over time because each connecting application might ask data in different format.
A real Example on assigning data formatting responsibility
Sometime back, I was part of design discussion involving 3 different applications.
- "Application A" wanted to display an entity Name, sourcing from different application.
- "Application A" would call "Application B" which is a kind of messaging layer to get the required data.
- Application B would in turn call "Application C" to get the data to service "Application A" request.
With that said, Application A (the end user app) wanted to display "N/A" when the entity doesn't have name stored and there was thought that, "Application B" would have that logic. Such business logic is very specific to "Application A" and also requirements are bound to change over time with the customer feedback.
Hence the view of "Application B" (messaging layer) reformatting the data as per the needs of "Application A" didn't fly when the design meeting concluded. So "Application A" was asked to format the data as per their needs.
No comments:
Post a Comment