Published on 02/08/2017 | Technology
This article is Part 3 of the whitepaper Digital Enterprise Architecture in Manufacturing, following from Part 2 here.
To relate manufacturing data and control applications to an EA model, requires that the model and the data on the same level abstraction. Looking at standard EA models, which are mainly used for communication for strategic changes, a much lower level of detail is required or even wanted. While this strategic view is beneficial, a more detailed, related model is required to make a link to data and control applications. The expectation is to have a model, which describes a particular processes on different levels of detail for different user groups and different purposes.
The model has to be completely connected, i.e. different perspectives or abstraction levels are all represented in the same model and are related with each other. This makes the model more complex, but it enforces that the different perspectives and detail levels are not contradicting each other and therefore the model is consistent in itself.
While this is the goal to achieve this consistency in a model with highly increasing size, complexity, and implicit dependencies is a challenge and requires different ways of working. We mentioned the introduction of semantic models to support search of concepts (see Sec 5) and will address query capabilities in Sec 7.
The model is still used for communication, documentation and analysis, which again needs a visualization of the analysis results. In EA models, views are used to share a set of concepts and their relations. Also in big models views are essential to share insights derived from the model, which are built using queries. This enables the user to deal with large amounts of concepts and relations. Similar to storytelling in analytics, where different analysis results are connected to each other providing a line of reasoning, we expect that we will need a concept of relating views and attaching a line of reasoning to it.
As motivated above, the huge number of concepts in a model requires strong query capabilities to support managing and editing the model. Some experiments were done to define queries on EA models using a graph database. The proposal exceeds the current capabilities based on text search or finding concepts related directly to a selected concept. In this paper the focus is on defining the requirements rather than proposing a particular solution, therefore in the following different types of queries are presented which are expected to be helpful in managing large models based on usage scenarios.
Query 1: A user wants to see which test procedure (business process) related to the LIMS has produced the quality statement (business object) of a product class in the ERP. To answer this question, you have to identify the “shortest” path between a business process and a business object for a given product.
Query 2: A user wants to see what the changes between two versions of the model. It is easy to determine which concepts and relations have been added or removed. However, to understand the impact and the dependencies between additions and removals requires to associate or cluster these changes. The aim of the cluster is to provide an inherent semantic relation of modified concepts and relations. Potentially, these clusters should contain some context, that is, some unmodified concepts and relations, to make interpretation for a human easier. Thus, the underlying query is to identify clusters of changes between two views or plateaus which support the interpretation of changes by a human user.
Query 3: A user is looking for the model part describing the virtualization of the MES. Thus, the query is using the MES application concept in combination with the ”virtualization” model pattern, which has been defined by this company. The query result is a view containing the MES application and the relevant concepts relevant for the virtualization pattern. The underlying query is a sub-graph matching problem.
This list of queries is not exhaustive, but hopefully is an inspiration to think about new capabilities of EA tools. Further, many of the above queries will not result in a single query result, but will provide a list of possible query results. This is quite similar to Web searches, where you receive a ranked list of possible query results. Thus, besides finding possible results, the ranking of these results and limiting the query execution to find only the top-k queries is another technical challenge.
Further, the envisioned way of working is very interactive. Users ask queries to build the views they want to use. This interactive way of working means very high query performance requirements. However, most of the underlying generic algorithms to answer the above queries are NP (Non-deterministic Polynomial time)-complete, thus have a very high computational complexity. However, for many of the problems there are algorithms or approximations available with a much lower complexity under certain circumstances. It will be essential to understand these dependencies to make smart choices in defining model patterns as well as selecting the right storage engine supporting the optimized algorithms to get to a workable solution.
Besides query capabilities for editing or viewing the model, analytics can be performed on the model. The difference is that analytics is not intended to be used to edit the model, but generate new insights derived from the model. Often analysis results produce new data or new concepts and relations, which are included into the model again. While some analytics is already supported by some EA tooling, in the following some ideas for analytics are discussed as a means to spark ideas.
Analytics 1:. A moderator of the model wants to see how well the architects are actually using the model patterns. Thus, he can query for “almost” patterns and put the attention of the architects to the missing parts. Further he wants to see whether there are new emerging model patterns. That is, patterns in the model, which are not model patterns yet, but are used more and more by architects. The underlying analytics is a graph clustering problem.
Analytics 2: A project manager calculates KPI’s for a business transformation project based on available usage data of underlying infrastructure and applications to support the decision on a design alternative. This analysis combines utilization and usage data attached to different concepts in the model and therefore combines data and model elements in the analysis. The underlying principle of the analysis is a graph traversal algorithm.
Analytics 3: An architect has modelled a production process controlled by a MES from the point of view of the user interaction as well as the point of view of the information flow. Further, integrating process mining results adds the product point of view on the same process to the model. He now wants to check whether the three perspectives are consistent with each other. The challenge in this scenario is that the different perspectives are not describing the same process, but are expressing constraints on each other. Thus, the aim is to identify what are the constraints and whether they are fulfilled or not.
Again, the list of analysis is not exhaustive, but hopefully an inspiration to think further. While the analysis scenario is easy to describe, finding good and efficient algorithms for answering these requests is challenge.
Industry 4.0 (a.k.a. Industrial Internet) is big on agenda for many companies and their CxOs. According to McKinsey’s recent research 80 percent of companies expect Industry 4.0 to impact their business model. According to PwC digitized and integrated vertical and horizontal value chains is the nr.1 focus needed and initiatives to achieve this will grow within 5 years from 20% today to over 80% across all manufacturing industry sectors.
All of this requires major transformation in industry history, but this at the same time should be agile while giving the business insight and control.
Major analyst and strategist reports agree that manufacturing enterprises spending on Industry 4.0 initiatives will reach US$ 900 Billion/Yearly in 2020. Enterprises investing in this area right now often do not meet the expectations, because the transformation is to complex and/or the approach is to rigid.
Digital Enterprise Architecture could enable companies to manage and control digital transformation whether it is from process, architecture, application, system and or integration perspective to meet their business goals. The need to simplify and to have users in the center has become more urgent. Business, IT, Manufacturing IT and Manufacturing Operations represent distinct entities, with unique goals and challenges. Those users will have different types of interest, and users will not be just typical architects. As such a new generation of Enterprise Architecture solutions that support manufacturers in the digital era, should become an collaborative and interactive platform to serve the different roles that goes with each of the distinct entities, with the ability to give a holistic view.
As agility, speed, quality and cost are other key must have capabilities, new generation Enterprise Architecture solutions should empower manufacturers to understand the full impact and changes needed for digital transformation of their processes, architecture or systems within days, with the capability to implement and deploy this in weeks.
In this paper requirements for a Digital Enterprise Architecture in Manufacturing have been described. In particular, the aim is to combine data, data analytics and models to support each other. For users of the Digital Enterprise Architecture collaboration platform the challenge is to provide a solution that provides rich query capabilities to cope with scalable sizes of models. Finally, it is stated that looking for such a solution has a high impact since based on all strategy companies the market potential is available.
