Diagramming Multi-Level Service-Oriented Enterprise Architecture

Abstract

Today’s enterprise architecture should incorporate high-level enterprise services that are considered as wrappers of business processes and ICT capabilities. This service-oriented enterprise model consists of a large number of model elements capturing various aspects of the enterprise in question, making any attempt to browse it too cumbersome. Enterprise architecture modeling, therefore, often resorts to a multi-view representation where views are focused and scoped. We define a visual modeling language and develop a supporting tool called SeamCAD that together lay the foundation for further multi-level enterprise modeling techniques. This article is dedicated to our tool realizing a notation schema and reinforcing a distinctive diagramming layout designed to visually capture the hierarchical containment in enterprise models. We demonstrate our real-life EA applications that were constructed thanks to SeamCAD. We report users’ feedback on SeamCAD.

Appendices

Appendix 1.A: Enterprise Model for an ERP-Seeking Company in the Market of Watch Parts Manufacturing

A company that is active in the development of enterprise resource planning (ERP) solutions and the research of a method for representing the customers’ needs in the market of watch manufacturing by using an ERP system.

Fig. 2

The supplier and the adopter value networks in the market of watch parts manufacturing

The model developed in the project was built using the SEAM method [22]. The SeamCAD tool was also used to build some part of this model that can be expressed by the SeamCAD modeling language.

Fig. 3

A third organizational level showing the ERP-seeking company

Figure 2a shows the very first organizational level of the model. At this level, there are two value networks on the market of manufacturing parts for watches: the supplier and the adopter. The supplier value network proposes products and services that would be consumed by the adopter value network.

Fig. 4

A fourth organizational level showing the ERP system

Figure 2b shows the second organizational level of the model. At this level, the adopter value network is seen as composite. It has some customer, a distributor, a provider and a company that manages the ERP system. Figure 3 sees this company as composite. It has direct and indirect purchases, logistics, manufacturing, sale and marketing, research and development, financial infrastructure, infrastructure for making decision and COM which is the ERP solution all of which are business working objects.

We see two business collaborations (sale_mfg of product and support of sale_mfg) within the main collaboration of the company. COM takes part in both of them. Note that the information objects that represent the products, objectives, results, etc. in these business working objects have $\texttt {<<in>>}$ or $\texttt {<<out>>}$ as their stereotypes. They are input and output information objects that are exchanged within the company.

Figure 4 shows data (e.g., items, sales, purchases, stocks) managed by the ERP system. These management activities are represented as business collaborations. In Fig. 5, one of these collaborations is scoped and zoomed in: manage the sales. This collaboration is broken down further into three component collaborations (listed in the order they happen): handle the command, handle the delivery and handle the bill. Again, the input and output information objects of the working objects that participate in these collaborations are in-stereotyped or out-stereotyped accordingly.

Fig. 5

This view is made at the same organizational level, but a higher functional level as the view in Fig. 4 is. It shows data exchanged and sequences of component actions for the distributed action manage the sales

Appendix 1.B: A Case-Study Enterprise Model in a Master’s Course on EA and SOA

The case-study is about a company called, called Engines SA, or BE for short, that manufactures and sells diesel-powered engines for lightweight aircraft. The company buys machine parts from suppliers and manages its own inventory. This case-study was extensively used in a master’s course the EPFL, Switzerland teaching students to develop their own EA model [41, 42]. Master’s students in the class are asked to team up to run their own companies and compete with other groups in the class. The students’ companies are supposed to sell engines they manufacture to a company called NewPlane SA, which itself sells aircraft to Dawa (DAnce With the Angels)—an air club who makes business on lightweight aircraft (e.g., rental, training pilot). The companies run by the students share a common competitor: manufacturers of gas-powered engines for lightweight aircraft. These competitors in fact have better market share because the majority of lightweight aircraft are still powered by gas. However, as diesel-powered engines are developed using modern-day technologies, they generally have better performance at the expense of maintainability.

Fig. 6

The 1st organizational level showing a market of airplane engines that has two segments

The students participate in various role-playing scenarios in the class to be convinced that they should improve the way their companies maintain engines they sold to the air club (via NewPlane SA). When an air club member brings her malfunctioning aircraft to the reception of the air club, the local garage of the air club proceeds in making an initial diagnosis on the aircraft engine. Upon learning that the engine has been broken, company BE is contacted asking for a replacement part and a trained technician (i.e. someone who is certified for repairing diesel-powered engines) to fix the problematic engine. Due to the inefficiency of the current telephone- and paper-based communication between the local garage of Dawa, the special garage that manages certified technicians and the BE company, the entire reparation process for broken engines is often unnecessarily delayed. Each student group is guided into developing an IT system for their company that better handles this communication. SeamCAD was used for building an enterprise model for company BE that captures all manufacturing and sale activities as well as the operationalization of such an IT system.

Fig. 7

BE enterprise model viewed at the 2nd organizational level and the 2nd functional level—both BE and Dawa are seen as composites

Figure 6 shows a view that represents the first organizational level of the said enterprise model. The market of lightweight aircraft is segmented by the fuel type, i.e. diesel vs. gas. Nevertheless, these market segments share an interest in growing their own market share. Figure 7 gives another view that shows the second organizational level of this enterprise model. In the segment of diesel-powered engine for light aircraft, there are two value networks: value network of the BE company (called BE Value Network) and value network of the air club (called Dawa Value Network). Note that this view is made for the second functional level. The two value networks sell engines and recycle them at the end of their lifecycle (collaborations sale and recycle, respectively). The BE value network also takes part in managing engines that are put in operation at Dawa Value Network – collaboration manageAtDawa. The overall interaction between the two value networks captures the entire lifecycle of diesel-powered engines and, as such, is expressed as a collaboration called engineLifecycle. Business processes at BE Value Network may perform in the following order: to manufacture engines, to get involved in managing engines that are in operation at Dawa Value Network and to recycle dead engines; those for Dawa Value Network are: to install engines, to manage engines that are in operation and to recycle dead engines.

Fig. 8

BE enterprise model viewed at 2nd organizational level and the 3rd functional level—both BE and Dawa participate in collaboration repair that is viewed as a whole

The view given in Fig. 8 also represents the same organizational level of the BE enterprise model as the one in Fig. 7 does. Note that the former is made at higher functional level than the latter. Localized actions ManageAtDawa⁶ of the two value networks are detailed in this diagram. Both BE Value Network and Dawa Value Network take part in the repair collaboration. Dawa Value Network operates and maintains engines in its aircraft but BE Value Network does not. All possible transitions between the three localized actions of Operate, Maintain and Repair are visible in this view shows.

The view shown in Fig. 9 treats business collaboration repair as a composite. Accordingly, localized actions Repair⁷ and the information objects bound to this localized action are all seen as composites. Business collaboration repair is broken down into a total of five component actions that do: (1) receiving a problematic aircraft from a member of the air club; (2) examining the potentially broken engine of the received aircraft; (3) ordering parts that necessary to repair the broken engine; (4) calling for a certified technician who is able to replace broken parts in the engine; (5) mounting the repaired engine to the aircraft and returning it to the air club member.

Fig. 9

BE enterprise model viewed at 2nd organizational level and the 4th functional level—the two value networks of BE and Dawa participate in collaboration repair that is viewed as a composite

For BE Value Network, the component localized actions of the Repair localized action would do (order is significant): initializing the reparation, receiving diagnosis report (from Dawa), delivering parts needed, sending a certified technician (to Dawa) and ending the reparation. For Dawa Value Network, the component localized actions of Repair perform the following (again, order is significant): reception of an aircraft needing to be repaired from a member, diagnosing aircraft engine, analyzing the diagnosis report, ordering the replacement parts necessary to fix the broken engine, calling a certified technician (from BE value network) who are able to replace the worn parts, fixing the aircraft and returning it.

Fig. 10

BE enterprise model viewed at 3rd organizational level and the 2nd functional level showing how the IT system, the garage and the delivering company collaborate with one another to implement the reparation process

As depicted in Fig. 9, information is exchanged between the two value networks during the course of the reparation process. In both BE Value Network and Dawa Value Network, RepairTxn is an information processing transaction that stands for the occurrence of localized action Repair. This transaction exhibits information objects that capture pieces of information exchanged during the reparation process. Most of them have $\texttt {<<in>>}$ or $\texttt {<<out>>}$ as their stereotype implying that they are either input or output information objects with respect to transaction RepairTxn where they are defined.

Note that some transitions between the component localized actions of Repair’s are associated with guard conditions. These transitions are supposed to be fired upon the availability of input objects or output objects. If an input information object is put in such a guard condition, the corresponding transition should be fired upon the reception of this information object. Similarly, if an output information object is found in a guard condition, the corresponding transition would be fired as soon as this information object is sent out. For instance, once information object approval is received in information processing transaction RepairTxn of BE Value Network, the transition from localized action Send technician to localized action End repairing is fired. When information object diagnosis result is sent out from RepairTxn of Dawa Value Network, the transition from localized action Diagnose to localized action Analyze is fired.

Figure 10 shows another view that sees BE Value Network as a composite. This view involves a few model elements listed below. They are business working objects that collaborate to materialize the localized actions that are made visible in Fig. 9 (of BE Value Network). First of all, the IT system obtains necessary information about the reparation process (e.g., name of the member whose aircraft needs repairing). Then it estimates the delivery time of the replacement parts based on their availability. DeliveryCo attempts to deliver the needed parts within the time fame. All Can Do uses this IT system to appoint a certified technician. This garage eventually second an appropriate technician. The IT system finally receives a notification confirming that the reparation process has been completed. It validates and archives the process (i.e., storing information about the entire reparation process in its database).

• BE Value Network that has an IT system handling the data related to the reparation process (e.g., delivery time of replacement parts, schedule for a certified technician to do reparation at Dawa).

• a delivery company called DeliveryCo that is responsible for delivering the replacement parts.

• a garage called All Can Do that manages certified technicians and an agent under the name OFAC who will certify the technicians.

The BE enterprise model created in this case-study has a total of 3 organizational levels. In this enterprise model, the deepest functional level is visible in the representation of the market segment of diesel-powered aircraft (see Fig. 9). After having created the enterprise model in the SeamCAD tool, it is possible to browse it and open all diagrams illustrated in this section. Using the tool, the student were able to comprehend the notion of hierarchy and the building blocks of SeanCAD. As the SeamCAD modeling language was based on the SEAM method, the students would learn the modeling terms that are introduced in the later stage of the course more efficiently.

Appendix 1.C: Designing EA with the SEAM Method and SeamCAD

A project was launched to apply the SEAM method and the SeamCAD toolkit in designing an enterprise model for a project of a new building for a school of the EPFL, Switzerland. A model built in this project (called the I&C enterprise model—named after the school) to specify how the building should be equipped and what IT systems should be installed in the building. This model was built using in the very first version of SeamCAD and had proved its usefulness of showing different views that would be of interest to different stakeholders in the project. Figure 11 gives a view of the I&C enterprise model that depicts the big picture related to how school I&C conducts research and learning. The school is responsible for providing students, researchers with quality research and learning facilities. The industry may get involved in some collaborative research, which is supervised by the management board of the EPFL. This view represents the very first organizational level of the I&C enterprise model.

Fig. 11

I&C enterprise model at the 1st organizational level—management of EPFL and the school of which the new building was constructed

Fig. 12

I&C enterprise model at the 2nd organizational level—internal structure and business of a school at the EPFL, Switzerland

Figure 12a depicts the internal structure of school I&C. In this school, business support system called BSS collaborates with professors, researchers, teachers, students and visitors. Figure 12b details the collaboration that may happen between BSS and them. Note that the two views given in Fig. 12 are made at the second organizational level of the enterprise model but for two different functional levels.

Fig. 13

I&C enterprise model at the 3rd organizational level—modern channels equipped by BSS and an IT application through which people can efficiently exploit these channels

Going into the internals of BSS, Fig. 13 diagrammatically describes modern channels of the new building of school I&C and how they are exploited. An IT application is developed to help different departments of the school efficiently exploit these channels: accessing the web, accessing school events, reserving a room, etc. Note that the views shown in Fig. 13 are made at the third organizational level of the I&C enterprise model.

Fig. 14

I&C enterprise model at the 4th organizational level—equipments managed by BSS and an IT application through which people can effectively exploit the equipments

The lowest organizational levels of the I&C enterprise model are addressed in a view given in Fig. 14. This view is dedicated to the component structure of the application that helps people access channels equipped in the new building of school I&C.