Your SlideShare is downloading. ×
© HW Sorenson Architecture-based Enterprise Systems ...
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

© HW Sorenson Architecture-based Enterprise Systems ...

391
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
391
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Architecture-based Enterprise Systems Engineering (AESE) An Emerging Graduate Program at the University of California, San Diego © HW Sorenson http://aese.ucsd.edu Joint Program of the Jacobs School of Engineering and the Rady School of Management
  • 2. © HW Sorenson The AESE Process Architecture-based Enterprise Systems Engineering (AESE) The AESE Structure People Organization Technology
  • 3. The General Context
    • Business & National Security Operations Involve
      • Many diverse stakeholders with differing cultures and responsibilities
      • High degree of heterogeneity and redundancy in organizations, processes, and systems
      • Large number of autonomous or stove-piped systems
      • Inconsistent data/information models and data bases
      • … ..
    • Business & National Security Operations Need
      • Cross-domain interoperation
      • Ability to respond to unexpected events in timely and effective manner
      • Decision support systems closely related to mission objectives
      • Affordable “IT renovations” that provide improved and new capabilities in the short-term
    © HW Sorenson
  • 4.
    • Enterprise systems are composed from component systems with these characteristics
      • The component systems achieve well-substantiated purposes in their own right even if detached from the overall system;
      • The component systems are managed in large part for their own purposes rather than the purposes of the whole;
      • It exhibits behavior, including emergent behavior , not achievable by the component systems acting independently
      • Functions, behaviors and component systems may be added or removed during its use
    • The resulting system is open and involves many management domains
    Important Characteristics of the Situation © HW Sorenson * After Maier, Sage, Levis…
  • 5. Return to the Basics of Systems Thinking 1
    • Operational definition of a “systems methodology” involves three interdependent variables
      • Structure
      • Function
      • Process
      • that, together with the environment , define the whole
    • Structure defines components and their relationships and constraints– synonymous with input, means, and effects
    • Function defines the outcome – synonymous with output
    • Process defines the sequence of activities required to produce the outcomes – how to do the function
    • Development process is necessarily iterative
    © HW Sorenson 1 Gharajedaghi, Jamshid, Systems Thinking: Managing Chaos and Complexity , Butterworth Heineman, 1999
  • 6. Return to the Basics of Systems Thinking 1
    • Operational definition of a “systems methodology” involves three interdependent variables
      • Structure
      • Function
      • Process
      • that, together with the environment , define the whole
    • Structure defines components and their relationships and constraints– synonymous with input, means, and effects
    • Function defines the outcome – synonymous with output
    • Process defines the sequence of activities required to produce the outcomes – how to do the function
    • Development process is necessarily iterative
    © HW Sorenson This methodology provides the basis for all of the program offerings 1 Gharajedaghi, Jamshid, Systems Thinking: Managing Chaos and Complexity , Butterworth Heineman, 1999
  • 7. Evolution of Systems Thinking © HW Sorenson Entropy is the measure of randomness in the universe. According to the Second Law of Thermodynamics, closed systems move toward increasing disorder or higher levels of entropy. However, open-living systems display and opposite tendency; they move toward order , thus generating negative entropy. Emergent behaviors are a result SHIFT OF PARADIGM Mindless System Machine Model Analytical Approach Independent Variables Interchangeability Of Parts & Labor Henry Ford’s Mass Production System
    • Purposeful
    • Society
    • Organization
    • Members
    Social systems are information-bonded Choice Reductionist Uniminded System Biological Model Multiminded System Social Model Systems Approach Interdependent Variables Diversity & Growth Alfred Sloan’s Divisional Structure Redesign Ackoff’s Interactive Management Participative Management Self-organizing Systems Tavistock Institute’s Socio-Tech Model Joint Optimization Ford’s Whiz Kids Operations Research Flexibility & Control Ohno’s Lean Production Cybernetics Model
  • 8. © HW Sorenson Context Problem Formulation Solution Approach Solution Implementation The Problem Solving Structure The Systems Methodology Understanding the Context is manifested as a strategy which drives the systems problem in terms of three interdependent variables and the solution is developed iteratively Function Structure Process Strategy AESE Program Fundamentals Desired Capabilities
  • 9. Enterprise SE Context
    • “ Continuous improvement” – no prescribed “end point”
    • “ Desired enterprise capabilities” – no well-defined and bounded requirements
    • Reality indicates that “no one” is actually in charge
    • Heterogeneity across diverse stakeholder domains
    • “ Systems” come and go so enterprise system is NOT bounded
    • … .
    • Enhanced capabilities evolve “rapidly” in the small and extend to the enterprise where needed
    • Trade studies using “prototypes and experimentation” “in the small”
    © HW Sorenson
  • 10. The Enterprise Systems Engineering Context
    • Development is driven by fundamental tension between needs of the enterprise and of the local user
      • Internet, W3C, and IT enable solution for different “virtualization” views (i.e., structure )
        • Trust virtualization and information governance
        • Storage virtualization (SANs)
        • Data virtualization (metadata repositories)
        • Information virtualization (semantic grid)
      • “ Data”, “information”, and “knowledge” are the medium of exchange * (i.e., function )
      • Business process modeling and work flow engines provide the basic tools for analysis (i.e., process )
    • Potentially a very large number of entities; people, organizations, and technologies (e.g., systems)
    • Dimensionality is a curse – system complexity
    © HW Sorenson The concepts and ideas stemming from the study of complex adaptive systems provide the foundation for the AESE Program.
  • 11. Basics of the AESE Development Approach
    • Development shall be done in a “ continuous iterative manner ”
      • Natural systems follow an evolutionary process – not a revolutionary process
      • Even disruptive innovations are introduced in an evolutionary manner
        • Example : The Internet and World-wide Web, while clearly having a revolutionary impact, have evolved and continue to evolve
    • Iterations are driven by business needs
      • What capabilities are most needed for the enterprise to survive, indeed to thrive?
      • Technology application responds to the business drivers
    © HW Sorenson Build the complex enterprise system by introducing changes that can be implemented in days or weeks, not years or decades
  • 12. Basics of the AESE Development Approach (2)
    • Define the “ outcome spaces ”
      • What are desired “capabilities” ( NOT specific requirements)?
      • Capabilities need to be defined carefully BUT should not be a “point solution” as produced by a requirements-driven process
    • Develop a “ continuous interaction space ”
      • Identify all stakeholders who are to be involved in the development of a specific capability
        • Include all legacy and new systems which contribute to the capability
      • Stakeholders define measures that enable “ judgments ” to be made about the utility of a solution approach
        • Choose utile solutions and discontinue less than satisfactory solutions
        • There must be “sensitivity” to possibly destructive behaviors introduced by “unsuccessful varieties”
    © HW Sorenson
  • 13. Basics of the AESE Development Approach (3)
    • Evolve a “ development environment ” that enables
      • Implementation of business processes that produce the desired outcome spaces
      • “ Elements” to “come and go” at will
        • Co-existence of “ run time ” behaviors with “ build time ” elements
      • Use of “agile” or “plan-driven development”, as appropriate
    • Current capability should be evolved to meet recognized deficiencies through
      • Systematic assessment of Use Cases (i.e., mission threads) as related to the responsibilities and capabilities of Communities of Interest (COI)
        • Use minimal level of detail that enables identification of
          • interoperability points
          • information/data and work processes that must be exchanged or shared
    © HW Sorenson
  • 14. Basics of the AESE Development Approach (4)
    • Introduce “ Developmental Precepts ” that prescribe rules for interaction
      • Define architecting principles
      • Evolve the appropriate architecture
      • Prescribe processes for architecture conformance and implementation compliance
    • Evolve a “common infrastructure” that supports the interaction space and exhibits continuous growth in ability to support ever increasing capability
      • Infrastructure is built from the business needs down – not from a bottom up engineering development
      • Development model is supported by the style of Service-Oriented Architectures (SOAs)
    © HW Sorenson
  • 15. AESE Process, Structure, and Function © HW Sorenson
  • 16. © HW Sorenson AESE Agile Development Process EVOLVE ENTERPRISE ARCHITECTURE DETERMINE CAPABILITY NEEDS IDENTIFY CAPABILITY STAKEHOLDERS SELECT CAPABILITY USE CASES DEFINE OUTCOME SPACE DEVELOP POTENTIAL CAPABILITY SOLUTIONS PERFORM GAP ANALYSIS SELECT PILOT PROJECTS EVOLVE ENTERPRISE INFRASTRUCTURE PRIORITIZE CAPABILITY SOLUTION ESTABLISH DEVELOPMENT ENVIRONMENT CURRENT CAPABILITIES STRATEGIC DRIVERS DEVELOP ENTERPRISE STRATEGY CONTINOUS INTERACTION SPACE
  • 17. © HW Sorenson AESE Agile Development Process EVOLVE ENTERPRISE ARCHITECTURE DETERMINE CAPABILITY NEEDS IDENTIFY CAPABILITY STAKEHOLDERS SELECT CAPABILITY MISSION THREADS DEFINE OUTCOME SPACE DEVELOP POTENTIAL CAPABILITY SOLUTIONS PERFORM GAP ANALYSIS SELECT PILOT PROJECTS EVOLVE ENTERPRISE INFRASTRUCTURE PRIORITIZE CAPABILITY SOLUTION ESTABLISH DEVELOPMENT ENVIRONMENT CURRENT CAPABILITIES AGILE DEVELOPMENT STRATEGIC DRIVERS DEVELOP ENTERPRISE STRATEGY CONTINOUS INTERACTION SPACE Enterprise Level Stakeholder Level Architect Level Feedback Outcome Space Enterprise Systems Engineer Level
  • 18. © HW Sorenson AESE Agile Development Process Which can be redrawn as the fundamental structure shown in the next chart Feedback Enterprise Systems Engineer Level Architect Level Stakeholder Level Enterprise Level EVOLVE ENTERPRISE ARCHITECTURE DETERMINE CAPABILITY NEEDS IDENTIFY CAPABILITY STAKEHOLDERS SELECT CAPABILITY USE CASES DEFINE OUTCOME SPACE DEVELOP POTENTIAL CAPABILITY SOLUTIONS PERFORM GAP ANALYSIS SELECT PILOT PROJECTS EVOLVE ENTERPRISE INFRASTRUCTURE PRIORITIZE CAPABILITY SOLUTION ESTABLISH DEVELOPMENT ENVIRONMENT CURRENT CAPABILITIES AGILE DEVELOPMENT STRATEGIC DRIVERS DEVELOP ENTERPRISE STRATEGY CONTINOUS INTERACTION SPACE Outcome Space
  • 19. The AESE Structure © HW Sorenson The Enterprise Enterprise Needs Architectural Guidance AESE Establishing Enterprise Goals Leadership Enterprise Drivers Developing Enterprise Needs & Investment Strategy Management Policy & Planning Assessing Performance Management Gap Analyses Deficiency & Gap Analysis Decision Support Business Operations Inputs to Leadership and Decision Recommendations Enterprise Knowledge System The AESE Function Enterprise & Product Systems Engineering Engineering The Enterprise ESE Engineering New Systems PSE CII Enterprise Architecting Evolving The Architecture Architect Complying & Conforming Governance Architecture
  • 20. Summary of the AESE Program © HW Sorenson
  • 21. AESE Operational Objective
    • Students should have considerable experience
      • Minimum of five years but ten or more is preferable
      • Graduate degrees are desired
    • Companies are asked to identify a student team of three to five people
      • Teams should come to the start of class with a problem (i.e., enterprise capability) that has the interest of a senior manager
    • Team project results are presented at the end of the program to AESE faculty and to the interested senior managers
    • Satisfactory completion of the course work and the team project will qualify students for a graduate degree “Masters of Advanced Study”
    © HW Sorenson
  • 22. Program Educational Philosophy
    • Each course has several lecturers
    • Major topics are covered in more than one course but within different contexts and different perspectives
    • Case studies illustrate use of concepts and major topics, whenever possible
    • Hands on and active involvement is preferred learning modality
      • In-class exercises are employed as a normal procedure
      • Application of material to team project is essential and foundation for performance in the program
    • Participating organizations send a team with a team project topic having the substantial interest of a senior manager
    © HW Sorenson
  • 23. Team Project Characteristics
    • Project must be driven by the need to achieve a desirable and impactful enterprise capability enabled by timely decision-making
    • To achieve the desired capability, there must be resources available in the form of people, organizations, and technologies that exhibit a large degree of heterogeneity
    • The desired capability potentially can be achieved through loose coupling (i.e. information exchange) among the available resources
    • A resource may become unavailable and new resources may appear in sometimes unexpected ways and times
    © HW Sorenson
  • 24. AESE Collaboration Laboratory
    • Server system provided by Sun Microsystems
    • Software tools are available on the Sun server
      • Primary software tools are provided by IBM
        • Rational tools
        • WebSphere tools
      • Assorted other tools are available
        • Business modeling
        • Concept maps
        • Colored Petri Net tools
      • Tool integration is an evolving matter
    • Teams have password access to system and their data
      • No desire to accommodate either classified or proprietary data
    © HW Sorenson
  • 25. AESE Pilot Program for CY 2006
    • Four companies sent teams with a total enrollment of 15 people
    • Diverse business models were solicited as part of the proof of concept
      • Booz Allen Hamilton
      • Northrop Grumman Integrated Systems
      • Solar Turbines
      • ViaSat
    • Enthusiasm of companies and students spurred the preparation of a proposal for a professional graduate degree “Masters of Advanced Study”
    • Proposal submitted to Graduate Council in June 2007
      • Now responding to guidance from the Graduate Council
    © HW Sorenson
  • 26. The AESE Leadership Program for the 07-08 Academic Year
    • Seven organizations
      • Boeing
      • MITRE
      • Northrop Grumman Integrated Systems
      • Northrop Grumman Mission Systems
      • Solar Turbines
      • SPAWAR Systems Center
      • ViaSat
    • Twenty five students enrolled
      • All are full-time working professionals
      • Each student pays a fee of $20K for the year
    • Graduate program is comprised of
      • Nine quarter courses (36 graduate credits and 30 hours of lecture/course)
      • Four team project courses (12 graduate credits)
    © HW Sorenson
  • 27. Schedule © HW Sorenson
  • 28. The AESE Fall Quarter Courses © HW Sorenson Course 1: Essentials of Business Practice - Strategic Thinking, Finance, Investment Planning, Business Operations, Marketing, … Course 2: Leadership Skills, Values, and Team Building – Understanding Self & Others, Building Collaboration, Influence, Group Dynamics, Emotional Intelligence, Team Building, … Course 3: Complexity and Large-scale Systems – System Complexity, Event Complexity , Enterprise Transformation , Knowledge Management, Strategy for Distributed Data Management, Managing Complex Projects, Plan-driven and Agile Development, …
  • 29. The AESE Winter Quarter Courses © HW Sorenson Course 4: Enterprise Architecting – Architecture Frameworks, Enterprise Architecting and Use Cases, Ontologies, Service-Oriented Architectures, Enterprise Service Bus, SOA Security, … Course 6: Engineering Essentials for Open, Distributed Systems – Business Driven Architectures, Business Process Modeling, Using Rational Software Modeler, SOA Infrastructure and WebSphere, Distributed Data Modeling Using iRODS, Domain Modeling Exercises Course 5: Modeling, Simulation, & Analysis – Architecture Description, Structured Analysis, UML, Executable Architectures, Discrete Event Dynamic Systems, Colored Petri Nets, Architecture Analysis and Evaluation, SOA and IT Governance, …
  • 30. The AESE Spring Quarter Courses © HW Sorenson Course 9: Managing Stakeholder Relationships - Build & Leverage Business Relationships, Create Business Development Strategies, Write Winning Proposals, Lead 3 D Negotiations, … Course 8: Risk Analysis & Decision Support – Competing on Analytics, Organizational Simulation, The Real Option Approach-Case Studies, Human Decision-making, Risk & Utility Theory, Bayesian Inference, Data Mining, Real Options Basics Core Course 7: Patterns for Architecture Implementation – Pattern Methodologies and Re-use, Patterns for Enterprise Integration, Implementing Patterns-An Enterprise Chat Example, Re-usable Patterns of Business Knowledge, Patterns for Complex Event Processing, …
  • 31. AESE Leadership Program Completion © HW Sorenson Team Project Final Preparation September 9 Tuesday September 10 Wednesday Final Team Project Presentations September 11 Thursday September 12 Friday Summer Quarter (July- September, 2008)
  • 32. © HW Sorenson The AESE Process Architecture-based Enterprise Systems Engineering (AESE) People Technology Organization
  • 33. Fundamental Questions That Must Be Answered in the Final Team Project Presentation © HW Sorenson
  • 34. What aspects should be considered in any architecture development?
    • At the Enterprise level
      • What is the relevant enterprise strategy and vision?
      • Does the architecture development have a well-defined scope and domain?
      • Has the stakeholder community been identified and the various points-of view been involved from the early stages of the development?
    • Using an Architecture Framework
      • Do the Views that are considered relate to all of the stakeholder groups that have been identified?
      • Do the viewpoints capture all of the concerns of the stakeholder groups?
      • Is there appropriate recognition of cross-cutting concerns (or perspectives) that span the views?
    • Summary question:
      • How do the preceding considerations inform the architect about desired capabilities and the most important requirements for the desired enterprise system?
    © HW Sorenson
  • 35. What aspects should be considered in any architecture development? (continued)
    • Concordance (or consistency) across views
      • What does it mean to make the viewpoints concordant or consistent?
      • Recalling the RUP construct of the “4+1” views, what is the “+1” view and how does it related to the question immediately above?
      • How does the development of use cases assist in achieving concordance?
    • Summary Question:
      • Does the preceding development concerns speak to the following possible principle for architecting and please discuss?
    • Principle: Architectures are created solely to meet stakeholder needs
    © HW Sorenson
  • 36. What aspects should be considered in any architecture development? (continued - 2)
    • Observation: Use cases (sometimes referred to as scenarios or mission threads) provide an integrating concept to capture desired capabilities and requirements
    • Architecture Description (i.e., model)
      • Using UML as the modeling language, how do use cases enable the development of UML diagrams? For this answer, discuss
        • Class diagrams
        • Activity diagrams
        • Sequence diagrams
        • State diagrams
    © HW Sorenson
  • 37. What aspects should be considered in any architecture development? (continued - 3)
    • Executable Architectures
      • What is an executable architecture?
      • Having developed an executable architecture as part of the architecture description, what use does it serve in the architecture development process?
    • The Next Step
      • Having developed the Architecture Framework and an Architecture Description, how does the architect inform the enterprise systems engineer to build a system that conforms to architectural guidance?
    • A good architecture description effectively and consistently communicates the key aspects of the architecture to the appropriate stakeholders
    © HW Sorenson
  • 38. What aspects should be considered in any architecture development? (continued - 4)
    • An Implementation Approach using the Service-Oriented Architecture Style
      • Do the Use Cases define Actors and their roles?
      • How does the architect start to define services using the Use Cases and the actors that are identified?
      • What is the relationship between services and legacy applications and data sources?
      • What is a service broker and what is the notional SOA structure that enables the future re-use of enterprise-wide services and their composability?
      • What are the notional functions provided by the Enterprise Service Bus?
      • What are Rich Services?
    © HW Sorenson
  • 39. What aspects should be considered in any architecture development? (conclusion)
    • Concluding the Architecture Development
      • What is the simple “C3 Definition” of an architecture?
      • What are general classes of “constraints”?
      • In developing the rich services SOA architecture, where are the constraints, or cross-cutting concerns, implemented?
    © HW Sorenson