SANNI Lookman

ESB: The SOA buzzword by Lookman SANNI and Younes ABOUELFAID

Globalization enforces nowadays companies to enable intra and inter-organizational process and to increase efficiency at low cost in order to stay competitive. In such a context of business integration, reusability and homogeneity are to be promoted in order to make services widely available in a real world IT environment through what’s called Enterprise Service Bus (ESB).

Most of vendors today propose proprietary software that covers every nuance of business integration requirements. This results in some outfit and overall locked enterprise software, exemplifying redundancy, complexity and resistance to extensibility. At the other hand, open source solutions lack of suitability to production environment as they are not provided as much industry support as they should.

As a matter of fact, software development industry started investing less and less in rigid and complex components where most of it is not used and more in light weighted and flexible ones. A new generation of software solution has then emerged under the term: “Lean Software”. Lean software is a ‘Just in Time’ solution for today and tomorrow needs. In other words, lean software is easily consumable and does not divert costly resource hours to be prepared for usage itself.

Talking specifically about ESB, it’s now about selecting a lightweight ESB for SOA adoption able to overcome the quoted limitations with minimal compromises. Such ESB should be configurable enough in order to make available only the right mix of needed functionality, to provide extensibility and scalability possibility and to provide necessary support while still being easy to use.

The Glassfish ESB provides such core ESB functionality opportunity in lean SOA deployment project. It is simple to be implemented and used. An essential set of adapters and support for common business integration standards facilitate rapid SOA deployment which makes developers concentrate more on integrating applications instead of spending costly resource hours on reworking the middleware to prepare the foundation for the actual project. Part of the Sun Glassfish portfolio, it combines technology from existing mature open source projects such as the Sun Glassfish Enterprise Server Runtime, the Netbeans Integrated Development Environment and new components, engines, adapters and standards from the OpenESB community.

Tailored to all profiles from programmers and architects to project managers, Glassfish ESB ensures cost reduction, efficiency increase and so resultant time-to-market reduction. Glassfish ESB can be highly scalable. For initial integration only the necessary functionalities can be used to create a department-level application; additional functionalities can be added later, based on the evolving needs. Glassfish ESB is also fully supported by Sun, with support subscription; testing; documentation; certification; training; and indemnification which is customized based on the customer’s level of usage.

The Glassfish ESB’s efficiency is not to be proven anymore as it has been implemented in several industry cases. The United States Department of Health and Human services (HHS) for instance has chosen it for connecting the federal government agencies and health information exchanges accross the country. Glassfish ESB’s cross platform compatibility and major footprint in health information exchange have been influencing in this choice.

It’s well known that scenarios, description of real world facts and actions, are very powerful in so far as they get stakeholders to immerse themselves and understand more a given process. Performing requirements engineering then without “inviting scenarios to the party” will be very arduous or almost beyond the bounds of feasibility. The main issue for scenario based approaches will then concern the way scenarios are designed and organized. The “scenario classification framework” is an attempt to solve that issue and to make scenarios more effective in the requirements engineering process. How does it work?

The framework proposes a classification of scenarios along four different views: form, contents, purpose and lifecycle. Each view is sliced in dimensions called facets, to which a list of attributes is attached. Thus, characterizing a given scenario foreshadows giving a value to each attribute in each facet, for each one of the framework’s views.

The form view emphasizes the way the scenario is expressed. This expression can be seen along two dimensions which are the description facet and the presentation facet. If the former one is measured by the level of formality and the channel used, respectively notation and medium attributes, the latter evaluates the liveliness of the scenario through animation and interactivity attributes.

On the contents axis, the framework enlightens scenarios along four different dimensions. The abstraction facet, expressing the concreteness of a scenario, is evaluated by Boolean values (instance, type, mixed) which indicate whether a scenario describes a specific experience or situation, a generic one, or both. Then, there is the context facet, which expresses the amount of information embedded in a scenario, relating to the context of the To Be system. This is performed by determining whether properties like the internal behavior of the system, interactions in terms or role playing with its environment, the organizational context of the system including the organization’s structure and the organizational environment are included in the relevant scenario or not. Another angle of scenario analysis along the contents axis is about the argumentation knowledge enunciated in the relevant scenario. There again, the duty is to check if the scenario includes descriptions of alternative positions, arguments that go along with a given position, conflicts or issues that may arise and final decisions or not. According to the kind of information captured by the scenario, a last clarification could be made: there lays the concern of the coverage facet. A scenario may capture functional aspects (structure, function and behavior) of the system as much as non functional ones (security, performance, time). Moreover, intentional aspects of systems like goals, problems and objectives are taken in account in that facet.

Scenarios can play different role according to intended ambition or expectation. The purpose view identifies those roles during the scenario classification process. Thus, scenarios may be descriptive regarding a given process, exploratory by investigating different ways to meet a requirement or explanatory by elucidating a pronounced issue.

The lifecycle view, the last one, investigates in one hand on scenario’s progression and lifetime, and in another hand on operations or transformation they might overcome. Thus, this view exposes two facets: The lifespan facet which will help separating transient scenarios from persistent ones and the operation facet for a classification according to the type of operation the scenario carry out. It could either be a capture operation through scenario generation from scratch or by reuse, or a refinement or restructuration operation. A scenario may also serve for assembly purpose and will then be classified in the integration operations category, or extend knowledge in an existing scenario and then be tagged as expansion operation type. Finally when a scenario reaches the end of its lifetime, deletion operations appear to be ineluctable.

Unfortunately, like many other approaches, this classification doesn’t tackle the process aspect of scenarios. Nevertheless, there have been some approaches to the process of scenario generation. These may include the use of business actors and responsibilities to discover use cases and then scenarios, or the use of a predefined matching between scenarios templates and types of situations.

Finally, from a practical point of view, the framework has proven usefulness after conducting polls on scenario characterization in industrial projects, although there’s still a gap between what’s stated in literature by research, and used tools and methodologies in experience.

An abstract by Lookman SANNI

Author: Colette ROLLAND

It has been known through various surveys that Information Systems (IS) projects imperfection and failures are mainly due to a misapprehension of such systems requirements. An appropriate way of doing requirements engineering (RE) should dig different stakeholders’ objectives and activities carried out by them to reach those goals. Thus, IS will no longer be only technically good but also purposeful and of quality. This view of RE process which focuses on goal centric activities is the “goal-driven requirements engineering”.

This focus on goals can be explained by the ability of goal modeling to ensure efficient requirements elicitation, completeness and pre-traceability. It also helps in terms of exploration of systems choices, detection and resolution of conflicts that may arise from multiple viewpoints provided by stakeholders. All these can be performed by answering to the following set of inquiries: Why is a determined functionality or constraint needed or not? Are the elicited requirements enough to achieve the goal they promote? Where does each requirement originate from and how to track changes it undergoes? What different ways of satisfying a given goal exit?

In order to make the goal-driven RE more efficient, some key issues have been raised by different approaches while trying to support the process. For instance, to automate goal analysis, efforts have been undertaken in terms of formalizing or semi-formalizing goals formulation. Propositions have also been made to match goals with scenario in order to make them more concrete, more illustrative with respect to undertaken actions by systems’ agents. Additionally, in pursuance of supporting a better understanding of goals, the notions of relationship and levels of abstraction have been introduced. Thus, goals can be distilled in either more or alternative sub-goals; they can also be influencing one another or straightforwardly be conflicting. Obviously, top level goals also known as business objectives linking to low level ones or systems requirements should then arise. “L’ECRITOIRE”[1], a goal-based approach to RE addresses all these issues.

An abstract by Lookman SANNI

Author: Colette ROLLAND

[1]: http://crinfo.univ-paris1.fr/CREWS/Process/chunk19_index.html

Below is an abstract I wrote recently about the interesting article “From conceptual modeling to requirements engineering” by Colette Rolland, my requirements engineering lecturer!!!

Information systems (IS) used to be designed via conceptual modeling. The output of that traditional way of engineering is a system specification which prescripts what the system should do, assuming that its exigencies are fixed and can be assimilated to its functionalities. Nowadays, economic pressure and new technologies emergence within organizations make their requirements continuously changing. Therefore the functionality approach of IS design is no longer suitable and from then on, there is a real need of efficient requirements elicitation, validation and representation through what is called “Requirements Engineering”. What kind of issues does conceptual modeling address? How is it processed? Since designing IS only via this approach doesn’t fit anymore the shaky business requirements, what additional aspects of IS requirements engineering does tackle?

Conceptual modeling aims at building up conceptual data model, based on analysis of the things of significance to an organization. As there was the need to capture as many aspects of real world semantics as possible, several conceptual models have emerged, each one viewing the universe of discourse from a given angle. Therefore, frameworks have been developed to understand and classify them according to their viewpoint. The Three dimensional framework proposes an organization into classes of process, data and behavior oriented models. If the first one addresses system components hierarchy building, the second one in contrast acts like a storehouse or data manager of organizations information contents, whereas the third one deals with interesting events, their causes and impacts. Taken apart, each one of these ways of looking upon IS is deficient as for instance process-oriented models don’t show interactions between components. Consequently a new generation of conceptual models which either integrates the three ways (object oriented models), or consists of loosely connected conceptual models each according to a different perspective emerged. As far as processes are concerned, conceptual models are activity based. In other words, they look upon process as consisting of a set of decomposed activities linearly ordered.

Whereas conceptual modeling scopes the “what is done by the system”, requirements engineering on one hand extends that notion to the “why is the system like this” view, and on the other hand explore the various ways in which the system might be used.

Mainly, requirements either come from informal statements of goals by users (user-defined) or from constraints and facts of real world (domain-imposed). This implies a discernment of two worlds of usage and subject which interact with the environment of the system also called world of specification or system world. In such organization, the user-defined requirements are captured via two kinds of relationship between usage and system world, namely usage fit and intentional relationship. These relationships introduce respectively goal-driven and scenario-based approach of requirements engineering. The former models organization objectives so as to relate them to the functions of the system, while the latter one purpose is to capture, describe, explain and explore all possible scenarios. In order to overcome some of the deficiencies and limitations of goal-driven and scenario-based approaches, models combining goals and scenarios have been developed. The added value is that they help operationalizing goals as well as checking whether scenarios achieve these goals. In addition to the representation relationship between subject and system world (main focus of conceptual modeling), the remaining requirements come from the domain genericity which results also from a relationship between subject and system world. In fact, since many new applications have same requirements as earlier ones, reusing already created and generic domain models can only make the modeling process easier.

Several aspects of requirements engineering process are also addressed in the article. Guidance for instance should be performed while modeling processes, as existing models (activity, product and decision oriented models) lack of completeness in their way of doing requirements engineering. This arises the importance of situatedness, which will help handling deviation that satisfies system’s constraints on one hand, and allowing changes to be made when needed on the other hand. Additionally, contextual and decisional modeling contribute to the requirements engineering process guiding. If the former’s purpose is to build a hierarchy of alternatives and select the best suiting to the situation at hand, the latter focuses on generation of the set of decisions that can be applied to a given product’s situation. Ensuring requirements traceability is also a fundamental aspect in implementing a quality system, as it is supposed to undergo requirements changes. Finally, all these approaches and methods processing can be automated in computer based environment. There’s been a broad range of Computer-Aided Software Engineering (CASE) tools, which help providing edition and maintenance for graphical specification, as well as documentation and verification; unfortunately they are lacking in adaptability to other methods and in providing process support. These limitations are addressed by the repository based approach.

Requirements engineering takes up the challenges of embedding system in their larger usage context and change management by taking in account almost all aspects of information systems. This efficiency is reached because of its ability to keep track of connections between goals, activities and requirements at any level of abstraction.

by SANNI Lookman
La croissance d’une entreprise passe forcément par un grand volume d’activités et donc une grande quantité d’informations à gérer et dont il faudra tirer le meilleur parti pour prendre les bonnes décisions. Cette masse d’informations, parfois sensibles, portent tant sur l’environnement de l’entreprise que sur ses ressources. La gérer au quotidien bien que n’étant pas toujours chose évidente, s’avère capitale dans cette sphère de globalisation des marchés. Ainsi on assiste aujourd’hui à l’émergence d’une nouvelle économie dite de l’information ou « Nouvelle économie », où le travail en rapport avec l’information est devenu plus important que le travail en rapport avec les autres secteurs. Ceci sous-entend donc la mise en place d’un système représentant l’ensemble des ressources (les hommes, le matériel, les logiciels) utilisées pour collecter, stocker, traiter et communiquer les informations au sein de l’entreprise : « Le système d’information (SI) » de l’entreprise. Qu’est ce qu’un SI ? Qu’apportent les systèmes d’information aux entreprises d’aujourd’hui ? Comment interviennent-ils dans la stratégie de l’entreprise afin que cette dernière puisse atteindre ses objectifs ?
Un S.I est un réseau complexe de relations structurées où interviennent hommes, machines et procédures qui a pour but d’engendrer des flux ordonnés d’informations pertinentes provenant de différentes sources et destinées à servir de base aux décisions selon Hugues Angot. Autrement dit, si l’entreprise était le corps humain, le système d’information aurait vocation à en être le système nerveux faisant ainsi acheminer diverses informations recueillies à différents niveaux entre toutes les composantes de l’entreprise. Aujourd’hui la plupart des systèmes d’information sont informatisés. Ils utilisent du matériel informatique, des logiciels, et bien sûr les nouvelles techniques de l’information et de la communication pour transférer les ressources en données et en divers produits informatifs et cela de manière sécurisée lorsque les données manipulées sont sensibles. Les SI regroupent les bases de données de l’entreprise, les progiciels de gestion intégré (ERP), les logiciels de gestion de relation client (CRM), les outils de gestion de production assistée par ordinateurs, des applications métiers, des serveurs de données et d’applications, des systèmes de stockage et évidemment des systèmes de sécurité pour assurer l’intégrité des données qui circulent au sein de l’entreprise.
Les systèmes d’information peuvent jouer un rôle capital dans le succès d’une entreprise. En effet, les dirigeants d’entreprise sont souvent confrontés à un certain nombre de choix décisifs (allocations de ressources, choix d’un modèle économique), qui engagent l’entreprise dans le long terme, afin de dégager un profit durable. Ces choix ne pouvant qu’être faits à partir des données dont disposent les dirigeants de l’entreprise, l’information possède désormais une valeur d’autant plus grande qu’elle contribue à l’atteinte des objectifs de l’organisation. Les SI à juste titre fournissent l’information dont l’entreprise a besoin pour une exploitation efficiente, une gestion efficace, et pour obtenir ou maintenir son avantage sur les concurrents. Ainsi une bonne maîtrise du SI et son adaptation aux objectifs stratégiques de l’entreprise aide à coup sûr les entreprises à prospérer dans une économie fortement concurrentielle. Un SI bien maîtrisé devra offrir à l’entreprise les outils pour réaliser ses objectifs stratégiques. Il devra permettre aux organisations par exemple d’améliorer leur créativité et leur efficacité, de pénétrer des marchés “de niche” à un niveau mondial et de saisir plus rapidement des opportunités commerciales, de traiter avec des groupes de petite taille comme s’ils étaient des entités beaucoup plus grandes, de réduire les cycles de développement de produits et d’adopter des stratégies marketing qui répondent largement aux besoins des clients.
Une fois les objectifs de départ réalisés, le SI pourrait ouvrir à l’entreprise des possibilités stratégiques qui n’existaient pas auparavant. Il apparaît alors que le SI, d’abord mis au service d’une première stratégie, modifie ensuite le champ du possible et ouvre aux dirigeants de l’entreprise la perspective de nouveaux objectifs stratégiques. Le SI devra alors évoluer également pour permettre à l’entreprise de suivre sa nouvelle stratégie, et le cycle continuera.
En résumé, c’est la gestion globale de l’information grâce aux SI qui est la stratégie qui permet à une entreprise de rester flexible et compétitive sur un marché toujours plus ouvert à l’international. Toutefois, des risques peuvent être encourus par l’entreprise en cas de mauvaise gestion du système d’information, ce qui se soldera par un échec du SI. En effet s’ils n’appuient pas correctement les objectifs stratégiques, les opérations commerciales ou encore s’ils ne comblent pas les besoins des dirigeants, les SI peuvent mettre en jeu le succès et même la survie de l’entreprise. Par conséquent une gestion saine des systèmes d’information constitue un défi pour les dirigeants.