MIS8043 IT SYSTEM ARCHITECTURE Session 2 – January 31 th , 2004

1. MIS8043 IT SYSTEM ARCHITECTURESession 2 – January 31th, 2004 Annette Lerine Steenkamp, PhD Suite M308  248.204.6069  248.204.6099 steenkamp@ltu.edu

2. S2- I. ARCHITECTURES AND FRAMEWORKS • Lecture • Models • Architectural models • Architectural frameworks • DMIT Blackboard site • IA1 Requirements

3. MODELS • In general a model is an abstraction (logical or physical) of a system • Constructed based on stated objectives, assumptions and constraints • Created to test the viability of the system to be constructed • Created as part of the construction life cycle • Manages complexity • Makes an intended system visible • Tests assumptions • Tests usage scenarios

4. MODELS In the context of IT systems the models represent a formal set of relationships that provide • context • structure • behavior of conceptual and physical entities in the system and its environment

5. ROLES OF MODELS • Communicate with client, users, builders, vendors • Models assist in decision-making processes of role players • The maintenance pf system integrity through coordination of design activities • Assisting design by means of templates, frameworks, and organizing and recording decisions • Exploration and manipulation of solution parameters and characteristics • Guiding and documenting generalization, aggregation and decomposition of systems, system functions, components and objects • Performance prediction, identification of critical system elements • Providing acceptance criteria for certification of use

6. ROLES OF MODELS The architect’s role is to communicate primarily using models • Architecting activities mainly before the physical design in SDLC; must interpret client/user requirements for builder team • Alignment of client objectives and builder technical feasibility of system is achieved using appropriate models, modeling languages • Modeling notation must be suited to intended purpose • Models must be documented – they represent decisions/ designs/architectures • Models are also classified by view Note: Roles are interdependent

7. CLASSIFICATION OF MODELS BY VIEW • IEEE 1471 A view is the expression of a system’s architecture with respect to a particular viewpoint; a view consists of one or more architectural models A viewpoint establishes the conventions by which a view is created, depicted and analyzed • Rechtin A view or perspective describes a system with respect to some set of attributes or concerns The set of views should be complete and consistent Views are mostly orthogonal (capture different aspects of information)

8. MAJOR SYSTEM OR ARCHITECTURAL VIEWS

9. Views and their models

10. Behavioral view1. Mathematical Systems Theory - the behavioral theory of multi-dimensional feedback systems Formalisms for modeling are: • Based on theory for continuous systems ( in terms of time and data, values are continuous) – has a sound theoretical basis; linear, non-linear differential equations • Based on theory for temporally discrete systems (i.t.o. continuously valued elements measured at discrete time points – has a sound theoretical basis; differential equations. This theory forms the basis of most computer simulations • Based on discrete event systems approach (some or all the quantities have discrete values at arbitrary points in time - state machines, Petri nets E.g. Queuing networks where data packets move around the network in discrete units

11. Behavioral view 2. Autonomous Agent, Chaotic Systems • These systems characterized by multiple-replicated, individually relatively simple components that interact to create new behaviors E.g. behavior of ant colonies determinable by behavior and interaction of individual ants 3. Public choice and behavior models • Depends on behavior of human society E.g. Models based on consumer surveys Network performance models where behavior is determined by individual behaviors/ decisions

12. Views and their models

13. Views and their models

15. ARCHITECTURAL VIEWS P& B: Architectural views are different slices through an architecture, where each view type embodies a different perspective of the architecture; purpose is to develop a complete architecture of system TOGAF: Views are perspectives of an architecture representing slices through the architecture of specific aspect of the computational requirements served by the architecture

16. TOGAF ARCHITECTURAL VIEWS

17. P&B ARCHITECTURAL VIEWS

18. IEEE Viewpoints

19. Other viewpoints • Project • Platform Service/ performance • Quality

20. S2 - II. Architectural Templates Refer IBM’s ADS ( Architectural Description Standard) by Youngs et al, IBM Systems Journal, Vol.38, No.1, 1999 Defined as a set of structural and behavioral patterns that describe some part of the architecture of an IT system E.g. Workflow, transactionality, user interface, network communications Web architecture template and protocol, Workflow Reference Model FSO-OSI 7 layer model for network communication

21. Reference Models • A technical reference model provides a visual representation of all the technical functions and services of the “foundation” IT environment for a domain • It provides a “frame of reference” of the usage domain e.g. 1. The RM-ODP(Reference Model of Open Distributed Processing – ISO 10746) provides a formal way to specify problems to be solved and techniques to be used for the analysis of SW systems, independent of methodology, language or vendor 2. Refer to the TOGAF Technical Reference Model in P&B Fig. 4.4

22. Architectural Frameworks • A conceptual framework that provides the organizational context within which relevant views of technical architectures can be represented • Usually interpreted as a generic template that provides the context of the domain for which it is intended. • Sometimes a framework is also considered as a standard, with specific features: • Standard data format • Security • Protocol • Functionality Contextual aspects include: • Organization and role players • Standards • Viewpoints (perspectives) and models • Inventory of views • Principles

23. Examples of Frameworks • B2B Frameworks – refer article by Shim et al, Computer, Oct 2000 • The TOGAF Framework – refer P&B, Chapter 4 and 5 This is an architectural framework providing a conceptual foundation for detailed architecture representation with features: • reasoned • cohesive • adaptable • vendor-independent • domain-neutral • Scalable • TOGAF has an associated architectural development method A process defined by TOGAF for the development and maintenance of an organization’s technical architecture

24. Architectural Frameworks Note that Arch. Frameworks vary in context, applicability and success: • When focusing on a SW system arch. the framework provides guidance by partitioning the design into abstract classes, and defining their responsibilities and collaborations; the developer customizes the framework to a particular application via sub-classes and instances • When focusing on an enterprise IT arch. The framework provides guidance for structuring the IT assets while keeping into consideration all relevant organizational aspects, principles, viewpoints, role players, standards, model notations • Governance of architectures is an emerging topic in organizations

25. Architectural Governance Defined as • The processes of adopting an arch. framework, reference model and set of standards • The processes of populating the framework in alignment with the enterprise strategic direction • Includes the policies, processes for implementing and maintaining the architecture within the enterprise • Management processes of monitoring, planning and organization, acquisition and implementation, delivery and support of IT • Also includes the ongoing quality management of the technical environment Refer slides on Architecture governance and P&B Chapters 13 & 14

26. Factors influencing Enterprise IT Archs. • Technology environment – refers to the HW, system SW, utilities, and infrastructure deployed and used within the organization: • How up-to-date • How integrated with the business processes • How well managed • IT organizational structure: Horizontal and Vertical structures What are the different structures in your orgs.? The problems with them? How deal with Development, Support, Operations ? Architectural governance ? Vertical application management ?

27. Factors Influencing Enterprise IT Archs. • Capability: the level at which IT is governed within the organization; • SW & HW acquisition • Deployment & Maintenance • Human Resource capability • Industry: the sector and degree to which processes are enabled by IT • Conservative (risk adverse) industries often lag behind more progressive entrepeneurial companies • Companies have different value propositions • Management philosophy – refers to the approach, style, capabilities and values of the executive decision-makers • IT must be aligned to management philosophy

28. The Problem Matrix • Business/Technical Strategy Gulf – lack of alignment of IT Planning and IT architecture to business strategy • Needed: an approach that traces Organizational goals and measures Business Process goals and measures Business Process goals  Operational activity goals and measures Note: IT strategic planning must be synchronized with IT strategic planning

29. The Problem Matrix 2. Information Inaccuracy – information is incorrect, inconsistent and incomplete • Lack of integration between systems, duplication • Technical differences in system architecture in “corners” of the organization • Distribution of function and data complicates overall integration Needed: An information architecture and business systems architecture to identify: • Function and information overlap • Areas within the technical arch. that restrict effective integration

30. The Problem Matrix 3. Infrastructure limbo – the IT infrastructure is based on tactical decisions and plans without considering overall enterprise arch. Needed: planning, implementation and governance of a technical arch. Based on an architectural framework that provides the infrastructure to serve the enterprise

31. The Problem Matrix 4. The Security Problem – IT environment is not secure Needed: • High capability of Security Service Area across all applications • Besides traditional security strategy for mainframe environment also include security for distributed systems, intelligent workstations, network infrastructure • Security policies built into architecture Refer ISO17799 International Standards for Information Security Management

32. The Problem Matrix 5. Incompatible Technologies – business processes are supported by IT enabling techs. That are not interoperable. This results in workarounds to overcome incompatibilities, inefficient operations, additional costs Needed: a planned IT architecture that has as key objective to be effective and supporting of interoperability E.g. Document sharing, effective information transfer, communication, integrated applications

33. The Problem Matrix 6. Cost – investment in IT in the organization is high, not effectively controlled, not cost-effective Needed: IT must be planned with awareness and consideration of pending tech. development and trends • Important that org. is able to quantify cost of IT ownership • Use appropriate value propositions such as improved productivity, product quality, customer service The architectural approach requires an understanding of the business, its market sector, and its attitude towards IT i.t.o. the organization type when prescribing ITs for the organization

34. The Problem Matrix 7. Technology anarchy – the technology vision for the organization is determined by individuals and not the whole org. • There is no defined or standardized IT architectural process nor governance of them • Several ad hoc tactical decisions are made • Organization is vulnerable when technical staff leave Needed: a defined architectural process for organization

35. The Problem Matrix • IT systems are not managed well – the distribution of IT applications and services across the organization are designed, developed and deployed without sufficient consideration of how they will be managed, i.e. the non-functional quality characteristics Needed: Consideration of key non-functional aspects: • Availability of IT systems and services (serviceability, performance, reliability) • Assurance (security, integrity, credibility, extensibility, portability)

36. The Problem Matrix 9. No defined, standardized procurement process: refer ISO 12207 Primary Life Cycle Processes Needed: • Procurement of technology must be aligned with technical strategy and planning • When following an architectural approach artifacts and processes guide and link into the procurement process

37. The Problem Matrix 10. Collapsing event horizon – organizations are experiencing a reduction in time needed to deliver new E-business related products and services; orgs. Resort to tactical technology decisions to deal with demand Examples are inappropriate Its to support: On-line selling Supply chain integration Information delivery Electronic lending Business process enhancements • Can lead to over-investment in e-business infrastructure and business failure • Must have sound E-Business strategy: the E-style of doing business demands that systems in support of business processes must be developed faster, be cheaper and better, interoperable, easy to use, …. • New expectations is counter to SE approach to software development

38. Need for Sound Architectural Approach • Architectural planning • Architectural Design and Implementation • Architectural Management – monitoring, control, feedback mechanism • IT projects must be initiated based on a project process that is derived from an standard organizational process • Minimize divergence form Organizational and IT strategies • IT maturity and capability must be improved • There must be IT architectural governance and control

39. S2 - III. Foundation for Technical Architectures • The Architectural Approach • Architecture Process Model • Phased structure with corrective feedback mechanism, iterations – there will be some overlapping • Intent is to drive architectural decisions from business strategy through the IT strategy • Aim to support alignment of IT arch. with business strategy, processes

40. Architecture Process Model

41. Business Strategy Process Must answer questions such as • Why does organization exist? – Mission Statement (1A in Performance Matrix (P.M.)) • What is ideal future for organization? – Vision statement (1A in P.M.) • What principles should decisions and actions be based? – Guiding principles (1B) • What steps should we take to achieve the org. vision? – Business Strategy Plan, the goals, objectives, CSFs (1B) • What are our milestones? – short term, longer term goals i.t.o. deliverables/ capabilities, the direction (1B, 1C)

42. Business Strategy Process • How will we achieve the milestones? – Which projects must be launched in order of priority and i.t.o. CSFs, the strategy (1C) • How will progress be measures i.t.o. strategy and projects? – prepare measures, compare with milestones, goals (1A, 1B, 1C) • What operational processes will keep the organization on track? – perform process analysis at process level of P.F., determine governance processes, compare with organizational level design (1B, 2A, 2B) Note that CSFs are the key goals and objectives of the org. that must be achieved for success

43. Performance matrixRefer Harmon, Rummler-Brache

44. Business Strategy Questions mapped to P.M. Organizational Level • Goals and Measures (1A) – Questions 1, 2, 7 • Design and Implementation (1B) – Qs 3, 4, 5, 8 • Management (1C) – Qs 5, 6, 7

45. Business Strategy Questions mapped to P.M. Process Level Goals and Measures (2A) – Question 8 Design and Implementation (2B) – Q. 8 Management (2C) – not applicable Activity Level Goals and Measures (3A) – not applicable Design and Implementation (3B) – not applicable Management (3C) – Not applicable

46. Business Strategic Planning Strategic Planning Process – Refer P&B Fig 3.1, p45 from Finkelstein Steps are: • Identify currentstrategy 1.1 Determine principles that guide strategy 1.2 Perform External Appraisal 1.3 Perform Internal Appraisal 1.4 Perform SWOT Analysis • Perform Strategic Gap Analysis • Consider strategic alternatives • Select best alternative • Formulate strategy i.t.o. goals, obejctives, CSFs, direction

47. Competitive Strategy Refer Boar Chapter 1 Harmon Fig 2.2 Porter’s Model for Competitive Strategy Fig 4.4 High Level Org. Diagram Five forces of competition: • Industry competitors • Buyers • Suppliers • Substitutes • Potential entrants

48. IT Strategic Planning Process Refers to organization’s strategic plan for IT and the IT group that will guide the direction over a medium to long term period • There is a collapsing event horizon – shortens the strategic time frame • Plan must be based on business goals, objectives, CSFs, constraints, structure, value chains, as expressed in Business Strategic Plan

49. IT Strategy Planning Process • Must determine opportunities to exploit IT for added value (value chains) within context of Business Strategic Plan • Steps are: • Formulate goals and measures for IT enabling processes (2A in P.M.)) Refer Boar, Fig 1.10 IT as a basis for advantage • Elaborate value chains of core business processes within context of the Porter Model(2B in P.M.) Refer Harmon Fig 4.3 High-level Organization Chart (the IT enabling processes may be identified in the supporting process diagrams of the core business processes • Focus on management of IT resources (HW,SW, infrastructure, information, people, processes) (2C in P.M.) In the P.M. this is at the process level for IT enabling processes in synchronization with 1C

50. IT Strategy Planning Process • Focus on managing technical policies and architecture based on sound architecting principles, synchronized with the guiding principles of the organization (elements 2A, 2B and 2C at the process level of the P.M. for IT enabling processes); perform processes/tasks/activities that are relevant using appropriate models and techniques • Manage business and IT processes through strategic governance (2C of P.M.) • I will post notes about strategic governance based on the COBIT Framework – this is summarized in P&B Chapter 14