A large European Energy Distribution Company (EDC) needs to adapt to the new state regulations. To do so they need to have a much thorough understanding of their stakeholders (customers, partners). This understanding is captured in data that needs to become a strategic asset. We explain how the concept of business object is used in organizing this data across the whole company. We also illustrate the key factors for success.
2.1
EDC 2.2 EDC is a European energy distribution company. EDC performs daily its missions by managing the energy network, connecting, and delivering energy to millions of customers (end-users) in a European country. EDC designs, builds, operates and maintains a large distribution grid. Thousands of municipalities are connected. EDC has thousands of employees. EDC cooperates with many different actors in its environment, this is why our example (in Section 5) explicates the concept of a third party. The main actors, with whom EDC interacts, are described in this Section. 2.2.2
Energy suppliers produce, import and market the energy. They have a distribution contract with EDC; it guarantees to their suppliers a fair access to the distribution network. EDC transports the energy from the production points via the energy transport grid to the consumers. For this service, it charges distribution fees to the suppliers. 2.2.3
Energy distribution is the duty of each city. They own the infrastructure and grant a right to EDC to use and maintain their infrastructure. 2.2.4
2.3
Individuals, companies, and public organizations purchase and consume energy. EDC needs to guarantee a reliable and safe supply of energy, regardless of their suppliers.
EDC works with numerous professionals to help manage energy, including people who own, finance, build, maintain buildings, as well as the professionals involved in planning, setting up and maintaining energy related equipment. EDC is organized as follows: • The regional organizations manage their own grids and stakeholders (e.g., customers, cities). Each region has a management and a local IT group. • The central management is responsible for best practices and governance.
• The Central IT Group (CIG) supports central management and regional organizations.
The mission of the CIG is as follows: • To actively support EDC’s business strategy, through the evolution of the information system; • To manage the development projects to fit the users’ needs; • To manage and maintain the applications; • To provide a secure and reliable IT and telecom environment to all EDC employees; • To coordinate the regional IT groups.
The CIG manages hundreds applications and has a bit more than one hundred development projects. Approx. a thousand people work in CIG (three-fourth being subcontracted). 3
The energy transition has reduced the consumer’s energy consumption, thus leading to a reduced revenue stream for EDC, which could cause difficulties in maintaining the quality and safety of the distribution network. New regulatory requirements (such as open data) has also affected EDC’s future. Furthermore, companies, who sell different kinds of energy, could use EDC data to influence EDC’s consumers to leave the energy, hence further reducing the revenue stream of EDC. Lastly, for this European country to be less dependent on foreign sources of energy, EDC could become instrumental in developing local green energy production. In this Section, we elaborate on these challenges. 3.1
With the deregulations introduced in early 2000, the goal of the regulator was to have an energy distributor, fair to all suppliers and not visible, from a marketing standpoint, to the energy consumer.
Approx. ten years later, it was decided by the regulators that EDC, being closer to the customer than the suppliers and having the best knowledge about their customers, should become more visible to the consumer. In order to do so, EDC had to learn and manage even more information about the energy end-users. EDC also had to better coordinate the community of energy professionals (i.e., engineering companies, architects, owners). Hence EDC confirm its position as a main actor in energy transition. Now EDC’s goal is to promote a varied usage of energy, and to disseminate best practices in energy management; hence maintaining their revenue stream in order to have the resources to maintain their distribution network.
Furthermore, the new energy intelligent-meter, which will be fully deployed in a few years, will send daily detailed consumption data. The analysis of these data is a challenge for the control of energy consumption and the knowledge about the customers. The analysis is useful for understanding how to gain customers and why the customers – sometimes – choose other forms of energy. 3.2
One of the strategies of EDC is to cooperate with local authorities and non-governmental, energy-aware, associations. The goal is to help them better manage their use of energy. This involves providing detailed and accurate data on energy generation, consumption and distribution. This is also compliant with the European Regulations on Open Data, in which many local authorities are involved. By law, EDC needs to provide: • Daily energy-consumption information provided to the consumer and to any authorized organization; • Yearly energy-consumption information provided to owners and real-estate management companies; • Yearly energy-distribution information provided to organizations who own the distribution infrastructure, typically the local authorities who grants the right to use them; • Aggregated yearly energy-consumption information provided to city councils with a data granularity related to city, regions defined by the state statistical agency, buildings and public and private companies (who own buildings). All data-bases of the public organizations (or associations considered as public) should be on-line, and freely and easily accessible. Exceptions exist to preserve privacy for both the individuals and the enterprises, as well as to ensure security. 3.3
EDC has opportunity to develop a new green energy. The management of these new producers require new kinds of information, such as a descriptions of the green energy producers, as well as of the new equipment necessary for the distribution network (meters, network elements, …). 4
A few years ago, the EDC’s information system had a business architecture (representing business processes, and the functions provided by IT) and a technical architecture (representing applications, components and exchanges between applications and components). But, these two architectures were not always aligned. The connections between the business processes and the applications were documented. However, it was not clear which data were used where, who was the data owner, and where the master data was located. First, a data-architecture project was launched. An architecture group, specialized in data, was created to help coordinate EDC business and IT activities. Then, due to the new regulations, it became clear that the data were strategic to EDC’s challenges. In this chapter, we document the main actions taken to make data strategic. 4.1
First, two additional teams were created: • The Data-Architecture Team is a team of 4 people in charge of modeling the business object, and of creating the exchange format (an XML file that contains “standard data”). This team also develops a data cartography and provides architectural recommendations on data management. They promote the best practices in terms of data governance, the identification of the master data, and the definition of the master data management (MDM) policies. • The Enterprise-Service Team specifies the SOA services used by the enterprise service bus (ESB) to exchange data.
They use the data models developed by the Data-Architecture Team. Other, already existing, teams manage the services implementation and the enterprise service bus. 4.2
Then, when more powerful uses of the data by the business divisions became strategic, the EDC CIG created three more teams: • The Data-Repository Team manages raw operational data, that are transformed to be compatible with the businessobject format. This transformation is made in a “normalization zone” in which the data are transformed from operational data to business data. It is these business data that can be accessed by the business users, through visualization tools. The system insures compliance with data-privacy regulation. • The Big-Data Team uses big-data technology and experiments how big data can bring value to the organization, for example, by explaining why people choose other forms of energy. They also experiment on improving the distributionnetwork reliability by using preventive maintenance. • The Data-Management Team was created by the business divisions. The team is responsible for defining the EDC business and technical strategies on data management (especially on open data). The existence of this management team was instrumental in making the overall organization aware of the importance of data management. 5
The business objects are central to the data strategy of EDC; they are also central to the on-going architectural efforts to structure EDC’s IT system. The business objects are used in different architectural descriptions. There are at least 3 descriptions: • The description of the business architecture, in which business processes are represented, uses business objects (data in a context). • The description of the IT functions, in which the functions are described independently of which application provides them, references business objects. These functions are organized in a cartography that groups them by domains (e.g., energy-network design, energy-network operation, HR, finance, …). Each functional domain is built around one or more business objects. • The description of the application architecture, in which applications, components and data exchanges are represented, also references business objects. The data exchanges are described using exchange formats that are closely related to the structure of the business objects.
The business objects are considered orthogonal to all these descriptions. They are defined in a business-object model. Each description (business architecture, IT function, application architecture) represents where the business objects are created, how they are manipulated and exchanged. 5.1
A business object is a concept that is used by one or more business domains in a company; it is an important concept necessary for supporting the cooperation between these domains. A business object • is created, as a consequence of a business event, in a business process; • is read and updated within the business processes; • is almost never deleted, because a business object is usually recorded forever, for legal reasons.
A business object has the following ontological properties: • Structure – a business object has nodes that have attributes and associations with other nodes (in the same or in another business object). A business object has operations that enable access to and manipulation of nodes, of attributes and of associations. A business object represents a business entity in its overall lifecycle. • Boundary – a business object is defined by a set of nodes. All nodes that belong to the same business object are within the boundary of that business object. Associations between nodes in different business objects cross the boundary.
Usually, a “main” node gives the name to the business objects.
Associations and inheritance relationships add “specific” information to a node. For example, a Third Party can have an association with one or many Structure (the association is the line between Third Party and Structure in Figure 1).
The Structure can be of two kinds. This is captured with the inheritance relationship. For example, in Figure 1, the arrow going from Legal Structure to Structure. This means that a Legal Structure is a Structure. This is why this inheritance relationship is also called sometimes an “is-a” relationship. In Figure 1, we show that there are two possible structures: • The Legal Structure describes the legal information about the Third Party, for example, sole proprietorship, limited liability company, corporation, cooperative; • The Ontological Structure captures the business semantics associated with the business object, for example, additional information necessary for business processes.
A Third Party is a stakeholder, identified in an unambiguous manner, operating in one or more relationships related to the activities of the EDC value-chain. These relationships can be: • Contractual relationships (e.g., the Third Party is a Customer or an Energy Supplier); • Marketing relationships (e.g., the Third Party is a prospective customer); • Partnership relationships (e.g., the Third Party collaborates in EDC’s business processes); • Regulation Relationships (e.g., the Third Party is a regulatory authority).
The simplified model in Figure 1 captures only one of these relationships: the contractual relationship (EDC Organization with the Energy Supplier or EDC Organization with the Customer). So a Contract is between a Third Party (either Energy Supplier or Customer) and a EDC Organization. The model shows that there are three kinds of contracts. For example, the Connection Contract (which “is a” Contract) is between a Customer (who “is a” Third Party) and a EDC Organization.
Business objects can be complicated. For example, a Third Party can have subsidiaries. The composition (or aggregation) relationship that connects a Third Party to many of its component Third Party captures this fact. This is the association with the diamond shape in Figure 1.
The business objects are used by the architects to represent the main information managed by the business processes. Figure 2 illustrates this fact, the Connection Contract in Figure 1 and in Figure 2 are the same concept.
The business objects are then used to develop applications. In this case, the business object is “de-normalized” to fit the needs of the application developer. A data object can become information in proprietary tables in a packaged application, or might be implemented as-is in a full custom application developed from scratch.
The approach described here is based on the concept of semantic networks. The business objects, the nodes, and the attributes make a two-level network (one level being at the business object level, one at the node level). The approach has similarities with the one described in (Abramowicz08); their business-object structure is similar but their focus is different as their goal is to develop and automate business processes; as opposed to our goal that is to provide data to the business division. A similar difference exists between our work and (Redding09). 6
With the popularity of the data repository and of the Big-Data Team in the business, and with the creation of the business DataManagement Team, the data project can be considered a success. Currently, approximatively 20 business objects, including 200 nodes and thousands of attributes and relations, are defined and described. They are now used in IT projects and for exchanging data between applications. We consider that three teams were decisive in the success of EDC’s data project. 6.1
Due to the business objects, it was possible to develop a cross-organizational shared vision. The business-object model acts as a common language within and between organizations.
Within IT, the business objects bring the following values: • In project scoping: The business object provides a granularity level and the base vocabulary necessary for identifying the perimeter of projects. In addition, the granularity of the business-object model is similar to the one used in the IT system cartography, hence the use of the business objects immediately defines the project’s scope in a way that many organizations understand. • Data exchange: Business objects can be represented in an XML schema that are mapped to the services used to exchange data between applications (SOA approach). Hence, conceptualizing the business and the IT system as working with business objects improves significantly the interoperability between applications. •
Master-Data Management (MDM): Using the business object helps to find where the reference data is and to identify which MDM tool should be used to reference the master data. This improves the overall data quality.
Business objects are a common language for the IT groups that build the IT system: • The business architects document the business processes, update the functional description in the cartography, and identify functional exchanges in which business objects are transferred. • The data architects define the business objects and XML schemas involved in exchanges and services. • The service architects define the services that manipulates business objects. • The ESB developers configure and build the enterprise services and manage the enterprise service bus that exchange business objects. • The application developers create applications and configure off-the-shelf packages, by using ESB in the case of shared business objects.
• The data repository developers use business objects to store and visualize data.
The business divisions also benefit from the following features: • Date use: The EDC infrastructure is setup in a manner that when business objects are used, exchanged and referenced, they are automatically planned to be stored in the data repository. The development roadmap is updated. A few releases later, the business objects are available in the data repository. This brings much added value to the business people, as the data assets are then exposed through the data visualization tools. • Shared vocabulary: As all business divisions are exposed to the same business objects, a common object-model begins to emerge among all of divisions. As a result, all divisions begin using a shared vocabulary. • 360° view: A concrete outcome is the seamless development of the 360° view. Describing the associations between one central business objet and the related ones, helps to discover the different “faces” of the 360° view. For example, the “faces” of a Customer business object can be the apartments/ houses the customer has, the total consumption, all metering equipment used, etc. So, without significant efforts from the business divisions (other than accepting the business objects), transverse views can be developed. 6.2
Quite a few years back, the Data-Architecture Team managed a business-object project in a different company. The businessobject project covered the entire energy value-chain (development of energy source and production, transportation by energy network, selling to customers, distribution, and trading). The target audience was traders, analysts, contract managers - people used to working with models (market models, economic models). The business objects were defined on a purely business level, regardless of the IT projects and applications. The advantage of this approach was that the team could work at their own rhythm, which is necessary to do such thorough work, regardless of any time, scope and money constraints. The result was a business model about the overall energy value-chain. This model could also be used to specify business processes and applications. The team won an innovation award for this project, for its contribution to the improvement of process and data management.
Three years back, the Data-Architecture Team began the project described in this publication. The perimeter was smaller than the aforementioned project. The project focused on the distribution part of the energy value-chain but required more details (for example precisely describing the energy distribution network). The number of users was significantly higher. The types of users were also different. They came from more diverse backgrounds and did not necessarily work with models. The team had to produce results more quickly and directly usable by projects. They used the model developed in the aforementioned project as a strawman. This model was merged with a first sketch of a business model that was previously developed in EDC. This helped bootstrap the use of business objects. From that point, the team worked with concrete projects and went frequently back and forth from the concrete projects to the overall business-object model.
A key factor of success was this combination of the top-down and bottom-up approaches. With the initial model, top–down, the businesses rapidly adopted the business objects. The bottom-up model brought relevance to the project. The « in vitro / in vivo » approach is essential for achieving the buy-in of the business divisions. After three years, the business now requires support for their projects from the Data-Architecture Team. 6.3
In business divisions that are close to the core business of EDC (e.g., energy distribution network management, customer management), the business objects are defined at a purely business level, regardless of the IT applications, by using process descriptions, “know-how” documents, official documents, and so on.
In the business divisions that are more “generic”, such as finance or human resources, the business objects mimic exactly the application-specific objects found in the applications, for example in the SAP application. Indeed, these application-specific objects became part of everybody’s everyday business vocabulary, use cases, and even part of their process descriptions.
Hence, the business-object model of EDC mixes business objects (respecting the specificities and strength of EDC) and application-specific objects (defined by commercial packaged applications), thus relating them.
To design the data repository’s model, EDC evaluated the business-object model sold by the editor of the chosen IT solution. The question was, “Should we use the data model provided by the vendor or not?” The commercial model was essentially for a different kind of energy value-chain and it covered the entire value-chain (from production to consumption), whereas EDC needed only the distribution part, but applied to one specific kind of energy. EDC decided to design the data-repository model, based entirely based on its business-object model.
In summary, when the business model is generic and does not reflect an expertise specific to the company (such as with financial objects), it is better to use the object model as defined by the commercial packaged application. For all “businessspecific” activities (including overall reporting), it is better to use the specific model developed by the business. 7
In this paper, we have described how deregulation and new energy challenges affect energy distribution in a European country. We illustrate how EDC, responsible for the distribution of energy, addressed these challenges by more strategically using data. One of the goals of EDC was to know more about the customers and to help all business divisions work together. They achieved this through a business-object model, business objects used as common vocabulary, and through a data repository that provides powerful analysis.
The key factors of success of this multi-year project were to develop a comprehensive approach in which all parties benefit from the use of business objects, to have an approach that combines top-down and bottom-up approaches, and to find the “right” way to define the business objects (sometimes using the model from the packaged applications or the model from the business). 8 (Redding09) - Redding, Guy, Dumas Menjivar, Marlon, ter Hofstede, Arthur, & Iordachescu, Adrian (2009) Modelling flexible processes with business objects. In Proceedings of the 2009 IEEE Conference on Commerce and Enterprise Computing, 20-23 July 2009, Austria, Vienna. (Abramowicz08) - Abramowicz, Witold, Filipowska, Agata, Kaczmarek, Monika, Pedrinaci, Carlos, Starzecka, Monika, Walczak, Adam (2008) Organization Structure Description for the Needs of Semantic Business Process Management. In Conference Proceedings of SBPM 2008, June 2003, Spain, Tenerife.