Introduction
We recently sat down with Matthew Palkowski, a senior systems analyst and architect at DFJ, to learn about his unique path into aerospace, the challenges of balancing old and new technologies, and how IcePanel helped him bridge gaps in communication and design.
This was a super fun chat as someone fairly removed from the aerospace industry with plenty of assumptions (building rockets and jets sounds really fun). Getting a little window into this world was fascinating, and it became clear on the sheer complexity of not only the technical work behind the scenes, but the organizational dynamics at play.
About Dassault Falcon Jet
Dassault Falcon Jet is the U.S. subsidiary of Dassault Aviation, based in Teterboro, New Jersey. They handle sales, service, and support for the Falcon family of business jets across the Americas.
Can you give us an introduction to yourself and what you do at DFJ?
Yeah, sure. So, I’m a little bit atypical in terms of my path to ending up in architecture. I actually began my career on the mechanical side in aerospace. Even before that, I explored teaching a little bit. I just had a real tough challenge finding how to mix all of my loves together. Having something out there in the world at the end of the day, but also being really involved with people and managing complex systems.
I was intentionally exploring a couple different areas and found my way into both digital and then really leaning into software architecture. That’s where I can fully manifest my love for the EQ-style work. Getting people involved, educating them on what’s available, and then building and integrating into this complex space.
So now, I’m a systems analyst slash systems architect in aerospace for DFJ, where I’m primarily focused on shop floor applications. Manufacturing execution systems, ERPs, warehouse management systems, that kind of stuff. Every once in a while, I’ll get involved with integrations on the floor, like real-time data back and forth with cutting machines.
What’s it like working in aerospace?
Yeah, I’ve been through a couple companies. My first internship was actually with Sikorsky, and I was with Collins Aerospace and Pratt & Whitney for a bit too. It’s a fascinating space. It often feels like you’re at the point where lava meets the ocean. Opposing forces collide, creating chaos but also something new.
In almost every part of the industry you see this duality. On the digital side, you still have systems that were built in the 1960s and 70s. Fortran, literal punch cards for machining and stamping parts. Those systems are still around today to support older aircrafts. And right next to that, you’ve got cutting-edge work, things like evolutionary algorithms optimizing aerofoil design using complex fluid dynamics approximations.
Then there’s the people dynamic. You’ve got folks working into their 80s who literally built those original systems, alongside a younger generation coming in now. Aerospace went through a big dip from the 1980s until just after the financial crisis, so you really feel the mix of two worlds colliding. New blood and old guard, different cultures, different expectations.
That comes with a lot of friction. It can be helpful to be thick-skinned and politically minded at times. But it’s also what makes the space so complex and interesting. For me, it’s built my skill set really well.
What do you do as a systems analyst? How’s that connected to software architecture?
Yeah, I don’t fit the system analyst mold perfectly. I spread out quite a bit. Typically, a systems analyst is supposed to be the liaison between either the business or the business analysts and the developers. We take a thorough understanding of the problem domain and its peripherals and integrate that into meaningful structure for the packages that we’re going to hand off to the devs.
In aerospace it is often challenging to ensure mechanical or logistical needs are expressed in ways that line up with modern software development. So there’s a big gap, and it’s been my job to help bridge that gap. Getting the right people talking to each other and making sure there’s some way of communicating across that divide.
That often involves a lot of validation and verification of requirements. Sometimes that means setting up tests, sometimes wearing the hat of a pseudo–test engineer. Given how much is always going on in aerospace, you have to pick your battles. But the point is, we make sure what’s being asked for actually makes sense and is achievable.
And then there’s the architecture piece. Taking that early understanding of the business domain and the technical requirements, I start to formulate real architecture. I work with the formal architecture team to instantiate high-level architecture, and then carry it down through the lower levels until we have detailed designs (the L3s in the C4 model) for the developers. So yeah, even though the title says analyst, in practice I end up doing quite a lot of architecture work too.
What’s the hardest part in your role?
So in my mind, most of the time, any technical problem, while enormously complex and deserving respect in its own right, is often still easier to solve than the socio-technical problems.
The biggest challenge is getting alignment. Alignment on whether there’s a problem in the first place, alignment on what the problem is, and alignment on what the solution should be. That has always been the number one challenge.
Anytime you come out of a committee meeting, what people have built “by design” is almost always out of line with what the user actually asked for. And that pervades everything, the implementation side, process changes, you name it.
So yeah, the hardest part is dealing with the old ways, managing the bureaucracy, and convincing folks that a new approach, or even just addressing a problem you see is actually worth their time and money.
Aerospace makes this even harder because it’s such a financially constrained and complex industry. The margins are razor thin compared to something like SaaS, and the products take 5–15 years from initial designs to finally building the first plane. People are already overwhelmed with hundreds of thousands of technical problems they have to solve, from manufacturing plans to material science. So even just raising a new problem can be a challenge in itself. Sometimes the hardest part is just keeping everyone calm, on an even keel, and willing to engage.
How do you actually get stakeholders aligned on architectural decisions?
I think the best approach I’ve had for success is twofold. First, you engage with the ceremony, whatever process has been set up for making change, you follow it. Even if you don’t love the process, engaging with it is a token of goodwill. It shows you’re respecting the way things are done.
But in tandem with that, you have to do the extra work of making sure you’re connecting with people directly. That means as much close contact and face-to-face interaction as possible—whether it’s Zoom, phone calls, instant messages, or emails. And usually it’s not just one outreach. It often takes two or three touches. An email, a chat message, and a call, before someone engages.
The point is to get stakeholders to invest in the problem, to feel like they’re part of it. That’s where you get that little bit of the IKEA effect, where someone values the solution more because they helped build it. If you can get that personal connection and buy-in, alignment becomes much easier, even if it takes a lot more legwork upfront.
Can you share an example where IcePanel helped solve a concrete problem?
100%. For years, I had been trying to hone and tune a Visio custom template that I’d put together. People were happy and excited when I presented it, but it was just utterly inadequate for the magnitude and scale of the problems we deal with. And with Visio, you don’t have a model behind you. You can’t just search for and add whatever object you need or lean on connections to quickly slap together a diagram. Instead, you’re stuck manually dragging boxes around for hours. And getting the arrows to line up was horrific. Having an aesthetically pleasing diagram at the end was basically impossible.
IcePanel changed that. The C4 paradigm and IcePanel’s somewhat opinionated structure gave me the scaffolding I needed. It made the whole process of thinking about and communicating architecture so much easier. Before, I had heard about the C4 model in passing but never really engaged with it. As soon as I tried IcePanel, I was hooked, I couldn’t stop using it and I now recommend it to everyone I know that works with software.
With IcePanel, almost every modelling task has become much easier. I can take a system landscape diagram, maybe add a couple context diagrams, break it down one more level, and walk stakeholders through the journey, “Look, this flow went back and forth multiple times. If we package these message all into one, we can significantly simplify our system.”
That kind of visualization lets me surface misalignments and make the case for common-sense fixes. Sometimes it’s just a slightly bigger lift, but the payoff is huge: less rework, less maintenance down the line, and a solution that’s much better aligned to what the user actually needed in the first place.
What advice would you give to teams starting with C4 or IcePanel?
I’ve very commonly found that the sales pitch of the model doesn’t quite do justice to the spectrum of intangible benefits you get by having that model in your back pocket. Taking a little bit of time to even do even just basic diagramming of the most important top-level systems, you can cut the prep time for a number of presentations massively. I can just slap on a couple tags, turn on one flow, or make one or two tweaks to a diagram, and export it to an image for PowerPoint slide, or better yet poke and prod the model live during the meeting.
The dynamics and interactability of the tool and the model are super helpful. For onboarding, I can write a thousand docs and how-tos, but it’s not going to touch the broad, intuitive understanding you get from seeing the system landscape, or a C2 diagram as a new dev. The explanations are cooked into the model objects, the names on each connection, and the ability to go look at how things talk to each other in the flows. With IcePanel, a new dev can easily facilitate their own learning about the various business systems and the wider landscape systems.
The biggest benefit is probably the least visible. Since IcePanel is so intuitive to use, people can investigate and learn for themselves. Time is saved with each meeting that no longer needs to happen, the prep-work that doesn’t have to done, and each questions you no longer have to answer.
The only other advice is: do everything in your power to keep in contact with the folks who are actually maintaining the diagrams and the model. Keep that conversation going and maintain alignment, even if things aren’t quite the way you’d like. Consistency is king over perfection, and alignment is far better than having separate paradigms.
Where do you see software architecture going in the next 5–10 years?
I say this with confidence that I don’t think anyone probably should have, but I see us continuing to lean into model-based enterprise as far as we can.
Something like IcePanel allows for that very well, because it gives us a clear hierarchy of how humans think. We tend to be kind of teleological in our thinking. Everything is oriented toward some purpose we’re trying to fulfill and the C4 model does a really good job of supporting that.
At the same time, there’s all this craziness happening with AI and large language models. I’d bet against AI making human work obsolete in the next 10 years, but I do think the most effective people will be the ones who can leverage both the human and machine element together.
That’s why having a model that is both human-readable and machine-readable is going to be the key. If you can do that, you’re going to be propelled far beyond your competition. So much so that I honestly think organizations that aren’t doing this will be able to compete at all.
Thinking about it, digital circuits operate at a million times the speed of human biological circuits. Even something only semi-intelligent, running at digital speed, will have a huge advantage over time.
Beyond AI, there are also trends like serverless or event-driven architectures. Has that changed how you think about system design and your role?
Like I mentioned before, making change in aerospace can be challenging, but there are definitely opportunities. When legacy systems are finally sunset, modern approaches like event-based architectures can be brought in to capture the benefits of better distribution, disaster recovery, cloud capabilities, all the advantages you don’t get with big monolithic systems.
But the tradeoff is always, what does our team actually have experience in, and what can we realistically manage? Is it worth making huge architectural changes to legacy systems that, if they fail, will cripple the business tomorrow? That’s the reality we live in.
Every once in a while, opportunities do come up to make those evolutions. But you still have to consider the people supporting and maintaining those systems going forward. Sometimes external constraints only permit your systems to communicate with an FTP server or a message queue, and as painful as it is, that’s what you’ve got to use.
So yeah, trends like serverless and event-driven design are definitely interesting and valuable, but in aerospace the practical constraints of legacy systems, team skillsets, and business continuity always dictate how far you can go.
What advice would you give someone who wants to break into aerospace in a technical role?
It’s hard to give a direct answer because I’ve kind of taken a very indirect path. I’m kind of a unique case. Generally, the key is to have respect for the clash between the old and the new. You need to understand that some of the old ways of doing things carry wisdom, even if they look outdated or silly from a modern perspective. Come in humbly, with the mindset that your ideas may not always be right for reasons outside your control.
On the technical side, there’s nothing magical about aerospace. If you can solve complex problems in any other tech industry, you can do it here too. The difference is the business complexity. It takes humility and time to build up that knowledge so you can apply your technical skills effectively.
So the advice is, put in the time, be patient, and develop EQ so you can manage the different parties involved. If you do that, you won’t just do fine, you’ll probably become one of the best employees the company has.
Any misconceptions about working in aerospace you’d like to clear up?
Yeah, I mean it’s true that the glamorous stuff, the space, the flying, the cool tech is a core part of aerospace, but the day-to-day reality is often that you’ll be maintaining or integrating with legacy systems. That said, if you understand the space, know the stakeholders and how to speak their language, you’ll be able to have a tremendous impact.
Thanks so much for your time Matt! Interested in breaking the ice with us? Give us a shout — mail@icepanel.io.