Enterprise Change - An architectural view

Enterprises are ubiquitous. The most generic definition of an enterprise could be stated as, “One or more organisations 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 specialised 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 realisation 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 tractability helps manage change effectively. We strongly recommend enterprises to capture the primitives, their relationships and tractability of their operational components for better IT management.

P.S.

I had written this article for an organisation I had the privilege of working for earlier in my career.

IT4IT™ – An Open Group Standard for Managing the Business of IT

The changing expectations of IT: Information Technology (IT) as a function in an enterprise has always played a supportive role to meet Business goals. In the past decade, the expectation was reset and IT was expected to play a more active role of being a key enabler for Business capability. The new digital age characterized by smart phones, gadgets, social media and an explosive growth of digital content however, has pushed the bar higher. Most segments of the market across geographies are being influenced by this new digital transformation one way or another. Hence IT capability of an organization is now expected to innovate and not merely limit itself to IT operations. This is a new transition that IT is going through.

In addition to raised expectations, there is an ecosystem of apps and platforms for devices and gadgets that is challenging the capabilities of IT in organizations. Stakeholders constantly draw comparisons. Planned down times and long wait times for features are not seen as acceptable anymore. Changes driven by rapid strides in technology and user experience are likely to come in thick and fast. Every eight years, a new generation comes out expressing its own will and having a say on how the digital economy will move forward. Expectations will continue to be reset every time a giant technological stride is made expanding user experience possibilities or in the reduction of operational cost. Whereas on the concrete side of digital technology, the cost of hardware is going down and its quality getting arguably better. Open source is consolidating on its evolutionary spirals providing a canvas for collaborative work across the globe. These open up several possibilities along with their own set of challenges.

IT Response: To handle these, the IT shop needs to see itself as a services provider with innovation prowess. The traditional paradigm of identifying gaps and proposing projects shall give way to a new paradigm of continuous assessment, continuous integration and continuous delivery. There is a need for full-fledged automation with a strong focus on work execution where outcomes are measurable with full transparency and traceability.  To do this, a meta-model along with various functional components need to be identified and agreed upon by practitioners. IT4IT, a prescriptive reference architecture and an operational model from The Open Group, is a major step in this direction. It is an industry neutral, technology agnostic evolving standard designed not only for existing landscapes but also for future IT paradigms.

IT4IT: IT4IT is based on Porter’s ‘Value Chain’ model. Value chain is a classification scheme for the complete set of primary and supporting activities that contribute to the lifecycle of creating net value of a market offering. It is based on a ‘process view’ of organizations. The standard has five levels. The first three levels are vendor neutral and provide generic views. Levels four and five are detailed vendor specific refinements and solution architecture which is not covered by the standard.

IT value chain consists of primary and supporting activities as shown in the figure below.  Primary activities are core to the IT organization. They are classified under four value streams.

1. Strategy to Portfolio (S2P) – Drive IT portfolio to business innovation
2. Requirement to Deploy (R2D) – Build what the business needs when it needs it
3. Request to Fulfill (R2F) – Catalog, fulfil and manage service usage and
4. Detect to Correct (D2C) – Anticipate and resolve production issues

The supporting activities identified are five in number and include Finance & Assets, Sourcing & Vendor selection, Intelligence & Reporting, Resource & Project, Governance, Risk & Compliance.

These operate in parallel and are not sequential and hence open for adoption of agile methods.

Final thoughts: IT4IT coexists with existing standards such as ITIL and COBIT.  Organizations can use their own evolutionary insights and best practices as a launch pad, evaluate against the reference architecture as to which functions are performed and what kind of data is being captured in their current state. In case of gaps if any, evaluate if there is a good enough rationale for non-compliance or choose to implement the missing elements and derive its full value. While choosing process tools from the market, the architecture helps perform due diligence providing visionary guidance on the end state integration model.

This is in brief about IT4IT. This is an evolving standard following a consortium model of development. Organizations are encouraged to join, make use of the standard and help it evolve and reach its intended objective. More can be found here.

P.S.

I had written this article for an organisation I had the privilege of working for earlier in my career.