WHY it is difficult to maintain an Optimized Technology Architecture?

By Lizette Robbertze

The businesses supported by our technology architectures change constantly – if not growing, they are declining. While we are hoping for growth, the fact is that its current state stipulates the technology architecture requirements. While we can do our best to anticipate these requirements and apply our best change efforts, we often end up on the back foot.

In my opinion, there are two significant perspectives to be considered by Enterprise Architects responsible for the business fit of the technology architecture within an organization:

1. The sources and volumes of change requests, and
2. A few caveats to technology changes.

1.   The sources and volumes of change requests

Figure 1: The sources of technology change requests in an organization

Figure 1 above identifies the major interdependent components of a business.

• The business model defines the product/service portfolios made available to different market segments via one or more distribution channels. It also includes the pricing and marketing strategies required to ensure growth and profitability.
• The financial model will include strategies to handle cash inflows and outflows while utilizing calculations to indicate the organization’s solvency, profitability, and efficiencies.
• The operating model structures the organization’s activities by stipulating functional distributions, reporting hierarchies, processes with governing policies and operating standards, and skills and experience requirements for every level.
• There are usually multiple resourcing models to explain the use of people, technology, and raw materials by operations. The technology resourcing model is described at the hand of a technology architecture with structure and stature characteristics. The structure defines the implementation patterns used for the different technology architecture component types, shown in figure 2 below, while the stature describes its business and technology fit.

Figure 2: The component types in a technology architecture

It is important to note that each model has either a direct or indirect impact on the others, for example:

• The business model needs to ensure a profitable income for the organization via the efficient delivery of the operating model; and product/service functions and features provided by the resourcing model.
• The resource model(s) requires CAPEX and OPEX outflows directly related to the business and operating model requirements. Therefore, as seen in figure 1, all changes in the organization end up as change requirements for the resource models.

Specifically, the technology department will receive new requirements from changes to the business model – such as price list changes, integration with new business partners, new/modified channels, and many more. It can also receive new requirements from the operating model, driven either by:

• Changes in the business model to adapt to new customer requirements or to compete with competitors – such as the establishment of new sales regions or product/services lines, changes to the customer interaction channels, Etc.; or
• Changes to improve operational efficiencies – workflow automation, business intelligence needs, and additional functional capabilities and features – to name but a few.

While one may argue that an efficient portfolio management function can manage all such change requests within the organization, some caveats need consideration.

2.   The SIX Technology Change Caveats

• Technology architecture planning is a strategic exercise, considering the implementation and integration patterns for all the technology component types, as shown in figure 2. It needs to align with the business strategy – hoping that this is defined well; and needs to remediate internally identified weaknesses, such as capacity and performance requirements. Such a strategic planning exercise would culminate in defining tactical goals and decision-making principles – to ensure focus during change delivery.
  • Ad-hoc and uncoordinated change requests from the business make compliance with the already defined tactical change goals almost impossible. Just like continuous ad-hoc changes to the layout of a building may result in an aesthetically unpleasing structure, frequent and ad-hoc technology changes may create an unsupportable and complex technology environment.
  • To exacerbate the situation, it often happens that requirements from business are not well defined or approved before being handed over to the technology practitioners, only to be changed just before or just after delivery. This is often experienced when the new solution’s risks and control requirements are not considered during design time.
  • It can also be that the organization doesn’t have access to enterprise architects to adequately translate the business’ change intent and requirements into short- and long-term technical requirements.

• Any change journey needs to clearly understand its points of origin, such as a view of all system functions and features used to support operations – with visibility into its strengths and weaknesses.
  • It is an almost impossible task in a fast-changing and complex environment with legacy systems and duplicate operational silos, each with unique implementation nuances. The resulting change planning then happens based on a limited understanding of the environment, resulting in increased complexity.
  • It is also not possible without using an architecture modelling tool in which such views can be created and stored for future reference. (As an example, the Abacus Enterprise Architecture platform from Avolution provides exceptional assistance in the modelling and comparing as-is and to-be architectures. Please refer to: https://www.avolutionsoftware.com/feature-comparison-enterprise-architecture-tool/)

• Not all changes are the same. As mentioned in a previous article, https://www.ze-ta.co.za/post/architecture_evolution, the following four types of technology change types are needed from time to time in a technology environment (please refer to figure 3):
  • Iterative evolution – the low cost, non-intrusive small changes applied to improve the business- and technical fit of already implemented solutions.
  • Simplify, optimize, and modernize – for example, technology upgrades that may be costly and impactful to current operations.
  • Re-define – this type changes whole architectural patterns, and the execution thereof significantly impacts operations.
  • Selective evolution – individual parts of the architecture evolve in a siloed fashion, maybe as part of a proof-of-concept exercise; or in an attempt to limit the impact on the larger organization.

The iteration through these change types should form part of the technology architecture strategic planning exercise and is very difficult to plan in an organization with a complex operating model.

Figure 3: The four types of technology changes

• Different architecture styles have to be considered best to serve the different types of operations. The operating model contains the ‘value chain’ and customer-facing functions; and business support type functions.
  • Examples of the business support type functions are Finance, Procurement, and Human Resources. Their operational requirements are usually standardized, highly controlled, and not likely to impact the organization’s competitive advantage. Therefore, it is advantageous to use standard solutions built by Vendors specializing in such functionality for this part of the architecture – consider, for example, SaaS solutions.
  • The value chain type functions need to maintain a competitive advantage in the marketplace and may also need integration with various external parties and the support functions’ systems. Therefore, they need an agile environment. However, agility has the caveat of needing simplicity and standardization. It is easier to plan WHAT to change when the WHERE to change is easily identifiable and decoupled from other functions. Therefore, architects should consider different architecture patterns, such as microservices, to enable these functions.
• While new, evolutionary technologies may give any organization a competitive advantage, it may not be easy to obtain resources with the skills required to implement and maintain these technologies. Also, the business needs to be operationally ‘ready’ for these technologies. For example, it would not be prudent to implement automated workflow solutions in environments with unclear and complex processes.
• Sustainability requires stability. Businesses often initiate transformation exercises to optimize operations, from both business and technology architecture points of view, only to see the impact of such efforts dwindle over time. The reason is that the effects of a change in any system need to stabilize via feedback loops. Changes need ‘technical’ stability and a ‘people’ stability. Technical stability is required to iron out operational issues and implement more minor optimizations. The people’s stability relates to the people’s acceptance of the change. Therefore, conscious efforts are needed to communicate:
  • The long-term vision/reason for the change,
  • Their role in ensuring the success of the change, and
  • An indication of how their contributions to the achievement of the change will be rewarded.

When considering the number of change sources, the number of change requests, and the change caveats relevant to any technology environment, it is easy to understand why there is so often a level of frustration between the business and technology environments. It would, therefore, be to the advantage of any CIO to communicate this message to his business stakeholders.

Lizette Robbertze is an Organization Optimization Architect and Digital Strategist. She can be reached at LRobbertze@ze-ta.co.za

LinkedIn: https://www.linkedin.com/in/lizette-robbertze-4842134/

www.ze-ta.co.za