This week here is sending you some thoughts on whether an architect needs to be a specialist or a generalist as one progress along the career path.
Specialists increase the depth of small ideas. Generalists connect small ideas into bigger ideas. We need them both to advance as a species. – Kenneth @leadershipABC
We need to know that an architect is support to have a lot of skills under his belt . An with the onslaught of technology changes every passing day. It is like changing the tires when the vehicle itself is going through an overall. An architect is supposed to be good at one or more skills and tech stacks . He needs to have full stack experience and should have handled at two end to end project in his lifetime meaning he saw the product or the solution go from concept to cash . This means that he was involved in every aspect of the delivery from start to finish and involved in all areas of the design , development and test and finally solutioning. All of this is still ok but what about the changing nature of the tech landscape and how does one keep pace with changing parts of the puzzle. The ancient greek definition of Architect meant that he was a man of words , arts , literature , interested in music and a tinkerer of sorts. All that we can think of someone who would fit that profile would a Da Vinci. Given the work pressures we all know how difficult it is to be someone of that level. It takes effort and years of practice to reach or play at that level.
But what is expected of an architect as he progress in his career path is that he should have broad experience in many areas of work and deep dive experience in one or two of them . This does not need us to be Da Vinci and looks like an within reach target. What are the skills that you felt inadequate to turn into a Senior IT professional ?
Here is an interesting news article about how Airbnb solved their problem by redefining their scope.They were stuck as they were looking at how to scale things first before solving other issues. You never know where your potential solution can come from unless you have looked at the problem from all its dimensions.
Thinking outside of the box is a key skill for an architect . It involves being exposed to new ways to think about existing issues. Most often people are so neck deep into finding solutions to problems that they forget to explore other options of how to make things better for people , customers. Most often the architects are disconnected from end user realities and design solutions considering only the technical landscape. This creates a one pointed view of looking at and arriving solutions. Most often the best solutions to customer facing solutions come from the coffee boy , the security guard or the customer who is using the system on a day in day out basis. Have we cared to check what are all the possible solutions which can enhance customer experience before going ahead with the solutions that are merely technology oriented and miss the business outcome or even the end user experience. Design thinking is a skill for an architect or a solution designer and is a skill that has many people looking forward to which is about getting a problem all out captured in all its dimensions and looking also for problems from all quarters. It does not designate anyone with a Chief of Innovation mantle to innovate on the problem , everyone is a potential out of box thinker. Every input when processed through the design funnel could solve a teething problem with a solution that everyone in WOW !!.
Here is leaving you with a design thinking approach to solve a product rollout issue using principles of design thinking
Most often getting business architecture requirements right is a challenge and it means there are two types of people who need to converge at a common point to where they could make sense it each other. The business people are concerned with the business side of things and look at the picture from an angle which could be quite different from the IT folks. For example the IT team is worried about building requirements that are more better versions of working software or rather refinements in releases but the business is concerned about what business value will this piece add to the overall product strategy or solution point of view. Many a times it so happens that there is no clear articulation of business value and organizations spend time and effort in producing waste or MUDA ( Toyota / Six Sigma ) prefers to call it. This can happen because in the name of taking up an initiative a wrong requirement was envisaged as having to be completed. Many a times the requirements although is an art and science by itself and needs to be done with the right focus as all the downstream actions based on this can create mis alignment in the vision and mission of an enterprise. So is there is definitive prescription to doing this , how is this similar to user stories or epics that agile teams talk about . User stories are not enough to detail all possible requirements more so when they depict the end to end system goals where aligning business and IT is paramount. This being the case there needs to be a structure to capture all the actors and details that goes into getting a business scenario right.
Recently been to an IT company where the issue was product owners hand over requirements over email or chat sessions or simply over a phone call. It was said that requirements not getting correctly scoped was the single most productivity loss and created enormous amount of wasteful downstream activities. What has been your experience here ?
RFP in the age of pay as you use / On demand Software ?
As you could see above the Ruler of Dubai has floated an open tender on his linkedin page calling for a solution to traffic congestion . As part of an IT team we are most often tasked with the task of how to prepare an RFP how to respond it and what does it take to ensuring that you are putting your needs across to that prospective vendor or customer out there to whom it needs to go out to.
In the age of cloud and COTS ( Commercial Off the Shelf ) solutions or software there are customers who pick and choose which software solution to buy based on similar success stories and circumvent the need for a formal RFP. They would most often go with a pay as you use model where with a subscription model you have the software solution at your disposal . But this apart the RFP is not dead yet and there are many formal RFP which get circulated like the one above where the need for pick and choose the right solution from the customer makes sense.
Some of the qualities that you would need while responding to an RFP ?
Understand the customer problem as it stands.
Articulate your value proposition to the customer so that you differentiate from the competition ?
Just because there is a solution it would straight way fit the customer’s context.
How are you going to take of customization needs from a solution fitment point of view.
What is the type of language / taxonomy that you would use when you interact with the business folks . Is it same as the IT side of things ?
Do you understand the jargon and the nitty gritties referred to in the RFP ?
Are you technically competent to see the solution in its entirety or are you from the business side of things where you are looking at the solution from a viability perspective from a purely business angle.
Do you understand responding to an RFP has a direct relevance to the development or downstream chain of solutions being offered. Sales promise the world and the reality is delivered by the downstream people.
Ability to think in terms of abstraction is a key asset here . How would you hide the implementation details and look at a reference architecture to solve these.
How will a reference architecture help you solve these issues , as these shall help creating repeated success in the company and also help iron out issues while solutioning with the client. What other skills do you find to be lacking here ?
So you want to transition from what you are doing to a role that helps you see customer solutions. There are many solutions for a given problem which one suits the solution the best given the customer context.Most often the tendency is to straight away jump to a problem and start solving it rather than step back and look at the big picture.
So what does the good solution architects have in common.
They are good at communication, good technical / business background, have a breadth of experience across a spectrum of an area of the industry pie, have an appetite for plugging risk , they can see the high level picture as well go down to the nuts and bolts when needed, they are visionaries , stand for the proposed solution by backing it with a proper rationale and more importantly life long learners.
Here is leaving you with an article that has these thoughts on how to become a solution architect or be better at it if you are already one.
What make a good solution architect ?
What has been your experience that you find is missing among the architect community and what skills are needed to help them look good in front of their peers , stakeholders and customers ?.