Why Architecture?

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.

????????

Intro | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Conclusion