Something that characterizes many of the projects that we undertake for our customers is that they start from an existing project that has gone wrong. When a project has gone wrong, the reason may be misunderstandings between the former supplier and the customer about how the project was to turn out, that internal members of staff are not qualified in the field to which the project belongs, inadequate or poor technical implementation or perhaps simply deficient routines. It can be hard to tell if the problems are caused by one thing or the other without doing a thorough analysis, but if you go through the ten points below, it might be easier to obtain an overview of how problems may occur.
1. Responsibilities and process
The first point has nothing to do with technical matters – it is about roles and responsibility for various different parts of a project and about how you collaborate. This point can relatively easily be clarified by identifying how various types of tasks are handled: has it been defined who is responsible for what, who is the contact person in which areas, who can replace who, what is the agreed response time, what does it take for a requirement to be fulfilled and so on. If all of these organisational aspects have been uncovered and documented, it should be obvious to everybody how new features and possible errors can be handled in the easiest way.
2. Environments, source code control and backups
When you handle a large system, it is a minimum requirement that a test environment has been set up where new features and corrections can be tested and approved before being put into operation. Large systems should also have a staging environment (a copy of the production environment with replicated data). In addition to this, it should be possible to return to earlier versions if unexpected problems occur. A backup procedure should also be prepared for it to be possible to find earlier data if an unexpected error occurs or if the system is compromised. You should carry out a sample test of your backup to ensure that it is intact and that it is possible to roll it back if this proves necessary.
3. Handling of errors and monitoring
Even the most tried and tested system may contain errors. What separates a good and a very good system is, for instance, how errors are handled. The first thing that should happen when an error is discovered is that the user should be given an explanation (for instance ‘The system is down temporarily – please try again in five minutes’). At the same time the administrator should be notified by email that there is an error, including detailed information, so that the background can be examined closely and the error can be remedied immediately. Handling of errors can typically be handled by Microsoft Enterprise Library, which is one of the common standard frameworks for this purpose. In other words, you should ensure your system includes a well documented model for handling errors and for monitoring if your system does not already include this.
Errors and problems do occur, but, if you do not know why, it can be difficult to rectify them, and the errors will probably repeat themselves. By focusing on developing traceable systems you avoid problems reccuring. First of all this means that logs must be in place everywhere where errors may occur (for instance sending of emails, IIS pool and so on). In this way you can examine things instead of guessing. Another method for increasing traceability is to make sure the right notification systems are in place. If errors happen in production, it is important that this is discovered quickly as a part of the management of errors (see next point).
In terms of organisation traceability should work during deployments and so on by documenting and registering changes (with date, time and person) so that if an error happens, you can refer to a name.
5. Transaction management
Transaction management ensures that, even if something goes wrong, it does not go seriously wrong. Bank systems constitute a good example of systems that are wrapped in transactions. If something goes wrong (for instance payment of money), money should not be drawn from an account. All systems contain internal dependencies, and, if something goes wrong, the process should be stopped and rolled back to make sure a system error does not produce more errors that can be difficult to explain and handle. As a person responsible for a system you should make sure all central functionality areas are covered by correct transaction logic so that possible errors do not cause other unwanted and related errors.
Thorough documentation ensures that programmers, people responsible for systems and others can be replaced without problems. Documentation ensures that important knowledge is not lost (forgotten) along the way, but also ensures that procedures (for instance concerning release and deployment) are complied with. In addition, documentation ensures that no human errors occur because of a poor information level. Documentation is a discipline in itself and should not be underestimated if you want your system to be safe and if you want to be independent of the system supplier.
Everybody makes mistakes, and, if you do not learn from your mistakes, they will keep repeating themselves. For this reason recurring, retrospective analyses of processes are critical. When errors occur, they should be discussed and proposals for solutions should be prepared and implemented, and the solutions should be evaluated and, if possible, improved. An organisation that learns all the time means you can continually improve product quality and ensure better quality of product development.
8. Use of standard systems
If something can be bought, this is often cheaper than to build it yourself. Problems often occur when home-made functions take over areas that established CMS, economy, mass mail and CRM systems could have handled better. If standards exist on the market relating to a specific area in your system, it is often beneficial to integrate to the standard system instead of reinventing things from scratch. In order to clarify this you can ask if there is something in your system that should be replaced by a standardized system and if this would provide advantages?
9. Best practice
All large tasks consist of a series of subtasks to which there are good and bad solutions. In terms of most implementation tasks there are ‘best practice’ methods and procedures. If you follow these known patterns all the way through a project, the risk of errors is minimised because known and tested models are used where most surprises have been eliminated. If your project is not based on best practice, it should be reviewed and possible ‘home-made’ solutions should be replaced by best practice in the field.
Do not let users act as testers without them knowing about it. Good tests start with good, internal procedures that are close to what is being developed – such as browser and device compatibility tests. Systems should also be covered by automated tests (units tests, validation tests, stress tests and so on), and regression tests based on realistic user scenarios should be used for stabilization. Only when all this preliminary work has been done should real users be involved, and this should take place in a controlled fashion.
If you can answer yes to the 10 questions above, there is a much greater chance that your IT project will succeed. When you are one step ahead and the right procedures are in place, you stand a much better chance of developing good IT practices and avoiding surprises and weekend work. It is never too late to take control of your procedures and you can keep on improving them.
The use of IT consultants is a big market and in many industries there is a consensus that this can be a good way to solve tasks that are beyond the primary competencies of the company or as a way to reach the goal faster in a project that have high priority. But the use of short-term on-site consultants is a risky affair if you have a longer term strategy and have a outright development project.
Every year the best Umbraco projects are elected at the Umbraco Codegarden conference and a total of 10 awards in various categories are awarded among several hundred projects. This year Compent won in the category Best New Tech with the Shamballa Jewels In-store Jewelry Designer.
We have just upgraded our internal baseline to Headless / .NET Core and will describe the main points for why you should consider Headless architecture for your next Umbraco project. A Headless CMS project means that the classic dependency between the CMS platform and the presentation layer have been removed. This means in practice that front-end is physically separate from the back-end, and you can therefore develop the presentation layer independently of the CMS platform version.
Many intranets are developed on Umbraco, but no standard platform has existed for a long time that you have been able to use from our.umbraco. With uIntra it has become easier to develop an intranet on Umbraco without having to start from scratch. A short while ago we placed version 0.2.3.7 on our.umbraco for free download. Among the new functions are groups, emoticons and comments on articles plus many small updates.
Umbraco is what you might call a classic system for web publication and presentation. For this reason it is often not associated with intranet use where functions such as decentralised administration, work group functionality, member management, document management and rights-based searching are among the most critical features. However, this does not mean that Umbraco cannot be used for intranets simply because all features do not appear out of the box in Umbraco. Whether Umbraco is the best choice for intranets therefore depends on which functional needs you have concerning your intranet.