Understanding Enterprise Architecture and Complexity Reduction Strategies

Enterprise Architecture Supplemental Notes

What is Enterprise Architecture Enterprise Any organisation (company, charity, government department/agency) A collaborative collection of sub-organisations with a sharted set of objectives Architecture Complex or carefully designed structure of something A description of the structure (components) and behaviour (processes) of a system Activity required to produce such a description

The course of lectures on enterprise architecture by Svyatoslav Kotusev (kotusev@kotusev.com) What Is EnterpriseArchitecture? Enterprise architecture (EA) can be defined as a collection of special documents (artifacts) describing various aspects of an organization from an integrated business and IT perspective intended to bridge the communication gap between business and IT stakeholders, facilitate information systems planning and thereby improve business and IT alignment Enterprise architecture typically describes business, applications, data, infrastructure and sometimes other domains relevant from the perspective of business and IT, e.g. integration or security SK #3 Based on the book The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment

What is Enterprise Architecture Enterprise Architecture Documentation describing the structure and behaviour of an enterprise (including its information systems) A process for describing an enterprise (including its information systems), then planning and governing changes to improve the integrity and flexibility of the enterprise

Frameworks Structure Zachman Content Metamodel TOGAF Framework TOGAF Process People Zachman Organisation Roles

Reducing Complexity A large, complex enterprise

Reducing Complexity Segment One way to reduce complexity is to segment the organisation into subsidiaries, breaking government departments up into agencies and so on Segment Segment Segment

Reducing Complexity Another way is to break the enterprise into domains

Reducing Complexity Another way is to break the enterprise into domains DOMAINS 1 2 3 4

Typical Domains Strategic thinking Goals Capabilities Business Architecture Objectives Processes The reason the organisation exists BUSINESS Functions Organisational structure

Typical Domains Data / Information Architecture BUSINESS DATA Overlap Business has its own view of the data and information The data tends to look at the entire organisation in the information systems layer

Typical Domains Application(s) BUSINESS Focussing on the IT applications Offer services DATA APPS Triangle Applications help the data on behalf of the business Applications offer up services to the business which in turn means that the business describes the business services to, either internally or externally to customers

Typical Domains Infrastructure / Technical Domain BUSINESS DATA APPS Infra Platform Wires Nuts and bolts Systems software

Typical Domains Overlaps represent where the business maps to the data architecture and the business architecture maps to the application architecture and how the data and applications architecture dependent on the infrastructure architecture BUSINESS Overlap Overlap DATA APPS Overlap Overlap Overlap Infra

Other Domains Security BUSINESS Compliance Compliance Security DATA APPS Infra

Architecture Activities Create architecture descriptions For each domain Have to be consistent and map to each other Need to have at least two: Baseline Future or target Represent the strategic vision of the organisation or enterprise Intermediate #1 Baseline Target Intermediate #2

Architecture Activities Create architecture descriptions Gap Analysis Differences What needs to change in these architectures to enable them the organisation to move forward Gap Intermediate #1 Baseline Target Gap Intermediate #2 Gap

Architecture Activities Create architecture descriptions Gap Analysis Plan strategic migration How can we fill the gaps? Intermediate #1 Baseline Target Intermediate #2

Architecture Activities Create architecture descriptions Gap Analysis Plan strategic migration Define principles and standards Enterprise architecture is not about doing these changes, but overseeing those changes by defining various architecture principles and standards Intermediate #1 Baseline Target Intermediate #2

Architecture Activities Create architecture descriptions Gap Analysis Plan strategic migration Define principles and standards Govern change activities Ensure standards and principles are being followed Ensure plans are going to achieve what the organisation needs Overseeing and governing Intermediate #1 Baseline Target Intermediate #2

Purpose of EA 90's to Early 00s IS/IT focus Silo-ed approach no sharing Integration and interoperability Late 00s to Now Lots of middleware available Shift to business focussed EA Enabling change 'Agile' enterprises

EA Program Approach Re-Evaluate: Identify Places Where EA Can Make an Impact Layers Communication & Education Advisories, Methodologies, and Principles Security Architects Requirements and Needs User Experience Applications and Software Components UX Consultation Interoperation Enterprise Architecture Implementation Plan Enterprise Technology Assessment Patterns and Reference Architecture Ad-Hoc Consultation Data Middleware ITCRB and PRC Reviews Infrastructure and IaaS Technology Trends and Best Practices Outreach and Training Networking Evaluate Skills & Organizational Needs 22

Domains of Enterprise Architecture The informational contents of enterprise architecture typically encompass the following common EA domains: Business domain covers customers, capabilities, processes, roles, etc. Applications domain covers programs, systems, custom software, vendor products, etc. Data domain covers data entities, structures, sources, etc. Integration domain covers interfaces, connections, interaction protocols, integration platforms, etc. Infrastructure domain covers hardware, servers, operating systems, networks, etc. Security domain covers firewalls, authentication mechanisms, identity and access management systems, encryption, etc.

The course of lectures on enterprise architecture by Svyatoslav Kotusev (kotusev@kotusev.com) EA Domains as aStack The set of common EA domains can be represented asa multilayered stack of domains, where lower layers underpin higher layers: Applications automate business processes Data is used by applications Integration mechanisms link all applications and data together Infrastructure hosts all applications, databases and integration platforms Security mechanisms permeate all other EAdomains The business domain is non-technical in nature, while all other EA domains are technical domains directly related to respective technologies SK #24 Based on the book The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment

The course of lectures on enterprise architecture by Svyatoslav Kotusev (kotusev@kotusev.com) Enabling and Supporting EA Domains All EA domains can be also separated intobusiness- enabling domains and business-supporting domains Business-enabling EA domains occupy the toplayers of the stack and represent functional domains These domains are relevant to business stakeholders and define the core business functionality of ITsystems Business-supporting EA domains occupy thebottom layers of the stack and represent non-functional domains These domains are irrelevant to business stakeholders and unrelated to business functionality of ITsystems SK #25 Based on the book The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment

The course of lectures on enterprise architecture by Svyatoslav Kotusev (kotusev@kotusev.com) The Stack of EA Domains Generally, enterprise architecture can describe any domains considered as important from the perspectiveof the relationship between business and IT SK #26 Based on the book The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment

Also see this: https://www.youtube.com/watch?v=9TVc32M_gIY https://www.youtube.com/watch?v=ahL1BCy_xLg&list=PLgn00WwJc Emo-m6nKFz2gh_r5l3jyqtGI (This is all about TOGAF) https://www.youtube.com/watch?v=mneshWqaqXU (COBIT 5W 1H)

Key Terminology: Layers Layers Definition Examples User eXperience End-user look-and-feel and navigation style of an application or service. Appearance of the Harvard brand, color schemes, use of breadcrumbs , position and appearance of navigation bars. Applications, services, SaaS Algorithms and code that provide technical or business value. Large-scale apps such as SIS, small apps such as Electronic Submission Tracking and Reporting (ESTR), services such as Informatica for data transfers, and Software-as-a-Service solutions such as Office365. Interoperation Exchanges of information and provisioning of business transactions between different applications and services. Information exchanges include transfers of student registration from SIS to central directories, or transfer of account balance values from financial to CRM systems. One remote service is IAM s Authentication service. Data Information represented in formats managed by apps and services. Structured data include student records and general ledger financial data; unstructured data include e-books, wiki content, and most of the information available on the Internet. Middleware Common business or technical services that are implemented separately from applications and services. Database technologies are the most common example of middleware, but this layer can also include reporting engines , rules engines , application servers, data transfer applications, and other common shared services. Infrastructure Hardware and virtualized platforms that operate applications, services, and their components. Servers, associated storage components, operating systems, and other computing devices are common examples, as well as cloud-based infrastructures of Platform-as-a-Service and Infrastructure-as-a-Service. Networks Communications tech to join infrastructures in disparate locations. Wired and wireless communications supported by devices such as routers, switches, and naming services. Security Use of resources by authorized individuals and computing services to information, business functions, and computing services. Mechanisms include door locks, user IDs/passwords, and intrusion detection/prevention tools. These are supported by apps/services to manage user and systemic authentication, authorization, and access to functionality and data. 28

Key Terminology: Processes Processes Definition Examples Principles Foundational elements to drive decision- making and alignment. Principles can be applied at many levels, from guiding principles that characterize strategic, enterprise-wide systemic behavior, to principles that help explain detailed technical behaviors of applications and services. Methodologies Methodologies divide IT work into phases for better planning and management, and determine methods or best practices to be applied to specific cases. May include specific deliverables/artifacts. Waterfall, prototyping, iterative, and incremental development; spiral development; rapid application development; extreme programming; Agile. Advisories Recommendations offered as a guides to specific actions or practices. Security notifications of newly discovered vulnerabilities with recommendations for patching systems or changing passwords; and announcements of changes to the features, forms, or functions of applications. Patterns Generic models or descriptions from which specific implementations can be based or derived. Reusable approaches for connecting applications to databases, establishing user security within an application, or implementing user experience in a solution. Reference Architectures A template solution that defines an architecture for a particular domain using multiple patterns and a vocabulary that promotes commonality. Business reference architectures include Insurance Application Architecture (insurance),and HL7 V2.5 (health records). One technical reference architecture is Java Enterprise Edition for IT systems construction. Outreach Elevating awareness of programs and initiatives to affected populations. Broadly-focused outreach at Harvard includes ABCD meetings on a wide range of IT topics; more narrowly focused are Big Group meetings on specialist topics such as IT skills upgrades. Training Acquiring knowledge and skills as a result of teaching on specific competencies, with a goal of improving productivity and performance. IT techniques training could include database design, software coding in node.js, and process modeling with BPMN. Vendor tool training could include Oracle Financials, PeopleSoft, and Informatica ETL. 29