How to build a modern digital platform, but properly.

If you run a modern business, you would have tried every online service under the moon to solve the everyday business problems you face, whether that be apps like Xero to make your accounting simple, Monday.com to manage the fulfilment of services, or automation services like Zapier to do the little tasks that you don’t like doing. But we hit a point where we’re having to pay for a lot of subscriptions, and not everything talks to each other.

It’s at this point where you should be thinking about using a purpose-built digital platform.

Where to start?

Well first, make sure you work with someone that knows the ins and outs of creating a platform. This could be an external agency (such as Cybercraft!) or by using your existing/onboarding capability.

Be careful of using a cowboy developer as cyber security flaws are often hidden away and if exploited, can be detrimental to a business.

We follow a Secure Software Delivery Lifecycle (also see OWASPS presentation of SSDLC), so I’m going to outline our processes and why it should be a part of your processes too.

Planning – Because diving straight into it can be costly.

Who’s needed for this step: Business Manager, Project Manager.

Planning is key. And I’m not talking about what your platform needs to be able to do, I’m talking about planning about how you’re going to fund, resource, launch, maintain and sunset the project over its lifetime.

A shocking number of businesses don’t realise that technology is much like a car and needs to be maintained to keep it safe. It’s a manageable trade-off with going custom, but an especially important one to be aware of.

More Planning – This time for the platform.

Who’s needed for this step: Business Analyst, Stakeholders.

You would typically want a business analyst to help you define the features of the platform, but in a nutshell, this is your chance to list out everything that your platform is going to be able to do. Now being a good businessperson, you’ll want to define how critical these features are. You can use a prioritisation framework like MoSCoW.

Must-Have – The items on this list contain all the features that your platform must be able to do and must be a part of your minimum viable product/platform (MVP). Without any one item, your platform should not be launched.

Should Have – These items are all features that your platform really should have but aren’t going to prevent your platform from being launched. You should still aim to have all these features.

Could Have – These items make up your Wishlist and can all be considered as “nice to haves”. If you find that you have spare time/resource/budget in the project, you can begin to include these features.

Won't Have – These items are primarily for clarification. It’s a list of features that you have decided that your platform will have. They’re primarily used for clarification of functionality and to help ensure that stakeholders understand what’s not included.

Design Time – How you want your platform to look.

Who’s needed for this step: User Experience (UX) Designer/User Interface (UI) Designer.

Yes, it’s still planning, but this part is visually creative. There is a plethora of design resources that talk about best practices, all which can easily overwhelm someone new to the design trade. But for the most part, there are some key concepts that UI/UX designers have constantly sitting in the back of their mind while designing.

Try not to vary from the common user experience too much.

The trendsetters have done an excellent job of training the world on how to interact with a digital interface, but this means there are expectations as to how someone might interact with your platform. Coming back to the car analogy again, all petrol stations have used a common method of filling up your car, via the fuel flap at the back of the car. This method has also extended into how electric cars are charged as well. Because car owners has been trained how to fill their car this way by the petrol industry, that the electric car industry kept a similar experience to allow for a smooth transition from petrol to electricity.

Know who your user is.

Knowing whom your user is going to be is a key part of defining the level of complexity that your platform may have. If you’re designing something for expert power users, then you may want to use your industry’s technical jargon throughout the user interface.

The same goes for their counterpart. If you are creating a platform for someone new to your industry, you may want to include more explainer information and step them through certain processes.

Keeping these in mind and doing a bit of homework about your users will help you to create a platform that your users enjoy using and keep them coming back.

Let’s Get Building – Hands-on Keyboards for development

Who’s needed for this step: Frontend Developer, Backend Developer, Infrastructure and Platform Architect.

Once you know what your platform is going to do, and how it’s going to look, you’ll need to pick and choose the tools and technology that’s going to help you accomplish it. It’ll be best to sort the advice of an infrastructure/platform architect to help you make these key decisions.

We highly recommend the use of a serverless architecture where possible. We’ve seen businesses experience as much as an 80% reduction in their ongoing operational costs compared to what they would have if they stayed on a traditional infrastructure stack.

For the development of your platform, there are a few concepts we like to follow as it keeps our code maintainable and should do the same for you also.

• Segment – allow your frontend to operate independently from your backends/APIs.
• Isolate – separate your platform into its different areas of responsibility
• D.R.Y – Don’t repeat yourself. If parts of the platform are used in multiple areas, create reusable components and functions.
• Document Everything – It’s a forward-thinking idea to leave documentation to read for the next developer or another person who is unfamiliar with the codebase.

Testing & Validation.

Who’s needed for this step: Developer, Infrastructure and Platform Architect.

Testing & validation is a vital component of development that is often overlooked, especially by businesses who underestimate the value it brings to helping to reduce “re-work” time but also to upholding strong levels of cyber security

• Test – invest in automated testing. It’ll cost a little bit more upfront but pays off when your platform becomes bigger.
• Validate – Use code linting and code scanning tools to catch common code errors and security issues.
• Independent Verification – We’re talking pen-testing here. Make sure that you have your platform undergo intendant penetration testing, done to either the OWASP TOP10 framework or even better, the OWASP ASVS standard.

If you’re in a regulated industry, you’ll find that most regulatory standards required some form of testing to be completed regularly to be compliant. Testing is also covered in ISO27001:2013, PCI-DSS, SOC2, HISO HISF and HIPAA.

Full disclosure here – we offer penetration testing services but that doesn’t affect our recommendation to have your platform tested. When we build platforms, we recommend to all our clients that they still go through an independent penetration.

Deployment & Release – Time to go live!

Who’s needed for this step: Infrastructure and Platform Architect.

Is it time to go live? Well sort of. We recommend going through a pre-product run to test that a live deployment will be successful and to work out the unexpected kinks and bumps before it’s opened for everyone to use.

In this environment, you will also want to have some of your most trusted users run through your platform, using each of the features as a means of quality assurance.

If your platform has all its “Must-haves”, passes all its testing, and completes the quality assurance process, then you’re good to go launch it!

Operations, Iterations and Maintenance.

Who’s needed for this step: Stakeholders, Project Manager.

Before we continue, there’s something we’ve neglected to mention and that’s the scale of this process. The traditional business process would typically ask that you complete the work in each of the steps in its entirety, and then never revisit it. What we should be doing though is to take it one step at a time.

Instead of investing all you’ve got into something that could be a big gamble, we ask our clients to take it one iteration at a time where only what’s feasible is completed. This means a business can validate ideas quickly and pivot when the unexpected happens without losing out on all of their investment. After each iteration, you decide if as a business you should stop, pivot, or continue as planned.

So, your go-live isn’t the end of the road. It’s going to be the first of many times going through this process. For this iteration, you’ll have only included what was needed for your MVP and you’ll want to gather real-world feedback and monitor the performance of your platform to make sure that it is still providing a good user experience, and that it’s performing efficiently and securely.

Every additional iteration of the platform will be about ensuring that you’re keeping your feature set current, that security vulnerabilities are being resolved as they are discovered, and that you are monitoring the performance of the system for anomalies that need correcting or improving.

Now is also a good opportunity to ensure that you have documentation in order, reflect on how the process of the development cycle performed and decide if the next iteration will continue, pivot, or stop.

Wait, when did security come into the picture?

Unsurprisingly, security comes in at every single step of the way and covers more areas of business than you would expect.

Planning – Get to know the risks increasing components to your idea. Are you planning to work with personal information? Is there a standard you need to follow like PCI DSS (for handling credit cards) or HISO HISIF (for handling personal health data)? Unless you’re already a specialist in these areas, it’s a good idea to speak with a experienced privacy officer or information security officer.

Design – This is really about having the right capability in place. Use professionals that really know the pitfalls of the technology that you will be working with and also consider a security specialist to independently review your plans.

Development – Again, experience is key. Work with developers that understand strong security practices and can bake these into your application. Another often forgotten element to security is the individuals your work with – make sure that anyone you partner with is criminal record checking their staff and if resourcing overseas, are doing so from reputable locations.

Testing & Validation – While this step is mostly to validate the features and functions of your platform function as expected, it’s also a great opportunity to perform code quality checks (scanning for vulnerabilities and common mistakes) to ensure high quality code.

Also, we’ve already mentioned it, but don’t forget to have you application independently pen-tested. Having a fresh pair of eyes on the platform is the easiest way to critical vulnerabilities before launching.

Deployment & Release – Security in this step is all about validating and verifying that you have set up your infrastructure correctly for production and that your security tools are all in place.

Operations, Iterations & Maintenance – The active monitoring of services is going a key part to upholding the security for your platform. Having systems generate logs and collecting those logs into a central system give you insights into not only how efficiently your platform performs, but also when something malicious is going on. Consult with a security specialist on what information should be made available in these logs to build a strong defence.

As for iterations, an iteration is the full development cycle. The practices from each step should be followed for each iteration.

A good rule of thumb for your security efforts is that it should be dispersed across all the layers that make up your digital platform, and not just focused around a “firewall” or “security plugin”. Take into consideration the 7 layers of OSI and think about what security can be put into place in at each of the layers.

In Summary

We've outlined the basics of what you would expect as a part of the secure software delivery lifecycle. Consider creating a formal SSDLC in your organisation before jumping headfirst into building your app or platform or alternatively, have chat with us here at Cybercraft. We can help you build your SSDLC or become your development partner. Our SSDLC is the same SSDLC that we use for our clients, our internal platform developments, and helped build out the basis of this article.

If you have any questions about the content of this article or any of our services, please don't hesitate and contact us today.