December 17, 2014

How to create a great Solution Definition

Jonas Bergqvist

Senior Solution Architect, Tieto

Time passes fast and in this post I will write about how I work to quickly produce solution definitions for my customers and colleagues. In return I would like to know how you do it.

It’s been a week since I wrote my first post and introduced myself, during this week I have worked with two primary challenges. First to finish a solution description for a customer who needs a relatively complex functionality in place already by January (and where the project did an early start, already Monday last week). The second task is to finish a product strategy work where we have given ourselves a short deadline in order to be able to start next year in the best way possible.

This post will focus on the first challenge: how do you produce solution definitions relatively quickly which have enough detail and quality to communicate to both non-techie clients, the business, IT and third parties?

From experience I have learned that it is easy to get stuck in theory and to put too much focus on either the business or technological perspective. Who of us haven't discussed an intricate business process detail or a deployment diagram for far too long, when it should be done further down the road or by completely different persons than those present?

For the time being I rely on this principal structure:

  • Business goal (business case) expressed very concise and measurable. Not more than half a page almost no matter the size of the scope.
  • A visual solution description accessible by anyone. Generally a simplification of the Business and Application Architecture models. This is where it can get creative and different every time.
  • A process map where the main process areas are modeled as a business architecture in a larger Collaboration diagram. Our process automation solutions naturally encompass a lot of systems and actors which makes the Collaboration diagram very appropriate and it carries a lot of aspects of the solution in its expression.
  • User Stories expressed as concise requirement and process descriptions. These are the basis for development estimates, sprint planning and testing.
  • A time plan that clearly shows when a solution could be in production given that the start requirements are met.

I feel that this structure has worked great on smaller to medium sized implementation projects that I have worked with where we base the solution on our own platform ad have a high degree of business knowledge and use a proactive approach to solution design (i.e. we suggest and recommend more than we ask questions).

Depending on the actual solution domain we complement the structure above with detailed descriptions of e.g. integrations in the form of sequence diagrams if there is enough complexity in them and they will add a layer of information more than just referring to the API documentation

What are your favorite tools when defining a solution architecture and what does your structure look like?

What methods and tools do you use that I should try?

Stay up-to-date

Get all the latest blogs sent you now!