Lecture 3pdf_ for MIT students.. prepared by Asst. Prof. Bal Krishna Subedi, Center Department of Computer Science and IT, Tribhuvan University.

1. Enterprise Application
(MIT503)
Unit 2: Enterprise Application Architecture
Asst. Prof. Bal Krishna Subedi
Center Department of Computer Science and IT
Tribhuvan University

2. Roles and practice of enterprise architecture
3
• The Need for Enterprise Architecture
• Enterprise architecture is a natural solution to natural
problems of modern organizations Enterprise architecture is
not an accidental phenomenon, but rather is a natural
solution to natural problems of many modern organizations.
• Successful execution of any business strategy in modern
organizations often implies, or sometimes is even equivalent
to, the implementation of the corresponding information
systems supporting this strategy. The critical
interdependence between business and IT functions requires
a disciplined approach to coordinating business and IT plans.

3. Roles and practice of enterprise architecture
4
• The Need for Enterprise Architecture
• However, business and IT are disparate areas and establishing
effective communication between them have always been
troublesome.
• Hence, the emergence of the phenomenon of enterprise
architecture is a perfectly natural reaction of modern
organizations to the desperate need to optimize their
extensive IT landscapes as well as to improve collaboration,
communication and partnership between various
stakeholders with incompatible business and IT backgrounds.

4. Roles and practice of enterprise architecture
5
• Significance of Enterprise Architecture
• Enterprise architecture is here to stay and its importance seemingly is only
going to increase in the future because of three ongoing trends:
– First, IT systems are continuously getting more sophisticated, comprehensive
and diverse. If typical business managers barely understood IT before, then in
the future it will be even more challenging for an ordinary business person to
understand how IT works.
– Second, the general dependence of business on IT is constantly increasing.
More and more manual operations become automated, more and more
analytical capabilities get implemented in software, more and more traditional
human roles in organizations become substituted with computers.
– Third, the innovative potential of IT for business is incessantly growing as well.
New strategic opportunities for gaining competitive advantage from the
effective use of IT emerge at a very rapid pace. If typical business managers
were not completely aware of the full innovative potential of IT before, then in
the future it will be even harder for an ordinary business person to understand
what groundbreaking opportunities IT can offer to their business.

5. Roles and practice of enterprise architecture
6
• Significance of Enterprise Architecture
• Enterprise architecture seemingly represents
one of the most significant and widely
applicable management innovations of the
last two decades which engendered a
completely new corporate function and even a
separate dedicated profession, reflecting the
fundamental importance of IT for modern
organizations.

6. Roles and practice of enterprise architecture
7
• Communication as the Cornerstone of
Enterprise Architecture Practice
• Different elements of an EA practice are only the means
of improving the quality of communication and decision-
making. However, these elements address rather
different aspects of communication and decision-making
in organizations.
• Importantly, communication as part of an EA practice
almost always implies, and even requires, intense face-
to-face contacts in the form of direct personal
conversations, group meetings, workshops or
presentations.

7. Roles and practice of enterprise architecture
8
• Communication as the Cornerstone of
Enterprise Architecture Practice

8. Roles and practice of enterprise architecture
10
• Direct Benefits of Enterprise Architecture
• Direct benefits resulting from the proper usage of particular types of EA
artifacts include:
– Improved effectiveness of IT investments: specific EA artifacts help
focus IT investments on the most strategically important business
areas and ensure that organizations achieve their critical long-term
business objectives by investing in IT.
– Improved efficiency of IT investments: specific EA artifacts help
estimate the short-term business value of separate IT investments and
ensure that each IT initiative has positive financial returns and delivers
reasonable business value for its money.
– Reduced costs of IT operations: specific EA artifacts help limit the
number of supported technologies, products and vendors and ensure
that proposed IT solutions do not introduce unnecessary additional
maintenance expenses.
– Reduced technical and compliance risks: specific EA artifacts help
follow consistent implementation approaches based on proven
technologies and compliant with relevant legislative norms and ensure
that proposed IT solutions don’t introduce any unacceptable risks.

9. Roles and practice of enterprise architecture
11
Direct Benefits of Enterprise Architecture
– Direct benefits resulting from the proper usage of
particular types of EA artifacts include:
– Reduced complexity of the IT landscape: specific EA artifacts help
reduce the diversity of utilized technologies and approaches, untangle
the IT landscape and ensure that new IT solutions do not introduce
excessive complexity.
– Increased reuse of available IT assets: specific EA artifacts help
manage and reuse existing corporate IT assets and ensure that new IT
solutions leverage available systems, platforms or databases whenever
it is possible and desirable.
– Reduced numbers of duplicated and legacy systems: specific EA
artifacts help identify potential duplication, manage the lifecycle of IT
assets and ensure that redundant and legacy IT systems are
decommissioned in a timely manner.

10. Roles and practice of enterprise architecture
12
• Direct Benefits of Enterprise Architecture
• Direct benefits resulting from the proper usage of particular types of EA
artifacts include:
– Increased agility of IT planning: specific EA artifacts help plan changes
in the IT landscape, explore available implementation options and
ensure that new IT solutions seamlessly fit into the existing IT
environment.
– Improved speed of the project delivery: specific EA artifacts help
accelerate the delivery of new IT projects and ensure that all IT
solutions are implemented with minimal unnecessary delays.
– Improved quality of the project delivery: specific EA artifacts help
deliver new IT projects in a more consistent, smooth and predictable
manner and ensure that all IT solutions meet essential business and
architectural requirements.
– Improved overall conceptual consistency: specific EA artifacts help
avoid making inconsistent or incompatible planning decisions and
ensure that all IT solutions align with the fundamental business and IT
considerations.

11. Roles and practice of enterprise architecture
13
• Indirect Benefits of Enterprise Architecture
• The direct benefits of utilizing certain types of EA
artifacts eventually help organizations achieve overall
business and IT alignment.
• The improved business and IT alignment leads to
numerous indirect organizational benefits including:
– Better operational excellence, customer intimacy and
product leadership
– Increased speed to enter new markets and overall
organizational agility
– Improved managerial satisfaction

12. Roles and practice of enterprise architecture
14
• Link Between Direct and Indirect Benefits
• The use of enterprise architecture leads to a number of direct
benefits, which in turn lead to a number of indirect benefits
for organizations.

13. Roles and practice of enterprise architecture
to drive their evolution. 15
• The Value of Enterprise Architecture
• Importantly, similarly to other supporting organizational functions like
accounting or human resource management (HRM), the business value
of an architecture function, as well as of an EA practice in general,
cannot be easily calculated, measured or otherwise quantified in
financial terms.
• An architecture function is a supporting function and its business value
cannot be easily calculated or measured.
• Like an HRM function, an architecture function adds no direct business
value to the organizational value chain.
• Since an EA practice is a continuous activity rather than a one-time
project, it is impossible to estimate the return on investment (ROI)
from EA efforts.
• The benefits of practicing enterprise architecture are qualitative in
nature and cannot be converted into dollars in a straightforward
manner.
• However, it is arguably impossible to manage thousands, hundreds and
even tens of information systems without using enterprise architecture

14. 16
Architecture Functions in Organizations
• What Organizations Practice EA?
• An EA practice can benefit all organizations employing more than
30-50 IT specialists where IT is used to support main business
activities.
• Enterprise architecture is widely practiced in various commercial
companies across the globe working in diverse industry sectors
including banking, agriculture, insurance, retail, high-tech and even
the oil industry.
• Enterprise architecture is practiced in commercial companies and
non-profit organizations from diverse industry sectors including
banking, agriculture, retail, education, healthcare and public
services.
• Currently the vast majority of large organizations in developed
countries either already practice enterprise architecture or plan to
start practicing it in the near future

15. Historical origin and best modern practices
17
• The widespread commercial adoption of information systems
in business began in the late 1950s.
• The commercial use of mainframe computers in organizations
further expanded in 1965 after the introduction of the
innovative IBM 360 series with a powerful operating system,
time-sharing and multitasking support. By the end of the
1960s, computers had already been widely used in many
leading U.S. companies and most of these companies
established permanent positions for top computer executives.
• The growing importance of information systems for the
business of many organizations intensified the persistent
problem of achieving business and IT alignment as well as the
need for effective strategic information systems planning.

16. Historical origin and best modern practices
18
• In order to address the pressing issue of business and IT
alignment, different vendors, consulting companies and
individual experts since the early 1960s proposed numerous
formal, detailed, step-by-step architecture-based planning
methodologies, initially positioned as strategic information
systems planning methodologies and later as EA frameworks,
intended to translate the business strategy of an organization
into an actionable plan for its information systems.

17. Historical origin and best modern practices
• The most widely known of the methodologies and
frameworks promoted during different historical periods
include early Business Systems Planning (BSP) and Method/1
in the 1970s, Information Engineering and Strategic
Data/Information Planning in the 1980s, later Enterprise
Architecture Planning (EAP) and Technical Architecture
Framework for Information Management(TAFIM) in the
1990s, Federal Enterprise Architecture Framework (FEAF) in
the 2000s and now TOGAF(The Open Group Architecture
Framework) since the 2010s.
• These planning approaches have been marketed under
different titles including strategic information systems
planning, then strategic data planning, information

18. Historical origin and best modern practices
19
• Modern EA Best Practices
• Genuine EA best practices emerged and matured in industry as
numerous system planners tried to address the problem of business
and IT alignment.
• The emergence of consistent EA best practices is a natural reaction
of industry, rather than a deliberate product of some consultants,
gurus or “fathers”.
• Numerous EA methodologies and frameworks might have inspired
current EA best practices, but certainly did not invent or prescribe
them in any real sense.
• Although the concept of enterprise architecture is associated with
popular EA frameworks, e.g. TOGAF, Zachman and FEAF, all these
frameworks have nothing to do with the actual EA best practices.
These best practices simply cannot be derived from any existing EA
frameworks or methodologies.

19. What an EA Practice Is Not
20
• Since the early 2000s enterprise architecture
has been a “hot”, widely discussed and overly
hyped topic.
• As a result, many descriptions of an EA
practice available today are unsubstantiated,
misguiding, unrealistic or even completely
fictitious.
• Therefore, it is important to understand what
an EA practice is not.

20. What an EA Practice Is Not
21
• Not a Purely Technical Planning
• An EA practice should not be confused with a purely
technical planning accomplished inside IT departments.
• The general purpose of an EA practice is to bridge the
gap between business planning and IT planning and
thereby improve business and IT alignment.
• Successful EA practices require to be closely integrated
with business planning.
• The separate planning of IT disconnected from
business planning can lead only to misalignment.

21. What an EA Practice Is Not
22
• Not a One-Size-Fits-All Methodology
• Even though an EA practice can be beneficial to most large
organizations depending on IT regardless of their sectors or
industries as noted earlier, there are no easily replicable
one-size-fits-all approaches or universal step-by-step
methodologies for organizing a successful EA practice.
• Though EA practices follow the same high-level patterns
described, they are always in many lower-level details, e.g.
specific EA artifacts, roles of architects or peculiarities of
EA-related processes.
• EA practices cannot be copied from other organizations,
but need to be established in-house and then fine-tuned
continuously adapted to specific organizational needs.

22. What an EA Practice Is Not
23
• Not an Automated Planning
• An EA practice is a practice of using specific EA artifacts for effective
communication, balanced decision-making and disciplined information systems
planning. However an EA practice does not make the planning in organizations
happen automatically.
• An EA practice itself is unable to translate the business strategy into specific
information systems in an automated semi-mechanical manner.
• EA artifacts are merely the tools that help different actors collaborate, achieve
mutual understanding and develop reasonable planning decisions taking into
account the best interests of all stakeholders.
• In EA practices the planning work itself is still carried out only by human beings,
not by EA artifacts. EA artifacts only facilitate, but not automate the information
systems planning processes.
• EA artifacts, though useful for planning, are unable to make any tough planning
decisions for people, e.g. select appropriate technologies, determine strategic
investment priorities or define rational solution structures. They can neither
substitute the human ability to plan and achieve agreements, nor automate the
actual planning activities.

23. What an EA Practice Is Not
24
• Not a Substitute for Competence
• An EA practice helps people in organizations make optimal planning
decisions and implement these decisions. However, an EA practice is
unable to transform incompetent thoughts and actions into competent
ones. For instance, an EA practice cannot help develop winning business
strategies to incompetent business executives, who are unaware of the
current business trends and opportunities in the market.
• An EA practice cannot help develop successful IT strategies to
incompetent IT leaders, who are not knowledgeable in the latest available
technologies and their capabilities.
• Similarly, an EA practice cannot help implement IT solutions to
incompetent IT specialists, who are not well-acquainted with relevant
technologies or unable to deliver high-quality work on time.
• In other words, an EA practice, though facilitates information systems
planning and delivery, is unable to compensate for the incompetence of
involved actors.

24. What an EA Practice Is Not
25
• Not a Work of Dedicated Experts
• An EA practice requires active involvement and participation of
multiple business and IT stakeholders in the planning processes.
• Architectural planning cannot be carried out solely by an isolated
group of architects or other highly qualified experts on behalf of the
whole organization.
• Any plans, regardless of their quality, are useless unless all the
essential stakeholders of these plans clearly understand how these
plans were developed, why certain decisions have been taken and
how these plans should be modified when circumstances change.
• Any architectural plans produced by a narrow group of architects on
behalf of their real stakeholders typically end up lying on shelves,
not improving business and IT alignment.

25. What an EA Practice Is Not
26
• Not a One-Time Planning Project
• An EA practice is a continuous organizational activity
requiring constant communication and collaboration
between various actors, not a one-time planning project.
• The ongoing process of planning and communication itself
is more important than the actual plans represented by EA
artifacts produced as an outcome of this process.
• An EA practice implies intensive organizational learning and
matures over time as its main stakeholders learn to
cooperate by means of using EA artifacts.
• Heaps of EA artifacts describing the ideal future produced
as a one-shot planning effort usually end up laying on
shelves rather than improving business and IT alignment.

26. What an EA Practice Is Not
27
• Not a Technology-Specific Practice
• An EA practice is a technology-agnostic and vendor-neutral
practice that is not related to any particular technologies,
technical approaches or paradigms.
• An EA practice facilitates information systems planning
regardless of what specific systems, products or
technologies are used.
• Since an EA practice intends to enable effective
communication, knowledge sharing and balanced decision-
making, its primary focus is not technologies but people .
• The role of an EA practice is to help make optimal decisions
regarding the selection of appropriate systems, products,
technologies and approaches.

27. What an EA Practice Is Not
28
• Not an Enterprise Engineering
• An EA practice should not be confused with enterprise engineering.
• An EA practice does not imply any rigid analysis-synthesis procedures
similar to traditional engineering
• An EA practice typically does not require producing any formal blueprints
or using any sophisticated calculations.
• Compared to “hard” engineering, an EA practice can be considered as a
“soft” organic planning approach which relies on pragmatic documents,
informal discussions and quick approximations instead of meticulous
drawings, strict processes and precise computations.
• Real organizations are complex living systems that cannot be designed
with traditional engineering methods.
• For the most part, enterprise engineering can be regarded only as a
utopian(everything perfect) idea unfit for the real world, while an EA
practice is a pragmatic and widely adopted approach to managing the
evolution of real organizations.

28. What an EA Practice Is Not
29
• Not Systems Thinking
• Practicing enterprise architecture is mostly about communicating
and doing, rather than thinking.
• An EA practice should not be confused with systems thinking. While
thinking systematically is definitely better than thinking
unsystematically and systems thinking is widely acknowledged as
one of the most critical abilities of architects, the misalignment
between business and IT in organizations cannot be addressed
merely by thinking.
• Managerial challenges related to poor coordination of plans,
decisions and actions require improving cooperation, rather than
applying better, more systematic thinking.
• Although an EA practice can undoubtedly benefit from the
systematic thinking of its actors, it still rests mainly on
institutionalized collaboration and decision-making processes.

29. What an EA Practice Is Not
30
• Not a Breakthrough Solution
• Even though an EA practice offers a kit of proven planning
instruments and approaches for addressing the problem of
business and IT alignment in organizations, it should not be
viewed as a miraculous solution capable of eliminating this
problem entirely or delivering dramatic enhancements in
productivity.
• Any complex organizational and managerial problems
simply cannot be resolved completely, but only reduced to
an acceptable level.
• EA practices allow taking the problem of business and IT
alignment under control and realizing gradual increases in
various aspects of organizational performance, but they do
not increase performance multifold.

30. What an EA Practice Is Not
31
• Not an Implementation of EA Frameworks
• An EA practice should not be confused with implementing popular EA
frameworks, e.g. TOGAF, Zachman, FEAF, etc.
• Though actively promoted and closely associated with the very notion of
enterprise architecture, these frameworks are merely marketing-driven
management fads unrelated to working EA practices and having no
examples of their successful implementation.
• All the attempts to follow the actual recommendations of EA frameworks
in practice may result in failures.
• EA practices in successful organizations do not resemble the prescriptions
of these frameworks in any real sense, neither in specific details nor even
in general ideas. For instance, successful EA practices never fill the cells of
the Zachman Framework, never follow the steps of the TOGAF
architecture development method (ADM) and never develop the heaps of
EA artifacts recommended by TOGAF, even in the organizations included in
the list of TOGAF users provided by The Open Group itself.

31. 32
Thank You!!!
Reference:
• Svyatoslav Kotusev - The Practice of Enterprise
Architecture, A Modern Approach to Business
and IT Alignment-SK Publishing (2021)