MSYS 50: Enterprise Architecture PDF
Document Details
Uploaded by SpellbindingRhyme
Tags
Summary
This presentation covers enterprise architecture, highlighting its complexity and the need for common language and models to manage it. It compares EA to city planning and presents examples of architectural domains and frameworks.
Full Transcript
# MSYS 50: Enterprise Architecture ## The Complexity of EA ### Outline - EA and city planning - Common language - Models - Frameworks ## Understanding Organizational Complexity - Enterprise architecture is unlike building architecture - Organizations are dynamic socio-technical systems - Ca...
# MSYS 50: Enterprise Architecture ## The Complexity of EA ### Outline - EA and city planning - Common language - Models - Frameworks ## Understanding Organizational Complexity - Enterprise architecture is unlike building architecture - Organizations are dynamic socio-technical systems - Cannot be engineered then built - Complex, organic, living entities that gradually evolve over time - Successful organizations: well-managed evolutions ## EA and City Planning - EA is a complex, multifaceted organizational practice. - City planning is an accurate analogy. - Multiple parallels can be drawn. ## Commonalities: EA and City Planning Characteristics | EA | City Planning | | ----------------------------------- | --------------------------------------- | | Business executives | City governors | | IT project teams | Construction teams | | Architects | City planners | ## EA Architects - Chief IT planners and owners of EA artifacts - Knowledgeable in business and IT, but have IT-centric background - Effective communicators - Team players - Innovators ## Responsibilities of EA Architects - Intermediaries between diverse stakeholders - Develop, update, peer-review, and approve EA artifacts - Create and maintain a repository of EA artifacts - Set-up software tools for EA - Establish, run, and optimize EA processes ## Commonalities: Organizations and Cities - Cannot be perfectly planned in every detail - Future needs can be anticipated but not described in detail - Running and evolving, at the same time - Cannot be changed entirely, but through incremental modifications - Major changes do not happen overnight ## Commonalities: Organizations and Cities (Continued) - Poor planning decisions can significantly hinder further development - Evolution is endless - No single best way to evolve - Planning must consider multiple concerns ## Major Considerations - Communication - Problem of alignment - Major challenge because each domain developed by distinct stakeholders with their own concerns and language. - Needs bottom-up process - Integration of architectural domains ## Architectural Domains - Various organizational aspects important for business and IT (Kotusev) - Sub-architectures that describe distinct functional areas (Bernard) - Integration often a challenge ### Sample Architectural Domains (LANKHORST) An image is provided that shows a representation of a sample architectural domain. This representation is presented in a diagram format which shows different, connected architectural domains, such as information architecture, process architecture, product architecture, application architecture, and technical architecture. ## Common Language - Use of common language is crucial. - No need to start from scratch - better to use existing elements when possible. ## Using Models as Representation - Models - Provide abstract, unambiguous definitions - Formal - Many types - Help capture the essence of EA. - Only the core of each domain should be included. - Multiple models are usually needed. ## Architectural Frameworks - Integrates different elements. - Many available for EA. - Considerations - Is it applicable and/or useful to the organization? - Is it worth adopting one? If not, what is the alternative?
