Highway to PIM – #4: technical implementation

Provided, of course, that you have chosen the right system and that the data structure and the processes are perfectly aligned with your needs. In the first three articles of this series we described how to proceed in the first stages of a PIM project and gave you some useful tips:

#1: The Business Case
#2: Choosing a PIM System
#3: Business Blueprint

Your Business Plan has been approved, the system has been evaluated and your Business Blueprint is ready? Then let’s get to the next step: The technical implementation of your PIM system.

The Technical Design Document (TDD)

If, at this stage, you think that you’ve had enough of theory and you would like to get started, you’ll probably be disappointed. Because the technical implementation too has to be carefully planned. In the Technical Design Document, generally known as TDD, business requirements defined in the Business Blueprint are translated into technical solutions. The document describes the technical architecture: Which formats are generated or required? How is data converted and transferred? How should interfaces and customizations be implemented? It should also include basic guidelines such as coding conventions, the need for source code repositories as well as performance requirements.
Another essential part of your Technical Design Document is the DoD, the “Definition of Done”, i.e.: Which criteria must be satisfied in order for the implementation or customization to be considered “done”? You will have to make a clear and concise list of requirements and acceptance criteria that a software implementation or customization must adhere to in order to be called complete.
Which use cases are affected? Test cases are also central to the “Definition of Done”: Which tests have to be carried out in order to verify if the implementation satisfies the requirements? Describe step by step the specific test procedures, as well as the planned results – both on the source and the target system.

Take, for example, data provision to a shop: you will need details about

• how data is transferred
• which data is transferred
• how it is implemented
• how it is verified.

First of all, consider the shop’s requirements: Which transfer or import format is required? If you’re using standards such as the BMEcat catalogue exchange format, you should verify if customer-specific extensions are necessary.
The next step is a detailed definition of data mappings, where you define the actual content and content rules:

• Which data is associated with which specific field?
• Do the source and target systems have different field lengths?
• How should different data types be managed?
• How is content stored, for example, in long text fields or titles?
  Are several source fields and attributes concatenated in a target field?

After specifying how to map data, you will of course have to define how data will be transferred and how it will be backed up, logged and monitored.
Should data be transferred asynchronously as package via SFTP? How can you ensure a safe transfer to the target system? Are there more complex transfer routes that need to be considered? Will you need to use a specific Enterprise Service Bus?
And finally: Tests, tests and more tests. Are you going to perform component or unit tests? And integration tests? How will they be set up and what success criteria will be used to determine the value of performance? Can you automate tests?

In our example, at least the following checks should be performed:

• Is the created file correct (e.g. XML Schema Validator)?
• Have specific content rules been applied correctly?
• Has the data been transferred correctly?
• Does the target system accept and process the file correctly?
• Is the output data displayed correctly in the shop?

All these tests sound quite straightforward, but it is essential that they include well-defined guidelines, instructions on how to perform them and expected results. In short: Well-defined test cases are absolutely necessary.
The TDD thus includes all functional and technical requirements as well as all basic rules and standards. Since the implementation of your system will be based on it, is can be considered an approved implementation guide. Without it, discussions about whether the system is correct, complete and sufficiently tested are inevitable.

Preparation and implementation

Now you can start preparing the technical implementation.
Break down the project into individual work packages and allocate the appropriate resources to the tasks. This is best done (and can of course already be useful at an earlier stage) with an appropriate software for organizing and planning tasks and projects (such as JIRA, Assembla, Mantis or similar). With such a tool you can easily document your implementation and allocate all necessary resources.
No matter which approach you have chosen for your project, whether you opted for a high-pace agile approach with quick and small sprints or for a waterfall model as large as the Niagara Falls, a detailed organization and planning of tasks and responsibilities is absolutely necessary!
I won’t be able to point out every single advantage and disadvantage, or every difference and suitable scenario for all process models since it would definitely go beyond the scope of this article and provide enough material for a separate article. But, whether you’re using an iterative, sequential, spiral or mixed model, you will always need clear objectives for your technical implementation and you should stick to them. Whether with a few long strides or in several small steps, you will definitively have to take every single step. You finally have a TDD and a DoD (or many small ones?), you have broken down your project into work packages and allocated the appropriate resources. Now: Let’s go! Let’s start with the implementation!
Just one last practical advice: our team always test on our local test system first. If everything works fine – as stand-alone and with other components – the software is deployed on the client’s test system.
Ideally, we will then install the software on a staging system whose hardware environment should be as close as possible to the production system. Only if all the test cases were executed successfully will the software be installed on the production system. This step-by-step test approach ensures that your production system is not impaired by development faults.
There are, of course, many other aspects that have to be considered when implementing such a system. Did you, for example, agree on a code freeze? Is scalability an issue? Would you like to be able to scale out as well as to scale up? Will you use Continuous Integration? Is the target system able to handle Unicode characters?
Simply too many topics to be covered by a single article. Therefore, I won’t get into more detail here. I would just like to point out that there’s much more to implementation than just coding algorithms.

Highway or bumpy road?

Even if this is the last of our “4 Steps to PIM” article, a PIM project will not end at this stage. Don’t forget that your system has to be continuously enhanced and maintained. Otherwise, your customers’ delight and your benefits won’t be long-lived.
We hope that we have been able to give some useful advice for your PIM project and have helped to make your road a little less bumpy. We would be happy to assist you with any queries that you might have.
Our team looks forward to hearing from you: please contact us without obligation at: sales@parsionate.com