Business Architecture 

Business Architecture

The Business Architecture describes the product and/or service strategy, and the organisational, functional, process, information, and geographic aspects of a business environment.

A knowledge of a customer�s Business Architecture is a prerequisite for architecture work in any other domain (Information, Systems, Infrastructure), and is therefore the first architecture activity that needs to be undertaken, if not catered for already in other organisational processes (enterprise planning, strategic business planning, business process re-engineering, etc.).

In practical terms, the Business Architecture is necessary as a means of demonstrating the business value of subsequent architecture work to key stakeholders, and the return on investment to those stakeholders from supporting and participating in the subsequent work.

Business Architectures are as variable as the organisations that they represent. Describing an organisation in architecture terms therefore needs to be flexible. However there are commonalities that can be captured at a high level for classifications of the elements (or �components�) that comprise an organisation, and can be developed at an appropriate level of detail to meet specific contexts. An example is as illustrated:

1. The Organisation. The structure of an organisation, its capabilities, areas of operation, strategies and the rules (legislation, standards, governance and policies) under which it operates.
2. Functions. The functions performed by an organisation in delivering its capabilities that determine the information that is required to undertake those functions.
3. Processes. As they apply to the functions.
4. The extended enterprise. An organisation�s customers, providers, partners, parent organisation etc and the interdependencies between them and influences they have on an architecture.

Business Architecting is often applied as a practice in its own right. Frameworks for business architecture in an EA context include the Zachman Framework, The Object Management Group (OMG) Business Architecture Working Group, the Business Architecture Guild and the eXtended Business Modeling Language.

The Organisation

The relationships among roles, capabilities and business units, the decomposition of those business units into subunits, and the internal or external management of those units.Sometimes addressed as separate Business Architecture components, the following Views can be used to represent the Organisation within a Business Architecture:

Business Strategy: captures the strategic goals of an organisation. The goals may be decomposed into various tactical approaches for achieving these goals and for providing traceability through the organization. These strategic goals are mapped to metrics that provide ongoing evaluation of how successfully the organisation is achieving its goals.

Business Knowledge: establishes the shared semantics (e.g., customer, order, and supplier) within an organisation and relationships between those semantics (e.g., customer name, order date, supplier name). These semantics form the vocabulary that the organisation relies upon to communicate and structure the understanding of the areas they operate within.

Business Operations: defines the set of strategic, core and support operational structures that transcend functional and organisational boundaries. It also sets the boundary of the enterprise by identifying and describing external entities such as customers, suppliers, and external systems that interact with the business - the "extended enterprise"'. The operational structures describe which resources and controls are involved. The lowest operational level describes the manual and automated tasks that make up workflows.

Business Drivers are the factors in an industry or the broader business environment that either impact an organisation or provide opportunities for business expansion. The strategic goals set out the business priorities or initiatives designed to take advantage of those drivers.Technology initiatives identify the key areas of focus to provide the infrastructure and tools to support the business initiatives.

Functions

Business Capabilities describe the business functional abilities expressed via business services of an enterprise and the sections of the organisation that would be performing those functions. This view further distinguishes between customer-facing functions, supplier-related functions, core business execution functions and business management functions.

Business Capabilities, Business Services, Business Functions and Business Processes.

Understanding the differences will help an Enterprise Architect to develop an appreciation of current and future needs and opportunities for IT, and those aspects that may apply enterprise-wide vs those that are specific to particular parts of the organisation.

• Business Capability is the ability (current or potential) to perform a range of actions to achieve strategic goals.A capability can be used by more than one Business Function. Business Capability decomposes business by purpose.
• Business Services. An external view of the services an organisation provides or sells to its customers can be represented as Business Services.
• Business Functions focus on the existing activities that an organisation is performing and decomposes business by activity. Functions are business unit specific. Where Business Functions define the 'What', Business Processes define the 'How'. Business Strategies should define 'Why' and 'When'.

""Business processes describe the methods an organisation employs in order to provide and leverage business capabilities. Business functions describes the roles that individuals and units within the business play in regards to meeting business objectives."

Processes

An understanding of Business Processes within an organisation is indispensible to Enterprise Architecture. The purpose of ICT within any organisation is to contribute to the effectiveness of the functions carried out by the organisation in meeting its objectives and goals. Whether it�s the automation of manual tasks, process improvement or whole new ways of working, the deployment of ICT and its underpinning architecture(s) needs to be validated through qualified improvements to Business Processes, and the optimal architecture to do so also qualified against possible alternatives.

There are a number of related disciplines that EA can exploit to develop and represent a Business Architecture:

• Business Process Management (BPM) focuses on aligning all aspects of an organisation with the wants and needs of its clients. It promotes business effectiveness and efficiency while striving for innovation, flexibility and integration with technology. BPM attempts to improve processes continuously.
• Business Process Re-engineering (BPR) is a business management strategy focusing on the analysis and design of workflows and processes within an organisation. Information technology has historically played an important role in the reengineering concept.
• Business Process Modelling (BPM) in systems engineering is the activity of representing processes of an enterprise, so that the current process may be analysed and improved. The process improvements identified by BPM may or may not require Information Technology involvement.
• Business process mapping refers to activities involved in defining exactly what a business entity does, who is responsible, to what standard a process should be completed and how the success of a business process can be determined.

The Extended Enterprise

No organisation (or individual - the occasional hermit excepted) operates in isolation. They will have at least some of: customers, clients, suppliers, competitors, audience and/or partners. These entities interact, almost always using ICT, even if it's just a simple phone call (or more contemporarily, a tweet). Such a virtual grouping represents the extended enterprise, and it needs to be considered in the context of a Business Architecture.

The Internet is the great facilitator of interactions between related entities. Media-rich communications across integrated channels that provide for the sharing and protection of information across diverse channels and devices - the Internet, intranets and VPNs, cloud-based services and systems and public infrastructures.

Capturing the extended enterprise and the points of interaction arises from a complete identification of Business Functions. It will ensure that an enterprises entire ecosystem and the interdependencies and constraints are considered in design work.

Larger orgnisations will typically have multiple ICT providers - in-house and external. These providers support related domains, often still classified by provider capabilities such as centralised computing, desktop or networks. The interactions between such providers in such scenarios is particularly critical. Effective governance to set out the respective roles and responsibilities needs to ensure that the ownership of overall architectures and the intergation of such architectures are undertaken collaboratively and in line with the client organisation's business strategies and objectives and in accordance with a common business architecture.

In the case of ICT services being sourced through separate arrangements (typically through multiple providers), the demarcation point between provider domains would sit between the Information Architecure and Systems Architecture levels in the taxonomy. This is inherent given all ICT domains are concerned with data and information and the information level forms the common level of architecture. This can vary of course. The demarcation point with a provider of data or information services could be between the Business Architecture and Information Architecture levels.

Baseline to Target State and Future State

Technology-driven Innovation

Enterprise Architecture is a business-driven discipline. The widely used frameworks such as TOGAF, Zachman, DODAF, FEAF etc. all use a top-down approach to align ICT with business objectives. But what about technical innovation and its ability to change or even transform an organisation�s business and the organisation�s ability to grow and change? After all, the Internet changed the way organisations operate, and has spawned new businesses and new business models.

ICT initiatives and innovations need to be tested against the business and its drivers, its ability and willingness to adopt new technologies and new architectures and to adapt to change. Bottom up architecture may work for minor changes, but for transformative change a top-down approach needs to be used, for validating innovations that are initiated at the technical level:

"One of the things I�ve always found is that you�ve got to start with the customer experience and work backwards to the technology. You can�t start with the technology and try to figure out where you�re going to try to sell it." Steve Jobs

Enterprise Architecture should proactively contribute to innovation and help drive change. One technique for doing so is to look beyond Target State architectures to a Future State that is aspirational and not subject to existing constraints such as technology maturity, budgets, resourcing and the ability of an organisation to adopt innovations. A Future State architecture should always be exactly that � in the future. It can never be reached. It forms an ideal that is not detailed, but is continually updated in line with longer term business strategies and emerging technologies to guide the development of Target State architectures so that they are able to be responsive to potential changes in line with such drivers.