The transaction pattern through automating TrAM

Transaction Agent Modelling (TrAM) has demonstrated how the early requirements of complex enterprise systems can be captured and described in a lucid yet rigorous way. Using Geerts and McCarthy’s REA (Resource-Events-Agents) model as its basis, the TrAM process manages to capture the ‘qualitative’ dimensions of business transactions and business processes. A key part of the process is automated model-checking, which CG has revealed to be beneficial in this regard. It enables models to retain the high-level business concepts yet providing a formal structure at that high-level that is lacking in Use Cases. Using a conceptual catalogue informed by transactions, we illustrate the automation of a transaction pattern from which further specialisations impart a tested specification for system implementation, which we envisage as a multi-agent system in order to reflect the dynamic world of business activity. It would furthermore be able to interoperate across business domains as they would share the generalised TM as a pattern.</p

Applying model-driven paradigm: CALIPSOneo experience

Model-Driven Engineering paradigm is being used by the research community in the last years, obtaining suitable results. However, there are few practical experiences in the enterprise field. This paper presents the use of this paradigm in an aeronautical PLM project named CALIPSOneo currently under development in Airbus. In this context, NDT methodology was adapted as methodology in order to be used by the development team. The paper presents this process and the results that we are getting from the project. Besides, some relevant learned lessons from the trenches are concluded.Ministerio de Ciencia e Innovación TIN2010-20057-C03-02Junta de Andalucía TIC-578

Leading the Practice in Layered Enterprise Architecture

While Enterprise Architecture (EA) causes organisations to think, work and model in domains, there are inadequacies in such a waterfall approach. By restating domains as layers, i.e. LEAD (Layered Enterprise Architecture Design/ Development) based on the LEAD Enterprise Ontology, EA performs better in enterprise layers and levels of abstraction. Through LEAD, the domain relationships are also better captured, hence leading the advancement of agile EA

Domain modelling and the co-design of business rules in the telecommunication business area.

This paper discusses the development of an enterprise domain model in an environment where part of the domain knowledge is vague and not yet formalised in company-wide business rules. The domain model was developed for a young company starting in the telecommunications sector. The company relied on a number of stand-alone business support systems and sought for a manner to integrate them. There was opted for the development of an enterprise-wide domain model that had to serve as an integration layer to coordinate the stand-alone applications. A specific feature of the company was that it could build up its information infrastructure form scratch, so that many aspects of its business were still in the process of being defined. The paper will highlight parts of the Enterprise Model where there was a need for co-designing business rules together with the domain model. A result of this whole effort was that the company got more insight into important domain knowledge and developed a common understanding across functional areas of the way of doing business.domain modelling; business rules; object-oriented analysis; business process modelling;

A commentary on standardization in the Semantic Web, Common Logic and MultiAgent Systems

Given the ubiquity of the Web, the Semantic Web (SW) offers MultiAgent Systems (MAS) a most wide-ranging platform by which they could intercommunicate. It can be argued however that MAS require levels of logic that the current Semantic Web has yet to provide. As ISO Common Logic (CL) ISO/IEC IS 24707:2007 provides a firstorder logic capability for MAS in an interoperable way, it seems natural to investigate how CL may itself integrate with the SW thus providing a more expressive means by which MAS can interoperate effectively across the SW. A commentary is accordingly presented on how this may be achieved. Whilst it notes that certain limitations remain to be addressed, the commentary proposes that standardising the SW with CL provides the vehicle by which MAS can achieve their potential.</p

Design Challenges for GDPR RegTech

The Accountability Principle of the GDPR requires that an organisation can demonstrate compliance with the regulations. A survey of GDPR compliance software solutions shows significant gaps in their ability to demonstrate compliance. In contrast, RegTech has recently brought great success to financial compliance, resulting in reduced risk, cost saving and enhanced financial regulatory compliance. It is shown that many GDPR solutions lack interoperability features such as standard APIs, meta-data or reports and they are not supported by published methodologies or evidence to support their validity or even utility. A proof of concept prototype was explored using a regulator based self-assessment checklist to establish if RegTech best practice could improve the demonstration of GDPR compliance. The application of a RegTech approach provides opportunities for demonstrable and validated GDPR compliance, notwithstanding the risk reductions and cost savings that RegTech can deliver. This paper demonstrates a RegTech approach to GDPR compliance can facilitate an organisation meeting its accountability obligations

Conditions for interoperability

Interoperability for information systems remains a challenge both at the semantic and organisational levels. The original three-level architecture for local databases needs to be replaced by a categorical four-level one based on concepts, constructions, schema types and data together with the mappings between them. Such an architecture provides natural closure as further levels are superfluous even in a global environment. The architecture is traversed by means of the Godement calculus: arrows may be composed at any level as well as across levles. The necessary and sufficient conditions for interoperability are satisfied by composable (formal) diagrams both for intension and extension in categories that are cartesian closed and locally cartesian closed. Methods like partial categories and sketches in schema design can benefit from Freyd’s punctured diagrams to identify precisely type-forcing natural transformations. Closure is better achieved in standard full categories. Global interoperability of extension can be achieved through semantic annotation but only if applied at run time