It's a funny thing, the more I practice the luckier I get.
Arnold Palmer, legendary American professional golfer
I’m writing this blog for anyone who is interested in growing their IT professional skills, and particularly those who see are interested in making solution architecting a greater part of their role. Many solution architects, like myself, come from a developer background. I want to be very clear that what I am NOT saying is that a solution architects are better than developers – that would be palpably untrue as a quick look at the careers of many of our SCN members alone would show. However, rightly or wrongly, in many workplaces the role of solution architect is more highly valued than that of a developer. Even if that’s not true in your workplace, adding solution architecting to developer skills can be an excellent way to expand your role, and increase your value to current and future employers. Plus with the increasing move into Cloud solutions, many of us believe that there will be greater need of solution architects and far less need of traditional developer/programmers, due to the very nature of how cloud solutions are structured.
Image courtesy of olovedog / FreeDigitalPhotos.net
These days one of my titles is “SAP Global Architect” - perhaps a rather grandiose term for a role which is now roughly 80-90% solution architecting and 10-20% developer. My own journey from developer to solution architect began many years ago when I realized my calling was on the professional development path. Granted it might have had something to do with the 25% salary raise one of my early managers gave me simply for having the right skills at the right time. That sort of hip-pocket boost does give one pause – and while I am never primarily motivated by money, it did give me an early idea of the value in which professional expertise skills were held compared to say managerial skills.
How do you know if being a solution architect would suit you? Essentially it is a job where you are called on to design something where the whole is greater than the sum of its parts. This is not some high level design, it is an intricate and detailed blueprint. If as a child you enjoyed mosaics, jigsaw puzzles, Lego, Mechano, or simulation games like Sim City or Sid Meier's Civilization then solution architecting might appeal to you.
So what does a solution architect do? I find comparing solution architect vs developer to architect vs builder is helpful in understanding the solution architect role. In designing a building an architect considers many aspects (such as the land to be built on, plumbing, electrical connections, government regulations and most importantly the desires and budget of the owners); the builder implements the architect’s design. But an architect does not simply create blueprints and then walk away; often the architect returns to review progress, and to resolve problems and deal with changes caused by real-life issues that could not have been foreseen when the original design was made. In the same way solution architects design how one or more software solutions will fit with their IT environment to meet business requirements; the majority of the developments will be done by developers; while the solution architect is often called on to shepherd the solution to completion.
What's the attraction of being a solution architect for a developer? Often as a developer you are limited to working on just a few small pieces of the overall IT puzzle. As a solution architect you are expected to design all or large parts of that IT puzzle, and have a greater influence over how the whole IT solution comes together. Personally I have found it not only more interesting than traditional follow-the-specification development, but it often brings with it opportunities to connect with senior and executive management as a trusted advisor. Think of solution architecting as less how-do-I-do technology and more how-should-technology-change-our-lives.
Oh and it can pay better – especially these days where development in common technologies – yes even ABAP - may be seen as a commodity skill.
When I first came across the term “solution architect” to a dyed-in-the-wool developer architecting sounded awfully like doing all the hard design work and then not getting the fun of actually implementing or the credit for building working software. It was years later before I finally realized that not only had I been solution architecting most of my career, but it was often the role I preferred and for which I was most highly valued by others, management included.
Like many junior developers my early attitude to career growth was that I just need to learn the next solution, and dig deeper into the solutions I already knew to get ahead. Unfortunately that attitude will only advance a career so far. There’s always another solution, another tool, another product, another release or enhancement pack or support pack; so only looking at solution skills puts you on a hamster wheel of continuous learning but with limited career growth.
Looking back over the decades of my own career, it’s been soft skills that have helped most to move my professional career forward, and I’d suggest that’s a shared conclusion of many in the IT industry. Here are the top 5 soft skills that I have found prepared me best and have advanced me most as a solution architect.
Be a T-skilled person
The first skill relates to how you direct your solution learning. Solution architects generally work across a suite of interrelated solutions. The general idea here for most solutions is to direct your learning to be “Mile wide, inch deep” – i.e. like a salesperson you need to know a little about a lot of solutions. The more solutions you understand the more possibilities you can discuss and recommend as part of your design. Perhaps unlike a salesperson you do need to go deep in some areas where you want to specialize – i.e. be T skilled. Just like an architect might specialize in residential or factory or government buildings. At SAP alone we have several thousands of solutions and still growing. It’s frankly impossible to know every solution at depth and keep up with release changes, so you need to choose carefully where you will specialize as to be effective you may need to stick with those solutions for some time.
How do you choose your deep skill areas? It helps to take your current knowledge and extend it across a suite of related solutions, adjusting the range of solutions you work in as your interests and opportunities change. For myself, I started as DB2 SQL database administrator, added ABAP, added ITS, then Workflow. Workflow gave me the opportunity to move across a range of functional areas so I started to move into B2B and its successor SRM, that moved me into Adobe Forms and from there parts of HCM, then into Project Portfolio Management. With the rise of SAP NetWeaver I decided to move back into more technical solutions and adjusted the suite yet again. I’ve added in turn Business Process Management, Business Rules Management, Process Orchestration, Operational Process Intelligence, BRFplus and Decision Service Management, and I’m currently considering whether to add Process Observer and Power Designer – and complete the Intelligent Business Operations suite. I also have a weather-eye on gamification as a way to the quality and direction of processes involving human/system interactions towards common goals.
That might sound daunting, but actually it’s a bit like learning a lot of languages – the more you learn the easier it gets. You have more patterns and more frames of reference you can use to speed your learning.
You also get better at figuring out what you need to learn now and what you can defer until later. When I first learn a solution I’m looking for key concepts; positioning and tipping points against other solutions; any significant restrictions and limitations; supported enhancement approaches; but most importantly, intent and purpose of the solution. Intent and purpose have proven the best guide to where a particular solution should fit into an overall design. Detailed configuration, monitoring, administration, reports and knowing all the enhancement spots can wait until later.
Practice the Art of Simplification
A major part of the solution architect’s role is not just to create a design but to socialize that design with a range of different audiences – Senior Executive Managers, Project Managers, Subject Matter Experts, Change Managers, other Solution Architects (who are responsible for other parts of the overall design), Developers, Administrators and even the End Users themselves. All of these groups have very different perspectives and information needs. A CIO might need a 90 second overview; the Project Manager a breakdown of resource and skill needs; a subject matter expert might need you to present the overall flow of the business process; a change manager needs to understand how your design compares with the current system, and a developer might need to discuss the standard/custom boundaries in the design. There’s often a lot to explain, re-explain, and reinforce in each meeting, presentation, or discussion.
These conversations get easier and quicker as you get better at simplification. Simplification is not at all the same as “dumbing things down”. Dumbing things down is sloppy and inaccurate; leads to misconceptions, misunderstandings; and ultimately ends up with more time spent in meetings and discussions, i.e. dumbing down costs you time.
Simplification is elegant clarity with exactitude, aimed at a specific audience. Every word counts and has meaning. Every part of a diagram is significant. Nothing is there that should not be. Simplification is the difference between a traditional SAP GUI user interface (complex & complicated) and Fiori (simple).
You know you have reached true simplification when you explain something once and your audience immediately “gets it”. It takes a lot of practice and a lot of trial and error but getting it right is not only time-saving and deeply satisfying, it opens up all sorts of unexpected career opportunities. For instance, being able to simplify has led me to co-author a SAP Press book and to speak at numerous conferences locally and internationally.
Know the difference between Best Practice and Best Fit
Ok – deep breath – I may be committing sacrilege here for many IT people and for many SAP consultants but really folks – Best Fit beats Best Practice every single time.
One of the big dangers in solution architecting is over-engineering the design. This is why you won’t see me advocating the learning of lots of models and methodologies. While models and methodologies can be very helpful in the right hands, when they are used without a proper understanding of the necessary difference between the ideal and the real, they can increase TCD and TCO beyond all reason.
To put it another way… if best practice is a kit house that assumes your house sits on a flat block, and you are building on a slope, best practice might not help you… if best practice shows you how to build the Queen Mary II, and all you need to build is a rowboat, it might not help you.
Too often on SAP projects best practice is used as an argument clincher – we should do it this way because its best practice. But that fundamentally misunderstands the purpose of best practice. Any model or methodology or commonly held approach is only ever there as a guide. It’s a starting point, a good default going-in approach when you don’t yet have a clear picture of the real business requirements. Best practice can also be a plumb-line that can highlight ways that the current design can be improved, but it should never take precedence over best fit.
If the final design doesn’t meet the business needs or overburdens the business with too high TCO, then no-one cares that its best practice. And conversely if the solution actually fits the business well, usually no-one minds that it’s not best practice (although of course it should be clear that you have deviated from best practice to improve the fit, and not just for convenience – there are usually good reasons why it’s considered best).
Get Great at Writing Stuff Down
To put it simply – if you don’t record your design don’t be surprised if it doesn’t get followed. It’s physically impossible to be everywhere you would need to be explaining your design to all the different audiences (as discussed above in Practice the Art of Simplification) that need to understand it during implementation. Especially as at that stage of a project you may be working in a more advisory capacity – not there full time but called in as needed, and even then spending the majority of your time in meetings reviewing progress or resolving issues.
But perhaps you are thinking – “hey this is the 21st century, so why can’t I do a few videos or a few diagrams or explain things over Skype”. Well if you haven’t already, take a look at Did you know 2014 especially the part that points out we are now working with 4 different generations with differing communication preferences. You might notice that 3 of them prefer using words – and as for the 4th group they still need you to use your words, it’s just that they expect other media with it.
What about diagrams, surely “a picture says a thousand words” – well yes that’s still true enough but unfortunately a picture doesn’t necessarily say the same thousand words to all those audiences. So language is essential in helping everyone interpret the diagram correctly.
The good news is that the more concise you can be in your explanations the better. I’ve been on projects where I’ve written 3 page, 10 page, 50 page and 80 page documents explaining the design. The 50 to 80 page versions mostly get ignored or used like a dictionary – people dive straight to the section they need and ignore the rest. The 3-10 page versions have a much higher hit rate.
The bad news is that concise explanations aren’t always easy… and are directly related to your skill at simplification.
As a rough guide, you should be able to describe your design in 3 sentences to a CxO, 3 paragraphs to a project manager, 3 pages to a subject matter expert or change manager, and I’d aim for no more than 15-20 pages even for detailed developers – and that includes screenshots. Similarly most diagrams work best when they are limited to 3-5 major blocks, slides work best when they are limited to 3-5 points per slide, videos when they are limited to 3-10 minutes, and so on for other types of media.
To improve your skills here watch how your target audience responds and keep asking yourself:
- Did I get my message across?
- What did I have to explain further… and can I rewrite that part more clearly?
- Did I include everything I needed to … and nothing I didn’t?
Play Well with Others
I’ll be the first to confess that personally this has been one of the hardest areas for me… and actually one of the reasons why it’s good for me to not spend too much time developing. As a developer I tend to zone in – come and speak to me when I’m developing and I may not hear you, if I answer I may forget to look at you, and it’s entirely likely that I’ll stop in mid-sentence and never even notice when you left. A sad case! :wink:
Solution architecting is not a solo role – you can’t just work out a design, hand it over and walk away. The major part of the job involves working with others – listening to needs and concerns, discussing pros and cons of options, cross checking your design with others where it moves outside of your deep skill areas, cross checking how your design will work in concert with other parts of the overall solution, and communicating your design to many different audiences.
So if working effectively with other people is not your strength, what can you do to improve?
My first tip would be to go out of your way to “give credit where credit is due”. There is nothing more motivating or that builds goodwill, loyalty, and cooperation faster than being seen as someone who is quick to share the glory. Always try to be specific in your compliments and critically you must be sincere. I sometimes find junior consultants are reluctant to share the credit because they think credit is finite, and by giving it to someone else they are losing part of it for themselves. Actually the reverse is true – by giving credit to others, it adds to your credit with managers who tend to see you as a team player who is growing your own skills in motivating those around you. And I’ve yet to meet a manager who doesn’t want to hear how good his/her people are.
At this point I’d like to take my own advice and give thanks to graham.robinson Graham Robinson for encouraging me to speak on this topic, and marilyn.pratt Marilyn Pratt and susan.keohan Sue Keohan whose frequent bravery in broaching non-product discussions in SCN have inspired me to step out of my own comfort zones.
Conversely, where you can, avoid blaming others. I see at least two reasons for this. Not only is it bad for your relations with others, managers included, but it doesn’t solve the problem. The best approach is to stay solution focussed - focus on the facts and discuss how best to fix the problem. Plus somewhere, sometime you will make a mistake yourself. You want people to have a reason to forgive you the occasional error.
The second tip is to “Seek first to understand, then to be understood”. Listening deeply to others can save you many a misstep and minimize rework. It also gives you a heads-up on concerns and risks so you can address them early before they impact the solution. And don’t just listen to the people you think are important. Nearly always when I have discounted some person or some role as not important, I’ve later learned it was because I didn’t yet understand what value they brought or what influence they wielded.
My final tip is a particularly painful one for me… “Remember you never know what people are going through”. A long time ago now I worked with someone who did a regular task I relied on. Most of the time she did it satisfactorily and without fuss. Occasionally something happened and she couldn’t do it on the day planned and we negotiated alternatives. But all of sudden she started missing lots of dates with no explanation and often no contact. Even when I could get hold of her I would just be given a list of apologies and lame excuses. Finally my frustration built until I couldn’t take it anymore. When I at last managed to get her on the phone I launched straight into my “Look, this is not acceptable and it cannot continue” speech. After a moment’s silence she broke down and admitted that her son had recently died in a car crash and that was why she wasn’t able to keep up with her work. There was absolutely no way I could have known that at the time, but I was instantly flooded with the remorse of having put someone in extreme distress under even more pressure. It was a very hard way to finally learn the lesson that you never know what people are going through, what they are thinking or what pressures they have to bear.
So please do your best to always assume that people are coming from the best of motives – even if you think they are misguided or mistaken. Give people every opportunity to surprise and delight you.
And in the hopefully rare situation where you just can’t seem to get on with someone – look for someone who works with them better than you and get their advice on how to improve your relationship.
Some Final Thoughts
If you take nothing else away from this blog take this… as a Solution Architect you see a lot of mistakes that other people have made. The oversights that meant the business value was reduced to almost nothing; the legacy system that broke when one more relationship was introduced; the over or under-engineering that drove the business to damaging maverick workarounds. Don’t laugh, don’t criticize, don’t get holier than thou. Just be observant, be grateful for the heads-up, and if at all possible, learn from the mistakes of others, because it’s so much less painful than learning from your own.
Whether or not you choose to move into solution architecting, have a wonderful career! YOLO
- SAP Managed Tags:
98 Comments
