Ryan: “[The team has] a regularly occurring iteration schedule where they bring feedback that they’ve received. We talk about it and discuss [whether] we can turn that into something useful.”

For each technical domain they have functional architects who are responsible for taking a business requirement and turning it into specific functional solutions. These team members not only work inside their own technical domain, but also find ways to best integrate parts with one another.

Ryan: “Sometimes the business objects aren’t going to directly correlate to the database objects, just because of their different nature. [The architects are] bridging the gap between the two. And they all work together to provide the bigger solution around that item.”

As for the other team members, they all have a prevailing technical domain and work with an appropriate architect. However, each has a wider range of skills, and can apply them if needed.

Ryan: “We expect that everyone on our team is a developer and can do more than a particular specification of our system. Yes, they have some [specific] focus, but that doesn’t mean that, for example, a front-end developer won’t ever write a query in the database.”

Portfolio Pathway screenshot

Software architecture and product management

Portfolio Pathway is basically a .NET solution with other Microsoft products applied—for instance, SQL Server. This technology stack makes it possible to do the very data-intensive job. They started with WinForms desktop applications for internal use and are still in the process of retiring them. Also, they have parts of a project that handles user interaction written in TypeScript and JavaScript using Angular 2. The software has a service-line architecture and multiple UIs.

Ryan: “Our website acts and behaves like an application, versus a traditional website. It’s not refreshing the page every time you […] click. What we try to do is more of a thinner client experience.”

At Portfolio Pathway, they use Scrum and have a six-week cycle consisting of three distinct stages (two weeks each): the requirement cycle, the development cycle, and the QA cycle.

Ryan: “You’re very limited in the scope of what you can do in a two-week-cycle, and we’ve found it just doesn’t work out well for us, especially with the amount of testing that’s involved in the finance space.”