Naming conventions for software components.
During the different XI/PI implementations i have been involved with I have experiance differet naming conventions. I would like to share the different types of conventions that I have seen and my thought of it.
There is a great document for best practice on naming conventions. Also see Thorstens blog about the subject. The naming convention does not explicit ways to name things. In this blog, I would instead describe how namespaces and software components can be derived. For all the different types of interfaces lot of effort has to be devoted create abbreviation and create a meaning full structure, this will not be covered in this blog, but hopefully in a new blog.
In this blog the term object refers to all object created in the Integration Builder Repository, like scenarios, interface mapping or message interface.
Simple Group
With the first implementations we used a very rough, method to divide the object based on the target system. I think we had software components like SAPR3, SAPXI and all the legacy systems as separate software components.
This method was very easy to get started on and did not require a lot of work op front. It was pretty easy to find which software components to use. The component names could be implemented at all customers, because it was the same setup they all used.
The namespaces just contained the legacy system name, so it was more a point to point connection. It was easy to find objects involved in a scenario. You just use the legacy system name, and you go the information you needed from the object involved.
The problem with this method, was that a lot of interfaces are grouped into the same component. This can make it more difficult to transport the components; at least you need to be more careful, what you are promoting to production. A large problem with this tight coupling was that interfaces were not named for reuse, or a refactoring should exists. This limits the SOA cababilities, which are one of the key selling points for XI/PI.
In recent implementations more focus was on making an SOA architecture. I my view this requires a more process centric approach. I have seen two different methods for creating a naming convention for grouping the objects smarter. Using the Solution Manager description of the processes, or using Solution Maps, which is SAPs standard way to look at processes in organizations.
Solution manager (SOLMAN)
In SAP implementation SOLMAN is vital part, to describe the business process used in the organization. This is both true in the implementation phase and I believe also after the solution has been implemented.
I have not been involved in designing the SOLMAN maps used for describing the processes. What I have seen is that the business process has been used for grouping of the scenarios. By using the same structure for the object, there is a clear mapping from SOLMAN to the PI respository.
Using the SOLMAN grouping of processes gives to following advantages.
- The business knows which process you are working on, since they have the same notation. This way it is easy for a developer to communicate, where there is a problem.
- The architecture and naming is given, because the naming has already been created.
The disadvantages
- If the project has multiply phases more maps can be created. With this it could be a little more difficult to find the mapping between the SOLMAN and PI objects. This could be solved with the help of software component versions.
- If you are designing a project, which does not involve SOLMAN, then you need to create a new structure or create the SOLMAN structure.
Solution Maps
On a resent project we used the SAP Solution Maps as a source grouping our objects. The solution maps contain all the different processes used in an organization. There are a number of different solution maps, both the general ERP but also industry specialized maps.
An example solution map.
Advantages of Solution maps:
- Structure which matches business organization.
- Common naming conventions between projects (really nice if you are a consultant). If used on all projects it is easy to find the objects. There is no need to considerer which naming conventions for software components and namespaces, because they can be defined before they are used.
- The convention is prepared for e-SOA, because the solution maps are used to place the enterprise services. There is though a small problem, about the enterprise services are places in the SAPAPP component. This can be solved in the design phase with placing the action in the software component corresponding to the Solution Map.
- Interface objects are placed in a way, relating to the service they perform. Different processes can use the same service.
Disadvantage
- It can be difficult to communicate issues about a scenario, because the implementation is focused on SOLMAN and not on the solution maps
- It can be difficult to place an object in the correct group. Is this service use for accounts payable or sales order management.
Conclusion
Both SOLMAN and solution maps focus on the process. They have both some advantages and disadvantages. I currently like the Solution Maps method best, because it allows a standard setup for all customers. I also like the point with having services grouped pr function, so multiply processes can use the same service.
I need to share more thought on how, I see the Solution Maps solution. This will be describe in a blog soon.
