There are a few services that fall within the scope of project support. A few of these services include:

• Administrative tasks – such as adding users/assigning user permission roles.
• The collection and presentation of analytical data.
• Providing advice on best practices.
• Recommending any system/architectural updates when and if required.
• Contractual service level agreements to service the client’s needs.

Completing administrative tasks and tracking the data for analytical purposes should be straightforward. Providing advice, making recommendations, and servicing a project, on the other hand, can be challenging.

Providing sound advice is an invaluable skill and service provided to clients. It can guide the client to plan correctly, identify possible risks, and make the right decision. Ultimately, this can also lead to the retention of the client in the long run and give the company a competitive advantage over other service providers – a win-win situation. Advice should be honest, well thought out, and relevant to the client’s specific needs/circumstances. Although it is vital to consider the client’s wants, advice should be impartial and pragmatic. What the client wants might not always align with the client’s needs.

The challenge is that advice can be based on assumptions and historical events. As we all know, the future can be unpredictable, and what would have been a good result from a decision made a year ago could quickly change into an unwanted outcome. The advisor should weigh all implications of a specific decision, and the benefits must outweigh the disadvantages. Future unknown events cannot be factored in when formulating advice, but with the proper due diligence, experience, and information available at the time, the advice provided and acted on can be crucial to the project’s sustainability to compete with competitors.

A strong foundation is critical in any process, whether in academics, construction, or software development. The foundation must be well-designed, durable, and stable when we think about building a house. Similarly, so should the architecture and coding. Easy enough?

The problem comes in when the house, originally designed to accommodate a small single-story, is now expected to carry a double or sometimes triple story on top of the existing foundation. When planning the house, it made sense only to accommodate one level. As time progresses, new needs arise. Similar to how an engineer would have to re-assess the foundation to make sure it would be able to carry the load, it is just as crucial for a solutions architect to make sure the software infrastructure can handle the newly expected load. Unfortunately, the proposed solution is only sometimes the preferred solution. The cost of upgrading the database may not make sense from a commercial point of view, or the refactoring could result in other implications for the existing functionality. 

Another factor to consider is the increased cyber security risks. Not only should the system be optimized, but it should also adhere to the standards required to provide enough protection against any cyber-attacks. The challenge is also to ensure that the solution will be viable for years.

Even if the cost of upgrading the architecture is not high, this does not mean it will be a simple switch. The software developers built the functionality around the existing foundation. If the foundation has changed or upgraded, it is essential to ensure that this change does not affect all other functionalities currently in the system. The vastness of this problem can grow, depending on the system’s complexity. Suppose multiple functionalities were added and tweaked over the years. In that case, it could result in code changes for those features – this is usually the case if the components were custom-built to meet the client’s initial requirements. The refactoring causes additional work and leads to further development costs that the client did not budget for when starting the project.

Furthermore, a need might arise to integrate with third-party applications or service providers. Depending on how the architect/developers originally built the system, it can add problems for any future developers working on the project to ensure the integration is working as it should. A definite challenge is not having direct access or control of the third-party provider, so pinpointing the problem can lead to back-and-forth communication. Not all service providers have the same response time, which can lead to delays that the project did not factor into the original plan.

Re-designing the foundation to ensure the costs of upgrading are low and the best seamless change implemented is challenging. Providing a suitable recommendation is crucial and finding a solution requires extensive knowledge and experience. The costs cannot be the main factor driving the decision. An Afrikaans proverb, ‘goedkoop koop is duur koop’ (meaning, buying cheap is expensive), immediately comes to mind. The benefit in the long run for biting the bullet now is that you will not have to pay twice. But there is a catch. Throwing money at the problem does not guarantee that the newly proposed implementation will resolve the issue. There still is a business risk, and there can only sometimes be a balance between the costs and the business requirements.

What adds to the problem is the increasing complexity of IT infrastructures. Over the years, there has been drastic growth in the industry. New computing systems with different versions are continuously released. Keeping up to date and accommodating all the different versions would add to the challenges. As complexity increases, it becomes difficult to identify where the interdependencies are and understand the effect each component has on another.

In some cases, the only option is to resort to a trial-and-error approach, increasing the risk of adhering to budgets and deadlines. There is also no guarantee that a solution will be found, and should that be the case, the architect and developers will need to revert to the drawing board. This exercise can be costly for the service provider and the client. Although this is a common challenge in the IT industry, clients expect an answer to their questions. Computer programming logic is rooted in mathematical logic, so there should be an answer. Unfortunately, there remain mathematical problems that need an answer to this day.

Although the level of complexity is specific to each project, it is evident that projects in support have complex and unique problems to solve. Whether it is architectural or integration challenges, it is essential to be transparent about these problems and provide clients with the best advice possible. With suitable recommendations and a solid foundation, the team can correctly address the issues faced by a project in support. It is not only in the client’s best interest but also for a business to remain sustainable and agile.