Principles as enterprise architecture outcome

Friday, April 17, 2009

Enterprise Architecture General Software Development

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	Just existing entities should be used	Entities creating one common language across the enterprise, applications and stakeholders.	any Interface should be implemented using entities. Any applications should implement existing entities.	Data
Using version control for all components	Each component should implement version control. the version control if for business process and business rules must have effective date.	for ease of management and track of changes.	Should be checked as part of SDLC.	Application
expanded by 20% from the initial data requirement.	expanded by 20% from the initial data requirement.	Support Expandability in minimum cost	Need to be checked as part of SDLC	Application

1 Comment