Business Architecture Scenarios
The following is a list of business architecture scenarios, as described in the OMG BASIG whitepaper Business Architecture Scenarios.
- SCENARIO> S01. Merger & Acquisition Planning & Deployment
- Scenario Overview
- Companies undergo mergers on a fairly regular basis. The typical merger or acquisition brings another company under the umbrella of another company. This may have a significant impact, such as two banks merging into one, or may be of a lesser impact where a conglomerate brings a related company under its wing. In either case, one company will need to merge redundant operations, financial functions, business units and other aspects of the enterprise with the newly acquired entity.
- Role of Business Architecture
- Merger and acquisition planning is an executive activity.
However, the operational inputs to these plans as well as the
activities that result from the invocation of these plans require
information about an enterprise's business architecture. This
includes identifying all aspects of a business that overlap with the
merged / acquiring entity so that management can articulate and
rollout a complete operational deployment plan.
Consider the merger of one insurance company with a property and casualty business being incorporated by a larger entity with many lines of business. All P&C functionality and operational capabilities, including the relationship between business unit components and IT components, must be identified for subsequent merger deployment.
- Merger and acquisition planning is an executive activity.
However, the operational inputs to these plans as well as the
activities that result from the invocation of these plans require
information about an enterprise's business architecture. This
includes identifying all aspects of a business that overlap with the
merged / acquiring entity so that management can articulate and
rollout a complete operational deployment plan.
- Elements of Business Architecture Involved
- The business factors that should be considered as part of the
business architecture in the merger and acquisition planning and
deployment scenario are as follows.
• Organizational capabilities (or functions) relating to the P&C business
• Organizational units that perform these capabilities
• All business processes related to the P&C business and supporting functions
• Business rules relating to the P&C business
• Common set of semantics used by P&C business
• Supplier / partners that extend the virtual enterprise in the P&C business
• All IT related assets that support the P&C business
In addition to the identification of the above elements of the business, management requires an enterprise map identifying the relationships of the above organizational elements.
- The business factors that should be considered as part of the
business architecture in the merger and acquisition planning and
deployment scenario are as follows.
- Scenario Overview
- SCENARIO> S02. Business Unit Consolidation
- Scenario Overview
- Significant functional redundancy or overlap exists in many
larger organizations. Consider a telecommunications that has emerged
from a series of acquisitions or other evolutionary steps. It may
have a dozen or more billing and service centers that service
overlapping customers and regions. Processes, semantics and systems
typically differ, which confuses and frustrates customers, drives up
business costs and drives down the ability to service those
customers.
Or consider the insurance company that has redundant sales, product management, policy management and claims units servicing the exact same customers. Such an organization does not know that it has multiple policies with the same customer and cannot leverage this information in its marketing or service efforts. These same factors make it either very difficult or prohibitively expensive to adjust to changes in customer profiles.
A third example involves the government agency that is running concurrent financial applications across various business units, making it difficult to obtain a single source of truth about a particular set of financial data. Each of these examples signifies how redundant business units and business functionality can result in major challenges to an enterprise.
- Significant functional redundancy or overlap exists in many
larger organizations. Consider a telecommunications that has emerged
from a series of acquisitions or other evolutionary steps. It may
have a dozen or more billing and service centers that service
overlapping customers and regions. Processes, semantics and systems
typically differ, which confuses and frustrates customers, drives up
business costs and drives down the ability to service those
customers.
- Role of Business Architecture
- Fixing processes, data or systems will not address the
aforementioned challenges because there are silos of problems that
need to be addressed holistically. The role of business architecture
in such a scenario is to enable management, architects and analysts
to visualize the redundancies and their impacts from a
cross-functional, cross-disciplinary perspective. This would include
governance structures and related risk and costs of continuing the
status quo. Business architecture would also support consolidation
option analysis and related benefits.
In addition, business architecture plays a role in driving the consolidation related changes back into IT, versus IT driving the changes back into the business units. In this example, business architecture would simulate various organization units, functional capability, business processes, information and related changes and use the retooled business architecture to drive consolidation requirements into the application and data architecture.
- Fixing processes, data or systems will not address the
aforementioned challenges because there are silos of problems that
need to be addressed holistically. The role of business architecture
in such a scenario is to enable management, architects and analysts
to visualize the redundancies and their impacts from a
cross-functional, cross-disciplinary perspective. This would include
governance structures and related risk and costs of continuing the
status quo. Business architecture would also support consolidation
option analysis and related benefits.
- Elements of Business Architecture Involved
- The business factors that should be considered as part of the
business architecture in this scenario are as follows.
• Organizational units that are engaged in redundant behavior
• Functional capabilities that overlap
• Overlapping information semantics
• Redundant business processes running in the overlapping business units
• User views and user-based shadow systems involved in the redundant processes
• Mapping of business architecture artifacts to redundant data structures and applications within the IT architecture
- The business factors that should be considered as part of the
business architecture in this scenario are as follows.
- Scenario Overview
- SCENARIO> S03. New Product & Service Rollout
- Scenario Overview
- Organizations roll out new products and/or services on a regular
basis. The impact of these rollouts is difficult to predict and
typically result in costly coordination or, worse, missteps.
Consider an insurance company that must rollout a new insurance
product across multiple regions. Such an effort typically crosses
multiple business lines, teams, disciplines and even organizational
boundaries.
A new product or service launch typically begins with market research, design, engineering, rollout planning and eventually the actual rollout itself. While some large organizations may have this process well established, many others do not. Even in situations where companies have a repeatable process, not all of the pieces always come together.
A typical scenario begins a product or service launch plan by engaging marketing, product design and other key players. In many cases, the launch plan would need to engage multiple internal business lines but also external suppliers or business partners. The plan also typically must engage IT. Product launches and other business plans have either been delayed or derailed because of inadequate IT engagement.
- Organizations roll out new products and/or services on a regular
basis. The impact of these rollouts is difficult to predict and
typically result in costly coordination or, worse, missteps.
Consider an insurance company that must rollout a new insurance
product across multiple regions. Such an effort typically crosses
multiple business lines, teams, disciplines and even organizational
boundaries.
- Role of Business Architecture
- In a new product / service rollout, every critical aspect of a
business must be engaged at the appropriate point. In the above scenario, this would include product management, policy management,
marketing, sales, billing, service support, distribution partners,
IT units and a variety of other potential aspects of the enterprise.
Without a business architecture visualization of how the main elements in this scenario link back to the concept of a product, much of the work is either recreated every time a launch is planned, mapped out on paper and not maintained, or done haphazardly resulting in inefficient and ineffective launch results. Business architecture visualization can provide this mapping.
- In a new product / service rollout, every critical aspect of a
business must be engaged at the appropriate point. In the above scenario, this would include product management, policy management,
marketing, sales, billing, service support, distribution partners,
IT units and a variety of other potential aspects of the enterprise.
- Elements of Business Architecture Involved
- The business factors that should be considered as part of the
business architecture in this scenario are as follows.
• Organization unit and functional capability identification and mapping
• Mapping of products and services to organization unit
• External suppliers / partners involved in a given product / service
• Processes engaged in a given product / service support role
• User interfaces and shadow systems used by those processes
• Information about a product / service that is impacted by a new rollout
• Relevant projects that may be impacted across business and IT
• Mapping between above business artifacts to impacted applications, data structures and other aspects of the IT architecture
- The business factors that should be considered as part of the
business architecture in this scenario are as follows.
- Scenario Overview
- SCENARIO> S04. Introduction of a New Line of Business
- Scenario Overview
- Introducing a new line of business requires coordination across
a variety of business lines and IT functional units. Consider a scenario where a bank wants to move into a personal lines business,
either through expansion or acquisition. Such a move would need to
consider where current business units, functions, processes and
information may be leveraged and where unique infrastructure would
need to be established.
Such an assessment and selected leveraging of existing assets is rarely done. On the contrary, many organizations across a variety of industries have a tendency to clone an existing business unit, functionality and IT environments and then customize these assets to fit the new business. This has typically resulted in a suboptimal solution.
For example, consider the health insurance provider that added a life and disability line to their portfolio. The life and disability lines were driven through existing health insurance business units, business processes, information models, systems and data architectures. This company spent the better part of a decade working around inadequate business processes and missing information, driving up operational costs and driving down policyholder satisfaction. This could have been avoided had this company visualized and integrated the new product line into the business and IT architectures using more systematic approaches.
- Introducing a new line of business requires coordination across
a variety of business lines and IT functional units. Consider a scenario where a bank wants to move into a personal lines business,
either through expansion or acquisition. Such a move would need to
consider where current business units, functions, processes and
information may be leveraged and where unique infrastructure would
need to be established.
- Role of Business Architecture
- Business architecture can play an important role in line of business rollout. Understanding where current functional capabilities, organizational units, processes and information can be leveraged in support of this new business unit is the first step. The second step would involve simulating the impact of the introduction of this new line of business on existing infrastructures and determining where that infrastructure needs to be augmented. Finally, the business / IT architecture alignment strategy would be based on visualization and simulation of the projected impacts of this new line of business on business architecture artifacts and corresponding IT architecture artifacts.
- Elements of Business Architecture Involved
- The business factors that should be considered as part of the
new line of business scenario are as follows.
• Business units and functional capabilities impacted by or that could be leveraged by the new line of business
• Cross-functional business processes requiring modification to support new line of business
• Information to be modified or added to support new line of business
• IT architecture artifacts that need to be updated or added based on business architecture mappings
- The business factors that should be considered as part of the
new line of business scenario are as follows.
- Scenario Overview
- SCENARIO> S05. Consolidating Suppliers Across the Supply Chain
- Scenario Overview
- Suppliers and business partners touch many aspects of the
enterprise. This includes the outsourcing of services as well as the
supplier of products and materials. The services outsourcing sector
has expanded over the years and many organizations tend to buy
multiple services from multiple sources. In some cases, several
lines of business may utilize the same supplier or several suppliers
for the same thing. In one case the enterprise may be suffering high
costs or discontinuity from a single provider. In the second case,
high costs and discontinuity may stem from redundant supplier
relationships.
Consider a telecommunications firm that uses many sources of customer support services. In one actual situation, a business was contacted 6 separate times by 6 separate support centers to say that a services contract had been inadvertently modified. Each unit had access to different records and was apparently using different systems. There was no way to correct this according to the service center representatives. This organization needed a map of what was going on with service support centers.
- Suppliers and business partners touch many aspects of the
enterprise. This includes the outsourcing of services as well as the
supplier of products and materials. The services outsourcing sector
has expanded over the years and many organizations tend to buy
multiple services from multiple sources. In some cases, several
lines of business may utilize the same supplier or several suppliers
for the same thing. In one case the enterprise may be suffering high
costs or discontinuity from a single provider. In the second case,
high costs and discontinuity may stem from redundant supplier
relationships.
- Role of Business Architecture
- Extending the visualization of governance structures, which
include organization units and functional capability mappings,
beyond the walls of the enterprise creates a virtual view of the
business architecture. In the above scenario, a business
architecture visualization map would need to be extended to include
the customer service functional capability and all internal and
external suppliers that provide this function.
In addition, the organization should be able to visualize the overlapping or redundant processes, information, products, systems and data that are used by these organization units. Once this visualization is in place, management can establish a strategy to standardize, streamline and even consolidate these complexities to drive down costs and increase customer service.
- Extending the visualization of governance structures, which
include organization units and functional capability mappings,
beyond the walls of the enterprise creates a virtual view of the
business architecture. In the above scenario, a business
architecture visualization map would need to be extended to include
the customer service functional capability and all internal and
external suppliers that provide this function.
- Elements of Business Architecture Involved
- The business factors that should be considered as part of the
business architecture in this scenario are as follows.
• Internal and external business units that support the functional capability called customer service
• Extended business processes supporting this capability within each organization unit
• Information unique to this support function
• IT architecture artifacts that map to each organization unit, process and information required to support customer service
- The business factors that should be considered as part of the
business architecture in this scenario are as follows.
- Scenario Overview
- SCENARIO> S06. Outsourcing a Business Function
- Scenario Overview
- Assume a manufacturing company wishes to outsource its
purchasing function. This would require management to understand
where purchasing is performed. This company will need to determine
requirements, move those requirements, processes and related
information to an outsourced vendor, and then deactivate those
purchasing functions within each of the business units performing
those functions.
Assuming that purchasing is performed in a highly distributed fashion, it may be difficult to see where this should occur without an architectural view of the business. Failure to do so would result in splintered purchasing, replicated functionality and high implementation costs. Note that this scenario is tied closely to the concept of business process outsourcing (BPO).
- Assume a manufacturing company wishes to outsource its
purchasing function. This would require management to understand
where purchasing is performed. This company will need to determine
requirements, move those requirements, processes and related
information to an outsourced vendor, and then deactivate those
purchasing functions within each of the business units performing
those functions.
- Role of Business Architecture
- The role of business architecture in this scenario is to provide rapid analysis input into where purchasing is performed organizationally, how processes differ or are the same across functional silos, which information is used and how IT supports this purchasing environment. In addition, business architecture should support the aggregated views of purchasing and the simulation of what would need to change if purchasing was consolidated into a new, eternal organization unit.
- Elements of Business Architecture Involved
- The business factors that should be considered as part of the
business architecture in this scenario are as follows.
• All organization units linked to the purchasing functional capability
• A map to the business processes used by these organization units that support or impact purchasing
• The purchasing information used by each of these units
• A link between the above business architecture artifacts and related IT artifacts
- The business factors that should be considered as part of the
business architecture in this scenario are as follows.
- Scenario Overview
- SCENARIO> S07. Divesting a Line of Business
- Scenario Overview
- Consider an insurance company that plans to divest its personal lines unit. All organization units, processes, systems and data structures impacted by such a move would need to be identified so this could be done very systematically. The impacts may not be clear without a map of the business architecture and the ability to visualize what decoupling and divesting a line of business entails and how it impacts various aspects of the business ecosystem.
- Role of Business Architecture
- Divesting a line of business requires identifying all functional capabilities that support that line of business and making the appropriate changes to the organization units, processes and information to be deactivated. A business architecture map showing these relationships would provide the basis for planning this deactivation effort. In addition, planners could build simulation models to determine the impact or ripple effects on other internal or external organization units.
- Elements of Business Architecture Involved
- The business factors that should be considered as part of the
business architecture in this scenario are as follows.
• All organization units linked to the personal lines functional capability
• A map to the business processes used by these organization units that support or impact the personal lines business
• The policyholder or other information used by each of these units
• A link between the above business architecture artifacts and related IT artifacts
- The business factors that should be considered as part of the
business architecture in this scenario are as follows.
- Scenario Overview
- SCENARIO> S08. Change Management
- Scenario Overview
- One more general and ongoing challenge organizations face is the
ability to react effectively and efficiently to changes in external
and internal enterprise dynamics. Many of the business architecture
scenarios contained herein reflect support for specific types of
strategic change within an enterprise, but change is an ongoing
phenomenon that occurs at varying degrees of scale.
An example of this scenario might involve a response to a regulatory requirement to engage all suppliers of a given material from certain regions in order to add a surcharge to that material. The impact of such a change would ripple through purchasing, planning, accounting and other areas. It would also impact IT data and systems environments. For a large, diverse organization or one with several divisions, such a situation could involve major coordination.
- One more general and ongoing challenge organizations face is the
ability to react effectively and efficiently to changes in external
and internal enterprise dynamics. Many of the business architecture
scenarios contained herein reflect support for specific types of
strategic change within an enterprise, but change is an ongoing
phenomenon that occurs at varying degrees of scale.
- Role of Business Architecture
- The role of business architecture in a change management scenario is to allow managers and analysts to view a living blueprint of the enterprise, drill down into certain aspects such as information related to suppliers and simulate the implications of a change. As change is simulated, impacted lines of business, individuals, processes, information, suppliers and partners, and IT architecture artifacts can be engaged.
- Elements of Business Architecture Involved
- The change management scenario requires a drill-down capability
to determine specifics of a given change. Drill-down capability
indicates the management teams and related personnel that need to be
engaged in planning and executing a given change. Key business
architecture elements include:
• Internal and virtual organization units, linked to functional capabilities and information models
• Business processes used by these organization units that support or impact information involved in a given change
• Information artifacts as they are related to organization unit, functional capability and information models
• Granular drill-down views within the business and IT architectures
- The change management scenario requires a drill-down capability
to determine specifics of a given change. Drill-down capability
indicates the management teams and related personnel that need to be
engaged in planning and executing a given change. Key business
architecture elements include:
- Scenario Overview
- SCENARIO> S09. Regulatory compliance
- Scenario Overview
- Regulatory issues hit a wide variety of aspects within a given
enterprise and the impacts can have ripple effects. For example, a
change in a privacy law can impact multiple departments, information
models, processes and IT artifacts. Consider a situation where a
federal regulation states that organizations can no longer share a
social security number (or similar identifier in non-US
environments) with business partners, customers or certain internal
business units.
Under this scenario, an enterprise would need to establish a plan, engage relevant business units and partners, identify key documents, change impacted processes and establish a systems impact plan. Many organizations may consider this an IT related issue, but changes of this nature must be coordinated at countless levels across an enterprise. Specific policy aspects of the regulatory requirements must be mapped to various aspects of the organization in order to determine priorities and establish a phased deployment strategy.
- Regulatory issues hit a wide variety of aspects within a given
enterprise and the impacts can have ripple effects. For example, a
change in a privacy law can impact multiple departments, information
models, processes and IT artifacts. Consider a situation where a
federal regulation states that organizations can no longer share a
social security number (or similar identifier in non-US
environments) with business partners, customers or certain internal
business units.
- Role of Business Architecture
- Business architecture supports regulatory changes by providing
the high-level and drill-down map of impacted aspects and artifacts
of the business. An assessment effort would begin with a review of
enterprise governance structures, a foundational aspect of business
architecture. Business architecture provides the baseline for
mapping various policy aspects of the regulatory requirements to
impacted organization units, business processes, information and IT
artifacts.
One essential step in addressing such a regulatory compliance initiative would be to engage the relevant and affected parties to address the requirements and changes at a grass roots level. Organization units can engage in collaborative teams that organize around addressing common issues including information impacts and all aspects of the business that fan-out from that information. This requires a widely accessible map of the business that can be updated in real-time by teams across the enterprise as projects are launched and lessons are learned.
- Business architecture supports regulatory changes by providing
the high-level and drill-down map of impacted aspects and artifacts
of the business. An assessment effort would begin with a review of
enterprise governance structures, a foundational aspect of business
architecture. Business architecture provides the baseline for
mapping various policy aspects of the regulatory requirements to
impacted organization units, business processes, information and IT
artifacts.
- Elements of Business Architecture Involved
- Regulatory compliance planning and subsequent deployment
projects require mapping and tracking the evolution of the following
elements of business architecture.
• Internal and virtual organization units, linked to functional capabilities and information models
• Regulatory policies, mapped to various aspects of the enterprise
• Business processes used by organization units that utilize information linked to a given policy change
• Organization units, information, processes and other aspects of the business architecture mappings to IT architecture artifacts
- Regulatory compliance planning and subsequent deployment
projects require mapping and tracking the evolution of the following
elements of business architecture.
- Scenario Overview
- SCENARIO> S10. Operational Cost Reduction
- Scenario Overview
- The operational cost reduction scenario identifies opportunities
for streamlining the business. This scenario is characterized by
management requests or mandates to find areas within the enterprise
where resource spending can be reduced. This may include functional
realignment, process streamlining, organizational consolidation or a
variety of other factors. This may include user interface
inefficiencies that are intertwined with business processes and
user-developed shadow systems.
Consider a scenario where there is an operational unit of a telephone company that is responsible for scheduling service calls for commercial and residential customers. The overall business unit is seeking to put a spending ceiling in place. This means that no new people can be hired so the business environment must find a way to cap personnel resources while continuing to support a growth in volume.
This scenario is characterized by business-driven, front-line user incremental phases. Each incremental improvement must demonstrate business value. If it does, the solution can be expanded or replicated. If not, it can be replaced with a better approach.
- The operational cost reduction scenario identifies opportunities
for streamlining the business. This scenario is characterized by
management requests or mandates to find areas within the enterprise
where resource spending can be reduced. This may include functional
realignment, process streamlining, organizational consolidation or a
variety of other factors. This may include user interface
inefficiencies that are intertwined with business processes and
user-developed shadow systems.
- Role of Business Architecture
- This scenario drills down a view of the organization unit being
targeted for cost capping or cost reduction to determine the
processes, roles, shadow systems and user interfaces being used by
that particular organization unit. The planning stage quickly
determines the work required to approximate the percentage of cost
reduction or cost containment. Ideally, management can run a
simulation to project the amount of savings within a given business
unit and then across replicated business units as the situation
dictates.
The first level of implementation streamlines processes and concurrently eliminates shadow systems in favor of a new front-end environment. The resulting environment may only be a first level streamlining, where one or more shadow systems are eliminated, or may entail subsequent phases of streamlining. For example, a phase two approach may consolidate backend user interfaces into an automated front-end solution.
The second level of implementation replicates proven solutions into multiple overlapping or redundant business units. In this scenario, this involves replicating the operational solution across other areas that perform the same work, using the same processes. Additional phases of a cost reduction solution rolls up multiple first-cut solutions into more sophisticate, integrated architectures.
- This scenario drills down a view of the organization unit being
targeted for cost capping or cost reduction to determine the
processes, roles, shadow systems and user interfaces being used by
that particular organization unit. The planning stage quickly
determines the work required to approximate the percentage of cost
reduction or cost containment. Ideally, management can run a
simulation to project the amount of savings within a given business
unit and then across replicated business units as the situation
dictates.
- Elements of Business Architecture Involved
- The business elements involved in the cost reduction
scenario
include the following.
• Organization units that can be mapped to the functional capabilities requiring streamlining
• Business processes used by organization units targeted for cost reduction
• Shadow systems and user interfaces that can be streamlined in conjunction with the targeted business processes
• Additional organization units that map to the same functional capabilities targeted for cost reduction
- The business elements involved in the cost reduction
scenario
include the following.
- Scenario Overview
- SCENARIO> S11. Federated Architecture Alignment in Government
- Scenario Overview
- Federated architectures are commonly found in large, complex
government organizations with independent lines of business that
distribute administrative and IT functions among various agencies,
departments or ministries. Overlapping functionality, processes and
semantics across seemingly disparate, highly autonomous silos
provides challenges and opportunities in visualizing and aligning
complex organizational silos.
Federated architectural challenges include exposing tiers of architectural layers that allow management to plan and deploy a range of initiatives. This includes mapping and exposing relationships among lines of business, organizational sub-units, third parties, functions, processes, semantics and the technologies that support these aspects of the enterprise. In addition, a federated architecture must provide a means to perform cross-agency / cross-department streamlining, risk assessment, project prioritization, cost management and other alignment focused tasks. These requirements imply that the federated business architecture is coupled with cross-functional strategies, policies and other motivators.
- Federated architectures are commonly found in large, complex
government organizations with independent lines of business that
distribute administrative and IT functions among various agencies,
departments or ministries. Overlapping functionality, processes and
semantics across seemingly disparate, highly autonomous silos
provides challenges and opportunities in visualizing and aligning
complex organizational silos.
- Role of Business Architecture
- Business architecture must expose the cross-functional view of a
federated architecture that allows senior leaders to ascertain
various high-level and drill-down views of the business model and
operating environment. Business architecture must also provide a
mapping between the federated business architecture and related IT
architectures that span various lines of business.
Business architecture must also deliver visioning capabilities, including simulations of what-if scenarios, to enable the streamlining of the organization, functions, processes and related IT assets to reduce cost structures, enable critical services and enhance revenue opportunities. Finally, business architecture must facilitate the ability to see across and within federated architectural infrastructures.
- Business architecture must expose the cross-functional view of a
federated architecture that allows senior leaders to ascertain
various high-level and drill-down views of the business model and
operating environment. Business architecture must also provide a
mapping between the federated business architecture and related IT
architectures that span various lines of business.
- Elements of Business Architecture Involved
- Key aspects of business architecture within a federated
architecture environment include:
• Agencies, departments and / or ministries
• Lines of business across agencies, departments and / or ministries
• Functional capabilities, business processes and semantics
• Policies, regulations, laws and related motivators
• IT assets mapped to various business architecture artifacts
- Key aspects of business architecture within a federated
architecture environment include:
- Scenario Overview
- SCENARIO> S12. Business Transformation
- Scenario Overview
- Business transformation is a commonly used term that has been
adopted by the United States Department of Defense (DoD). Three of
the DoD business transformation objectives that are common to other
public and private sector enterprises are listed below.
• Enable rapid access to information for strategic decisions
• Reduce the cost of defense business operations
• Improve financial stewardship to the American people
This scenario, with certain shifts in topics, has broad applicability across a variety of industries. A strategy that focuses on improving decision making abilities, reducing costs and improving profitability through improved financial stewardship to constituents, stockholders or other stakeholders has universal appeal.
This scenario requires executives to turn key objectives into a series of pragmatic initiatives or programs that can be acted upon. Each of these initiatives provides a basis for solidifying the role of business architecture on the overall concept of business transformation.
- Business transformation is a commonly used term that has been
adopted by the United States Department of Defense (DoD). Three of
the DoD business transformation objectives that are common to other
public and private sector enterprises are listed below.
- Role of Business Architecture
- Generally speaking, business architecture facilitates decision
making through the cross-functional mapping between functional
capabilities, organizational units, business information, processes,
rules and related artifacts.
Business architecture facilitates cost reduction of business operations by highlighting cross-functional operational redundancies and inconsistencies that can be streamlined, rectified or eliminated. This includes a mapping to backend IT artifacts that are likely to perpetuate operational redundancies and inconsistencies.
Improving financial stewardship is typically envisioned to be an executive level responsibility. However if it is a key strategy, financial stewardship is best achieved by engaging business professional at all levels of the organization to seek out opportunities to deliver the most effective and efficient decisions with a focus on either decreasing costs or increasing revenues. Business architecture supports this through transparent governance that facilitates decision making related to financial stewardship across all aspects of the enterprise.
- Generally speaking, business architecture facilitates decision
making through the cross-functional mapping between functional
capabilities, organizational units, business information, processes,
rules and related artifacts.
- Elements of Business Architecture Involved
- Key aspects of business architecture that support business
transformation are as follows.
• Strategies, policies and major projects or initiatives
• Organization units mapped to functional capabilities
• Financial models or objects by organization unit
• Processes mapped across organizational units
• Mappings between customers, revenue goals, organization unit and processes
• Mappings between cost reduction goals and operational units
- Key aspects of business architecture that support business
transformation are as follows.
- Scenario Overview
- SCENARIO> S13. Global Transformation: Entering International Markets
- Scenario Overview
- Entering global markets requires the ability to expand the
enterprise model to incorporate new markets, regions, countries,
currencies and other aspects of global expansion. The impact on an
enterprise of entering global markets can be very far reaching.
Impacts must be anticipated in advance and incorporated into a plan
based on the ability of the management team to visualize the
cross-functional, cross-disciplinary impacts.
Global transformation is a long-term initiative that takes many forms. It may involve regional expansion into Europe or Asia or may involve a country by country strategy. Each major functional area is likely to feel some impact. Thsis is particularly true when it comes to systems, which may be customized or replicated to address international monetary, regulatory or other requirements. The key requirement for this scenario is to gain rapid visibility into the numerous aspects of the enterprise that are impacted by global expansion, including customers, partners and foreign governments.
- Entering global markets requires the ability to expand the
enterprise model to incorporate new markets, regions, countries,
currencies and other aspects of global expansion. The impact on an
enterprise of entering global markets can be very far reaching.
Impacts must be anticipated in advance and incorporated into a plan
based on the ability of the management team to visualize the
cross-functional, cross-disciplinary impacts.
- Role of Business Architecture
- Business architecture supports global transformation through the exposure of all business units and external entities that may be impacted by global expansion based on the functions these organization units perform. This requires full visibility of governance structures, functional capabilities, information, processes, customers and business partners. Business architecture should also provide the simulation capabilities to determine the impacts of moving into one country, region or continent; shifting to a new currency or metrics environment; or expanding into a worldwide business environment.
- Elements of Business Architecture Involved
- Key aspects of business architecture that support global
transformation include:
• Organization units, customers and partners
• Functional capabilities and business processes
• Information and related mappings to IT data architecture
• Customers and business partners
- Key aspects of business architecture that support global
transformation include:
- Scenario Overview
