One of the nice things about good practices is that they’re typically things that you’ve done before and you’ve learnt some lessons to support them. Best practice sounds like it’s the only way to do something, and that’s simply not true when you work with a platform that has so many features and options for you to use. When the platform also contains a large number of different add-ons and supports hundreds of partner delivered solutions, you really can only talk about good practice and then apply some discussion, intelligence and effort to implement them in a way that works, for you.

Rather than make you read another hundred posts, I’ll give you some simple practices to follow, and we’ll expand on each of them in other entries. It will mean this one is longer than normal, but so be it.

1. Don’t try and design the entire system before you start, and that includes documenting what you think it might do.

   We document as we go (using tools like the Kabeus Design Manager), which allows us to try what we’re designing and determine if it’s useful, acceptable and workable. Don’t design databases, forms and business logic until you understand the data and it’s reason for existing.

2. Focus on the purpose of the data and make sure it’s in the right place.

   The content engine is about data that describes documents. It gives you information to find it again once you’ve added it and to support someone knowing what it is for, hopefully, without having to read the entire document. If you’ve got more than five data fields on a document, you’ve got too many fields. Two or three fields that are used to locate documents, locate the relationships between documents and distinguish between two that are similar is all you should need. Another two or three to provide additional context and you’re done. Any other data, put it in a database. The content engine isn’t a database, it’s a content management system

   The process engine is about data for routing, referencing and reporting, nothing else. Routing data is data to make a decision about a path to take in the process. Reference data is to support you finding the piece of work, or the other information that it relates to, like documents, database information or external data. Reporting is data that is needed for you to know what has happened or to predict what might happen, and is most likely going to be historical and be passed to the analytics engine.

   Any other data, regardless of whether it’s in a form, needed in a bespoke user interface or part of a case, isn’t meant to be kept in P8. Put it in a database and use the reference data that’s been described to retrieve it when you need it.

3. Design iteratively and test as you go

   Content design is a multi-step exercise. You need to identify some of the simple things first. How do documents get added and what data do I know when I add them. How do I retrieve the documents and how is the data used to relate similar documents. Determine any characteristics of the data that make things similar, and identify the things that make them different. That should give you a simple class hierarchy with some data elements that are common and some that aren’t. Security, audit, geography, processing patterns and volume of data will make you change class structures to meet the requirements. You can’t do that all at once, so be prepared to iteratively add requirements to the design, and extend it, modify it and perhaps even redo it entirely.

   Process design is just as much a multi-step exercise. The routing logic is the most important part as that is what the process engine excels at delivering. Make sure the process represents the process you want, before you start adding extraneous data elements, attachments, components and other system behaviours. The design and draw modes of the design are well suited to ensure you design the routing path and the major steps before you do anything else. Once your routing logic is done, deal with reference logic so that you have the means of referencing the things that are used in the process when needed. Finally add the metadata required to satisfy your reporting requirements.

There are many individual points to make on each of these design topics and we’ll be expanding on each of these design behaviours in future posts.

Thanks for reading.

David