From a strategic viewpoint, the more complex PLM landscapes in the shipbuilding industry become, the greater the importance of enterprise architecture (EA). This refers to the coordination of corporate strategy, business architecture and organization, information flows, application architecture and IT infrastructures. The consultants at PROSTEP provide you with support when it comes to designing EA-compatible PLM architectures.
Decades ago, when shipyards first adopted CAD/CAM and nesting systems, their PLM landscapes were comparatively simple. Today, they can include 30 to 40 different and sometimes very specialized applications, which need to interact if they are to support the processes in the different departments. This means that it is becoming increasingly difficult for shipyards to keep tabs on everything and ensure that the PLM architecture meets their current and future requirements. EA helps you manage the complexity of your PLM landscapes better.
Some shipyards have already gained experience with EA and are pleased with it. Others complain about the paperwork involved, which they feel provides too little benefit. We however don’t believe that this is a reason for doing away with EA, as the complexity of PLM landscapes is still on the increase. The solution is knowing exactly what to do and how to do it.
Using existing EA frameworks
There are a variety of standards frameworks for EA with recommendations on how companies should best proceed. If customers have already decided on a specific framework, we are happy to follow this standard. A key component is the involvement and firm commitment of the organization, which includes reviewing organizational processes. Sponsors, stakeholders, etc. must also be identified, and the scope and budget must be defined. However, perhaps the most important thing is defining the architectural vision and/or the desired target situation.
Once the organizational tasks have been completed satisfactorily, the next step is defining the PLM architecture. This means that companies must first understand the current situation in their IT department and business divisions. It then makes sense to define one or more target architectures that can be compared with each other in order to specify the vision in greater detail. Based on this, an analysis of the gap between the current and target state can be performed. The gaps might involve a lack of skills, imprecisely defined processes, missing or incorrect information, or functional deficits in the applications. A consolidated gap analysis provides the basis for implementing the target architecture.
One of the key challenges in terms of EA is the interaction between business architecture and IT architecture. To improve understanding in this context, we have developed a best practice called Information Flow Analysis (IFA). It describes the path that key information and business objects take as they move through the organization. In shipbuilding, for example, this includes the vessel specification, which provides the input for the next objects. This could be a general arrangement plan, a P&ID or a test report. The input/output relationships exemplify the information flows between the different departments and domains.
If relevant information is added to the IFA, e.g. the IT systems in which these objects are created and managed, it is easy to bridge the gap between business and IT architectures. The definition of business objects and the analysis of information flows is the key to a PLM architecture designed to meet business requirements. The principle of “as much as necessary, but as little as possible” applies here to avoid getting lost in the details.
Three real-life examples
As part of our PROSTEP Shipbuilding PLM Insights series of web seminars, we present three real-life EA projects that we have recently realized. They demonstrate the versatility of the approach. In the first use case, the company in question had installed all the necessary IT applications and wanted to know how they should be integrated to provide the best possible support for the business processes. The input-output relationships between the business objects made it very easy for us to visualize the integration requirements.
In the second use case, we examined the flow of information at the same shipyard from the perspective of the ship development process with the aim of making it possible to plan the next project more precisely. To do this, we linked the previously recorded business objects to the milestones. This allowed the shipyard to better estimate the workload per milestone and the impact of moving a milestone. In the third example, we analyzed the flow of business objects from the perspective of collaborative relationships with different types of partners. The way in which companies collaborate also has an impact on the PLM architecture.
In conclusion, we can say that the importance of EA for shipyards increases with the growing complexity of PLM system landscapes. A variety of different tools are available for modeling EA and the relationships between business and IT architectures, but they are only helpful if the company knows exactly what it is they are trying to accomplish. Governance is even more important: EA is a strategic discipline that must accompany the PLM architecture throughout its entire lifecycle.
By Jan Bitomsky