11. Perspectives

11.3 The Information Technology Perspective

BABOK® Guide

IIBA.org KnowledgeHub A Guide to the Business Analysis Body of Knowledge® 11. Perspectives 11.3 The Information Technology Perspective

The Information Technology Perspective highlights the characteristics of business analysis when undertaken from the point of view of the impact of the change on information technology systems.

This perspective focuses on non- agile approaches to IT initiatives.

For information regarding agile approaches within information technology initiatives, see The Agile Perspective.

When working in the information technology (IT) discipline, business analysts deal with a wide range of complexity and scope of activities. Initiatives may be as small as minor bug fixes and enhancements, or as large as re-engineering the entire information technology infrastructure for an extended enterprise. Business analysts are called upon to work with this diverse level of knowledge and skills among stakeholders to deliver valuable solutions to their IT needs.

Being able to effectively articulate the business' vision and needs to technical stakeholders is central to the success of a business analyst in the information technology discipline. Business analysts proactively collaborate with both the business stakeholders and development teams to ensure that needs are understood and aligned with organizational strategy. A business analyst frequently plays the role of the translator who helps business and technology stakeholders understand each other's needs, constraints, and context. The concept of solution design is appropriate in a technology context, and from the IT business analyst’s point of view. However, the term 'design', when discussed within an IT setting, is generally assumed to mean 'technical design' or the utilization of technologies to solve business problems. Business analysts within an IT context define and elaborate solution requirements or participate in solution design with business stakeholders while maintaining a separation with technical design.

Important In IT contexts, the term 'design' has traditionally been reserved for solution or technical design performed by developers, IT architects, or solution architects. All work done by IT business analysts is covered by the term 'requirements', including concepts such as the definition and design of business processes, user interfaces, reports or other elements of the solution relevant to stakeholders outside of the implementation team. Business analysts working in this context may prefer the term 'solution requirements' instead of 'design' in order to maintain a clear separation of responsibility.

Business analysts working in an information technology environment consider their tasks in light of three key factors:

Solution impact: the value and risk of the solution to the business.
Organizational maturity: the formality and flexibility of the organizational change processes.
Change scope: the breadth, depth, complexity, and context for the proposed change.

11.3.1 Change Scope

Changes to IT systems are initiated for several reasons. Each of the following triggers can lead to an IT change:

Create a new organizational capability: can be executed to transform the organization. These types of IT initiatives may drive the creation of larger programs to address non-IT changes, but are centered on a technology that alters the business environment.
Achieve an organizational objective by enhancing an existing capability: is part of a change that meets a defined need. This may include changes to meet regulatory requirements or to enable business specific goals. These types of initiatives often modify an existing system but may also require implementation and integration of new systems.
Facilitate an operational improvement: is undertaken to improve organizational efficiency or reduce organizational risk. The change scope, organizational maturity, and solution impact dictate whether these changes will be managed as a project, part of a continuous improvement effort, or as an enhancement.
Maintain an existing information technology system: is undertaken to ensure smooth operation of an existing IT system. Depending on the scope of the change, maintenance may be managed as a project or a regularly scheduled activity. This may include technology driven changes such as a vendor discontinuing support of a technology, scheduled releases or upgrades to a purchased software package, or technical modifications required to support architecture strategy.
Repair a broken information technology system: is undertaken when an IT system that is not performing as expected is changed to correct the dysfunction. The urgency of the repair is generally based on the level of disruption caused. In some cases the scope of the repair effort is very large, so the repair is managed as a project.

.1 Breadth of Change

Information technology initiatives may focus on a single system or on multiple systems which interact with each other. Some systems are developed and maintained in-house while others are commercial off-the-shelf (COTS) systems developed by an organization that is external to the group implementing the system. It is also possible that an external organization completes custom development, such as when development tasks are outsourced or contracted.

The scope of an IT initiative is often narrowly focused on software and hardware and a minimal set of systems, applications, or stakeholders. Larger initiatives may impact multiple user groups or systems, and often require collaboration with the extended enterprise. The implementation of COTS information technology systems may begin with a small or limited scope when the change is initiated, but after analysis is complete the scope is broader than originally anticipated. The business analysis approach for a COTS selection and implementation is approached differently than in-house development. These IT systems almost always require customization, integration, administration, and training. In some cases, the initiatives are limited to initial installation and implementation, or enhancements to an existing application. IT initiatives may also focus on a very specific technology solution such as what data is needed, how data is gathered, how it is stored and accessed in order to support business transaction methods, or how information is reported and available to the business groups.

Business analysts working in IT carefully consider the context for any information technology change. They consider whether the change is managed as a project, a continuous improvement, or a maintenance activity. Business analysts also consider organizational change management and all impacts including training, communications, and adoption of the change.

The nature of business analysis activities in an IT environment depend on a variety of solution impact factors:

What happens to the business if this system shuts down?
What happens if the system performance degrades?
What business capabilities and processes depend on the IT system?
Who contributes to those capabilities and processes?
Who uses those capabilities and processes?

When considering these solution impact factors, not only do business analysts match the formality of analysis activities to the business analysis processes defined by the organization, but also consider the importance of the IT system. The importance of the system under analysis may indicate that more analysis is needed to support and define the requirements for the change.

.2 Depth of Change

Changes in an IT environment frequently require the business analyst to define explicit details, including technical details such as the definition of individual data elements being manipulated or impacted by the change. Integration efforts can require analysis and definition at a great level of detail while identifying and defining the interfaces between IT systems. Due to the level of detail required in these types of initiatives, business analysts elicit and analyze how the organization works as a whole and how the IT system will support those operations. This provides the necessary context for the business analyst to understand whether the details being discovered and documented are relevant to delivering value. This can be particularly challenging when an IT system change is initiated for technology driven reasons but without sufficient clarity or alignment to business purpose.

.3 Value and Solutions Delivered

Information technology systems are implemented to increase organizational value, which includes any support capabilities and processes that use the system. Business analysts seek to align IT functionality to these processes and capabilities, and to measure the effect that the system has on them.

Changes to IT systems can increase value many ways, including:

reducing operating costs,
decreasing wasted effort,
increasing strategic alignment
increasing reliability and stability,
automating error-prone or manual processes,
repairing problems,
making it possible to scale up, enhance, or make more readily available a business capability, and
implementing new functionality and new capabilities.

.4 Delivery Approach

The delivery of business analysis activities within an IT organization varies greatly. Initiatives may range from small enhancement efforts which are completed with a single, short time frame release schedule to multi-release, phased implementations.

Short time frame initiatives may involve a single business analyst for a short period of time. Larger efforts frequently involve several business analysts who may coordinate analysis activities in several ways. Business analysts may divide work based on business group involved or by specific activity.

.5 Major Assumptions

The following is a list of major assumptions of the IT discipline:

business capabilities and processes that use an IT system are delivering value to the organization,
business analysts working from other perspectives can integrate their work with the work of the IT business analysts, and
IT systems changes are usually driven by a business need, although some initiatives may originate from within technology developments.

11.3.2 Business Analysis Scope

.1 Change Sponsor

Information technology changes may be requested or sponsored by business sponsors, IT departments, or as a collaboration between the two. These changes should align to organizational strategy and business goals. It is possible for an IT department to initiate change to align with technical strategy or reach technical goals, but an overall organizational strategy alignment is still crucial for change success.

The following list represents possible change sponsors:

technical team,
technical executive,
application owner,
process owner,
business owner,
internal product manager, and
regulatory representative (such as a corporate legal department). Enterprises may use many methods to initiate changes related to information technology. Frequently, large enterprises define a program or project management office within the IT department, which intakes requests and prioritizes efforts on behalf of the department.

.2 Change Targets

Business analysts identify all possible departments, processes, applications, and functions which can be impacted by the proposed change. A business analyst not only focuses on details of the initiative, but also keeps an eye on the larger picture and the potential impact (both business and technical) of the change. This involves a level of process and functional analysis with specific focus on both technical interfaces as well as process hand-offs.

.3 Business Analyst Position

Within an IT initiative, the business analysis activities may be filled by personnel with one of several types of backgrounds or job titles within the organization. This assignment may be dependent upon the type of change, the level of experience, knowledge needed, or simply the personnel available to staff the effort. The personnel may be assigned to the business analysis tasks due to the experience described below, and may complete some or all of the business analysis responsibilities for a given change.

It is possible that all business analysis tasks for an IT project may be completed by a person with only one of these backgrounds:

a business analyst who works specifically with the business users of an IT system,
an IT business analyst who is the designated liaison between the technical team and the business group which uses the application,
a subject matter expert (SME) experienced with the current software implementation,
a software user experienced with the daily activity of how the software is used and can focus on usability,
a systems analyst who has experience within the business domain, but does not have experience with the specific application,
a business process owner who has a depth of experience with the business capabilities or processes, but may not have any technical or IT experience,
a technical person with a depth of technical experience, or
a COTS representative who will allow for customized implementations of a packaged solution, and leverage the knowledge of the vendor's package and past implementation experience.

.4 Business Analysis Outcomes

Within an IT initiative, a business analyst may consider business processes impacted by the change, as well as the data and business intelligence information collected by the system. Business analysts working in the initiative thoroughly plan the business analysis effort and the deliverables that support the change effort.

The change approach being utilized has a direct impact on business analysis deliverables or outcomes. Many organizations have a defined system or solution development methodology which, to some extent, dictates the deliverables which are required at each project milestone. Even within the context of this structure the business analyst may seek to complete additional deliverables beyond those required by the change approach or organization specific process, and employ techniques which support the comprehensive understanding of the change effort needed.

Business analysts working in the IT discipline are responsible for delivering any of the following:

defined, complete, testable, prioritized, and verified requirements,
analysis of alternatives,
business rules,
gap analysis,
functional decomposition,
use cases and scenarios, and/or user stories as appropriate,
interface analysis,
prototypes,
process analysis,
process models,
state models,
decision models,
context models or scope models, and
data models.

Additional deliverables not included in the above list but relating to any of the outputs of business analysis techniques used may also be considered deliverables of the business analyst.

11.3.3 Methodologies

The methodologies followed by information technology organizations vary widely.

In general, solution development methodologies fall into two generic approaches:

Predictive: structured processes which emphasize planning and formal documentation of the processes used to complete the change. Each phase of the process or sequence is completed before advancing to the next phase.
Adaptive: processes which allow for reworking within one or more of the overall structured process cycles. Most adaptive models are both iterative and incremental, focusing on growing the product in both breadth and depth.

A hybrid methodology may also be utilized. A hybrid may include an overall vision for the whole initiative (as in predictive), as well as a definition of details within individual cycles or iterations (as in adaptive).

The following table identifies several established methodologies or approaches that a business analyst practicing in an information technology environment may encounter.

Table 11.3.1: Information Technology Methodologies

Methodology	Brief Description
Homegrown or Organization Specific	A methodology which is derived from components of other established methodologies or approaches may be created by an information technology organization to govern information technology based initiatives.
Requirements Engineering (RE)	Establishes a structured approach for requirements development and management and is used in predictive, adaptive, and agile environments.
Structured Systems Analysis and Design Method (SSADM)	A predictive development methodology that focuses on established logical modelling and the separation of requirements from solutions as central to systems analysis and specification.
Unified Process (UP)	An adaptive development approach. The inception and elaboration phases are of particular interest to business analysts. UP is not considered agile but is an adaptive methodology.

11.3.4 Underlying Competencies

A business analyst working within IT may possess skills related to IT development such as programming, creating a database, creating a system or solutionarchitecture, software testing experience, or other technical skills. However, development-related skills or technical skills are not necessary for a business analyst to be successful within an IT environment. It is important for the business analyst to have a strong understanding of the detail required within a requirements package to support technical solutions, as well as an understanding of what is technically feasible within the constraints of an organization’s technical architecture. These skills will enable a business analyst to work with all stakeholders to design a business solution framework which will also allow the technical team the flexibility to design a technical solution.

Business analysts use influencing and facilitation skills when working with stakeholders. Negotiation skills are frequently used when working with business and technical staff to come to agreements and decisions if the costs of a solution (either in budget, time, or architectural impact) conflict with the desired business outcome.

Systems thinking is a crucial competency for business analysts practicing in an IT environment. Systems thinking supports the ability of the business analyst to see the larger picture including any other applications or technical aspects which may be impacted, the details of the specific need, and possible technical solutions. Systems thinking also supports the ability to identify impacts to people, processes, and software which are not necessarily directly changed as part of an IT development effort, and to analyze the risks and possible outcomes of those impacts.

11.3.5 Impact on Knowledge Areas

This section explains how specific business analysis practices within information technology are mapped to business analysis tasks and practices as defined by the BABOK® Guide. It also describes how each knowledge area is applied or modified within the IT discipline.

Each knowledge area lists techniques relevant to an IT perspective. Techniques used in the discipline of information technology do not deviate, to any great extent, from the BABOK® Guide techniques. BABOK® Guide techniques are found in the Techniques chapter of the BABOK® Guide. This is not intended to be an exhaustive list of techniques but rather to highlight the types of techniques used by business analysts while performing the tasks within the knowledge area.

.1 Business Analysis Planning and Monitoring

A business analysis approach is a fundamental communication tool which can be used to identify resources required for business analysis work and ensure adequate time for the analysis effort. A well-defined business analysis plan integrates into the overall project plan and provides business analysts with the opportunity to define and schedule the business analysis activities for the project.

Many organizations have some standards and processes in place, which may identify certain analysis tasks and deliverables. If these are not in place, the business analyst identifies these tasks and deliverables based on the needs of the specific initiative.

It is important that the context of the analysis work is understood. This includes understanding the inter-operation of software systems, business processes, and the data that is passed from one system to the next. Changes to any single system or process may have a ripple effect that brings additional systems, processes, or stakeholder groups into the scope of the initiative.

The IT business analyst may be embedded within a software team. This approach allows the business analyst to become quite knowledgeable about specific software or processes supported by the software. Stakeholder attitudes and needs may change or shift in regards to each particular change. Roles, collaboration, and communication plans are planned for every change effort.

COTS solutions can involve major systems integration efforts, customizations, and many unexpected tasks due to the introduction of external software. When planning for unknown impacts and unknown customization needs, business analysts engage both internal stakeholders who understand the needs of the change, and external stakeholders who have expertise with the COTS solution being implemented.

BABOK® Guide Techniques

.2 Elicitation and Collaboration

Information technology changes frequently affect many stakeholders with distinct relationships to the solution or change. When a change involves an IT application or system, the technical staff may have expertise, perspectives, or experience that can identify additional impacts to systems or processes as requirements and solutions are defined. For this reason, it is beneficial to have at least one elicitation session with IT technical personnel, such as development or technical design staff, and business SMEs in the same room at the same time. This type of elicitation approach provides a platform for collaboration between technical and business teams, where the IT business analyst serves as a facilitator and liaison for the process.

Business analysts practicing in an IT environment may utilize any of the techniques identified in the Elicitation and Collaboration knowledge area. Additionally, the following methods can be of great benefit in the information technology discipline:

Investigation: using organizational process assets, market research, competitive analysis, functional specifications, and observation,
Simulations: using statistical modelling and mock-ups, and
Experimentation: using proofs of concept, prototypes, alpha- and beta- releases, and A/B testing.

Information technology changes can be seen as a distraction or cost by business stakeholders if the change is not perceived as mission critical or if the stakeholder is experiencing negative value from the change. This can make engagement for elicitation challenging. Elicitation across organizational boundaries may be impeded, causing collaboration breakdowns and rework. IT business analysts can decrease the risk of rework by engaging information technology and business resources in collaboration activities.

BABOK® Guide Techniques

.3 Requirements Life Cycle Management

IT initiatives frequently experience major discoveries while creating the change. It is through exploration that the business analysts discover the implications of the new functionality provided by the solution. This sense of discovery in IT environments has led to the adaptation of short cycle times (agile and continuous improvement), rigorous change control (Capability Maturity Model Integration (CMMI) and predictive), and externalized information technology (Software as a Service (SaaS) and cloud services).

Business analysts working in IT pay particular attention to alignment, approval, change control, traceability, and requirements life cycle management tools. It is the role of the business analyst to work with stakeholders to develop a consistent method for reviewing evolving requirements to ensure alignment with the business objectives for the initiative.

In many cases, changes to approved requirements are driven by changes to higher-level requirements such as business objectives. Business analysts collaborate with stakeholders to ensure these requirements are stable before proceeding to solution or technical requirements. When changes to requirements are presented, the business analyst analyzes the impact and plans how to manage proposed changes.

As the complexity of an information technology environment grows, it becomes increasingly important to track each change to each requirement or between requirements and other information. Traceability that includes dependencies and relationships among requirements makes it easier for stakeholders to understand what is changing about the IT system and predict impacts of additional changes.

As technical systems are changed over time, it is helpful when each version of each requirement is stored in some way and accounted for. Traceability makes it possible to find the source and owner of each requested function and feature, as well as why, when, and how it changed over time. This history is important for ensuring that the requirements are complete and that the approval of requirements is a sensible decision. When the change–work and the IT system are audited, regulators and other interested parties can understand what happened, when, and why. This can be especially important for audit purposes, when an application manages data or processes systematically without human intervention for each transaction or
instance of the process occurring. This tracing also helps the organization understand why some functionality is not delivered or implemented in the IT system, and why it was dropped from the scope of this implementation.

BABOK® Guide Techniques

.4 Strategy Analysis

Within an IT organization, strategy analysis focuses on the technologies and systems, business units, business processes, and business strategies impacted by a proposed change. It is possible that the impacts of a change cause a ripple effect through other systems in the organization. In order to analyze needs and proposed changes, business analysts seek to understand all the various aspects that may be impacted by the change.

Current state analysis within IT initiatives includes analysis of manual processes, understanding what the system or technology currently does, the data needed to complete tasks, and the other systems and processes that interact with the system. Business analysts plan for a thorough understanding of the current state and a large context of the enterprise at first, with the understanding that the scope will narrow as the future state is identified.

Once the current state is understood, the desired future state is described. This may be process or capability related and usually includes how current system functionality is required to change in order to support the future vision and meet the objectives of both individual stakeholders and the enterprise. In understanding both the current and future states, the gap between the two is identified, and that is where the direction of the change effort can be set. It is at this point of analysis that solution options are explored.

Once the aspects of the change scope and desired future state are understood, business analysts assess uncertainty and risk. Uncertainty is clarified by:

identifying and defining risks,
identifying and defining potential benefits,
establishing parameters for variance in known processes and operations, and
exploring the unknown.

Business analysts also explore other potential risks including:

vendor risks, such as their business and product stability,
impacts to the system’s technical environment,
scalability of the solution should volumes of transactions or users increase over time, and
additional process or system changes required based on the change initiated.

BABOK® Guide Techniques

.5 Requirements Analysis and Design Definition

It is important for business analysts working in IT to understand and clarify the term 'design'. Many IT organizations think of design only as it applies to the design or blueprint of a software or technical change. Within the Requirements Analysis and Design Definition knowledge area, the term design is viewed more broadly and from the business analyst’s point of view. Designs are usable representations that focus on the solution and understanding how value might be realized by a solution if it is built. For example, a model of a potential process improvement (whether it impacts or utilizes an IT system or not), as well as user interface layouts or report definitions, can all be considered designs.

Business analysts elaborate business and technical requirements, break down and define stakeholder needs, and identify the value to be realized by stakeholders once a technical solution or change is implemented. They elicit, define, and analyze business and stakeholder requirements, and also define, analyze, and model solution designs. They define requirements to a level of technical detail that will be used as part of solution design and input into technical designs. This elaboration will include both functional requirements and non-functionl requirements. For some change initiatives, the definition of non-functional requirements could define all business goals for the change effort.

Business analysts often rely on other change agents to produce technical designs for software solutions. A systems architect, programmer, database manager, or other technical expert is often needed to determine how to use technology to satisfy a set of requirements. IT business analysts define process steps, business rules, screen flows, and report layouts. Defining requirements to include detailed functionality of a system, the business, and system processes is a crucial part of solution design and does not separate analysis and design.

As part of requirements analysis, an IT business analyst may partner with another business analyst with a different focus, such as an enterprise business analyst or business architect, to ensure that the IT requirements align to business or organizational strategy.

Requirements analysis and design definition frequently involves documenting requirements using words and pictures. In some cases, requirements may be represented in other ways such as a proof of concept, working software prototypes, or simulations. In all cases, the business analyst works to produce documentation with sufficient and appropriate details for:

the business to verify and validate the requirements,
the developers to design from, and
the testers to measure the solution against before it is implemented into a production environment.

BABOK® Guide Techniques

.6 Solution Evaluation

Solution evaluation focuses on solution components and the value they provide. Within an IT context, this includes a focus on the interactions between multiple systems within the change and the surrounding environment. It is important for a business analyst working in the IT discipline to understand the context of the solution and how changes within one system or process can impact other systems within the environment. These impacts can add negative or positive value to the other systems, therefore impacting the overall realization of value for the change.

One aspect of solution evaluation within an IT context is software testing or solution testing. Testing or quality assurance ensures that the solution performs as anticipated or designed, and that it meets the needs of the business or stakeholders who requested the change effort. The business analyst works with quality assurance (testers) to ensure that technical solutions will meet the business needs as defined by the requirements and other business analysis deliverables. Testers utilize testing methodologies to plan, develop, and execute tests. This aspect of solution testing generally focuses on complete process testing, including across systems to ensure end-to-end solution quality and accuracy. Business analysts work with stakeholders to plan, develop, and execute user acceptance tests to ensure that the solution meets their needs.

Business analysts make themselves aware of the rationale for implementing an IT solution and how that rationale works to create solution value. This value realization is commonly associated with better support for business processes and procedures.

Business and technical objectives are associated with benefits and value realization which are measured against defined metrics used to evaluate success. Requirements should trace back to the objectives, and this traceability provides a foundation for solution evaluation. The analysis of solution performance focuses on technical systems and how they provide potential and actual value to stakeholders.

Where a large organizational change contains an IT element, an IT solution evaluation can contribute to a broader benefits realization activity associated with the whole change program.

As part of solution evaluation activities, a business analyst may work with a team to complete tasks, such as assessing solution limitations and assessing the impacts of such limitations. The business analyst may support and assess technical testing efforts for all, or a portion of, the developed solution.