Erp 03
Upcoming SlideShare
Loading in...5
×
 

Erp 03

on

  • 505 views

 

Statistics

Views

Total Views
505
Views on SlideShare
504
Embed Views
1

Actions

Likes
1
Downloads
11
Comments
0

1 Embed 1

http://inure.nmu.org.ua 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Erp 03 Erp 03 Presentation Transcript

  • by Dr. Vsevolod S. Chernyshenko
  • TOGAF is an architecture framework that provides the methods and tools for assisting in the acceptance, production, use, and maintenance of an enterprise architecture. It is based on an iterative process model supported by best practices and a reusable set of existing architecture assets.
  •  The Business Architecture defines the business strategy, governance, organization, and key business processes.  The Application Architecture provides a blueprint for the individual applications to be deployed, their interactions and their relationships to the core business processes of the organization.
  •  The Data Architecture describes the structure of an organization’s logical and physical data assets and data management resources.  The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.
  • Preliminary Phase describes the preparation and initiation activities required to create an Architecture Capability including customization of TOGAF and definition of Architecture Principles. Preliminary
  • Architecture Vision describes the initial phase of an architecture development cycle. It includes information about defining the scope of the architecture development initiative, identifying the stakeholders, creating the Architecture Vision, and obtaining approval to proceed with the architecture development. Architecture Vision
  • Business Architecture describes the development of a Business Architecture to support the agreed Architecture Vision. Business Architecture
  • Information Systems Architectures describes the development of Information Systems Architectures to support the agreed Architecture Vision. Information Systems Architecture
  • Technology Architecture describes the development of the Technology Architecture to support the agreed Architecture Vision. Technology Architecture
  • Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases. Opportunities And Solutions
  • Migration Planning addresses how to move from the Baseline to the Target Architectures by finalizing a detailed Implementation and Migration Plan. Migration Planning
  • Implementation Governance provides an architectural oversight of the implementation. Implementation Governance
  • Architecture Change Management establishes procedures for managing change to the new architecture. Architecture Change Management
  • Requirements Management examines the process of managing architecture requirements throughout the ADM. Requirements Management
  • Deliverables  a contractually specified work product. Artifacts  a more granular architectural work product describing an architecture from a specific viewpoint. Building blocks  representing a (potentially reusable) component of business, IT, or architectural capability.  Architecture Building Blocks (ABBs) describe required capability.  Solution Building Blocks (SBBs) represent components that will be used to implement the required capability.
  • According to TOGAF, architecture principles define “the underlying general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise” (TOGAF http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html)
  • Principles governing the architecture process, affecting:  development  maintenance  use of enterprise architecture Principles governing the implementation of the architecture, establishing:  first tenets  related guidance for designing and developing information systems
  • Name: Should both represent the essence of the rule as well as be easy to remember. Statement: Should succinctly and unambiguously communicate the fundamental rule. „Rationale: Should highlight the business benefits of adhering to the principle, using business terminology. Implications: Should highlight the requirements, both for the business and IT, for carrying out the principle - in terms of resources, costs, and activities/tasks. Name Statement Rationale Implications Schema:
  •  Don’t mention specific technology platforms in the Name or Statement of a principle.  Avoid ambiguous words in the Name and in the Statement such as: "support", "open", "consider", and for lack of good measure the word "avoid", itself.  Be careful with "manage(ment)”.  Look for and avoid unnecessary adjectives and adverbs (fluff).
  •  Point to similarity of information and technology principles.  Point to principles governing business operations.  Describe relationship to other principles and the intentions regarding a balanced interpretation.  Describe situations where one principle would be given precedence or carry more weight than another for making a decision.
  • Name Interoperability Statement All the software in university (already existed and new developed) should conform the same standards either in technologies or interface. Rationale Keeping existed software standards let spend minimum time and costs for development. Hardware and data standards prevent reiterative appeals or applications for explaining usage or operations. In the general will improve satisfaction of users and clients. Implications Interoperability standards will be followed unless client (university) would like completely change an inner software or hardware environment. All the hardware should exist in minimum variety of kinds. Investigate data formats, as the transcribed data should arouse minimal amount of problems by opening in any kind of software environment.
  • by Dr. Vsevolod S. Chernyshenko
  • Propose at least six architecture principles, concerning example from the previous exercise. Reminder: Your organization requests you to conceptualize and implement a new social system oriented both on academicians and students, their parents for a National Ministry of Science and Education. End-consumer is your home university.
  • by Dr. Vsevolod S. Chernyshenko
  •  Defining "where, what, why, who, and how to do architecture"  Main aspects o Defining the enterprise o Identifying key drivers and elements o Defining the requirements for architecture work o Defining the architecture principles o Defining the framework to be used o Defining the relationships between management frameworks o Evaluating the enterprise architecture maturity
  •  Defining "where, what, why, who, and how to do architecture"  Main aspects o Defining the enterprise o Identifying key drivers and elements o Defining the requirements for architecture work o Defining the architecture principles o Defining the framework to be used o Defining the relationships between management frameworks o Evaluating the enterprise architecture maturity
  • Overview about the client’s organisation / enterprise  Identify stakeholders o Actors like university management bodies, department operators, university platform, student services  Identify scope and elements of the organization o Departments, faculties, etc. o Student domains o Educational, academic processes o Key information in the context o Responsibilities, Liabilities, Legal conditions, Cultures o Technical features
  •  Define a framework and detailed methodology o TOGAF and the Architecture Development Method  Confirm a support framework that will provide detailed notations and/or languages to develop models o ADONIS, Visio  Define architecture principles  Examples Interoperability Full electronic support Cross-organizational Management interactions Legal compliance Usability Convenience Simplification Harmonisation
  • Preliminary and also Architecture Vision phase are used to gather as much information about the enterprise and the enterprise’s domain  Research methods offer different ways to collect data from stakeholder o Desk research o Questionnaires o Interviews o Observation o Think-alouds o Workshop & participation techniques o Scenario technique o Mock-ups o Soft Systems Method Preliminary phase is used to prepare the usage of Enterprise Architecture
  •  Gather knowledge about: o TOGAF o Other frameworks if required o Board and Business strategy o Business goals o Business drivers o Budget for scoping project o Partnership for scoping project o IT strategy  Pre-existing organisation models, architecture frameworks and principles  Pre-existing architecture repository
  •  Organisational Model covering: o Scope of organisations impacted o Maturity assessment, gaps, and resolution approach o Roles and responsibilities for architecture team o Constraints on architecture work o Re-use/Budget requirements o Request for changes o Governance and support strategy
  •  Customised Architecture Framework containing o Tailored architecture method and content o Architecture principles o Chosen tools  Initial Architecture Repository  Information on business principles, goals and drivers  Request for architecture work
  •  Scope the Enterprise Organizations impacted  Define and establish Enterprise Architecture Team and Organization  Identify and establish Architecture Principles  Select and tailor Architecture Frameworks
  •  Identify units involved in Architecture Work: • core enterprise - those units most affected from the work o E.g. dean office • soft enterprise - those units who will see changes but are otherwise not directly affected o E.g. student government department • extended enterprise - those units outside the scoped enterprise affected in their own enterprise architecture  Identify enterprises involved in Architecture Work: • communities involved - those stakeholders affected and organized in groups • governance involved
  •  Determine existing enterprise and business capability  Identify gaps in existing work areas  Allocate key roles and responsibilities for enterprise architecture  Define requests for change to existing business programs and projects: o Inform existing enterprise architecture and IT architecture work of stakeholder requirements o Request assessment of impact on their plans and work o Identify common areas of interest o Identify any critical differences and conflicts of interest o Produce requests for change to stakeholder activities
  •  Scope new enterprise architecture work  Determine constraints on enterprise architecture work  Review and agree with sponsors and board  Assess budget requirements
  •  Identifying of Architecture Principles because:  Architecture principles • define o underlying general rules and o guidelines for the use and deployment of all IT resources • Are the background for making future IT decisions  form the basis for all decisions in Architecture Vision, Business Architecture, Information Systems and Technology Architecture Phase
  •  TOGAF provides an abstract framework that can be tailored or enhanced for every kind of enterprise  The Open Group pointed out three aspects to tailor: • Terminology o Architecture practitioners should use terminology that is generally understood • Process o Provides the opportunity to remove, add and change tasks of the ADM • Content o Allows adoption of third-party content frameworks o Allows customization of the framework to support organization-specific requirements
  • Modelling notations for different levels of abstraction and for specific aspects  Organisational modelling o Organisational diagram (MS Visio®) o Work environment diagram (ADONIS®)
  •  Represent the structure of an organisation, the distribution of work and hence the responsibilities  Useful for work assignments and for access rights o Understanding of business domains and organisational units involved o Workflow management systems o Coordinating the assignment and workload to personnel and the need for respective systems applications for their work o Access control at systems level
  •  In general they describe the overall structure of an organization and further on the human actors involved in a process  Approach: Organisational diagrams describing • The individual organisational units and the relationship among different such units o Including hierarchical relations such as Headquarter -> Business domain -> Department -> Group - > Position o Concept of decomposition • Smallest unit in organisational diagrams is position
  • by Dr. Vsevolod S. Chernyshenko
  • Propose a scheme of the Enterprise Architecture Team and University within the task presented in the previous exercise (during past lecture). Reminder: Your organization requests you to conceptualize and implement a new social system oriented both on academicians and students, their parents for a National Ministry of Science and Education. End-consumer is your home university.
  • by Dr. Vsevolod S. Chernyshenko
  •  Initial phase of the Architecture  Design Method Includes information about o defining the scope o identifying the stakeholders o creating the Architecture Vision o and obtaining approvals
  •  Ensure recognition, endorsement and support from the corporate management of the enterprise.  Define and organize an architecture development cycle.  Validate the business principles, business goals, etc.  Define the scope of, and identify and prioritize the components of the Baseline Architecture effort.
  •  Define the relevant stakeholders and their concerns and objectives.  Define the key business requirements and constraints.  Articulate an Architecture Vision and formalize the value proposition.  Create a comprehensive plan that addresses scheduling, resourcing, financing, communication, risks, constraints, assumptions, and dependencies.  Secure formal approval to proceed.
  •  Develop Architecture Vision (high level) • Confirm with administration on actual baseline and future target architecture o remember scenario introduction current state and target solution  Identify concerns and requirements • Using e.g. interviews to gather expectations and needs of potential users of the new eUniversity platform o e.g. no media breaks / full online documents circulation • Using interviews or mind mapping sessions to elaborate university goals, drivers and constraints o budgets etc.  Gain rector’s sign off to proceed!
  •  Output of Preliminary phase  Request of Architecture Work  Business Principles  Business Goals  Business drivers
  •  Approved Statement of Architecture Work  Agreed statements of Business Principles, Business Goals and Business drivers  Architecture Principles  Architecture Vision, including • Agreed key high-level stakeholder requirements • Baseline and high-level Target Business Architecture • Baseline and high-level Target Technology Architecture • Baseline and high-level Target Data Architecture • Baseline and high-level Target Application Architecture
  •  Identify stakeholders, concerns and business requirements  Confirm and elaborate business goals, business drivers and constraints  Define scope  Confirm and elaborate Architecture and Business Principles  Develop Architecture Vision
  •  Concerns and requirements as basis for formulating a target Architecture Vision  Concerns and requirements to be summarized and discussed with the contractor  Background about how architecture is presented and communicated needs to be defined
  •  Major product: stakeholder map showing • Stakeholders • How they are involved • Relevant views and viewpoints  Template for Stakeholder involvement “map” Stakeholder Involvement description Kind of involvement Relevant Viewpoints
  • Stakeholder Involvement description Kind of involvement Relevant Viewpoints University administrati on Supervise the process of advancement and transparency of the work of academics and they own, enhancement of IT architecture. Get other departments involved in the project. KEEP SATISFIED Rich/Goal/Objective/Ser vice Models, Information map Academic Staff Express their demands, test a system (as it’s ready). KEEP SATISFIED / KEEP INFORMED / INVOLVE in TESTS Rich/Objective Models, User interfaces
  • Stakeholder Involvement description Kind of involvement Relevant Viewpoints Human Resources Control vision of roles and actors. Re-form or create a new Processing office. KEEP INFORMED / INVOLVE in NEW ACTOR CREATION Actor Location, Competency map Students Take part in tests of a new system, get to know and share information among themselves about new possibilities. KEEP INFORMED Interested in timely and quality materials.
  • Stakeholder Involvement description Kind of involvement Relevant Viewpoints Human Resources (HR) e.g., HR Managers Key features of the enterprise architecture are the roles and Actors that support the functions, applications, and technology of the organization. HR are important stakeholders in ensuring that the correct roles and actors are represented. KEEP INFORMED / INVOLVE in NEW ACTOR CREATION Organization Chart / Organization/Actor / Location Competency map Customer Peculiar interests to simplify interaction with supplier; Interacting directly across systems. INVOLVE if necessary; ANALYSIS Concerned that specific data is not protected well or is transmitted via insecure networks.
  •  Identify business goals, business drivers of the organisation • May be defined elsewhere in the enterprise o If yes: ensure that the existing definitions are up to date, and clarify any areas of ambiguity  Define constraints that must be dealt with • project-specific constraints (time, schedule, resources, etc.) • enterprise-wide constraints (by the business and architecture principles)  Work with originators of the Statement of Architecture Work and Corporate Management to secure their endorsement.
  •  Define what is inside and what is outside the scope of the Baseline Architecture and Target Architecture efforts • Often Baseline is described on higher level of abstraction to save time and capabilities for more detailed Target description  TOGAF requests to define: • The breadth of coverage of the enterprise • The level of detail required • The partitioning characteristics of the architecture • The specific architecture domains to be covered (business, data, application, technology) • The extent of the time period • The architectural assets to be leveraged, or considered for use
  •  Review the principles under which the architecture is to be developed • normally based on the principles developed as part of the Preliminary phase  Ensure that the existing definitions are current, and clarify any areas of ambiguity  Work with responsible for Architecture Governance and corporate management to secure their endorsement
  •  Create a high-level view of the Baseline and Target Architectures based on: • Stakeholders concerns • Business capabilities requirements • Scope • Constraints and principles  TOGAF states Business scenarios as useful technique
  •  Business scenario is a method for: • identifying and articulating the business and architecture requirements  Method may be used iteratively and at different levels of detail  Business scenario describes • A business process, application, or set of applications that can be enabled by the architecture • The business and technology environment • The people and computing components (called "actors") who execute the scenario • The desired outcome of proper execution
  •  Identifying, documenting, and ranking the problem driving the scenario  Identifying the business and technical environment of the scenario and documenting it in scenario models  Identifying and documenting desired objectives • Get "SMART“
  • A good business scenario is "SMART"  Specific, by defining what needs to be done in the business  Measurable, through clear metrics for success  Actionable, by • Clearly segmenting the problem • Providing the basis for determining elements and plans for the solution  Realistic, in that the problem can be solved within the bounds of physical reality, time, and cost constraints  Time-bound, in that there is a clear statement of when the solution opportunity expires
  •  Identifying the human actors (participants) and their place in the business model  Identifying computer actors (computing elements) and their place in the technology model  Identifying and documenting roles, responsibilities, and measures of success per actor; documenting the required scripts per actor, and the results of handling the situation  Checking for "fitness-for-purpose" and refining only if necessary
  • 1. • Problem 2. • Environment 3. • Objectives 4. • Human Actors 5. • Computer Actors 6. • Roles & Responsibilities 7. • Refine
  • Digging into details through iterative phases of Gathering, Analyzing and Reviewing
  •  Gathering is the phase where information is collected • Multiple techniques to solve this phase o Desk research to investigate Information o Surveys o Workshop with carefully selected participants from high levels in business and technical positions  Enterprise Architect can strengthen the business scenario by obtaining "real-world examples"
  •  Information gathered is processed and documented  Further models are created to represent that information  Maintain linkages between the key elements of the business scenario • Creation of matrices that assist in maintaining such linkages o Constituencies o Human Actors o Computer Actors o Issues o Objectives
  •  Feedback results to the contractor of the project to ensure that there is a shared understanding of: o the full scope of the problem o and the potential depth of the technical impact.  Interactive workshops are an appropriate way to communicate the results  Key sensitive feature o Absence of shared expectations in many cases the background of latter project failures
  • by Dr. Vsevolod S. Chernyshenko
  • Aggregation Composition Association / has interfaceGeneralisation Is constraint Has note Dependency Has association class
  • has note has sub document
  • Build a Data model showing which data is relevant to solve the task, presented in the previous exercise (during past lecture). Reminder: Your organization requests you to conceptualize and implement a new social system oriented both on academicians and students, their parents for a National Ministry of Science and Education. End-consumer is your home university.