Skip to Content

Principles as enterprise architecture outcome

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.







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.


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


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



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 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.


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.


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.



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.


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




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


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.


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.


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.


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


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.


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)


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.



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.



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.


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


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.


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


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.


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


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.


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)


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.


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


Use existing technologies

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

Minimize portfolio.

To be checked as part of SDLC.


Use just existing entities

Be the first to leave a comment
You must be Logged on to comment or reply to a post.