Enterprise Architecture (EA) Service-Oriented Architecture (SOA) Web Services Architecture (WSA) NorStella SOA-seminar 30.05.2007 Brian Elvesæter brian.elvesater@sintef.no ICT 1 Outline What is an architecture? Enterprise architecture and enterprise modelling Interoperability Enterprise architecture and SOA Integration, SOA and Web services References ICT 2 What is an architecture? ICT 3 Different kinds of architectures Enterprise architecture Business architecture Conceptual architecture Integration architecture Architecture framework Knowledge architecture Serviceoriented architecture Realisation architecture Functional architecture ICT architecture Logical architecture Information architecture Web services architecture ICT 4 EA – SOA – WSA Enterprise architecture (EA) is the practice of applying a method for describing a current and/or future structure and behaviour for an organization's processes, information systems, personnel and organizational sub-units, so that they align with the organization's core goals and strategic direction. Holistic view of the enterprise and all its important assets. Service-oriented architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. [OASIS 2006] Architectural style for designing (technical) systems. Web services architecture (WSA) intends to provide a common definition for understanding Web services. A Web services architecture involves many layered and interrelated technologies. [W3C 2004] A set of enabling Web technologies for implementing software systems. ICT 5 IEEE Std 1471-2000 IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description of Software- Intensive Systems Adopted September 2000 Architecture definition Structure(s) of a system in terms of components, their externally visible properties, their relations, and the underlying principles Common frame of reference for architectural descriptions Common terminology architecture, architectural description, model, view, viewpoint, system, stakeholder, concern, … ICT 6 The fundamental organisation of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. Mission fulfills influences Environment 1..* is important to 1..* has Stakeholder identifies used to cover selects Viewpoint 1..* Those interests which pertain the system’s development, operation and other aspects that are critical or otherwise important to one or more stakeholders. identifies participates in 1..* conforms to organized by 1..* View participates in has source 0..1 Library viewpoint Rationale The expression of a systems architecture with respect to a particular viewpoint. Addresses one or more of the concerns of the system stakeholder. Architectural description 1..* 1..* Concern provides Architecture described by 1..* is addressed to 1..* has an System inhabits Has interest in, or concerns relative to the system. has 1..* 1..* consists of 1..* aggregates 1..* Model establishes methods for 1..* ICT Developed using the methods established by its viewpoint, consisting of views expressing an architectural description. 7 Architecture of what and for whom? Bus2 Bus3 Bus1 Virtual enterprise Bus4 Decomposition Actor1 EA Actor2 SW syst1 SW syst2 Business Decomposition SOA Comp2 Software system Comp3 Comp1 Comp4 Decomposition WSA Object2 Software component Object3 Object1 Object4 Decomposition Datatype2 Datatype1 Software object Operation1 Datatype3 ICT 8 Enterprise architecture and enterprise modelling ICT 9 History of enterprise architecture The major pioneering efforts: Zachman Framework - initiated 1978 ARIS tool set - 1988 First Metis tool set - 1991 Troux Knowledge Repository - 2002 Four major approaches: Systems development case tools - 1984 IT process modelling - 1986 Product and process modelling - 1989 Business process management - 1995 Enterprise architecture modelling - 1997 ICT 10 Why enterprise architecture? How can I involve my people in improving the performance of the business ? ? How can I use best practices to ensure the success of the business? How can I ensure that the IS technology helps the work of my people? ? ICT 11 Governance with enterprise architecture Architecture is a strategic tool not just high-level design Architecture goes beyond ICT Enterprise architecture is a key component of the IT governance process at any organization of significant size. Stability and flexibility Seem to be contradictory, but a good architecture facilitates change! Communication with stakeholders architects, managers, customers, engineers, … Analysis Enterprise Architecture (EA) is a generic, abstracted and aggregated representation of the core structures and competences of an enterprise. EA supports laying out the main characteristics of the enterprise to be analysed and agreed before detailed technical design is started. It is shared and discussed enterprise-wide between all stakeholders as a common description forms, functions and features, components, properties and relationships. impact-of-change cost and performance ICT 12 Role of enterprise architecture Mission Vision Strategy Goals as is enterprise architecture Actions to be culture leadership domain/aspect architectures products processes people Operations … people IT Mark Lankhorst et al., "Enterprise Architecture at Work: Modelling, Communication and Analysis", Springer, 2005, ISBN: 978-3-540-24371-7. ICT 13 Describing coherence Information architecture Product architecture ? Process architecture ? ? ? Application architecture Technical architecture ? Mark Lankhorst et al., "Enterprise Architecture at Work: Modelling, Communication and Analysis", Springer, 2005, ISBN: 978-3-540-24371-7. ICT 14 Enterprise modelling Enterprise modelling (EM) is a capability for externalising, making and sharing enterprise knowledge. EM tools can either be: used stand-alone to produce various kinds of model views, integrated as front-ends to other systems, part of an environment providing a contextual userenvironment. ICT 15 Enterprise modelling languages Enterprise modelling languages should allow building the model of an enterprise according to various points of view such as: function, process decision, economic, etc. in an integrated way. Languages defined at high level of abstraction as constructs for EM are independent of the technology of implementation Examples are: IEM Metis Enterprise Arcitecture Framework (MEAF) CIMOSA GRAI IDEF PSL WPDL XPDL BPML EDOC BPDM EPC Archimate ICT 16 Enterprise architecture frameworks Enterprises architecture frameworks are fundamental structures which allows defining the main sets of concepts to model and to build an enterprise. Architectural frameworks are designed to define views of specific enterprise domains. Frameworks lack capabilities for Examples are: meta-data management role-driven viewing integration with platforms ZACHMAN GERAM GRAI ARIS CIMOSA DoDAF TOGAF TEAF Troux/Metis/AKM ISO 15745 MISSION model-driven design generation of interoperable solutions ICT 17 Representations of architecture ARIS ZACHMAN GERAM EKA POPS EN/ISO 19439 NIST ATHENA ICT 18 Zachman Framework VA Enterprise Architecture DATA What FUNCTI ON How NETW ORK Where PEOPLE Who TIME When MOTIVATION Why SCOPE (CONTEXTUAL) Things Im portant to the Business Processes Performed Business locations Important Organiz ations Ev ents Significant to the Business Business Goals and Strategy Planner Entity = Class of Business Thing Function = Class of Business Process Node = Major Business Locations People = Major Organiz ations Time = Major Business Event Ends/Means = Major Business Goals ENTERPRISE MODEL (CONCEPTU AL) Semantic Model Business Process Model Business Logistic s System Work Flow Model Master Schedule Business Plan Owner Ent = Business Entity Proc = Business Process Rel = Business Relationship I/O = Business Resources Node = Business Location People = Organization Unit Time = Business Event Link = Business Linkage Work = Work Product Cycle = Business Cycle End = Business Objectiv e Means = Business Strategy SYSTEM MODEL (LOGICAL) Logical Data Model Application Architecture Distributed System Architecture Processing Structure Business Rule Model Designer Ent = Data Entity Rel = Data Relationship Proc = Application Function Node = IS Function People = Role I/O = User Views Link = Line Characteristic s Work = Deliv erable Time = System Event Cycle = Processing Cycle End = Structural Assertion Means = Action Assertion TECHNOLOGY MODEL (PHYSICAL) Physical Data Model System Design Control Structure Rule Design Builder Ent = Segment/Table Rel = Pointer/Key Proc = Computer Function Node = Hardware/Softw are People = User I/O = Data Elements /Sets Link = Line Specifications Work = Screen Format End = Condition Time = Ex ecute Cycle = Component Cycle Means = Action Program Security Architecture Timing Definition Rule Design Data DETAILED REPRESENTATIONS Definition (OUT-OF-CONTE XT) Technology Architecture Netw ork Architecture Human Interface Architecture Presentation Architecture Sub-Contractor Ent = Field Rel = Address Proc = Language Statement Node = Addresses I/O = Control Block Link = Protocols People = Identity Work = Job Time = Interrupt Cycle = Machine Cycle End = Sub-Condition Means = Step FUNCTIONING ENTERPRISE Data Function Netw ork Organiz ation Schedule Strategy Ent = Rel = Proc = I/O = Node = Link = People = Work = Time = Cycle = End = Means = DATA What FUNCTI ON How NETW ORK Where PEOPLE Who TIME When Based on work by John A. Zachman SCOPE (CONTEXTUAL) Planner ENTERPRISE MODEL (CONCEPTU AL) Owner SYSTEM MODEL (LOGICAL) Designer TECHNOLOGY MODEL (PHYSICAL) Builder DETAILED REPRESENTATIONS (OUT-OF-CONTE XT) Sub-Contractor FUNCTIONING ENTERPRISE MOTIVATION Why ICT 19 Enterprise Unified Process (EUP) ICT 20 Interoperability ICT 21 Interoperability research Project type: Network of Excellence (NoE) Web page: Web page: Interoperability Research for Networked Enterprises Applications and Software Project duration: 3 years Project budget: 12.0 M€ EU IST funding: 6.5 M€ Partners/contractors: 50 Start date: Nov 1, 2003 Integrated Project (IP) Full title: Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Applications Project duration: 3 years Project budget: 26.5 M€ EU IST funding: 14.4 M€ Partners/contractors: 19 Start date: Febr. 1, 2004 Full title: www.interop-noe.org Project type: www.athena-ip.org ICT 22 Rationale for interoperability Interoperability is the key to increase competitiveness of enterprises. “Enterprise systems and applications need to be interoperable to achieve seamless operational and business interaction, and create networked organizations” – European Group for Research on Interoperability, 2002 Application integration license revenue System implementation budget Misc. 20% B$ Integration 40% Hardware 10% Imp. Services 20% Software 10% The cost of non-interoperability are estimated to (Source: the Yankee Group 2001) 40% of enterprises IT budget. ICT 23 Knowledge integration The originality of the projects are to take a multidisciplinary approach by merging three research areas supporting the development of Interoperability of Enterprise Applications and Software: Architecture & Platforms: to provide implementation frameworks, Enterprise Modelling: to define Interoperability requirements and to support solution implementation, Ontology: to identify Interoperability semantics in the enterprise. Architectures & Platforms ATHENA & INTEROP Enterprise Modelling Ontology ICT 24 4-layered view of an enterprise Business Operational Architecture Operations Strategy Governance Laws, rules, principles Agreed norms and practices Procedures and routines Business terms Enterprise methodology Enterprise models Enterprise templates Metamodels and languages Product models Reference architectures Semantics Enterprise Knowledge Architecture (EKA) Dictionaries Ontologies Nomenclatures Classifications Information and Communication Technology (ICT) Architecture Business and user services Infrastructure services EKA services Ontology tools Software platforms Modeling tools Management tools Ontology services ICT 25 Holistic approach to interoperability Enterprise A Enterprise B Application ICT Knowledge Application Data Data Semantics Knowledge Business Semantics Business Interoperability (def.) is “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” – IEEE Standard Computer Dictionary Communication To achieve meaningful interoperability between enterprises, interoperability must be achieved on all layers: Business layer: business environment and business processes Knowledge layer: organisational roles, skills and competencies of employees and knowledge assets ICT layer: applications, data and communication components Semantics: support mutual understanding on all layers ICT 26 Enterprise architecture and SOA ICT 27 Motivation for SOA Enterprise ICT Challenges Business agility Flexibility and adaptability Enterprise architecture frameworks + Holistic approach + Different views of an enterprise as related (visual) knowledge models - Current enterprise architectures are only blueprints Challenges Inflexible and difficult to adapt Enterprise application integration (EAI) Service-oriented architecture (SOA) + Architectural style + Loosely coupled systems + Horizontal integration between different business domains + Use case oriented service composition +/- Web services (enabling technology) Requirements Enterprises require operational enterprise architectures ICT solutions must be designed to be inherently interoperable ICT 28 Business and technology alignment Business Services can be seen as business capabilities that support the enterprise. Services usually represent a business function or domain. Services provide the ‘units of business’ that represent value propositions within a value chain or within business processes. Traceability between the service as a business capability and its technical implementation. Services will improve delivery methods that are an integral part of the business product. Technology Modular design Compositions and granularity Services are loosely coupled From compile-time and deployment-time dependencies to run-time dependencies Dynamic discovery and binding Services are standardized (“platform independent”) Standard Internet and Web protocols as the common “glue” to provide “syntactical interoperability” ICT 29 Problems with current EA frameworks User's problems A lot of enterprise architecture proposals on the "market" However, it is usually difficult to understand, compare and choose Researcher's problems There is no justification, nor evaluation of existing enterprise architectures No adequate architecture representation language, too many different views and levels of detail Confusing notions between Enterprise Architecture, Enterprise Model, Enterprise Infrastructure Lack of standardized terminology and collaboration between different EA communities (system engineers, software engineering,…) Engineer's problems There is no "architecture continuity", it is difficult to transform an architecture from conceptual to implementation levels, and vice versa There is no "architecture interoperability", enterprise applications built on different architectures are not interoperable There is no scientific "architecture principles" like we have in the construction or shipbuilding domains, enterprise architecting is still a matter of experience ICT 30 ATHENA's approach to operational EA EA is the holistic expression of the enterprise’s key business knowledge, information, application and technology strategies and their impact on business functions and processes, that: Guides investment strategies and decisions Provides the framework needed to innovate the business Consists of the current targeted Enterprise Knowledge Models (EKMs): EBA: Enterprise Business Architecture EKA: Enterprise Knowledge Architecture EIA: Enterprise information Architecture EAA: Enterprise Application Architecture ETA: Enterprise Technology Architecture Oversees integration across the core architectures that provides a synchronized set of EA artefacts that needs to be created, collected, organized and communicated to enable adaptation to change business and technology Is defined and deployed through the company-wide process councils ICT 31 Enterprise architecture viewpoints Enterprise Business Architecture (EBA) Integrates Across EBA,EKA,EIA, EAA Business Processes • Information Flows (between processes) • People, Teams, RAA • Business Policy & Strategy Enterprise Knowledge Architecture (EKA) Business Information • Information Policy & Strategy Enterprise Application & Architecture (EAA) Applications • Application Data • Data Flows (between Apps) • Application Policy & Strategy (EA) Enterprise Technical Architecture (ETA) IT Platform and Infrastructure • Hardware & OS • SW Services & Middleware • Productivity Apps. • Technical Policy & Strategy ICT 32 From EM to Enterprise Visual Scenes (EVS) Utilizing the powers of visual enterprise knowledge scenes Redefining Enterprise Knowledge Modelling EM is externalizing and sharing enterprise knowledge, developing the enterprise knowledge architecture and enabling EVS. EKM is extending EM by Intelligent Infrastructure and knowledge architectures to support continuous enterprise architecting, business management and more. Four types of views: meta.data, content, functional and context. Different kinds of views to support process roles. Many kinds of diagrams Views have their specific view styles, and dependencies. Views can also be turned into and be models ICT 33 ICT 34 Visual enterprise architecture management Enterprise architecture layers – Integrated by intelligent infrastructures Inter-related reflective views of key roles – replacing frameworks as mosaics of static kinds and types of views (the knowledge legacy from paper carriers) Layers, aspects: Business layer: Methods, models, operations, strategy, governance, … Enterprise Knowledge Architecture (EKA) layer: POPS methods, EIS templates, UEML +++ ICT architecture layer: Services as reusable tasks, servers and EKM repositories Logic and content: Law, rules, principles, agreed practices and norms, day to day routines EKAPOPS User views (types and kinds), Enterprise-models and submodels, Meta-models: Languages, Structures and Type-hierarchies Access services, capabilities to integrate legacy systems, extract data, handle parameterised sub-models ICT 35 POP* dimensions The Process Dimension includes constructs related to activities, tasks and processes going on in the enterprise or between enterprises. The Organisation Dimension focuses on organisational structures, as well as members and positions thereof. Also, focus is set on interaction between structures, both as a whole and between members. The Decision Dimension is concerned with the collection of concepts and constructs that allow describing the decision-making structure in terms of decision centres and decision activities. The Product Dimension is used to model product architectures or product structures, for the purpose of design, development and engineering or product data management. The purpose of the Infrastructure Dimension is to support modelling of infrastructures and the services they provide. ICT 36 Mutually reflective views An object in one view will have reflections in other dimensions Process No orthogonal, layered meta-hierarchy No difference between modelling and metamodelling View connections and dependencies are designed or automatically created Types and kinds of views for each design role A content view for role A may be a definition view or functional view for role B Complex relationships, tasks, decisions Product ICT 37 Enterprise knowledge spaces Enterprise Knowledge Spaces (EKSs) are externalised knowledge spaces of four or more knowledge dimensions that contain mutual and complex dependencies of domains and elements in the four dimensions. ICT 38 Modelling Platform for Collaborative The integrator of all systems Enterprises (MPCE) and provider of new solutions Model-designed and generated working environments supporting concurrent design, planning and execution. Model-generated workplaces with business and user services Modelling tools Administration Modelling support services Services Modelling support Administration services services Repository management services services . POP* POP*enterprise enterprisemodel modelrepository repository Integration Integration Services Services The ICT infrastructure is a platform of software component services. Enterprises’ ICT infrastructures ICT 39 Model-designed and generated Workplaces Modelling clients Client Roles, users, pages, permissions, projects Storage Server Menus Navigation Modules with Web UI - Page editor & runtime - Dynamic forms ed. & runtime - Problem tracker - Document uploader - Simple EKA text browser POP* metamodel New Models MPCE Web Services -update users, projects, roles, -update dynamic forms etc -load, save EKA etc MPCE Server (non-UI) modules -Permissions, users, groups, roles -Projects, portals, menus, navigation -File storage and retrieval -Model transformation services -EKA load, save, merge, etc MPCE Storage - with models as EKA structures -files -internal MPCE data as models Reference models as EKA structures Web Service Enactment -call other systems -return results for viewing File Repository (Blobs) EKA Object repository ICT 40 Integration, SOA and Web services ICT 41 The waves of client/server technology First Wave Second Wave Third Wave Fourth Wave Fifth Wave MDA, Web Services, .Net Server-side Distributed Service-oriented componentsc Objects Architecture J2EE/EJB OMG CORBA SOAP, XML COM+ COM/OLE WSDL/WSFL Corba Comp Web/Internett Agents, P2P Java File Servers FIPA 1982 1986 1990 1994 Grid 1998 1999 2000 2001 2002 2003 Base Source: Client/Server Survival Guide, 1994 Robert Orfali, Dan Harkey OS/2 Edition, VNR Computer library + AJB update 2004 ICT 42 Web service Web service “Applications identified by a URI, whose interfaces and bindings are capable of being defined, described and discovered as XML artefacts. A Web service supports direct interactions with other software agents using XML-based messages exchanged via Internet-based protocols.” (W3C) http://www.w3.org/ SOA ~ architectural style Web services stack ~ technology/protocol standards SOA =/= Web services ICT 43 Web services architecture Web services can be used to implement serviceoriented solutions They adhere to the set of roles and operations specified by the service oriented model. They have also managed to establish a standardized protocol stack. ICT 44 WS-* stack to-be Simplified version of the to-be WS-* stack Families of related specs not expanded Competing spec families not shown “Historical” or abandoned specs not shown WS-Addressing WS-Notification WSDL SOAP WS-Coordination XML WS-Security BPEL WS-CDL WS-Federation UDDI WS-Policy WS-ReliableMessaging WS-MetadataExchange WS-Resource WS-Transfer ICT 45 WS-* stack as-is Complete version of the as-is WS-* stack The 3 widely-accepted specs today are the same as 5 years ago BPEL and WS-Security is gaining momentum Orchestration, discovery and brokering do not exist in today’s world WS-Addressing WS-Notification WSDL SOAP WS-Coordination XML WS-Security BPEL WS-CDL WS-Federation UDDI WS-Policy WS-ReliableMessaging WS-MetadataExchange WS-Resource WS-Transfer ICT 46 Application architecture vs. SOA Segmented business areas a Collaborative business areas b c SOA r x s x y1 y2 Application architecture r a y s b y t c z t z a r b x t c s z z y Service-oriented architecture (SOA) ICT 47 SOA and integration Fundamental change for integration: X <-> Y Pre-SOA: outside, after development Post-SOA: inside, integral part of development / computational model Consequences How should integration be done? Innovation and experience Competition, expansion, consolidation Not understood: IDC Directions 2006 (3/2/06): SOA important but not understood or deployed as claimed Gartner (2/15/06): “Globally, organizations placing minor emphasis on understanding the role of data integration in SOA and creation of data services at the foundation of their architectures” ICT 48 History of integration 1950 – 2006: Integration = develop then integrate 1950s-1970s: Simple, manual integration 1970s-1980s: Distributed Computing Applications (interoperation) Databases (integrate) 1990s: Business Driven Integration – concepts, technologies, and tools – increased automation, internet-based computing Concepts: Workflows, Processes, Web, Integration solutions blossom (diverge): ETL, EAI, BPM, … 2000: SOA Emerges 2000: Web services 2003: Integration solution evolution accelerates, vendor chaos ensues 2005: Growth in all integration categories ICT 49 Integration in SOA 2006 – 2012: Integration = dominant programming model 2001-2010: Wrapping 2005-2010: Re-Engineering 2006-2008: Consolidation 2006-2008: Research on Semantic SOA 2007-2012: Emergence of SOA Platforms and Solutions 2006-2012: Problem Solving Era: IT/integration relegated to low level function ICT 50 ICT 51 SOA platform consolidation Data and information integration ➪ Information Fabric EII: Enterprise information integration ETL: Extract, transform and load Application integration ➪ Integration Suite EAI: Enterprise application integration B2Bg: Business-to-business gateway ESB: Enterprise service bus Applications and Processes ➪ Business Process Management Suite BPM: Business process management B2Bi: Business-to-business integration Enterprise workplace ➪ Interaction Platform ICT 52 ICT 53 Integration suite services Goal: Composite applications Components: EAI, BPM, B2B, B2Bi Extensions: Adapter, collaboration, analysis, reporting, development, monitoring, contracts, SOA standards, … ICT 54 Business process management suite & interaction services Goal: Continuous process improvement Components: BPM human-centric: people-intensive processes Integration-centric: system-intensive processes ICT 55 Information fabric services Goal: Holistic view of data (information virtualisation) Components: DBMS, EII + ETL + replication Extensions: Distributed meta-data repository, distributed data access, integrated data management ICT 56 Trends Consolidation ➪ comprehensive platforms Merging of Human Workflow and System Orchestration/Process services Integration of Business Rules Engines Support for Event Notification services (publish and subscribe) Integration of Model-generated workplaces and role/taskoriented user interfaces, user interaction services, portals, and multi-device interfaces Explicit use of models (Enterprise and System) Enterprise architecture + SOA ICT 57 References ICT 58 References [ATHENA] ATHENA, "ATHENA Home Page", ATHENA IP. http://www.athena-ip.org/ [DnD] DnD, "Faggruppen for applikasjonsintegrasjon – metoder og arkitektur", Den norske dataforening (DnD). http://www.dnd.no/ [Elvesæter, et al. 2005] B. Elvesæter, R. K. Rolfsen, F. Lillehagen, and D. Karlsen, "Integrated Enterprise Service Architecture", in Proc. of the 12th ISPE International Conference on Concurrent Engineering (CE 2005), Fort Worth, Texas, USA, 2005, M. Sobolewski and P. Ghodous (Eds.), International Society for Productivity Enhancement, Inc., NY, USA, pp. 129-134. [INTEROP] INTEROP, "INTEROP Home Page", INTEROP NoE. http://www.interop-noe.org/ [Lillehagen, et al. 2005] F. Lillehagen, D. Karlsen, H. G. Solheim, H. D. Jørgensen, H. Smith-Meyer, B. Elvesæter, and R. K. Rolfsen, "Enterprise Architecture - from Blueprints to Design Services", in Proc. of the 12th ISPE International Conference on Concurrent Engineering (CE 2005), Fort Worth, Texas, USA, 2005, M. Sobolewski and P. Ghodous (Eds.), International Society for Productivity Enhancement, Inc., NY, USA, pp. 121-128. [NESSI] NESSI, "Networked European Software & Services Iniative (NESSI)". http://www.nessieurope.eu/Nessi/ [OASIS 2006] OASIS, "Reference Model for Service Oriented Architecture 1.0", OASIS, OASIS Standard, 12 October 2006. http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf [W3C 2004] W3C, "Web Services Architecture", World Wide Web Consortium (W3C), W3C Working Group Note, 11 February 2004. http://www.w3.org/TR/ws-arch/ ICT 59