Architecture-based Enterprise Systems Engineering AESE

1. � HW Sorenson Architecture-based Enterprise Systems Engineering (AESE) An Emerging Graduate Program at the University of California, San Diego

2. � HW Sorenson

3. � 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

4. � 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

5. � HW Sorenson Return to the Basics of Systems Thinking1 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

6. � HW Sorenson Return to the Basics of Systems Thinking1 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

7. � HW Sorenson Evolution of Systems Thinking

8. � HW Sorenson

9. � 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�

10. � 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

11. � 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

12. � 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�

13. � HW Sorenson 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

14. � HW Sorenson 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)

15. � HW Sorenson AESE Process, Structure, and Function

16. � HW Sorenson

17. � HW Sorenson

18. � HW Sorenson

19. � HW Sorenson The AESE Structure

20. � HW Sorenson Summary of the AESE Program

21. � 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�

22. � 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

23. � 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

24. � 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

25. � 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

26. � 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)

27. � HW Sorenson Schedule

28. � HW Sorenson The AESE Fall Quarter Courses

29. � HW Sorenson The AESE Winter Quarter Courses

30. � HW Sorenson The AESE Spring Quarter Courses

31. � HW Sorenson AESE Leadership Program Completion

32. � HW Sorenson

33. � HW Sorenson Fundamental Questions That Must Be Answered in theFinal Team Project Presentation

34. � 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?

35. � 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

36. � 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

37. � HW Sorenson 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

38. � HW Sorenson 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?

39. � 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?