1. 1 Architectural Principles A Tool to Reach the Goal Architecture Åsa Lindström Ph D Student Royal Institute of Technology, Sweden asa@ics.kth.seasa@ics.kth.se, www.ics.kth.se, 070-7702480www.ics.kth.se

2. 2 Why?

3. 3 The value chain of architectural principles… BUSINESS STRATEGY IT STRATEGY ARCHITECTURAL PRINCIPLES

4. 4 What is an architectural principle? 1.Maximize benefit to the enterprise. Information management decisions are made to provide maximum benefit to the enterprise as a whole. 2.Common use applications. Development of applications used across the enterprise is preferred over the development of similar or duplicative applications which are only provided to a particular organization. 3.Data is shared. Users have access to the data necessary to perform their duties; therefore, data is shared across enterprise functions and organizations 4.Control Technical Diversity. Technological diversity is controlled to minimize the non-trivial cost of maintaining expertise in and connectivity between multiple processing environments Exemples from TOGAF

5. 5 The Federal Enterprise Architecture Framework Standards. Establish federal interoperability standards Investments. Coordinate technology investments with the federal business and architecture Data collection. Minimize the data collection burden Security. Secure federal information against unauthorized access Functionality. Take advantage of standardization based on common functions and customers Information access. Provide access to information Proven technologies. Select and implement proven market technologies Privacy. Comply with the Privacy Act of 1974

6. 6 Content…?

7. 7 Architectural principles at Company A Was developed in 2000 35 principles Used as a basis for their technology framework

8. 8

9. 9

10. 10 PART OF THE PRINCIPLE DEFINITION StatementWhat to improve MotivationWhy this is important for the enterprise ImplicationWhat must be done and when, and who is responsible MeasuresHow the fulfilment of the principles is measured. Both for the Enterprise Architecture long-term and short- term, e.g. after an investment. Comment

11. 11 Rules for principles SYNTAX “Have we got the principle description right?” SEMANTIC “Have we got the right principles?” PRAGMATIC “Do the reader interprets the principles right?” Consistent Stable Verifiable Unambiguous Modifiable Correct Complete Robust Std 830-1998, Software Requirement Specification, 1998, www.ieee.org

12. 12 More rules for principles Few in numbers, approximately 10-20, so that people can remember them One document, so that it is easy to survey all principles and impossible to loose a set of principles Of equal importance, so that all will be employed One statement for each principle, to make it understandable Not redundant, to make it understandable Consistent, so that no misunderstandings occur on what should be applied Recommends actions to be taken, so that they are clear on what should be done. Measurable, so that the adherence to the principles can be followed.

13. 13 States a fundamental belief of the enterprise in one or two clearly written sentences Recommends an action against which some arguments could be made Has relevance to a technical architecture Is worded directly and in simply terms understandable by both business and IT managers Has business wide applicability Is durable; will not be outdated quickly by advancing technology Has objective reasons for advancing IT instead of the alternatives which were considered Has impacts which needs to be documented A principle is not a statement that no one would dispute A principle is not a general business or financial statement A principle does not select a specific standard or technology A principle is not stated on such low level of detail so that it might not endure A principle is not included “because I say so”

14. 14 SYNTAXSEMANTIC ConsistentGood. No inconsistencies were found. StableGood. Two potentially non- stable principles were found VerifiableImprovable. Most principles were measurable, but some principles are hard to verify. VerifiableImprovable. It is hard to verify that the enterprise architecture has been improved. Unam- biguous Improvable. Some principles with multiple focuses have been identified. Correct & Complete Improvable. Some minor differences were found. ModifiableImprovable. Multiple documents are used and too many principles ModifiableImprovable. Many redundant principles have been identified.

15. 15 More information www.ics.kth.se -> Publikationer ->Working papers or http://www.ics.kth.se/Publikationer/Workin g%20Papers/publikationer_working%20pa pers.htmwww.ics.kth.se http://www.ics.kth.se/Publikationer/Workin g%20Papers/publikationer_working%20pa pers.htm The Open Group Architecture Framework http://www.opengroup.org/architecture/to gaf/ http://www.opengroup.org/architecture/to gaf/ Federal Enterprise Architecture Framework http://www.cio.gov/archive/bpeaguide.pdf http://www.cio.gov/archive/bpeaguide.pdf

16. 16

17. 17 Architectural Principles A Tool to Reach the Goal Architecture

18. 18

19. 19 Deployment The IT architect 150 measures and 3 hours/application and platform Coordinate technology investments with the enterprise and its architecture. The total business need/value is the primary objective when making information management decisions. The architecture should be optimized for modifiability. The architecture should be optimized for interoperability. Applications must be easy to use, satisfy end users need and provide benefit to both the organization and the end users. Data must be trustworthy and shall be of high quality. Users must have access to the applications and infrastructure necessary to perform their duties. Technical diversity must be controlled and Proven technologies are preferred over less tested technologies. Data is protected from unauthorized use and disclosure. Minimize the use of redundant applications and infrastructure in the enterprise.

20. 20 Deployment Application Portfolio Management 50 measures and 5 hours/application Applications shall correspond to their need of availability. Unavailable applications can cause production stops and lost revenue, which thereby affect the business in a negative way. How well does the level of availability of the application correspond to the Service Level Agreement according to Table 7 above? (This question should be directed to persons on IT- coordination level) 0 None of the availability measures corresponds to the agreement 2 There are times when the agreement is not fulfilled, but the availability agreement is met most of the time. 4 The availability measures for the application all correspond to the agreement. Does the provided availability level result in any business complications? (This question should be directed to persons on IT- coordination or business level) The provided level of availability results in business complications: 0 Once or a couple of times per week. 2 Once or a couple of times per month. 4 Once or a couple of times per year.

21. 21 Vad sa de som var med? Bra översikt över ”sin” applikation Ger tips på hur man kan arbeta med förvaltningen av ”sin” applikation Bra översikt över flera applikationer Gör varje år! Gör före och efter större förändringar Bra att låta process- och IT-ansvarig svara på frågorna gemensamt