What is Solution Architecture?

solution-architecture.png
 

Planning and executing a project can be challenging, and complex ideas call for complex thinking.  Doing that thinking before actually engaging in the project is key to creating a quality product.

Imagine you want to build an apartment complex. The ground floor will be lined with businesses, including a cafe and a franchise of your favorite gym. The complex will be twelve stories high with fifteen apartment units per story. You’ve picked out the granite slab countertops that will accent each kitchen. There will be an attractive garden on the roof, balconies for every unit, and you bet there will be a pool.

So you share your vision with a team of construction workers, electricians, and designers, then release them to get their work done. Nothing could possibly go wrong, right?

Without a head architect, even a dedicated, communicative team might end up digging the pool too close to the sewage. Worse yet, the team may be screwing the covers onto outlets when you realize that it would have made more sense to use that location to build a hotel instead of an apartment complex.

Complex projects call for complex thinking prior to execution. The solution architecture stage of development helps a team handle that complex thinking.

What is solution architecture?

Solution architecture lacks a central definition. Different industries have different ways of going about it, and even different organizations within the same industry may be talking about slightly different processes when they use the phrase. The definition we will use here represents the way Outside Source approaches solution architecture. 

Solution architecture is the process of creating the right strategy to produce a product, like software. It helps you identify which business requirements to address and what user needs the product will fulfill to be considered successful. Having a clear inventory of what user goals software the product will need to accomplish enables a software development team to effectively chart out how to prioritize and plan out a project that will meet your needs.

What happens in solution architecture?

Solution architecture is so much more than a phase to gather your project requirements. An airtight solution architecture phase refines the product’s purpose, defines the development execution strategy, and charts the roadmap for software development. 

While every organization will run their solution architecture phase differently, at Outside Source, our approach begins after a few initial discovery calls where we learn about the vision for your software.

1) Solution architecture proposal and ROM estimate. Once the developers have a solid idea of what you need from their work, they’ll put together a proposal. The proposal will include the price of the solution architecture phase and the rough order of magnitude (ROM) estimate, or the ranges of what the steps beyond solution architecture may cost.

Outside Source designs the solution architecture phase to match the client’s needs. Providing a proposal for solution architecture and an estimate up front for the rest of the development process ensures that you don’t go over budget or pay for an out-of-scope product.

2) Initial kickoff meeting. Once the proposal is accepted and the budget determined, the team at Outside Source sets an initial kickoff meeting. The kickoff meeting often involves a project manager, a product manager, a designer, and a developer and is a collaborative exploration of the software that needs to be developed. The team at Outside Source will walk through their understanding of what the software needs to do and what a user’s interaction with it will be like. They’ll ask you everything they can think of to fill in the blanks.

For instance, if your software involves a physical component, they’ll want to know your plan for that device’s setup. They’ll ask, “Who’s going to set it up? Will it be the user, or will an installer get involved? What kind of specialty will that installer have to have? Can it be anyone from your team, or does it have to be someone with an electrician’s background?” They’ll ask about device setup, configuration, usage, notification, and any other major activities that your product would be used for.

By the end of this meeting, the team should have a thorough understanding of what a user can do with your product and expect from your product. They’ll take that information and create a user story map for your next meeting.

It’s quite possible to create software without a user story map and this step of the solution architecture phase. But it’s risky. You may, for instance, explain your vision for a banking app that draws credit card interactions directly from user-determined budgets. You may feel that you communicated everything your developers needed to know in order to create the app correctly, down to the color of the sign-in button. But as soon as you see the prototype for the first time, little details are off. In order to sign up, your user needs to type and re-type a password, but you wanted them to have the functionality to create a password, then tap an icon to peek at the password to double check spelling. The username field doesn’t permit special characters, and you’d hoped users would sign up directly with their email addresses. We haven’t even passed the sign-in page and you’re already realizing you need to dip into the budget again to buy more developer time.

A thorough solution architecture phase with a complete user story map will define all these elements before the developers spend any of their time or any of your money on a prototype.

3) Review meeting(s). In your next meeting with the team, you’ll be presented with an initial draft of a user story map. The word map is not descriptive of the way this document looks. It’s referring to the journey the user makes as they interact with your product.

The document will span many pages and have entries that represent the possible variables in the design and development process. The details here will serve as a map for the developers to create exactly the product you have in mind with the proper functionality for the user. The user story map will help you think all the way through the product and what it should accomplish, down to which details to include in a sign-up confirmation email and what to do to recover a forgotten password. It is the genetic code of your future product.

4) Final review and approval meeting. After you review the user story map and provide feedback, the developers at Outside Source set up a final meeting to confirm and finalize the development plan. They’ll come with a finalized user story map to review.

Your software development team should display a vested interest in the sustainability of your product. They may bring up the future of your product and discuss how you might accomplish scaling or altering it eventually. They may even offer to test its viability in a given market.

Remember that ROM estimate back in step 2? Now that solution architecture is complete, the team will produce a project proposal—no estimation involved—for the scope and price of the development phase. This will include a summary of what will be involved in each step of development and actual cost tables. By the end of this meeting, everyone should be on the same page about the exact functionality of your product and what its development would be like. 

How can you tell quality from mediocre solution architecture? 

Plenty of organizations offer solution architecture. But not every solution architecture process will operate with the attention to detail and caliber your product deserves. Being familiar with the signs of a good user experience or software development team may help you differentiate between a good investment that will make your life easier in the long run and a dead-end deposit for your precious software development budget. Here are some of those differences.

  • Length of time. The professional world generally acknowledges that time spent on a project is not necessarily directly correlated with that project’s quality. That said, solution architecture isn’t something that you hammer out between a 10:00 a.m. stretch break and lunch. Thorough solution architecture will take time. Outside Source walks through a multi-level process over the course of four to eight weeks (depending on the complexity of the project). This provides you with enough review meetings to ensure they’re getting the job done right. But just because a developer offers to spend significant time on your project doesn’t mean they’re using that time well. Find a team that spends as much time as is necessary without dragging their feet and squandering your development budget. 

  • Experience of the architect. There is and will always be room in business for the rookie, but the solution architecture phase must be conducted by a veteran. The very nature of the responsibility requires a comprehensive understanding of each element of software development. The solution architect should have a thorough understanding of every facet of software development and would ideally be a software engineer themselves. They must also be able to speak your corporate language and should be comfortable wearing a creative hat to wrap their mind around the hypotheticals central to the development process. 

  • Deliverables offered. If your chosen software development team had only the deliverables offered at the end of the solution architecture phase to guide them through the development process, how likely is it that they would be able to execute each of their unique responsibilities? Would they need extra information, or do the deliverables from the solution architecture phrase carry them from beginning to end?

    Outside Source produces a user story map, any technical architecture documentation necessary, and a revised and final proposal for the remaining project after solution architecture. These deliverables help to ensure that you’ve thought through everything necessary to begin to invest in actual software development. If the deliverables your software development team offer at the end of a solution architecture phase don’t inherently prove that the team fully understands your product’s needs and your direction, don’t trust that team with your product’s future.

You deserve a team that understands the complexities of development and values your time as a business. That’s why you should consider a partner who starts with a solution architecture phase before they write any code. If your software development team skips this phase, you’re liable to end up spending more time, money and resources than you planned. In fact, many products spend far longer in development when the software doesn’t accomplish your business and user goals, or the deliverable isn’t quite what you needed. You may end up spending too much time in a development phase and miss out on potentially productive months while your product goes back to the drawing board. Solution architecture is key to slowing down so that all future development activities are productive and aligned to your goals. When solution architecture is done right, there’s nothing better you can do to ensure the early success of your product.