Architecture in times of rapid technology evolution - Part II

In the first part of this article, the author argued, rather passionately, for the need of "good old academic discipline and rigour" while engaging in Enterprise Architecture spanning People, Process, and Technology. In this part, we shall look at the role that Enterprise Architects can play in the complete the Product Lifecycle from formulating the business hypotheses to defining the product roadmap to creating a backlog of product features to creating the architecture runway to delivering blueprints and coding standards to establishing a suitable BizDevOps process to ensuring quality of each release to helping adopt the appropriate Site Reliability Engineering (SRE) practices to enabling the capture of appropriate Key Performance Indicators (KPIs) to test the hypotheses to finally deciding when to retire the product and start the cycle anew.

We shall ignore new product ventures that would adopt a Lean approach to product development and instead focus on medium ($500M to $1B) to large (>$1B) enterprises that develop complex products for internal use or for sale to other enterprises or direct to millions if not billions of customer using a multi-vendor engagement model and requiring to comply with international and regional governance standards and laws. However, the concepts described in this article equally apply to smaller companies especially if they have plans to become next unicorn!

Subsequently, the article will not attempt provide an in-depth analysis of the role of and contributions by Enterprise Architects to each step of the lifecycle described above. Instead, the intention is to provide some guiding principles as to how modern tools combined with GenerativeAI assistants can help Enterprise Architects master the legendary "T"-shaped skills to be included in each column of the Responsibility Assignment matrix (Responsible - Accountable - Consulted - Informed). Before proceeding, the author does wish to acknowledge that true blue T-shaped Enterprise Architects are a rare, almost endangered, species that might be significantly expensive to engage and extremely slippery to retain for the average lifetime of a product, typically 5 years but often much longer. Consequently, an enterprise might choose to engage the services of a number of different types of Architects to better manage costs and knowledge.

The following are the typical types of Architecture skills to be found in the talent market today:

• Domain Architects understand the business context and operational value streams and can help in identifying new revenue opportunity as well as apply methods such as Theory of Constraints to optimise existing value streams.
• Enterprise Architects define high-level strategies and roadmaps for an organisation's IT systems.
• Systems Architects focus on designing and implementing specific systems, such as databases or networks.
• Solutions Architects bridge the gap between business needs and technical solutions.
• Application Architects specialize in designing and developing software applications.
• Software Architects are responsible for the overall design and structure of software systems.
• DevSecOps Architects ensure security is integrated throughout the development and operations lifecycle.
• SRE Architects focus on designing and implementing reliable and scalable systems using Site Reliability Engineering principles.

The author would like to insist that Enterprise Architects must develop a deep understanding of the business as well as the limitations of the existing IT systems and business unit organisation to negate the need for Domain and Systems Architects. At the same time, key business stakeholders in medium and large enterprises must develop the necessary technology skills to effectively communicate with the Enterprise Architects. The role of Business should not be simply to be the budget holders.

With the context established above, let us now look at how Enterprise Architects can up-skill themselves to stay relevant across the entire Product Lifecycle.

The easiest part is the skill to promote a new operating model for ensuring Business Agility. The Scaled Agile Framework (SAFe) is an excellent starting point and it is highly recommended that an Enterprise Architect acquire the SaFE Practice Consultant (SPC) certification. Of course, helping and enterprise to adopt SAFe and managing the change is outside of the scope of an Enterprise Architect and they should simply be "Involved" in the journey.

For the People aspect of Enterprise Architecture, it is important to understand and/or define the competencies and skill sets that are most applicable to the enterprise, possibly specific to each business unit. For example, for a large life sciences company such GSK, Novartis, etc. the nature of the operating value streams and the products that are involved vary significantly across R&D, Manufacturing and Supply Chain, Global Pharma Sales and Operations, and possibly Consumer Goods. Irrespective of the differences, certain competencies and skill sets pertinent to product development are common across the various business units and if, due to historical reasons, they are different, it behooves the Enterprise Architect to try and rationalise them as it allows for more effective use of software engineering capacity across the enterprise and also drive efficiencies in the vendor management processes.

Of course, as per the theme of this article series, competencies and skills are rapidly evolving and hence the Enterprise Architect must have a keen eye to identify upcoming trends in technology stacks and programming languages. For example, while React.js has been the most popular frontend development library combined with the Next.js framework, Astro and Svelte are challenging the status quo. For backend development it should not surprise anyone reading this article that Java 11 and .Net Core 6 continues to be popular choices in spite of Java 22 and .Net Core 9 being available or close to being released. On the cloud native PaaS front every day brings some new offering from the hyperscalars that renders some older offerings obsolete. Thus, Enterprise Architects must be competency leaders and work with internal or external training organisations to ensure that appropriate skills are available within the enterprise or easy to procure from the market. Also, avoiding hyperscalar lock-in must be a key agenda item for quarterly or annual architecture review and should be tracked as Technical Debt.

One core tenet that the author abides by is that certifications are not a measure of skills in spite of the ease of tracking that they offer to large organisations. Simply because 75% of your employees have a particular certification it does not mean that they are able to apply the associated skills to solving real world problems. A better way is to ensure that every employee can devote up to 20% of their working hours to up-skilling and then demonstrate those skills by participating in regularly organised hackathons and other coding events.

Finally, for the Technology facet, an Enterprise Architect must first and foremost be fluent with the Unified Modelling Language even if the Rational Unified Process is a distant and fond memory. The knowledge of Enterprise Architecture methodologies such as the TOGAF framework or the C4 model is highly desirable but not mandatory. Instead of a design first approach, engaging in collaborative and evolving architecture through the use of free tools such as PlantUML and Architecture Design Records (ADRs) is highly encouraged. This allows for Architecture as Code (AaC) practices to be adopted along with a strong governance model to manage Technical Debt.

Similarly the Enterprise Architect must be an integral member of the User Experience Design team and be comfortable with using tools such as Figma and Adobe XD.

In this process the use of GenerativeAI for transforming Customer Journeys into Features and PlantUML JSON code to Technical Enablers should be explored. In the author's experience none of the existing GenerativeAI tools are capable to achieving this transformation but that just might be a matter of training a custom LLM with the appropriate dataset that consists of established Enterprise Architecture guidelines.

The final and the most important Technology skill for any Enterprise Architect is the ability to write code across the entire stack. In the author's experience, nothing motivates developers, junior and senior alike, to go above and beyond when a skilled Enterprise Architect works shoulder to shoulder with them and helps them chart a career path to the "Ivory Tower"! Of course, the Enterprise Architect also needs help in this endeavour and once again the plethora of extensions available for modern Integrated Development Environments (IDEs) such as Visual Studio Code and IntelliJ are invaluable to prevent the Architect from being unduly dependent on the senior developers. Additionally, the various GenAI coding assistants are available to lend a helping hand.

Alas, all is not well in the Land of Oz described above!

Enterprise Architects often tend to become the "Wizard" without any true magic powers. Developers are less than forgiving when the wise old Architect offers a word of caution against using the shiny new JavaScript framework that has just been released, often the one that the lead developer themselves may have contributed code to. And finally, the bean counters refuse to allow any breathing space for acquisition of new skills by claiming that learning is a life long activity to be undertaken for self gratification rather than for the good of the enterprise and hence not at the expense of sacrificing billable hours or deadlines.

The GenAI assistants have also failed to deliver on the hype as the author discovered when he tried to use GitHub CoPilot for the rather elementary task of extracting a reusable UI component library from the sample Next.js + React.js example available on GitHub at https://github.com/vercel/next-learn/tree/main/dashboard/final-example. Using the @workspace directive for GitHub Copilot resulted in errors being thrown by the extension itself in VS Code as per the screenshot below:

The author humbly submits that he maybe challenged due to personal prejudices against GenAI apparent in the first part of this article and could have failed to use Github Copilot correctly; but then that proves the author's claim that GenAI simply cannot handle the complexity of large codebases to help managed let alone reduce Technical Debt. In the example described above, the author was able to complete his objective by using the trusted method of using the Google Search Engine along with StackOverflow and the developers one true friend "Command-C + Command-V" (or for the unfortunate developers who have to work in Windows - Ctrl-C + Ctrl-V).

In conclusion, Architecture is a life long journey that requires constant honing of niche skills along with a keen study of history and mathematics whilst indulging in nostalgia!

Au revoir et bon chance!

PS: Lest you forget, architecting Quantum Computing Systems is likely to be a whole another universe of woe! Stay tuned!