EA Consolidated Slides from Q1-Q2 (2015)

Architect / Advisor em Seat Consulting Ltd
15 de May de 2015

Mais conteúdo relacionado

Apresentações para você(20)

Similar a EA Consolidated Slides from Q1-Q2 (2015) (20)


EA Consolidated Slides from Q1-Q2 (2015)

  1. Introductory Concepts and Practices Daljit Roy Banger MSc FBCS Enterprise Architecture
  2. • Introduction  Todays Exam Question  Sample Definitions  Enterprise Architecture Views • Enterprise Architecture Primer  EA Frameworks  The Stack / Primer • Products of Enterprise Architecture  Context  Control,  Inform &  Direct  Engagement Model (Projects/Programmes)  Enterprise Architecture as a career  Transition • Thank You  Final Note  Question / Answers Agenda
  3. Introduction
  4. Todays Exam Questions • What is Enterprise Systems Architecture ? • What are the Products and Value of Enterprise Architecture • Position of Enterprise Architecture within the ICT organisation
  5. EA seeks to align the Business Supporting processes , Technology Capabilities (both of today and for tomorrow) to deliver efficiency and cost gains resulting in some form of competitive advantage . EA Aligns the business needs of today & tomorrow with the technology services and landscape to support those needs in a cost effective way. EA attempts to document and understand the Enterprise Eco System to deliver value adding technology capabilities and services Sample Definitions
  6. Enterprise Architecture • No Single or Generally agreed Standard or Definition. • Bias in Approach and Deliverables
  7. SEAT Zackman TOGAF FEAF MODAF Enterprise Architecture Frameworks
  8. EA Primer
  9. Value Added / Hygiene Technology Services NRF Capabilities DR Governance Enabling Technology (Physical) Device Hosting Cabling Appliances Technology Services (Logical)Service Bus Messaging Security Logging Containers Monitoring Routing Name Services Data & Information Services Big Data ETL Custodians Classification Master Data Mgmt. DW Applications Custom Off the Shelf Bespoke Development In-house/out-source Development Methods Frameworks Capabilities / Services Technical Tactical v's Operational Business Innovation Business Process Manual / Automated Formal / Informal Outsourced Straight Through / Call Off Inventory Business Operating Model Info / Resources pushed & pulled External Forces (Govmnt, Competitors, Market) Strategic Drivers Structure B2B, B2C, C2B, C2C Value Added / Hygiene Technology Services Consume Produce/Deliver
  10. Time
  11. Efficiency Gains / Cost Savings can be achieved through: 1.Exploiting Technology Synergies 2.Re-using System Components 3.Exposing System Services to new processes. 4.Understanding the impact of new systems on the performance and capacity of enabling technologies.
  12. The Products of Enterprise Architecture
  13. Thus the deliverables and attributes of artefacts produced by the EA teams will be directly influenced by one or all of the following: The Structure / Size of the Organisation Characterist ics of the Organisatio n The Operating Environment of the Enterprise Architecture Practice Manageme nt buy-in of Enterprise Architectur e Size and Budget Available to the Team. Team Capabil ities However , irrespective of the structure or capabilities of the team, all artefacts can be classified into 1 of 3 domains One Size does not necessarily always fit all No Two Organisations are Identical
  14. Control Governance – Process Boards – Review, Technical, Business Boards Programme / Project Engagement Business / Partner Engagements Stakeholder Management Inform Architectural Principles (Segmented by domains) Portfolio Management (Application / Data / Infrastructure) Funding Models Technical Reference Model Application Reference Model Best Practice Patterns Repository Impact Assessments Marketing Plans Inventory of Business Processes Standards / Notations Direct Stakeholder Engagement Business Architecture Target Definition Application Target Architecture Data & Information (Master Data Management Strategy) Infrastructure Target Architecture – Enabling Technology & Platforms Roadmaps (Product / Technology) Gap Analysis – Transitional States Impact Assessments Service promotion, catalogue etc…
  15. Control Governance – Process Boards – Review, Technical, Business Boards Programme / Project Engagement Business / Partner Engagements Stakeholder Managemen
  16. Inform Principles Policies Portfolio Management Inventory of Business Processes Funding Models Reference Models •Technical •Application Best Practices Patterns Impact Assessments Marketing Plans Standards / Notations
  17. Direct Stakeholder Engagement Business Architecture Target Definition Application Target Architecture Data & Information (Master Data Management Strategy) Infrastructure Target Architecture – Enabling Technology & Platforms Roadmaps (Product / Technology) Gap Analysis – Transitional States Impact Assessments Service promotion, catalogue etc…
  18. CID Touch Points I C D I CI I C C I I D D I I
  19. Principles • Business • This criteria element relates to the promotion of enterprise wide principles around the domain of business processing, especially business process modelling and service design. • Application • Principles relating to the design, build and deployment of applications • Information • Principles linked with the production, cleansing and publishing of information • Data • Principles associated with data design, usage, persistence etc. • Infrastructure • Principles associated with selection, deployment, management of the infrastructure (data Centres, Servers storage, network etc) • Foundation Services. • Foundation services relate to DR, Security, Incident management etc i.e. services that are core to all of the above Practices • Business Operations • Here Enterprise Architects should be concerned with the practices associated with capturing, modelling and digitally executing the business operations. • Application Design • I.e. delivery of designs of. Whilst, practices adopted may based on a specific methodology or approach, the real question ‘ how efficiently have we adopted the practices of the approach and are we meeting the business demands based on this adoption ?’ • Application Build • The maturity of the build of applications both internal and externally developed applications should encapsulate test of software unit, components etc prior to build • Governance • Architectural Governance and the teeth i.e. power of associated with the various boards. • Service Delivery • The maturity of the practices i.e. what actually happens during the deployment, management of systems on the technology landscape. • Support • Whilst this is close to Service Delivery it must be noted that we should rank how effectively the EA team deliver the support of its artefacts Process • Business • The engagement of the Enterprise Architecture functions with the Business Process Modelling and Design functions and any alignment activities. • STP • EA should facilitate a move towards Straight Through processing i.e. reducing the number of digital and manual process hand offs between processes. • Information • The Information Architecture and the associated process to capture, manage and publish EA information. • Orchestration • This relates to the processes associated with orchestrating business and technology services • Production Acceptance • The maturity of the processes associated with deployment, management of systems accepted into the production environment. • Documentation • The maturity of document production , publication and promotion by the Enterprise Architecture function • 3rd Party Engagement • How effectively does EA engage with 3rd parties to maximise the benefits to the organisation e.g. cost reductions, savings etc • Contribution to the Enterprise • What is the general perception of EA processes e.g. Governance contributing real value to the organisation from system users to senior management? Patterns • Publications • Does the organisation have a patterns catalogue? How mature is the organising in publishing it patterns, do these publications adopt standards for syntax, notations etc • Promotion • How are patterns promoted through the organisation, are they rendered via an intranet? Or are they in a document library somewhere? • Development • How patterns are developed – are they text book extracts or are they developed with the various technical communities? • Usage • Do the technical Communities use these patterns to provide efficiency gains to the organisation? • Application • Application patterns are to be found publically available and thus should be exploited – do your organisational developers for example exploit published patterns when constructing applications. • Infrastructure • As with Applications above – Do your Service delivery personal for example use standard patterns for system configurations deployed into production. • Security • Security patterns are emerging as a key in distributed systems – are these in use ?, does the technical community know of the existence • Re-Use • How often are patterns re-used if at all and do we as an organisation promote reuse. Portfolio Management • Services • Most Organisations have their own definition of a Services the EAM measure assumes a service as a function that is well-defined, self-contained, and does not depend on the context or state of other services. A service can be either a business or technical object. • Application • The portfolio of applications in an Organisation can be a mix of either bespoke or Commercial Off the Shelf (COTS) either way the life cycle should be managed in a single unified location. • Middleware • Middleware could refer to Enterprise Service Buses, Messaging or even request brokers – these should be managed and in most cases the interfaces to these systems. • Storage • Information and data object persistence should be monitored and managed, i.e. not be the physical devices e.g. the NAS or SANs etc. • Servers • The portfolio management of the Physical Servers both in the production and test environments. • Other Infrastructure • Maturity of the portfolio management of the Physical devices e.g. network Switches, laptops, etc. • Techniques • The techniques adopted to create, capture and manage the information required to measure the level of maturity in the management of the ‘artefact’ portfolio. 5P’s of Enterprise Architecture
  20. EA Career Path
  21. Transition to an Enterprise Architecture
  22. Final Note • Enterprise Architecture is delivered in the context of the Organisation – true value can not be realised by simply following a single ‘Cook Book’ approach. • Architectural Realization is a way of thinking and not a concrete technological implementation. It is however, supported by frameworks, patterns & best practices that complement the mindset.
  23. Website : (Tools, Papers Downloads) Blog : Email : Thank You

Notas do Editor

  1. The purpose of today's session is to revisit some core concepts around Enterprise Architecture and highlight what success should look like. We shall Revisit What it is Enterprise Architecture is and is meant to deliver Discuss the characteristics of a successful Enterprise Architecture practice Discuss observations from existing clients and highlight the progress to date. Have a Open Forum discussion around the way forward on delivering and promoting Enterprise Services
  2. Get the audiences perception of EA .. This should allow the structure of the session i.e. If they have a clear understanding of EA , then the focus should be on the academics and experiences to date. If they do not get it then this should be treated as a instructional lecture with follow on actions
  3. The Purpose of this slide is to highlight – how sometimes we can make over complex simple theories... This is often done by ‘Ivy league’ consultancies to sell additional services. In essence EA is about aligning the needs of the business with the technology capabilities ... Keeping it simple, agile and responsive as a service facilitates the perception of the ‘value for money’ service
  4. Hidden Slide
  5. Master Stack
  6. 27