Using Alfabet to address architectural challenges of IIoT solutions

Transformation leaders

Digital transformation programs are considered top priority at most organizations around the world. Although the benefits delivered by those programs are generally similar, the desired detailed outcomes depend on the sector or industry involved. For example, in manufacturing, leaders develop ambitious strategic transformation goals such as:

• Improving the efficiency of operations
• Developing new opportunities for competitive advantage
• Redesigning the most inefficient business processes
• Obtaining a full digital view of the entire product lifecycle
• Delivering increased value to customers using connected products and innovative business models¹

Solutions for digital transformation involve many different technologies and those including the Industrial Internet of Things (IIoT) are the most ubiquitous. To begin their transformation journey, enterprises typically launch pilots to test selected IIoT use cases in practice. In the manufacturing and asset-intensive industries, most enterprises have successfully finalized numerous IIoT-based pilot solutions. However, only a relatively minor percentage of those pilots have been rolled out across the whole organization.

In general, surveys indicate only 30% of enterprises managed to reach transformation goals in terms of business benefits or have made satisfactory progress in this direction. These organizations are transformation leaders. The remaining 70% of organizations, “followers,” are still planning their transformation, running the pilots; or have finalized them but cannot expand the pilots across the whole company.² The phenomenon of the obstacles preventing or slowing down IIoT-based rollouts has even earned a special name—pilot purgatory.

Pilot purgatory

There are many reasons why IIoT projects are stuck in the pilot phase, preventing enterprises from making progress toward their transformation goals. Probably the most common mistake is to begin the transformation program on the wrong foot, i.e. with the IIoT platform selection. The associated technical implementation topics overshadow almost everything else, so it is no surprise that little business value is achieved, as the business objectives are not defined in the first place.³

Experts agree such objectives should be defined at the very beginning, followed by careful selection and prioritization of use cases. Various research in the manufacturing and asset-intensive industries have also identified other reasons for slow progress toward transformation goals in follower organizations:

1. Insufficient budgets
   Transformation programs enjoy a high level of executive commitment with top management declaring them as top priority. However, this commitment is not necessarily reflected in adequate funding. Top management provides budgets for research, proofs of concepts, and pilots, but when it comes to solution rollouts, the financial burden ends up falling on the shoulders of the manufacturing plants.
   
   
2. Insufficient involvement of plant-level expert
   The top three IIoT use cases—remote monitoring, remote maintenance and predictive maintenance of assets—involve direct use of technologies on the shop floor. Yet, plant-level experts and management are all too often not sufficiently involved.⁴
   
   
3. Complex, heterogenous environments at the plant level
   In the past, suppliers of industrial machinery and equipment preferred to use their own proprietary software. The older a machine is, the more likely it uses a proprietary communication protocol as well. Above the lowest level of the industrial automation stack, dedicated software systems are used. As plants usually make their own software purchasing decisions, the level of standardization of this software tends to be also low.

It is worth noting that overall complexity is significantly increased when IIoT layers (see Figure 1) are added on top of plant or facility environments. If the classic IT environment would be added to this picture, the resulting overall landscape would be truly mind-boggling.

Insufficient collaboration

There are many more reasons for rollout failures of IIoT-based solutions and certainly some of them manifest simultaneously in most enterprises.⁵ Nonetheless, there is one additional reason for slow progress in scaling up IIoT pilots, and it is quite an important one. Specifically cultural issues and change management in general are cited as one of the most frequent transformation challenges in manufacturing and asset-intensive industries.⁶

Until the advent of IIoT, information technology professionals at the corporate level and technical experts on the plant, facility or building level operated independently. Due to different backgrounds and job requirements, there were and still are cultural differences between those two groups, inevitably leading to tensions.

In the past, such a conflict could be somewhat tolerated and caused relatively little harm. IIoT however makes effective cooperation of those two groups a necessity.⁷ Therefore, one can safely conclude that if there are problems in scaling IIoT-based solutions, insufficient cooperation of IT professionals and technical experts is most likely to occur.

Different technologies

Information technology (IT) covers all technologies for data collection and information processing, including software, hardware, communications technologies, and related services. In manufacturing and asset-intensive enterprises, IT typically includes systems such as ERP, CRM and enterprise asset management (EAM) systems. Facility management software systems are also part of IT, as well as data centers and corporate communications networks.⁸ Operational technology (OT) in turn encompasses hardware and software that detects or causes a change through the direct monitoring and/or control of industrial equipment, assets, processes and events.⁹ It is embedded in operations and assets in industries ranging from manufacturing, pharmaceutical and utilities to oil and gas. OT is also embedded in buildings, shipping systems, and air traffic control infrastructures.

Examples of software dedicated to OT include manufacturing execution systems (MES), supervisory control and data acquisition systems (SCADA), and distributed control systems (DCS), all collectively labeled as industrial control systems (ICS). OT also includes building management systems (BMS) for facilities. On the hardware side, OT encompasses industrial computers, programmable logic controllers (PLCs), sensors, industrial Ethernet networks, as well as a plethora of proprietary programming languages and protocols.¹⁰

IT and OT divergence

There are many fundamental differences between IT and OT. Their roots reside in the organizational separation of professionals dealing with corresponding technologies, different missions and evolutionary paths of those technologies, as well as many other factors.¹¹

IT deals with data. Its evolution has been driven by standards and short innovation cycles, with the next revolutionary technology discovered every two or three years. IT computers operate in comfortable office environments and data centers. IT hardware is replaced usually after several years. IT security is focused on operating systems and networks, showered with a constant stream of upgrades and patches.

OT deals with machines and equipment. Its software was engineered for proprietary devices, and standards began to emerge only recently. OT hardware is expected to last 10-20 years, working in sometimes harsh conditions on the shop floor. Software patching and upgrades are performed reluctantly and preferably deferred for as long as possible. The main concerns of OT security are physical in nature, and the concept of cybersecurity is relatively new in this area.

Most of all, IT and OT areas are usually separated organizationally. IT is usually centralized on a corporate or business unit level, while OT is distributed across plants and facilities. Experts from those areas have different educational backgrounds, different skill sets and use different professional languages. However, in the first decade of this century a call to integrate these two areas gained momentum, particularly in asset-intensive industries.¹² Important benefits expected of IT/OT integration were:

• Improved automation, sensing, and visibility of operations
• Increased control over distributed operations
• Better compliance with regulatory requirements and tracking
• More responsive systems and improved organizational performance
• More effective use and optimization of the involved workforce
• Better strategic decisions based on more timely and accurate information
• Improved customer satisfaction, resulting from increased proactive maintenance and reduced response times

Convergence imperative

While the calls for IT and OT convergence were based mostly on the merits and benefits of such integration, the arrival of IIoT changed this ‘good-to-have’ feature into an essential, outright necessity for transformation efforts. Effective connectivity of devices within plant or facility communication networks, collection and transmission of the operational data, analysis of this data to support decision making on various levels, and finally using this data in business systems—all this enabled by IIoT platforms— simply cannot be achieved without IT and OT integration. Such an integration is driven additionally by several trends, such as:

• Industrial connectivity, using dedicated hardware and software, causing a faster increase in the number of connected assets
• The large number of industrial connectivity vendors
• The emergence of new edge-to-cloud architectures (see Figure 3)
• The use of hardware-agnostic software by small and midsize industrial automation vendors challenging entrenched incumbents, such as Siemens^®, Schneider Electric^®, Rockwell Automation^® and ABB^®
• The emergence of new standard protocols for industrial connectivity, a necessity for IIoT-based solutions¹³

Dimensions of IT/OT convergence

Convergent communication networks, coupled with the new IIoT technologies mentioned above, are the ultimate technical enablers of IT and OT convergence. However, support on the technical side is not enough.

While a decisive majority of IIoT projects are IT-led or sponsored, such projects inevitably include OT experts. Therefore, to ensure success, smooth collaboration of IT and OT experts is needed. This in turn requires active leadership to support cultural change and creation of shared governance models. It requires also cross-training of professionals from both sides to build a team of IT and OT resources familiar with their opposite disciplines.¹⁴

The classic divisions between IT and OT are blurring nowadays. However, technical, organizational and human IT/OT convergence enablers are not enough to facilitate faster, successful rollouts of IIoT-based pilot solutions. What is missing is the architectural foundation for IT/OT integration or convergence. Moreover, such an architecture must also take business side of the whole company into account. Therefore, the ultimate recommendation to expedite transformation progress is to jointly design business and IT/OT technology architecture. Such a comprehensive architecture would serve as a foundation for selection of use cases, pilot scoping and solution rollouts.¹⁵ Such an architecture would also be indispensable for evaluating and dealing with the complexity of the IT/OT foundation. The same goes for the relationships of its myriad components with cross-functional business processes. Finally, such an architecture would make it easier to deal with cybersecurity concerns at the corporate, business unit, plant and facility level.

This view is supported by the latest research. It recommends, apart from a converged IT/OT organization and culture, a converged technology architecture. Specifically, to succeed in transformation programs based on IIoT-based solutions, companies must appoint a cross-functional team to identify business challenges and define use cases, as well as to select technology requirements. This should be followed by development of operational architecture as a foundation for all future technology decisions and roadmaps.¹⁶

Digital transformation and EA

The potentially leading role of the enterprise architecture (EA) practice and teams in achieving successful digital transformation was proposed several years ago. Digital transformation introduces changes to the business architecture as well as adds many new technologies and applications. The resulting increased complexity of the IT architecture makes it harder to manage, which in turn makes transformation efforts more difficult.

A McKinsey survey on digital transformation looked at the role and contribution of enterprise architects.¹⁷ While management of IT architectures is commonly a responsibility of EA teams, the survey focused on how EA teams facilitated successful transformation at the business level at companies considered digital leaders. The survey identified several key complementary best practices:

1. Involvement in development of business strategies
   EA teams in most digital leaders had high levels of interaction with stakeholders such as top management and strategy departments. This interaction turned out to be a 2-way street. On one hand, EA teams invested more of their time to understand business needs and convince top managers to explore EA topics. On the other, top managers understood the importance of technology for their business models and committed more of their time supporting and making technology decisions with the EA teams.
   
   
2. Emphasis on strategic IT planning
   EA teams at all digital leaders had responsibility for developing and maintaining a target IT architecture to be used as an input to strategic IT planning. These teams spent more time than the average EA team on strategic IT planning. This emphasis increased the likelihood of delivering sustainable business solutions and led to greater share of those teams in delivered benefits. Such emphasis resulted also in wider recognition of EA teams within companies.
   
   
3. Focus on business outcomes
   In a nutshell, digital transformation depends on changes in business models and processes enabled by advanced digital technologies. Business and IT collaboration is always beneficial. In digital transformation, however, such cooperation is critical. Technology solutions cannot be treated as end results and the expected business outcomes need to be defined first. At companies perceived as digital leaders, EA teams delivered valuable contributions not only to IT, but also to the business.
   
   
4. Importance of business capabilities
   The survey confirmed usefulness of a business capability architecture when used as a basis for strategic IT planning. Survey participants from digital leaders were more likely to report use of capabilities as the business context for technology solutions delivery.

All the above best practices are really variations on the theme of business architecture as a requisite and overriding layer. For EA teams, supporting digital transformation using a business angle is a great opportunity to embrace business and IT concepts and successfully merge them to achieve benefits on the company level. As IIoT-based solutions constitute a subset of digital transformation results, the EA discipline should also be ready to tackle the challenge of IT/OT integration and promote collaboration between business, IT, and OT.

Operational architecture

A pragmatic, partial solution to the most pressing IT/OT integration challenges was developed by experts at LNS, an advisory company specialized in industrial transformations. Particularly, the concept of operational architecture was developed using EA concepts as a source of inspiration.¹⁸ As a general framework, the levels defined in the ISA-95 standard were used, while the operational architecture (OA) objectives were defined as follows:

• Identify the technology and data architecture which will support transformation efforts and thus achieve strategic objectives
• Identify the process and organizational changes required to leverage investment in IIoT and other technologies
• Secure buy-in for the identified process and organizational changes
• Manage the complexity of the OT landscape

The OA is a key element of the LNS framework recommended for IIoT-enabled transformation efforts being undertaken in various industries.¹⁹ Such an architecture is particularly important when the new IIoT-enabled solutions will:

• Interface plant floor devices and industrial automation control systems (IACS) with classic IT software, such as ERP or supply chain management applications
• Support multiple users in operations and specialized functions like quality management and environment, health and safety
• Replace legacy applications with IIoT-enabled technology to profit from big data potential²⁰

Convergent DEA

An operational architecture concept is definitely very valuable. However, such an architecture alone is not enough and should be supplemented by both business-oriented and IT-oriented architectures. The result should be the already mentioned convergent digital enterprise architecture (DEA), the ultimate foundation for IIoT-based solutions and enabler of effective IT/OT integration.

Just as EA concepts can be applied to the OT domain, software tools for governance and management of the architecture can be used for governance and management of OT as well. Specifically, mature EA management software can catalog assets, devices and relevant software, it can also support analysis of their usage. Such a software can also expose impacts of change on business, IT and OT. Furthermore, its life-cycle management, planning, and portfolio management functionalities can be used for transformation planning as well. This approach is strongly recommended due to the complexity of IIoT-based transformation programs.²¹

To sum up, the ideal EA software to support this all-encompassing approach should have all these capabilities. It should also fulfill the unique requirements of such a comprehensive architecture.

IT/OT complexity

The primary mission of any enterprise-wide architecture is to allow its governance and to manage change that external and internal factors imply. Classic enterprise architecture is complex enough to justify use of a dedicated, specialized software. An all-encompassing convergent DEA is much more demanding and justifies use of such a software even more. This should be facilitated by the architecture repository and a thoughtful configuration of its meta-model.

Convergent DEA makes the architecture much more complex for several reasons. The architecture needs to be relevant and easy to use for a wide range of stakeholders, including CIOs, CTOs, IT planners, enterprise architects, solution architects and business managers on all company levels. In addition, the architecture should support the needs of plant managers, facility managers, OT professionals on plant/facility levels and many others depending on industry. For that purpose, in addition to classic business and IT items, it must include representations of such elements as MES, SCADA and BMS systems, IIoT platforms, gateways and devices, as well as PLCs, industrial network elements (see Figure 6) and ultimately a plethora of locations, sites, buildings and machines.

Traceability

Such an inevitable complexity makes traceability a necessity. Traceability in practice means that each relevant component of the repository is connected, which allows anyone to evaluate how physical assets contribute to value creation across the enterprise. Moreover, the architecture must ensure full traceability between business value and all the objects within the repository, down to the level of individual technical components, including sensors, machines and equipment.

In traceable architecture, each view is based on the state of a complete/interdependent set of elements, thanks to the relationships defined in the repository. The complexity can be hidden if it does not add value to the desired perspective. For example, if the desired perspective requires demonstration of components contributing to achievement of particular business objectives, this can be achieved by filters and report configuration. When creating reports or live dashboards, the traceable, interconnected architecture facilitates navigation between all objects in any direction along the defined relationships. Completeness of these relationships guarantees the integrity and flexibility of the architecture, while enabling distributed maintenance of the model by the responsible roles.

Architectural principles

Despite such an increased scope and complexity, the architecture must be still easy to govern and use. There are certain key principles pertaining to the use of an architecture repository which help to achieve this. Those principles have been defined based on EY experience in convergent DEA projects and are summarized in the picture below.

In addition to the above principles, there are additional ways to ensure a more powerful convergent DEA. In the first place, it must be ensured that the repository is able to adopt to change faster than the most dynamic element of the architecture, which is usually the edge. Examples of techniques to achieve this include:

• Defining lifecycles for all relevant object types, leveraging time analysis and monitoring functions of the repository
• Creating abstractions by use of object types covering wide ranges of objects distinguished by their attributes (i.e. logical application component)
• Grouping of entities sharing common features (i.e. software and hardware sharing the same location)
• Connections with external repositories of content management systems (CMS), EAM software, configuration management databases (CMDB) and potentially many others

Architectural concerns

Another practical way to provide high architecture usefulness is to define perspectives and attributes to directly address specific architectural concerns. Those concerns include for example scalability, performance, operability, maintainability, security, availability and portability. The ability to define perspectives as a scope of objects and selection of relevant attributes is an extremely powerful mechanism. However, to make this mechanism effective, one should define/reuse only the attributes relevant for the architectural concerns. The remaining standard attributes defined in the meta-model should be hidden. It is also advised to mark the crucial attributes (i.e. security) as mandatory when creating object instances.

Meta-model

While customization of the meta-model cannot be avoided, special care must be taken to keep it as simple as possible:

• Separate object types should be used for logical and physical objects. In other words, for every physical object in a repository, there must always be a corresponding logical one. For example, a physical application component, with a version and defined vendor, has a corresponding logical application component, which generalizes a grouping of delivered functionality
• One should always ensure it is possible to create tree-like structures of all object types and use them for services, locations, contexts, application components, technology components and processes
• Complexity should be hidden by minimizing the number of object types and transferring the distinguishing features into attributes of objects of the same type. For example, object type “Actor” can be used to represent a role, a person or a whole organization. If this is not possible, then using stereotypes based on existing object types is preferable to creating new object types
• The object type “Service” should be used as the focal point to represent the composition of functionality, datatypes, providers and consumers
• The concept and object type “context” should be used to logically group objects by relationships. This is especially important in modeling IIoT systems that have numerous instances of objects that are unrelated except for one feature (e.g. sensors deployed on vehicles, machines and buildings as elements of different solutions but having the same firmware)

Architecture and security

The convergent DEA must also address a key architectural concern, namely security. The security of IIoT solutions can become a very complex problem if it is not treated in a consistent way. Traditionally, industrial environments were protected by isolation from external networks. This can lead to islands of security solutions that are redundant and can have multiple security gaps introduced by modern IIoT devices. Additionally, due to the diversity of industrial devices and protocols, this approach can lead to restricted security solutions, using only the lowest common denominator technologies.

IIoT solutions address this with the separation of contextual data, also known as metadata or context. This is a complex problem, which is outside the scope of this paper. One of the ways to address it is to define a set of attributes, such as criticality and trust levels, security domains, capabilities, controls, policies, etc. for each object type as shown below.

Convergent DEA tool

Alfabet, an established EA management product provided by Software AG, is fully consistent with the principles mentioned above. It has a proven architecture repository capable of handling the complex dynamics and scale of a convergent DEA. Alfabet provides nearly all required capabilities out-of-the-box, while only some require a modest degree of additional configuration. The meta-model flexibility, freedom to create relationships, distribution of responsibilities for data entry and update, as well as satisfactory performance when working with repositories consisting of millions of elements, are its most important technical capabilities. An interesting additional and useful feature is the ability to define attribute types on the fly without the need to configure changes in the meta-model. All the above are necessary for governance and management of convergent DEAs.

In addition, Alfabet provides other capabilities suitable for transformation programs in the IT/OT domains:

• Management dashboards and drill-down mechanisms for top-down exploration of architectures, beginning with a corporate-level overview of security status for example
• Risk management capabilities facilitating planning and implementation of mitigation efforts to reduce the possibility of security breaches
• All the portfolio planning capabilities required to plan and track complex, corporate-wide transformation programs
• Flexible integration with any number of external repositories
• Standard interface for a device management platform

Project background

The usefulness of Alfabet to model and maintain a convergent DEA was validated during a pilot project for a very large global company, a customer of EY and Software AG. The company has a high market capitalization, significant head count and is geographically dispersed on six continents. It operates a heterogenous, diverse set of facilities—legacy and modern, built from scratch and acquired as is, networked and hardly accessible. Its facilities use diverse technologies available locally in the corresponding region or country. In terms of the EA, the company has an effective, centralized practice with a well-defined structure and processes. The company uses Alfabet, a product of Software AG, as the software to handle the architecture repository.

The company initiated an ambitious digital transformation effort and one of its strategic initiatives was implementation of an IIoT-based solution for its facilities. Specifically, the initiative was to monetize the indirect value of existing assets and data, regardless of the maturity levels of its facilities. This was justified by investments already made for operational purposes. The facilities already had deployed BMS systems, various instrumentation (sensors, controllers etc.), analytics, and several backoffice systems. The supporting organization and processes were in place, but with very different levels of maturity—from basic deployments packaged with technical solutions (i.e. a BMS-like control system deployed with HVAC equipment upgrade) to a state-of-the-art deployment of a Smart Campus concept.

EAM tool

A pilot project spearheaded the strategic initiative outlined above. Its objective was to demonstrate measurable business benefits in energy efficiency via implementation of an end-to-end IIoT-based solution in half a year. During the first phase of the project, working sessions captured the following:

• Around 20 business goals to be achieved by implementation of the IIoT solution
• Around 70 business objectives and KPIs to measure goal achievement
• Around 70 business capabilities required to realize goals and objectives
• Over 200 technical and analytical capabilities needed to deliver the business capabilities

The EY team recognized at the very beginning that clear governance principles and a robust architecture were crucial to managing the complexity of the business and technology landscapes.

Use of Alfabet for the project as an enabler of the IIoT-based solution was proposed at the outset. However, one of the challenges was that there were already two independently developed meta-models and repositories in use. One was transformational and business-oriented. The corresponding architectural repository was partially integrated with the ARIS repository of business process architecture and maps. The other meta-model was technological, application-oriented and very extensive. Its corresponding repository was integrated with the CMDB. The two meta-models were not integrated, were used for different purposes and both were based on the Alfabet standard object types. Ultimately, this led to over 200 object types being used inconsistently. This prevented effective modeling of the energy efficiency business aspects and made it difficult to link them to processes, assets, and data in a coherent manner.

During the project, a new end-to-end meta-model was defined. It allowed for full traceability of business objectives, along with the associated KPIs and assets, including numerous physical IIoT/OT assets. The new meta-model was also much simpler than the two legacy meta-models. This had been achieved mainly by applying the principles discussed in the previous chapter to drive the development of the new, universal meta-model.

Deliverables

The early adoption of Alfabet as a tool for convergent DEA, and subsequently as an enabler of the whole solution, made it possible to achieve the project’s objectives. Specifically, the following deliverables were deployed and integrated with the IT/OT landscape:

• Browser-based dashboards for the near-real-time business KPIs of the IIoT solution
• An analytical engine providing the input for dashboards based on the IIoT data
• An IIoT platform that manages and routes the data streams from the field
• A tailored API common for integration with all the edge systems (i.e. BMSs)
• Edge gateways providing internet connectivity and physical edge integration, including a protocol bridging both the systems (BMSs) and the sensors as required
• Additional edge sensors for insufficiently instrumented locations

The implementation integrated the data from two physical locations in two countries with three IIoT gateways, deployed to connect two clouds (a hybrid cloud in Microsoft^® Azure^® and private cloud at a selected hosting site). The back-end integration included links with weather data sources, asset management, configuration management, and an external data consolidation platform for some of the data on the buildings.

Results

There were 335 sensor data streams in total, the majority coming from two BMSs and some directly from sensors; the bridging protocols included OPC^®, BACnet^®, C-Bus^®, and raw data mapping. The available historical data was utilized to improve the initial quality of the analytical model for energy efficiency. During the first three months of running of the solution, there were eight action items identified to improve the overall efficiency without affecting the comfort of the building occupants. This led to significant energy costs savings.

The usage of the convergent DEA enabled full traceability of business KPIs, consolidated into two crucial measures:

• Relative spend for energy (compared to historical performance and in the context of outdoor conditions)
• Level of satisfaction with the environmental conditions at the managed facilities as reported by the building occupants

Both measures were displayed in near-real time as simple dials for the sites in scope, completely hiding the complexity of the data sources and required analytics. The dashboards provided the ability to drill down through the data consolidation layers, down to the individual sensor level. The platform offers selection by the location levels specified within the model (i.e. room, building, site, region, enterprise).

Summary

The Alfabet EAM tool was successfully used to support development of a pilot IIoT-based solution at a large global company. A structured, architecture-driven approach allowed development of an end-to-end energy efficiency solution within the project’s 6-month timeframe. After establishing common terminology and the meta-model, all layers of a convergent DEA were modeled in Alfabet. The model was fully traceable, i.e. one could navigate from the strategic goal through business motivations and KPIs, business processes, business and technical services down to the smallest physical technology components.

Based on the convergent DEA, a swift integration of buildings and their IT/OT systems was performed using an IIoT platform designed and implemented for the initiative. As part of the platform, a portal was deployed to allow for near-real-time monitoring of the energy efficiency, using the selected business performance indicators. Implementation of the IIoT-based solution opened the way for significant energy savings, while Alfabet proved to be the key to managing the complexity of the solution and the technical IT/OT integration.

EY is a global leader in assurance, tax, transaction and advisory services. The insights and quality services we deliver help build trust and confidence in the capital markets and in economies the world over. We develop outstanding leaders who team to deliver on our promises to all of our stakeholders. In so doing, we play a critical role in building a better working world for our people, for our clients and for our communities. EY refers to the global organization and/or one or more of the member firms of Ernst & Young Global Limited, each of which is a separate legal entity. Ernst & Young Global Limited, a UK company limited by guarantee, does not provide services to clients.

Information about how EY collects and uses personal data and a description of the rights individuals have under data protection legislation are available via ey.com/pl/pl/home/privacy. For more information please visit ey.com.

References