Enterprise Architecture - An Introduction
1 like114 views
The document provides insights into enterprise architecture, emphasizing its role in aligning technology with organizational goals and operational strategies. It covers essential concepts, governance, and the compliance impact of regulations like GDPR, while highlighting the responsibilities of architects at various levels. Furthermore, it discusses frameworks, effective practices, and the importance of adapting strategies to the unique context of each organization.
Enterprise Architecture - An Introduction
- 1. 13/11/2018 1 An Evening of Enterprise Architecture Awareness BCS Enterprise Architecture Specialist Group Hosted by Wednesday 14 November 2018 Sussex University #BCS #BCSEASG www.bcs.org Daljit Banger , Lorne Mitchell, Ian West Running Order 1. Enterprise Architecture an Introduction from the Real World 2. Agile Enterprise Architecture: Paradox or Oxymoron? 3. Modelling for Enterprise
- 2. 13/11/2018 2 Enterprise Architecture An Introduction Daljit Banger MSc FBCS 14th Nov 2018 Hosted By Context Enterprise Architecture What HowWhy
- 3. 13/11/2018 3 Some Terms…. Enterprise • An undertaking ( commercial or not-for-profit ) existing to deliver specific products/services or capabilities to a set of consumers - People, Places and Things. Systems • A set of things working together as parts of a mechanism or an interconnecting network • Methods, Procedures and Routines created to carry out a specific activity, duty, or solve a problem. Architecture • The art of designing and building Systems and Structures. Capability • The power or ability for a computer system to do something i.e. performing a specified task or set of tasks. Service • The ability to do something or deliver something of material value e.g. a business capability like Human Capital Management (HCM) Governance • The action of governing and controlling a set of technology capabilities in an Enterprise. People, Places and Things Inputs, Processes & Outputs New Business Models Considerations… Operating Environment Technical Debt Complex Technology Estates InnovationNew Ways of Working / Channels Systems Best Practices IT Costs / Budgets Technology Alignment / calibration Drivers for Change Enterprise Architecture as a function ensures that all of the above, at a minimum, are aligned and managed to deliver the strategic, tactical and operational goals of the Organisation. Business Strategy Global Services
- 4. 13/11/2018 4 Enterprise Architecture supports how one builds a reusable Unified Information Systems/Management Capability that supports and meets Organisational needs. The EA Goal is to Align and Manage the Technology landscape of an Organisation with its Strategic / Operational Goals/Objectives for both today and tomorrow. Enterprise Architecture is NOT Enterprise Systems Architecture. Enterprise Architecture is NOT a methodology for building a stand-alone single information system. Enterprise Architecture is NOT Enterprise Systems Architecture. Enterprise Architecture is NOT a methodology for building a stand-alone single information system. Food for thought .. A Quick Introduction
- 5. 13/11/2018 5 The Stack – (BOM to Technology Mapping) Each layer in the Stack can be further decomposed, with each layer pushing or consuming to the layer above and below. The Stack – (BOM to Technology Mapping) Each layer of the Stack is a complex view in its own right of a specific element of how the layer above and below maps and interacts to support the Business Operating Model What are the tools available to us to analyse, visualise and render to stakeholders the alignment ? The Stack (Methods/Questions)
- 6. 13/11/2018 6 The Stack (Points in time ) • What if a new piece of legislation is imposed by a Local, Central or International body with which the organisation must comply? One such piece of legislation that is coming in 2018 is the General Data Protection Regulation (GDPR) • Full text of GDPR can be found at http://ec.europa.eu/justice/data- protection/reform/files/regulation_oj_en.pdf ) • “Do nothing” was not an option as GDPR significantly raised the stakes in terms of compliance, with maximum penalties of 4% annual global turnover or up to 20m Euros (whichever is higher). • How do we ensure that we are compliant using an Enterprise Architectural Approach and that we have factored most areas of our technology estate to the problem? • More info available at my blog : https://dalbanger.wordpress.com/2017/03/18/general-data-protection-regulation- gdpr-and-the-enterprise-technology-landscape/ Example Scenario Example Scenario
- 7. 13/11/2018 7 Guidance Consent • freely given ? Transparency Profiling High risk processing Certification Administrative fines • 4% annual global turnover or up to 20m Euros (whichever is higher). Breach notification • where feasible, within 72 hours of becoming aware! Data transfers Privacy by Design General Data Protection Regulation (GDPR) http:www.s-ea-t.com CopyrightDaljitRBanger Impact / Touchpoints Data Breach Policy Audit / Trace Reporting Info Exchange Policies Info Processing controls refactoring refactored Controls DR Systems Compliance Procedures Reporting SQL Extracts Audit Privacy by Design principle Impact of GDPR on the Enterprise / Actions
- 8. 13/11/2018 8 Products of Enterprise Architecture The deliverables and attributes of artefacts produced by the EA teams will be directly influenced by one or all of the following: TheStructure/Sizeofthe Organisation Characteristicsofthe Organisation TheOperatingEnvironmentofthe EnterpriseArchitecturePractice Managementbuy-inofEnterprise Architecture SizeandBudgetAvailabletothe Team. TeamCapabilities 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/industries are ever identical Abstract • Notional Models • Views Functional interactions & Inter- relationships Artifacts / Components Support / Hygiene Regulatory Requirements Vision - Goals Context..
- 9. 13/11/2018 9 Control Governance – Process Boards – Review, Technical, Business Boards Programme / Project Engagement Business / Partner Engagements Stakeholder Management Approvals – Build Permits Inform Principles Policies Portfolio Manageme nt Funding Models Reference Models • Technical • ApplicationBest Practices Patterns Impact Assessmen ts Marketing Plans 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… Enterprise Architecture Products (Support/Enablers) .. Enterprise Architecture - Example Product Matrix Control Inform Direct Artefacts x x x API Management x x Governance – Process x x Application - Target Architecture/s x x Architectural Boards – (Review, Technical, Business Boards(Participation)) x x Architectural Principles - System, Process, Generic x x x Best Practices Research / Promotion/ Socialisation x x x Business Architecture Target Definition x x x Data & Information (MDM Strategy), Journey from Data to Insights x x x Financial / Funding Models (TCO, Investment Plans) x x x Gap Analysis – New Solutions, Transitional States x x x Group / System Policies (Sys Admin etc) x x x Impact Assessments - Projects, Technologies, Solutions x x x Infrastructure Target Architecture – Enabling Technology & Platforms x x Reusable System Patterns (Dev, Integration etc.) x x Portfolio Advisory x x x Programme / Project Engagement x x x Reference Models x x x Technical / Application x x x Roadmaps (Product / Technology) x x x Service catalogue Strategy (Product/technology, Deviation etc.) x x x Service promotion Plans x x x Stakeholder Engagement x Stakeholder Management x x Standards / Notations (Promotion of BPMN, UML, Archimate, etc.) Enterprise Architecture – Example Product Matrix
- 10. 13/11/2018 10 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. Products of Enterprise Architecture Contd.. Services/Touchpoints of Enterprise Architecture
- 11. 13/11/2018 11 The Role.. • Strategic input into the technology roadmaps of the organisation – shape, form and stabilise. • Influence decision makers on technology investment – current & future • Provide systems consultancy, guidance and assurance to large programmes. • Review and assure Solution Designs produced both internally and by 3rd party suppliers. • Ensure that governance mechanisms such as review boards, principles etc. are maintained and supported. • Police the standards through Project and Programme engagement. • Represent the organisation with 3rd parties, for example Systems Integrators and Standards Bodies. • Understand the impact of the introduction of new technology into the technology landscape of the organisation. Enterprise Architects maintain the organisational abstract view, with a primary objective to ensure that the technology landscape is aligned to the strategic, operational and tactical goals of the organisation. Roles & Responsibility (EA)
- 12. 13/11/2018 12 Solution Architects work with/in Projects and Programmes to provide systems consultancy services, impact assessments, end-to-end designs, cost models.. Solution Architects work within the Projects and Programmes to deliver the following architectural services: • Manage the ‘cradle to grave’ – from conception through to delivery into production of solution architectures. • Design both the physical and logical components of solution architectures that will deliver a positive business outcome. • Work with Project Managers to provide provisional costs for the components of the architecture. • Technical Analysis and Design capabilities • Business and technical requirements capture, when required • Facilitate design workshops • Validate designs / costs produced by 3rd parties wishing to sell systems to the organisation. Technical Architects deliver the lower level of technical design, based on high-level component solution designs and costs provided by the Solution Architects. Technical Architects work with projects and the BAU organisation to provide some of the following: •Delivering technical designs and standards and the associated approvals from the formal governance channels. •Understanding the technology estate and the encapsulated technology components of the organisation. •Providing technical recommendations and options based on solution designs which can cost-effectively be realised in the production environment. •Mitigating any technical risks that could occur through the introduction of new technology into the landscape of the organisation. •Providing input into the appropriate innovation funnels for the analysis of new technology. •Keeping abreast of technology trends, attending industry events to ensure product roadmaps are understood by the Solution and Enterprise Architects. •Ensuring that production acceptance for projects is delivered and managed. Roles & Responsibility (SA&TA) 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’ or Framework approach. • Architectural Realisation is a way of thinking and not a concrete technological implementation. It is however, supported by frameworks, patterns & best practices that complement the mindset. • As an Enterprise Architect you must be aware of both the technology landscape of your organisation and external factors that can impact the landscape.
- 13. 13/11/2018 13 Website : www.s-ea-t.com (Tools, Papers Downloads) Blog : https://dalbanger.wordpress.com/ Email : [email protected] Thank You