Why Is EA So Important? Jeff Tash, ITscout Flashmap Systems, Inc.

Why Is EA So Important?
Jeff Tash, ITscout
Flashmap Systems, Inc.
([email protected])
(www.FlashmapSystems.com)
Abstract
Discover how and why companies ought to transform themselves from IT cultures
driven by cost and quality control to enterprises that can profit from creative IT
thinking. Designing innovative IT architecture requires visionary talent. Success
depends on turning enterprise architecture into a core methodology of innovation.
This requires learning how to communicate complexity by simplifying and
synthesizing.
Introduction
EA is a two-letter acronym that stands for “Enterprise Architecture.” Unfortunately, if
one were to ask people who work at most enterprises to define EA, the majority would
likely frame their definition in terms of a completely different two-letter acronym -- BS!
It’s not that they’d necessarily be lying to you. Indeed, they’d probably honestly believe
what they were telling you. Rather, the problem is that most wouldn’t have a clue what
they’re really talking about.
The difficulty in trying to define EA begins with the term “architecture.” If you were to
look at the construction industry, you’d find very little confusion about what an architect
does. One can hardly imagine trying to build an office building, a new residential house,
or even adding a room onto an existing home, without first procuring the services of a
professional architect. It’s pretty clear to everyone involved in the construction business
what an architect does and why builders need one. Similarly, I seriously doubt there’s
much controversy, if any, regarding what kind of work is performed by a landscape
architect.
If, on the other hand, one were to ask a dozen different IT architects to define
“architecture,” they’d probably wind up with at least two dozen different definitions.
Much of this confusion stems from the fact that so many different job titles include the
term “architect.” Besides enterprise architecture, there’s software architecture, network
architecture, security architecture, data architecture, information architecture, systems
architecture, storage architecture, hardware architecture, computer architecture,
application architecture, technical architecture, service-oriented architecture, plus who
knows how many more!
Copyright © 2007 Flashmap Systems, Inc.
1
What is EA?
At its core EA is the bridge between business and technology. It’s EA’s job to translate
internal and external technology forces so that business managers can anticipate and
prepare for future changes that might affect business processes. In other words, EA helps
place IT squarely where it belongs: in the hands of business executives under whose
direction it can create the most value, thereby helping to ensure alignment of IT
capabilities with the needs of the enterprise.
Harnessing EA can produce massive business benefits -- not the least of which involves
innovation -- by guiding the integration, design, construction, deployment, and
management of IT solutions through principles, policies, standards, and models that
reflect business strategies, requirements, and constraints.
Disruptive Innovations
IT investments can help businesses achieve competitive advantage, especially at
companies where IT is recognized as a major part of a firm’s product or brand, or where
information technology is used to create the kind of disruptive innovation that results in
massive industry change. For example, look at Wal-Mart’s phenomenal success. They
are the world’s largest retailer today largely because of how they have effectively
deployed IT in a manner that has redefined the industry’s whole concept of supply-chain
management. Similarly, consider manufacturing firms. Can you imagine any company
larger than a Mom & Pop operation trying to run a modern-day factory without
IT-enabled ERP? How about sales and service? What kind of business nowadays isn’t
heavily dependent on IT-enabled CRM?
Then there are whole new IT-enabled markets.
Companies such as Amazon and eBay have totally
revolutionized consumer buying patterns. Google has
almost single-handedly transformed the entire
advertising industry.
The bottom line is that IT and innovation go together
like bread and butter. Moving forward, there will be
ever greater expectations for business and IT to work
more closely together to conceive, assemble, deploy,
operate, and enhance systems that are far better at engaging customers and delivering
improved results.
Rethinking IT Strategy
Most enterprises manage IT in just one way. In short, they primarily want to lower IT
costs while simultaneously increasing support for business growth. The most common,
Copyright © 2007 Flashmap Systems, Inc.
2
time-tested modus operandi for managing IT has been to cut costs during rough times and
fund projects when business is good.
Unfortunately, many IT organizations are in a deep malaise. They’ve been focused since
the beginning of the millennium almost exclusively on cost control. For far too long,
they’ve been conditioned to expect their performance targets to be continuously raised
and their overall budgets and headcounts to be cut. As their organizations have
downsized, rationalized, outsourced, and offshored -- all in a never-ending quest for
savings -- their IT management teams have become increasingly thin and homogeneous.
Worst of all, most remaining managers are expert at executing the last generation of IT
activity. The bulk of their time, work, attention, and funding has gone to “problems”
rather than to “opportunities.”
The hallmark of IT used to be that of an innovation enabler. But, today, IT is more often
than not seen as a barrier, slowing the pace of innovation. On the other hand, because the
IT industry is currently facing major discontinuities, now may be the perfect time for
businesses to once again consider using information technology to innovate. Today more
transistors are being produced annually than grains of rice -- and at a lower cost. There
already exists in the world over 2 billion mobile phones and almost 1 billion PCs.
Business executives would like their enterprise IT systems to be no less user-friendly
than iPods or digital cameras. Yet, most business managers feel the technology they have
at home is far better, faster, and cheaper than what they experience in the office.
Innovation was once the cornerstone underlying information technology. But ever since
Y2K, and then the dot com bomb, enterprise IT innovation has pretty much stagnated.
Nevertheless, technology has continued its inexorable march forward with ever more
transistors on a single chip -- now delivering multi-core microprocessors that combine
two or more independent processors onto a single integrated circuit (IC); ever more
bandwidth -- both wired and wireless -- at pennies per gigabit per second; and ever more
storage at costs that approach a billionth of a cent per byte. As George Gilder pointed out
in his October 2006 Wired Magazine article entitled The Information Factories:
“The recent explosion of hard disk storage capacity makes Moore's law look like
a cockroach race. In 1991, a 100-megabyte drive cost $500, and a 50-megahertz
Intel 486 processor cost about the same. In 2006, $500 buys a 750-gigabyte drive
or a 3-gigahertz processor. Over 15 years, that's an advance of 7,500 times for the
hard drive and 60 times for the processor. By this crude metric, the costeffectiveness of hard drives grew 125 times faster than that of processors.”
Looking ahead, at the present time, at least three major technological trends are
combining together to create the new next-generation IT platform. The goal of these
three technologies is to deploy and better assure the interoperable performance of
technologies, systems, information, people, and processes.
Copyright © 2007 Flashmap Systems, Inc.
3
#1: AJAX
AJAX is that part of Web 2.0 that will absolutely, positively have a significant
impact on IT. Microsoft has enthusiastically jumped onto the AJAX bandwagon.
For instance, check out how they have drastically redesigned their company's
home page www.microsoft.com by using AJAX to dynamically load content
when the user clicks on items in the floating menu to the right of the page.
Dynamically loaded content gets displayed in a floating panel that appears over
the top of the rest of the page, which gets dimmed and cannot be clicked while the
panel is visible.
To the user the interface is the system!!!
AJAX provides the rich client behavior that was so predominant before Web
browsers became popular. With AJAX, gone is the notion of constantly having to
refresh an entire web page for each transaction. With dynamic reloading of
portions of web pages, transmitting only a small amount of data to the client, the
resulting user experience is faster, richer, and arguably better in terms of
functionality.
Google has long been an ardent AJAX supporter. For example, see Google Maps
(maps.google.com) which enables users to drag a map to move it in various
directions, or Google Suggest (www.google.com/webhp?complete=1) which
provides suggestions from the server as users type, showing in a drop-down box a
list of search terms that may be of interest.
Invest in AJAX. Rich clients are worth it. Historically, display terminals like
IBM 3270s displaced keypunch machines. Character-based terminals like DEC
VT100s displaced 3270s. Character-based PCs with memory-mapped I/O like
MS-DOS displaced VT100s. Graphical user interfaces (GUIs) like Windows
displaced MS-DOS. GUI browsers like IE (or Firefox) displaced PC-based GUI
apps. AJAX is the next major user interface revolution and it’s happening now!
# 2: Service-Oriented Architecture
Microsoft, IBM, HP, Oracle, SAP, BEA, and just about every other software
vendor are all now singing the same exact tune -- that SOA represents their
next-generation IT development and deployment strategy. Of course, the $64,000
question still remains “What's a service?”
An effective, functioning service-oriented architecture requires the ability to share
services across multiple business units and enterprises. This demands
orchestration between services as well as governance. Otherwise, you end up
with just a bunch of services and a spaghetti-oriented architecture.
Copyright © 2007 Flashmap Systems, Inc.
4
The software industry has been promising reusable components ever since the
invention of subroutines. The problem invariably boils down to the age old
dilemma of how does a developer “find” a software module to be reused. If
the process of discovery takes as long as creating entirely new software, the
developer always opts for the latter, especially if the reusable software is
perceived as being unlikely to handle 100% of the requirements for the new task
at hand.
Software reuse -- whether we're talking a service, a component, an object, a
module, a subroutine, a macro, or whatever -- is always, in fact, a two-part issue:
1) finding the software to be reused; and 2) being able to modify the software to
handle non-generic special cases. The first challenge is one of figuring out how
to organize, classify, and categorize the software to be reused so that it can be
readily found. The second question involves supporting techniques for either
adding new functionality to software to be reused, or overriding existing
functionality.
Fundamentally, SOA's success will largely depend on evolutionary advancements
that can extend software components beyond SOA's predecessor technology,
object-oriented programming. The big breakthrough that SOA delivers is in the
way that it uses the Internet's underlying Web infrastructure in place of OO's
CORBA and DCOM object request brokers. XML is the key enabling
technology that makes all this possible.
One of the keys to building successful SOA-based systems is to exploit the
abstract semantic relationship that reflects the continuum between generic and
specific. In other words, SOA needs to allow developers to create generalpurpose building blocks that can easily be extended to handle special cases. This
is accomplished by supporting mechanisms for developers to add new
functionality or override existing functionality.
Another critical aspect of SOA pertains to business process modeling. Whereas
services represent the core components of SOA, developers still need to be able to
find those services in order to reuse them. It just so happens that the most
reusable facets of any information system are its business events. A specific
business event triggers a business process which itself is a set of distinct steps,
some of which must be performed in sequence, others of which may be able to be
performed in parallel. Furthermore, some process steps are conditionally
performed based on the results of prior activities. One key to SOA's success
depends on its ability to organize, classify, and categorize services based around
business events (so that those services can be easily discovered).
#3: Cloud Computing
Servers reside in an Internet cloud somewhere and it doesn't matter when you
access the cloud whether you have a PC or a Mac or a Blackberry or a cell
Copyright © 2007 Flashmap Systems, Inc.
5
telephone or whatever. Nowadays this notion of cloud computing is often being
referred to as SaaS which stands for Software as a Service.
The pendulum in computing relentlessly swings back and forth between personal
and shared machines. The very first computers, such as ENIAC, were single user
systems. Those computation workhorses were soon followed by sharable
mainframe computers like IBM's System/360. Next came minicomputers from
companies like DEC which were, once again, primarily single-user systems.
Soon, however, minicomputers became much more powerful enabling them to be
shared by multiple different users simultaneously, where each user had his or her
own virtual machine, and the shared resources were controlled by a sophisticated
operating system such as UNIX or VAX/VMS (or various other derivatives of
MIT's Project Multics). Minicomputers, though, soon were made obsolete by
personal computers which gave each virtual machine user their own physical
machine to control. But, PC users still wanted to share data and resources just as
they had previously been able to do on their shared systems. That demand led to
the advent of client/server computing. The ultimate winner in the client/server
war was the World Wide Web which itself is evolving into cloud computing
especially as behemoths such as Google and Microsoft build massive data centers
with massively parallel processing capabilities constrained only by their ability to
find enough electricity to power their truly amazing infrastructures.
Architect Now
Companies ought to transform themselves from IT cultures driven by cost and quality
control to enterprises that can profit from creative IT thinking. Designing innovative IT
architecture requires visionary talent. Success depends on turning architecture into a core
methodology of innovation. This requires learning how to communicate complexity by
simplifying and synthesizing.
In most enterprises it’s the architects who will be the people responsible for bridging the
chasm between the cultures of business and technology. It will be their job to educate,
inspire, cajole, hire, bribe, punish, build -- all to transform their companies' cultures. To
succeed they’ll need to tear down silos, mix people up, bring in outside change agents,
stimulate people's minds, and generate a diversified portfolio of promising ideas. Their
mission will be to redefine the whole meaning of the term “application” to where
businesses depend on services that are combined, mixed, matched, mashed and reused as
needed.
Innovation means implementing new ideas that create value. The innovation process
must start with business executives who can clearly understand, and then articulate, the
directions where they want their organizations to go. Additionally, these business leaders
need to be able to communicate goals to their IT management teams. Further, both the
executive and IT management teams need to know how to apply their enterprise's vision
to the specific plans, programs, people choices, projects, responsibilities, and
accountabilities that will enable the growth that they seek. Finally, both sets of leaders
Copyright © 2007 Flashmap Systems, Inc.
6
have to possess the execution focus and discipline that’s needed to turn their plans into
reality. Delivering long-term success depends on both these two groups -- business and
IT management teams alike -- being able to develop relationships based upon credibility,
understanding, and trust.
The overriding goal of enterprise architecture is to allow an organization to think about
and manage technology in precisely the same way that it currently knows how to think
about and manage money, people, and property. EA’s role in bridging the gap between
business people and technology people is to enable these widely divergent audiences to
all share a common vision and a common vocabulary. EA tackles the challenge of
establishing a common set of expectations by addressing four separate architectural
components:
1.
2.
3.
4.
Business Architecture
Data Architecture
Application Architecture
Technology Architecture
Business Architecture
Business architecture is based on the logic of rational organization and production.
Rationalization works by applying scientific management to the creation of defined,
quantifiable, repeatable production and organizational processes. Almost every facet of
modern industry takes some quantifiable process, maximizes it for efficiency based on a
distinct division of labor, with defined inputs and outputs, and then manages it based on a
rules-bound bureaucratic structure.
There are two key challenges facing the enterprise architect who tries to define the
processes and workflows that constitute an organization’s business architecture. The first
involves avoiding the quagmire of quicksand which can result from diving too deeply
down into process details. Business process modeling tools -- often based on graphical
UML (Universal Modeling Language) diagrams -- make it far too easy for architects to
create massive, intricate models that can often obscure effective communication with
non-technical business audiences. While it’s true that comprehensive, complex models
do indeed capture the richness of a business reality, and do provide a great learning
environment for an architect, it’s unreasonable to expect a busy manager to pore over a
convolution of graphical information in order to understand what’s actually happening
within their enterprise. Instead, what’s required is a high-level overview diagram that
serves the same purpose as an executive summary which summarizes all the other
sections of a long, complicated report. An interested manager can always drill-down to
see more detailed views.
The second obstacle one wants to avoid when trying to define business architecture is
overemphasizing the importance of efforts such as ITIL (IT Infrastructure Library). The
problem here is that ITIL does not, by itself, describe EA. Rather, it deals with only a
small portion of an enterprise’s overall business architecture. A typical enterprise
Copyright © 2007 Flashmap Systems, Inc.
7
generally can be described using a high-level functional decomposition which breaks
down an organization into a business process view that can be represented as primary
layers. Generally, there are somewhere between five and ten different primary business
process layers. Each of these will themselves include multiple sub-processes, and each
sub-process may have as many layers as necessary to define the organization. One of the
primary business process layers will indeed be Information Technology, and ITIL may
well be used to model the processes surrounding IT services. For the vast majority of
organizations, though, the business processes supporting Information Technology are,
like other Corporate Services, less important than those that deal with Product
Development, Demand Creation, Sales, Production, Logistics, or Finance.
Data Architecture
Data architecture is a model mapping to critical business entities as well as relationships
among entities. In other words, for each real world entity, or “thing,” such as a
customer, a part, a supplier, etc., there exists a one-to-one correspondence between that
real world “thing” and a representation of that “thing” as it’s portrayed in the model.
Each of these “things,” or entities, includes descriptions of properties and behaviors.
Encapsulation hides implementation details about data, such as the distinction between
fields and operations (i.e., methods).
The data architecture models the relationships between instances of real-world entities.
These include one-to-one, one-to-many, and many-to-many relationships. Metadata
relationships, especially inheritance which distinguishes between generic cases versus
special cases, also need to be described. Composition is used to describe things made up
of other things.
Business executives need a cognitive roadmap to help them manage technology. They
need mental models which enable them to better understand and more intelligently
communicate about their enterprise’s most essential business entities. Business analysts
need to view information organized using multi-dimensional attributes that can be sliced
& diced or rolled-up & drilled-down. These operations allow data to be analyzed and
explored so that patterns and trends can be more readily identified and understood,
especially through facilitation of meaningful comparisons between various sets of related
data such as different business units, geographic regions, or time periods.
The beauty of the data architecture is its innate stability -- especially by comparison to
the business architecture which tends to be in a continual state of flux (e.g., business
architecture changes every time a reorganization takes place). The data architecture
models real-world things, like customers, parts, suppliers, contracts, employees, etc.
These things don’t tend to change very often. Enterprises may reorganize and reengineer
all they want. At the end of the day, a customer is still a customer; an employee is still an
employee; a supplier is still a supplier; etc.
Copyright © 2007 Flashmap Systems, Inc.
8
Application Architecture
Application architecture deals with the functional requirements of a software application
that delivers business value. In other words, think of it as the “what” in terms of the
functionality that gets delivered by executing software, encompassing the features,
feature sets, and user-centered clumps of functionality as might be expressed in a User’s
Guide or marketing brochure. It’s literally the architecture underlying the automated
services that support and implement functional requirements, especially the interfaces to
other systems and other applications. Application architecture describes the structure of
an application and how that structure implements functional requirements.
Application architecture is responsible for the combining together of portions of
processes with pieces of data into separate independent software. It defines the set of
API’s (Application Programming Interfaces) that enable application partitioning across
distributed computing platforms. It’s also responsible for the API’s that support
application integration across multiple systems.
There are various ways of partitioning processing that range from fat clients to thin
clients depending on how much of the code runs on the front-end versus how much runs
on the back-end. In between are various ways of handling interprocess communication,
some based on remote procedure calls, others based on object request brokers, and still
others that depend on asynchronous message transmission.
Service-Oriented Architecture (SOA) represents the next generation of application
architecture technology. SOA is the perfect platform for pervasive, massively distributed
computing because of how its middleware handles all partitioning and integration tasks as
well as provides full support for directory and security services on top of an industry
standard Internet-based Web infrastructure.
One of the great promises driving SOA is that application components can be loosely
coupled. This refers to a technique of designing interfaces across software modules in
such a way that greatly increases flexibility by reducing the risk that changes within one
module can cause unanticipated changes within other modules. Of course, a far more
important goal for businesses is to create loosely coupled processes that will depend on
services that can be combined, mixed, matched, mashed and reused as necessary, and
where each service need not be aware of others to operate successfully.
Perhaps the biggest benefit of loosely coupled software is the opportunity it creates for
businesses to define processes that can operate asynchronously. The reason why this is
so important is because a distributed system is significantly harder to build than a
monolithic one. The reality is that networks are never totally reliable, latency is never
zero, and bandwidth is never infinite.
Copyright © 2007 Flashmap Systems, Inc.
9
Technology Architecture
Technology architecture models technology portfolios. Technology portfolios refer to
past -- as well as projected future -- technology investments consisting of all the different
kinds of IT products, systems, and services an enterprise owns.
Beware: technology architecture is not an
inventory of assets. Asset management tools
are responsible for capturing, tracking, and
reporting on individual assets. Asset
managers not only can tell you how many of
some asset exists, but also where each asset is
located. Accountants need to collect this kind
of information in order to handle such tasks as
calculating depreciation. Technology
architecture focuses on classes of products -not instances of products. That distinction is
analogous to the difference between data and
metadata.
Presented in figure 1 is the three-layer, fourmodel ITscout Technology Architecture
Framework (see http://www.ITscout.org/).
The bottom layer corresponds to
Figure 1: ITscout Technology Architecture Framework
Infrastructure. While extremely expensive
and complex, by itself, infrastructure really doesn't do too much of anything. It just sits
there. Value is derived only after Applications get layered on top. Depicted as the
middle layer in the graphic, applications can either be developed or purchased. Of
course, regardless of whether they're built or bought, applications generate Data -- data
that yearns to be analyzed and mined for its business intelligence. That's the top layer.
EA Artists
Enterprise architecture that's not communicated does not add value. Success, in terms of
architecture, begins with communicating the right information to the right people at the
right time. This requires simple and easy access to architectural information.
Communicating information visually is especially important since over 70 percent of the
neurons in the human brain are dedicated to visual processing. The old adage that a
picture is worth a thousand words is probably a gross understatement.
In the real-world of construction where architects design buildings for a living, inordinate
amounts of time are devoted to communicating -- both with the consumers (i.e.,
customers/clients) and with the producers (i.e., developers, contractors, sub-contractors).
Initially architects produce drawings, or renderings, so that their clients can visualize
what they're buying, and actually see what's going to be built using their money. Then
the architects produce numerous, much more detailed drawings called blueprints that are
Copyright © 2007 Flashmap Systems, Inc.
10
shared with contractors and sub-contractors who will do the actual construction work.
Note that the client isn't expected to extrapolate what an eventual structure will look like
based just on the blueprints. Instead, they get to view sketches that are far more
meaningful and understandable to a non-technical person.
Enterprise architects can't just produce UML drawings, not if they want to convey
important information to business people. They must concentrate their focus on
communicating architecture to untrained users. Edward Tufte, an expert in the
presentation of informational graphics, explains that graphical excellence is the “welldesigned presentation of interesting data that communicates complex ideas with clarity,
precision and efficiency by providing the viewer the greatest number of ideas in the
shortest time, with the least ink, and in the smallest space.”
Presented below in figures 2 and 3 are a couple of examples of EA artistry taken from the
ITscout Technology Architecture Framework. These diagrams convey descriptions of
extremely complex topics, yet the presented information can be readily understood by
non-technical business executives.
Figure 2 presents a picture that graphically describes the Business Intelligence Roadmap
(for more detail, see http://www.ITscout.org/). The top red surface of the 3-D cube
represents data. It shows how data can be captured from either internal or external
database sources. Once captured, the data undergoes a three-stage process called ETL
which stands for Extract, Transform, and Load. After processing, BI data resides in
either data warehouses or data marts. Furthermore, the data undergoes various checks to
test for data quality.
The two side-by-side surfaces
facing front in the 3-D cube
describe the various categories of
products that are used for analyzing
BI data. The green surface on the
left side describes tools used for
query & reporting, data analysis,
data visualization, or data mining.
The blue surface on the right side,
labeled analytics, corresponds to
software available as commercialoff-the-shelf (COTS) packaged
solutions.
Figure 2: ITscout Business Intelligence Roadmap
Copyright © 2007 Flashmap Systems, Inc.
The bottom portion of the diagram,
depicted by the porthole-shaped
yellow portals (below the 3-D
cube), signifies how most business
people access their BI tools and
data using browser-based portal
11
products that aggregate and standardize access to systems, applications, products, and
data.
Figure 3 shows the visual graphic
depicting the Application Development
Roadmap (for more detail, see
http://www.ITscout.org/). Notice how
the outer enclosing yellow ring
represents life cycles. Alliteratively,
one first defines the requirements.
Next, they design, develop, debug, and
deploy the code. Lastly, they discover
what they got wrong. Then they start
the whole cycle all over again. This
illustration helps a viewer immediately
see how different categories of tools
are associated with each of the various
stages throughout the application
development life cycle.
Figure 3: ITscout Application Development Roadmap
The visual illusion that the inside
section of the picture tries to convey is
that of a three-bladed propeller spinning clockwise in a spiraling rotation. The red blade
labeled platforms refers to Java, Dot Net, and XML. The blue blade corresponds to
languages such as JavaScript, Java, C#, Basic, C++, or Perl. Lastly, the green blade
represents various categories of reusables relevant to the application development
process such as components, metadata, or repositories.
Not BS Artists
Over the past few years, many IT organizations have lost significant ground. Their IT
infrastructure, internal processes, architectural consistency, and applications portfolio
have fallen behind. The enterprise-wide understanding of what it takes to create IT value
has diminished.
EA provides IT with an opportunity to regain their management’s trust by demonstrating
that they understand the business and its context. To do so, enterprise architects ought to
mimic their counterparts in the construction industry. Those architects create two
different sets of drawings. One type includes the set of detailed blueprints that tell
builders how to construct whatever structure they’re building. The other set are sketches,
or drawings, which are renderings that convey to non-technical customers a conceptual
description they can readily visualize and understand.
Enterprise architects need to paint pictures that explain their enterprise’s business
architecture which executives can quickly understand and validate. Architects must
create cognitive models that map out for business people what their organization’s data
Copyright © 2007 Flashmap Systems, Inc.
12
architecture looks like. Similarly, they should visually illustrate how their company’s
application architecture delivers functionality that generates business value. Finally,
enterprise architects must develop a technology architecture that formally charts IT
assets. Managing IT functionality as a portfolio of valued assets provides the business
leverage of the future. Healthy stewardship requires tracking what’s been acquired,
purchased, built, licensed, or leased. It means managing life cycles from consideration to
retirement.
Innovative architecture does not mean instant perfection. Architecture will naturally
evolve over time. What's most important, however, is understanding that people need a
vision, along with a plan on how to get to that vision.
Summary
The question was posed, why is EA so important? The answer is that enterprise
architects, properly empowered, are able to make extraordinary, high-impact
contributions based on the models they construct, and subsequently communicate, to the
business people and technology people within their organization. Architects are in a
unique position to articulate their enterprise’s business capabilities -- the combination of
processes, systems, and people -- that serve as the fundamental building blocks for
achieving overall business objectives.
Invariably, EA may threaten the autonomy of individual business units. The challenge is
to strike the proper balance between centralized versus decentralized decision making.
This requires buy-in from many different stakeholders in order to achieve optimal
consistency, consolidation, and leverage across the enterprise. The goal is to persuade
everyone involved to embrace the architecture that best serves the enterprise overall in
implementing business strategy. EA provides the bridge that allows business strategy to
drive what capabilities are built, sustained, and jettisoned at the enterprise level, versus
those that are delegated to individual business units.
EA supports technology standards across the enterprise. That reduces IT complexity and
costs by increasing convergence, consolidating purchases, lowering training costs, and
enabling better mobility of technical staffers. EA improves collaboration among different
parts of the enterprise by sharing access to information across the organization,
eliminating duplication of effort, and globally addressing issues related to integration,
interoperability, and security. Additionally, because EA communicates and informs more
effectively, it increases an enterprise’s agility by facilitating quick responses to changes
in business strategy.
Enterprise architects must be highly regarded by technology workers. They must be
highly credible among business managers. They need to be really good at modeling, and
especially good at describing the “big picture.” The goal is always to simplify and
synthesize using architecture to communicate, at a high level, how the enterprise will
deliver the value established in its business strategy.
Copyright © 2007 Flashmap Systems, Inc.
13
Resources
•
•
•
•
•
•
•
ARR -- Architecture Resources Repository (www.ITscout.org/Architecture)
ITscout (www.ITscout.org)
Enterprise Architecture Executive Report, by Dana Bredemeyer and Ruth Malan,
Cutter Consortium, 2004, Vol. 7, No. 8
The Empowered CIO, by Bruce Rogow, Optimize Magazine, August 2006
(http://www.optimizemag.com/article/showArticle.jhtml?articleId=191204749)
The Information Factories, by George Gilder, Wired Magazine, October 2006
(http://www.wired.com/wired/archive/14.10/cloudware.html)
The Work of Edward R. Tufte (www.edwardtufte.com)
Tracking Core Assets, by Bruce Rogow, Optimize Magazine, April 2006
(http://www.optimizemag.com/issue/054/bm.htm)
Copyright © 2007 Flashmap Systems, Inc.
14