Interoperability and Service Oriented Architecture an Enterprise Architect's approach

Transcription

1 Interoperability and Service Oriented Architecture an Enterprise Architect's approach Peter Bernus and Ovidiu Noran 1 Griffith University, Nathan (Brisbane) Queensland 4111, Australia P.Bernus@griffith.edu.au, O.Noran@griffith.edu.au Abstract. The paper presents a business model for creating and sustaining networked organisations, as well as the principles, policies, processes and information deemed necessary to achieve interoperability. The business model not only includes business units, but also the supporting infrastructure, business- and technology development programmes, as well as projects to perform the developments needed to achieve intra- and inter-organisational interoperability. In particular, the conditions are discussed under which a service oriented architecture (SOA) approach can support interoperability, applied both as an organisational design principle and as a way to structure the IT infrastructure. Finally, the forces that limit the use of this approach are also mentioned. Keywords: Interoperability, Service Oriented Architecture, Enterprise Architecture. 1 Introduction Interoperability as a condition has always been necessary for business, and the concept itself is not related to information technology. The authors define interoperability as the ability of two entities to access, exchange, and correctly interpret information provided to one another. Effectively this condition allows two entities to jointly participate in business processes and thus act together (or interoperate). If entities (companies) want to exchange information through automated means then there is an obvious need for technical interoperability (with the associated multitude of standards in the multi-layered stack of communication) however, correct interpretation is only possible if the structure and the meaning of the exchanged information is mutually known (which is the condition called semantic interoperability [1]). The existence of languages and techniques to define standards for technical and semantic interoperability is only an enabler because the conditions for interoperability need to be created through social and business intentions, and sometimes through legislation. There are forces in business and government that favour the development of interoperability standards (e.g. without interoperability standards certain markets would not be able to exist), but competitive forces can also

2 work against interoperabilty, because the lack of interoperability can exclude entrants to markets and can be a protection of monopolies and work against the interests of Small and Medium sized Enterprises. Therefore, a generic business model that defines the scope of the interoperability problem also needs to include the roles of government (regulatory bodies) and industry associations. For a considerable amount of time practitioners concentrated on the technical aspects of interoperability (including semantic interoperability), and kept predicting practically the same breakthrough results every five years or so. However, the social and business conditions have not been addressed with equal vigour, and it is only recently that these conditions (and what to do about them) have been given serious attention. For the reasons given above, this article develops a dynamic business model that maps the scope of the interoperability problem and gives equal coverage to technical, business and regulatory aspects. 1 (a) 1. Identification (a) of the entity and its role in the business 2 (b) 2. The Concept of the entity: Mission, vision, strategic objectives, policies, principles and values (b) (c) 3 (e) (m) (i) 4 (k) (g) (d) (f) (j) (n) (h) (l) 3. Requirements (functional and non-functional, such as resource capability, reliability, availability, cost, size, location, etc): - Definition of the (c) mission fulfilment tasks, and (d) management and control tasks of the entity and associated non functional reqs. - Requirements specification of (e) the entity s mission fulfilment, and of (f) management & control (complete and consistent statement of functions, information, and non functional requirements for resources and the organisation of the entity) 4. Preliminary (or Architectural) design: definition of structure of the entity and a mapping of this structure to the requirements specification - Human roles (competencies, skills) in (g) mission fulfilment, and (h) management & control - Human roles (instructions, policies & procedures) in (i) mission fulfilment and (j) management & control - Hardware components (manufacturing, logistics, info and communicationn technology) for (k) mission fulfilment, and (l) management & control - Software components (application programs, database schemata, control software) of the above: (m) for mission fulfilment, (n) for management and control Fig. 1. Entity Life Cycle scope (from Identification to Architectural design) (cf ISO1504:2000)

3 2 Generic Business Model for Networked Organisations The Business Model proposed below is of a special type: entities are represented together with their life cycle and life cycle relationships. The life cycle representation follows ISO15705:2000 [2] / GERAM [5],. According to this standard the life cycle consist of life cycle activity types identification, concept definition, requirements definition, preliminary design, detailed design, implementation (release into operation), operation and decommissioning. There is no implication that this list of activities is performed in the above temporal order (in fact feedback loops exist among these activity types). Note that the way instances of these activity types are performed in time can be represented on the timeline (for example using a GANTT chart.) Figure 1 represents the scope of life cycle activities of an entity and it will be important to read any subsequent figures (Fig 2., etc) with this scope coverage in mind. (NB the scope of the life cycle diagram is not explicitly illustrated in Fig.1 for the detailed design, release to operation, operation and decommissioning phases, but this detail is available for the interested reader in ISO15704:2000). The scope of Identification is the definition of the entity and its role in the business (why it exists, what it does). The Concept definition of the entity must describe: the mission of the entity (what is it that the entity is intended to deliver to its customers), the vision of the entity (if there is a future imagined state of the entity then it needs to be described together with the reason why it is necessary to achieve that state). Furthermore, the Concept definition must include strategic objectives consistent with the vision, as well as policies, principles and values that guide choices in the future development of the entity. Some of the latter can be externally controlled, meaning that the entity does not have a choice whether to adopt them or not (e.g. relevant legislation, social rules, etc), while some others are internal in the sense that it is the entity s choice to adopt them (compliance with some industry standards, human resource principles, manufacturing-, logistic- and information technology principles, financial / asset management principles, process principles, etc). Requirements definition extends to two kinds of requirement statement: the definition of the tasks of the entity and the requirements specification of the entity. What is being called here the tasks of the entity covers both service tasks and management & control tasks, and each of these need to include functional requirements as well as non-functional requirements (such as resource capability, reliability, availability, cost, size, location, etc). The requirements specification of the entity is a complete and consistent statement of the entity s functions, the information that links between these functions, together with all non functional requirements, regarding resources and the organisation of the entity. Importantly, there must be a traceable link between the requirements specification, the tasks, and the elements of the Concept of the entity. The Preliminary (or architectural) design of the entity covers the identification of a structure for the entity (definition of human roles and the definition of automated / hardware and software components, such as for manufacturing, logistics, control system and other information technology) and a mapping of this structure to the requirements specification. Importantly, architectural design decisions must be

4 traceable not only to show that the requirements specification is satisfied, but also to show that these decisions are compatible with all elements of the Concept level description of the entity (compliance with design policies & principles and values). It is relevant to discuss at this point the relationship between policies, principles & values, and the architecture of the entity developed by the preliminary design activity. Any policy, principle or value (henceforth, for simplicity, we just use principle to mean these three) can be satisfied by an entity in two (and only two) ways. An entity can satisfy the principle by design, meaning that after implementation every operational state of the entity automatically complies with the principle. Alternatively, an entity can satisfy a principle by control, meaning that the stated principle is introduced as control information to every relevant activity in the operation of the entity, thus the entity could operate in violation of the principle if it chose to do so. It is during preliminary design that the decision is made to build compliance with a principle into the design or to leave it as a control, and there are important consequences of this when discussing interoperability. E.g. if the designer of the entity decides that compliance with a selected interoperability standard is a principle to be upheld, then there is an architectural design choice regarding how to satisfy this principle. 1) One can design and build the entity entirely out of components that were developed to implement the given interoperability standard. In this case the entity will be locked-in with the standard, implementation cost may be reduced (through the use of off the shelf products) but future changes can become costly. This choice is acceptable if the return on investment of such a dedicated system is likely to be shorter than the expected frequency of change in what the preferred standards are in the given industry. 2) One can build the entity in such a way that only one, or few, small components are compliant with the standard by design, and the rest of the system is only compliant by control. This second choice is typically achieved using some type of middleware, able to translate from a company-internal standard data representation to the external standard. Notice that the decomposition of an entity into its constituents (human roles, hardware and software component systems) is a recursive activity, therefore the compliance with a principle may be enforced by design in one component system while it may be enforced as control in another component. Through this decomposition hierarchy it is possible to find the right level of component system which can be made dedicated to the standard of the day : above this level the system uses the principle (to follow a given standard) as control, whereupon below this level there is at least one component that is dedicated to the given standard and other components can be existing legacy systems, for example. The ability to use the interoperability principle as control (rather than as a design property of the entity in question) is also constrained by the theoretical limitations of information translatability (sometimes the information schema of a company must change otherwise the company can no longer interchange information with supply chain partners). As a result, the compatibility with interoperability standards is more important on the requirements specification level than it is on the architectural or detailed design level., because provided an entity complies with standard information schemata and a standard process nomenclature, the translation between internal and external representations is always achievable through relatively small middleware

5 components. Notice the terminology we used above: an information schema is not necessarily a database schema, thus two companies with compatible information schemata can easily interoperate even though their level of automation (and therefore their database schemata) may be different. Figure 2 represents a business model that includes the company as an entity, other companies (supply chain partners and competitors), a self-regulatory environment (such as an industry alliance, or network) and a governing entity (such as a regulatory body) that provides outside regulation to the given industry (and is not aligned to a select set of companies). We believe that this is a minimal set of players that need to be differentiated according to their role in having an effect on interoperability. 3 Life Cycle Relationships and Feedback Loops Directed arrows in Figure 2 show two types of relationship between entities. If an arrow starts in the operation of an entity and ends in the operation of another entity, then the arrow represents operational interactions. Forms of operational interaction are the exchange of information or material, the participation of an entity in the other entity s process (e.g. through the provision of service). If an arrow starts in the operation of entity A and ends on a life cycle activity of another entity B (except the operation of B), then the interaction is called generative, because A participates in the creation (or change / transformation) of B. For example, an Industry association participates in the work of a Regulatory Body (e.g. industry representatives are members of relevant committees), but the Regulatory Body eventually defines policies and principles (including legislated ones) that define, limit, or otherwise direct the processes or the organisation of the Industry association. This feedback loop is labeled Z in Fig.2. Many additional feedback loops or paths exist in this business model. Some loops are straightforward (like Z ), but some have multiple steps of action. Take for example the path Y V. An Industry Association (representing its members) participates in the operation of a Standards Body. The Standards Body creates standards that can be used (adopted) by supply chain partners as Reference Models (of processes and / or information). These standards in turn influence the way supply chain partners operate; finally, supply chain partners as they operate operationally support Industry Associations thereby closing the loop. To create a successful interoperability standard these feedback loops must be thoroughly understood and the lack of good governance (e.g. through which an Industry Association can voice its members opinions regarding the endorsement (or otherwise) of an interoperability standard is likely to create standards that will not become generally accepted by the given industry. One important role of Regulatory Bodies is (or at least would be) to define principles that govern the participation of industry users, industry associations and of vendors in standards creation, to ensure that standards are not hijacked by special interest groups to the exclusion of others.

6

7 This is not to say that competing standards will not exist at any one moment in time, because existing and emerging new standards are able to create similar divisions. However, Regulatory Bodies can enforce policies that require interoperability standards to be open, allowing open source or in-house implementations, in addition to proprietary ones. Reference models for interoperability include Requirements level models. Requirements level interoperability models further include the definition of typical process building blocks (e.g., Partner Interface Processes defined by Rosettanet [6]), from which building blocks various complete business transactions (processes) may be built. Requirements level interoperability standards also include information models (expressed, for example. as Entity-relationship or UML Class diagrams) and state transition diagrams (determining the relationship between activities in the process model and states of objects in the information model). As noted in Section 2, it is the adoption of such requirements level interoperability standards that make joint operation (or co-operation) between business entities possible. However, efficient joint operation typically also needs comparable levels of automation (see C4ISR/LISI Interoperability Levels [3]). The design level specification of the same standards may be expressed as a translation of the requirements level interoperability standard to workflows (for process standards) and as XML schemata (for information standards). The difference between preliminary design and detailed design level descriptions of these standards are minimal, and concern potential language bindings or other physical schema related information, referring to particular product modules that implement the mentioned process building blocks. However, it is not an interoperability requirement that supply chain partners use the same building blocks in their respective implementations of these standards. Partner interface processes and associated information schemata define reference models for the Application- and Data Services respectively. It is therefore the task of the Business Process management and execution services to invoke either local or remote functions as application services. 4 The Relation Between Service Orientation and Interoperability Implementing application functions as published services has the advantage that supply chain partners are able to define new business processes relying on existing local- and partner functions, rather than local functions alone (see Fig.2, support by Application Services of B i to Business Process Execution Service of entity A ). Notice that each application service has two sides to it (just as any other entity does, as explained in Fig.1): the left hand side refers to the service provided, while the right hand side refers to the management and control of the service. Given that management has strategic, tactical, operational and real time levels, if a business entity (either the company of interest or its partner) wishes to include an application function in a new business process, then that needs to be negotiated with the management of the respective application service. The negotiation includes the definition of the required quality of service, the definition of a service level agreement, the planning for potentially needed resource upgrade, or detailed design

8 change (e.g. database tuning), and the scheduling and supervision of such change (including the supervision of the design, implementation / release into test operation, testing, quality assurance, and final release into operation). Recent experiences with the implementation of Service Oriented Architecture suggest that the above service management and the assurance of the performance and quality of service is essential [4], otherwise the desired business process characteristics can not be guaranteed. As the above discussion shows: the fact that two businesses are interoperable (because of adhering to the same process and information standards) has almost nothing to do with whether these businesses use a Service Oriented Architecture or not! At the same time, to reap the benefits of interoperability technology is needed (on the detailed design level) that allows the interoperability potential to be quickly turned into reality, and SOA technology is one such technology platform which can achieve this. I.e., if supply chain partners implement business functions as published services (using SOA technology) and they are interoperable, then there is a potential for fast configuration of new business processes, which property leads to agility both on the level of the individual company and on the level of the complete supply chain. The use of SOA technology without interoperability standards is possible, but that limits the reuse of application functions to a single company (Company of Interest in Fig.2). Notice also that fast configuration (mentioned above) is not the same as dynamic (or on-demand) configuration, and to the authors knowledge there is no technology available at present for dynamic configuration that would be able to guarantee performance (speed, availability, gracious degradation). Thus interoperability standards and SOA technology are two separate means of improving supply chain integration, but used in combination have the potential of fostering agility and business innovation. 5 Conclusion This short article has demonstrated, through the use of a generic business model, the forces that influence interoperability in the supply chain. The role of regulatory and Standards bodies has been discussed and related to the role of Industry Associations, Major Vendors, and companies (such as SMEs). Various feedback loops in the development of interoperability standards has been discussed and it was argued that the design of the processes behind these feedback loops is essential for the achievement of truly open interoperability standards. The article also concluded that Service Oriented Architecture as a technology is an enabler, which can help members of the supply chain to reap the benefits of interoperability standards and implement agile and innovative business processes.

9 References 1 Grace A. Lewis, G.A., Wrage,L. : Approaches to Constructive Interoperability, CMU/SEI TR-020 Software Engineering Institute, Carnegie-Mellon University (2004). 2 ISO 15704:2000 Industrial Automation Systems -- Requirements for Enterprise Reference Architectures and Methodologies. Geneva : International Standards Organisation (2000) 3 C4ISR Interoperability Working Group: Levels of Information Systems Interoperability (LISI). Department of Defense. Washington, D.C. (1998). 4 Isaacson, C.: High Performance SOA with Software Pipelines. SOA Magazine Issue V, (March 2007) pp1-8 [on-line article published at 5 IFIP-IFAC Task Force, GERAM The Generalised Enterprise Reference Architecture and Methodology. in P. Bernus, L.Nemes and G.Schmidt (Eds) Handbook on Enterprise Architecture. Berlin : Springer Verl. pp RosettaNet Program Office : Overview Clusters, Segments, and PIPS (Version ). Lawrenceville, NJ : Rosettanet (April 2008)