It takes a village!

By ,
New

A chat with Norval Hope

Each piece of functionality within ConSol was designed and developed by a real-life person (some would say guru, expert or magician) working closely with our wider team to bring the most meaningful and powerful user experience possible to all of our users.

Over the years, our team has grown into a dedicated and passionate group of experts in their respective fields.

I had the opportunity to interview one of our most senior team members, Norval Hope, and gain some insight into how his skills as a Solution Architect help create a system that helps you get work done. Norval gave me a sneak peek into what he’s currently working on as well as some insight into his thought processes on innovation and delivery.

Hi Norval, for the folks playing at home, what does a Solutions Architect do?

Well, solution architecture is the process that bridges the gap between business problems and technology solutions.

This requires me to collaborate with Trish and Hamish, two of ConSol’s business analysts, to review new user requirements we’d like to implement.

I think about which requirements fit nicely into the architecture we already have or which ones are low-hanging fruit that we can implement efficiently even if they don’t fit into the existing structure of our system – and then come up with technical designs for implementing the required features.

Most importantly, I’m responsible for thinking about the long term and trying to design and implement major design changes and features over time.

What expertise do you bring to ConSol through this role?

I think the particular skill I bring is around solution design and how to grow the system in a scalable and maintainable way over time – clean lines if you like!

I’ve worked as a software architect or solution architect for about 15 years and I’d say that probably the single biggest skill required in my job is being able to develop things in ways that provide a straightforward extension in the future and are easily maintained by current and future teams.

The other skill that’s important is the ability to interface with colleagues who talk to our customers directly to understand what the real requirements are, and then see through “that little change” down to the deeper problem. You can often design a bigger, deeper solution that does a much better job of solving the problem for a longer period of time. If you just approach it with a myopic fix this/fix that, add this/add that attitude, then over time you end up with software that is very hard to maintain. More generic solutions that are easier to extend are always preferable.

How do we decide what to build into ConSol’s architecture? Is there a common theme or set of requirements we follow?

The primary thing we keep in mind is how many other requests we’ve had for similar functionality.

The challenge is looking for a cluster of related requests and addressing them in a nice flexible way that can be driven by configuration, which is simpler to adjust over time, rather than more bespoke clunky code changes that may be quicker to implement initially but introduce technical debt and are much harder to change or extend later.

The second most important thing is we don’t often have time to build something out to it’s possible, utopian completion. If we only have a single, yet meaningful use case, the key is building things out incrementally according to a clean grander design, leaving nice coat hangers so you can add to it easily in the future.

What are you currently working on?

I’m currently focussed on enhancing multiple automation approaches such as improving our API’s and building on the work we’ve started with the Gateway importer/exporter.

It’s a configurable importer for spreadsheets, that allows customers to send bulk batches of data to create objects (such as orders) in ConSol with one action.

What are your strategic goals with developing the Gateway importer?

Gateway is definitely a big architectural shift for us. There’s multiple methods for validation of data that made sense at the time. My main goal for Gateway is to have everything driven by a generic dictionary covering ConSol’s model, with user-defined templates driving flexible import and export formats as required for each customer use case (e.g. import using a .csv generated by a customer’s specific feed).

The dictionary means that, within ConSol, validation can be done generically in one place and doesn’t have to be coded again in slightly different ways for every import and export variant. In addition to validation, copying spreadsheet cell values into fields of Consol objects can also be done generically.

We’ve currently implemented Gateway import logic for a few different entities (Project View, Order, Order Item) but the long term goal is to replace all of the ConSol importers and exporters we’ve collected over the years with this one consistent implementation, with just different template configurations driving them.

In summary, moving from bespoke coding for each use case to a single configuration-driven approach.

Why are we focusing on implementing automation in our software? What are the benefits to users?

More streamlined automated processes are popular because by definition they result in faster throughput and involve fewer manual touch points. This means the quality of the result achieved when using an importer is much higher than if you rely on a fleet of people to go and do manual entry, as there is less room for human error.

ConSol development is often driven by customer requests of a more acute nature, so Gateway represents one of the larger architectural changes I’ve overseen at Yarris. It puts the power in the hands of the people configuring the templates who tend to be much more across the needs of the business, which means they can utilise their process knowledge and understanding of the subtleties of particular cases.

Gateway moves the configuration much closer to the people driving the business changes as well as making it much faster, more reliable and accurate.

What’s the most rewarding part of your job?

I think the most rewarding part of any job I’ve ever had is seeing things that I’ve designed or built being used, and then hopefully built on and refined.

That’s the biggest buzz for me. The intellectual and professional satisfaction of concluding a design and implementation wouldn’t be complete for me without seeing it being put to good use.

The first couple of passes of the Gateway importer have been particularly rewarding as there has been very good customer feedback (even better as it has been largely positive).

Gateway configuration changes can now be made very quickly; changes can now be “live” ten minutes after advice from the customer, whereas previously such changes required a multi-week coding exercise. It’s very satisfying.