Connecting Everything Together: The Work of a Solutions Architect

Note: This is the third article in a series about the three different architect roles on the Student Information System project. If you missed the second article, you can read it here: The Design Architect, A New Role for New Challenges.

It’s the middle of the day in the middle of a week filled with meetings, meetings and more meetings. I arrive a few minutes late to a meeting that I scheduled and without a valid excuse for my tardiness; it’s not like I had to walk across campus to arrive. After more than two years of remote and hybrid work, I am sure I am not the only person to have inexplicably arrived late to a Zoom meeting. Just the same as I am sure I am not the only person to have wondered, bewilderingly, exactly how I managed to do it. 

Rather than waste any additional time, after an apology for my unexplainable tardiness, I dive right into a discussion with Jonathan Whitman, our Solutions Architect for the Student Information System (SIS) project. Jonathan has a composed, relaxed way about him and as we settle into our conversation about his role on the project, even in his virtual presence, I find myself naturally calming and the hectic energy I brought into the meeting dissipating.

When I ask him to describe to me his role on the project, he first explains to me his day-to-day work as the Senior Director of Student Information Services for IT Services. “My main task is to figure out how to stitch together all of our student- and faculty-related systems and then coordinate the work to make that happen, as well as to oversee the teams ensuring that those systems are maintained and supported once they’re all connected together,” he says. The SIS is the centerpiece of the systems he oversees, and so it is critical for him to be a part of the project team to do that same work and to ensure that the new system we choose fits well into the existing student software ecosystem.

We have been using that word, ecosystem, a lot these days, I think because it’s the best word we’ve found to describe the large collection of things—systems, projects, processes—we’ve been tasked with overseeing and affecting. Like an architect creating drawings or draftings for a new building, Jonathan creates diagrams of our systems to demonstrate how everything in this ecosystem connects together. The drawings are simultaneously orderly and overwhelming, but they illuminate the main challenge faced by Jonathan in his role: getting everything to play nicely together.

The Right Tools for the Job

When he’s looking at all the possible ways to make a new system play nicely with the rest of our ecosystem, Jonathan’s thoughts go something like this: We know we need to do X and the system can do X. Good. We know we need to do Y, but we don’t know if the system can or will be able to do Y, so what do we do with Y?

To answer this question, Jonathan has a number of tools in his toolbox, including reconfiguring existing systems, connecting existing systems in a different way, finding a new vendor-supported system, or creating a wholly new application. Each one has its benefits and its drawbacks and Jonathan has to be sure to choose the correct tool for the task at hand.

To be able to determine which tool is the right one for a particular situation, he has to have a deep understanding of the purpose of the system and its associated processes, how work is accomplished currently (the current state), the capabilities of the new system, and how the work is likely to be accomplished going forward (the future state). On top of those, he also has to know how governance, permissions, security, and regulatory compliance may play into various aspects of the system, its data and its processes.

Jonathan is an ever-present attendee in the SIS business process mapping sessions. He is there listening to gather information and understanding, so that he can make the best choices possible when he begins to connect all of the pieces of the ecosystem together. “The more I understand of the current state, the better I can help stakeholders see outside of their existing processes to an improved future state,” he says and, ultimately, that’s his goal―transformational improvement for the users, be they students, faculty or staff.

The Connection Point

Jonathan, in his role as the Solutions Architect, sits at the connection point between the work of our Enterprise Architect and our Design Architects. He must use the high-level information gathered by the Enterprise Architect—information about outside market forces, product strategy, the flow of information beyond just the student information system, and the larger context in which the student- and faculty-related systems sit—to inform his own decisions about the SIS. 

He must also assist the Design Architects to understand the larger student and faculty software ecosystem, as well as the specific choices made for the SIS, so they can then marry the business processes to the technology through the design process. Then, once all the decisions are made at those various levels, it’s up to Jonathan to see them executed. This includes taking into account any systems upstream or downstream from the core student system, as well as making sure nothing breaks along the way. He described this whole process to me as creating “the unified puzzle of how everything works together.”

Sometimes creating this unified puzzle can be especially difficult because of what he calls the “secret sauce.” The secret sauce is what makes us special and sets us apart from other universities and, according to Jonathan, we have a lot of it here. The trouble with secret sauce is that it often means systems are not built with our unique needs or preferences in mind.

The Choice to Not Customize

If there is so much secret sauce at UC San Diego, I ask him, then why has the ESR Program made it a goal of its many projects to minimize customizations? It seems to me that secret sauce and customization would go hand-in-hand. He smiles in such a way that makes me feel as though my question was predictable. “It’s a delicate balance,” he says, “and it’s my role to tease out what really is the secret sauce and what is change management.” 

A significant benefit of adopting a system that is offered on a Software as a Service (or SaaS) model, he explains, is that upgrades to and support of the system are managed by the vendor. It is their responsibility to ensure everything works as expected and continues to work as expected throughout the lifetime of the system. Customizations and their consequences, however, are our responsibility. If a vendor pushes out an update to their system and it is incompatible with our customizations and therefore causes our system to break, we cannot go to the vendor for a solution. That’s on us to fix. “This becomes very costly very quickly,” he points out, and if his staff are busy fixing systems that broke because of our customizations, they are not available to work on other needed projects.

To manage this, it’s best practice to stay away from making customizations. That doesn’t mean that any new systems won’t be configured to support our needs, they will. However, Jonathan points out, there is a significant difference between configurations—changes to the settings of the system—and customizations—creating our own additions to the software that are dependent upon the underlying code of the main system and, crucially, that the underlying code remains unchanged. The former we’ll be doing lots of throughout the course of the project, the latter we really want to stay away from.

Jonathan concedes that there are some instances where we need to find a way to meet a unique need that is not inherently supported out of the box by a system, even after configuring the system as much as is possible. Because we want to stay away from customizing a vendor-supported system, Jonathan and his team play a critical role in determining how to meet those unique needs. He explains that such needs are usually met by “last mile applications,” or custom tools he and his team build to meet critical systems gaps.

The Last Mile

As an example of a last mile application, Jonathan describes to me the Graduate Financial Support Request Tool (or the FSRT) which was created to facilitate the unique ways we calculate and apply financial support for graduate students. Ensuring our graduate students have financial support is obviously mission-critical for us, but how we execute that is very different from how other universities do it, which means that most student financial systems do not inherently support our processes even after configuration. University leadership has determined that the unique way in which we support our graduate students is part of the UC San Diego Special Sauce and must be maintained, and so Jonathan and his team are building the next-gen FSRT to accommodate those processes.

Ensuring the FSRT works with our future systems, including the new financial aid system we are preparing to implement, is a key part of Jonathan’s work, as is the process of understanding where other last mile applications may need to be created. By their nature, last mile applications are created near the end of an implementation process, after all our needs are clearly defined and after all of the capabilities of the new system are fully understood. “We don’t build anything until we’re certain we need it and until it’s clear how to do it,” Jonathan says. 

Until then, he is paying very close attention during the current state process mapping and other project meetings, noting where last mile development may be needed, determining how the pieces of the puzzle may come together, and making connections between the business side and the technical side of the project.

The Tech to Non-Tech Translation

In addition to ensuring everything is working well together and building applications to fill gaps, Jonathan sees another one of his key tasks as being a translator, or “talking tech to non-tech” as he describes it. From what I’ve seen of him at work in various meetings, he’s effective in this role. He attributes his ability to translate the needs of stakeholders into technical solutions to his more than 20 years working at the University in roles within the Undergraduate Colleges, the Graduate Division and now IT Services. He knows something about almost everything that happens at the University, at least from a technical perspective.

It’s a good thing, then, that he plays a critical, though unofficial, role on the project’s change management team. His deep understanding of the University, its systems, and its people, cultivated over those more than two decades, benefits both the team and the project stakeholders, through his ability to advocate clearly for the needs of both. 

“My ultimate goal on this project is the successful implementation of a new SIS and I am going to support that in any way I can. If I can leverage my institutional knowledge, historical knowledge and relational capital in order to succeed with the implementation, I will absolutely do that.” Coming from someone else, the same comment might sound almost Machiavellian, but coming from Jonathan it’s earnest and passionate. 

Throughout our conversation he regularly refers to the student experience and the ways in which a new SIS will update this core piece of our technological ecosystem to provide students with the kind of experience they expect from a university of our caliber. He wants this project to succeed for the University at large and especially for our students.

The Keys to Success

To wrap up our meeting, I ask if he has anything he’d like to share with the larger campus community about the project. He pauses for a long moment, sighs quietly and then says, “First, we all have learned a lot of lessons from other previous implementations, both within our university and at other universities, and we are being very careful and very thoughtful about not repeating the mistakes of past projects.” 

No project is flawless and the team has no illusions that the SIS project will be without its own mistakes, but the team routinely expresses its thankfulness that we are one of the later projects in the ESR program; we are now treading a well-worn path, rather than blazing a wholly new trail. In that we have a very significant advantage that other projects did not have.