You are on page 1of 58

Enterprise Architecture Definition

Business Process Management (BPM)


Version No. 3.3

May 2010

Author:
Enterprise Architecture Council

FTB Proprietary and Confidential


Business Process Management (BPM) - Version No. 3.2

Document Information
Revision History

Version Date Author Change Description


1.1 2/2/09 John Roussel Title change
2.0 7/22/09 Lisa Duran Annual Refresh –
First Draft – Only Current
Architecture updated
3.0 11/23/09 Lisa Duran Annual Refresh
Brenda Keebaugh – All sections updated
– Applicable information from
ECM EAD included
– Applicable information from
BI EAD included
3.1 12/3/09 Lisa Duran Review edits made
Brenda Keebaugh
3.2 2/3/10 John Roussel Revision of executive summary;
formatting changes
3.3 5/18/2010 Lisa Duran Revisions in response to EDR
Brenda Keebaugh review

References

EAD Area Source


Current Architecture Enterprise Content Management Task Force
Summary of Findings (2007)
2008/2009 BPM CoE Artifacts
EAC Website
Business Problem Analysis Report

Target Architecture BPM Institute


IBM
Tech Republic
BP Trends
Six Sigma handbook
Object Management Group
Software AG
CIO Update
FTB ITSP

All Wikipedia

May 2010 ii
Business Process Management (BPM) - Version No. 3.2

Table of Contents
1.0
1.1 Overview .................................................................................................................. 1
1.2 Scope........................................................................................................................ 1
1.3 Current Architecture................................................................................................ 1
1.4 Target Architecture.................................................................................................. 2
1.5 Strategy and Roadmap ............................................................................................ 4
1.5.1 Establish Business Process Management Methodology and Governance .................. 4
1.5.2 Create a Process-Centric FTB ..................................................................................... 4
1.5.3 Promote Cultural Change ............................................................................................. 4
1.5.4 Implement a Business Process Management Suite (BPMS) ....................................... 4
1.5.5 High-level Timeline ....................................................................................................... 5
1.5.6 Dependencies ............................................................................................................... 5
1.6 Closing ..................................................................................................................... 6
2.0
2.1 Overview .................................................................................................................. 8
2.1.1 Enterprise Architecture Council .................................................................................... 8
2.1.2 BPM Center of Excellence............................................................................................ 8
2.1.3 BPM Defined ................................................................................................................ 9
2.1.4 BPM Components ...................................................................................................... 10
2.1.5 BPM at FTB ................................................................................................................ 11
2.2 Business Intelligence (Process Monitoring) ........................................................ 12
2.2.1 History of BI at FTB .................................................................................................... 12
2.2.2 BI Technical Architecture ............................................................................................ 12
2.2.3 BI Business Architecture ............................................................................................ 14
2.2.3.1 Primary BI Services ................................................................................................. 14
2.2.3.2 Other BI Activities .................................................................................................... 14
2.2.3.3 BI Users .................................................................................................................. 15
2.2.3.4 BI and Business Process Analysis .......................................................................... 15

2.3 Workflow Automation ............................................................................................ 16


2.3.1 Workflow Automation Technical Architecture ............................................................. 16
2.3.2 Workflow Automation Business Architecture .............................................................. 16
2.4 Enterprise Content Management .......................................................................... 18
2.4.1 ECM Technical Architecture ....................................................................................... 18
2.4.1.1 Capabilities and Components ................................................................................. 18
2.4.1.2 Content Management Solutions .............................................................................. 19
2.4.2 ECM Business Architecture ........................................................................................ 20
2.4.2.1 Electronic Content Types ........................................................................................ 20
2.4.2.2 Electronic Content Statistics .................................................................................... 21

2.5 Business Process Modeling ................................................................................. 22


2.5.1 Business Process Modeling Technical Architecture .................................................. 22
2.5.2 Business Process Modeling Business Architecture ................................................... 22
2.6 Business Rules Management ............................................................................... 23
2.6.1 Business Rules Management Technical Architecture ................................................ 23

May 2010 iii


Business Process Management (BPM) - Version No. 3.2

2.6.2 Business Rules Management Business Architecture ................................................. 23


3.0
3.1 Overview ................................................................................................................ 24
3.1.1 What is BPM Governance? ........................................................................................ 24
3.1.2 What is BPM methodology? ....................................................................................... 24
3.1.3 What is process management? .................................................................................. 25
3.1.4 What is a Business Process Management Suite (BPMS)? ........................................ 25
3.1.5 BPM Lifecycle ............................................................................................................. 26
3.2 BPM Technical Architecture ................................................................................. 27
3.2.1 Overview ..................................................................................................................... 27
3.2.2 BPMS Flow ................................................................................................................. 28
3.2.3 BPMS Tools ................................................................................................................ 28
3.2.4 BPMS Supported Activities......................................................................................... 29
3.2.5 Process Monitoring and Operational Business Intelligence ....................................... 30
3.2.6 Process Model Execution and Simulation .................................................................. 30
3.2.7 Workflow Automation .................................................................................................. 30
3.2.8 Digital Asset Management.......................................................................................... 30
3.2.9 Enterprise Content Management ............................................................................... 31
3.2.10 Open Standard System, Development Platforms, and Enterprise Service Bus ......... 32
3.2.11 Process Modeling and Business Process Analysis .................................................... 33
3.2.12 Business Rules Management ..................................................................................... 33
3.3 BPM Business Architecture .................................................................................. 34
3.3.1 Overview ..................................................................................................................... 34
3.3.2 Enterprise Architecture Council .................................................................................. 35
3.3.3 BPM Center of Excellence.......................................................................................... 35
3.3.4 BPM Governance ....................................................................................................... 36
3.3.5 BPM Methodology ...................................................................................................... 36
3.3.5.1 Value Creating Business ......................................................................................... 36
3.3.5.2 Organizational Change and Structure ..................................................................... 37
3.3.5.3 Cultural Change ...................................................................................................... 40
3.3.5.4 Business Process Management Maturity ................................................................ 41
3.3.5.5 Process Management ............................................................................................. 44
3.3.6 BPMS and Business Architecture .............................................................................. 45
4.0
4.1 Technical Architecture .......................................................................................... 46
4.2 Business Architecture ........................................................................................... 48
5.0
5.1 Technical Architecture Roadmap ......................................................................... 50
5.2 Business Architecture Roadmap .......................................................................... 51
5.3 Dependencies ........................................................................................................ 52
6.0
6.1 BPM Glossary ........................................................................................................ 53
6.2 BPMS Standards .................................................................................................... 53
6.3 BPM Best Practices ............................................................................................... 53

May 2010 iv
Business Process Management (BPM) - Version No. 3.2

List of Figures

Figure 1.5-1: High-level Timeline................................................................................................ 5


Figure 1.6-1: BPM Architectural Definition – “To Be” Technical Architecture Model ................... 7
Figure 2.1-1: Business Process Management Wheel ................................................................. 9
Figure 2.2-1: Current BI Technical Architecture.........................................................................13
Figure 2.2-2: User Base for FTB BI Systems ............................................................................15
Figure 2.4-1: FTB Content Management Process - Current ......................................................19
Figure 3.1-1: Business Process Management Lifecycle ............................................................26
Figure 3.2-1: Business Process Management Suite Flow .........................................................28
Figure 3.2-2: FTB Content Management Process - Target ........................................................32
Figure 3.3-1: Example Target Organizational Structure Model ..................................................38
Figure 3.3-2: Business Process before Process-Centric Organization ......................................39
Figure 3.3-3: Business Process after Process-Centric Organization .........................................40
Figure 3.3-4: Business Process Management Maturity Model ...................................................42
Figure 5.1-1: Technical Architecture Roadmap .........................................................................50
Figure 5.2-1: Business Architecture Roadmap ..........................................................................51

List of Tables

Table 2.4-1: FTB Content Management Tools ..........................................................................19


Table 2.4-2: Electronic Content Types ......................................................................................20
Table 3.3-1: Target Business Architecture for Key Elements.....................................................34
Table 3.3-2: Value Proposition and Value Chain Examples.......................................................36
Table 3.3-3: Five BPM maturity levels .......................................................................................43
Table 3.3-4: Comparison of Low and High BPMM Indicators ....................................................43
Table 3.3-5: BPMS Components in Relation to Business Architecture ......................................45
Table 4.1-1: Technical Architecture Gap Analysis .....................................................................46
Table 4.2-1: Business Architecture Gap Analysis ......................................................................48

May 2010 v
Enterprise Architecture Definition – Business Process Management

1.0
1.1 Overview

The Franchise Tax Board (FTB) definition of Business Process Management (BPM) is “A
strategy for managing and improving the performance of a business through continuous
optimization of business processes in a closed-loop cycle of modeling, execution, and
measurement.” This includes the methods, techniques, and tools used to design, enact, control,
and analyze business processes involving people, systems, applications, data, and
organizations helping to improve business agility and performance.

Significant changes at FTB are proceeding to ensure comprehensive and successful enterprise-
wide BPM solutions for establishing practices and governance, and managing key business
processes. The pursuit of these BPM enterprise-level solutions focuses on the:

Way people in the organization think: thoughts, expectations, and conclusions, of the
members of the organization
Norms: often referred to as corporate culture, the standards, models, and patterns which
guide behavior
Systems and processes: processes and technologies used to do business

1.2 Scope

This BPM Enterprise Architecture Definition (EAD) defines the current and target, states of
FTB‟s BPM architecture. Additionally, it provides a gap analysis and implementation strategy for
each of the following subject areas:
BPM Methodology
BPM Governance
BPM Technical and Business Architectures
BPM-Enabling Technologies

1.3 Current Architecture

FTB‟s current organizational structure is function-centric, also known as siloed, and structurally
organized by a collection of common tasks or functions. FTB utilizes various aspects of BPM,
but lacks a standard, recognized, and accepted BPM methodology or BPM governance for the
enterprise. FTB utilizes various components of BPM including:
Process Monitoring (Business Intelligence)
Workflow Automation
Enterprise Content Management
Process Modeling
Business Rules Management

1|Page
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

The majority of these BPM components are specific to a single system or business process,
vary between systems and business processes, are not shared or re-used throughout the
enterprise; additionally a number of the processes are intensively manual. Finally, FTB lacks
a Business Process Management Suite (BPMS) to assist in managing enterprise
business processes.

1.4 Target Architecture

The scope of the BPM EAD targets the capabilities, usability, and benefits of a BPMS, as
well as, the establishment of successful enterprise BPM methodology and governance. FTB‟s
enterprise-focused BPM target architecture includes the following:

A mature Enterprise Architecture Council


An expanded BPM Center of Excellence
A mature BPM Governance process
A mature BPM methodology
A mature process management method
A robust Business Process Management Suite (BPMS) and corresponding technologies

BPM Governance – FTB‟s target BPM governance is comprised of a well-defined structure and
developed governance body that is responsible for all strategic, and tactical, BPM governance.

BPM Methodology – FTB‟s target BPM methodology executes a holistic organizational


management approach. This method includes executive management buy-in and support,
as well as, executing process-aware information systems and providing opportunity for
accountability and culture receptiveness that builds and matures business processes. In
addition, BPM methodology is based on process architecture, which captures the
interrelationships between key business processes, and supporting processes, that align
with organizational strategies, goals, and policies.

Furthermore, BPM methodology provides a pragmatic approach for managing and improving
FTB core business functions. This enables decisions that affect business performance,
processes, and strategies to be based on first-hand data, strategic analysis, and real world
testing. The desired outcome is providing quality, low-cost, fast results for the organization.

Critical BPM methodology success factors include:


A structured approach
Organizational and cultural change
Alignment with corporate goals and strategies
Focus on customer needs
Top management commitment
Benchmarking
Process measurement, improvement and management
Process-aware information systems infrastructure and realignment

2|Page
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

FTB‟s target BPM methodology:


Focuses on value with emphasis on value-propositions, and value-chains, that identify
core business processes and process steps
Establishes a process-centric organization that organizes achievements of strategic and
tactical goals to create standard, repeatable, and actively managed business processes
that provide predictable results
Reduces reliance on traditional territorial and functional structures by redefining
organizational areas to facilitate process-centricity; in addition to deemphasizing
hierarchical reporting relationships and empowering employees to pursue improvements
across organizational boundaries
Controls and manages business processes centrally, and defines new roles which
support business processes and cut across functional “stovepipes” to encourage
process-centric business
Measures the success of BPM by assessing the organizations maturity level which
provides effective information that can be used to predict future BPM performances
of a given area, or set of areas

Process Management – FTB‟s implementation of process management methods and tools


facilitates procedures that ensure organizational resources are executing critical activities to
improve productivity, as well as ensuring a level of control to manage the organization in the
best manner. This is achieved by applying a process management methodology that requires
process experts to conduct the actual tasks involved in the process.

Business Process Management Suite (BPMS) – FTB‟s target BPM architecture requires the
procurement of a software package that will facilitate the process management aspects of BPM,
including process design, workflow, applications, integration, and activity monitoring (in system
and human-centric environments). This software package must support business needs by
defining, modeling, simulating, deploying, executing, monitoring, analyzing, automating, and
optimizing business processes.

A BPMS offers tools (e.g. software), and solutions (e.g. integration), that depict, analyze, and
measure Key Performance Indicators (KPIs) that will optimize business process and workload
management. The BPMS environment contains all operating information, and context of
business process execution, which are easily available and reusable to all business and IT
areas; thus, increasing the speed and agility of core business processes by providing a system
that can implement efficient change to business operations, application support, or data
access. Additionally, a BPMS will award control of processes to business users and increase
speed of delivery, which in turn will support a transition to Service-Oriented Architecture (SOA)
based applications and an enterprise data access approach (e.g. enterprise data warehouse).

Furthermore, the implementation of a BPMS will address the current needs of business
managers to establish and control operational processes and manage work outcomes
efficiently. In addition, it will permit authorized personal/staff to retrieve, view, and confirm
comprehensive information to simulate changes, compare costs and improvements, and know
the impacts of the change prior to making operational reengineering decisions. The BPMS
environment provides a foundation to deliver business models and information. Business
managers working with data analysts develop applications, which are generated from a
combination of business models, and rules definitions, to manage workflows, track work and
processes, and monitor performance.

3|Page
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

1.5 Strategy and Roadmap


1.5.1 Establish Business Process Management Methodology and Governance
FTB must first address organizational, cultural, and process changes in order to implement
a successful BPM solution. The gains achieved through BPM architecture will drive agility;
real-time management skills (e.g. collaboration, consensus building, etc.); and establish joint
control between business and IT managers to condense the time it takes to make process
improvements throughout the organization. Additionally, IT development staff no longer
performs all front-end analysis and process design, and IT managers proactively encourage
a progressive shift to shared responsibility for these activities with business process analysts,
business managers, and process owners.

Through the EAC, the BPM Center of Excellence (CoE), and the Enterprise Data to
Revenue (EDR) project, FTB will define and implement BPM governance, and identify all
value-propositions/value-chains and promote enterprise adoption of BPM methodologies,
standards, models, and patterns.

1.5.2 Create a Process-Centric FTB


By the creation of a process-centric organization, FTB will be able to centrally control and
manage business processes, and establishes new roles to support business processes. This is
accomplished through the work of the FTB‟s Governance Council (GC) and various action
committees, which are supported, by the Enterprise Architecture Council (EAC) and the BPM
Center of Excellence (CoE).

1.5.3 Promote Cultural Change


A paradigm shift in the current FTB culture is needed in order to successfully support BPM.
This can be achieved by engaging employees at all levels and promoting the positive benefits
of enterprise thinking and BPM throughout the organization. The focus will be on analysis and
improvement of the work. Management will direct additional focus towards vision, customers,
value, and results. Starting with a top-down methodology promoted by the GC, executive
management, various action committees, and supported by the Enterprise Architecture Council
(EAC). Furthermore, the BPM CoE will assist in the development of communication plans and
creating process owner roles and responsibilities.

1.5.4 Implement a Business Process Management Suite (BPMS)


Through projects such as the Enterprise Data to Revenue (EDR) project, and additional
BPMS expansion projects, FTB will implement a software infrastructure platform that enables
collaboration between business and IT staff regarding process design, development, execution,
and enhancement activities. These projects will provide a solid foundation for the
implementation, and transition, to an enterprise-wide BPMS.

4|Page
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

1.5.5 High-level Timeline


Figure 1.5-1: High-level Timeline
12/31/12
6/1/12 Business Process Maps
Simulation & Optimization Tools Business Intelligence & Analysis Tools 12/31/14
Orchestration Engine 11/1/12 Enterprise Content Management
Business Rules Engine Enterprise Service Bus
Business Rules Repository 12/30/13
Digital Asset Management

1/1/09 1/1/10 1/1/11 1/1/12 1/1/13 1/1/14


Oct 1, 2008 12/31/14 Dec 31, 2014
9/30/11 6/29/12 7/1/13
Governance Organizational Changes Cultural Changes Process Management

1.5.6 Dependencies
Implementation of a robust and comprehensive BPMS at FTB will be dependent upon these
architectural disciplines:

Service Oriented Architecture (SOA): There is a two-way relationship with SOA. BPMS
tools will be used to design the system-to-system process flows. SOA will be required to
be truly process centric. With the implementation of SOA, business users will be able to
use business application modeling to record the activities within a database and analyze
how things are working. Users can execute their process changes within the systems in
real-time with SOA. This gives users control of systems in the end-to-end processing
Data management: Store models, flows, rules, etc. Data management will be important
for data quality assurance
Identity and Access Management: Used to define and control the workflow. The
implementation of the IAM architecture will ensure that workflow rules can be enforced
as processes move between systems and staff
ECM: For unstructured data, BPMS could supply the workflow

Implementation of comprehensive and successful BPM at FTB will be dependent upon


the following:
Establishing Governance and a BPM methodology
Organizational and cultural changes
Establishing process management

5|Page
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

1.6 Closing

Organizational, cultural, and process changes for how FTB does business will be necessary for
successful BPM implementation. In addition, implementation of a BPMS for efficient BPM will
be necessary. Increased business agility is one of the many benefits realized from adopting
BPM. The gains realized through new BPM practices and enabling technologies propel agility
throughout the organization. BPM requires business managers to learn real-time management
skills to achieve greater business agility. Those skill sets include collaboration and consensus
building. Shared control between business managers and IT managers shortens the cycle time
to make process improvements. IT development staff must leave behind the long-held belief
that they must perform all the front-end analysis and process design. IT managers must
proactively encourage a progressive shift to shared responsibility for these activities with
business process analysts, business managers and process owners.

The FTB Target Architecture Model, (Figure 1.6 1: SOA Architectural Definition – “To Be”
Technical Architecture Model), depicts FTB‟s goal for future business and IT service delivery.
This model illustrates the high-level relationships between FTB‟s core services and its
customers in addition to other core services that are required to align in order to achieve a cost
effective and efficient solution. Each core service is related to a specific Enterprise Architectural
Definition (EAD).

6|Page
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

Figure 1.6-1: BPM Architectural Definition – “To Be” Technical Architecture Model

7|Page
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

2.0
2.1 Overview
Franchise Tax Board‟s (FTB) current organizational structure is function-centric (also known
as siloed), that is generally FTB is structurally organized by a collection of common tasks or
functions. FTB utilizes various aspects of BPM, but does not have a standard, recognized, and
accepted BPM methodology in place for the enterprise. Nor does FTB have a Business
Process Management Suite (BPMS) in place to assist in managing business processes. The
organization commonly performs BPM in various manners related to the organizational structure
of the business versus an enterprise approach. However, FTB has an established Enterprise
Architecture Council (EAC) and a BPM Center of Excellence (CoE) that has begun laying the
foundation for enterprise BPM at FTB. Additionally, FTB has begun plans to establish a BPM
Governance process (refer to the Governance EAD).

2.1.1 Enterprise Architecture Council


The EAC establishes the enterprise wide roadmap to achieve the department‟s key initiatives
and strategic goals through improving the performance of its core business processes within
an efficient information technology (IT) environment. The EAC is a key member of FTB‟s
governance structure and is responsible for developing, as well as, refining enterprise
architecture (EA) maturity, assurance, and deliverables. The EAC collaborates with project
development and operations personnel to create the most cost effective service delivery
architectural model possible for FTB.

2.1.2 BPM Center of Excellence


The BPM CoE is an organizational component of the FTB EAC. The CoE is a cohesive and
collaborative team of FTB staff from around the department lead by the EAC BPM solution
architect. The primary tasks include defining, planning, and maturing FTB‟s master plan from
which to make decisions for a FTB BPM solution. The BPM CoE‟s responsibilities and
strategies are:
Improve FTB Business and IT delivery by participating in the EAC processes
Reduce total cost of ownership (TCO) of FTB solutions through “green” initiatives,
reduction, alignment, consolidation, elimination, and simplification
Prepare and submit deliverables to the EAC such as principles, policies, standards,
and master plans

The BPM CoE tackled several efforts during its 2008/2009 sessions, including:
Establishing a BPM Glossary, BPMS Standards, and BPM Best Practices
Adopting BPMN (Business Process Modeling Notation)
Creating business process maps (models) for the business processes as related to our
main tax processing systems and identifying FTB Sections and roles responsible for the
activities in the maps
Creating the FTB Business Reference Model (BRM)

8|Page
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

2.1.3 BPM Defined


FTB recognizes the definition of BPM as a strategy for managing and improving the
performance of a business through continuous optimization of business processes in a closed-
loop cycle of modeling, execution, and measurement. This includes the methods, techniques,
and tools used to design, enact, control, and analyze operational business processes involving
people, systems, applications, data, and organizations. BPM is a highly productive management
discipline with the goal of improving business agility and performance, its foundation includes
governance and a business process environment. BPM is a structured approach that employs
methods, policies, metrics, management practices and software tools to manage and
continuously optimize an organization‟s activities and processes.

Through researching industry best practices, the BPM CoE has identified these BPM
components as depicted in the figure (Figure 2.1-1: Business Process Management Wheel)
below and compiled the component definitions as shown in section 2.1.4.

Figure 2.1-1: Business Process Management Wheel

9|Page
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

2.1.4 BPM Components


The following are components of BPM:

Process Monitoring – the tracking of individual processes, so that information on their


state can be easily seen and statistics on the performance of one or more processes
can be provided.

Process Simulation – process simulation is a model-based representation of a business


process used in the computer modeling of a hypothetical situation that can be analyzed
to determine how a given application of systems may operate when deployed.

Workflow Automation – the automation of a business process, in whole or part, during


which documents, information or tasks are passed from one participant to another for
action, according to a set of procedural rules.

Digital Asset Management – consists of tasks and decisions surrounding ingesting,


annotating, cataloguing, storage and retrieval of digital assets, such as digital
photographs, animations, videos and music. The term "digital asset management"
(DAM) also refers to the protocol for downloading, renaming, backing up, rating,
grouping, archiving, optimizing, maintaining, thinning, and exporting files.

Enterprise Content Management – the strategies and technologies employed to manage


content (documents, images, and data) across the enterprise. ECM tools and methods
allow the management of an organization's information, wherever that information exists.
The attributes used in ECM are capture, manage, store and retrieve, preserve, deliver,
collaboration, and security.

Open Standard System – a system based on an open standard. An open standard is a


standard that is publicly available and has various rights to use associated with it, and
may also have various properties of how it was designed (e.g. open process).

Development Platforms – the combination of hardware and software typically providing


many features for authoring, modifying, compiling, deploying and debugging software.

Enterprise Service Bus (ESB) – a collection of components that comprise the


foundational services for more complex architectures via an event-driven and
standards-based messaging engine “the bus”.

Process Modeling – creating integrated graphical models representative of


business, system, and human processes used to capture, design, simulate, and
optimize processes.

Business Rules Management – defining, deploying, executing, monitoring, and


maintaining the variety and complexity of decision logic that is used by operational
systems within an organization or enterprise. This logic, also referred to as business
rules, includes policies, requirements, and conditional statements that are used to
determine the tactical actions that take place in applications and systems.

10 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

2.1.5 BPM at FTB


Currently, FTB creates, operates, and manages business processes within individual Systems
of Work (SOW) tied to the organizational structure rather than enterprise functionality. This has
resulted in process redundancy and outcome discrepancy (i.e. multiple notices, different tax
amounts, etc). Additionally, workflow steps between systems are manual and a source of
costly rework.

The following are components of BPM that FTB is currently utilizing:


Process Monitoring (Business Intelligence)
Workflow Automation
Enterprise Content Management
Process Modeling
Business Rules Management

Most all of these components at FTB are specific to a single system or business process, vary
between systems and business processes, and are not shared or re-used throughout the
enterprise. Additionally, several of the components in use are intensively manual processes.

11 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

2.2 Business Intelligence (Process Monitoring)


2.2.1 History of BI at FTB
Business Intelligence (BI) is a business management term referring to applications and
technologies used to gather, provide access to, and analyze data and information about an
organization‟s operations and performance. BI systems help organizations have a more
comprehensive knowledge of the factors affecting their business, such as metrics on production
and internal operations assisting organizational decision making. Three main components of BI
are reporting, data mining, and predictive analytics.

The current BI organization and system architectures are tightly connected to the evolution of
overall IT services in the department. Prior to 1995, IT services at FTB were “centralized” in one
organization that serviced all FTB business areas. Information needs were primarily provided
through mainframe applications that lent themselves to central control and management. The
increasing use of personal computers and the emergence of distributed computing, coupled with
a concern about the ability of the department to respond to rapid changes in technology for
meeting business needs, prompted FTB to reorganize technology services in 1995 into a
“decentralized” model. Under this model, each major business area was responsible for
developing and maintaining the specific technologies that supported their business activity.

The deployment of various projects influenced the emergence of BI at FTB, as reporting and
analytical needs were tightly integrated with the deployment of each project normally without
consideration to enterprise BI needs. The corresponding BI efforts were developed at different
times, under different management, using different products, and in silos:

PASS MI (Professional Audit Support System Management Information) - SQL Server


database, implemented as separate project, subsequent to PASS in 2004
ARMR (Accounts Receivable Management Reporting System) - SQL Server database,
implemented as a separate, parallel project, to ARCS in 2000
ECAIR (Enterprise Customer, Asset, Income, & Return) - DB2 database, implemented
as the last phase of INC, in 2002
BETS Revenue Reports - SQL Server database, implemented as a separate effort
subsequent to BETS, in 1997

2.2.2 BI Technical Architecture


Due to the massive amount of data that needs to be extracted, transformed and loaded (ETL) to
a data warehouse system, the operations and analysis performed on this data and the ETL
process, is performing at a decreasing rate. Although the ECAIR data warehouse is becoming
enterprise focused, there are no rules or standards to pull the third party data into FTB‟s data
stores. Currently, third party data is not managed and is not using a stable front-end to load the
data. This results in data that is unusable. Many of the data feeds are hand coded resulting in
reduced data quality.

The current BI technical architecture parallels the data architecture and adds the process and
delivery mechanisms for BI focused data. Figure 2.2-1 illustrates the current technical
architecture and environment of FTB‟s BI systems. The diagram depicts the source systems,
data warehousing systems, and reporting and analysis systems currently in use.

12 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

Figure 2.2-1: Current BI Technical Architecture

13 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

2.2.3 BI Business Architecture

2.2.3.1 Primary BI Services


The Business Intelligence and Data Services (BIDS) group within the Technology Planning and
Decision Support Bureau was formed in early 2006 by consolidating most of the staff involved in
supporting FTB‟s business customers analytical and reporting needs. One of the key goals of
forming this group was to examine the BI activities, practices, technologies and tools for
opportunities to reduce redundancies, standardize, and implement industry best practices.

BIDS provides information about how FTB is functioning, including performance measurements,
cost/revenue measurements and customer demographic information. BIDS makes this
information available to the enterprise in data marts, data warehouses, and other summary
sets of information. BIDS provides information to customers through query and reporting
mechanisms and ad hoc services.

BIDS implemented a standardized development lifecycle, which they consider key to improving
their ability to effectively meet BI users‟ needs, increase the quality of data and products, and
reduce potential redundancy and development costs. As part of this lifecycle, the BIDS group is
empowered to approve or deny all proposed changes to the BI systems reducing the potential
impact to other BI systems and the perpetuation of stovepipe systems. This has helped the
organization move away from the prior practices of development or system changes that
ignored the impact to other BI systems or other development activities, practices that
perpetuated stovepipe systems.

2.2.3.2 Other BI Activities


While BIDS is the primary provider of business intelligence reporting and analytics, other areas
within FTB also engage in providing reports, analytics, and ad hoc support. These
areas include:

Economic and Statistical Research Bureau (ESRB) – provides a wide range of reports
and analytics relating to corporate and individual filing activity and demographics. ESRB
is responsible for overseeing the creation of annual filing data samples that are critical
for determining the potential impacts of tax policy changes or trends in economic activity.
The information is used for a variety of purposes, such as the department's Annual
Report, news releases, revenue impact analyses, a variety of special studies, and
providing answers to questions posed by other departmental units, other state
departments, the Legislature, and the general public. Although the organization does
not represent itself as a “provider of BI,” many of their activities are clearly BI in nature.

Privacy, Security and Disclosure Bureau (PSDB) – develops security policies and
procedures, including security measures for the protection of FTB‟s facilities, and to
prevent, detect, and track unauthorized access to information technology systems,
networks, and data. Some activity related to tracking data exchange agreements with
third parties and analyzing system usage activity for potential security policy violations
are BI in nature.

Financial Management Bureau (FMB) – provides reports and analytical support relating
to CALSTARS and Activity Based Costing (ABC), often considered to be within the
BI umbrella.
14 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

Compliance Systems Bureau (CSB) – provides some reporting and analytics related to
various applications developed and maintained for audit and collection activity, including
ad hoc support. BIDS often refers ad hoc support to this area when requests actually
need operational data associated to systems supported by this group.

Tax Systems and Applications Bureau (TSAB) – provides reporting and analytics relating
to tax systems and web-based systems that support taxpayer activities through FTB‟s
public website. Web statistics are collected using a commercial-off-the-shelf application
and provided to users through FTB‟s intranet or through ad hoc support.

Infrastructure Services Bureau (ISB) – provides for the design, implementation and day-
to-day operation of a “Reporting Info Mart”, that is a BI application focused on call center
and IVR data.

2.2.3.3 BI Users
Figure 2.2-2: User Base for FTB BI Systems

Type of Users
BI System Total
Casual Users Power Users Developers
ARMR 500 12 5 517
PIT Return DM 50 11 4 65

ECAIR DW 20 10 5 35

PASS MI 100 3 3 106

Outside of BIDS 195 8 20 223

Total 670 36 17 946

2.2.3.4 BI and Business Process Analysis


FTB usually accomplishes business process analysis (BPA) using system BI reports, ad hoc BI
reports, and automated or manual analysis. The majority of FTB‟s applications gather system
data and produce reports used for BPA. BPA information gathered is regularly published via
paper or documentation posted to the FTB intranet.

15 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

2.3 Workflow Automation


2.3.1 Workflow Automation Technical Architecture
FTB does not have an enterprise workflow automation solution, however, several systems at
FTB have workflow automation capabilities; but each is specific to single applications or
business processes. Current workflow processes are not available for reuse. The following lists
some of the systems that have workflow automation capabilities:

INC – Case Management Template (CMT) – the CMT component for workflow
management is User Task Window (UTW). UTW allows users to view assigned tasks
and “work” those tasks to resolution, but this process is not currently used due to
performance issues, instead the BI unit performs queries to provide work lists. However,
the batch process that moves the case from state to state is being utilized
ARCS – uses workflow functions to move cases from state to state and adds them to
work lists for collectors based on business rules
IPACS – uses workflow functions to route batches through the applications that make up
IPACS. The workflow is automatic and a key part of the system, but can be monitored
and changed by managers
PASS – uses workflow functions to automatically route cases through the system.
RV/TI/BETS – uses workflow functions to automatically route tax returns through the
system, place returns on hold, and identify returns for review
Content Update Tool (CUT), Unicenter, ClearQuest: uses workflow functions to route
cases from state to state and automatically sends email notifications
TeamSite – uses workflow functions to route and approve content postings on FTB‟s
external website

2.3.2 Workflow Automation Business Architecture


Several FTB business programs use workflow automation; however, these automation
processes do not have the capability to perform workflow automation across systems of work
much less the enterprise. Surveying indicates that over 60% of electronic content is either
routed from or routed to others. In addition, 43% indicate they have workflows that are not
automated, and 28% of FTB indicated they do not know. Examples of workflow automation are:

Electronic data capture workload uses workflow automation functions via IPACS for
routing of imaged data.

Filing enforcement program uses limited workflow automation functions via INC. The
INC system has the capability for more mature workflow automation; however, due to
performance issues, it is not used to its fullest capability.

Collection program uses ARCS to move cases from state to state and to create work
lists for collectors to work; however many of the functions require manual intervention
and there is little ability for automatic exception handling.

Audit program uses PASS for candidate selection via modeling, to store electronic
content related to the case, and to change and track case status; however many of the
functions require manual intervention.

16 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

Return validation programs use RV/TI and BETS for limited workflow automation to
identify returns requiring manual processing, holds, and review. RV and BETS
returns the case to the user until all required conditions are addressed and the return
is validated.

Content managers and approvers of content on the FTB Intranet use the CUT to change
and approve content posted to the FTB Intranet web pages. The CUT changes the
status of the web page to approval needed once changed and sends emails notifications
when the page has been changed requiring approval, and when the page requires
rework or is approved.

Incident managers of FTB systems use Unicenter to enter information related to


production system incidents, outages, and issues, which creates a problem ticket.
Unicenter routes the problem ticket to the appropriate staff for resolution and sends an
email notification for each stage of the process.

IT Helpdesk staff use Unicenter to enter requests for IT services, which creates a service
request ticket. Unicenter routes the service ticket to appropriate staff for resolution and
sends an email notification for each stage of the process.

Business analysts, system testers, and system developers use ClearQuest to enter IT
system and application change requests, which creates a change request ticket.
Unicenter routes the change ticket to the appropriate staff for handling, changes the
ticket status and sends an email notification for each stage of the process.

Content managers and approvers of content on the FTB external website use Teamsite
to approve and post content. Teamsite changes the status of the web page to approval
needed once changed and sends emails notifications when the page has been changed
requiring approval, and when the page requires rework or is approved and ready to be
loaded (e.g. posted to the external website).

17 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

2.4 Enterprise Content Management


2.4.1 ECM Technical Architecture
Currently, FTB does not have an enterprise ECM system or process. The department uses
numerous systems and processes to perform its ECM needs as FTB ECM methods were
developed in silos instead of with an enterprise focus. ECM components and capabilities are:

2.4.1.1 Capabilities and Components


Capture – FTB creates content through three main input systems - Tandem, Image
Processing and Cashiering System (IPACS), and the e-gateway. There are also other
input processes for third party data, postal mail, tax supporting documents, etc. The
department receives this content in a variety of methods; fax, phone conversations,
postal mail, email, FTP, on-line, paper receipt, etc. Additionally, numerous in-house
processes exist that generate content within FTB to support business functions.

Manage – FTB manages content through folder organization and/or file name variations.
Tax document management is the most mature process using the IPACS and e-gateway
database and storage platforms. Other FTB processes use a variety of tools and
processes like Microsoft SharePoint, Serena PVCS Version Manager, Microsoft Visual
SourceSafe, IBM Rational ClearQuest, etc.

Store and Retrieve – FTB uses a variety of methods for storage of both paper and
electronic content, including paper storage in the warehouse to electronic storage on a
server/SAN. FTB performs retrieval in a variety of methods, from actual manual paper
file pulling and routing to automatic electronic workflow routing. The main retrieval
applications for tax documents are e-View and the Image Delivery Application (IDAX).

Preserve – FTB performs long-term retention of content in numerous ways with


redundancy across systems. Different methods and processes, from batch processing to
manual updates control varying retention timeframes from system to system.
Deliver – FTB delivers content from system to system using a variety of methods; from
case management tools to applications designed specifically to deliver and control
content (e.g., e-view and IDAX).

Collaboration – FTB does not generally share content in a centralized fashion or method
except for some in-house tax document processing systems. However, MS SharePoint
is being used for project collaboration on several projects.

Security – FTB controls security independently from platform to platform and usually
controls it within the application by the use of an access/authorization table. Various
content security methods are used including authentication, password protection, and
physical security access.

18 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

Figure 2.4-1: FTB Content Management Process - Current


FTB Content Management Process (Current)

Tandem- Data
Paper Receipt Data Collection (Long-Term Storage - Partial Data )

Manual Paper Manual Keying


Movement
(Trucks and Manual Keying
- Keybase Software
Trays) - Partial Data
HP Non-Stop
Receiving

Accounting System
IPACS - Images and Data Data Only
Data Collection (Long Term Data Storage)
(Long-Term Storage – Partial Data)
Centralized

Validation
Scanning OCR Capture/KFI

Field Level OCR


- Inscript Software
- ICBS KFI
-Partial Data
SAN Storage Oracle Database BETS & TI Databases
(Images) (Data) (Data)

eGateway- Data
(Long-Term Storage - ALL Data )
Electronic
Receipt
Swift

Web Services

Validation SQL Database


(Data)
IDAX Applicaton

Users
- Only Tax documents are being collected.
- No Tax Supporting Documents are being collected, i.e.. White mail.
- Users have to know if return is paper or electronic to use the appropriate viewing application.
- Only Partial data is being collected from the paper processes.
- All data is being collected from the electronic processes.
- Paper is still being stored by the department.
- No other Non-tax workloads are being imaged. eView Application
- Multiple databases are performing long-term storage and retention.

2.4.1.2 Content Management Solutions


The ECM Task Force identified 29 content management solutions in use at FTB in 2007. They
determined that only six of the solutions are true content management solutions. The remaining
23 were not true content management solutions but being used in that manner. Table 2.4-1
identifies tools currently used. The tools listed in the table on the top are identified as true
Content Management solutions. The tools listed in the table on the bottom are not true content
management solutions, but are identified as being used in that manner.
Table 2.4-1: FTB Content Management Tools
Content Management Tools
eRoom (EMC Natural ISPF (Software PVCS Version SharePoint Teamsite
Documentum) AG) Manager (Serena) (Microsoft) (Interwoven)
Tools Used for Content Management
ARCS AutoForms (Adcorr) BETS CalATERS INC
Crystal Reports Extra Personal Client Content Update Tool Macromedia -
New Tax Comp
(Seagate) (Attachmate) (CUT) RoboHelp
Rational ClearQuest Rational Robot
PASS System PAWS SENDIT
(IBM) (IBM)
SQL Reporting TDM (Test Data
TI Unicenter
Service (Microsoft) Management)
19 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

2.4.2 ECM Business Architecture

2.4.2.1 Electronic Content Types


Table 2.4-2 depicts the 12 categories FTB identified for electronic content and examples of
each category. Analysis of FTB‟s electronic content has determined content is often duplicated
through various media. For example, the same content is frequently found via the web, email,
and local area network (LAN).

Table 2.4-2: Electronic Content Types

EC Category Examples
Organizational Flow Charts, Meeting Agendas, Meeting Minutes,
Administrative Duty Statements

Business Performance / Monthly Reports, Inventory Reports, Business Plans, Annual Reports, Statistical
Management Reports Reports

Business Process ARM Procedure Manuals, ARCS Release Planning, Audit Procedure Manuals,
Procedures Strategic Plans, Return Validation Manuals

Business Process Procedure Manuals, Application Code, System Code, System Requirements
Rules
Financial Reports, Financial Statement Worksheets, Budget Change Proposals,
Financial / Budget Schedule 3 Documents
Emails, Compressed Files, Data Files, Image Files, Video Files
Miscellaneous

Project Plans, Project Charters, Project Documents, Project Templates


Project

Schema Documents, System Change Requests, ARCS E-Lien Electronic Files,


System / Technical PASS Help Files, System Requirements
Taxpayer Notices, Taxpayer Correspondence, Revenue Reports, Audit Work
Taxpayer Related Papers
Tax Publications, Legislative Change Proposals, Tax Schedules
Taxation Related

Training Training Materials, Training Brochures, Training Schedules, Training


Presentations
Web Web Forms, Bureau Web Pages, Web Procedures, Project Web Pages

20 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

2.4.2.2 Electronic Content Statistics


The following provides statistical information as related to the current FTB ECM capabilities and
components. The percentages represented below are a cross section of FTB:

Capture – over 70% of the electronic content types are created using a Microsoft product
(Word, Excel, Visio, PowerPoint, Publisher, Outlook, FrontPage, Project, Access,
Internet Explorer, .NET). A distant 2nd is Adobe Acrobat/Reader with 6%.

Manage – approximately 70% of the time, FTB manages electronic content (i.e. version
control) through folder organization and/or file name variations. The majority of FTB‟s
sections are not clear on what version control is. Of those surveyed, 25% listed „Other‟
tools for managing electronic content as listed below:
o Microsoft SharePoint
o Serena PVCS Version Manager
o Microsoft Visual SourceSafe
o Interwoven TeamSite
o eRoom
o Autoforms
o IBM Rational ClearQuest
o McAfee HelpDesk
o Macromedia RoboHelp

(Note; “ERoom, Autoforms, IBM Rational ClearQuest, McAfee HelpDesk and Macromedia
RoboHelp are not considered version control tools. It may be possible staff are using these tools
to manage electronic content even if that is not the primary function of the tools.)

Store and Retrieve – about 90% of content at FTB is easily located; however, survey
results indicate redundancy is an issue.

Preserve – approximately 70% of FTB is not concerned with the need to centralize and
automate the retention of content.

Deliver – over 60% of electronic content is either routed from or routed to others. In
addition, 43% have workflows that are not automated and 28% of FTB does not know.

Collaboration – over 56% of the electronic content requires collaboration, which is


performed via email and shared network folders. About 20% of all electronic content
types are shared with others external to FTB.

Security – approximately 43% of the electronic content requires identity management.


Business Process Modeling

21 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

2.5 Business Process Modeling


2.5.1 Business Process Modeling Technical Architecture
FTB uses two tools for Business Process Modeling. These tools perform other main functions
but can be used for Business Process Modeling. Below are the tools FTB is currently using for
Business Process Modeling:
Microsoft Visio – Microsoft Visio has pre-built templates to document business
processes for process modeling, but has limited functionality.
Sybase PowerDesigner – includes object-oriented analysis and design capabilities, but
mostly focuses on data models.

Due to the limitations of these tools, EAC continues to research modeling tools that will be more
robust and better suit FTB‟s needs.

2.5.2 Business Process Modeling Business Architecture


FTB has adopted Business Process Modeling Notation (BPMN) as the notation standard and
has begun documenting business processes as related to the main tax processing systems
using Sybase PowerDesigner. The department currently has business process models for the
business processes related to the following systems:
BETS
BE ARCS
E-Gateway
IPACS
INC
NRWS
PASS
PIT ARCS
SBRD
Tandem
TI/RV

These business process models include major activities, most sub-activities, and many tasks.
In addition, the models identify the FTB sections responsible for the activities and the roles
performing those activities.

22 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

2.6 Business Rules Management


2.6.1 Business Rules Management Technical Architecture
FTB does not have an enterprise business rules management tool or repository. Various tools
are used to document, change, add/delete, and maintain business rules. These tools include but
are not limited to MS Word, MS Excel, Visio, MS SQL, MS Access, ClearQuest, macros, and
system/application coding tools.

FTB recently purchased Micro Focus Modernization Workbench, as part of the EDR project, to
extract, document, and analyze business rules from system application code such as COBOL,
Natural, JCL and Java.

2.6.2 Business Rules Management Business Architecture


FTB does not have an enterprise business rules management process. Various tools as listed
above are used to document and store business rules. Generally, business staff document and
request changes to the business rules while technology staff change, test, and execute them.

While there are common methods used throughout FTB, each business area utilizes their own
method for documentation, change control, and storage of business rules. FTB documents,
changes, and stores business rules in various locations including requirement documents,
system specifications, procedure manuals, memos, system/application code, change requests,
and business flows. Because of the various documentation methods, rule visibility is regularly
an issue.

Often, multiple areas document the same business rules as the same rule frequently applies to
multiple business programs and processes. On the other extreme, some business rules have no
formal documentation, and very well may be buried deep in code with knowledge of the rules
residing only in the minds of staff associated with the business or code.

Frequent changes in law, policy, or procedures necessitate business rule changes. While in
some cases, rules can be changed “on the fly” (for example, TI has this capability for some
rules) some business rules can only be changed once a year due to the potential risk of
changing the rules and the need for extensive testing of the change. Ease of change is lacking
due to the inconsistent methods FTB uses for business rules management.

23 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

3.0
3.1 Overview
The target architecture for business process management with an enterprise focus at
FTB includes:
A mature Enterprise Architecture Council
An expanded BPM Center of Excellence
A mature BPM Governance process
A mature BPM methodology
A mature process management method
A robust BPMS and corresponding technologies

While a primary focus of this architectural definition is Business Process Management


technologies, in particular the capabilities and benefits of a BPMS, and how they would fit
within FTB, it is crucial to establish an enterprise BPM methodology and BPM Governance
for successful and efficient business process management at FTB.

3.1.1 What is BPM Governance?


Governance is a framework for decision and accountability that produces desirable outcomes
within the organization. BPM governance framework determines the what, who, and how of
enterprise business process decision-making.

3.1.2 What is BPM methodology?


Simply stated, BPM methodology is an approach an organization uses to manage its business
processes. BPM consolidates objectives and methodologies, which have been proposed in a
number of approaches including Business Process Reengineering, Process Innovation,
Business Process Modeling and Business Process Automation/Workflow Management. BPM is
widely recognized as a foundation for contemporary management approaches as it goes via the
analysis of business processes to the roots of an organization. BPM methodology requires
focus at the enterprise level on the:
Way people in the organization think – thoughts, expectations, and conclusions, of the
members of the organization
Norms – often referred to as corporate culture, the standards, models, and patterns
which guide behavior
Systems and processes – processes and technologies used to do business

24 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

A mature BPM methodology requires holistic organizational management practices, with top
management understanding and involvement, process-aware information systems, well-defined
accountability and a culture receptive to business processes. It is based on a process
architecture, which captures the interrelationships between the key business processes and the
enabling support processes and their alignment with the strategies, goals, and policies of an
organization. BPM methodology provides an approach for managing and improving business
that allows decisions that affect the business‟ performance, processes, or strategies be based
on first-hand data, analyzed in a scrupulous manner and tested for authenticity in the real world.
The desired outcome is providing quality, low-cost, fast results for the organization.
Following a BPM methodology is critical. Organizations are in transition and long-standing
business practices may be in flux. BPM further drives and guides change. The management
discipline of BPM itself is not static; it too must respond to change. Strict governance and
procedures must be in place for business rule management and approval of process change.
Organizations must understand how better process management enables agile response to
change. The focus on improved process management forces the organization to adopt a greater
focus on process discipline. The only motivation for senior leadership to embrace such a
disruption to the status quo must lie in the promise of a significant benefit to the organization.

Increased business agility is one of the many outcomes realized from adopting BPM. The gains
realized through new BPM management practices and enabling technologies propel agility
throughout the organization. BPM requires business managers to learn real-time management
skills to achieve greater business agility. Those skill sets include collaboration and consensus
building. Shared control between business managers and IT managers shortens the cycle time
to make process improvements. IT development staff must leave behind the long-held belief
that they alone must perform all the front-end analysis and process design. IT managers must
proactively encourage a progressive shift to shared responsibility for these activities with
business process analysts, business managers and process owners.

3.1.3 What is process management?


Whatever the process may be, process management means confirming that procedures are in
place to ensure staff execute critical activities required to improve productivity and guarantee a
level of control to best manage the organization. The particular process is almost irrelevant
because every process should be managed in essentially the same way. Smart organizations
use process management as the driver behind process steps and let the experts handle the
actual tasks involved in the process.

3.1.4 What is a Business Process Management Suite (BPMS)?


A BPMS is a software set facilitating the process management aspects of business process
management, including process design, workflow, applications, integration, and activity
monitoring for both system and human-centric environments. A BPMS supports business in
defining, modeling, simulating, deploying, executing, monitoring, analyzing, and optimizing their
business processes. BPM suites offer tools (software) and solutions (integration) that depict,
analyze, and measure KPIs for business process optimization and workload management.

BPMS technology places the control of processes back in the hands of business but does not
completely eliminate IT from BPM. A BPMS addresses the desire of business managers at FTB
to see and gain hands-on control of their business processes to manage work outcomes better.

25 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

3.1.5 BPM Lifecycle


The figure below (Figure 3.1-1: Business Process Management Lifecycle) depicts the lifecycle
of process management and indicates the potential roles in each phase of the BPM lifecycle.
The diagram also illustrates the continuous flow of the BPM lifecycle.

Figure 3.1-1: Business Process Management Lifecycle

26 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

3.2 BPM Technical Architecture


3.2.1 Overview
As a software infrastructure platform, a BPMS enables business and IT professionals to work
collaboratively on process design, development, execution, and enhancement activities. A
BPMS makes processes clearly expressed and readily changeable and delivers both speed of
change and a way to focus improvement. Additionally, a BPMS enables an enterprise focus to
ensure the relevancy and impact of change at the enterprise level. FTB‟s BPM technology will
provide graphical models that enable managers to control various aspects of business
operations and invoke the relevant resources.

A BPMS environment contains all the operating information and the context of their
execution. This information is available and reusable. The BPMS tools allow authorized persons
to look up comprehensive information, confirm it, and redesign the operation knowing the
impacts, simulate changes, compare costs and improvements, and decide on the best action.
If a complete BPMS has been used as the foundation for this change environment, business
managers working with data analysts will be able to generate the applications that manage their
workflows and the overall processes, track work, and monitor performance. These operating
management applications are generated from a combination of business models and rules
definitions that are linked together. To provide the needed foundation, the BPMS environment
delivers the models and information on the business, the rules, the performance, the
applications, and the data flow that allows for proper application. Because this information
is integrated within the BPMS, it can be accessed and changed quickly with the operating
management applications being automatically generated and regenerated to support
any change.

The result is speed. In this environment, it is now possible to change the business operation, its
application support and its data access quickly. Additionally, if the IT group has moved to an
SOA (service-oriented architecture) based application and enterprise data access approach
(e.g. enterprise data warehouse), these changes may be able to happen in days. Legacy
application function and data interface changes are sometimes still a problem, but in many
cases, the automation support can be generated outside the legacy environment to save time
and improve flexibility.

Realizing the true potential of operational improvement requires flexible teams that are open to
using a range of tools and optional methodologies to deliver both immediate improvement and
focused continuous improvement. This mixture of disciplines should also take advantage of the
speed that BPM and BPMS tools can deliver. It is this immediate impact that allows an
operation to reach and sustain optimization.

27 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

3.2.2 BPMS Flow


The figure (Figure 3.2-1: Business Process Management Suite Flow) below depicts the tools
and flow of a BPMS.

Figure 3.2-1: Business Process Management Suite Flow

3.2.3 BPMS Tools


A complete, robust BPMS will contain these core BPM-enabling tools:

Simulation and Optimization Tools – enables business managers to compare new


process designs with current operational performance. Executes scenarios, altering
resource constraints and business goals, to assess risk and display the financial and
operational impact on an organization.

Orchestration Engine – coordinates the sequencing of the activities and steps (system
and manual) according to the flows and rules in the process model.

28 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

Rules Engine – executes rules that abstract business policies and decision tables from
the underlying applications, and makes process changes more flexible. A rules engine is
a software system that executes one or more business rules in a runtime production
environment. It is commonly provided as a component of a BPMS which, among other
functions, provides the ability to: register, define, classify, and manage the rules, verify
consistency of rules definitions, define relationships between different rules, and relates
some rules to applications that are affected or need to enforce one or more of the rules.

Enterprise Rules Repository – contains process definitions, process models, business


rules, and business rule data to enable reuse across business functions. The rules
repository is a centralized repository of all business rules and information about the rules
and has the capability to externalize rules outside the process implementation.

Enterprise Service Bus(ESB) – links the model to other system assets (data and logic)
that support work steps. An ESB is a collection of components that comprise the
foundational services for more complex architectures via an event-driven and standards-
based messaging engine “the bus”.

Business Intelligence and Analysis Tools – provides business activity monitoring tools to
support analysis of data produced during process execution. Capabilities range from
reporting to online processing analysis to graphical user dashboards in real time with
proactive alerting.

3.2.4 BPMS Supported Activities


A BPMS will support the following core BPM‐enabling activities:

Modeling and analysis of business processes – including all aspects of workflow to be


managed (that is, tasks, roles, decisions, approvals, reviews, escalations, collaborations,
flows, rules, policies, forms and other business information objects, events, goals,
objectives, and scenarios) to identify the best possible design.

Round‐trip engineering between the model and its physical implementation – changes
made to the model are easily reflected in the execution and changes to the resources
are easily fed back into the model.

Manipulation and management within the process context – with access to various forms
of business content (both structured and unstructured information).

Monitoring, reporting, analysis and notification of work activities and business events –
using both data about completed work transactions and in‐flight business transaction
data (in real time and offline, potentially for predictive analysis).

Process simulation and optimization – using real‐time, historical and estimated


data values.

Management of all process components – (refer to Section 3.2.3) through the life cycle;
that is, access control, versioning, and descriptive metadata

29 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

3.2.5 Process Monitoring and Operational Business Intelligence


The BPMS's graphical process model will allow business managers to see and directly monitor
and manage interactions between human, system and information resources and adjust
behavior and execution flow in response to changing dynamics and improve business
performance. The BPMS will give visibility to the Business Activity Monitoring data, which
provides event-driven, real-time access to process performance. This provides users with
historical and real-time access to process execution, provides alerts and allows users to act on
problems in real-time. Graphical user dashboards, online analytical processing analysis, and
reports will all be available via this monitoring process.

Operational Business Intelligence (BI) focuses on providing real-time monitoring of business


processes and activities as they are executed within computer systems. Operational BI will
incorporate triggers, events, rules, and advanced analytics, which will allow for decision-making
in real time. Data is captured at a point in time saved by persistent data logging for future
matching of situations and patterns. FTB will develop and maintain a central data repository.

3.2.6 Process Model Execution and Simulation


The BPMS will allow users to design the process models, and execute the models in a
simulation environment. Making a model executable requires other BPM-enabling software such
as integration technology, a runtime environment and rule engines. To support the entire
process life cycle, from modeling through execution to monitoring, the process model will
become the core of the business process. This environment will use both historical and real-
time data to perform the model simulation to test how the design works with other processes
and with any constraints placed on the processes. The BPMS tools are used to design and build
the process models, and store the models in a single process repository.

3.2.7 Workflow Automation


The BPMS will provide for enterprise electronic workflow management that is seamless
between processes, systems, and organizational structures. It will be able to integrate the
case management processes or other business processes with ECM workflows and document-
oriented processes provided by an ECM solution. It will automate business processes, in whole
or part, passing documents, information, cases, or tasks, from one participant to another for
action; according to defined business and procedural rules.

The workflow automation solution will provide the capability for the workflow system to route
exceptions to different work queues. It will also allow workflow managers to change business
rules easily, and make workflow routing decisions automatically based on those rules.

3.2.8 Digital Asset Management


The BPMS and corresponding technologies will provide for digital access management. This
includes the tools necessary for cataloguing, storing, and retrieving digital assets, including
images, audio recordings, and video. The BPMS will establish a library for digital content in a
centralized archive allowing broader, faster, and easier access to the content. The digital
archive will categorize the content and allow users to quickly identify and view the content
through customized portals. The archive will also retain and automatically delete content based
on FTB defined retention rules.

30 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

3.2.9 Enterprise Content Management


The goal is to provide an architecture that will address current and future departmental
Enterprise Content Management (ECM) needs while being a scalable, portable, dynamic
service. The ECM solution will provide SOA capabilities that provide and consume services for
interfacing, receiving, delivering, and storing electronic content. FTB already possesses the
major components needed to consolidate workloads into enterprise ECM processes. By
leveraging our current capabilities and expanding these capabilities, we could assemble the
resources to target short-term gains, and address the long-term goal of providing FTB ECM
services. (Figure 3.2-2: FTB Content Management Process – Target) depicts the target ECM
architecture.

Capture – both electronic and paper content will be funneled through a centralized
common process for validation, storage, delivery, retention, etc. This common process
routing allows FTB to utilize enterprise services. Current electronic content methods will
continue. Paper content will be collected using two input methods, centralized scanning
and satellite scanning. Centralized scanning will be by a common departmental system
that is scalable for FTB‟s large volume workloads. Satellite scanning will take place at
the document‟s originating source and would handle sensitive, postal mail, field scanning
processes, small workloads, administrative processes and tax supporting documents.
Satellite locations will route scanned images through the central common “imaging
pipeline” into the centralized archive for storage and retention.

Manage – specialized ECM systems will exist based on content category types. Tax
workloads use archives to process, and store, the content outside of the databases and
have a “pointer” to the content. This saves on overall database size, recoverability, back-
up times, etc.

Store and Retrieve – storing all content into a centralized archive will provide a single
point for the management, storage, retrieval, delivery, collaboration, and security. The
archives will also contain documents from FTB‟s out-going processes, for example,
notices, correspondence, etc.

Preserve – storing all content into a centralized archive will allow for consolidation of
retention timelines. Retention will be automated and will be based on workflow and case
management processes.

Deliver – establishment of an enterprise document viewing service. Establishing a single


enterprise document viewing service will provide greater efficiency and reduce costs
incurred by maintaining separate applications/processes. Any system or application will
use the service.

Collaboration – ECM Collaboration will be identified and provided through business


process management and a BPMS.

Security – ECM security falls into three main areas; authorization, authentication, and
electronic data interchange. The Identity and Access Management and Electronic Data
Exchange Architecture Definitions address this.

31 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

Figure 3.2-3: FTB Content Management Process - Target

FTB Content Management Process (Phase 4)

Paper Receipt Data Collection IPACS - Images and Data Accounting System
Centralized (Short-Term Storage – ALL Data) Data Only
Scanning OCR/ICR Capture/KFI (Long Term Data Storage)
Field Level OCR/ICR
Receiving

- Inscript Software
- ICBS KFI
-Partial Data
Satellite
Full Page OCR SAN Storage
Scanning - New Software
Oracle Database
- ICBS KFI (Images) (Data) BETS & TI Databases
(Data)
Metadata Collection
eGateway- Data
- ICBS (Short-Term Storage - ALL Data )
-Sensitive Areas Users
Electronic - Satellite Locations
EDI Service

Receipt

Web Services FTB Applications


(Taxpayer Folder, PASS,
INC, BETS, TI, etc.)
SQL Database
Validation (Data)
Service
ECM Archives
Enterprise Viewing
(Long Term Content and Data Storage) Service

Centera Archive SAN Storage Authentication and


Storage Database Authorization Service

- Establish PIT supporting document scanning.


- Tandem to IPACS workload conversion finished, retire Tandem, All data is collected now.
- Paper is no longer being stored by the department, retire CDTS system.
- Satellite scanning for „Non-tax‟ FTB workloads (Financial, Budget, Admin, etc.)
- Satellite Scanning and Metadata collection established for field office workloads
- Move Authorization and Authentication into Enterprise Service
- Transition from Document Archives into ECM Archives (All data types into archives)
- Collect and Store Faxes, Emails, Phone Calls, Text Messages into ECM Archives
- Move Enterprise Viewing Application into Enterprise Viewing Service called by applications
- Move Swift into Enterprise Electronic Data Interchange Service
- Move Validation into Validation Service used during data collection, not post processing

3.2.10 Open Standard System, Development Platforms, and Enterprise Service Bus
The BPMS and corresponding technologies will be open, modular, interoperable with any
FTB system or application, and based on SOA. It will also support system message routing,
message queues, and transformation and data access through a component such as an ESB.
The BPMS will also provide the ability to create multiple environments (e.g., Development,
Staging, and Production) to facilitate authoring, modifying, compiling, deploying, and
debugging the software.

32 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

3.2.11 Process Modeling and Business Process Analysis


Process models are events that trigger action and the sequences of steps and the business
rules used in and between those steps to support decision-making and execution flow. Process
models are needed to help business and IT managers understand actual processes, analyze
the processes, and enable them (by visualization and simulation) to propose improvements.

The BPMS will provide a business process-modeling tool in a shared environment for the
capture, design, and simulation of business processes by business analysts, managers,
architects and other staff. This tool is a modeling-only environment, not an execution
environment. This tool will support the BPMN and BPEL standards, so it can work and
communicate with other BPM technologies as acquired. This tool will be the initial step in
supporting the BPM initiatives and enterprise architecture and will be used to create “as-is”
and “to-be” process models.

The business process-modeling tool will provide process-modeling capabilities that are easily
changeable by non-technical managers. These models provide a basis for cross-organizational
collaboration between managers responsible for the separate parts of a process, and with IT
staff on the implementation of the resulting design. To support simulation, models will embrace
characteristics such as roles, skills, availability, and costs of the people, and other resources
that perform the process as well as frequency and escalation conditions.

The business process-modeling tool will provide a framework to follow for modeling processes
and a fully functional dashboard allowing business staff visibility into the processes and their
interactions. This allows business users to view graphically the processes and their interactions.

3.2.12 Business Rules Management


The BPMS will provide a Business Rules Repository (BRR) to contain business rules for any
functionality such as process modeling and workflow management. The BRR is a centralized
repository of all business rules and information about the rules for proper execution (such as
rule type, Meta data, etc.) and has the capability to externalize rules outside the process
implementation. The BRR will make the rules available to be used as services for driving
external workflow and/or modeling. The BRR will allow business staff to store, analyze, and
modify business rules. A BRR allows for any system or application to access and use the rules,
and reduces or eliminates the need for imbedded business rules in system or application code
reducing the time required for modifications.

The BPMS will also provide a Business Rules Engine (BRE) that is a component of the BPMS,
managed independently from processes and workflows, for business rule execution and
management. The BRE will provide decision tables and trees to assist in execution of the
business rules.

33 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

3.3 BPM Business Architecture


3.3.1 Overview
Organizational, cultural, and process changes for how FTB does business will be necessary
for successful BPM implementation. In addition, implementation of a BPMS will occur. These
changes will enable FTB to provide quality, low-cost, prompt results to its customers
consistently. The table below (Table 3.3-1 Target Business Architecture for Key Elements)
depicts target business architecture for key elements at FTB.

Table 3.3-1: Target Business Architecture for Key Elements


Elements Target
Governance Have established methodologies, standards, models, patterns, and governance to
guide behavior
Organizational Be a process-centric organization - meaning FTB will organize the achievement of
strategic and tactical goals around standard, repeatable and actively managed
business processes, providing predictable results
Align people, work, and capital to the processes that create customer value
Centralize control and management of FTB‟s business processes
Define and establish new roles for both business and IT staff to support the new
business architecture. Such as: Chief Process Officer, Process Owner‟s Council,
Process Architect, Process Owner, Process Manager, Process Supervisor,
Process Engineer, Process Analyst, and Process Performer
Eliminate gaps between business functions and between business and IT
Cultural Promote enterprise thinking
Foster value-creating business processes, where everyone focuses on FTB‟s
goals and KPIs
Identify and establish process owners
Make business details visible and understandable by all
Make business decisions using real-time and historical data, and
predictive analysis
Make as common practice, training of the new roles, standards, models,
processes, tools, etc. for both IT and business staff
Business managers will have real-time management skills to achieve greater
business agility
Processes Have detailed models for all core business processes
Make business processes highly visible and agile
Make continuous improvements to business processes and simulate the
outcomes prior to implementation
Establish ownership and control of business processes in the hands of business
staff, with IT enabling business processes
Automate business processes where work will be passed seamlessly across
organizational lines as necessary
Manage, store and retrieve electronic content centrally
BPMS Make a robust BPMS available to the enterprise
Incorporate all business processes into the BPMS gradually
Assure business and IT staff are fully trained on the use of the BPMS

34 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

3.3.2 Enterprise Architecture Council


The EAC will continue to plan the architecture of FTB with a focus on the four sub-categories of
Business, Process, Management and IT. The EAC will continue to be a key member of FTB‟s
governance structure and be responsible for further developing, as well as, refining enterprise
architecture maturity, architecture assurance, and enterprise architecture deliverables.
The EAC will be crucial to enterprise acceptance and adoption of BPM Governance, an
enterprise BPM methodology, as well as having a significant role in ensuring the acquisition
of a BPMS and corresponding technology meets FTB needs and adheres to FTB architecture.

3.3.3 BPM Center of Excellence


The BPM CoE will continue as an organizational component of the EAC and will expand its role
in BPM at FTB, becoming a BPM strategic planning body. The BPM CoE is a cohesive and
collaborative team of FTB staff from around the department led by the EAC Business Solution
Architect. The BPM CoE primary tasks include planning and governance activities, and
supporting the implementation and maturation of BPM at FTB. The BPM CoE offers a "one-stop
shop" providing services to multiple BPM initiatives enabling the enterprise to transition to
process-centric from the current function-centric siloed organization by implementing BPM
and its governance. The BPM CoE will be vital to successful enterprise BPM at FTB.

The key objectives of the BPM CoE will be to:


Align FTB BPM initiatives with State and Agency policies and standards
Support FTB‟s vision, goals, strategies, and principles
Recommend process management controls and standards
Recommend governance processes
Develop FTB business process maps
Define process roles and responsibilities
Increase BPM awareness throughout FTB

Items of significant focus for the BPM CoE will be:


Defining an FTB BPM methodology and attaining and promoting enterprise adoption
Continuing to refine and analyze the business process maps (models) for the major
tax systems
Developing a practical and comprehensive BPM governance strategy which includes
governance for managing business processes and business rules through the eight
stages of the BPM Lifecycle; Define, Model, Simulate, Deploy, Execute, Monitor,
Analyze, and Optimize.
Creating a detailed end-to-end business process map for FTB‟s
administrative processes
Obtaining further knowledge about FTB business processes with a focus on discovering
efficiencies that can be gained

35 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

3.3.4 BPM Governance


The work of the EAC and the BPM CoE will define BPM Governance, with expectations that the
Internal Business Action Committee (IBAC) will be the strategic governing body. It is anticipated
as part of the Governance process, it will be necessary to form a Business Process Owners
Council as a strategic and tactical governing body. Refer to the Governance EAD for
more information.

3.3.5 BPM Methodology


FTB will develop a BPM Methodology for enterprise adoption. Common critical BPM
methodology success factors include:
A structured approach
Organizational and cultural change
Alignment with corporate goals and strategies
Focus on customer needs
Process measurement, improvement and management
Top management commitment
Benchmarking
Process-aware information systems, infrastructure, and realignment

FTB will require change to assure success in these areas and to strive for BPM maturity.

3.3.5.1 Value Creating Business


FTB will concentrate on value-creating business with identification of its value-propositions and
value-chains, which are the first steps in identifying its core business processes, and process
steps. A value proposition is an analysis and quantified review of the benefits, costs and value
that an organization can deliver to customers and other constituent groups within and outside
of the organization. Put simply, the value proposition is what the customer receives for their
money/time. A value chain is a chain of activities. Products pass through all activities of the
chain in order and at each activity, the product gains some value. Examples of likely FTB Value
Propositions and Value Chains include:

Table 3.3-2: Value Proposition and Value Chain Examples


Value Propositions Value Chains
Law to Filing Method
Filing Method to Refund
Information Exchange
Filing Method to Payment in Full (PIF)
Filing Method to Collections
Collections to PIF
Compliance
Assessment to PIF
Incompliant to Compliant
Effective New Employee to Valued Employee
Employees Untrained Employee to Fully Trained Employee
Working Employee to Paid Employee

36 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

3.3.5.2 Organizational Change and Structure

Organizational Change

FTB will be a process-centric organization. A key factor in successful implementation of BPM


is to “change the way an organization thinks”. BPM is a management discipline that requires
organizations to shift to process-centric thinking, and to reduce their reliance on traditional
territorial and functional structures.

For most of the industrial age, enterprises (including FTB) have been organized as a collection
of common tasks or functions, such as design, finance, manufacturing, operations, and so on. In
the latter part of the 20th century, new organizational structures emerged, including product-line
(where all the functions for a single product are collected), and matrix (where expertise from
functional organizations is brought in and assigned to projects). More recently, Lean practices
have further evolved these models into business architectures that align people, work, and
capital to the processes that create customer value. BPM calls on the organization to adjust its
business architecture to foster value-creating business processes directly. The process-driven
organization treats these business processes as a portfolio of valuable corporate assets. BPM
techniques are used to explicitly define and execute processes in a manner that creates
significant benefits. New roles and new ways of thinking and doing business are necessary
for realizing the full benefits BPM makes possible, doing more and better, at less cost.

FTB will centrally control and manage business processes and define and establish new roles to
support the business processes. BPM requires creation of new roles that cut across functional
stovepipes to support the process-centric business. Some of these roles and the definition of
those roles include:

Chief Process Officer – executive responsible for defining and enabling the enterprise
process architecture, who fosters the process-centric business culture, including skills,
systems, and behaviors.

Process architects – individuals who design and construct models and frameworks for
the core and enabling business processes, including workflows, KPIs, and control plans.

Process owners – individuals responsible and accountable for the performance of end-
to-end processes.

Process engineers – individuals who build run-time business processes, including the
composition of orchestrated services, composite applications, and systems of
measurement, notification, and control.

Process analysts – experts who define what events should be monitored, diagnoses
process problems, and prescribes performance solutions.

Process performers – individuals who not only work inside a process, but also
understand how they fit within an extended value stream.

37 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

Organizational Structure

To obtain the maximum benefits of implementing BPM techniques, FTB must change its
organizational structure to facilitate becoming process-centric. The FTB organizational structure
will recognize the interdependencies and relationships that foster value-creation across the
enterprise. FTB must de-emphasize hierarchical reporting relationships and empower
employees to seek improvements across organizational boundaries.

What does a process-centric organization look like? There will still need to be some functional
alignment, there is no one fit for all – a best fit is needed aligning like processes that center on
FTB customers and value propositions. The figure below (Figure 3.3-1; Example Target
Organizational Structure Model) illustrates a target organizational model that places focus on
process-centric structural organization. The model depicts an organization that “sits” on the
value-creating business framework, identifying the organizations‟ value-propositions, resources,
customers, and regulatory and social environment. It de-emphasizes hierarchical reporting,
emphasizes enterprise collaboration and sets a foundation to identify core business processes.

Figure 3.3-1: Example Target Organizational Structure Model


Regulatory & Social Environment - Law, Policy, Directives, Social Trends

Chief Executive Employee


Officer Core Processes Services
Governance Council Office
CEO, CLO, CSO, Chief Employee
CFO, CTO, CIO, Information Compliance
Services Officer
CCO, CESO Office Office
Chief Information Chief Compliance
Human
Officer Officer
Action Advisory Resources Office

Customers - Taxpayers, Governor, 3rd Parties, Employees


Commitees Councils HRO
Resources - People, Capital, Technology, Vendors

Business Data Office Audit Office


Process Data Services DO Physical Security
AO
Governance Governance Governance Office
PSO

Communications Accounts Facilities Office


Legal Office Receivable Office FO
Office Support Processes
CO ARO
Chief Legal
Officer Knowledge Office
Information Enforcement KO
Strategy Enterprise Project Oversight Governance Security Office Office
Office Planning Office Office Services Office ISO EO
Chief Strategy EPO POO GSO EEO Office
Officer EEOO

Information Compliance
Financial Budget & Procurement Process Office Process Office Employee
Office Accounting Office Office IPO CPO Services Process
Chief Financial BAO PO Office
Officer ESPO

Technology Infrastructure Operations Information Compliance Employee


Office Office Management Process Office Systems Support Services Systems
Systems Support
Chief Technology IO Office PO Office Support Office
Office
Officer OMO ISSO CSSO ESSO

Value Propositions - Information Exchange, Compliance, Effective Employees

38 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

Process-Centric Organization – Process Examples

Aligning the FTB organizational structure to its value-propositions and value-chains, will position
FTB to clearly identify its business processes, and assure those business processes are in-line
with the process-centric organization.

The following figure (Figure 3.3 2: Business Process before Process-Centric Organization)
represents a before picture and (Figure 3.3 3: Business Process after Process-Centric
Organization) represents an after picture of a business process after process-centric
organizational alignment.

Figure 3.3-2: Business Process before Process-Centric Organization


Taxpayer\
Law/Policy
Practitioner Filing Method to Refund -
Function-Centric
FMS Create Filing Design Filing Test Filing Organization
FD Rules Methods Methods

ESS Create Filing Test Filing Capture Filing Retain Filing


TSD Methods Methods Info Info

CMS Create Filing Deploy Filing


AD
Methods Methods

SMS Deploy Filing


TSD Methods

ICBS Capture Filing


FD Info

IPACS Capture Filing


TSD Info

Process Create
IVS
Filing Info Refund
FD

BES Process Create


FD Filing Info Refund

Retain Filing Create


TI Refund
Info
TSD

BETS Retain Filing Create


TSD Info Refund

CCSS
Transmit
TSD Refund Info

Intercept
SCO
Agencies

39 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

Figure 3.3-3: Business Process after Process-Centric Organization


Filing Method to Refund -
Process-Centric
Organization

Law/Policy Taxpayer\
Practitioner

Create Filing Design Filing Create Filing Test Filing Deploy Filing Capture Filing Process Retain Filing
Information
Rules Methods Methods Methods Methods Info Filing Info Info
Office

Deploy Filing Create Transmit


Technology Methods Refund Refund Info
Office

SCO

Intercept
Agencies

3.3.5.3 Cultural Change


BPM adoption inevitably requires cultural change and can trigger resistance to improving
processes coming from inertia, the politics of power, and fear - all of which FTB must overcome
to achieve real BPM success. The key to acceptance of change is organizational engagement -
getting all parties to see the positive net benefits and originate changes that will be as desirable.
FTB can accomplish this through sound change management and communication methods.

BPM provides for bringing all dimensions of a business together, and enables new levels of
participation and collaboration among teams - especially between business staff and IT staff.
The greatest barrier to change is communication. BPM lowers this barrier by increasing the
direct and immediate lines of communications and collaboration among all process participants.
Responsibilities of those involved in a BPM effort are as follows:

Leadership team:
o Articulates the strategic imperative for change
o Communicates the vision for a process-centric organization and the approach for
a continuously improving enterprise
o Authorizes structural adjustments
o Trumpets the results

Process teams:
o Agree on the metrics of business process performance
o Share process models and common business semantics
o Clearly communicate about the tasks to be performed

Everyone is:
o Authorized, empowered, and compelled to measure and analyze performance
o Participates in the design and implementation of new ways of working
o Continuously improves performance outcomes

40 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

FTB will consider how its culture will need to change for successful BPM implementation and
adoption. To facilitate cultural change towards enterprise thinking:

FTB Focus – will move more towards enterprise unity, for example, by avoiding divisive
terms to describe the organization. Terms such as Division, Section, and Unit – all drive
to separatism. Examples of better terms to foster a vision of enterprise unity are: Office,
Bureau, Group, and Team.
Management Focus – will move more towards vision, customers, value and results. It
will be less important for managers to know how to do the work, but to enable their
employees to do the work - that is assuring employees have the right knowledge, tools,
capacity, and empowerment to do the job. Management will encourage an environment
where they can say for example: “last year 100 people, this year 50 people, doing the
same work faster, cheaper, better."
Employee Focus – will move more towards analysis and improvement of the work vs.
doing the work. Employees will fully understand the vision, reason, desired outcome,
and consequences of the work they do, and the interaction with and affects of what they
do with other areas of the department. BPM-enabled workers see processes more
clearly, are able to analyze and understand them, and participate directly in making
improvements.

3.3.5.4 Business Process Management Maturity


FTB will use the Business Process Management Maturity (BPMM) model illustrated in Figure
3.3-4 to target reaching full BPM maturity and will achieve BPMM when fully evolved to Stage 5.
The BPMM level of an organization provides a way to predict the future performance of the
organization for a given domain or set of domains. Experience has shown that organizations do
best when process improvement efforts are focused on a manageable number of process areas
that require increasingly sophisticated practices. It is important to note that the BPMM model
measures BPM maturity, and not the maturity of business processes. Currently FTB is
positioned at around 1.5 on the BPM maturity level.

41 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

Figure 3.3-4: Business Process Management Maturity Model

Business Process Management Maturity Model

Level Management Focus Process Areas Goals

Implement continuous Planned innovations


Change
Maturity Level 5 proactive improvements to Change management
Management
Innovating achieve business goals Capable processes

Manage process and results Stable processes


Maturity Level 4 Capability
quantitatively and exploit Reuse/knowledge mgmt.
Predictable Management
benefits of standardization Predictable results

Develop standard processes, Productivity growth


Maturity Level 3 Process
measures, and training for Effective automation
Standardized Management
product & service offerings Economy of scale

Build disciplined work


Work Unit unit management to stabilize Repeatable practices
Maturity Level 2
Management work and control Reduced rework
Managed
commitments Satisfied commitments

Motivate people to overcome


Maturity Level 1 Fire-fighting
problems and just "get the
Initial Management Get the job done
job done"

Maturity Level Descriptions

The table below (Table 3.3-3 Five BPM maturity levels) depicts the five maturity levels briefly
described in terms of their management focus and primary objective.

42 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

Table 3.3-3: Five BPM maturity levels


# Name Description

“Fire-fighting management” – The objective is to “keep the lights on”, solving each crisis
1 Initial as it becomes apparent. Success in these organizations depends on the competence
and heroics of the people in the organization and not on the use of proven processes.

“Work unit management” - The objective is to create a management foundation within


2 Managed
each work unit or project. Enterprise processes are not standard.

“Process management” - The objective is to establish and use a common organizational


3 Standardized process infrastructure and associated process assets to achieve consistency in how
work is performed to provide the organization‟s products and services.

“Capability management” - The objective is to manage and exploit the capability of the
4 Predictable organizational process infrastructure and associated process assets to achieve
predictable results with controlled variation.

“Change management” - The objective is to improve continuously the organization‟s


processes and the resulting products and services through defect and problem
prevention, continuous capability, and planned innovative improvements. Change
5 Innovating
management utilizes standardized methods, processes and procedures to facilitate
efficient modifications and a balance between the need for change and the impact of
change.

BPMM Indicators

The following table (Table 3.3 4: Comparison of Low and High BPMM Indicators) lists a
comparison between low and high maturity for common indicators of BPMM level.

Table 3.3-4: Comparison of Low and High BPMM Indicators


Low Maturity High Maturity
Un-coordinated, isolated projects Coordinated BPM activities
Low BPM skills High BPM expertise
Reactive Proactive
Manual Meaningful automation
Internally focused Extended organization
Low resource Efficient resourcing
Naïve Comprehensive understanding
Static Innovative

Continuous process improvement is based on both small, evolutionary steps and process
innovations. BPMM provides a reference model for organizing these evolutionary and innovative
steps into five maturity levels that lay successive foundations for continuous process
improvement.

43 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

3.3.5.5 Process Management


FTB will adopt process management methods and tools. Smart organizations use process
management as the driver behind process steps and let the experts handle the actual tasks
involved in the process. It may take some time to help others understand the difference between
process management and process steps – it can be a little overwhelming the first time trying to
grasp it. But as long as the right procedures are in place to ensure teams execute critical
activities, business will benefit from the increased productivity and efficient operations that a
strong process management focus brings. Specifically, process management should always
include the following activities:

Enabling Process Steps – regardless of the work groups, databases, or people involved,
all processes consist of actual tasks that must be completed for the process to work
properly. These tasks are called process steps. Effective process management
recognizes that the success of a process rests with those most qualified to perform and
complete the process steps. These people are the experts – the doers. If they have a
strong process management system supporting them and enabling the tasks that they
need to complete, they can get the job done effectively. To be sure the proper
assistance is given to any process, FTB must clearly identify every step of the process,
regardless of whether technology or humans support the process.
Creating a Process Design – process design examines the internal and external
workflows and processes that impact an organization and outlines a path to ensure all
aspects of those workflows and processes are interlocked. By reducing requirements for
users or improving a process so that fewer steps are required, process design helps
drive specific process steps through enterprise linkage, provision of best-of-class
procedures, and recommendations for the best solution for the function and enterprise.
Outlining Process Roles – another key area of process management that drives process
steps to completion are the people involved and their process roles. Someone must
oversee the processes, ensure compliance and usage, deploy the tools involved, and so
on. Not everyone with a role in a process must perform the process. Therefore, without
strong definitions of which roles are active and which are passive, it is possible to
implement a process that has an awful lot of talkers and few doers.
Implementing a Process Management System – another aspect of driving process steps
to completion is the implementation of a process management system. This is a
reporting method to help stakeholders track how processes are performing and alert
them to process concerns that could affect other areas of the business. Additionally to
track how changes to or issues with the process are being communicated and resolved.
Using Strategic Planning – knowing the organization‟s strategic plan and direction can
help determine process strategies. Business strategy should always be considered in
process management. The process design should fit the organization‟s current business
model and be flexible enough to change if the business model changes. Considering
business strategy as process design is developed and other aspects of process
management can help pinpoint rising trends and identify where processes should remain
flexible to meet future demands.

While a BPMS is not necessary for process management, a BPMS facilitates most of
these activities.

44 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

3.3.6 BPMS and Business Architecture


The following table (Table 3.3-5: BPMS Components in Relation to Business Architecture)
depicts how the FTB utilization of a BPMS will transform the business architecture across
the enterprise.

Table 3.3-5: BPMS Components in Relation to Business Architecture


BPMS Component Business Architecture
Process Monitoring Business intelligence will be performed via the BPMS.
Modeling and scoring (e.g. for compliance) with access to all date,
rd
including 3 party data will be performed via the BPMS.
Real-time monitoring of business processes will occur.
Both historical and real-time process data will be available to make
informed business process decisions.
Process stakeholders will receive real-time alerts when process
issues arise.
Process Simulation Changes to business process will be simulated using real data before
executing process changes.
Process simulation will allow business process stakeholders to know
the impacts of changes on other business processes prior to
executing changes.
Workflow Automation Workflow automation will be the same and seamless across the enterprise
for core business processes.
Process stakeholders will be immediately able to change the business
rules to route workflows differently based on need.
Digital Asset Digital assets will be annotated, categorized, easily retrievable, and
Management automatically eliminated once their retention period has expired.
Enterprise Content Enterprise Content Management will be managed the same and seamless
Management across the enterprise
All FTB content will be stored electronically
Electronic content will be easily retrieved, viewed and delivered.
Electronic content will be secured as appropriate using consistent
security methods.
Electronic content will be automatically eliminated on its retention period
has expired.
Process Modeling Models of all cores business processes will be created.
Use of process models will make business processes visible.
Use of process models will allow for graphical representation of all
business process steps and related information.
Use of process models will be for analysis, design, simulation, and
continuous business process improvement.
Business Rules Business rules will be identified, compiled, and stored centrally in a
Management Business Rules Repository.
Business rules will be standardized, centralized, non-redundant, and
separated from the business processes.
Business rules will be visible and easily analyzed and changed by
business staff.
Any business process will access and utilize the same business rules.

45 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

4.0
4.1 Technical Architecture
A BPMS will make processes explicit, which are visible, via graphical models and will be
independent of physical resources used in execution. BPMS tools enable organizations to
document, analyze and streamline complex processes, thereby allowing business areas to
become more agile and effective. FTB will procure a BPMS solution to close gaps between
current state and target BPM architecture.

Table 4.1-1: Technical Architecture Gap Analysis

Gap Category To Close Gap Benefit


Simulation and Implement: Manages business risk by providing process
Optimization Tools o Process simulation, simulations
monitoring, and modeling Increases efficiency by providing data for
tools continuous process improvement
o In conjunction with a BRR Increases transparency and visibility of the
processes
Orchestration Create detailed business Improves application agility - business
Engine process maps specifying analysts can change the process themselves.
process flow Decreases complexity of application code
Implement: Improves reusability of the components and
o An orchestration engine services as control context specific logic is
o In conjunction with a BRR not included
Business Rules Implement: Defines the relationships between different
Engine (BRE) o A business rules engine rules
o In conjunction with a BRR Provides decision tables and trees to assist
in execution of the business rules
Decreases
o Costs associated with business logic
modification
o Development time
o Risk associated with changes
Externalized rules are easily shared among
multiple applications
Business Rules Create a centralized repository Increases agility by
Repository (BRR) of all business rules and o Allowing for quicker changes
information about the rules for o Allowing any system/ application to
proper execution (such as rule access and use the rules
type, Meta data, etc.) o Allowing business staff to store,
Implement in conjunction with a analyze, and modify rules
BRE o Reducing/eliminating rules in imbedded
application code
Enterprise Service Implement a message broker Decreases time and money required to
Bus between applications accommodate existing systems
Increases flexibility; easier to change as
requirements change
Increases scalability from point-solutions to
enterprise-wide deployment (distributed bus)
Increases configuration rather than
integration coding

46 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

Gap Category To Close Gap Benefit


Decreases down-time with incremental
patching
Business Implement: Increases visibility to the Business Activity
Intelligence and o Graphical user Monitoring data (event-driven, real-time
Analysis Tools dashboards access to process performance)
o Online analytical tools Increases quality of decisions through the
Processing analysis use of historical and real-time process
Reports execution data
Increases efficiency by providing alerts to
problems in real-time
Digital Asset Establish a library for digital Increases efficiency through:
Management content in a centralized archive o Broader, faster, and easier access to
Establish processes for the digital content
lifecycle of digital content o Categorization of the content
o Automatic enforcement of defined data
retention rules
Increases customer service by providing
content through customized portals
Enterprise Expand imaging to include all Decreases storage space with the elimination
Content document types and workloads of paper documents
Management (in phases) Increases efficiency with single point storage
(ECM) Expand scan and shred policy and retrieval
for all documents imaged Consolidates/automates content retention by
Establish: preserving content in a centralized archive
o Standardized OCR Reduces and possibly eliminates mainframe
capable forms file and print services
o A centralized document Reduces costs associated with:
archive o Maintaining multiple document viewers
o An enterprise document o Processing paper documents
viewer
o Scalability in the imaging
system
o Workflow for imaged
documents based on
business processes

47 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

4.2 Business Architecture


A key component of a BPM initiative is the redefinition of the role of the business as a partner in
BPM. Business will not only participate in defining the processes, but also in defining the goals
of the BPM effort and selection of the BPM tools. This will be a significant shift from IT staff
taking the lead to business and IT sharing responsibility, which will require organizational and
cultural changes. FTB will implement BPM to close gaps between current state and target
BPM architecture.

Table 4.2-1: Business Architecture Gap Analysis

Gap Category To Close Gap Benefit


Governance Define an FTB BPM Increases quality of decisions
methodology and attain and Increases strategic alignment of business
promote enterprise adoption processes and goals
Develop a practical and Decreases total cost of ownership through
comprehensive BPM standardization of processes
governance strategy including
governance for managing
business processes and rules
Define standards, models, and
patterns and attain and promote
enterprise adoption
Organizational Define and establish new roles Increases agility and efficiency
for business and IT staff to Decreases total cost of ownership through
support the new business alignment of resources to processes
architecture Increases effectiveness through clearly
Eliminate gaps between defined roles and responsibilities
business functions and between
business and IT
Align people, work, and capital
to processes creating customer
value
Centralize control and
management of business
processes
Implement standard, repeatable
and actively managed business
processes providing predictable
results to achieve strategic and
tactical goals
Cultural Promote enterprise thinking Increases loyalty to the entire organization
Establish process owner roles rather than to the sub-group
and responsibilities Increases the quality of decisions
Avoid divisive terms to describe Increases ownership in the processes
the organization. Foster a vision through process ownership
of enterprise unity by using Decreases total cost of ownership through
terms like: Office, Group, and standards and models
Team Increases collaboration towards common
Direct management focus goals
towards vision, customers,
value and results

48 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

Gap Category To Close Gap Benefit


Determine value-propositions
and value-chains. (Requires
asking such questions as Why
are we doing what we do? What
is the ultimate result? Who are
our primary customers” What do
our customers want from us?)
Foster value-creating business
processes focusing on goals
and key performance indicators
(KPIs)
Make as common practice,
training of the new roles,
standards, models, etc. for both
IT and business staff
Increase employee focus on
analysis and improvement of the
work vs. performing the work
Make business decisions using
real-time and historical data,
and predictive analysis
Increase BI support and/or
collaboration with the BPM area
Processes Create detailed models for all Increases visibility into FTB‟s business
core business processes processes
Make business processes highly Decreases dependency upon heroes
visible and agile Decreases process cycle time
Identify FTB‟s value- Decreases manual analysis/routing
propositions and value-chains Increases efficiency:
Establish ownership and control o By focusing on FTB‟s value
of business processes in the propositions and chains
hands of business staff, with IT o Through automation of previously
enabling business processes manual processes
Manage, store and retrieve o Through consistent, documents
electronic content centrally methods
Make continuous improvements
to business processes and
simulate the outcomes prior to
implementation
Automate business processes
where work will be passed
seamlessly across
organizational lines as
necessary
Monitor processes and identify
and correct those broken

49 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

5.0
5.1 Technical Architecture Roadmap

Figure 5.1-1: Technical Architecture Roadmap

2009 2010 2011 2012 2013 2014


ID Task Name Start End
Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1
1 Orchestration Engine 10/01/2008 12/31/2012
Create detailed business process maps
2 10/01/2008 12/31/2012
specifying process flow
3 Implement orchestration engine 10/03/2011 06/01/2012
4 Simulation and Optimization Tools 10/03/2011 06/01/2012
Implement process simulation, monitoring,
5 10/03/2011 06/01/2012
and modeling tools
6 Business Rules Engine (BRE) 10/03/2011 06/01/2012

7 Implement a business rules engine 10/03/2011 06/01/2012


8 Business Rules Repository (BRR) 10/03/2011 06/01/2012
Create a centralized repository of all
9 business rules and rules information for 10/03/2011 06/01/2012
proper execution (e.g., rule type, Metadata)
10 Enterprise Service Bus 07/01/2011 11/01/2012
Implement a message broker between
11 07/01/2011 11/01/2012
applications
12 Business Intelligence and Analysis Tools 01/02/2012 12/31/2012
13 Implement graphical user dashboards 01/02/2012 12/31/2012
14 Implement online analytical tools 01/02/2012 12/31/2012
15 Digital Asset Management 10/01/2008 12/31/2013
Establish a library for digital content in a
16 04/02/2012 12/31/2013
centralized archive
Establish processes for the lifecycle of digital
17 10/01/2008 12/31/2013
content
18 Enterprise Content Management (ECM) 01/01/2009 12/31/2014
Expand imaging to include all document
19 01/01/2009 06/29/2010
types and workloads
Expand scan and shred policy for all
20 03/05/2010 05/05/2011
documents imaged
21 Tools Governance Implementation - pre EDR 07/01/2010 06/29/2012
22 Establish standardized OCR capable forms 07/01/2010 07/01/2011
23 Establish a centralized document archive 07/01/2011 12/31/2013
24 Establish an enterprise document viewer 07/01/2011 12/30/2011
25 Establish scalability in the imaging system 07/01/2011 03/30/2012
Establish workflow for imaged documents
26 01/02/2012 12/31/2014
based on business processes

50 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

5.2 Business Architecture Roadmap

Figure 5.2-1: Business Architecture Roadmap

2009 2010 2011 2012 2013 2014


ID Task Name Start End
Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1

1 Governance 04/01/2010 09/30/2011


Define an FTB BPM methodology and attain and promote
2 04/01/2010 07/01/2010
enterprise adoption
Develop a comprehensive BPM governance strategy
3 04/01/2010 07/01/2010
including governance for business processes and rules
Define standards, models, and patterns and attain and
4 04/01/2010 09/30/2011
promote enterprise adoption
5 Organizational 04/01/2010 06/29/2012
Define and establish new roles for business and IT staff to
6 04/01/2010 06/29/2012
support the new business architecture
Eliminate gaps between business functions and between
7 04/01/2010 06/29/2012
business and IT
Align people, work, and capital to processes creating
8 07/01/2011 06/29/2012
customer value
Centralize control and management of business
9 07/01/2011 06/29/2012
processes
Implement standard, repeatable and actively managed
10 07/01/2011 06/29/2012
business processes providing predictable results
11 Cultural 01/01/2009 12/27/2013
12 Promote enterprise thinking 01/01/2009 07/01/2013
13 Establish process owner roles and responsibilities 01/01/2010 12/30/2011
Implement new vocabulary to describe the organization
14 04/01/2010 07/01/2010
like: Office, Group, and Team
Foster value-creating business processes focusing on
15 07/01/2010 12/30/2011
goals and (KPIs)
16 Increase BI support and/or collaboration with the BPM area 07/01/2010 12/27/2012
Implement training of the new roles, standards, models,
17 07/01/2010 12/27/2013
etc. for IT and business staff
Increase employee focus on analysis and improvement of
18 07/01/2010 12/27/2013
the work vs. performing the work
Make business decisions using real-time and historical
19 01/03/2011 12/30/2011
data, and predictive analysis
Direct management focus towards vision, customers, value
20 01/03/2011 07/01/2013
and results
21 Processes 01/01/2009 12/31/2014
22 Create detailed models for all core business processes 01/01/2009 12/30/2010
23 Make business processes highly visible and agile 07/01/2010 06/29/2012
24 Identify FTB's value-propositions and value-chains 07/01/2010 12/27/2013
Establish ownership and control of business processes
25 07/01/2010 12/30/2011
with business staff, with IT enabling business processes
26 Manage, store and retrieve electronic content centrally 07/01/2011 07/01/2013
Make continuous improvements to business processes
27 06/01/2012 04/01/2014
and simulate the outcomes prior to implementation
Automate business processes where work will be passed
28 06/01/2012 06/02/2014
seamlessly across organizational lines as necessary
29 Monitor processes and identify and correct those broken 06/01/2012 12/31/2014

51 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

5.3 Dependencies

Implementation of a robust and comprehensive BPMS at FTB will be dependent upon these
technical architectures:
Service Oriented Architecture (SOA): There is a two-way relationship with SOA. BPMS
tools will be used to design the system-to-system process flows. BPMS also relies on
SOAs for monitoring and changing processes. SOA will be required to be truly process
centric. With the implementation of SOA, business users will be able to use business
application modeling to record the activities within a database and analyze how things
are working. Users can execute their process changes within the systems in real-time
with SOA. This gives users control of systems in the end-to-end processing
Data management: Store models, flows, rules, etc. Data management will be important
for data quality assurance
Identity and Access Management: Used to define and control the workflow. The
implementation of the IAM architecture will ensure that workflow rules can be enforced
as processes move between systems and staff
BI: Provide information about process and workflow results
ECM: For unstructured data, BPMS could supply the workflow Implementation of
comprehensive and successful BPM at FTB will be dependent upon the following
Establishing Governance and a BPM methodology
Organizational and cultural changes
Establishing process management

52 | P a g e
May 2010 Enterprise Architecture Council
Enterprise Architecture Definition – Business Process Management

6.0

6.1 BPM Glossary

6.2 BPMS Standards

6.3 BPM Best Practices

53 | P a g e
May 2010 Enterprise Architecture Council