EA Principles Sample

Download as pdf or txt
Download as pdf or txt
You are on page 1of 18
At a glance
Powered by AI
The document discusses 21 principles of enterprise architecture that are relevant for IT departments in the financial sector.

 
© Copyright IBM Corporation 2012Trademarks21 principles of enterprise architecture for the financial sectorPage 1 of 18
21 principles of enterprise architecture for the financialsector
Thiago Souza Mendes GuimarãesNovember 20, 2012The article lists the most relevant architectural principles for an IT department to follow in thefinancial market, with details about each principle. These principles are essential for an ITdepartment to take on a strategic role in the company and to indicate actual value generation inIT decisions within an environment where pressure and business decisions are critical.
Structure of these principles
This article was developed with the purpose of proposing certain principles that must drive anenterprise architecture initiative. The main motivation that led to the development of this list isthe difficulty of implementing enterprise architecture in an environment as hostile as the financialmarket. There is great pressure on the technology segment, which is usually not perceived asstrategic. An even greater challenge is showing that IT decisions can add value and differentials tobusinesses.This list was organized and developed based on the selection and adjustment of the most relevantprinciples established throughout my experience in the financial market. Despite being selected within the financial segment context, most of these principles apply to any type of industry afteronly a few minor adjustments.
Definitions
Principles are high-level definitions of fundamental values that guide the IT decision-makingprocess, serving as a base for the IT architecture, development policies, and standards.The principles of architecture define general rules and guidelines to use and implement allinformation technology (IT) resources and assets throughout a company. They must reflect a levelof consensus between several corporate components and areas, constituting the basis for futureIT decisions.Each architecture principle must focus mainly on business goals and key architecture applications.
Format of each principle
Each principle must be formally stated. Some suggestions regarding the format in which principlesmust be stated are available in related literature. This article follows the format suggested by The
 
developerWorks®ibm.com/developerWorks/
21 principles of enterprise architecture for the financial sectorPage 2 of 18
Open Group Architecture Framework (TOGAF), in which each principle is presented according tothe following format:
Name
The name must represent the essence of the rule and be easy to remember. Specifictechnology platforms must not be mentioned in a principle's name or description. 
Description
The description must succinctly and directly convey the fundamental rule. Most informationmanagement principle descriptions are similar among different companies. 
Rationale
This must highlight business benefits generated by adhering to the principle, using businessterminology. It must emphasize the similarity between information and technology principlesand those that regulate business operations. The rationale must also describe its relationshipto other principles and intentions compared to a balanced interpretation. It should describesituations in which a certain principle would outweigh another in the decision-making process. 
Implications
This item must highlight requirements, both for businesses and IT, to comply with theprinciple regarding resources, costs, and activities or tasks. The impacts in businesses andconsequences of adopting a principle must be detailed. Readers must be able to easilyanswer the following question: "How does this affect me?" It is important not to simplify,trivialize, or question the merit of such impacts. Some implications are exclusively identifiedas potential impacts, with a speculative characteristic as opposed to being fully analyzed. 
Four categories of principles
Usually, there are around 20 enterprise architecture principles that must be followed. A very shortlist contains more generic and ethereal principles, hindering practical applications. On the otherhand, an excessively extensive list is too specific and generates inconsistencies and conflictsbetween principles and changes resulting from technological, environmental, and contextualevolution. The following list has 21 principles, organized in four categories.• General principles• Information principles• Application principlesTechnology principles
General principles
Principle 1. IT and business alignment
Description
Information management decisions are always made under the business alignment perspective inorder to generate maximum benefits for the company as a whole.
5
 
ibm.com/developerWorks/developerWorks®21 principles of enterprise architecture for the financial sectorPage 3 of 18
Rationale
This principle means "service above all." A better alignment between IT and the business mustgenerate a competitive edge for the financial institution.Decisions based on the corporate perspective have greater long-term value than decisions basedon a certain perspective of a group with a specific interest. An optimal ROI requires informationmanagement decisions to be aligned with the company's priorities and positioning. No single areamust affect the benefit of the company. This principle, however, must not prevent anyone fromperforming tasks and activities.
Implications
Aligning IT with the business and promoting optimal corporate benefits requires changes in howinformation is planned and managed. Technology alone is not enough to promote such changes.IT must direct its processes towards the front office.IT cost management must focus on IT services directed toward establishing a competitive edge.IT management must add responsiveness and availability indicators.IT architecture must implement a complete IT vision that is focused on business.Some areas might need to waive their specific preferences to benefit the company as a whole.Application development priorities must be established by and for the entire company.Application components must be shared among all areas of the financial institution.Information management initiatives must be conducted based on a corporate plan. Individual areasmust follow information management initiatives in accordance with corporate plans and priorities.Planning is modified whenever necessary.As new needs arise, priorities must be adjusted proportionally. A corporate representationcommittee must make such decisions.
Principle 2. Maximum benefits at the lowest costs and risks
Description
Strategic decisions for solutions must always strive to maximize benefits generated for thebusiness at the lowest long-term risks and costs.
Rationale
5
 
developerWorks®ibm.com/developerWorks/
21 principles of enterprise architecture for the financial sectorPage 4 of 18
Decisions must not be made based solely on reaching lower solution costs. Every strategicdecision must be assessed based on cost, risk, and benefit perspectives. Lower costs oftenrepresent greater risks and, perhaps, fewer benefits.
Implications
A solution must be selected based on a qualitative or quantitative cost, risk, and benefitassessmentMost times, quantitative assessments are simpler based on cost perspective but more complex forrisks and even more intricate for benefits. The quantitative assessment must always be conducted whenever possible and sufficient.A qualitative assessment of one or two perspectives is sufficient when a quantitative assessmentof other perspectives (for example, cost) is properly conducted and already leads to a decision.Operating risks must be quantified whenever possible.IT infrastructure must also be optimized based on business requirements and technologicalcapacity to generate lower costs and risks, thus benefiting the focus of the company.
Principle 3. Business continuity
Description
Corporate activities must be maintained, despite system interruptions.
Rationale
As system operations become more inherent, we become more dependent of them. Therefore, wemust consider the reliability of such systems throughout their entire conception and application.Business areas throughout the entire company must be able to continue conducting their normalactivities, regardless of external events. Hardware failures, natural disasters, and lack of dataintegrity must not interrupt business activities. Business activities must be able to employalternative mechanisms to convey information.
Implications
Dependence on shared applications implies that business interruption risks must be expectedand managed in advance. Management includes, but is not limited to, periodic revisions,vulnerability and exposure tests, or designing mission-critical services to ensure continuity throughredundancies or alternative resources.Recoverability, redundancy, and maintenance must be approached at inception.Applications must be assessed regarding criticality and impact on the company's mission todetermine which continuity level is required and which corresponding recovery plan must beimplemented.
5
5
5
5
5
5
5
5
5
5
5
5
5
5
5

Reward Your Curiosity

Everything you want to read.
Anytime. Anywhere. Any device.
No Commitment. Cancel anytime.
576648e32a3d8b82ca71961b7a986505