Strategic Capabilities Architecture











PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The
reader is available for free
download
.

Strategic Capabilities Architecture

by Kirk Woodward

Docid: 00011239

Publication Date: 1703

Report Type: TUTORIAL

Preview

The passage of the Clinger-Cohen Act, along with changes in the nature of
IT operations, encouraged the development of a systematic approach to
enterprise architecture for timely and efficient responses to competitive
situations. A Strategic Capabilities Architecture (SCA) is an enterprise
infrastructure design that can enhance flexibility, adaptability,
growth, and responsiveness. It is a top level architecture, based on the
strategic goals of the enterprise, with elements that may include the use
of service-oriented architecture (SOA), data warehouses and data marts,
intranets and portals, virtualized resource schemas, mobile technologies,
federated databases, on-demand computing, Software-as-a-Service (SaaS),
and other enabling technologies.

Report Contents:

Executive Summary

[return to top of this
report]

The passage of the Clinger-Cohen Act, the increasing interrelation of IT
functions and corporate strategies, the iterative integration of
networked systems and applications, the rapid growth of social media and
mobile computing, and the growing economic pressures on the
enterprise have encouraged the development of an approach to systems
architecture that aims at positioning the technological structure for
timely and efficient response to competitive situations. The foundation of
this structure is a strong strategic design.

Service Oriented
Architecture Tutorial

A Strategic Capabilities Architecture (SCA) is an enterprise
infrastructure design that can provide flexibility, adaptability,
growth, and responsiveness within the enterprise infrastructure. Elements
of the implementation of the SCA may include the expanded use of
service-oriented architecture (SOA), data warehouses and data marts,
intranets and portals, virtualized resource schemas, federated databases,
on-demand computing, ASPs, Software-as-a-Service (SaaS), mobile devices,
online stores and business-to-business auction sites for both products and
services, and other enabling technologies. An organization may choose from
these and other options based on its strategic plan, which in turn should
be based on its perceived current and future needs.

In designing an SCA, the enterprise looks at its corporate goals; its
current and future strategic challenges; its current technological state,
with a particular emphasis on network capacity; the ability of its
technology to respond to market conditions; and the ability of its
infrastructure to absorb and adapt to technological and market change.

Description

[return to top of this
report]

Strategic Capabilities Architecture (SCA) is not a purchasable product or
a specific technology but a method for conceptualizing and configuring
the network infrastructure that allows the enterprise to operate
strategically and efficiently in its competitive environment. The core
concept behind SCA is that the operations of an enterprise should
reflect its strategic vision. An SCA, then, is not just an efficient
architecture; it is a strategic architecture, one poised to enhance
business operations to maximum advantage.

Implicit in an SCA is the fact that the network infrastructure of an
enterprise must have capacity sufficient to support the business
requirements of the enterprise, including future growth and expansion. As
a result an SCA may lead to restructuring of the network, to the purchase
of additional capacity, or both.

Certainly companies can and do create products and services that are
successful in the marketplace without reference to an SCA at all, through
luck, talent, and/or large investments of time and money. However, a
potentially more efficient approach is to implement an SCA through the
development of a business strategy, the translation of the business
strategy into a technical strategy, and the implementation of the
technical strategy as a foundation for competitive advantage.

Three important developments have contributed to the emergence of the SCA
and related approaches to network design. The first development is the
Clinger-Cohen Act (1996), originally titled the Information Technology
Management Reform Act, requiring that departments of the federal
government create integrated technological frameworks for their
technological functions, or, in essence, that they run their IT operations
the way a business ought to. This law provided the impetus for the
non-government enterprise to look at its technological operations in the
same integrated way, since the federal government began to apply the
concept to contract bidding, although it was not specifically
strategic in nature. 

The second development is an increasing awareness that “information
systems” are not merely technology but require integration with corporate
goals and strategic aims. Technology is increasingly viewed as a
continuation of corporate operations by technical means. Implicit in SCA
is the idea that information systems can be maximized for corporate
effectiveness in the marketplace.

The third development is the increasing integration of computer systems.
If the first era of computing is represented by the monolithic mainframe
computer, and the second era by the standalone personal computer, the
third era is represented by the network (including the Internet, the World
Wide Web, the cloud, Web-based, personally owned, and mobile products)
that connects disparate computer systems, applications, and programs.

These three developments have encouraged organizations to consider their
technological operations as parts of a coherent framework designed to
carry out the purposes of the enterprise. Organizations face a continuing
expansion in the range and capabilities of leading edge information
technology to support their missions. 

Many of these technologies offer reductions in cost and improvements in
the capabilities of existing technological solutions, although cost
reduction is not the first objective of strategic architecture. Some
technologies offer the promise of going even further by radically
changing, if not transforming, the ways missions are performed, and even
by redefining the nature of the mission itself. All of these applications
of leading-edge technologies represent potential opportunities for
the enterprise. Some of course may require increased investment.

The SCA focuses on creating a framework that enables the company to
compete in a competitive environment, with the aim of achieving any or all
of the following results:

  • Quickly
    respond to changing business, economic, and regulatory conditions
  • Rapidly
    implement new or changed strategic objectives
  • Achieve
    greater consistency across business processes
  • Improve
    time to market
  • Increase
    productivity
  • Reduce
    headcount
  • Build useful
    applications faster and at lower cost
  • Reduce
    spending on licenses, maintenance, and consulting
  • Reuse
    software that supports specific business functions across applications
  • Integrate
    applications built in heterogeneous environments
  • Gain
    competitive advantage

There is no standardized, authoritative list of elements that make up a
SCA, which as noted above is an approach rather than a purchasable
technology. A useful frame of reference is Enterprise Architecture (EA).
An EA is a long-range blueprint for cost-effectively managing and aligning
business processes, information needs, communications networks, people,
operations, information systems, data, delivery systems, and projects with
the organization’s overall strategy. It includes a transition plan
to move from the current architecture to the new architecture. 

The process calls for developing, implementing, and maintaining the
blueprint over time according to changes in business requirements and
technologies. One may think of SCA as an extremely flexible manifestation
of an EA. For the remainder of this article, where the functions of
the EA and SCA coincide, the terms are used interchangeably.

An EA is the enabler of the Strategic Capabilities Architecture, and is
made up of several components, including but not limited to Business
Architecture, Information Architecture, Data Architecture, Systems
Architecture, and Computer Architecture. Table 1 depicts the components of
an EA.

Table 1. Components of the Enterprise Architecture

Component

Description

Business Architecture (BA)

This is based upon the organization’s strategic vision of the
required current and future capabilities as defined by the SCA.

In essence, a Business Architecture takes into consideration
the business strategy of the company, its long term goals and
objectives, the technological environment, and the external
environment, as well as the interests of the various
stakeholders of the firm such as regulatory agencies, customers,
employees, stockholders, and so forth. It is composed of
architectures, workflows, and events.

It defines the formal link between the enterprise business
strategy and the results predicted from supporting strategic
initiatives.

Information Architecture (IA)

A conceptual framework used to describe the design and
organization of information, the content, functionality,
navigation, and usability of information systems, particularly
websites, knowledge management systems, and intranets, including
labeling and navigation schemes. Good information
architecture ensures that data is structured so that information
can be easily found by the user. An Information
Architecture is primarily a map of the overall information needs
of the firm, based upon the firm’s Business Strategy, that takes
the Data, Systems, and Computer Architectures into account.

Data Architecture (DA)

The DA follows from both the Information Architecture and the
Business Architecture, defining the framework for organizing the
enterprise’s current and future needs for data accumulation,
usage, renewal, maintenance, and transfer both within and
outside the firm’s boundaries.

Basically the DA aligns the various data requirements with the
business applications (Information Architecture level), the
systems-related protocols (Systems Architecture), and the
various hardware and software applications (Computer
Architecture level).

Systems Architecture (SA)

The SA is a description of the design and contents of a
computer system, and may include information such as a detailed
inventory of current hardware, software and networking
capabilities; a description of long-range plans and priorities
for future purchases; and a plan for upgrading and/or replacing
dated equipment and software.

It is primarily related to the Information, Data, and Computer
Architectures. 

Computer Architecture (CA)

The CA defines the structure and organization of a system’s
hardware and/or software, as well as specifications for the
relationship between the components. It sets the standard
for all devices that connect to it and all the software that
runs on it based on the type of programs that will run (for
example, business, scientific) and the number of programs that
run concurrently.

It is closely related to the Information, Data, and Systems
Architectures.

Depending on specific business requirements, there are other
architectures – Knowledge Management (KM), Federal Enterprise (FE), and
Communication, for example – that may come into play when implementing a
Strategic Capabilities Architecture. The point is that once the
desired or required current and future capabilities of the organization
have been defined and aligned with its strategic goals, the appropriate
enabling technologies may be selected and implemented to achieve them,
including:

  • Service
    oriented architecture
  • Data
    warehouses and data marts
  • Internet
    sites, intranets, and portals
  • Virtualization
  • Federated
    databases
  • On-demand
    computing
  • Software-as-a-Service
    (SaaS)
  • Social
    media
  • Mobile
    computing

The above table demonstrates that, regardless of terminology, the listed
components are all closely related to each other. As long as the
enterprise keeps the interrelatedness of the various architectures in
mind while developing the SCA, decisions related to modification of these
architectural components will be a far more organized and manageable
activity, and modification of one component may modify others at the same
time.

Current View

[return to top of this
report]

It is the nature of an organization to conduct numerous interrelated
activities in order to complete work and deliver value. A broad range of
information technologies enables these activities to take place, and in
the aggregate makes up the organization’s architecture(s). An SCA
is a way of making sense of these complexities and the relationships
and dependencies that exist between them.

Every organization has some sort of technical architecture, even if it is
only an “accidental” or basic standards-based one. It may underlie an
organization of hundreds of thousands of employees and billions of dollars
in sales, or one with a dozen employees and much more modest revenues.
Whether a corporate architecture is formally documented and understood as
such or not, it exists if the organization exists. It may, however, lack
the breadth and flexibility to qualify it as an SCA. For example,
the business may have defined standards (a necessary but not sufficient
condition for an architecture) such as:

  • A
    primary vendor: IBM, Microsoft, or Oracle
  • Desktop
    technologies, groupware systems for email and calendaring, and/or
    collaborative applications
  • Instant
    Messaging, desktop audio/videoconferencing, presence detection,
    white-boarding, application sharing, reporting/monitoring tools
  • Security
    applications
  • Groupware

At the same time, that same corporate architecture may lack the
conceptual framework and implementation plan that enables it to function
as an SCA. It may further lack a strategic focus. It has been estimated
that up to fifty percent of Global 2000 organizations lack an EA of any
sort, let alone one flexible enough to be called an SCA. A major hurdle is
contentment with the status quo, along with the view that architecture is
an ivory-tower playground for technicians and academics, as opposed
to a framework that ensures the alignment of business and
technology within the enterprise.

Sponsorship and commitment to architecture almost without
exception begin with sponsorship by the CEO or CIO, or if possible
both. Complacent cultures with few performance standards and a dearth of
visible crises are often perceived by those who lead the organization as
examples of “if it ain’t broke, don’t fix it”. This view is
misleading. In a world of rapid change, the benefits of an SCA/EA are both
real and significant.

If, among other examples, an enterprise wants or needs to embrace
wireless technology, set up an online store that integrates with its
physical counterparts (“click and mortar”), resolve a merger or
acquisition, implement new revenue streams (such as a fee-based download
of songs, TV shows, or movies), or comply with new legal or regulatory
standards, a well-designed SCA will enable this to be done relatively
quickly, cost-effectively, and painlessly, since such situations will have
been prepared for in advance.

The 1996 Clinger-Cohen Act required the US government to adhere to a
systematic IT process, with the result that “architecture” became a
critical input for governmental IT-related investment decision making. The
need to meet this requirement has had an obvious and positive effect on
SCA use in the vendor sector as well.

A difficulty in reporting the spread of Strategic Capabilities
Architecture is that companies may be reluctant to publicize their steps
in developing and implementing an SCA/EA. The artifacts produced are often
kept confidential, due to the belief that such exposure will give insight
to competitors. Unfortunately, such reticence may reinforce the
impression that there is small value in the implementation of an SCA.
However, the value of business process analysis is beyond question.

Primary examples of the thorough implementation of an SCA are Intel and
the United States Departments of the Interior and Defense. Among the
companies that have shared their architectural successes and failures at
the Digital Consulting Institute’s Enterprise Architectures Conferences
(no longer active) were Volkswagen AG, Intel, Intercontinental Hotels,
Nationwide, and the Oklahoma Department of Human Services. 

Software to assist in the analysis and design of business process is
available from a number of major vendors. IBM’s offering is its Rational
Enterprise Architecture suite, with System Architect, Asset Manager,
Software Architect, and Portfolio Management modules. Microsoft’s System
Center 2016 allows diagramming of business processes. (Microsoft in fact
describes its entire familiar suite of products as business process
software.) A sampling of products from smaller vendors includes the ARIS
Enterprise Architecture solution from IDS Scheer, which offers design
modeling views ranging from the broadest picture to physical and design
views. Modeling tools also are a specialty of Mega, and iGrafx
emphasizes the suitability of its modeling tools for manufacturing
companies.

Outlook

[return to top of this
report]

Going forward, SCA success will be determined by the extent to which
corporate and line-of-business managers comprehend, support, and enforce
the approach. Statistics show an increasing number of core architectural
teams that are moving from the IT organization to direct reporting of
either corporate strategy or corporate change management functions.
Estimates are that the primary expertise of close to half of enterprise
architects will be in business strategy or process engineering within this
decade. 

The concept of the SOA has occasionally been criticized as more an
intellectual than a practical exercise, often resulting in few benefits.
Nevertheless expanded use of service-oriented architecture (SOA), expanded
use of data warehouses, data marts, Intranets and portals, virtualized
resource schemas, federated databases, on demand computing,
ASPs, Web-based Software-as-a-Service (SaaS), and other enabling
technologies such as online stores and business-to-business auction sites
for both products and services can be confidently predicted. Organizations will choose from these and other options based on their
current and future needs. Table 2 lists enabling technologies.

Table 2. Enabling Technologies
Enabling Technology

Description

Service Oriented Architecture (SOA)

Essentially a collection of services which
communicate with each other. This communication can involve
simple data passing or two or more services coordinating some
activity. Such services are not necessarily tightly linked, but
share a commonality of communications means.

Service-oriented architectures are not new.
Historically, many in the past used DCOM or Object Request
Brokers (ORBs) based on the CORBA specification.

Data Warehouses and Data Marts

A database, or collection of
databases, designed to help managers make strategic
decisions about their businesses. While a data warehouse
combines databases across an entire enterprise, data marts are
usually smaller and focused on a particular subject or
department. Some data marts are subsets of larger data
warehouses.

Intranets & Web Portals

Intranets are private networks maintained by
corporations for internal purposes, using Internet/Web
protocols, software, and servers. They are relatively cheap,
fast, and reliable systems that can nevertheless link offices
around the world. They make it easy for corporate users to
communicate with one another, and to access the information
resources of the Internet.

Public web portals are Web sites or services
(for example, AOL, Yahoo, Google) that offer a broad
personalized array of resources and services, such as e-mail,
stock quotes, phone and map information, community forums,
search engines, and on-line shopping malls.

Business portals are designed to enable
collaboration in workplaces. Applications that reside on
multiple platforms – mainframe, PC, client-server – can be
accessed via a company portal. A further business-driven
requirement of portals is that their content be able to work on
multiple platforms such as personal computers, personal digital
assistants (PDAs), and cell phones.

Many corporate portals have adopted the
search engine style of content categories with a text-intensive,
faster loading page that visitors find easy to use and to return
to. Companies with portal sites have attracted stock market
investor interest because portals are viewed as able to command
large audiences and numbers of advertising viewers.

Virtualization

Virtualization is a means by which multiple
physical storage devices and CPUs are viewed as a single logical
unit. At its heart, it is a process of presenting computing
resources in ways that users and applications can easily get
value out of them, rather than presenting them in a way dictated
by their implementation, geographic location, or physical
packaging. In other words, virtualization provides a logical
rather than a physical view of data, computing power, storage
capacity, and other resources.

Virtualization is an approach that enables IT
to pool resources so utilization is optimized and supply
automatically meets demand.

Federated Databases

An integrated repository of metadata from
multiple, possibly heterogeneous, data sources. In a
federated or virtual database system, a client application can
use a single SQL statement to join data that is distributed
across multiple database management systems and can view the
data as if it were local.

In brief: a collection of databases are
treated as one entity and viewed through a single user
interface.

On-Demand Computing

On-demand computing is an increasingly
popular enterprise model in which computing resources are made
available to the user as needed. The resources may be maintained
within the user’s enterprise or, more typically, made available
by a service provider.

The on-demand model was developed to overcome
the common challenge to an enterprise of being able to meet
fluctuating demands efficiently. Because the enterprise’s demand
on computing resources may vary drastically from one time to
another, maintaining sufficient resources to meet peak
requirements can be costly. Conversely, if the enterprise cuts
costs by only maintaining minimal computing resources, there may
not be sufficient resources available to meet peak requirements.

Software-as-a-Service (SaaS) or Application Service Provider
(ASP)

Software that is rented (that is, outsourced) instead of
sold. The applications are delivered via a Web browser. This
delivery model speeds customer implementation, minimizes the
expenses and risks incurred across the application life cycle,
and overcomes the chronic shortage of qualified technical
personnel available in-house. This delivery model is becoming
increasingly popular with end users because they no longer have
to bear the direct cost of infrastructure, IT staff, and
operational issues such as application management, monitoring,
availability, disaster recovery, etc.

The two terms – ASP and SaaS – are often used interchangeably,
but SaaS is an evolution from the ASP model, differing in that
Independent Software Vendors (ISVs) now provide their own
applications as a service, rather than depending on a third
party to aggregate a selection of applications for use. SaaS
offerings also facilitate the delivery of fine-tuned and more
configurable offerings while ASPs tend to be more standardized
applications.

Hosted applications, such as the CRM
applications from Salesforce.com and Siebel (Oracle),
are experiencing triple digit annual growth, and deliver
applications on demand with a variable cost structure, such as
monthly billing or pay-as-you go options, similar to a power
utility. The cost for deploying, maintaining, and upgrading the
software is shared among all the clients.

It should be noted that SCA is not a panacea for all of the challenges
facing IT or the organization. It will, however, enhance the
organization’s ability to react more quickly to change, embrace new
business opportunities, and prioritize projects and investments.

Recommendations

[return to top of this
report]

Any organization that wants to leverage its electronic infrastructure in
order to achieve a competitive business advantage will want to consider
developing a Strategic Capabilities Architecture. This means first
defining an appropriate business strategy, then translating it into a
technical strategy, and finally implementing that technical
strategy. When an organization changes its business processes, the
impact of change can be assessed by identifying the components of the
enterprise architecture that will be affected. The organization can
quickly understand what needs to change, how to make the changes, and what
resources must be assigned to accomplish the change. 

Such change may not necessarily mean the implementation of an SCA.
Process improvements are important whether or not they lead to strategic
architectural restructuring.

However, if the result of strategic planning and analysis is to implement
an SCA, the following steps should be taken:

  1. Form
    a cross-functional team with representative stakeholders from across the
    organization to develop clear and concise guiding principles
    that will serve as filters for subsequent decision making and will
    eliminate inconsistencies with the organization’s goals and objectives.
  2. Define
    the scope and the mandate of the team, the expected benefits for the
    business, and the metrics to be used to measure success. 
  3. Appoint
    a champion to promote the effort throughout the organization. It is
    essential that this champion be a key member of senior management, for
    example, the CEO or CIO.
  4. Establish
    a cross-organizational steering committee. This governance body should
    consist of subject matter experts and senior leadership capable of
    representing the organization from both a business and a technical
    perspective, and with the authority to make architectural decisions.
    Architectural governance is a key element and relates to how an
    organization makes decisions, sets priorities, allocates resources,
    designates accountability, and manages its architectural processes. This
    group is responsible for reviewing products produced from EA efforts to
    ensure that they meet the goals of the SCA, for serving as the forum for
    resolving issues, and for providing inputs and updates to the SCA/EA.
  5. Document
    the models and standards to be implemented. Start by engaging the
    business stakeholders in the development of business architecture
    blueprints, then have technical architects work closely with them to
    document the mission, vision, goals, objectives, and business
    capabilities required to enable the business strategy. The result
    will be a set of linked architectural elements that clearly show the
    capabilities required to deliver business goals and objectives. In
    addition, business metrics should be identified and associated with each
    objective, providing a model that will be used to regularly measure the
    progress made. The modeling of current and future state versions of the
    operational dimension of the business architecture will allow architects
    to assess the impact a new strategy can have on current operations.
  6. Have
    IT develop its systems architecture, which describes in a
    platform-independent way the high-level applications, information,
    infrastructure, and interfaces that enable the strategic and operational
    business architectures. Such a model will link technical elements like
    applications and information with business capabilities, and will
    provide a common language for discussions between IT and the
    business. This is the level that describes the physical
    implementation of the applications, information, infrastructure, and
    interfaces, and identifies the specific products and protocols that
    will guide the implementation.
  7. Maintain
    documentation on architectural processes in an easily communicable
    format and an accessible location, since it is essential to keep the
    SCA well-documented, up to date, and available for access and use
    by stakeholders. When a solid SCA/EA is documented, stored, and updated
    within an EA tool, business users can quickly obtain clear answers to
    questions such as the impact in time and dollars of various proposed
    changes, and what information assets are available to reduce risk and
    cost while enabling shorter time to market for new products.
  8. Implement
    and use architectural metrics proactively as the basis for demonstrating
    the value of the architecture. Examples of metrics include the
    percentage of planned strategic capabilities achieved and the percentage
    of existing enterprise assets reused by a program. These help to
    quantify the return on architectural investments realized.

Once in place, benefits will grow out of the clear linkage between
business vision and technical architecture.

It is not necessary to define the entire SCA/EA before receiving
benefits. It is possible and often desirable to begin with small
manageable phases and to build the architecture incrementally. It
should also be kept in mind that the value of the architecture will
diminish rapidly if not maintained in a timely fashion.

[return to top of this
report]

About the Author

[return to top of this
report]

Kirk Woodward is a technical writer and project manager.
His areas of expertise include enterprise software, hardware systems, and
the use of Internet resources.

[return to top of this
report]