customer – nettech Blog

This is the first newsletter article proper. I will try to keep this brief, but If there is sufficient interest, I could spend some more time/words on the topic. Our topic today, is an important question, and one that architects will face from time to time. Here is a recent article that I wrote on this subject. Do read it if you can, as it covers details that I will not rehash here.

But in answer to the question, my response has always been that the drivers for IT architecture are, mindset and environmental imperatives. The first is proactive, while the second is reactive. As you can expect, I recommend the former (mindset) over the latter, because it instils architecture from the get-go. Such organisations seek excellence, are in for the long haul, or seek to rapidly gain market-share in an existing market. Because of their ambitions, such businesses will prioritise strategy, even in MVPs.

Almost always, this strategic view percolates from champions in the highest levels of the business (c-suites typically), to the IT area. Because the influence is coming from the highest levels, the effects are pervasive and resilient, resulting in an IT culture that is closely aligned with the business aspirations. In this kind of enterprise, what one may label as MVP, is actually an optimal release for the time, constraints and environment of the business. Because it is under-girded by sound business and architectural thinking. This is not true for all organisations, particularly those that employ architecture reactively.

Some other organisations introduce architecture, as a response/reaction to changes in their environment. The stimuli that I identify are, scale, complexity, and risk. Some experts also mention cost, but I think cost is a direct consequence of the three primary imperatives. One is unlikely to see costs going south while any of these are going north. When things get more complex, scope multiplies, or risks (regulatory, financial, legal, others) emerge, most organisations will wake up to the need to engage staff outside of day-to-day operations. Unfortunately, this is often problematic, because governance becomes a big issue.

Folks who previously made their own decisions, now have to discuss it, and perhaps, submit it for oversight by architects. This can create tension, resistance and in some cases conflict, with vassals overseeing strongholds of opposition; overt or covert. Secondly, because architecture has not evolved as a culture, when the immediate need has been addressed, it is easy for those organisations to regress on the discipline of architecture. In the short term, it saves on the stress and tension that the introduction of architecture creates. In the long term, of course, the problems will re-emerge, having evolved into more complex and entrenched threats.

One may ask: what to do, if the architecture function is not yet present in our organisation? My advice is to identify a sponsor that you can communicate with directly. Preferably someone higher up (quite😀) in the organisational hierarchy, and preferably on the business side. Get to know the vision, targets and roadmap of the organisation; from a business perspective. Do your diligence to identify any of the motivations that I mentioned above for mindset-driven IT architecture. Now explain, in simple language, how taking a strategic view that aligns technology change with business change, at every step of the roadmap, will be salutary to success. Continue to state how this can be facilitated by the introduction of architecture.

As one who has led a startup, I can tell you first-hand that most business leaders see tech as an enabler only. Therefore, you must arm yourself with numbers and other quantitative details. Imagine that my goal as CEO is to make 170x in value within a given time, and I have investors expecting 38x of that back in the same time. Your suggestions must show how we can either overshoot the target now, or miss it “mildly”, but secure significant and increasing gains in the near future. If I don’t get that empathy, I am unlikely to consider what you are offering. That is the red, proactive pill.

If that fails, because no one gets the picture, try the blue (reactive) pill as a last resort. Identify existing or potential change imperatives, as I mentioned earlier, and use that to argue for advance preparation. Such pre-emptive action requires a stepping above the business-as-usual (BAU), looking to the horizon and putting plans in place to harness everything in the enterprise, in synergy, to manage anticipated changes. Once again, you will need to demonstrate how the introduction of a strategic (architecture) rather than tactical approach, creates value for the organisation. If you succeed with either pill, be prepared to lead the change. Trust me, it will be challenging, but extremely rewarding, in the short and long terms.

Before I go any further, I need to point out that the focus is not on technical or application architecture, which typically approach solutions from a technology perspective. Rather, it will be on solution and integration architecture. The two roles are very similar, and both work closely with the business, various architecture teams, and the core technical/delivery teams. Henceforth, I will use solution architect or solution architecture as generic terms, for both. I found this video by Marco Lenzo, most enlightening, in illustrating this bridging function provided by solution architects. Marco has several short videos on key technologies, which I find to be handy time-savers.

Solution architecture (SA) has some overlap with enterprise architecture (EA). However, as organisations scale up, the distinction of function is cleaner and the overlap decreases. In my opinion EA, sets the stage for architectural involvement within an organisation (enterprise), whereas SA works with the business and technical teams to deliver changes, within the constraints that EA has previously agreed, and continually evolves, with the business. As you can see from the diagram above, SA has a vital role in keeping the technical/delivery functions aligned with the business.

I initially planned for 500-word articles, but having reviewed the number of topics, and the possibility that more may be introduced, I am doubling that number, to keep the lifetime of the newsletter manageable. Please let me have your comments and feedback for this week. I will respond to any comments, and God willing (GW), continue the discourse in two weeks’ time.

Adios for now. 🙏🏿👍🏿

I still remember the early days when I first started out in tech. All answers were apparent and hardly was the ink dry on the request, and I was already delivering pieces of the solution. It was a kind of “Agile”; quick, and invariably, MVP. The success factors for me were essentially the functional aspects. Value was perceived from a tech perspective.

These days, so many answers are qualified, nuanced, and accompanied by caveats. Almost nothing is clear and certain. I have discovered that value is the prerogative of the customer, and he/she expresses it in subjective terms. However, the customer is often not the only important stakeholder, and one has to address all the concerns of key stakeholders to deliver a successful service. The matrix of concerns, constraints, opportunities, etc. is a hazy mesh that takes patience, knowledge, imagination and tact to navigate.

Oh, for the halcyon rookie days, of operating below the radar of key stakeholders, architectural governance, and budget holders! For certainty and technical purity, for the stream of tactical solutions, and the buzz/hit of seeing “it” work! I still remember one moment of amazement, when a visiting consultant pointed out to me that the collection of MVPs I had laboured over for the last two years was actually a mini ERP. Those were some memorable years, in London, Edinburgh and Southampton. It was a lot of adrenalin, noise, banter, late nights, early mornings, intense work and much fun.

I now work mainly in the integration & solution architect scopes, synthesising services from business, architectural and technical inputs. Constantly scanning for opportunities to drive innovation, efficiency and competitiveness, while also reducing complexity, cost and TTM. In addition to the requisite technical and business knowledge, my role involves tact++, listening++, politics, psychology, emotional intelligence, and social strategy. It is not a straight line, there are no easy answers, there is little fizz, and you do not enjoy a fiat in any context.

Neither do I ever deliver anything alone. I always work with others, no one works for me, but rather with me: hierarchies can oft-times be an impediment. I depend on others to implement, provide or revise funding, change scope, grant a dispensation, review a requirement, move a date, or compromise in one way or another, to advance the delivery of solutions, and value to our customers. Customers are the ones that pay for our activity, and it is key that we understand their perception of value in order to consistently deliver services that they are willing to pay for.

The customer is king! But KYC cannot always be gleaned from the organogram or reading through the requirements. What may be right for one customer with a tight and close market window might be an unacceptable hack for another. The solution that was gladly embraced by customer-A in Q3 of this financial year, when revenue was trending up, could be flatly rejected in Q1 when corrections reveal shortfalls. Over time, one does gain knowledge and one does build trust, and all this widens the scope of influence. However, with such a wide matrix of interdependencies, the role is always challenging and unpredictable.

All said and done, it is still very interesting and rewarding work. It is a journey of discovery, of self and others; of building relationships and trust; of learning from failures and successes; of growing in patience and perception, and of seeing the sometimes hard-to-perceive positive impact of changes one helped to nurture. And “Yes, it is a good life, ‘Henry’“.

Tag: customer

The Fog of Experience