Skip to Content

Principles are the  better half of blueprints.  Principles enable enterprise architects to set up the boundaries that  application / solution architects should follow to create their own architecture  / solution, in order to build better enterprise architecture.  Principles are actually set of rules which  set the boundaries that needed to be respect and implement by all relevant roles  in the enterprise. Together with blueprints principles enable enterprise  architects to shape future architecture of a given enterprise.

 

Due to the fact  that principles shape the enterprise we expect to see principles for each one of  the four  enterprise domains (Business,  Information, Applications and Technology). In order  to make principles more understandable and  easy to follow we tend to write for each principle its name, a short statement,  the rational behind it and any implications if the principles.

 

As with blueprints  we (as enterprise architects) expect solution and system architects not just to  follow the principles but also to embedded them in their solution in a way that  we can use it while going through   different reviews as part of the solution / system development life  cycle. The most common why that I tend to use is to relate any architecture  building block to the principles which was follow or implement.

 

To make it more  easy to understand and practical you can find below a list of common principles  taken from different work that I’ve done.

 

 

Name

Statement

Rationale

Implications

Type of Principle

All access to DB should be done using dedicated service  layer

All access to DB should be done using dedicated service layer. no  direct or custom data access.

Standard, reuse and management

Need to be checked as part of SDLC.

Application

All reporting should be done using BO  solutions.

All reporting should be done using BO solutions. no room for custom  solutions for reporting.

Reporting standard.

Validate this principle as part of  SDLC

Application

All reports should be kept in original form for  audit.

any statements sent to market participant should be kept as they were  sent to the market participant

To be compliant with market rules.

Should be check as part of SDLC

Business

 

Application must pass Application Security Readiness  Review

Any new application must successfully pass a Application Security  Readiness Review

Maintain application security and to be compliance with Singapore  government regulations

A SRR test should be done to each and every new  application

Application

 

Application should be schema  neutral

Application should be schema neutral. application should work against  any schema defined in external setting file.

Be able to run applications in different environments == supports  agility.

Applications need to be build in such a way that they can run against  any schema.

Application

Be able to measure business  processes

Any business prices should be  measured

Measuring business processes enable to identify flaws and improve the  process

each and every application that implement business process should  measure time for each step in the process.

Business

Build loosely coupled solutions

Build solutions that enable application/components replacements  without application rewiring.

Reach agility and flexibility of XXX to enter new business  opportunities

 

Need to be checked for relevant design patterns in the  SDLC.

Application

 

Changes to sensitive data should be  audit

all changes to sensitive data (such as financial and HR data) should  be Audit.

To be able to track changes made by humans to sensitive  data.

Implementation of Audit in each  application.

Data

DOCUMENTATION must be integral part of  application

Documentation will be required that covers the following areas:
*  Technical specification
* Operations
* User  instruction

Enable application maintain

Enable application maintain

Application

 

 

DB connection should be compatible for RAC  implementation

DB connection should be compatible for RAC  implementation

To enable solution supporting RAC implementation without code  changing

Need to be checked for relevant design patterns in the  SDLC

Application

Compliance to Oracle security standards and  guidelines

general security control requirement applicable to Oracle database  and server environment.

Increase IT platform stability

a. To prevent critical processes or resources from being unable to  startup or encountered unexpected problem due to security hardening, the  standards and guidelines described in this documentation should always be  implemented in the development environment, fully tested, before propagating to  the production environment.

Application

Data exchange across process boundaries and portlets will be based on  entities

Data exchange across process boundaries and portlets will be based on  entities. just entities, not custom data to be transfer across services,  portlets.

Create one standard language to communicate between  apps.

Should be checked as part of SDLC.

Application

Data should be accessible to each role that needs  it

data access should me maximized to increase data sharing across the  enterprise. the idea is to reduce compartmentalization to a  minimum.

Increase data share across the  enterprise.

Minimize data hiding.

Data

Design common code for reuse

Any code that is common or consider to be common will be develop and  deploy in such a way that enable reuse

Maximize reuse.

Need to be validate as part of SDLC

Application

Design for IE 6.0+

The Market Rules do not specify inter-operability requirements that  relate to Task 2. The implementation of these rules from a system perspective  requires the use of ‘industry standard IT practice’ tailored to the  needs

Support new markets and  opportunities

Need to set standard and impose it as part of SDLC and as part of  RFP.

Application

Design for disaster recovery

The solutions to disaster recovery are not usually the same as those  for ensuring high availability. Whatever the criticality of a system and the  replicating of all component parts to ensure maximum availability on component  failure, the considerations of a complete site failure are not usually catered  for.
Disaster recovery has to cover a lot more than just the system  components, eg personnel and location. The main consideration is the ability to  provide the same functionality at a different site with alternative  communications, with as close a replication of the system data as possible to  the point in time of failure.

Enable market trading after system  lost

Part of SDLC reviews (Architecture)

Technology

Design for performance

The performance requirements should be defined for each time critical  sub-system

Improve trading product performance

Should be define for each system and checked as part of  SDLC.

Application

EASE OF USE

The term ‘ease of use’ is a subjective measure. Ease of use can be  achieved by user system features such as existence of documentation, consistency  in human computer interaction, feedback for user actions, descriptive error  messages.

Users satisfaction from working with our  system

Set standard to Usability, Operability and Maintainability. enforce  those standards as part of SDLC. Include those standards as part of  RFP.

 

Application

Each Portlet that shows table should support export of data to  external formats

such as PDF, Excel, CSV, XML

Ease user experience with the system. enable the user to use data for  his own needs

Need to be checked as part of SDLC.

Application

Each component need to expose predefined services, but to implement  needed function

Each component need to expose predefined services, but to implement  needed function

standard way to consume services and reuse  components.

Need to be checked as part of SDLC

 

Hot Deployment

Application must support hot deployment to prevent system outage  while deployment.

Maximize availability

To be checked as part of SDLC

Technology

Information should be stored in  databases

all the information should be stored in databases and not in any  local machine or local storage (Excel).

To be able to share and use the data across the enterprise and to be  able to effectively backup all the needed data.

No local storage of data. if there is a need for local storage, the  data should be stored on DB as well.

Data

Java application must follow Java Coding  Standards

Java application must follow Java Coding  Standards

One standard coding across  applications

Part of SDLC review need to check this  principle

Application

New projects wont decrease current  performance

New projects wont decrease current performance. new projects will  improve or keep current performance.

Validate improvement of  performance.

Part of SDLC should check if performance effected from new  project.

Application

No logic in DB

All logic code that need to be written wont be done inside  DB.

Separation between layers to enable  agility.

Need to be checked as part of SDLC

Application

Solution must be able to fail over to another  cluster

Solution must be able to fail over to another  cluster

Maximize availability

Need to be checked as part of the  SDLC.

Technology

System availability to 99.98%

Availability is a statement of the time for which a system or service  is not operating as normal. The same availability may be the consequence of a  number of short-term failures or a single long one. It is a combination of the  failure rate (reliability) and the time required to restore the service (mean  time to repair).

The need to support market available for  trading.

Need to be checked as part of SDLC reviews (architecture and  code)

Application

Use Automate test

Any new application should come with automatic tests and scripts that  can be run at any time to check the system.

in order to improve our ability to embed new changes to existing  application we need automatic way to check existing scenarios to identify new  issues.

Any new application should come with automatic test tool and scripts  that support scenarios.

Application

Use existing services wherever you  can

Always use application platform services (Logging, Audit,  authentication) instead of writing your own

Maximize reuse and make maintenance more  easily.

Implement checking as part of SDLC

Application

Use existing technologies

Use existing technologies excluding .Net PL/SQL and Sonic  MQ

Minimize portfolio.

To be checked as part of SDLC.

Technology

Use just existing entities

 
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply