A great solution architect appreciates a range of possible solutions with enough understanding of ‘Why’ to identify the benefits and limitations of each ‘How’. This leads to the defining of a best practice solution, beyond band-aid solutions.
What does it actually mean to be a solution architect? By doing the time and learning the pieces of the puzzle, how they interact, you end up with an understanding that allows you to put together solutions that are not off-the-shelf. This involves a custom solution where the business requirements are not satisfied by pre-built configurations.
A good example of this is the SAP Business Content within SAP Netweaver Business Warehouse (SAP BW) or the applications within the SAP Enterprise Central Component (SAP ECC) system.
Here are a few questions you should be able to answer as a solution architect:
- What are the primary differences between the available solutions?
- How does each available solution achieve the result?
- What are the benefits and limitations of each available solution?
- How well aligned is each solution to the business requirements?
- How much customisation is needed for each available solution?
- What is the Total Cost of Ownership (TCO) for that customisation?
- Do you have time to give an available solution the attention it needs?
There are quite a few standard business processes that are available within the SAP ECC applications. Given that a business process can be implemented via several different methods, there is usually a great need for functional and configuration experts. Some solutions involve minor changes while others almost ‘re-invent the wheel’. There are also varying degrees of robustness, validation, cross-referencing, etc; within the flexibility of the business process implemented within ECC.
The effort required to implement a solution can be guided by the approach to the solution:
- How do the business requirements want to run the business?
- Are you only allowed to do it one of two ways?
- Here are all options, pick and choose as you go?
- What are the implications of mandatory fields?
- Additional fields from other application components?
A SAP BW solution architect is someone who knows how the pieces of the puzzle work internally. How those pieces interact with other pieces externally and then has a feel, almost a sense of creativity, in rearranging those pieces so that they achieve the result the business requirements has identified.
Deeper learning into different solutions eventually gives you a feel for the lifetime expectancy of a solutions. Most solutions will work and they will meet the requirements, as stated. However, they will have quite a few limitations just outside the boundaries of the business requirements.
These solutions can be quite inflexible and when the business changes their mind and the business process needs to focus on a slightly different requirement, quite often there will be a lot of problems where the solution will be unable to move to its new goal without actually requiring a lot of effort to get there. As a Solution Architect, one of the main goals is to always keep in mind the life expectancy of the solution.
“most minor reporting enhancements should
only involve MultiProvider and query changes”
Whilst there is no immediate praise or even acknowledgment that a limitation is not in the solution, the acknowledgement will come in later when the business process actually needs to change and the current solution is able to be enhanced, easily. This is one difference between a BW developer and a BW solution architect.
All of this is based on the solid foundation of knowing what the pieces are and how they interact with each other.
Start with an area of interest, something that might not get you totally excited but you’re at least curious. Think about where you seem to have a knack for providing good, solid solutions in a subject area or technology. Build on that. Dig deep and learn more. Get to know it thoroughly and become the Subject Matter Expert (SME) who can provide a custom solution that leverages off-the-shelf pieces and lasts well beyond go-live.
- Is your library of solutions growing as you learn?
- Are you actively refining your library to identify best practices?