Issue 02

Welcome new readers 👋 Many of you likely connected with us at Prairie Dev Con a few weeks ago. Oliver and Derrick had a super fun time meeting the local community, demo-ing IcePanel, and furiously giving away server farm t-shirts.

Back to Issue 02. We recently sat down with Matthew Palkowski, a systems analyst/architect from Dassault Falcon Jet, who focuses on shop floor applications. If you’re curious about what it’s like working in aerospace doing architectural work, this one’s for you. Matt’s also a heavy user of IcePanel, and shares a few examples of how it’s used in enterprise.

In other news, Anthropic released their latest economic report, highlighting increasing enterprise AI adoption yet less usage for architecture and engineering tasks. Linkedn shared how they build multi-agent systems at scale, and Pinterest reflects on their docs-as-code journey since 2021.

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.

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.

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.

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.

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.

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.

Read the full interview on our blog.

Oliver and Derrick were at Prairie Dev Con and Winnipeg for the first time. Their trip didn’t get off to a great start, as they arrived at midnight only to find out their hotel reservation wasn’t in fact reserved. Apparently this was a nightly occurence at this hotel 🤔.

Hotel issues aside, they had a fantastic time meeting the local community, talking about IcePanel, handing out t-shirts, and our Yeti cooler giveaway. We’ll certainly be back as a team at some point in the future, maybe to see the polar bears.

Stay chill till next time,