Designing Complex Web Information Systems

Today, to deal with Information Systems appears very complex because the term by now is used in order to indicate any application able to resolve any problem in a specific business area. During the years, we have seen to use this term in a very general way often with divergent meanings between them. Moreover, they have been used several and different design methodologies, from the functional decomposition to those relative ones to big framework SAP-like (that they put together different specific applications with the goal - above all Marketing goal- to supply integrated Information Systems simply choosing some configuration parameters) and, beside these, several and different philosophies of design like ERP, MRP, CRM etc… Moreover, the advent and the extraordinary spread of Internet and, therefore, the expansion of the Information System on the Web, have generated an remarkable increment of methodologies and technologies for the design and the development of applications for the Web, forcing to review well-known methodologies, such as the Object Oriented, with the result to make the effective use of UML for the design of Information Systems extremely complex. In general terms we can assert that any methodology, for being truly effective, must allow the designer to concentrate itself on the problem to resolve rather than to try to understand as using the same methodology in order to express the specific problem. It appears, therefore, necessary to try to make order in this chaotic universe of acronyms, philosophies, methodologies that often approach similar problems and offer similar solutions even if dressed of innovation and oneness, supplying a clear point of reference to which we will relate within this book. INFORMATION SYSTEMS The term Information Systems means “the set of the procedures and the infrastructures that support and describe the flowing of the information inside an organizational structure” (Pighin, 2005) In other words, an Information System allows to describe, in detail, as any Company (public or private) carries out the job to which it is deputy and which are the material and immaterial resources available. Such definition prescinds, and must prescind, from the use of an eventual automation related to the use of Computer-based systems. To become “automated”, partially or completely, an Information System means to design and to develop a Computer-based System that supports and implements how much described previously; Alternatively, rather, the application must be adapted itself completely to the way of working of the Company, and not vice versa. A lot often, today, many Software Houses tries to impose to the Companies the way of working already implemented within their applications, prescinding from the peculiarities of the companies, their history and the resources available. Of course, to develop an ad-hoc application requires remarkable economic investments and not always it is affordable for the average and small productive realties and, therefore, often it is indispensable to balance these two divergent requirements. The goal of the book and of the methodology that is described inside, it is just to realize a compromise between the economic effort and the necessity, for the Companies, to differ from other concurrent economic realities. Information Systems: from business process design to the business process reengineering In the 1990 Hammer (Hammer, 1990) published its theory on the necessity of reengineering the business processes starting from the observation of the reality and from the experience that many computer experts had experimented in their professional life. It asserted that the introduction of innovative technology on old business processes had highest probabilities of failure. Such affirmation, however obvious, had the merit to raise the problem of the understanding of how the company carried out its own job and with which resources before proposing innovation. This is, in our opinion, the guideline that would have to always drive the proposal of innovation to a company but as pointed out previously, it is not how much happens in the majority of the cases. The theory of the BPR - Business Process Reengineering – (Hammer, Stanton 1995), in brief, is made up of three main phases: 1. AS-IS: the definition of present BPs (Business Processes). This is supposed to be the fundamental phase of the analysis because it allows to identify the Primary Processes (or Macro-Processes) that they describe as the company works currently; 2. Comparison and diagnosis: it is provided to a quantitative and qualitative evaluation of what it is found, using well-known techniques of benchmarking, and eventually a comparison with companies of the same typology; 3. TO-BE: re-definition of BPs according to the requirements of a company. The variables to be considered in each phase are at least four and in particular: • The flow of BPs: the decomposition of the Processes in activity flows; • The organizational structure: the contribution and the responsibility of the productive units to BP; • The human resources: the characteristics, skills and the availabilities to the change; • Systems of values (motivation and boosting): a system that aims both to reduce the opportunistic individual factor and to measure the productivity. Considering globally these variables, the strategies of Reengineering that have been asserted are substantially 3: 1. Buy-side strategy: related to the part of Information System that regards the suppliers of raw materials and/or services (B2B, e-procurement, etc.); 2. In-side strategy: related to the part of Information System inside the company (ERP); 3. Sell-side strategy: related to the part of the Information System that involves the final users (B2C, etc.). Any design of reengineering always begins with the necessity of a change and the definition of a new business vision. In the first phase (AS-IS), therefore, it is indispensable to understand as the company operates currently, with which organizational structure and which level of responsibility within the activities in being, with which kind of Human Resources (skills, availability to the change, etc.) and with which system of values that define both the individual and structure goals and the way with which it is come stimulated to the aim to reduce most possible what in literature it is called “opportunistic individual behaviour” (Williamson, 1975). This phase is, in our opinion, most difficult and most expensive from the economic and employed resource point of view but, if well executed, a succeeding concurs to carry out BPR with. In fact, starting from the detailed analysis of the present situation and using opportune tools of simulation, it is possible to carry out a first rationalization of the organizational structure and the flows of business processes. Such affirmation, justified from the experience of a quarter of century in the field of the high level Information Systems of one of the authors, is based on the fact that often the operating procedures and the information exchange inside the Companies is the result of a series of adjustments that they have contributed to create, in the course of time, a superstructure not justified and often unknown to the Company’s people. AS-IS Analysis would have to identify a few Primary Processes for being able to effectively manage a reengineering of the same ones and, in particular, we think that for big Company 15 processes would have to be characterized approximately. Both the Primary Processes and the Support Process (or Secondary Processes) are represented using the Value Chain of Porter (Millar, Porter 1985) identifying the Processes that create value for the Company according to their mission. The first activity, therefore, concerns the decomposition of these processes in a harmonic and reasoned flow of tasks. For many years, from the introduction of the concept of Business Process, it has been a complete anarchy in the use of an effective notation for the graphical representation of the flow of the activities regarding the first variable into play. Some big Software Houses have developed its own method (for instance, FILENET, now an IBM subsidiary) while others have used standard methods like IDEF0 (IEEE, 1998). The fundamental characteristic of these models of representation of the Processes is that they are not user-oriented, that is they are particularly complex to use and too much cryptic the final user could understand they. Finally, in 2004, the more important Companies in this sector have gathered in a consortium to aim to develop a common and effective notation to be used to model the BPs in an understandable way for the final customer. Such notation, BPMN - Business Process Management Notation, that it is the base of this book and will come shortly illustrated later on, (OMG, 2006) now is maintained from the OMG. The representation of the Processes through BPMN uses, for its formal representation, a specific language machine-readable - BPEL - which the Companies of the sector use in order to develop all the support tools that are not free of charge. Our research group, since many years, uses OWL (Ontology Web Language) as main language for the modeling and the definition of meta-model because it is considered more suitable to represent the concepts and the base rules understanding a methodology. The choice to use the ontologies in the field of Software Engineering has been confirmed by a recent paper published by IEEE (Cardoso, 2007). The use of Ontologies, that shortly will be dealt forward, allow us homogeneity of modeling being a platform/company-independent. The second phase, defined of Comparison and Diagnosis, provides a first activity of appraisal using the techniques of benchmarking sure complex and articulated but tendentially determinist. Different is instead the comparison with other similar Companies. In literature, often it refers to such a comparison with the term of Best Practice that means some success cases of companies that operate in the same segment of market with equal dimensions: in other words, concurrent companies. It is obvious that the Companies cannot have approached, legally, sensitive data of concurrent Companies in order not to incur in the crime of industrial espionage. It is equally obvious that the big Consultant Companies, thanks to the elevated number of customers, could have such information, but they would not have to use them for the same reason expressed previously. The term Best Practice comes instead used widely in the business field but with obvious scope to propose to the customer something of pre-assembled. According to our opinion, the true comparison would have instead to be carried out between how much found using benchmarking and the goals of the Company according to the Vision that has generated the change necessity. Finally, the third phase, called TO-BE, has the job to redesign the way with which the Company must work in order to aim its goals. The change, of course, will regard all the involved variables described previously and the result will be absolutely integrated. It is interesting to notice that, until now, we have spoken exclusively about Information System and not about applications by agreement with the separation between the two systems, Information System and Computer-based System, described previously. During the last few years, the Business Process Management (BPM) that “is a field of knowledge at the intersection between management and information technology has been asserted, encompassing methods, techniques and tools to design, enact, control, and analyze operational BPs involving humans, organizations, applications, documents and other sources of information” (Van der Aalst, 2003). This mixture between Information System and Computer-based System was already present de facto on the market since many years. In fact, when the big Consultant Companies with their associated Software Companies propose the notorious Best Practices, they certainly sell effective software applications, but these applications are pre-manufactured and customizable through an opportune set of parameters, so it is possible that these applications are not the better possible solution for that specific company. In short, the Consultant proposes to the company a solution to the problems that have driven to the change but, this solution does not keep in some account the own peculiarities. Some among the more important Companies of the sector pursue this type of approach, that could be useful for some Companies of small and averages dimensions but the economic effort required a lot often is unsuitable to this kind of Companies. The market currently is global and too much competitive, so the reasons that induce to change are multiple. Moreover, the change necessities take part very frequently (in some cases also many times in the same year) so the Information System must be flexible for being able itself to adapt easy to the new reality without the necessity of dramatic reengineering. In the same way, the support Computer-based System must be equally flexible for effectively being able to adapt itself to the new requirements. The philosophy of the BPM proposes to exceed the logic of the BPR, just for the ability to implement flexible systems in order to follow the continuous evolution of BP; it considers as main software instrument the Workflow Engines that has the job to automate the repetitive activities above all (the operating job) usually oriented inside the Company, putting into effect the transformation of the Processes according to the in-side strategy that generated the ERP. In this book, we will not deal about ERP because, however currently many Software Companies continue to advertise their products like ERP, practically having unique DBMS and allowing the sharing of the information between all the business software systems is a norm of good design. Therefore, the BPM as more modern, more flexible and softer approach of the BPR. However, is it true? No, it is not in our opinion. In fact, very often would be opportune before to carry out, where necessary, a radical transformation using the BPR and successively to follow the continuous evolutions through the techniques of the BPM. In fact, using the directly BPM in order to model BPs in the point of view of their automation, it is high the risk to fall back in the error described by Hammer: to graft computer-based innovation on a not adequate organizational structure represents a high probability of failure. The failure risk increases considering which professional figure should model the BPs. In the point of view of automating the execution of this flow of activities, it seems natural to design such a flow using the necessary sagacity to the implementation and, therefore, the key figure would have to be an expert of design of applications. Such choice does not seem adequate to us. In the methodology proposed in the book the starting hypothesis regards just the knowledge that a cultural gap exists between the specialists of business and organization and the specialists of software applications. Web application: the concept of user experience Today it is dealt widely about Web applications (WA), but everyone interprets in its own way this definition. We think, therefore, to be opportune to clear to the reader what we mean for Web application. Firstly, it is well to clear what sure we do not mean with such a term that instead, unfortunately, many specialists of the field adopt. The WA is not a traditional application that uses the Browser as interface. The WA is, instead, a tightened marriage between the necessity to carry out operations, being active part of a Business Process, with the typical usability and the navigation of a static Website. The greater causes of failure in the area of Web are determined from the inability of the visitor to find the information that it needs and to surf between these. For this reason, some methodologies of design of Web Application have been born in the last years that will come deepened and illustrated in the following pats of this book. At the dawning of Web, also with the knowledge of the concept of Hypertext, that is a semantic relation between information, many have undertaken the development of such applications without using a design methodology; they realized absolutely unusable WA in which the visitor “it got lost” and that it abandoned desperate in order not to return there never more. When account of the necessity has become us to use also for this type of applications a design methodology, many turned to the only noted and widely used: UML. Many continue to think about this methodology without to keep in some account the fact that it has been born in order to model System-Oriented applications continuing to ignore the requirements of usability of the visitor. UML has been evolved in order to try to model any thing, without to lose own originates represented by the base rules of the Object-Orientation thus becoming potentially a methodology able to model any thing (also BPs) but, de facto, so complicated to be unusable even for the same specialists of applications. The user of a WA needs, instead, “to feel at ease” in a world to which it belongs, and that it agrees before still to find the information which it needs. This means to model the user-experience: To model the interaction of the user with the application by agreement with its requirements and not to model the application according to the requirements of the system. The approach used in this book aims to model the interaction of the user with the WA using the paradigm of the “Dialog”, considering both the peculiarities of the user (multi-user) and those of the device that it is using (multi-device). Moreover, the user of a WA uses information not closely tied to the data but that instead are related to the marketing and to the creation of a world able to attract a new user. The approach used for modeling the WAs is based on three levels: conceptual level, logical level and page level. The details of every level will be illustrated more ahead; in this moment we only notice that the more advanced point of the modeling, mainly close the implementation (page level), loses a few semantic to advantage details to the necessary developer. The attention of the specialists, therefore, is moving more and more towards the application domain rather than towards the classic design of applications (OO). This area of research, confirmed from the result of the Workshop on the DSM (Domain Specific Modeling) in the conferences OOPSLA 2006 and 2007, considers not effective the use of standard methodologies in order to model any thing in any application domain. The main reason is the limitations that these methodologies of course introduce and that force to express the key concepts of an application domain “make up” that make to lose in clarity and acquaintance (Paiano, 2006), (Paiano, 2007). In the conference of 2006, IBM itself, UML owner, has tried to illustrate the use of UML from the point of view of the DSM, and the result has been a sort of an Old-Style functional decomposition, brought up-to-date with some of the typical terms of the OO. In any case, one of the key concepts of this area of research is represented by the automatic generation of the final application starting from the model. We are nearly perfectly by agreement with this tendency. The domain we consider is the web, and we model the WAs using a methodology, that we think absolutely suitable for the Web, in order to model applications in different application domains, with the awareness that, if will be further clarity and representativeness requirements, we can modify the below meta-model thanks to the use of Ontology that allow us to express concepts many complexes with the needed semantic and clarity. Finally, starting from the model of the application, we automatically generate the final WA using two different open source frameworks. Complex Web Information Systems: The challenge At this point, a question is not being more deferred: What is a Complex Web Information system? A Complex Web Information System is an Information System, usable via Web, which includes inside the way a Company performs its activities, the BPs. This System must be usable and must be arranged to easily follow the changes of the activities of the Company according to the vision of a Company as an “open system” (Galbraith, 1973) adopting, therefore, a contingent perspective about its position in the business world. This vision, after 35 years, is not only actual but unavoidable in the global market of the third millennium. As the reader can see, the answer appears quite simple, however to aim the goal of designing a “contingent” Information System capable to effective adapt itself to the continuous changes forced by the solicitations coming from the outside of the Company, it is needed a complex work of analysis and integration of several methodologies. Therefore, the challenges of this book are: • To design Information Systems approaching two main problems: on one hand those relative to the development of web applications and on the other hand to the design and integration, inside of the information system, of the business processes that, although their importance and unquestioned usefulness, they found it hard to enter in a pervasive way in the design and the development of the Web Information Systems. • To implement the Information Systems through the automatic code generation tools that, starting from the design model in a machine readable format, help the IT expert to obtain the Information System very close to the design and without the little personal choices very often dangerous. The methodology that is to the base of this book has the goal to propose a solution to the several problems related to the development of Information Systems usable via Web. Regarding the BPs, as argued previously, it is thought fundamental to start from a deepened analysis of the actual situation without to consider eventual automations. Moreover, being this activity much complex and embracing every aspect of the business life, the experience and the skill of the analysts who, apart some cases ascribable to small business reality, are expert of organization and models of business and not expert of development of applications, are decisive. This clear separation of the jobs represents our starting hypothesis. In fact, currently we can identify two situations. The first represents how much happens using the techniques of the BPM. The consultant companies aim to design BPs from the point of view of the developer of applications, allowing therefore of being able to use the Workflow Engines or similar techniques. In this case, they completely lose sight of the company in its wholeness, so this technique represents just a way to design applications with look & feel more attractive but substantially similar to the functional decomposition of approximately 20 years ago. Of course, in some cases, this technique can be equally effective, but it is impossible to generalize its use. The second situation represents, instead, exactly the opposite one. A big Consultant Company designs the new BPs considering correctly the company in its wholeness and acting on all the variable ones into play. Successively, when they will develop the computer-based system, which must support the new way to work of the Company, the developers will use well-known techniques of Design of applications considering BPs just as requirements. Therefore, it needs to bridge the gap between the design of BPs and the design of the Web applications. Our research work, that it is the base of this book, has the goal to bridge this gap through a methodology that keeps into account the requirements and the peculiarities up to here evidenced. The research activity, therefore, starts from the foundation that the activity of the business experts, that are those who have the task to redesign a Company in its wholeness, stop itself at a detail level unsuitable to those who, instead, must implement the applications. Therefore, the first methodological step carried out from the designers of applications is that one to refine the flow of the processes in order to render them apt to being a true Input (and not just as a requirement) for the developers. Moreover, two possible scenarios are proposed. The first regards the part of Information Systems turned to the internal stakeholders by agreement with the strategy of reengineering of the BPs defined “in-side” to which often it is associated, erroneously to our opinion, the acronym ERP. This type of users often has the necessity of applications Data or Process-Driven, and, therefore, the philosophy of designing the User-Experience could be not suitable, in the sense that it, in the majority of the cases, coincides with the semantic structure of an E-R model with the timing based on the flow of the operations. For the internal users, the use of a Workflow Engine could be suitable also, but we have thought opportune to give a greater freedom to such users in order to build a “virtual desktop” according to their needs. For this reason, and by agreement with the philosophy of the DSM, we have preferred to generate automatically the Java Portlet or the Webparts in Microsoft environment. In this way the user could personalize its virtual desktop adding to the business activities also others Portlet about individual productivity or social communication. The second scenario, concerns, instead, the external users of the company and therefore essentially, but not only, by agreement with the strategy of reengineering of BPs defined “sell-side”. The external users use essentially a WA in order to both navigate between the information and to activate BPs being been integrating part of the same ones. This scenario allows to make a design of the User-Experience independent from the processes and by agreement with how much described in the previous paragraph to which successively will be integrated the BPs. According to these considerations, this book aims to introduce two new methodologies: the first one as result of the extension and a reasoned integration of existing methodologies at conceptual and logical levels introducing a new publishing model, the second one, that oriented to the internal stakeholders, as an enhancement of the generation of applications through workflow engines. This book, dealing with new methodologies, is clearly oriented to the scholars demanding their contribution to improve our approach; however, since the book also deals with tools and automatic code generation starting from the models of the Information Systems, it could be an essential guide for practitioner that have to design, to manage and to maintain Information Systems.