Part of realising why the frustrations that are actually holding you back, stopping you, is understanding that being a Solution Architect is not about achieving the goal, getting to some sort of pinnacle. It is not about a career path that ends by becoming the boss. Being a Solution Architect is about the journey. It’s about how you get there, not the destination.
“Yes, yes …” Project Managers will say “… but it’s the destination we are being measured and judged on; and in some cases whether or not a lawsuit will happen”. While this is true, it is not the primary motivation of being a Solution Architect. It is about the journey of being able to provide specific solutions, not about reaching some sort of career pinnacle. It’s the journey that matters the most.
No matter where somebody is at in their journey of becoming an SAP BW Solution Architect, there’s always more to learn. There is a little bit over here on this topic, there is a little bit over there on that topic, there is always more to learn. That learning is both wide and deep. It is learning across the breadth of different topics. It is learning deep into the specifics of each of these different topics. You will find that the best way to practice your art as a Solution Architect is to learn piece by piece. To build on what you have, from where you are.
To do the journey of building solutions to meet requirements, start small. Pick a requirement that’s pretty close to something that you already know. Now add to it a twist of something that you don’t know. Use the four aspects of a piece to discover what you do not know. The key thing is to understand that the twist is a small step. It helps you focus and build on what you already know while essentially digging deeper in that area of knowledge.
The extra goal should be based on a practical requirement. For example, if you’ve got a lot of reporting experience with queries, perhaps look down into optimizing the MultiProvider. Perhaps look out into better understanding broadcasting which then leads to automation of broadcasting. Perhaps look at the process of implementing the queries themselves and build up a Naming Standard that caters for all the different types of solutions that you know.
By going through the process of creating a naming standard you will be forced to group, classify and label the features of reporting that you currently understand. This in turn helps you work out areas that you could learn more about.
“the key is to always take small steps
towards practical solutions”
Now this is where the project experience versus your own exercise of learning diverges. Practical solutions, as defined within a project for real project goals, will quite often encompass a whole range of topics. Most of the time there are quite a few small steps that are skipped in the knowledge transfer and the benefit of learning each small step is missed. This is where you need to take note during the project to identify practical exercises for learning later.
When you are not involved in the project, you are able to narrow down those requirements to bite-size activities that are practical and achievable. Practice the small steps. Having access to a live BW system to be able to experiment and build on the knowledge that you already have, is definitely a great way to practice the art of being a Solution Architect.
- Do I have new small steps to practice? Add them to my library.
- Have I gained a new insight? Document it in my library.