Autopsy of Architecture

Mahesh Mohta
INFOSYS TECHNOLOGIES LTD
44 Electronics City, Hosur Road
Bangalore 560100, India
Mahesh_mohta@infosys.com
Mobile : +919886173942

Introduction: Application architects often face situations when they need to

quickly evaluate the architecture of an existing application. Architecture as a
whole is such a wide subject that often after the evaluation exercises,
architects realize that they missed one or more important facets, which were
quite important for the exercise.
This paper intends to give ready reference not only to the architects who wish
to evaluate the architecture of an already built up application but for those
architects also who are building an application from scratch. This paper lists
key facets of architecture against which application can be evaluated or which
should be the key ingredients of an application. Although all the facets listed in
this paper may not be applicable for a particular application, it is architects’ /
evaluators’ responsibility to choose the right facets for their application.

Objective & Scope:

Objective of this paper is to provide the different facets of architecture, which
are key ingredients of any application but still are independent of the
functionality of the application. This paper provides
a) How to evaluate Technical Architecture (Technical features)
b) How to evaluate Application Architecture (Design of application)
c) How to evaluate Database Design (OLTP* only)
d) How to evaluate application framework components (uniform channel
for technical and application architecture)
* OLAP Database design is out of scope for this paper

Approach
To evaluate any architecture, one should know the architecture needs. First
the business drivers of an application should be identified and architectural
needs of the application should be derived from the same. Then map the
different facets of architecture satisfying the architectural needs. Remember,
business requirements are the key drivers for any architecture. There is no
point in having fancy capabilities in architecture, which are not having any
business drivers.
It is important to note that architectural requirements for a system should be
completely and unambiguously specified. For example, requirements like
“Architecture should be robust” have no meaning unless it is quantified as
“Architecture should be able to provide 24x7 availability support with
maximum system downtime of 5 min”. Otherwise, word “robust” is more likely
to be interpreted differently by developer and business. First job of an
architecture evaluation is to elicit the specific goals against which the
architecture will be evaluated.

Figure shown below is the sample mapping of business needs with the
architectural facets:
Business Requirements and Characteristics Key requirements for Architecture Architecture Solution FOCUS

Volatile Business
Scenario Adaptive to N-Tier
Change Application
(Flexible, Agile)

Rapid Expansion Adaptive

And Infrastructure
Internationalization (layered/Virtualized)
Increased
Information sharing

QoS Engineered
Across Layers and
Productivity
Performance Tiers
Through
And
Automation
Scalable

Event Driven
(Immediate,
Tactical and
Multi Channel Strategic)
Electronic Means Access
Of Access for
Users

Loosely Coupled
Integration
Service Based
Secure

Increase Profitability

Component
Based
Durable
Improve Quality
Of Service

Based upon various business requirements a set of key architectural

requirements were identified. Approach adopted in this paper categorizes them
into three different categories

Technical Architectural parameters

A Good technical Architecture must be judged against the parameters below

Infrastructure components’ Scale up and Out Capability

Infrastructure components’ Clustering and Load balancing Capability

Infrastructure components’ Fail over capability

Infrastructure components’ management capability

Partner Interfacing Capability Using Web Services

Partner Interfacing Capability Using EDI

Asynchronous Communication Capability

Batch Handling Capability

Event Notification Capability through configurable and preferred
medium (like E-mail / SMS)

Standard based messaging support (peer to peer and broadcasting)

Multi-platform deployment capability

Workflow/workbasket based capabilities (Process flow control flexibility)

Rule Engine based capabilities (Business rules enhancement flexibility)

Partial upgrade and Hot Deployment capability

N-Tier Deployment Capability

Application User session control and monitoring capability

Scalability, Availability, Reliability, Modifiability and Performance

Standard interfacing between technical/functional layers

Availability needs of the applications are taken care of through
appropriate clustering, and Disaster Recovery mechanism

Facilitate tools to monitor, audit and trace the availability of interfacing
systems

Select Technologies, standards and Vendors based on their ability to
endure for at least 5 years

Provide means to identify bottlenecks, usage pattern and forecast
capacity and scalability needs

The architecture should facilitate transparent IT systems access (Single
Sign On).

Avoiding use of ad-hoc and point-to-point integration mechanism by
having a generic and standard communication and messaging channel

Multi-channel Access Capability (Thru Mobile device and Desktop)

Portal Based interface for customer interfaces

Data migration capabilities

Confidentiality and integrity of the data being stored or transmitted and
the measures employed to secure the information

Facilitate maintenance and control of external and internal user profiles

Connection pooling mechanism

Object Caching mechanism

Subsetability1

Conceptual integrity: Conceptual integrity is exemplified in architecture
that exhibits consistency, i.e. the architecture should do the similar
things in similar ways

Application Architectural parameters

Functional Coupling & cohesiveness in components (modularity)

Capability to deal with unavailability of External Interfaces

Capability to deal with unavailability of components (inter-component
interaction)

Role based security i.e. Administrator should be able to grant different
privileges to different roles on the same screen
1
Subsetability: This is the ability to support the production of a subset of the system. While
this may seem like an odd property of architecture, it is actually one of the most useful and
most overlooked. Subsetability can spell the difference between being able to deliver nothing
when schedules slip versus being able to deliver a substantial part of the product.
Subsetability also enables incremental development, a powerful development paradigm in
which a minimal system is made to run early on and functions are added to it over time until
the whole system is ready.

Large File upload and download capability

Audit Log Maintenance capability

Capability to generate performance log and functional log (in success
scenarios as well) with configurability to switch it on or off.

Uniform model for raising and logging / displaying business errors,
warnings, information and exceptions.

Capability to present data in different format like XML, CSV or PDF

Internationalization Capability

Ability to maintain structured and unstructured data

Flexible report output control capabilities like column and row selection
and their ordering besides their presentation in different format

Publish and Subscribe model for Secure Data, Event and Service access
control

Ability to share security context with other components and applications

Decoupling aspect of application modules

Separation of UI from business Logic

Separation of business logic from technical architecture

Maintenance of Application's logical transaction context in UI. (Each
Application transaction may consists of multiple business service call,
data should get committed only if the logical transaction is committed)

Business Logic is engineered as stateless services

Business service interfaces are location agnostic rather they are
abstracted and externalized

Scalability options like threading, parallelization, a-synchronicity
engineered in components

Flexible business rule and process flow control externalization capability

Common Application user authentication and authorization

Capability to disable/enable component services

No multiple ownership of the data

Availability of the design templates in the design tools

Availability of the template screens for LOV and simple search-result
screen.

Single Business Logic configurable across multi-instance deployment – by
use of external Business Rules & Parameterization

On-line context sensitive help to the end users and support staff

Single point of handshaking between the different tiers. For example in
3-tier architecture, 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.

Proper documentation of functional and non-functional requirements in
a standardized format.

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

OLTP Database Design Parameters

Although database design consideration is a part of Application architecture
section, but considering its vastness and importance its worth mentioning its
parameters separately. This section will list only the database specific design
considerations which are not covered by the “Application Architectural
parameter” section.

Availability of well defined ER diagram, consistent with the actual
system

Entity relationship should respect the layering and tiering defined in
logical view of the architecture.

Support for Object Oriented design

Usage of standard naming convention ( for Manageability)

Different Schemas (logical partitioning) for different modules

Only Schema owners should be allowed to manipulate the data of their
corresponding schema.

Normalization aspects of DB tables (3rd normal form compliance) wrt
transaction profile.

Proper indexing of tables (No over indexing) and usage of hints (if
appropriate)

Tables and indexes should be analyzed (if database supports)

Very large tables should be properly partitioned.

Ability to switch on / off audit trailing facility in all tables

Ability to view the SQL execution plan to optimize bad SQLs

Usage of summary tables or materialized views/tables where desired
data is calculation intensive and high performance is desired.

Primary keys should be fields which are not supposed to be changed.

Usage of sequences, where primary key is having more than 3-4 columns.
(Primary key columns should form unique key in such a scenario)

Usage of foreign keys to enforce validation within a module.

No Cross referencing of foreign keys beyond schema boundary

No business logic in database table triggers

Provision for versioning of critical transactional data. (Do not overload
database with inadequate versioning )

Logical Undo Capability of critical transactions.

Logical deletes only for critical transactions.

Recovery mechanism for uncommitted critical transactions in case of
database crash

Clear distinction between and current and historical data (There may be
scenarios where data having maximum version is not current and vice
versa)

No cascaded deletes and updates

Usage of domain values where field values are fixed.

Archival / Purging strategy

Replication management (if data needs to be replicated from any other
database)

Ability to enhance and revoke users’ access grants on application screens
without changing the application code

Effective usage of asynchronous processing in critical transactions to
enhance performance

Provision for Key Process Indicators (KPIs)

Controlled locking mechanism (optimistic locking is preferred)

Usage of appropriate data storing technique according to the application
transaction profile (like RAID 0+1, RAID 5 etc.)

Framework Evaluation parameters

Category Features and facilities Required

Presentation Layer Framework

Thin/Thick Client
Framework
1 Search Block
2 Table Block
3 Form Block
4 Tree Block
5 List of Value Block
6 Menu
7 Multi Step Wizard (Tab Paged)
8 Error Block
9 Menu, Action and Input Item level security
10 HTML based Client (only for thin client)
11 XML based Client (only for thin client)
Presentation Validation
Libraries
12 Generic Validations(Null, Size)
13 Numeric Format
14 String Format
15 Date Format
16 Support for JS Libraries and CSS classes
Generic Usability
Features
17 Client-side printing
18 Context Sensitive on line Help
19 Error and Alerts Support

20 Internationalization (Language, UoM, Date Formats)

21 Extensive Keyboard-Action Mapping Support
22 UI Guidelines and Standard document
Business Logic
Persistence Framework
Support
23 EJB/COM+
24 JDO/ADO
25 JDBC/ODBC
Data Access Layer
26 Transaction management
27 Row level security
28 Object Relational Mapping Tool support
29 Web Service Support
DB Query Builder &
Business Logic
30 Query Definition screen
31 Security
32 Multiple Data Source
33 Rule Engine Support
Communication
Send and Receive
Message Using EMAIL
34 Support POP3
35 Support SMTP
Communication
Framework
Send and Receive Message Using FAX, SMS, EDI and Message
36 Queue
37 Facility to Track message flow
38 Parse and validate message
39 Facility to support multiple protocols

40 Facility to provide content-based messaging service

Facility to maintain routing and format preference for
41 users/customers
42 Synchronous and asynchronous messaging
Collaboration
Collaboration with local
mail client / scheduler Collaboration with local mail client / scheduler like Lotus notes
43 Scheduling appointment
44 Retrieve the calendar entry
Isolation layer to hide the complexities of document management
DMS system.
45 Retrieve Document
46 Store Document
47 Search Document
Others

48 Converting data in various format like CSV, PDF and Word

Security
 49 Delegate the authentication to SSO server
Facility to manage roles and role groups to be allocated to the
50 users

Structure to maintain hierarchy based user-level access control for

51 Screen
52 Operation
53 Data
54 Field
Encryption/Decryption of selective columns in the database. The
encryption key to be secret, not available to anybody but
55 application itself

56 Communication and message level security features

57 Row and Column level security
58 Hierarchy based user profile / context
Printing

Server-side Printing Configuration of print queues as physical and logical queues

59 Workstation
60 Network

61 Ability to reassign the print job to different print queue

62 Structure to maintain User and Program level printing preference.

Error Handling
support for error types as
information
warning
error
63 fatal
64 Ability to Log error

Framework for showing the error in consistent manner irrespective

65 of the error source and layer.
66 Ability to raise events on occurrence of errors
Reporting
67 Canned report invocation interface
68 Hierarchy based Security
69 Report Definition Manager
70 Ad-hoc Reporting
71 Batch mode server side Reporting

72 Generated reports to be stored in document management system

Tracing

73 Ability to enable/disable tracing at Business process level

74 Ability to enable/disable tracing at session level
 Tracing a session for following levels
no-log
information
debug
warning
error
75 fatal error
Configurable output medium as
SNMP,
socket,
file,
76 database etc.
Batch Framework

Facility to define, parameterize and schedule batch processes

77 Restart-ability
78 Transaction management
79 Commit Frequency control
80 Security
81 Error and exception management
82 Message based triggering
83 Ability to log, debug information

84 Facility to raise events on completion of process

System Management
User Management
85 Ability to log user sessions, concurrent sessions
Session management

86 Session Termination
87 Session Restriction
88 Logically start or stop the applications

89 provide hooks to capture various system activities

90 Quality of service monitoring
Auditing
91 Log complete audit trail for marked entities
92 interface to view audit information
Configuration Parameters

93 Hierarchical configuration parameter management

Design Patterns
Various Design patterns like
a) Façade pattern
b) Factory pattern
c) Singleton pattern
d) Command pattern
94 e) Observer pattern
Compilation
After collating the business requirements and deriving the relevant
architecture facets applicable for the candidate system architecture, 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 facets.
Sample table is mentioned below
Architectural facets Weightage2 (Scale 1-5) Rating3 (Scale 0-5)
Facet 1 5 5
Facet 2 4 3
Facet n 5 0

On the basis of above information, generate a compliance graph depicting

percentage of existing architecture which can be used “AS IS” (rating 5s only),
can be used with modification (rating 1-4) and facets not catered in candidate
architecture (0 rating). This report can be presented to management for taking
higher decisions. Sample graph is shown below:
Java Fram ew ork Requirem ent Com patiability

AS IS
30%
Partially

Not Exist
59%
11%

Architecture Tradeoff Analysis

Violation of architectural principles is not always against the application’s
benefit. There may be scenarios where one less significant architectural facet
is consciously violated to achieve another high architectural facet or to support

2
Weightage is the severity of business need for the architectural facet. Higher Weightage
implies higher degree of importance of the associated facet for the business.

3 Rating indicates how successfully candidate architecture fulfills the business needs. There
may be a case, when the Weightage of a facet 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 business may live without that
capability of architecture but the candidate architecture successfully provides the associated
facet.
a typical business scenario efficiently or where an architectural facet is
knowingly ignored because of commercial and entrepreneur decisions. It is
worthwhile to investigate the trade off behind the scenarios and re-rate the
facet accordingly.

Conclusion
Evaluation of architecture should be purely based on architectural needs of the
current and envisaged business requirements. It should not emphasize the
fancy capabilities of candidate architecture, which may not be of any use in
envisaged system. Same holds true for those application as well which are to
be built from scratch.

Disclaimer
This paper is currently in evolving state, hence may not be covering all the
aspects of the architecture. Architects are recommended to think beyond the
boundary of this paper while evaluating architecture. Readers are requested to
mail author, if any significant facet is suppose to be added in this paper.