EVOLVING an Organization’s ARCHITECTURES

There are three constants in life – change, choice, and principles.
Stephen Covey

Evolution refers to all species’ constant change and development to ensure a better fit/alignment with their environment. Similarly, organizations constantly evolve to achieve sustainable excellence in their external environments – whether they aim to improve financial results, expand to a larger market share, improve customer satisfaction scores, or have more efficient operations.

The organization’s environments impact its evolution.

Any organization has an internal and an external environment. As an illustration of the business environments, please refer to Figure 1 below.

The internal environment encompasses three models:

  • The Business Model, defined by strategic choices about the product- and services portfolio provided to selected market segments via chosen distribution channels. It also includes pricing, sales, and marketing strategies.
  • The Operating Model,describing the capabilities required by the organization to deliver the Business Model. It contains two types of capabilities: those required for sales, customer support and billing (usually referred to as the Value Chain); and those required to support the whole organization (traditionally referred to as Business Support Functions – such as Finance, Human Resources, Procurement, IT, etc.). Capabilities are specified as processes organized in domains or business functions. The design of the Operating Model is called the Business Architecture.
  • The Resourcing Modeldescribes the different resource types and -structures used by the Operating Model to fulfill its duties. One kind of resource is people, and its model has a design (the organization structure), and other characteristics, such as the preferred consumption policy (e.g., use of full-time employees, contractors, or consultants), and training-, remuneration-, and performance evaluation practices.

The technology solutions used to support the operating model is another type of resource, and its model includes application-, data-, integration-, infrastructure- and security architectures.

The external environment includes the customers, partners, suppliers, competitors, regulators. Some, like customers, have a direct impact on the company’s bottom line, while others, like the regulators, only have an indirect effect.

Figure 1 An Organizations Environment
Figure 1: An Organization’s Environment

Types of organizational evolutions

In organizations, the purpose of evolution is two-fold. Firstly, to ensure alignment with the external environment (customers, suppliers, partners, regulatory bodies) – called its Business Model Evolution – created as strategic decisions by the management team. Secondly, to simplify the operational entropy that naturally develops while doing business. Also, to optimize, modernize, and grow the organization’s operational capability. All changes to the operational capability can be classified as a type of evolution and will always impact the architectures mentioned above – business, application, data, integration, infrastructure, and security.

Understanding the cycles, motivations, and impacts of evolutionary changes will assist in maximizing their benefits to the organization. Evolutionary changes can be classified by their focus and their motivation.

Evolutionary focus can be either tactical or strategic. Tactical, when it happens gradually and not necessarily formally recognized. Strategic, when it is planned officially and executed.

On the other hand, the motivation for evolution can be organic or inorganic. An organic motivator is business growth – increased sales volumes may require more efficient, flexible, and scalable operations. Such change requirements include achieving economies of scale, the maturing of operational capabilities, or the use of advanced technologies.

An inorganic motivator is significant changes to the business model – such as entering new industries by either defining new product/service portfolios for new or existing markets, or, by the merger/acquisition of other businesses. Inorganic business model changes are usually employed to mitigate threats introduced into the external environment – disruptive competitors, significant regulatory or geopolitical changes, or environmental disasters come to mind.

Let’s consider the focus (gradual or strategic) as a vector and motivation (organic or inorganic) as another. It is much easier to understand how each cross-section’s evolutionary styles differ. Figure 2 identifies four types of evolutionary changes:

  • Iterative Evolution:
  • Simplify, Optimize and Modernize:
  • Re-define
  • Selective Evolution
Figure 2 Types Architecture Evolutions
Figure 2: Types Architecture Evolutions

1.      Iterative Evolution

Iterative changes include the Business as Usual (BAU) projects, usually used to improve the business- and technical fit of resources required by the business’ operating model.

Therefore, the scope of these changes is usually specific to a specific domain, and it applies changes to any of the defined architectures. The change requests can originate top-down, from business, or bottom-up, from the technology operations area. They are implemented in a continuous, iterative, and agile manner – new requirements are defined on the fly as per the tactical requirements of the relevant domain.

The impact of iterative changes is usually of low cost and non-intrusive to operations. They, therefore, are low risk and very beneficial to the domain in the short term.

Unfortunately, because of the narrow focus of such changes, the longer-term consequences can be operational complexity and entropy, as the delivery cycles don’t consider alignment across architecture types and business domains. Once scalability and performance issues are experienced, a strategic decision is usually made to move to the ‘Simplify, Optimize and Modernize’ evolutionary type.

2.      Simplify, Optimize and Modernize

This evolutionary type implies changes to most of the organization’s architectures based on predefined goals of alignment and fit.

The scope of these changes includes both the business and technology architectures. Business architecture changes include a redefinition, and even automation, of business processes.

Technology architecture changes include application changes – which could be version upgrades to existing solutions; or the implementation of new solutions to better fit the business’s capability needs. In extreme cases, a holistic redefinition of the application and integration architectures can be considered – for instance, moving from monolithic solutions to a microservice-based architecture.

Changes to the data architecture can include implementing new data storage types – such as graph databases and data lakes – providing operations with artificial intelligence and machine learning; enabling operational decision-making with improved reporting; or, improving data governance with data fabric solutions.

Infrastructure architecture changes usually imply moving the hosting of technology solutions from privately owned and supported infrastructure to clouds managed by Third Parties.

The impact of these change types is significant, costly, and critical if the alignment of requirements between all architectural domains is not given adequate consideration. For example, moving to a microservices architecture is advisable for fast-changing business environments. However, because data is stored locally within each service, it may not be easy to obtain a ‘single view’ of a customer – needed for future business model decisions. Also, even though individual SaaS or PaaS solutions may currently be a perfect fit, they may restrict the future implementation of innovative capabilities that could have provided the organization with a competitive advantage.

Therefore, it is advisable to carefully plan a holistic change plan to guide this type of evolution. A key component of such a plan is the upfront definition of ‘fitness functions’ – stipulating the characteristics (e.g., scalability, reliability, etc.) required from the new architectures.

In the longer term, refinements will be required to the implemented architectures, and the evolution type will therefore migrate back to the tactical ‘Iterative Evolution’ type.

3.      Re-define

The Re-define evolution type is used for significant strategic changes to the business model. Where the next evolution type, ‘Selective Evolution,’ caters for the required changes in a tactical manner, this evolution type involves the integration of the capabilities for the new business model into the current operating model. Therefore, it is driven by a strategic decision and must be designed top-down – starting with the requirements of the new business model.

The scope of these changes starts with a redefinition of the business architecture. Understanding the strengths and weaknesses of all current technology architectures and, the ‘fitness functions’ required for the new architectures are crucial. New architectures are now defined using selected portions of the existing architectures.

The impact of this evolutionary type is impactful and may frustrate operational staff while in progress. For instance, data consolidations and migrations are time-consuming but essential for longer-term success. However, the business can operate as a single entity once implemented, and hence the benefits speak for themselves.

As with the previous evolutionary type, the longer-term consequences include refinements to the implemented architectures, and the evolution type will therefore migrate back to the tactical ‘Iterative Evolution’ type.

4.      Selective Evolution

This evolution type occurs while the business model undergoes significant changes without a strategic decision to optimize or consolidate the supporting operational architectures. Often, the business will operate in silos, with minimal integration in the long term.

The scope of changes is contained per silo, handled as gradual and iterative changes per business- and technical fit requirements.

The impact of changes per silo is usually low cost and non-intrusive to implement. They, therefore, are low risk and very beneficial to the silo in the short term.

However, the longer-term consequences of this type of evolution are not positive and it should be avoided. Apart from being costly to maintain different architecture silos, it also creates operational complexity with slow degradation of overall effectiveness. Often, organizations make the further mistake, attempting to fix the situation by moving into the ‘Simplify, Optimize, and Modernize’ evolution type, while they need, and will always need, to move into the ‘Re-define’ evolution type.

From the above discussion, it is clear that organizations, and their architects, should be conscious of their current evolutionary phase and the one they plan to move in next. Not only will this ensure more constructive planning, but it will also save money and be less stressful on the organization as a whole.

 

Lizette Robbertze

Organization Optimization Architect and Digital Strategist

LRobbertze@ze-ta.co.za

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