Principles as enterprise architecture outcome

[Former Member]

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