2.9 Functional architecture

Before getting started, make sure you have everything you need to proceed. Our definition of ready gives us a chance to double-check and, if needed, go back to previous activities to finish up anything that’s missing.

Before starting

Functional architecture is the last step in Blueprinting — it takes the North Star artifacts (your service catalog, architecture foundation, and delivery processes) and answers, “exactly what technology do we use for this specific thing?” Up to this point we’ve chosen design patterns (for example, “event streaming”) but avoided naming exact implementations (for example, “Kafka”). This activity makes those final selections, so we can move into implementation.

Guide to functional architecture

At this point, we have a high-level architecture but it lacks some specifics. We’ll need to discuss those specifics and make final technology selections — which may include workshops or spikes.

This is chiefly a technical exercise, and it’s a foundational one (you want everyone to have clarity, and offer their input). You’ll want your entire development team participating, and will likely need to involve the business here and there (for instance, making specific decisions regarding performance, cost and reliability).

This exercise is iterative. Your first run through doesn’t have to be perfect or final. In fact, it probably won’t be — because we don’t want monolithic design, we want velocity. It’s better to iterate on a smaller increment, trying out ideas, proving and disproving them.

We also want to focus on delivery following steel thread principles.

What’s a steel thread?

A steel thread puts in place all critical architectural pieces of a system without diving too deep into specific features. We want the large brush strokes filled in, and all the significant risks eliminated early. In our Peloton bike use case, that might look like establishing simple authentication, an event log, a single transaction, and seeing that result in sending an event to an external banking component. Functionally, it doesn’t do a lot, but architecturally it touches on all our major components.

Feel free to go back to this article on steel threads for a refresher, if needed. Everyone on the team should be familiar with the concept, and should be thinking about delivering a complete thread in just a couple of sprints.

Inputs

• Participation from team leads, architectural leadership, and engineering team, as well as some availability of business team.
• Service catalog providing current candidate technologies.
• Architecture foundation artifacts (including your high-level architecture model and architecture realization).
• Documented delivery processes and tools.

Process

In this activity, you’ll be collaborating on a canonical functional architecture. You’ll want to make sure everyone is briefed ahead of time on objectives. Depending on the scope of your project, you may want to schedule multiple, shorter working sessions.

As you go through this exercise, you may need to run a spike or breakout session to do additional analysis. As candidate solutions are proposed, questions are likely to come up. For example, has anyone actually wired your IAM solution into your gateway before? It’s probably a good idea to try it out, if not. These should be short, minimal spikes — it might just be reading some documentation, or spending a few hours to confirm a hypothesis. You want to complete the design quickly, but also don’t want to proceed with blind assumptions.

I find the most effective way to create the functional architecture is to start from a copy of your architecture realization drawing, from chapter 2.7. This drawing should have all of your major architectural components, making it the perfect starting point.

Prepare

1. Organize your working sessions appropriately, based on the scale of your system. Make sure everyone has access to your design tools, and make a copy of your architecture realization drawing (to use as a starting point).
2. Share material for each working session with everyone who will be participating ahead of time. Make sure everyone has access to:
   1. Your service catalog (from chapter 2.6).
   2. Your architecture foundation designs, including the high-level architecture and architecture realization designs (from chapter 2.7).
   3. Your delivery processes and tools (from chapter 2.8).
3. Scope your workshops accordingly and try to establish some clear goals if necessary. For a particularly large architecture, you may want to focus in on one area to start.
4. Schedule accordingly, knowing that some of the larger technical decisions will require a significant amount of time. I tend to favor 2 to 4 hour working sessions, giving everyone time for breakout sessions — and avoiding “meeting burnout.”
5. Make sure everyone has access to your design tool (such as Miro). Everyone should be “hands on” and contribute to the design.

Execute

Stay focused on the idea of creating a design around a steel thread. You want to have all the major components identified and slotted into their proper place. You do not need to define every single little feature that depends on the same core technologies.

You may discover new requirements or complications! Don’t worry. That’s perfectly expected and is, in fact, one of the reasons taking a careful, intentional approach in design is valuable.

Any new discoveries, requirements, complications should be documented. You might do this right on the functional architecture design, or you might go back and add it somewhere else. The most important thing is to capture it, so it isn’t lost.

1. Modeling activity
   1. Simplify. Keep in mind that we are defining architectural stereotypes. In other words, we only need to define how something is done once. Remove duplicate components from your architecture diagram, until you essentially have one of everything.
   2. Technology selection. Begin adding notations to indicate what technologies will be used for each of the components, APIs, and channels on your diagram.
   3. Elaborate. Add more detail as necessary to resolve questions. Often several technologies will be used together to achieve an end result — model the entire solution. If unknowns surface, go ahead and document them on the diagram, noting what needs further attention.
   4. Iterate (internal). Continue adding fidelity until an acceptable solution emerges as a clear winner. Indulge in further conversations about patterns, architecture principles, and key assumptions where necessary.
2. Finalize
   1. Functional architecture. Your final functional architecture drawing shouldn’t have too many open questions but, it may still have a few. If the team agrees it’s OK to postpone those decisions for the future, then proceed — but avoid leaving any high-risk unknowns.
3. Document. Be sure that new discoveries (requirements, changes, constraints) are adequately captured — for example, going back to event maps and updating designs. You may find that new technologies should be proposed in your service catalog.
4. Iterate (external). Solicit feedback from the architects within your organization to gain alignment and further insight.

Outputs

• Functional architecture model. A view, usually simplified, of the target state architecture that elaborates on specific technologies and design decisions. It should clearly express the technologies (languages, frameworks, tools, libraries) that will be used for each architecture component.

Example use case

Following the activity process, our first step is to take the architecture realization diagram, make a copy, and strip it down by removing any redundant components. We want to clearly establish our design patterns — it’s only necessary to establish a pattern once.

In the simplified drawing, you remove everything that seems unnecessary to complete the functional architecture model. That means removing components that provide some contextual value, but are essentially just duplicates — at least, architecturally if not functionally.

It can be useful to leave two services. At first glance they might appear to be architecturally redundant, but one thing we need to express is how two different services communicate. Choosing foundational services (for instance, “Customer” and “Loan”) helps, because whatever steel thread we define is likely going to use these two services to achieve some basic proof of value.

From here, we can begin our design workshop.

It’s very likely that you’ll discover something new — new questions, unknowns, possibly requirements or limitations. These can be documented on the diagram, as red post-it cards. Big question mark icons help clearly highlight there’s something we need to investigate.

Your first iteration is probably going to look complicated, especially if you have a lot of unresolved questions and gaps. That’s expected. You’ll likely see:

• Several unresolved questions (denoted with big red question marks). These represent unknowns that we must resolve before moving forward. We don’t have to build the complete solution, we just need to know the path forward is clear of major risks.
• A few red cards. These highlight major concerns or decisions that we need to make. For example, are we going to use a serverless or server-side architecture? This is pretty fundamental to the design, so moving ahead without an answer isn’t possible.
• Margin comments and assumptions. Among these are some spikes we’ve called out — we need to resolve those as well.

Now is the time to plan some breakout sessions, dividing and conquering to resolve all these unknowns as efficiently as possible. Let the team break up into working groups to do necessary research, perform a few quick spikes, and do whatever else is necessary to eliminate major risks and agree on a path forward.

After each decision is made, risk is eliminated, or question is answered, we get clarity and usually simplification.

After a few rounds, the final functional architecture model is much cleaner and gives us all the answers we needed before moving forward. There are probably still a few questions — that’s fine — but these should all be deemed acceptable by the team, something we can tackle in the future.

We haven’t yet gone into engineering designs, detailed specifications, or done any estimation. That said, the team has enough information and reasonable confidence that this represents a complete canonical architecture. It starts to call out a steel thread that the team feels reasonably confident can be delivered in one sprint, or if not one, then two.

Most important, we have a solid first attempt at our functional architecture, and nobody on the team has any questions regarding the technologies we’ll use, or how we’ll apply them.

Tips for a successful workshop

For engineering sessions like this, it’s important to align for a productive, successful session. For a deeper treatment, see My formula for running a successful workshop.

• Send everyone materials well in advance, and give them time to prepare. Set expectations regarding everyone’s involvement, especially for anyone with an important role.
• If there are known outliers or questions, jumpstart progress by asking a team member with some available time to research the topic before the workshop.
• While my preference is to engage and collaborate with drawings, don’t be too prescriptive. If someone wants to introduce a different kind of model, describe things in a table, or use a SWOT matrix — indulge. Anything that contributes to the architecture is a win.
• Delegate the job of capturing action items. That way you can focus on the design activities, knowing there’s a second pair of eyes and ears making sure things don’t get lost in all the action.
• When working on architectural drawings, avoid deleting anything. Instead, make a copy in a different part of the workspace. Tools with unlimited drawing space, like Miro, are great for this.
• Drawings can get quite large, and often have a lot of cross-references. Use linking within the drawings to facilitate navigating (Miro does this).

Wrapping up Blueprinting

This finishes your Blueprinting phase. Now that we have all of our “prints” (meaning, designs and drawings) we’re ready to move into the Delivery phase.

Before moving on, you might want to review the activities and artifacts from the Blueprinting phase to make sure they are all up-to-date. Various notes and “to-do’s” accumulate during design. Think about the next team member joining the team — they’ll be counting on designs that provide an accurate description of the system.

In the next chapter, 3.0 Delivery (phase 3), you’ll begin the iterative build of your first product increment. The first activities in Delivery are value mapping, and identifying your first product increment. These two activities work well together. The former focuses on establishing high-value results, while the latter pinpoints exactly what you can build and deliver quickly.

Next activity

• 3.0 Delivery (phase 3)