# Software Architecture: Business Alignment, Constraints, and AI

**Podcast:** The InfoQ Podcast
**Published:** 2026-06-01

## Transcript

If your team has AI running in a proof of concept, but you're still figuring out how to run it reliably in production, you're not alone.
That's the gap most engineering teams are navigating right now.
QCon AI Boston, this June 1st and 2nd, brings together senior engineers, software architects, and technical leaders who've already made that shift.
They'll share the patterns that scaled, the mistakes that didn't make the blog post, and what they'd actually do differently.
No hidden product pitches, just senior practitioners helping senior practitioners.
Learn more at boston.qcon.ai.
Welcome to the Architects Podcast, where we discuss what it means to be an architect and how architects actually do their job.
Today's guest is Sonia Nittansson, who is a seasoned engineering leader and software architect working at the intersection of social and technical aspects of software engineering.
She experiments with various methodologies such as domain-driven design, team topologies, architecture advice process, and others to improve building and operating software in the healthcare sector.
She speaks about the outcomes at international software conferences and meetups.
It's great to have you here on the podcast, and I'd like to start out by asking you, how did you become an architect?
It's not something you decided one morning you woke up and said, today I'm going to be an architect.
No, not at all.
And thank you for having me here.
I am what they call an accidental architect.
I think Mark Richards was the one who coined that term.
And it really resonated with me.
It's not something I set out to be.
It's not something that was even a term or a role when I started out in software engineering.
But what I observed is...
With my work as a software engineer, I took on progressively larger and larger projects.
And at some point realized that my work is really more in putting pieces together, understanding the big picture, understanding how the whole thing is supposed to hang together.
And there wasn't really a word for it.
And when I heard software architect, I thought, yeah, that really fits.
started taking on this role, I imagine you sort of evolved into it.
What struck you the most that people were not doing right?
You know, was it technical?
Was it political?
Was it social?
The intersection of all these things?
Two things struck me, and they were revelations in succession.
First being technology really is not as important as we technologists seem to think.
If I made something for the user that works with a bunch of hamsters in a wheel and they're happy, that really is all that matters.
They don't see those hamsters.
I get to feed them.
Things work great.
And that was revelation number one.
I thought, oh, I need to talk about technology less and talk about what I'm trying to accomplish more.
And the second one really is how much we need to understand the business.
And what I find very interesting about this is time and time, role after role, I noticed that no one in the business really wants to understand how software is built.
But we software engineers and architects really need to understand the business.
So this relationship is definitely not a two-way street.
But if we underestimate the importance of understanding what the business is, how it works, where it makes money, how do we get users, not lose users, we fail as architects because we can really direct things towards those business outcomes.
find the well-known statement of Gregor Halpe about the elevator architect.
You have the ability to explain the technical things to the business folks and the business stuff to the technical people.
And it's amazing to me how difficult it is for people to express what they really want.
I've said this over and over again during my software career.
I've only done three things.
Trade-off space and time.
insert levels of indirection, and try to get my clients to tell me what they really want, which introduces the interesting sort of topic that people don't talk about, which is requirements analysis.
And how do we actually go about this process?
And what are the ways that you have found that it's best to get people to tell you what they really want?
Oh, that's a tough question.
I think it's...
a continuous conversation.
There isn't a single time, a single meeting that you could have where you elicit that.
It is a constant process.
And I would argue at times that it's not just soliciting a requirement, soliciting behavior, but also shaping it in a way.
By nature of this really malleable technology called software, we can actually shape behavior and make users do things that they want.
And there's some value in saying we're not just going to ask a question because sometimes users will not know what they want, but we're going to try and shape it a little bit by introducing new things, new form factors, other things.
I'll give you just a tiny example of how my personal behavior is shaped.
I was checking out at the store and there were a bunch of prompts that I needed to click answers to in the register.
And I completely mechanically kept hitting the right button because I wanted it to be a yes and I wanted to get through it.
And the right button happened to be no.
My behavior is already shaped by...
somebody coming up with this form factor and saying, okay, the continue, the next should always be on the right side.
So there is some value in not just asking the question, but also proposing things to do that can shape that behavior.
But in terms of how, I would say, try many different things.
And most importantly, listen.
Don't just respond, but really, really listen and really try to Draw conclusions out of it.
Play things back.
Make sure you're well understood.
And represent back in different ways what was said.
I find words to be very valuable, but also very ephemeral.
If they're not recorded in some way, if they're not documented in a way that people can gather around and talk about, they become very, very open for interpretation.
Well, that's certainly the case.
I mean, from the point of view of human interaction, the fact that language is ambiguous is very useful.
But from the point of view of a stupid, dumb computer, it's not very useful.
I mean, to pick a simple example, if I came to you and I said, this program has to be fast.
Well, what does fast mean?
It seems that what you're implying is that there has to be continual conversation where you actually have to model out exactly what people mean when you say fast, when you say organized, when you say availability.
These have to be modeled out.
Yeah.
And there is a concept in domain-driven design called ubiquitous language.
I will say I've...
tried to instill this in many different places.
What is the ubiquitous language?
How do we talk about this concept or that concept?
It's been a very interesting experience because the technology language and business language is almost always different, even in the core concepts.
And you'd be surprised to find What things shape our language?
The platforms we use, I find, are exceedingly influential in shaping our language.
And coming back to the question, how fast is something?
I find people think much better in relative terms, not in absolute terms.
So modeling it out in the world that they live in, in their functional reality and saying, we can get it to here.
And these are the trade-offs that we're going to have to put in place in order to get it to that level of speed.
Does this work for you?
Implicit in what you just said are two interesting things, and they're both, of course, part of domain-driven design, is one, how do you get to the ubiquitous language?
Because if you can get the technical people and the business people at least to understand each other, then you've made a major contribution.
And the other one that comes out of this conversation is also the constraints.
In other words, I personally feel, and you can tell me if you agree or disagree, I think constraints are a great thing because it actually helps you come to a conclusion or to lead the design in a certain direction.
You and I are in violent agreement.
I think a completely open field with no constraints.
is really difficult to work in.
There are too many directions.
There's analysis paralysis.
And it's just too easy to wander off in a place where you probably don't need to go.
Constraints do really shape this.
And you and I will call them constraints.
Other people will call them requirements.
I was just reflecting back on.
a system that I architected.
And one of the constraints was certain algorithms had to be absolutely isolated.
They couldn't affect each other.
That was a regulatory constraint, but it helped us say, okay, there are certain things we already know we can't do.
And it shapes the design of that system pretty nicely.
So I really do like working with constraints because it just shapes the path.
much quicker.
But presumably to get to the constraints, you have to come up with that ubiquitous language so people can express those constraints in understandable ways.
In other words, if the technology people don't understand what the business people are talking about, they think they're being arbitrary when they actually are not being arbitrary.
So do you have any ideas how you get these business people?
and technical people together to find these constraints to get this ubiquitous language because if you start out with ubiquitous language then you're really ahead of the game yeah well i personally love workshops and I like workshops to be fairly large and well attended, even if some people are bored for some periods of time when everybody's in the room.
It's just easier or in a virtual room, it's easier to pull people in to say, OK, what about this?
What about that?
Get their attention.
What I find is, and this is honestly on both sides of the aisle, what folks really need practice with is they don't put together.
problem statements very well.
And I heard this absolutely brilliant definition of a problem statement that I took with me throughout my career.
And that is, the problem statement can contain one of two things, either good outcomes that are not happening, or bad outcomes that are.
And I thought, my God, this is absolutely gold.
And the corollary to that was, if your problem statement starts with, we need, It's going to be a solution statement.
It's not going to be a problem statement anymore.
And a lot of these things that masquerade as problem statements, in reality, are solution statements.
We need X.
We need Y.
A lot of right now, we need AI.
AI is in a lot of places.
I find that it can be a solution in search of a problem at times.
But really, crisping up problem statement and spending actually a lot of time on that, helps with those conversations.
Once you coalesce around a problem statement, you can start peeling the layers.
This is how constraints emerge.
This is how requirements elicit themselves, at least on a high to mid level.
What you seem to be saying is when someone comes to you and says, we need X, a solution statement, it seems to me you really have to try to peel that back.
And ask them, why do they need X?
Because you want to convert that into a problem statement because that you can work with.
I always find if I need to redirect that, the question that I ask is, what is the useful outcome that you're trying to accomplish?
And the keyword there is useful, well, and also outcome.
And then people start thinking about, why am I asking her to?
do this in microservices or something else that's very much a solution rather than a problem.
So that's been a really helpful tool.
And my tool belt is asking, like, give me the useful outcome.
And then let's give us some space to think about this useful outcome to see if there are multiple ways of approaching this.
We get so anchored into a solution state that sometimes it's right.
It's this is the solution to take to solve that problem.
But without the problem statement.
We can't really measure whether we achieved an outcome, whatever it is that we're decomposing monolith into microservices for.
Did we accomplish it at the end?
Maybe we got microservices, but the bigger goal is still not attained.
And giving ourselves space to think about alternative solutions.
Sometimes people come up with better things, better options.
So that raises also another thing that I think I've heard you speak about, but certainly as implicit in this statement, is when you have a problem statement, and that problem statement has a business goal in it, you are dealing with the reality of the current situation.
And that very often comes up against what people sometimes call best practices, or this is the way you should do it.
And maybe you could comment a little bit on that.
Honestly, I love best practices, assuming that they exist.
And when I think of best practices, I think of for a use case like this, what would be a reference architecture that I can utilize?
Has anybody put this together already?
Has it worked for them?
I don't want to reinvent the wheel if I can help it.
Our work is already difficult and there is a lot of it.
That said.
You have to keep the context in mind.
I spent a lot of years in healthcare and you would think that all the problems that I'm solving are the same problem over and over again.
But the context is different enough that you can't necessarily forklift something that you've done before and implement it in the next place.
There's always enough differences where your best practice needs to be.
adjusted, needs to be changed, needs to be shifted.
And honestly, sometimes needs to be thrown away because there's, you name it, new technology, new regulation, a new boss who wants to do something exciting and innovative.
Lots of new things where you just need to go, okay, I know I've done it before like this, but let's think about a new way of doing things.
That's best practices.
I do like them.
I will say if you approach them without dogma and contextualize them, they could be very helpful.
Do you find an understanding of this context comes from domain-driven design?
Because there's a certain idea of a bounded context in domain-driven design, or you see that as something sort of different.
I think there is a lot of it there.
And honestly, I think it's the desire to understand.
the totality of the business and then be able to draw pieces of it that you're going to address.
It's really easy to get overwhelmed as an architect because there's just a lot.
Businesses are surprisingly complex.
And I've learned over time not to dismiss anything that might look simple on the surface because once you start looking at it closely, there is...
always nuanced details, things that just put on layers of complexity.
So having that capacity, almost similar to the architect elevator to go up to 10,000 feet, 30,000 feet, and then come back down and say, I am going to just take this piece at 5,000 feet and work through this, bound the context.
Without completely losing the bigger picture around it, yeah, absolutely, it's a skill that comes from domain-driven design.
When you work with teams, are they familiar with domain-driven design?
Or is this something they have to be taught or made to appreciate?
Because I've always found it to be a very powerful idea.
In my career, I've only encountered a few people who were truly interested in it.
But what I also learned is...
You don't have to root something in a particular methodology in order for people to utilize it.
You could just say, this is what we're doing and this is how we're going to do this.
And by the way, it's a really fun trick.
You could be trained in something, not train anybody else and just be that facilitator and see how far you could get.
I hosted a workshop that was effectively event storming.
Nobody knew the words event storming or what it's supposed to accomplish other than me.
But we started the workshop with, here's what we're doing and here's how we're going to do this.
And lo and behold, at the end of the day, there were a bunch of people who, without knowing that they participated in event storming, participated in event storming.
So some of this is just...
train by doing without giving folks really big books.
But I have had people who took this further, read Eric Evans' book, and really tried to internalize a lot of these concepts.
I can see doing that with event storming, but coming up with an ubiquitous language seems to be something you have to do a little more explicitly.
Or I guess you could do it, I just think out loud, implicitly by getting the business people.
and the technical people talking with each other and see how the concepts sort of emerge from the conversation.
Yeah.
And somebody has to sit there and say, I am going to write a glossary.
I've gotten a lot of mileage of saying glossary rather than ubiquitous language and say, here's the word that you use and this is how you define it.
Do we all agree on this?
Or is there something else that I should write in front of you on the screen that we know now that we're talking about the same thing?
This is interesting because You know, I've certainly taught domain-driven design and I participated in such efforts.
But the idea of doing it without telling people you're doing it is sort of an interesting idea.
And perhaps people should think about this.
Because what I hear you saying is that if you present it to someone directly and say, we're going to do domain-driven design, you get a certain amount of resistance.
Yeah, because this is yet another methodology.
This is another thing that's getting in the way because some managers have this idea of why isn't Johnny coding?
Why isn't Joanne coding?
You know, why are we doing all this talking?
Why don't we get to this?
But if you can do this, I don't want to say surreptitiously, but if you can do it sort of obliquely, you can get both things going.
You know, why aren't they starting implementing yet?
Well, we have to help them understand.
what they have to implement.
And in order to do that, we have to make sure that everybody understands this, that, and the other thing.
Now, why isn't Johnny coding sounds particularly funny now?
I feel like we've done, I don't know, 180, 360.
I can't tell how many degrees we've gone.
But I always thought that engineers should be spending more time thinking and less time typing, meaning really good designs, really good work.
It's simple.
It's succinct.
It's elegant.
It shouldn't take miles and miles of code.
I feel like we got back to the same place, except now the coding is done for us.
So there's that space for engineers to think and figure out exactly what they want to accomplish with now bigger, better tools.
Now you raise the almost irresistible question.
of the world of agentic AI.
Let's assume for the moment that obviously there's a trust question about whether you can actually trust what the AI coders produce.
I've spoken to quite a few engineers who say, you know, you always have to check what they do.
You can't trust what they do.
But let's assume for the moment we've gotten beyond that.
And these AI coders are just like any other coder.
I mean, you know, when you have humans coding, you don't trust them completely.
You have tests, you have things like that.
So let's say we treat them the same way.
But what does architecture look like?
How do you communicate to these agentic AIs?
Or how do you define the agents or where the agents fit into the architecture?
You know, I've stopped predicting a year ago.
I feel like we've gone such a long way.
I do think that as long as AI coding remains fundamentally for humans, and let me unpack what that means.
There's no reason why code needs to be written the way it is right now if it's written entirely for machines and by machines.
It could just be machine code.
Why do we even have all the in-between stuff of human-readable code that then needs to go through a four-pass compiler and become machine code and get deployed and all of this.
It could just run on the machines.
I think for as long as coding happens to be for humans and we want to retain some modicum of control over it, meaning we want to be able to look over it and understand it and change it if need be and correct it or throw it away.
The architecture is going to remain kind of the same way.
We will define things conceptually.
We will lay out boundaries.
We will modularize things in the way that couples things more or less depending on trade-offs.
I think all of that will remain the same for the time being.
And again, I will caveat this that a year from now, things may be vastly different.
Or better or worse.
Yeah.
What always bothers me when I think about this scenario is not at the senior developer or the architect level, but at the junior developer level.
How are we going to train junior developers if all these AI tools are doing the coding?
I mean, it's one thing for a senior engineer to say.
Oh, yes, because I use Claude.
I'm 10 times or five times more effective because I can get it to do the easy work.
But that's the work the junior developers used to do.
So how do people become senior developers if the junior developers are these agents?
Tooling is an interesting thing.
And there is this constant compaction that takes place of bigger and better tools.
We, again, don't use punch cards, don't use any of the ancient tooling before because we've gotten better, but we haven't lost our ability to build and design things.
I think using the tooling to do more rote work and having the junior developer, somebody who used to write it by hand, write it with the tool.
is totally fine as long as that junior developer is then able to explain what was done.
And I think that that's the key.
Reviews are still a thing.
It's a big thing.
People look at agentic code or agent-produced code before it goes to production, assuming, of course, they're doing anything of material value and there's customers on the other end that might get angry that things went wrong.
Being able to explain why things were done the way that were done, what can change, and being able to, if change is needed, send off an agent to change it in the way that was requested, I think is going to be the skill that we're going to shift to.
First of all, I remember punch cards.
I've been doing this for a long time.
I remember, for example, working on IBM 1130 where there was no file system and you had to load your program into a particular disk block.
And then you had to load the linker and the loader and you had to tell all these things that people today have no idea.
You know, they don't realize, as you said, compilers, debuggers, linkers, loaders, outbringes, file systems, these were all invented at some point in time.
And you had to do those things exactly right.
If you don't do it exactly right, like, First try, no warm-up.
That's it.
Yes.
For one course I took, I got one run of the punch cards a night.
And if I had misspelled something, that ruined the whole thing.
But my point in bringing this up is one of the things that I kept as I made this technology transfer is I developed an intuition about how systems work.
And the most important thing about this intuition...
was to understand where the abstractions broke down.
I once was programming a personalization system.
And normally to scale things, you put them in the database because the database, they know how to scale.
Turned out, for various internal reasons which are not important, the database was not scaling and I had to put the scaling in the middle tier.
in the object layer.
I could only do that because I had an intuition about how the database worked, how the middle tier worked, how things scaled.
And what I'm afraid of is that working with these agentic tools, people will lose that intuition to understand where things are not going to work.
because the abstractions break down.
Yeah, I think it's a totally valid concern.
There is some level of de-skilling, if you will, that's going to take place.
But in my experience, and I think in your experience that you described, that only happens until things don't work.
I'll give you a tiny story in response, and that one is a lot more contemporaneous.
where my son was working on a project where he had to parse a Google sheet for his bioinformatics work.
And as everybody does these days, went to Chattopay or whatever.
help he got.
It gave him some code.
He ran the code and things were working except he kept getting this error and he was updating cells in this Google Sheet and the API was basically throttling him because he was making too many updates.
And he was Googling or using AI to get answers to this error message and the suggestions were, well, you can up your subscription and get more API.
More tokens.
Yeah, exactly.
And I looked at it and I said, well, you could just load your sheet into memory, do all updates at once and save it rather than doing it cell by cell.
So little things like that where at some point they have to find the right answer to this.
There will be other options that they're going to have to explore rather than the first thing that AI gives us.
And then they'll have to find the right level of that skill to gain that intuition, come back to best practices or some sort of a known pathways to address a particular problem.
I don't think that's ever fully going away.
Well, let's hope so.
The interesting thing about software is we're always pushing the edge.
In other words, it's possible for somebody who is a mechanical engineer or a build bridge, you can build the same bridge over and over again if you have to.
But usually in software, if we do something, it's because we're doing something new and therefore we're pushing the tools.
We have yesterday's tools being pushed for tomorrow's problems.
You know, I think if you don't really understand what's going on, you're going to get yourself into trouble.
I think you're right.
But I think we're going to just evolve into more narrow specializations at certain level.
Like, for example, I'm not a hardware specialist and people who do hardware to me do black magic.
And I don't see that going away anytime soon.
There are continued.
To do black magic, we still need to interface with that.
So we have to understand enough to build the tools.
So AI is going to be as good as what we trained it on.
If we're trying to do something novel, by definition, we're going to have to work through this ourselves before we're able to train the next model on it.
Well, let's end on that semi-hopeful note.
I like to ask you sort of my architect's questioning, which I like to ask all the people who appear on the podcast, because I think it gives us a little human element to this practice, which ultimately is practiced by humans, at least for the moment.
I don't know if I was interviewing a bot, what kind of answer it would give me, but I'm not worried about that.
Probably a lot more polished one.
Maybe like some LLM answers, a little too polished.
With a little too much made up as he goes.
But anyway, what is your favorite part of being an architect?
Seeing something come together.
Honestly, this is always my favorite part is seeing a solution emerge through ephemeral things like conversation and people going, okay, that's going to work.
Let's try this.
I love that part of it.
It's not the beginning of the road.
You know, it's not even necessarily the end of the road is when it goes to production.
But when all of the requirements, all of the fuzzy problem statements, all of the technology opinions, all of the egos finally coalesce into something that people agree on and can move forward.
That's my favorite part.
What's your least favorite part of being an architect?
I think trying to convince people to look at things from different lenses.
That is such a hard thing to do.
It's hard for me at times.
I fully recognize that I am a product of my own experiences.
I have biases around how things work.
trying to tell folks, hey, just look at it from this direction.
Just think about this in a different way.
I worked with a product manager one time who told me, if you can think of one solution, you definitely can think of more than one.
So go and try.
And I apply that to other people in a much more gentle fashion.
But I always think it's a good way of...
Think about it.
It may not be something you end up going with, but it's a good mental exercise to get you out of those biases and try and adopt a different lens.
Is there anything creatively, spiritually, or emotionally about architecture or being an architect?
I'll say creatively.
It is a oddly creative work, and odd is an interesting word here.
I don't necessarily hands-on do.
everything soup to nuts.
So can I call myself creative?
No, but coming up with solutions, really distilling things.
To me, it's a creative pursuit that ends up in useful things that I can talk about and practices that I can extrapolate.
So it is a creative outlet.
And just kind of on the broader level, people who think that software engineering is just this boring thing of sitting in front of the computer and clacking away on the keyboard, I think really missed the big point of it's actually really creative.
It's work where you get to do some super net new things.
And architecture is just that at maybe somewhat higher level.
What turns you off about architecture being an architect?
I think it's a hard one to strike a right balance sometimes of being high level enough and technical enough.
You can get into a space where rather than riding the elevator, you're stuck in it and you're neither on the ground floor nor at the C-suite.
And the perception is very interesting, I think, and can be challenging for a lot of people.
They're kind of in this zone where...
they can't align themselves with either group.
So that can be a little isolating at times.
Do you have any favorite technologies?
I do, but I think I'm going to hold back because I always get very interesting flame wars when I talk about technology.
I'll say this.
I think Microsoft has always been really good at keeping developers happy with their tooling.
And I've been very partial to Microsoft technologies.
Again, things are changing now.
Maybe those IDs will never get open anymore, but I've been partial to a lot of Microsoft tech.
What of that architecture do you love?
I love the community of practice.
I really, really do.
This is one of the reasons why I go to a lot of these architecture conferences is because I can encounter people.
who do the same things that I do, who are solving not the same problems in necessarily the technical sense or even a business sense, but in a global sense.
How do you break something down or coalesce something together?
How do you keep the big picture in mind while solving for details?
How do you have the right teams in place to do the work?
And that community, it's one of those rare communities where I see people.
want to produce these materials for each other and consume them and give each other good information and good feedback to keep moving forward.
What about architecture do you hate?
That's a strong word.
I don't know, drowning in a lot of technology options.
I honestly, if I have to start selecting one, I don't know, database against another one with slight differences, In the tech, that gets exhausting.
There are a lot of options out there these days.
What profession, other than being an architect, would you like to attend?
It's something that I've had a little bit of time to think about these days.
And the answer as a profession, honestly, doesn't come to mind.
I think it's more, what can I do outside of this and apply my skills to?
I've been practicing my gardening skills, and I really enjoy that.
I do some work with high school students as they're about to go to college or embark on career path, and I really enjoy that too.
I'll say kids these days are so smart.
I am very, very hopeful.
But I don't know what other profession I would attempt, to be honest.
Do you ever see yourself not being an architect anymore?
I think for as long as I stay in engineering, that particular gene is always going to get expressed in some way, shape, or form.
I'm mindful about this.
Don't get me wrong.
When I lead teams, I want to make sure that I don't just steamroll them with my experience and with my knowledge of these practices and let them make their own choices.
But I think it's always in there.
It's like, ooh.
Let me help you.
I know how to do this.
When a project is done, what do you like to hear from the clients or your team?
Honestly, I think maybe the best thing is nothing.
And the nothing here means the technology, the solution is working the way it should.
And it's faded into the background.
It's letting people accomplish what they came here to accomplish.
It's not front and center.
It's not annoying.
It's not broken.
So I think nothing is really a good option there.
Silence is praise.
Yes.
I think we touched on some very, very important points about how to get people on the same page, how we think about...
problems.
I enjoyed doing this very, very much.
And I think our listeners will get a lot out of it.
Thank you so much for having me.
I had a lot of fun.
It was my pleasure.