Customer Relationship Management (CRM)
Data Farm
Inc.®
|
The Technical "Know-How"
|
Check List: Transparency
The only way to present the "Transparency" concept or term to nontechnical audiences is
to present an opposite scenario of Transparency. Looking at the event when online bank
customers logged in to their bank site to come upon the bank message stating the bank site is
being updated and the bank services would not be available for few hours or next day. The
next surprise is when the bank website comes on with totally different looks, names, layout
and some of the previous site functionalities are no longer available. From our architectural
point of view, such an event has nothing to do with Transparency.
Transparency means invisible. In computer software, an action is transparent if it takes
place without any visible effect. Transparency is usually considered to be a good
characteristic of a system because it shields the user from the system's complexity
or development side effects and redoing of code.
Technically, to achieve "Transparency", an architect must give attention to the system
interfaces and the implementation of the following concepts or methodologies in the architect:
• Loosely coupled
• Tiers architecting
• Components structure
• Dynamic Business Rules
• Services (Independent )
• Software Engines
• Utilities Packages
• Common tier or packages
• Using Property files and Property Manager classes
• Intelligent DAO
• Templates
• Refactoring
• Security (Independent )
Security should also be Transparent to the system users and the development teams.
|
|
