Anatomy of Architecture - II

November, 2008
by Mahesh Mohta

About the Author
Mahesh Mohta, Technical Architect, Infosys Technologies Limited

Mahesh has been working in the Performance Engineering domain for more than 5 years. He has solid experience in Architecture evaluation, System Sizing, Workload & Performance Modeling and Performance Testing. Mahesh’s overall software experience is 8 years.

Anatomy of Architecture I and II are a work in progress. If there are any significant aspects or approaches that the reader feels he has omitted or which should be addressed in another way, please feel free to contact him:

Mahesh Mohta
INFOSYS TECHNOLOGIES LTD
44 Electronics City, Hosur Road
Bangalore 560100, India

Mahesh_mohta@infosys.com

Mobile : +919886173942

Recap

In my previous article, we discussed the approach to evaluate existing architecture or to consider what is architecturally required for new applications. Subsequently, we also discussed the most vital ingredients of technical architecture and how they can impact an application. In this article, we will talk about the ingredients of application architecture, ingredients of database architecture & design (OLTP only), ingredients of application framework components and mechanisms to evaluate these architectural ingredients.

Section 3: Application Architecture

Apart from technology aspects chosen to implement the business functionality, the way business needs are architected in an application is also very important. Application architecture also derives significant influence from the domain for which application is built, so that it can have enough flexibility to take care of future enhancements and modification. Some of the examples below, which I came across while evaluating architecture, may help in understanding how many hassles can be avoided by correctly architecting from the domain and business needs. These examples highlight some of the aspects of application architecture. Refer to Appendix B for a comprehensive list of application architectural aspects.

Example 1: For a big shipping client, containers were tracked based upon their last milestone received. While dealing with thousands of container numbers in a day, it is common to enter wrong digits and update milestones for wrong containers (Operator entered container number in hand held system by looking at the container in front of him). There were many transactions done once a milestone is received for a container and later on, realizing that it is done for a wrong container, required a data fix from the backend. This may invite data instability, which would be very difficult to track. Instead of this, the application architecture team proactively provided "Logical Undo" feature, which, by knowing all the required steps, will undo the last transaction. This was thoroughly tested in the testing phase and fully ensured data integration.

Example 2: In a similar example, where adhering to architectural principles helped the application team to reduce time and increase customer satisfaction: the application was accessing a database (DB2) and the data was converted from database types into Java types. A single point of handshaking was devised for that, wherein instead of converting data individually in every section of code, a common API was called to convert data. Every database call has to mandatorily call that API whether the conversion is required or not thus creating a single tunnel, from which all the data coming from database has to pass. Later, the client wanted to convert some of the column values into another (like showing "US Dollars" instead of "USD") in all the screens. Given the size of the application, any such change in all the screens requires 40 person days of effort (including testing); but, trapping the value in a data tunnel and converting its value then and there reduced the effort to 2 person days (including testing)

Example 3: In another case for a port client, while designing the database for the product, component boundaries were not respected to save build time. Any component code (say component A) can refer to the tables of another component (say component B) to retrieve data (ideally it should retrieve data by accessing component B's interfaces). Later on, when this company was acquired by another port organization, who was interested in only implementing 3-4 components of the product, it was virtually impossible to decouple those 3-4 components because of such tight coupling. Ultimately, looking at the cost of decoupling, that product was trashed and fresh components were built. Therefore around 100 person years of effort went to waste.

These examples show how an application architect can proactively provide stability and longevity to the application.

Section 4: OLTP Database Design

Although database design consideration is a part of the Application Architecture section; nevertheless, considering its vastness and importance, it's worth mentioning separately. This section will list only the database specific design considerations which are not covered by the "Application Architectural parameters" and "Technical Architectural parameters" sections.

Like technical architecture and application architecture, database architecture and design is critical. Experience reveals that most of the performance or scalability issues have roots in poorly designed databases (around 60% performance problems are because of bad DB design or bad SQLs). A well tuned database guarantees half of the success of the application. Listed below are some of the examples, where changing the database model or design improved application scalability and performance. Again, these examples highlight some of the database design and architectural aspects. For a comprehensive list of database design and architectural aspects, please refer to Appendix C.

Example 1: While doing assessment for one of the banking and insurance client products, it was found that one of the tables which were storing images as well had (over)grown to 1 TB. A table was supposed to hold 90 days of data and every day thousands of records were loaded and thousands of records (older than 3 months) were deleted; however, space vacated by deletion of records was not reclaimed before reorganization activity. Reorganization time of that table was getting close to an unacceptable 7 - 8 hours. Adding more memory and doing reorganization at the end of the week in a lull period was earlier chosen as a solution. But this solution was having a performance impact because the queries were expected to get slower on Thursdays/Fridays before the reorganization activity. Reports which are supposed to generate in 10 min were taking an hour to complete. Later on, table partitioning was suggested, wherein the table was partitioned into 90 different partitions and every day a new partition was attached (for new data) and the oldest partition (data older than 90 days) was removed. The whole activity was completed in half an hour. Cost of changing the application could have been avoided if growth of the table was accounted for at design time.

Example 2: In one of the cases, performance SLAs for a reporting application was very stringent and reports were doing lot of numerical calculations (calculating sum and average of various fields) based upon the existing column values. Materialized views were suggested as a solution at the architecture & design time. Performance base lining revealed that the query could have taken 105 sec (without materialized view), but was now taking only 7 sec. to complete (SLA time given by client was 20 sec.). The end result was high customer satisfaction and repeat business later.

Example 3: Also, for one insurance client, the application was unable to scale because of locking and concurrency issues (database was DB2 UDB on Solaris). Application memory reserved for locking became exhausted when two big batch processes were executed simultaneously. This resulted in sequential processing of batch jobs. The batch window spilled over to the online window processing time, causing loss of business. Also, the product was not able to scale because it was unable to handle beyond a certain load due to locking issues. Later on, it was determined that the isolation level of those transactions was running on default and had not been set appropriately. This caused row locks for all the rows of the data pages accessed, irrespective of the row being part of the end result (default isolation level was set to RR). Converting the isolation level from RR to CS helped the application to reduce locking memory requirements drastically and helped the application to run those processes in parallel and assume extra workload. Considering the volumes and nature of the transactions at architecture and design time would have avoided a lot of hassles and the loss of business.

These examples show how database architecture and design boost performance and add to customer satisfaction and increase ROI for the customer.

Section 5: Framework Evaluation

A software framework is a reusable design for a software system, which provides a basic conceptual structure to solve or address complex issues. It provides standardization in work along with enhanced productivity. Frameworks hide complexity and let the developer use the plug-ins and give enough flexibility to change behavior to a certain level without changing the application code. For example, error handling frameworks should provide the developer flexibility to change the error message text attached without doing any change in application code.

Similarly, to improve productivity, the application should have ready templates for simple screens. For example, all the "Search-Result" screens or "Maintaining reference data screens" (having simple insert/update/delete feature without any complex processing) have almost similar behavior. Usually these screens are more in number but have very low complexity. Providing a framework for such screens will let the application team spend less effort in trivial tasks and concentrate more on complex screens.

Please refer to Appendix D for comprehensive details of different frameworks required by the application and their expected features or facilities.

Section 6: Compilation

After collating the business requirements and deriving the relevant architecture aspects applicable for the candidate system architecture, the objective should be to deduce the compliance of the candidate architecture vis-à-vis business needs. To achieve this, assign the appropriate weightage and applicable rating to the architectural aspects. A template table is provided below:

Table

Based upon this, a sample table would look like:

Technical Aspect
Weightage
Rating

Remarks or Gap Description

Multi-channel Access Capability (Thru Mobile and Desktop)
5
3

Allows access through Web and Hand Held Devices. SMS based interaction is missing

Portal Based interface for customer interfaces
5
0
Needs to be built fresh

Event Notification Capability through configurable and preferred medium
5
3

Existing components needs to be modified

Asynchronous Communication Capability

5
5

Related components can be used as it is

Partner Interfacing Capability Using Web Services
3
5

Related components can be used as it is

Partner Interfacing Capability Using EDI
5
5

Related components can be used as it is

Batch Handling Capability
5
4

Parallelism is not used. Existing components needs to be modified

Standard based messaging support using XML, JMS
5
5

Related components can be used as it is

Multi-platform deployment capability
5
2

Only Java based application components has this feature

Workflow/workbasket based capabilities
4
0
Needs to be built fresh

Partial upgrade and Hot Deployment capability
5
0
Needs to be built fresh

N-Tier Deployment Capability
5
3

Existing components needs to be modified

Infrastructure component's Scale up and Out Capability
5
5

Related components can be used as it is

Infrastructure component's Clustering and Load balancing Capability
5
5

Related components can be used as it is

Infrastructure component's Fail over capability
5
5

Related components can be used as it is

Application User session control and monitoring capability
5
1
Needs to be built fresh

Infrastructure components management capability
5
4

Existing components needs to be modified

Standard interfacing between technical layers
5
3

Existing components needs to be modified

On the basis of above information, generate a compliance graph depicting percentage of existing architecture which can be used "AS IS", i.e., Full Compliance (rating 5s only); can be used with some modification, i.e., Partial Compliance (rating 2-4); and aspects not catered or very poorly catered in candidate architecture and requires full rework, i.e., No Compliance (0-1 rating). This report can be presented to management for taking higher decisions. A sample graph is shown below:

Graph

Similarly, information should be collected for application architecture, database architecture and framework compliance. Graphs should be plotted to find out how much the application is in line with business needs.

Architecture Tradeoff Analysis Methodology (ATAM)

Violation of architectural principles can work to the application's benefit. There may be scenarios where one less significant architectural aspect is consciously violated to achieve another high architectural aspect or to support a typical business scenario efficiently or where an architectural aspect is knowingly ignored because of commercial and entrepreneur decisions. It is worthwhile to investigate the trade off behind the scenarios and re-rate the aspect accordingly. Although ATAM is quite a wide topic in itself, and this paper is not meant to provide detail, ATAM can definitely help in compiling and rating architectural aspects efficiently and; therefore, must be considered.

Conclusion

Evaluation of architecture should be purely based on architectural needs of the current and envisaged business requirements. It should not emphasize only the fancy capabilities of candidate architecture, which may not be of much use in envisaged system. Architects should have a holistic view of technical, application and database architecture, which are driven by business requirements, along with the standardization provided by the frameworks. The same holds true for those applications which are to be built from scratch.

Appendix B (for Section 3): Application Architecture ingredients

  1. Functional Coupling & cohesiveness (modularity): Different application components should exhibit functional cohesiveness i.e., similar or related functionality should be packaged together.
  2. Decoupling: Application modules should have very loose coupling between themselves so that any module can be upgraded or replaced independently.
  3. Capability to deal with unavailability of External Interfaces: There should be a mechanism to gather or hold information in case of external interface unavailability and upload such information into system later. This ensures the availability of the application to its end user even if the external application (on which this application depends) goes down for the reasons beyond control.
  4. Capability to deal with unavailability of components: (Inter-component interaction): Components supporting mission critical functionality should be available through out even if one/some of the non-critical components are not available. System should have facility to switch to asynchronous mode of interaction between components whenever one of the component goes down (given the functionality allows the delay caused by asynchronicity). This feature ensures the availability of the critical components of the application to its end user even if some of the components of application are not available.
  5. Role based security: The administrator should be able to grant different privileges to different roles on the same screen. Application code need not be altered to provide or revoke grants to user. There should be ready-made roles having related grants/privileges which can be attached a user.
  6. Large Files' uploads and downloads capability: These must be available in different desired formats like excel, pdf, etc.
  7. Audit Log Maintenance capability to track who has done what in which sequence.
  8. Capability to generate performance log and functional log: Need to have configurability to switch it on or off. Usually it remains "OFF" in production environment but will be switched "ON" on need basis to get data for tracing issues in production which are not getting replicable in test environment.
  9. Error Display: Uniform model for raising and logging / displaying business errors, warnings, information and exceptions.
  10. Data presentation: Capability to present data in different formats such as XML, CSV or PDF to let user download and store the information on his local machine. This is usually required when user does an important search or transaction and wants to store relevant data for future reference.
  11. Internationalization Capability: Internationalization is the ability of the application to adapt various languages and regions without engineering changes in code.
  12. Data management: Ability to maintain structured and unstructured data and provide proper storage and search facility for the same.
  13. Flexible report output control capabilities: Examples are column and row selection and their ordering besides their presentation in different format.
  14. Publish and Subscribe model for Secure Data, Event and Service access control. This will ensure the secure data or sensitive event information should be accessible to intended audience only.
  15. Security context sharing: Ability to share security context with other components and applications.
  16. MVC adoption: Separation of User Interface from business logic and business logic from technical architecture.
  17. Maintenance of Application's logical transaction context in UI: Each Application transaction may consist of multiple business service calls; therefore, data should get committed only if the logical transaction is committed.
  18. Logical Undo: Logical Undo Capability of critical transactions i.e. user should have a system supported feature to undo his last transaction. This feature should be provided for critical transactions where chances to revert back are higher.
  19. Business Logic engineered as stateless services. A stateless service is a service that does not maintain state information between message calls, i.e., it doesn't remember any information related to previous transactions. Stateless services require considerably less resources compared to stateful services.
  20. Business service interfaces should be location agnostic.
  21. Application scalability options like threading, parallelization, a-synchronicity engineered in components.
  22. Business flexibility: Flexible business rule and process flow control externalization capability.
  23. Authentication: Application should have common Application user authentication and authorization process.
  24. Service Access: Capability to disable/enable component services.
  25. Data ownership: No multiple ownership of the data.
  26. Template readiness: Availability of the design templates in the design tools. Also, the application should have availability of the template screens for simple search-result screen to expedite the build.
  27. Configurability: Single Business Logic configurable across multi-instance deployment by use of external Business Rules & Parameterization. This means application code should not be altered to cater different scenarios of the same business functionality, i.e., to cater regional needs of various or specific regions. The change in application behavior should be achieved by configurable parameters.
  28. Help: On-line context sensitive help to the end users and support staff.
  29. Single point of handshaking between the different tiers. In 3-tier architecture, the presentation tier should call controller layer through a common method, all the data returned from the data layer should call a common method to pass it back to the controller / presentation layer.
  30. Documentation: Proper documentation of functional and non-functional requirements in a standardized format.
  31. KPI Measurement: Provision for measuring Key Process Indicators (KPIs). KPIs or Key Performance indicators are counters which measure the business related parameters to track the usage of load on business per unit of interval. This provides insight on business volume (transaction wise) and in projecting future capacity needs of the application. In an airline booking system, one booking may have a reservation for one or multiple seats. Technically both kinds of bookings might have the same impact on system resources but, in terms of the business, there may be a huge difference. Therefore, having a KPI for number of seats reserved per day for a flight may help the business to make better decisions.
  32. Abstraction: Proper abstraction from Tool and Technology level dependencies in cases such as
    • Time/Date functionality
    • Inter Process Communication
    • Environment parameter retrieval
    • System event generation
    • File I/O
    • Data Access.

Appendix C (for Section 4): Database Architecture ingredients

  1. Entity Relationship Diagram (ERD): Availability of well defined ERD, consistent with the actual system.
  2. Cross referencing: Entity relationship should respect the layering and tiering defined in logical view of the architecture, i.e., there should be no cross referencing of entities beyond their logical boundary through foreign keys to avoid tight coupling.
  3. Object Oriented Design: Database design should provide support for Object Orientated design and make full use of it wherever applicable.
  4. Naming convention: Usage of standard naming convention ( for Manageability)
  5. Modularization: Different Schemas (logical partitioning) for different modules. Although some database supports a schema mechanism (Oracle), others don't. In such cases, logical partitioning of components may not be possible, but naming conventions to identify different module's objects should be adhered to.
  6. Ownership: Only Schema owners should be allowed to manipulate the data of their corresponding schema.
  7. Normalization: Normalization aspects of DB tables (3rd normal form compliance) with respect to transaction profile.
  8. Database maintenance processes: There should be processes in place for the database maintenance. Key processes include:
    • Indexing: There should be a proper indexing strategy in place, which not only helps in creation of indexes at relevant places but should also review the existing indexes and their applicability and should help the database administrator to phase out redundant indexes.
    • Statistics updating: Timely collection of table/ index/column statistics to improve performance of the system.
    • Reorganization: Tables and indexes should be analyzed or properly organized (if database supports) timely to free up the empty space created by deleted rows.
    • Backup and Recovery: Application should have online backup support (if 24x7 availability is required). There should be a proper backup strategy defined to get the minimum backup window and quickest recovery time. Recovery mechanisms should support uncommitted critical transactions (for database crash).
    • Archiving and Purging: Proper Archival/Purging strategy should be in place to phase out non-usable data. Any regulatory compliance must be properly addressed.
  9. Database monitoring processes: Effective monitoring is a key to any good performing database. The application should have a diagnostic monitoring process in place rather than reactive monitoring processes, where problem is identified after occurrence. Monitoring processes should primarily have an ability to identify or generate:
    • Explain Plan: SQL execution plan to optimize bad SQLs
    • Top n time consuming SQLs: Top n SQLs which are taking maximum execution time.
    • Top n CPU intensive SQLs: Top n SQLs which are consuming maximum CPU.
    • Top n most frequently executed SQLs: Top n SQLs which are executed maximum number of times.
    • Top n SQLs performing worst sorts: Top n SQLs which are performing worst sorting and consuming disproportionate memory.
    • SQLs holding Locks: SQLs which are holding locks and not releasing them and causing other SQLs to wait. In many scenarios, this may lead to deadlocks or lock escalation as well.
    • Poorly parameterized SQLs: SQLs which are not properly parameterized and each occurrence is separately compiled and causing performance degradation.
  10. Partitioning: Very large tables should be properly partitioned.
  11. Audit trailing: Ability to switch on / off audit trailing facility in all tables. Audit trailing facility has two levels:
    • Level1: To track who has created or updated the row and at what time. This should be enabled for all the tables.
    • Level2: To track what exactly has changed in the row. This may be required only for few critical tables.
  12. Materialized Views/Tables: Usage of summary tables or materialized views/tables where desired data needs to be aggregated and is calculation intensive and high performance is desired.
  13. Primary keys should be those columns which are not supposed to be changed. Typically, even if there is a change expected in a primary key column, it is not advisable to change primary key. Best way is to insert a new record with new primary key and invalidate or delete the previous record.
  14. Usage of sequences, where a primary key has more than 3-4 columns. (Primary key columns should form a unique key in such a scenario) and all the child tables should refer to the sequence in their foreign keys.
  15. Foreign Key usage: Can be used to enforce validation within a module especially when the data can be sourced from multiple places such as file feed, UI, Hand-held devices, etc.
  16. DB Triggers: There should be no business logic in database table triggers
  17. Provisions for critical transactions:
    • Versioning: Provision for versioning of critical transactional data to retain the transaction log (Do not overload database with inadequate versioning).
    • Logical deletes: Only Logical deletes for critical transactions. The database should not physically delete the row deleted by the user, but should mark a flag to be identified by the application that the row is logically deleted.
  18. Backup and Recovery: Applications should have online backup support (if 24x7 availability is required). There should be proper backup strategy defined to get the minimum backup window and quickest recovery time. Recovery mechanism should support uncommitted critical transactions in case of a database crash.
  19. Data distinction: Clear distinction between and current and historical data (There may be scenarios where data having maximum version is not current and vice versa) or to store historical data of a transaction separately.
  20. No cascaded deletes and updates: Suppose Table B is a child of Table A (i.e., a primary key of table A is defined as foreign key in table B). This means a record can not exist in table B without having a corresponding record in table A. Whenever a record is deleted from table A, logically all its child records should also cease to exist. If the cascaded delete/update is defined, then any delete/update that occurs in table A will automatically be reflected in table B's corresponding records as well even if program logic is not deleting/updating Table B explicitly. This is wrong. Ideally there should be no cascaded deletes or updates. The programmer should first delete or update in the child table (Table B in our case) and then in the parent Table (Table A).
  21. Usage of domain values where field values are fixed.
  22. Replication: Efficiency of Replication management (if data needs to be replicated from any other database).
  23. Effective usage of asynchronous processing in critical transactions to enhance performance.
  24. Isolation level and locking: Application program's isolation level and locking mechanism should be carefully designed to avoid performance degradation caused by locking.
  25. Data storage: Usage of appropriate data storing technique according to the application transaction profile (like RAID 0+1, RAID 5 etc.).

Appendix D (for Section 5): Framework parameters

  1. Presentation layer framework (Thin/thick client): Most of the applications require users to interact with the system (except batch applications where the scheduler runs the batches without any user intervention) and usability of the application has a major role in end user satisfaction criteria. No wonder that's why front end designing has such an important role in the application life cycle. A good presentation layer framework ensures consistency, high productivity and reusability. A good presentation layer framework must ensure the following:
    • Usage of standard frameworks for application development for example usage of struts for web applications.
    • Search & Result block (for typical search / result screens).
    • Table, Form or tree block.
    • List of Values Block (LOV).
    • Role based application Menu.
    • Multi step wizard (Tab paged).
    • Error / Exception Block.
    • Menu, action and input item level security.
    • Generic Validations (Null, Size).
    • Format checking (Numeric Format, String Format, Date Format).
    • Support for JS Libraries and CSS classes.
    • UI Guidelines and Standard document.
  2. Generic Usability features: Apart from a look-n-feel perspective, there are some other usability features which help a user to provide all required information to aid his work. Listed below are such key features:
    • Client-side printing
    • Context Sensitive on line Help
    • Notification and Alerts Support
    • Internationalization (Language, Units of Measurement, Date Formats)
    • Extensive Keyboard-Action Mapping Support.
  3. Business logic: Persistent framework support: A well designed framework for business logic unit not only ensures good reusability but also ensures good modularity and maintainability. Therefore, a framework for business logic must ensure following features:
    • Support for EJB/COM+, JDO/ADO and JDBC/ODBC
    • Transaction management i.e. ability to identify system steps into one logical transaction and provide commit / rollback ability for that transaction
    • Row level security
    • Object Relational Mapping Tool support
    • Web Service Support
    • Framework for Database query builder to support ad-hoc query.
    • Support for multiple data source.
  4. Communication framework: Many applications need to go beyond the boundaries of servers and are required to connect users anywhere through their mobiles (SMS), at their workbench through their desktops/laptops (e-mail) or at work in the field (Hand Held devices). Such applications must have a reliable and strong communication channel; therefore, their communication framework must support the following:
    • Support for POP3/SMTP
    • Send and Receive Message Using FAX, SMS, EDI and Message Queue
    • Facility to Track message flow
    • Parse and validate message
    • Facility to support multiple protocols
    • Facility to provide content-based messaging service
    • Facility to maintain routing and format preference for users/customers
    • Synchronous and asynchronous messaging.
  5. Collaboration framework: The application may be required to collaborate with other desktop applications to provide seamless integration between user's day-to-day activities and application profile. Depending upon the nature of application, integration needs with different application might vary. In general, a typical collaboration framework should provide following features:
    • Collaboration with local mail client / scheduler like Lotus notes
    • Scheduling appointment
    • Retrieve the calendar entry
    • Isolation layer to hide the complexities of document management system
    • Search, Store & Retrieve Document
    • Converting data in various formats like CSV, PDF and DOC.
  6. Security framework: Term ‘security' is self explanatory and its importance requires no introduction. Its purpose is to be an immune system for the application to fight any malicious outside attack. A typical security framework must provide the following features:
    • Delegate the authentication to SSO server.
    • Facility to manage roles and role groups to be allocated to the users.
    • Structure to maintain hierarchy based user-level access control for:
      • Screen
      • Operation
      • Data
      • Field
    • Encryption/Decryption of selective columns in the database. The encryption key to be secret, not available to anybody but application itself.
    • Communication and message level security features.
    • Row and Column level security.
    • Hierarchy based user profile / context.
  7. Printing - Server side: Like client side printing, server side printing is also important, especially for reporting applications where large reports need to be scheduled for printing regularly. Framework for server side printing should provide the following features:
    • Configuration of print queues as physical and logical queues
    • Ability to reassign the print job to a different print queue
    • Structure to maintain User and Program level printing preference.
  8. Error/Exception Handling: Error or Exception handling is a very important feature of any application. No matter how carefully an application is designed or coded, there are always chances to have errors. The application may need to raise business exceptions if a user is filling in in-appropriate data. Therefore, error or exceptions should contain as much information as required by the support team to resolve the error without losing its simplicity to be understood by business users. Error/Exception frameworks have been evolved a lot but typically any such framework should provide at least the following features:
    • Support for error types as:
    • information
    • warning
    • error
    • fatal
    • Ability to Log error
    • Framework for showing the error in consistent manner irrespective of the error source and layer
    • Ability to raise events on occurrence of errors.
  9. Tracing / Logging: Traces and logs are those pieces of information which the application leaves behind for analysts to find out what exactly it did while going through any transaction. That's why traces/logs provide very helpful information to examine if an application is throwing unexpected error messages or corrupting data. A good tracing mechanism not only stores the error information but also stores the data used in transactions. This is important because there may be cases when an application is not throwing any error or exception AND is not yielding desirable results or is corrupting data. Traces/logs provide all important information to resolve such issues. Apart from that, traces/logs help in workload modeling and characterization to be used later for simulation and performance testing. Therefore, a good tracing/logging framework must ensure:
    • Ability to enable/disable tracing at Business process level
    • Ability to enable/disable tracing at session level
    • Tracing a session for following levels
      • no-log
      • information
      • debug
      • warning
      • error (suggested for production environment)
      • fatal error
    • Configurable output medium as
      • SNMP
      • socket
      • file
      • Database.
  10. Reporting: No application (which is storing data) is complete without reporting. Reports are those important pieces of information on which the current state of the business is evaluated and future decisions are taken. Therefore, any application having reports must provide an accurate and consistent experience to its users without losing flexibility to view data from different angles. To satisfy all the information needs of an application, any good reporting framework must provide:
    • Canned report invocation interface
    • Hierarchy based Security
    • Report Definition Manager
    • Ad-hoc Reporting
    • Batch mode server side Reporting
    • Generated reports to be stored in document management system.
  11. Batch Framework: Batches process bulk data at the back-end where user intervention is least required. Therefore, a good batch framework has a responsibility to utilize the resources optimally, maintain performance, store any anomaly which a user might wish to see later, and inform associated personnel in case of any contingency without losing its usability and maintainability. Hence, a good batch framework must ensure the following:
    • Facility to define, parameterize and schedule batch processes
    • Restart-ability
    • Transaction management
    • Commit Frequency control
    • Security
    • Error and exception management
    • Message based triggering
    • Ability to log, debug information
    • Facility to raise events on completion of process
    • Running various threads of the same batch
    • Running batches in parallel.
  12. Session Management: Sessions are very important for web based applications; therefore, their management must ensure the optimum usage of resources without compromising their aid to the application. Session management must ensure the following:
    • Ability to log user sessions, concurrent sessions
    • Session Termination
    • Session Restriction
    • Logically start or stop the applications
    • provide hooks to capture various system activities
    • Quality of service monitoring.
  13. Auditing: Auditing is required to track who has changed what and when. Do not confuse auditing with tracing/logging as tracing/logging happens at application code level and auditing happens at database entity level. Typically an auditing framework must support the following features:
    • Log complete/partial audit trail for marked entities
    • Interface to view audit information.
  14. Configuration parameters: In this global era, a single application is deployed at multiple sites to support global business without losing local variations. These local variations vary from one place to another; therefore, any good application provides support to alter application behavior through configuration parameters without touching application code. Thus, a configuration management framework must support:
    • Hierarchical configuration parameter management
    • Interfaces to change configuration parameters.
  15. Design Patterns: Design patterns are tried and tested ready-made solutions to already known problems. They are the best examples of reusability. Therefore, the architect must ensure the usage of appropriate design patterns wherever applicable. The whole list of design patterns is bit long (but readily available). Some of the widely used design patterns, which an architect must consider are:
    • Façade pattern
    • Factory pattern
    • Singleton pattern
    • Command pattern
    • Observer pattern.

Disclaimer

This paper is currently evolving and, hence, may not be covering all the aspects of architecture. Architects are recommended to think beyond the boundary of this paper while evaluating architecture. Readers are requested to email the author , if any significant aspect should be added.

References

  1. Weightage is the severity of business need for the architectural aspect. Higher Weightage implies higher degree of importance of the associated aspect for the business.
  2. Rating indicates how successfully candidate architecture fulfills the business needs. There may be a case, when the Weightage of a aspect is high but the rating is low, this means that business direly needs that particular capability of the architecture but the candidate architecture is not capable enough to fulfill the same. Similarly, there may be a case when Weightage is low and rating is high, which simply means that the business may live without that capability of architecture but the candidate architecture successfully provides the associated aspect.