Business Rules Friendly or not so Business Rules Friendly Business Concepts Modelling - Early Experiences from a Business Rules Project on a Digital Vaccination Recommendation Service

WHO estimated in 2002 that 1.4 million children in the world would die from preventable diseases (World Health Organization, 2010). Each child is, or should be, immunized according to their national immunization schedule, which regulates i.e. vaccines and doses. Problems emerge when immigrant children should be transferred from one national vaccination schedule into another. This problem is quite evident in Sweden (Statistics Sweden, 2010). Vaccination practitioners have a hard time figuring out how to immunize an immigrant child. As a remedy for this situation, the VacSam project develops a Business Rules (BR) centric digital service through principles of (BR Approach), for providing unique vaccination recommendations. The service is designed using a commercial BRMS (BR Management Systems), which require a business concepts model. Thus, the paper presents early findings on how a business concepts model could be designed more or less BR-friendly. We have discovered, by designing, that a rigid, relational model approach is not BR-friendly. Instead, the concepts model should be de-signed to provide rule clarity and understandability. Thus, we draw the conclusion that a con-cepts model designed for persistent data storing, favouring a good quality relational model, is not rule friendly

A service-oriented approach to embedded component-based manufacturing automation

This thesis is focused on the application of Component-Based (CB) technology to shop oor devices using a Service Oriented Architecture (SOA) and Web Services (WS) for the purpose of realising future generation agile manufacturing systems. The environment of manufacturing enterprises is now characterised by frequently changing market demands, time-to-market pressure, continuously emerging new technologies and global competition. Under these circumstances, manufacturing systems need to be agile and automation systems need to support this agility. More speci cally, an open, exible automation environment with plug and play connectivity is needed. Technically, this requires the easy connectivity of hardware devices and software components from di erent vendors. Functionally, there is a need of interoperability and integration of control functions on di erent hierarchical levels ranging from eld level to various higher level applications such as process control and operations management services. [Continues.

Architectures v/s Microservices

As it evolves, technology has always found a better way to build applications and improve their efficiency. New techniques have been learned by adapting old technologies and observing how markets shift towards new trends to satisfy their customers and shareholders. By taking Service Oriented Architecture (SOA) and evolving techniques in cloud computing, Web 2.0 emerged with a new pattern for designing an architecture evolved from the conventional monolithic approach known as microservice architecture (MSA). This new pattern develops an application by breaking the substantial use into a group of smaller applications, which run on their processes and communicate through an API. This style of application development is suitable for many infrastructures, especially within a cloud environment. These new patterns advanced to satisfy the concepts of domain-driven, continuous integration, and automated infrastructure more effectively. MSA has created a way to develop and deploy small scalable applications, which allows enterprise-level applications to dynamically adjust to their resources. This paper discusses what that architecture is, what makes it necessary, what factors affect best-fit architecture choices, how microservices-based architecture has evolved, and what factors are driving service-based architectures, in addition to comparing SOA and microservice. By analyzing a few popular architectures, the factors which help in choosing the architecture design will be compared with the MSA to show the benefits and challenges that may arise as an enterprise shifts their developing architecture to microservices

Best Practices for Implementing Agile Methods: A Guide for Department of Defense Software Developers

Traditional plan-driven software development has been widely used in the government because it\u27s considered to be less risky, more consistent, and structured. But there has been a shift from this approach to Agile methods which are more flexible, resulting in fast releases by working in an incremental fashion to adapt to the reality of the changing or unclear requirements. This report describes the Agile software development philosophy, methods, and best practices in launching software design projects using the Agile approach. It is targeted to Defense Department software developers because they face broad challenges in creating enterprise-wide information systems, where Agile methods could be used most effectively. Though not a panacea, agile methods offer a solution to an important class of problems faced by organizations today. Technology and E-Government

Proposing a Delphi-derived, inter-enterprise service-oriented architecture maturity model

Companies have long sought to integrate existing Information Systems (IS) in order to support existing and potentially new business processes spread throughout their “territories” and possibly to collaborating organizations. A variety of designs can be used to this end, ranging from rigid point-to-point electronic data interchange (EDI) interactions to “Web auctions”. By updating older technologies, such as “Internet-enabling” EDI-based systems, companies can make their IT systems available to internal or external customers; but the resulting systems have not proven to be flexible enough to meet business demands. A more flexible, standardized architecture is required to better support the connection of various applications and the sharing of data. Service- Oriented Architecture (SOA) is one such architecture. It unifies (“orchestrates”) business processes by structuring large applications as an ad-hoc collection of smaller modules called “Services”. These applications can be used by different groups of people both inside and outside the company, and new applications built from a mix of services (located in a global repository) exhibit greater agility and uniformity

Towards an understanding of business design within enterprise architecture management: a cautionary tale

Includes bibliographical references.Business Design represents a set of concepts that are described in the literature as providing a sound foundation for sustainable competitive advantage into the future. The particular values underpinning Business design are based on the enablement of a design thinking approach to solving the imponderable problems that organisations regularly encounter. In particular, the application of a design thinking approach to Business Design requires that resultant system designs are economically viable and technologically feasible. Enterprise Architecture Management plays a vital role in supporting these latter two requirements. Yet the definition of Enterprise Architecture Management as the 'normative restriction of design freedom' (Deitz, 2011) implies constraints that could impose limits on such business design. Consequently, the qualitative inductive research described in this document was undertaken to explore the perceived paradoxical relationship between Business Design and Enterprise Architecture Management. This dissertation recounts the process and results of this research initiative based on data recorded during interviews with a number of management level staff at a leading South African Insurance organisation. The participants were intimately involved in a programme to, amongst other objectives, establish a platform to support enterprise-wide Business Design within Enterprise Architecture Management, a programme that was experiencing a number of challenges and that was still underway at the time of completion of this research. Findings arising from this research were that the varying perceptions and levels of commitment of business and IT stakeholders associated with the programme and its requirements, contributed significantly to these challenges. In addition to providing a rich description of the case organisation's journey towards the establishment of a Business Design platform, a sensitising framework – 'The 6 Cs Framework in Support of the Successful Enablement of Business Design within Enterprise Architecture Management' – is proposed as a useful tool to assist organisations that might be considering a similar programme in the future