© HW Sorenson Architecture-based Enterprise Systems

AESE

© HW Sorenson

Architecture-based Enterprise Systems Engineering (AESE)

An Emerging Graduate Program at the

University of California, San Diego

http://aese.ucsd.edu

Joint Program of the Jacobs School of Engineering and the

Rady School of Management

AESE

© HW Sorenson

The AESE Process

People

Organization

Architecture-based

Enterprise

Systems Engineering

(AESE)

The AESE Structure

Technology

AESE

© HW Sorenson

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

AESE

© HW Sorenson

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

* After Maier, Sage, Levis…

AESE

© HW Sorenson

Return to the Basics of Systems Thinking1

• Operational definition of a “systems methodology” involves three interdependent variables – Structure– Function– Processthat, 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

1 Gharajedaghi, Jamshid, Systems Thinking: Managing Chaos and Complexity, Butterworth Heineman, 1999

AESE

© HW Sorenson

Return to the Basics of Systems Thinking1

• Operational definition of a “systems methodology” involves three interdependent variables – Structure– Function– Processthat, 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

This methodology provides the basis for all of the program offerings

1 Gharajedaghi, Jamshid, Systems Thinking: Managing Chaos and Complexity, Butterworth Heineman, 1999

AESE

© 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

Evolution of Systems Thinking

SHIFTOF

PARADIGM

Mindless System

Machine Model

Uniminded System

Biological Model

Multiminded System

Social Model

Analytical Approach

Systems Approach

Interdependent Variables

Independent Variables

InterchangeabilityOf

Parts & Labor

Henry Ford’s Mass Production System

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

Purposeful1. Society2. Organization3. Members

Social systems are information-bonded

Choice

Reductionist

AESE

© HW Sorenson

ContextProblem

FormulationSolution 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

StructureProcess

Strategy

AESE Program Fundamentals

DesiredCapabilities

AESE

© HW Sorenson

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”

AESE

© HW Sorenson

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

The concepts and ideas stemming from the study of complex adaptive systems provide the foundation for the AESE Program.

AESE

© HW Sorenson

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

Build the complex enterprise system by introducing changes that can be implemented in days or weeks, not years or decades

AESE

© HW Sorenson

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”

AESE

© HW Sorenson


• 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

AESE

© HW Sorenson


• 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)

AESE

© HW Sorenson

AESE Process, Structure, and Function

AESE

© HW Sorenson

EVOLVEENTERPRISE

ARCHITECTURE

DETERMINECAPABILITY

NEEDS

IDENTIFYCAPABILITY

STAKEHOLDERS

SELECTCAPABILITY

USE CASES

DEFINEOUTCOME

SPACE

DEVELOPPOTENTIALCAPABILITYSOLUTIONS

PERFORMGAP

ANALYSIS

SELECT PILOT

PROJECTS

EVOLVEENTERPRISE

INFRASTRUCTURE

PRIORITIZECAPABILITYSOLUTION

ESTABLISHDEVELOPMENTENVIRONMENT

CURRENT CAPABILITIES

AESE Agile Development Process

STRATEGIC DRIVERSDEVELOPENTERPRISESTRATEGY

CONTINOUS INTERACTION

SPACE

AESE

© HW Sorenson

EVOLVEENTERPRISE

ARCHITECTURE

DETERMINECAPABILITY

NEEDS

IDENTIFYCAPABILITY

STAKEHOLDERS

SELECTCAPABILITY

MISSION THREADS

DEFINEOUTCOME

SPACE


PERFORMGAP

ANALYSIS

SELECT PILOT

PROJECTS

EVOLVEENTERPRISE

INFRASTRUCTURE




AGILEDEVELOPMENT




SPACE

EnterpriseLevel

StakeholderLevel

Architect Level

Feedback

Outcome

Space

Enterprise Systems Engineer

Level

AESE

© HW Sorenson

Feedback

Enterprise Systems Engineer

Level

Architect Level

StakeholderLevel

EnterpriseLevel

EVOLVEENTERPRISE

ARCHITECTURE

DETERMINECAPABILITY

NEEDS

IDENTIFYCAPABILITY

STAKEHOLDERS

SELECTCAPABILITY

USE CASES

DEFINEOUTCOME

SPACE


PERFORMGAP

ANALYSIS

SELECT PILOT

PROJECTS

EVOLVEENTERPRISE

INFRASTRUCTURE




AGILEDEVELOPMENT




SPACE

Outcome

Space

Which can be redrawn as the fundamental structure shown in the next chart

AESE

© HW Sorenson

The AESE StructureThe Enterprise

EnterpriseNeeds

EstablishingEnterprise

Goals

Leadership

EnterpriseDrivers

Developing Enterprise Needs &

Investment Strategy

Management

Policy & Planning

Architectural Guidance

AssessingPerformance

Management

GapAnalyses

Deficiency &

GapAnalysis

Decision Support

Business Operations

Inputs to Leadership and DecisionRecommendations

EnterpriseKnowledge System

The AESE Function

Enterprise & Product Systems Engineering

Engineering The

Enterprise

ESE

EngineeringNew

Systems

PSE

CII

Enterprise Architecting

EvolvingThe

Architecture

Architect

Complying&

Conforming

Governance

Architecture

AESE

AESE

© HW Sorenson

Summary of the AESE Program

AESE

© HW Sorenson

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”

AESE

© HW Sorenson

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

AESE

© HW Sorenson

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

AESE

© HW Sorenson

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

AESE

© HW Sorenson

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

AESE

© HW Sorenson

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)

AESE

© HW Sorenson

Schedule

AESE

© HW Sorenson

The Enterprise

Business Operations

Policy & Planning Enterprise Architecting

EnterpriseNeeds

EvolvingThe

Architecture

Architect

Complying&

Conforming

Governance

Architecture

Enterprise Systems Engineering

Engineering The

Enterprise

ESE

EngineeringNew

Systems

PSE

CII

ArchitecturalGuidance



Management

EKSNeeds

Deficiency &

GapAnalysis

Decision Support



Goals

Leadership

EnterpriseDrivers Developing

Enterprise Needs &

Investment Strategy

Management

AESE

The AESE Fall Quarter CoursesCourse 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, …

AESE

© HW Sorenson

The Enterprise

Business Operations


EnterpriseNeeds

EvolvingThe

Architecture

Architect

Complying&

Conforming

Governance

Architecture


Engineering The

Enterprise

ESE

EngineeringNew

Systems

PSE

CII




Management

EKSNeeds

Deficiency &

GapAnalysis

Decision Support



Goals

Leadership


Enterprise Needs &

Investment Strategy

Management

AESE

The AESE Winter Quarter Courses

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, …

AESE

© HW Sorenson

The Enterprise

Business Operations


EnterpriseNeeds

EvolvingThe

Architecture

Architect

Complying&

Conforming

Governance

Architecture


Engineering The

Enterprise

ESE

EngineeringNew

Systems

PSE

CII




Management

EKSNeeds

Deficiency &

GapAnalysis

Decision Support



Goals

Leadership


Enterprise Needs &

Investment Strategy

Management

AESE

The AESE Spring Quarter CoursesCourse 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, …

AESE

© HW Sorenson

AESE Leadership Program Completion

Team Project Final Preparation

September 9 TuesdaySeptember 10 Wednesday

Final Team Project PresentationsSeptember 11 ThursdaySeptember 12 Friday

Summer Quarter (July- September, 2008)

AESE

© HW Sorenson

The AESE Process

People

Technology

Organization

Architecture-based

Enterprise

Systems Engineering

(AESE)

AESE

© HW Sorenson

Fundamental Questions That Must Be Answered in the

Final Team Project Presentation

AESE

© HW Sorenson

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?

AESE

© HW Sorenson

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

AESE

© HW Sorenson

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

AESE

© HW Sorenson


• 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

AESE

© HW Sorenson


• 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?

AESE

© HW Sorenson

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?

Documents

© HW Sorenson Architecture-based Enterprise Systems