Information System Architecture

Information system The data is the raw material of any I.S. Before becoming information, the data must be created, stored, processed, analyzed and distributed. Information systems can be characterized by their functions: the generation, storage, presentation, exchange, interpretation, transformation, and transportation of information.

An application-centric view of IS Applications, developed independently of each other, provided functionality that can only be used within the boundaries of each application. Differences between platforms, programming languages, and protocols created technology boundaries that are not easy to cross. As a result enterprises lost the flexibility the agility they need in the marketplace; IS stopped being part of a solution and became more of a problem; enterprises ISs locked them into specific ways of, and created barriers to, carrying out Business.

Architecture Design 1/3 “An architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.” IEEE STD Is used to:  Make buy decisions.  Discriminate between options.  “Discover” the true requirements.  Drive one or more systems to a common “use” or purpose.  Develop system components.  Build the system.  Understand and conduct changes in the system as the BP is modified.

Architecture Design 2/3 It focuses on the creation of new systems designed to play a role in some business environments. A key factor is the systematic, controlled and coordinated development of systems’ components and the ability to keep overview over the complexity of the system. The way to do this is to use models to describe parts or aspects of a system. A set of models that together define the essentials of a system is called the architecture of the system. The architecture of a system plays different roles, in the development process and during the life cycle of a system.

Architecture Design 3/3 Besides the development of totally new systems it becomes more and more important to consider the renewal or renovation of existing systems. This requires different approaches and introduces new challenges. One of the major issues is that the systems engineers have to understand the system that has to be renovated. An existing system puts extra constraints on the development of new parts which makes renovation different from development from scratch.

Architecture Framework “An architecture framework is a tool… It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.” [TOGAF 8, OpenGroup]TOGAF 8, OpenGroup

Enterprise engineering Resources management, enterprise organization, production management.

Business Management Economiy, cognitive, trust management… etc.

Computer science Information system, decision making systems…etc.

Architecture Products: Graphic, Textual, and Tabular… Organizations Locations Functions Applications Entities Database/file Technology Platforms Organizations Locations Functions Applications Entities Database/file Tech Platform X X XX X X X X X X X GraphicTextDictionary Relationships Communicate Capture Analyze Use products to: Tabular Systems Node Name System Name System Function Name System Component Name Operational Node Name Operational Activity Link Name/ID Needline Name Component Interface Name

Enterprise competitive edge An enterprise’s competitive edge and ultimate success are enabled by its ability to rapidly respond to changing business strategies, governance, and technologies. The competitive edge translates into higher levels of customer satisfaction, shorter work cycles, and reductions in schedules, maintenance costs, and development time, all resulting in lower overall cost of ownership.

Enterprise Architecture Enterprise Architecture is the key facilitating ingredient providing a holistic view and a mechanism for enabling the design and development as well as the communication and understanding of the enterprise. The goals of enterprise architecture are to manage the complexity of the enterprise, align business strategies and implementations, and facilitate rapid change in order to maintain business and technical advantages. IS Enterprise Architecture is like urban planning.

City planning metaphor

Urban planning …..What!!? Consists of cutting out IS in autonomous modules, of more and more small size, in a way similar to the city. Between these modules we establish zones of information exchange, which render possible to decouple the various modules.

Urbanisation: the goal? They can be evolved/removed separately while preserving their ability to:  Interact with the remainder of the system.  Replace some of these subsystems (inter- changeability).  Guarantee the possibility to integrate subsystems of various origins (integration).  Strengthen the capability to interact with others ISs (Interoperability).

Important rules of Urbanisation The autonomy of functional system’s components. The crosscutting nature of the functionalities applied on all system components should be thought to provide an end to end homogenous solutions. Avoiding the “spaghetti” effect in the enterprise’s information system. These principles enable the agility of the information system to align with the changes in the enterprise organisation and strategy entrained by markets’ changes.

Urbanization, the what and why? City planning metaphor: How to re-organize or evolve a city while keeping a normal life for city’s inhabitants during the construction or re- construction? In the same way: how to re-organize the IS without totally destroying the existing applications and while maintaining IS functionalities during the re-construction; IS must be reorganized to facilitate its evolution while protecting its informational legacy.

Urbanisation : what else?  Allows establishing the link between: mission of the organization, exchanges, internal and external actors, business event, business process, information, applications and infrastructure.  Provide a complete description of IS on functional, organisational and technical levels.  Being a decision-making support tool to understand change impacts during the evolutions (business, functional, applicative, and technical).

Non-Urbanized City 

Urbanized city

Non-Urbanized IS 

Urbanized IS

Multilayer approach

Multilayer approach! The methodology is based on a reference framework integrating four views from the information system:  Business view: it describes all the business activities of the enterprise that the information system must support.  Functional view: it describes the information system functions which support the business process.  Applicative view: it describes all the applicative elements of a data processing system.  Technical view: it describes all the hardware, software and technologies used to support the functionality of the information system.

Ishikawa diagram The strategy is modelled by a hierarchy of goals represented by ISHIKAWA diagrams, breaking up them into sub-objectives until reaching the lower level in which all the objectives are achieved by at least one process. This diagram is constrained by the following rules (urbanisation rules for the diagram of objectives):  The same objective appears once and only once in the diagram.  If an objective is divided in sub-objectives the list of those must be exhaustive.  An objective of the lower level must be associated to one or more of performance indicators.

Urbanisation and strategy

Tiré des cours: C. Costaz Urbanisation and BP

Tiré des cours: C.Costaz Urbanisation Modeling

Support Monitoring and Governance Operational processes Processes Identification

Tiré des cours: C.COSTAZ Urbanisation Business Functions

Urbanization rules IS urbanization initiative should satisfy the following rules: Affiliation: in the hierarchical decomposing of an information system, each component belongs to one and only one unit. Autonomy: no dependency should exist between units; a unit can deal with an Event from start to end, without the need for treatment in another unit. Asynchronism: a unit can handle an event and send the result without waiting for the response from the receiver. Data Normalization: the results produced by each unit are based on recognized standards. Single Exit Point: the information in each unit is sent by a single point. Data Ownership: each unit is responsible for its own data; updates of these data are carried out by each individual unit. Passage Point: units communicate indirectly via an Entity which is responsible for data flow management.

Service Oriented Architecture Today, component based development is considered to be the most promising way of developing information systems. The idea is instead of constructing the software from scratch; we achieve a selection, re-configuration and assembly of existing components. Of course there is always a need for new components. The idea is to reuse existing components to compose different functions using particular mechanisms in order to satisfy specific needs of a given business domain or environment.

What is SOA? Applications must open up their capabilities for use by other existing/new applications. It must be possible to combine the services offered by different applications to create higher-level services or composite applications. Technology differences must not matter; interoperability must be a key goal. Open standards must be adopted to enable integration across enterprises. Attention must be paid to governance and manageability in order to make sure that flexibility granted by the first three principles does not lead to chaos.

What is SOA? Services: distinct units of loosely coupled technical or business functions, which can be distributed over a network and can be invoked, combined and reused to create new business processes. These services communicate with each other by passing messages from one service to another, and by coordinating their activities using an orchestrator. Orchestrator: a part of the middleware assembling published services and coordinating their interactions into business flows.

SOA principals?  The use of explicit implementation-independent interfaces to define services (adaptors).  The use of communication protocols that stress location transparency and interoperability.  The definition of services that encapsulate reusable business function.

Middleware!

Middleware capabilities Security. Transformation (Data). Mediation (functional and semantic). Routing. Monitoring. Tracing. End to end QoS. Searching and matching. Invocation.

Middleware

Middleware!

What qualifies as a service? A service is defined at the right level of granularity, from the point of view of a service consumer. A service is discoverable. Consumers looking for a service can discover its presence, usually by looking up a service registry (as la the yellow pages in a phone directory). A service is self-describing. Potential consumers can learn by themselves how to invoke the service. A service is technology-agnostic. Potential consumers are not constrained from using the service because of a mismatch in hardware or software platforms. A service can be composed with other services to create a higher- level service.

SOA « typical » standards UDDI: Universal Description, Discovery and Integration. WSDL: Web Services Description Language. SOAP: Simple Object Access Protocol.

ServicesServices Services directory (UDDI) Seache a service service Invocation 2 - HTTP Get 3 – WSDL (encapsulaed in a SOAP) service Publication Client Service Provider 4 - request “Soap” 5 - response “Soap” 1

Composite service I want to pass tow weeks in a cold, dry, not very far, and cheap country with a lot of touristy views geographic Info. touristy Info. Weather Info. Plane tickets Hotels Car rental Services Travel Agency ?

What is UDDI Stands for Universal Description, Discovery and Integration. UDDI is a directory for storing information about web services. UDDI is a directory of web service interfaces described by WSDL. UDDI communicates via SOAP.

How can UDDI be Used? If the industry published an UDDI standard for flight rate checking and reservation, airlines could register their services into an UDDI directory. Travel agencies could then search the UDDI directory to find the airline's reservation interface. When the interface is found, the travel agency can communicate with the service immediately because it uses a well-defined reservation interface.

WSDL Web Services Description Language. Written in XML. Used to describe and to locate Web services.

The main structure of WSDL It contains set of definitions to describe a service. A WSDL document describes a web service using these major elements: The operations performed by the web service. The messages used by the web service. The data types used by the web service. The communication protocols used by the web service.

WSDL Ports The element is the most important WSDL element. It defines a web service, the operations that can be performed, and the messages that are involved in these operations. The port defines the connection point to a web service. It can be compared to a functions library in a traditional programming language(or a class in OO language). Each operation can be compared to a function in a traditional programming language.

WSDL Messages The element defines the data elements of an operation. Each message can consist of one or more. Parts can be compared to the parameters of a function call in a traditional programming language.

WSDL Types The element defines the data type that are used by the web service. For maximum platform neutrality, WSDL uses XML Schema syntax to define data types.

Example

In this example element defines " VoyageDirectory " as the name of a port, and " getVoyage " as the name of an operation. The "getTerm" operation has an input message called "getVoyageRequest " and an output message called " getVoyageResponse ". The elements define the parts of each message and the associated data types. Compared to traditional programming, "VoyageDirectory" is a functions’ library, "getVoyage" is a function with "getVoyageRequest" as the input parameter and "getVoyageReponse" as the return parameter.

Operation Types One-way: The operation can receive a message but will not return a response. Request-response: The operation can receive a request and will return a response. Solicit-response: The operation can send a request and will wait for a response. Notification: The operation can send a message but will not wait for a response

One-Way Operation An example: In this example the port " newVoyageValues " defines a one-way operation called "setVoyage". The " setVoyage " operation allows input of new voyage items messages using a "newVoyageValues" message with the input parameters “Date“,“Destination“ and “ Price“. However, no output is defined for the operation.

WSDL bindings (1) Defines the message format and protocol details for a service, example binding to SOAP a request-response operation : <soap:binding style="document“ transport=" />

WSDL bindings (2) The binding element has two attributes - the name attribute and the type attribute. The name attribute (you can use any name you want) defines the name of the binding, The type attribute points to the port for the binding, in this case the "VoyageDirectory " port. The soap:binding element has two attributes - the transport attribute and the style attribute.  The transport attribute defines the SOAP protocol to use. In this case we use HTTP.  The style attribute defines the message style, it can be "rpc" or "document". In this case we use document. The operation element defines each operation that the port exposes. For each operation the corresponding SOAP action has to be defined. You must also specify how the input and output are encoded. In this case we use "literal".

SOAP 1. SOAP is transport neutral; SOAP can be used across HTTP, FTP, SMTP …etc. 2. SOAP includes a whole stack of “composable” WS-* specifications; WS- Security for inserting security tokens into SOAP headers, WS-ReliableMessaging, WS- Transactions, ….etc.

SOAP Used for both Messaging and RPC Simple structure  Envelope  Header (optional)  Body

The SOAP Header Element The optional SOAP Header element contains application specific information (like authentication,) about the SOAP message. If the Header element is present, it must be the first child element of the Envelope element. The SOAP mustUnderstand attribute can be used to indicate whether a header entry is mandatory or optional for the recipient to process. If you add "mustUnderstand="1" to a child element of the Header element it indicates that the receiver processing the Header must recognize the element. If the receiver does not recognize the element it must fail when processing the Header.

The Actor Attribute A SOAP message may travel from a sender to a receiver by passing different points along the message path. Not all parts of the SOAP message may be intended for the ultimate endpoint of the SOAP message but, instead, may be intended for one or more of the endpoints on the message path. The SOAP actor attribute may be used to address the Header element to a particular endpoint.

The SOAP Body Elements The SOAP Envelope element is the root element of a SOAP message. It defines the XML document as a SOAP message. It should always have the value of: The required SOAP Body element contains the actual SOAP message intended for the ultimate endpoint of the message.

SOAP over HTTP An HTTP client connects to an HTTP server using TCP. Client sends an HTTP request message to the server, example: POST /item HTTP/1.1 Host: Content-Type: text/plain Content-Length: 200 The server then processes the request and sends an HTTP response back to the client. The response contains a status code that indicates the status of the request: 200 OK Content-Type: text/plain Content-Length: Or: 400 Bad Request Content-Length: 0

SOAP/HTTP Binding A SOAP request could be an HTTP POST or an HTTP GET request SOAP=HTTP + XML, example: POST /login.ispatu-ryukyus, HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length:1000 > Layth Okinawa ……………..

Prescribes Standards and Conventions StandardsRules Conventions Technical Standards View DoDAF An Integrated Architecture with Three Views Information Flow Operational Elements Activities/ Tasks Identifies What Needs To Be Done And Who Does It Operational View Systems Data Flow Communications X Y X Z X Y Y Relates Systems and Characteristics to Operational Needs Systems View

DODAF Products The DODAF describes a set of 26 work products to ensure uniformity and standardization in the documentation and communication of architecture The 26 DODAF views are designed to document the entire architecture, from requirements to implementation

DODAF Products - Views The list of products is refined into four views:  All Views (AV): is the overarching information describing the architecture plans, scope, and definitions  Operational View (OV): focuses on the behaviours and functions describing the enterprise mission aspects  System View (SV): describes the system and applications supporting the mission functions  Technical Standards View (TV): describes the policies, standards and constraints

DODAF Products

DODAF Products - Essential The current DODAF version indicates a subset of work products that should be developed at a minimum (essential) AV-1: Overview and Summary Information AV-2: Integrated Dictionary OV-2: Operational Node Connectivity Description OV-3: Operational Information Exchange Matrix OV-5: Operational Activity Model SV-1: System Interface Description TV-1: Technical Standards Profile

AV-1 & AV-2

OV-2 – Operational Node Connectivity Description

OV-3 – Operational Information Exchange Matrix Table Headers Specified in Framework:  Name of Operational Needline Supported (from OV-2)  Name of Information Exchange  Nature of Transaction (Mission/Scenario, Language, Content, Size/Units, Media, Collaborative or One-Way?)  Purpose or Triggering Event  Information Source (ID of Producing Node Element, Owning Organization of Node, Name of Producing Activity, UJTL ID)  Information Destination (ID of Receiving Node Element, Owning Organization of Node, Name of Receiving Activity, UJTL ID)  Performance Requirements (Frequency, Timeliness, Throughput, Other)  Information Assurance Attributes (Classification Restrictions, Criticality/Priority, Integrity Checks Required, Assured Authorization to Send/Receive)  Threats (Physical, Electronic, Political/Economic)  Operational Environment (Weather, Terrain, Policy/Doctrine Constraints)

OV-5 – Operational Activity Model

SV-1 – System Interface Description

TV-1 – Technical Standards Profile

To be continued……. 83