Lecture 5

LECTURE 5
The Dialog Between Business and IT
Svyatoslav Kotusev, PhD
Copyright © 2019 by Svyatoslav Kotusev. All rights reserved.

The course of lectures on enterprise architecture by Svyatoslav Kotusev ([email protected])
In This Lecture
 The most typical practical problems associated with
using a business strategy as the basis for IT planning,
i.e. as an input for an EA practice
 Five common discussion points providing a convenient
middle ground meaningful to both business and IT
representatives and suitable for establishing a productive
dialog between them
 The hierarchy and relationship between these discussion
points
 The so-called EA uncertainty principle
SK Based on the book The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment #2
Problems with the Business Strategy

 The business strategy defines the overall long-term
direction for the whole organization
 The business strategy often includes the following
common elements:
• Core mission statement
• Organizational vision and values
• Competitive and environmental analysis (e.g. SWOT, PEST, Five
Forces, etc.)
• Strategic goals and objectives
• Quantitative and measurable key performance indicators (KPIs)
 However, the business strategy in a narrow sense rarely
provides an adequate basis for IT planning
Strategy Is Often Vague or Merely Absent

 The guidance provided by the business strategy may be
too vague, unclear or abstract
 Many business strategies proclaim largely meaningless
generic motherhood statements
 The business strategy may be miscommunicated,
misunderstood, interpreted differently or merely unknown
 Sometimes a formal and documented business strategy
is simply missing altogether
 The lack of a clearly defined, mutually agreed and widely
understood business strategy undermines the strategy-
based IT planning efforts
Strategy Rarely Provides a Direction for IT

 The business strategy often does not offer any clear
suggestions for IT
 Mission statements, market-share goals, target
indicators of financial performance provide no guidance
on what IT should do to achieve these objectives
 The lack of adequate guidance forces IT planners to
make planning decisions based on their own guesswork
 The inconsistency of perspectives between the business
planning and IT planning minimizes the value of the
business strategy as an input for an EA practice
Strategy Is Unstable and Often Changes

 In many organizations the business strategy changes too
often to offer a sound basis for IT planning
 Constantly changing business objectives quickly make
any strategy-based plans for IT outdated
 In the most extreme cases, strategy-based plans for IT
might become obsolete even before they are completed
 The unpredictable, volatile and unstable nature of the
business strategy makes a strategy-based IT planning
essentially impossible
Strategy Requires Non-Reusable Systems

 The business strategy often requires highly specific IT
systems, which might be essential for the current
strategy, but useless in the long-term future
 Business strategies may be active for 3-5 years, but the
IT systems implemented to support these strategies
often “live” for 10-15 years or even longer
 Many IT systems might be considered as an asset for
the current strategy, but as a liability for the next
strategies
 Chasing latest business strategies leads to proliferation
of legacy IT systems, which create significant problems
in the long run
The Role of Strategy for an EA Practice

 The business strategy in a narrow sense rarely provides
a very useful input for an EA practice
 The strategy specifies neither what IT should do right
now, nor what IT should provide after the next 3-5 years
 A business strategy sets only the “soft” context for an EA
practice, but does not provide enough “hard” data
Discussion Points for Business and IT

 Other aspects and elements should be discussed for
developing optimal IT-related planning decisions
 These discussion points should be able to provide a
middle ground relevant to both business and IT
 The middle ground for business and IT alignment should
be meaningful from both the business and IT viewpoints
 Moreover, this middle ground should provide certain
discussion points across the entire time spectrum
 However, neither typical business notions nor typical IT
notions are able to provide an adequate middle ground
meaningful to both parties
Five Key Discussion Points

 Although different organizations and teams often find
their own unique discussion points, the most common
discussion points include:
• Operating model – global process standardization and data
sharing requirements
• Business capabilities – specific capabilities of an organization
that require improvements
• Specific business needs – specific needs of an organization that
require to be addressed
• Business processes – high-level process change requirements
to specific IT solutions
• Business requirements – detailed business requirements to
specific IT systems
Convenient Discussion Points
Operating Model
 An operating model is the desired level of organization-
wide process standardization and data integration
 An operating model defines what business processes
are standardized and what business data is shared
across major business units, e.g. lines of business,
business functions or regional offices
 An operating model determines global standardization
and integration requirements for the key business-
enabling EA domains, i.e. business, applications and
data
Process Standardization
 The required level of process standardization indicates
the degree to which business units should perform same
business processes in the same way
 Standardization of business processes has both
advantages and disadvantages for organizations
 Standardization of business processes facilitates brand
recognition, global efficiency and predictability
 Standardization of business processes limits local
opportunities for customization and innovation
Data Integration
 The required level of data integration indicates the
degree to which business units should share business
data between each other
 Sharing of business data across business units also has
both advantages and disadvantages for organizations
 Data integration allows presenting a “single face” to
customers, enables end-to-end transaction processing,
increases transparency, coordination and agility
 Data integration increases coupling between business
units, requires achieving a common understanding of
shared data entities and developing their standard,
commonly agreed definitions and formats
Four Operating Models

 Decisions regarding standardization and integration have
far-reaching implications for the whole organization from
both the business and IT perspectives
 The combination of these two decisions defines four
possible operating models:
• Diversification
• Coordination
• Replication
• Unification
 Each operating model implies different structure of the
business, requires different structure of the IT landscape
and supports different types of business strategies
Diversification (Description)
 The diversification model is an operating model with
low process standardization and low data integration
 The diversification model is appropriate for highly
decentralized organizations consisting of diverse and
independent business units, e.g. lines of business
 Business units are managed autonomously, design their
own business processes, have independent transactions
and share little or no common customers and suppliers
 IT landscapes consist of global IT services and
infrastructure and local applications and databases
owned by specific business units
Diversification (Capabilities)
 Core elements of IT landscapes are lean layers of
shared infrastructure and technology services supporting
all business units
 The key capability of IT landscapes is providing
economies of scale through sharing IT services and
infrastructure without limiting local independence
 The diversification model relies on the independence,
flexibility and local autonomy of separate business units
in serving customers and generating profits
 The diversification model may be unsuitable for any
centrally orchestrated business innovations
Coordination (Description)
 The coordination model is an operating model with low
process standardization and high data integration
 Coordination is appropriate for decentralized companies
consisting of diverse but interdependent business units,
e.g. business functions or product divisions
 Business units are managed autonomously and may
offer their own local products or services, but depend on
transactions in other business units and have shared
customers, products, suppliers or partners
 IT landscapes consist of global databases, IT services
and infrastructure shared by all business units and local
applications owned by specific business units
Coordination (Capabilities)
 Core elements of IT landscapes are central data hubs
storing common information accessible to all local
applications in business units
 The key capability of IT landscapes is providing easy
global access to the shared data through standard
technology interfaces
 The coordination model relies on superior customer
service, local innovation, cross-selling and upselling
opportunities, transparency across key transactions and
supply chain processes
 The coordination model may be unsuitable for competing
based on lower costs
Replication (Description)
 The replication model is an operating model with high
process standardization and low data integration
 The replication model is appropriate for decentralized
organizations consisting of similar but independent
business units, e.g. regional offices selling same product
 Business units are managed autonomously but follow
centrally defined business processes, have independent
transactions, manage their customers locally and share
little or no common customers
 IT landscapes consist of globally standardized
applications and databases owned locally by specific
business units and global IT services and infrastructure
Replication (Capabilities)
 Core elements of IT landscapes are replicable IT
systems supporting core business processes and
deployed in all business units
 The key capability of IT landscapes is providing standard
sets of information systems for standardized business
processes optimized for global efficiency
 The replication model relies on efficient, predictable and
repeatable business processes enabling consistent
customer experience as well as on the capacity for
organization-wide process innovation
 The replication model may be unsuitable for building
complex customer relationships
Unification (Description)
 The unification model is an operating model with high
process standardization and high data integration
 Unification is appropriate for centralized organizations
consisting of similar and interdependent business units,
e.g. interrelated regional or market segment divisions
 Business units are managed centrally, perform similar or
overlapping business operations, run standardized
business processes, have globally integrated
transactions, shared customers, products or suppliers
 IT landscapes consist of global applications, databases,
IT services and infrastructure shared by all business
units
Unification (Capabilities)
 Core elements of IT landscapes are globally accessible
systems enabling core business processes in all
business units, often comprehensive ERP systems
 The key capability of IT landscapes is providing standard
IT systems with global data access reinforcing
standardized business processes
 The unification model relies on maximizing efficiency and
reducing variability of business processes, using
integrated data, minimizing costs and ensuring
consistent customer experience
 The unification model may be unsuitable for competing
based on highly innovative offerings
Key Properties of the Operating Models
Operating Models as Discussion Points

 Since an operating model has profound consequences
for both business and IT, it provides a convenient
discussion point for business and IT leaders
 Each operating model implies a specific way of doing
business and determines what an organization can do
 Each operating model facilitates the execution of some
business strategies, but inhibits the execution of others
 Each operating model requires a specific structure of the
IT landscape and demands certain IT capabilities
 An operating model provides suggestions regarding what
IT landscapes should do well and should not do well
Time Horizon of Operating Models

 An operating model is the most abstract of all common
discussion points between business and IT stakeholders
 The choice of an operating model is a more fundamental
decision than the choice of a business strategy
 The notion of operating model is appropriate for a very
long-term global IT planning with a horizon of longer than
3-5 years
 Decisions on the desired operating model are often
expressed through architecture principles or other dual
EA artifacts helping document organization-wide process
standardization and data sharing requirements
Business Capabilities
 A business capability is a general ability or capacity of
an organization to perform a specific business activity
 The full set of all organizational business capabilities
represents everything that an organization can do or
needs to do to run its business
 Business capabilities are multifaceted notions
encompassing all underlying business processes,
people, knowledge and other resources, including
information systems, required to fulfill these capabilities
 Business capabilities of an organization offer a stable
view of its business and change pretty rarely, only in
case of significant business transformations
Capabilities as Discussion Points

 Since business capabilities represent both the abilities of
business and underlying IT assets, they provide
convenient discussion points for business and IT leaders
 Business leaders understand the relationship between
their business strategy and business capabilities
 Business executives can specify which exactly business
capabilities should be improved to execute the strategy
 Architects understand the relationship between business
capabilities and underlying information systems
 Architects can determine what new IT systems are
necessary to uplift the requested business capabilities
Time Horizon of Business Capabilities

 Business capabilities are more detailed than an
operating model
 Business capabilities suggest where exactly business
and IT improvements are required according the current
business strategy
 Business capabilities may be very useful for coarse-
grained conceptual planning, typically with a long-term
planning horizon up to 3-5 years ahead
 Discussions of business capabilities are often supported
by capability maps or other similar dual EA artifacts
helping decide which capabilities should be uplifted
Specific Business Needs

 A specific business need is a general idea to address a
particular business problem using IT, e.g. accelerate the
mortgage lending process
 Specific business needs can be considered as proposed
business initiatives or projects with necessary IT
components
 Each business need implies solving some business
problem as well as changing the organizational IT
landscape to enable the corresponding solution
Business Needs as Discussion Points

 Since business needs represent both business
improvement opportunities and related IT changes, they
provide convenient discussion points for business and IT
 Business executives understand the relative importance
of specific business needs for their business
 Business leaders can assess the value anticipated from
addressing specific business needs
 Architects understand what changes in the IT landscape
are required to implement specific business needs
 Architects can offer a number of possible technical
options for addressing the requested needs with IT
Time Horizon of Specific Business Needs

 Specific business needs are more detailed than business
capabilities
 Specific business needs suggest what approximately
should be done
 Specific business needs are often used for planning the
mid-term future up to 2-3 years ahead, in some cases for
longer planning horizons
 Discussions of specific business needs are facilitated by
IT investment roadmaps or other similar dual EA artifacts
helping business and IT leaders prioritize and schedule
candidate business needs to be addressed with IT
Business Processes
 A business process is a sequence of specific activities
carried out by particular actors intended to produce
some valuable business outcomes
 Business processes are also characterized by certain
inputs and outputs, material or immaterial, e.g. physical
goods or information
 Business processes define the steps and tasks
accomplished by the employees as well as the roles of
relevant IT systems in enabling these steps and tasks
Business Processes as Discussion Points

 Since business processes represent both specific
business activities and functionality of IT systems, they
 Business leaders understand the role of separate
business processes for their business
 Business sponsors can evaluate the business benefits of
specific changes in established business processes
 Architects understand the role of information systems in
supporting specific business processes
 Architects can articulate what the IT department should
deliver to enable the desired changes in processes
Time Horizon of Business Processes

 Business processes are more detailed than specific
business needs
 Business processes suggest how approximately IT
solutions should work and how exactly specific
organizational activities should be changed
 Business processes can be used only for relatively short-
term planning up to 1-2 years ahead in the future
 Discussions of business processes are often based on
solution overviews or other dual Outlines helping decide
how exactly current processes should be modified by
new IT solutions
Business Requirements
 Business requirements, or system requirements, are
detailed functional and non-functional specifications for
concrete IT systems
 Business requirements describe the expected behavior
of a particular IT system from the business perspective
 Business requirements specify how exactly an IT
solution should work and imply certain underlying system
components implementing these requirements in
software or hardware
Requirements as Discussion Points

 Since business requirements reflect the behavior of IT
systems from both the business and IT sides, they
 Business stakeholders understand the role of specific
business requirements to IT systems
 Business sponsors can formulate and prioritize business
requirements for IT projects
 Architects also understand the role of specific business
requirements to IT systems
 Architects can propose and describe the detailed
structure of new IT systems addressing the requirements
Time Horizon of Business Requirements

 Business requirements are the most detailed of all
common discussion points between business and IT
stakeholders, more detailed than business processes
 Business requirements provide very specific descriptions
of desired IT systems
 Business requirements are suitable only for the short-
term IT planning covering the immediately actionable
perspective up to 6-12 months ahead
 Discussions of business requirements often revolve
around solution designs or other dual Designs helping
agree on specific requirements to new IT systems
The Role of the Key Discussion Points

An operating model, business capabilities, business needs,
business processes and business requirements are the
most common, but not the only possible discussion points
The five key discussion points are significantly different in

their abstraction levels, appropriate organizational scopes
and planning horizons
Properties of the Key Discussion Points
The Pyramid of Key Discussion Points
Granularity, Scopes and Horizons

 The abstraction levels of discussion points negatively
correlate with their planning scopes and horizons
 The discussion points and respective planning decisions
appropriate for the widest scopes and longest time
horizons are the most abstract ones, and vice versa
 The same conclusion is true for EA artifacts as well
 The EA uncertainty principle: Organizations can be
either planned for wider scopes and longer horizons in
less detail, or planned for narrower scopes and shorter
horizons in more detail, but they cannot be planned for
wide scopes and long horizons in great detail
EA Uncertainty Principle
Lecture Summary
 The business strategy rarely provides a sound basis for
planning due to ambiguity, volatility and irrelevancy to IT
 Productive discussions between business and IT often
revolve around five key discussion points:
• Operating model – helpful for the horizon of more than 3-5 years
• Business capabilities – helpful for the horizon up to 3-5 years
• Specific business needs – helpful for the horizon up to 2-3 years
• Business processes – helpful for the horizon up to 1-2 years
• Business requirements – helpful for the horizon of 6-12 months
 The EA uncertainty principle suggests that organizations
can be planned for wider scopes and longer horizons in
less detail, and vice versa
In the Next Lecture

 The next lecture will focus specifically on the process
aspects of an EA practice and provide an in-depth
discussion of key EA-related processes
QUESTIONS?
Svyatoslav Kotusev, PhD
Copyright © 2019 by Svyatoslav Kotusev. All rights reserved.

Lecture 5 - The Dialog Between Business and IT

Uploaded by

Copyright:

Available Formats

Lecture 5 - The Dialog Between Business and IT

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lecture 5 - The Dialog Between Business and IT

Uploaded by

Copyright:

Available Formats

The Dialog Between Business and IT

Svyatoslav Kotusev, PhD

Copyright © 2019 by Svyatoslav Kotusev. All rights reserved.

Problems with the Business Strategy

Strategy Is Often Vague or Merely Absent

Strategy Rarely Provides a Direction for IT

Strategy Is Unstable and Often Changes

Strategy Requires Non-Reusable Systems

The Role of Strategy for an EA Practice

Discussion Points for Business and IT

Five Key Discussion Points

Convenient Discussion Points

Four Operating Models

Key Properties of the Operating Models

Operating Models as Discussion Points

Time Horizon of Operating Models

Capabilities as Discussion Points

Time Horizon of Business Capabilities

Specific Business Needs

Business Needs as Discussion Points

Time Horizon of Specific Business Needs

Business Processes as Discussion Points

Time Horizon of Business Processes

Requirements as Discussion Points

Time Horizon of Business Requirements

The Role of the Key Discussion Points

The five key discussion points are significantly different in

Properties of the Key Discussion Points

The Pyramid of Key Discussion Points

Granularity, Scopes and Horizons

In the Next Lecture

Copyright © 2019 by Svyatoslav Kotusev. All rights reserved.

You might also like