Digital Transformation & Software Engineering Services
Enterprise Change: An Architectural View

Enterprise Change: An Architectural View

Enterprises are ubiquitous. The most generic definition of an enterprise could be stated as, “One or more organizations working for a common objective”. Entities such as corporations, government bodies, municipal bodies and small businesses etc. are all enterprises. The benefits they deliver can widely range from shareholder value to the establishment of law and order in a society. Enterprises are legal entities and honour contractual obligations making them key vehicles of commerce. The boundary of an enterprise is not always definite. It constantly evolves both in terms of its composition and in terms of its interaction with its environment. We will discuss some of the common drivers of enterprise change in this article.

Enterprises structure supply and demand. They evolve and adapt according to the environment. Enterprises perform several functions. The larger the scale of operations, the greater is the need for specialized departments performing specific functions.  Departments such as Sales, Marketing, Customer Support, Manufacturing, HR, Finance, Logistics, Legal services, Purchasing, Warehouse and IT are universally common for commercial enterprises across industries.

The structural similarity of enterprises led to Enterprise Resource Planning (ERP) products which initially claimed to solve all enterprise needs. However, each ERP product specialized only in certain areas that they were well designed for.  Besides, ERPs are expensive to implement. Clearly, one size does not fit all.  On the other hand, custom-built enterprise applications of varying sizes tailored for various workflows and business processes have been common. A typical medium sized enterprise would have a sizable number of applications in their catalogue. Relatively large enterprises would have one or more ERP solutions in addition to a number of enterprise applications. These discrete applications led to information and process silos, which could be unlocked and integrated with integration patterns and solutions such as an Enterprise Service Bus (ESB). Moreover, mergers and acquisitions introduce duplicate features. In addition to these challenges, the availability of low cost alternative technologies such as cloud infrastructure would require the entire catalogue of applications to be revisited and re-architected from time to time. Change and complexity are inevitable for enterprises.

Other key change triggers could be:

  1. Strategic initiatives resulting in new business processes or change in existing business processes
  2. Market conditions or statutory regulations triggering a change in business processes
  3. Technological advancements in User Experience (UX) and rendering mediums requiring alternative approaches to achieve the same business goals or even trigger a change in strategy
  4. Advancements in big data technologies and analytics resetting business expectations
  5. New engineering practices promising faster turnaround triggering a change in implementation and operational mechanisms
  6. Addition of a few new locations or external partners
  7. Addition of new organizations or modifications to existing ones with new roles
  8. Changes in business rules depending on one or more factors
  9. Changes to periodicity of well-defined event occurrences or new event occurrences

There are several types of complexity triggers here. Complexity has at least three aspects: interconnectedness, interwoven-ness and composite. While the interconnected and interwoven nature of complexity can be easily understood, the composite aspect is not so obvious. An enterprise is made of several primitives, e.g., data, business processes, organizations and roles, locations, timings and motivations. Every time a primitive undergoes change, its composite relationship with other primitives could also change. So too the operational components that are realized after several transformations may undergo change. The Zachman framework helps make sense of these variables and transformations.

The framework draws inspiration from ancient wisdom and proposes a two-dimensional classification schema. The first dimension consists of the six primitive interrogatives (what, how, where, who, when and why). The six interrogatives translate to:

  1. Inventory sets (what),
  2. Process flows and application components (how)
  3. People, responsibility assignments, organizations and roles (who)
  4. Locations and distribution networks (where)
  5. Event timings (when)
  6. Motivational intentions or business rules (why)

For instance, primitives such as inventory sets (what), roles (who) and process flows (how) lead to composites such as user-activity and user-activity-data. Importantly, these mappings are generic and are not technology or implementation specific. Thus any business rule can be seen as a composite of primitives or a composite of composites.

The second dimension consists of the six levels of reification (identification, definition, representation, specification, implementation and instantiation). Reification essentially means ‘to convert abstract into concrete’. Strategy is at the highest level of abstraction and operational model is its concrete reality. The levels are perspectives from various standpoints.

  1. Executive perspective – Strategy (identification)
  2. Business management perspective – Business (definition)
  3. Architect perspective – System (representation)
  4. Engineer perspective – Technology (specification)
  5. Technician perspective – (implementation)
  6. Enterprise perspective (instantiation and operation)

Each level is a set of models across the six primitives that meet the goals as set by the layer above it and sets expectations for the layer below it. The first three levels are technology agnostic and hence provide immense value for clear communication across various stakeholders.

In terms of architecture, business architecture encompasses identification and definition.  Solution architecture is equivalent to system representation model. Technical architecture is equivalent to specification of technology. Implementation is the realization of application components. Operational model (instantiation) stands up the components, determines change management, SLA adherence and escalation process etc. Infrastructure architecture pertains to locations and distributions column.

Summary: Enterprises are complex yet made of simple primitives. Vertically, strategies translate to operations. Horizontally, a change in any one primitive can impact the composites it is associated with. It can also impact the operational components in the functioning enterprise. A view of this traceability helps manage change effectively. We strongly recommend enterprises to capture the primitives, their relationships and traceability of their operational components for better IT management.

More about Zachman framework can be read here.

About the Author

Vivekanand Gopinath Vivekanand Gopinath
Vivekanand Gopinath is a Senior Architect who has 17 years of experience in IT that includes scoping, defining, designing and delivering complex, scalable, distributed, component-based enterprise applications. He is an Oracle and TOGAF certified professional.