Autopsy of Architecture

8/14/2019 Autopsy of Architecture

1/11

Autopsy of ArchitectureMahesh Mohta

INFOSYS TECHNOLOGIES LTD44 Electronics City, Hosur Road

Bangalore 560100, India

[email protected] : +919886173942

Introduction: Application architects often face situations when they need toquickly evaluate the architecture of an existing application. Architecture as awhole is such a wide subject that often after the evaluation exercises,architects realize that they missed one or more important facets, which werequite important for the exercise.This paper intends to give ready reference not only to the architects who wishto evaluate the architecture of an already built up application but for thosearchitects also who are building an application from scratch. This paper lists

key facets of architecture against which application can be evaluated or whichshould be the key ingredients of an application. Although all the facets listed inthis 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, whichare key ingredients of any application but still are independent of thefunctionality 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

ApproachTo evaluate any architecture, one should know the architecture needs. Firstthe business drivers of an application should be identified and architecturalneeds of the application should be derived from the same. Then map thedifferent 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 anybusiness drivers.It is important to note that architectural requirements for a system should becompletely and unambiguously specified. For example, requirements likeArchitecture should be robust have no meaning unless it is quantified asArchitecture should be able to provide 24x7 availability support withmaximum system downtime of 5 min. Otherwise, word robust is more likelyto be interpreted differently by developer and business. First job of an


2/11

architecture evaluation is to elicit the specific goals against which thearchitecture will be evaluated.

Figure shown below is the sample mapping of business needs with thearchitectural facets:

Volatile BusinessScenario

Productivity

ThroughAutomation

Rapid ExpansionAnd

Internationalization

Electronic MeansOf Access for

Users

Increase Profitability

Improve Quality

Of Service

Adaptive toChange

(Flexible, Agile)

IncreasedInformation sharing

Performance

And

Scalable

Multi ChannelAccess

Secure

Durable

N-TierApplication

AdaptiveInfrastructure

(layered/Virtualized)

QoS Engineered

Across Layers and

Tiers

Event Driven

(Immediate,

Tactical andStrategic)

Loosely Coupled

IntegrationService Based

Component

Based

Business Requirements and Characteristics Key requirements for Architecture Architecture Solution FOCUS

Based upon various business requirements a set of key architecturalrequirements were identified. Approach adopted in this paper categorizes theminto three different categories

Technical Architectural parametersA 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)


3/11

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 (SingleSign 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 similarthings 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 differentprivileges to different roles on the same screen

1 Subsetability: This is the ability to support the production of a subset of the system. Whilethis may seem like an odd property of architecture, it is actually one of the most useful andmost overlooked. Subsetability can spell the difference between being able to deliver nothingwhen schedules slip versus being able to deliver a substantial part of the product.Subsetability also enables incremental development, a powerful development paradigm inwhich a minimal system is made to run early on and functions are added to it over time untilthe whole system is ready.


4/11

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. (EachApplication 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 througha 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


5/11

System event generation File I/O Data Access

OLTP Database Design Parameters

Although database design consideration is a part of Application architecturesection, but considering its vastness and importance its worth mentioning itsparameters separately. This section will list only the database specific designconsiderations which are not covered by the Application Architecturalparameter 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 desireddata 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 viceversa)

No cascaded deletes and updates Usage of domain values where field values are fixed.


6/11

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 toenhance 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 ClientFramework

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 Block9 Menu, Action and Input Item level security

10 HTML based Client (only for thin client)

11 XML based Client (only for thin client)

Presentation ValidationLibraries

12 Generic Validations(Null, Size)

13 Numeric Format

14 String Format

15 Date Format

16 Support for JS Libraries and CSS classes

Generic UsabilityFeatures

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


7/11


8/11

49 Delegate the authentication to SSO server

50Facility to manage roles and role groups to be allocated to theusers

Structure to maintain hierarchy based user-level access control for

51 Screen

52 Operation

53 Data

54 Field

55

Encryption/Decryption of selective columns in the database. Theencryption key to be secret, not available to anybody butapplication 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

63

support for error types asinformationwarningerrorfatal

64 Ability to Log error

65Framework for showing the error in consistent manner irrespectiveof 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


9/11

75

Tracing a session for following levelsno-loginformationdebugwarningerror

fatal error

76

Configurable output medium asSNMP,socket,file,database etc.

Batch Framework

Facility to define, parameterize and schedule batch processes

77 Restart-ability

78 Transaction management

79 Commit Frequency control

80 Security81 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

94

Various Design patterns likea) Faade patternb) Factory patternc) Singleton patternd) Command patterne) Observer pattern


10/11

CompilationAfter collating the business requirements and deriving the relevantarchitecture facets applicable for the candidate system architecture, objectiveshould be to deduce the compliance of the candidate architecture vis--vis

business needs. To achieve this, assign the appropriate Weightage andapplicable rating to the architectural facets.Sample table is mentioned belowArchitectural facets Weightage2 (Scale 1-5) Rating3 (Scale 0-5)Facet 1 5 5Facet 2 4 3Facet n 5 0

On the basis of above information, generate a compliance graph depictingpercentage 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 takinghigher decisions. Sample graph is shown below:

Java Framework Requirement Compatiability

59%

11%

30%AS IS

Partially

Not Exist

Architecture Tradeoff AnalysisViolation of architectural principles is not always against the applicationsbenefit. There may be scenarios where one less significant architectural facetis consciously violated to achieve another high architectural facet or to support

2

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

3 Rating indicates how successfully candidate architecture fulfills the business needs. Theremay be a case, when the Weightage of a facet is high but the rating is low, this means thatbusiness direly needs that particular capability of the architecture but the candidatearchitecture is not capable enough to fulfill the same. Similarly, there may be a case whenWeightage is low and rating is high, which simply means that business may live without thatcapability of architecture but the candidate architecture successfully provides the associatedfacet.


11/11

a typical business scenario efficiently or where an architectural facet isknowingly ignored because of commercial and entrepreneur decisions. It isworthwhile to investigate the trade off behind the scenarios and re-rate thefacet accordingly.

ConclusionEvaluation of architecture should be purely based on architectural needs of thecurrent and envisaged business requirements. It should not emphasize thefancy capabilities of candidate architecture, which may not be of any use inenvisaged system. Same holds true for those application as well which are tobe built from scratch.

DisclaimerThis paper is currently in evolving state, hence may not be covering all theaspects of the architecture. Architects are recommended to think beyond theboundary of this paper while evaluating architecture. Readers are requested to

mail author, if any significant facet is suppose to be added in this paper.

Documents

Autopsy of Architecture