Luc Véronneau on Building Software That Matters
Q&A with Solutions Architect Luc Véronneau
Written by the DSH team*
Une version française de ce billet a été publiée ici.
The Data for Society Hub (DSH) team spoke with Luc Véronneau to learn more about his role as a solutions architect, his involvement in this project, and his team’s objectives for the coming year.
What is your role within the DSH?
Luc Véronneau (LV): I was in contact with CIRM [Centre for Interdisciplinary Research on Montréal] long before the DSH appeared. My role was along the lines of a “technical specialist.” I was doing the work of a solutions architect by discussing the Observatory of Montréal’s Narratives (which has since been subdivided into two projects) and by working on the solution for Commun Axiom, which is an idea that I came up with.
Currently, my official title is “solutions architect,” but what I do goes beyond that. I’m responsible for the development team, which means that I mentor the developers and review their code. I also create the architecture and designs for the software and guide the team when it comes to implementing design patterns.
This can involve selecting technology stacks and providing guidelines for their implementation, because the developers we have right now are students. They don’t have as much experience as I do, so I usually have to go through their code and give them pointers. A large part of my work is helping them. That being said, they are more specialized than me, so we gain a lot in other aspects by having them work with us.
Another part of my job is meeting with other technical leaders of Montréal in Common to keep up with what they’re doing, [as well as] with architectural guidelines and restrictions. I also keep in touch with the partners and with different team members to stay up to date on projects that might work with our own technological initiatives. This involves extended partnerships with people who aren’t directly related to the DSH, but who could be interested in using certain solutions on a long-term basis. We’re not building software that can only respond to the needs of a specific group of organizations; the point is to have something that will be accessible to a larger audience.
We’re not building software that can only respond to the needs of a specific group of organizations; the point is to have something that will be accessible to a larger audience.
What exactly is a “solutions architect”?
LV: I’m going to give you my own definition of that term, because there are many ways to define it. Usually, a person who is a “solutions architect” selects what software is going to be used and how it will be assembled to cover the basic needs of a business. It goes beyond designing one piece of software — the role requires the architect to figure out which different software will work together to keep the business running.
That being said, there is also what we call an “enterprise architect.” Enterprise architects manage things from a broader point of view. They don’t only deal with software; they also take into account the specific needs of a company, and they decide on whether people or technology will be used to meet those needs.
A solutions architect also has to think about those issues because when we talk about “implementing a solution,” we either want to fix a problem or meet a need. Your company’s needs might be better served through the implementation of a software solution, or by building a stronger staff, or by [redistributing] responsibilities within your current staff.
You need to think about the principle of a function. Not in terms of software — people from the software world might think of this as being a piece of code, but a function is something that goes beyond that. People who work within organizations have functions which are usually assigned by title. These functions cannot always be automated, so you have to define which parts you can automate through software and which parts you cannot.
You also have to make sure that people get the most out of their efforts by implementing the right software at the proper levels, because bad software can make it harder for people to do their job. This is usually a bad solution. People get really frustrated when they work with this type of software.
So, what you want to do as a solutions architect is meet everyone’s needs. This involves talking to those who will be using the software to get a better feel for their roles within the company. You ask both the [senior management] and the people working on the ground what they do and how the implementation of software could help their work.
It’s when you cover those bases that you can map out a structure of the different functions executed within the company, and see which ones can and cannot become software. You can see how to make things easier for the people who work there, so they can take on more interesting tasks and reduce the amount of effort required in the repetitive parts [of their job], where you can usually use software to do the work instead.
What is the intended purpose of Commun Axiom?
LV: From a social standpoint, the purpose of Commun Axiom is to produce something that can be helpful to smaller organizations. Through my work on the private side of things, I saw that there are many solutions available for big companies and for individuals. But smaller companies don’t often have the money to invest in large solutions, and they don’t have the infrastructure to manage complex software, yet they still need some form of business intelligence to manage their data. Commun Axiom was really meant to cover this technological gap that seemed obvious to me.
I always knew that there was no money to be made out of the solution. It’s free software. The product is meant to be decentralized and hosted on a voluntary basis, so there is no [intent to monetize] within the software itself. In the long run, I might get some financing to be able to keep it alive, but that doesn’t mean it’s going to gain a lot of value. To me, the best profit that I can have is for Commun Axiom to be used. Because people can actually find ways to make their lives better by using the software.
What motivates and inspires you to be part of this project?
LV: Obviously, from a technological point of view, this project is super interesting. Beyond the fact that we’re really helping organizations, the technical aspect of the solution itself is interesting because there’s nothing like it. We’re reusing principles from software that already exist, but in ways that have never been put together before, and we’re using a decentralized approach.
I’ve looked at available solutions for universities when it comes to entering information into a repository that will be made available to others. It’s very centralized, often “clunky,” and the only options for decentralization that exist right now are very unsafe. Dropbox is not very private — it’s easy to [forfeit your privacy] by losing your URL somewhere, or copying and pasting it on the wrong page, or sharing it with the wrong person. There’s also no easy way to track where information is going and how it’s being used.
So, in terms of data governance, Dropbox, Google Drive, Microsoft OneDrive, and other similar products don’t actually answer the requirements of protecting identity privacy, anonymization, or even the protection of intellectual property and the ability to know what is being done with your data in the long run. Many options are also too technical for most people to use. These are all elements that we want to provide people with when they use Commun Axiom. We’re covering many different considerations that typically aren’t covered by a single solution.
Beyond the fact that we’re really helping organizations, the technical aspect of the solution itself is interesting because there’s nothing like it.
What have you learned so far through your involvement with the DSH?
LV: How difficult it is to generate movement within organizations. We have a partnership, and everybody is working toward a common objective, but having those organizations seriously implicate themselves in the project to say, “We need this feature and that function, we need to have those possibilities in order to make our jobs easier,” is actually very difficult.
What surprises me is that people seem to be afraid of giving straightforward answers [such as], “If this was implemented, I wouldn’t use it.” I guess it’s because they’re worried that they’ll sign on to something bigger than what they first signed up for. People don’t often say “this is a horrible idea,” probably because they don’t want to hurt anyone, but I want to know if I’m wrong or getting off track! Not knowing can definitely make things more challenging in terms of organizational processes, to get some movement, some inertia going, and to have things happen.
In terms of software development, it’s not necessarily as difficult even though it requires a lot of work. It really comes down to the operational aspects of the whole project. I knew that it wouldn’t be easy, but I didn’t think that it would necessarily be this hard to get some overall movement going. The strategies to get people implicated and to have them give you their feedback without making them feel like they’re signing up for something more — those are things you can only learn by doing.
What challenges is the DSH facing between now and the end of the project in December 2024?
LV: The biggest challenge will be to create an organization that can survive the initial experimentation phase. Between now and 2024, we are putting together processes, software, and principles that will allow for different organizations to collaborate and learn about the context in which they live in Montréal, and to create more knowledge through the aggregation of information. But it needs to become more than just an experiment. It needs to become something that survives by itself, and to do that it will need to become a separate organization at some point.
Right now, CIRM is representing that organization, but eventually it will have to exist independently. That gives us two years to build the foundations of the organization and create the processes that are required for it to exist. That’s a lot to do [in that timeframe] because we need to identify the key roles within an organization. Even if we decide to do a data trust for the data governance within the partnership — which seems to be one of the solutions of interest — that data trust on its own cannot cover all the requirements to get those solutions to survive, because we still have to do some hosting.
Even with Commun Axiom, which is mostly decentralized, certain parts require hosting because we’re identifying people when creating accounts, so we need a main repository of individuals that exist within the network. Having an orchestrator that is a centralized part that gives and retrieves information from everyone actually makes it easier for us to maintain a solid network. But those centralized parts need to be hosted and managed, so we will require an organization that receives funding to do that and make it work.
We might even get to a point where we will need to build two different organizations. One of them would be for the network, like a nonprofit organization that would host the main servers and monitor and support the further development of Commun Axiom. The other would specialize in building knowledge from the Montréal perspective and would manage data governance. The two organizations would be complementary, but they wouldn’t necessarily answer to the same people or meet the same needs, so they wouldn’t receive the same budgets.
This is probably going to be a big challenge, and I think everybody is aware of that. It will have to be tackled fairly soon because two years goes by really fast.
What are some objectives that your team has set for itself for the coming year?
LV: We’re hoping we’ll start meeting with some partners to define the type of data and dashboards we will be building for them, in terms of data analytics. We’re going to grab some datasets and go through the whole process of ingestion to put them on those dashboards.
I also hope we will have new members start working with us. Ana [Brandusescu] and Jonathan [Van Geuns] will hopefully work on the whole data governance aspect of the project. They are going to start acting as a body of authority around data governance, and will impose constraints and restrictions on those datasets that we’re studying and that we want to ingest, so that we can build metainformation on those datasets that define which clean-up transformations need to be done for them to be usable. This would demonstrate the whole process of data governance, which will eventually be done through Commun Axiom’s platform, especially in the context of a data trust. So, it would kind of be a test run for something bigger.
With Commun Axiom, we’re looking into testing out the basics of data transfer from the Commons software in the next year. Once that’s done, we will have the basic infrastructure to start automating data transfer, and then we can also start putting together all the metadata infrastructure, so that people can start documenting what datasets they have, whether or not they are accessible, and why.
We will hopefully also start working on another software called Let’s Agree which will define agreements for sharing data between different parties. When those elements begin to emerge, they will provide the appropriate tools for a data trust to be exercised in the context of Commun Axiom.
So, there are a lot of objectives for the coming year, but I think we’re getting there.
This Q&A has been edited for length and clarity.
Compiled by Angelina Mazza; content editing: Karolyne Arseneault, Julie Levasseur, and Luc Véronneau.
