Enterprise Architecture in Banking

By Clive Finkelstein

Contents

Enterprise Architecture in Banking .................................................................................................. 1

Contents....................................................................................................................................... 1
Introduction .................................................................................................................................. 1
Banking Case Study .................................................................................................................... 1
Strategic Plan was the Catalyst for the Strategic Model.............................................................. 2
Subset of Strategic Model for the Bank ....................................................................................... 2
Identification of Business Activities at the Bank........................................................................... 4
The Strategic Model is a Common Communication Medium ...................................................... 4
Strategic Alignment of Bank to Strategic Model .......................................................................... 5
Derivation of Project Plans from Strategic Model ........................................................................ 7
Refinement of Business Activities from Strategic Model ........................................................... 10
Development of Project Maps for Rapid Delivery ...................................................................... 11
Summary of Project Results for the Bank.................................................................................. 13
Download Bank’s Enterprise Architecture Portfolio Plan Report ............................................... 13
Clive Finkelstein ......................................................................................................................... 14

Introduction
This month I will continue the series of articles on enterprise architecture.
In my first article I introduced the basic concepts of enterprise architecture
(see http://www.ies.aust.com/pdf-papers/bi-ea01.pdf) Last month I
discussed the principles of strategic modeling for the rapid delivery of
enterprise architecture (see http://www.ies.aust.com/pdf-papers/bi-
ea02.pdf) This month I will show how these principles were used by a
regional bank to manage its evolution to enterprise architecture by using
strategic modeling to develop its enterprise architecture portfolio plan
(EAPP) in just 20 days.

Banking Case Study

The banking case study in this series of real-world enterprise architecture projects was for an
innovative regional bank. Since 1994 this bank had used banking systems implemented using
distributed client / server technologies, which was quite unusual for banks at the time. Most banks
use mainframe systems. In fact, in 1995 this bank was selected as one of the 100 most
innovative installations world-wide by Computerworld USA.

However these banking systems were found to be inflexible and unable to change to support the
Internet. As a result, a project was initiated to redevelop these systems for electronic banking.
This was a large project that used strategic modeling to develop project maps to manage the
progressive implementation for rapid delivery of priority banking systems.

I discussed in my second article on strategic modeling the importance of developing an enterprise

architecture portfolio plan (EAPP) [ED: Please insert a link to my second article in BI-EA02.doc].
This is used to manage development of a project map for the rapid delivery of priority business
activities and processes into production in 3-month increments. The EAPP is derived using entity

Page 1
dependency analysis of the strategic model, as also discussed in that second article. We will see
examples of project map derivation in this current article relating to the bank.

The project team comprised banking experts as well as IT experts. An initial strategic model was
first developed in 1 day with the IT management project team, then refined and expanded in two
further days in a facilitated strategic modeling session with bank managers and their business
experts. I discussed strategic modeling in last month’s article [ED: please insert a link here to the
article BI-EA02.doc]. The strategic model was entered into a modeling tool for the automatic
application of entity dependency analysis and for development of the enterprise architecture
portfolio plan (EAPP) documentation for the bank over a total elapsed period of four weeks. The
results were then formally presented to managers and their business experts on the last day, for
review.

The strategic information systems plan (SISP) of this project, as an example of an enterprise
architecture portfolio plan (EAPP) report developed from the strategic model, can be read and
downloaded from the IES Web Site using links that I will provide at the end of this article.

Strategic Plan was the Catalyst for the Strategic Model

The catalyst for this strategic modeling project was the bank’s strategic business plan. This
included its mission, vision and directions. It addressed the bank’s goals, objectives and defined
key performance indicators (KPIs). It covered strengths, weaknesses, opportunities and threats
(SWOTs) of the bank.

These planning statements were discussed by the bank managers and their expert staff in a 2-
day facilitated modeling session. (In last month’s article I discussed how a facilitated modeling
session is conducted, to define a strategic model.) As they agreed on key things that were
important to manage, the facilitator documented this on a whiteboard as a “picture of the
business”. This “picture” was the strategic model of the Bank.

The strategic model that was developed was analyzed automatically by a modeling tool using
entity dependency analysis, as discussed last month. The results were documented in a strategic
information systems plan (SISP) report. It identified priority databases and systems for early
delivery. The project plans derived from the strategic model were then used for the precise
management of each of these early delivery sub-projects, as discussed shortly.

Subset of Strategic Model for the Bank

Page 2
Figure 1: Part of the strategic model for the bank

The screenshot in Figure 1 is a subset of the bank’s strategic model. It indicates the key areas
based on the bank’s strategic plan. These are boxes in Figure 1, representing data entities.

The lines joining related boxes you will recognize as associations or relationships. But to the bank
managers these lines represent: management controls; reporting paths; communication paths;
audit controls; security controls or governance controls that are needed in this “picture of the
bank” to ensure that all required security, governance and audit issues are addressed. The
strategic model shows the following:

• The bank is interested in many Markets. Each Market must have at least one Need that
the bank can address, to be relevant to the Bank, as indicated by Market Need
(highlighted in Figure 1).

• Each Market has many Customer Satisfaction Indices (CSIs) and a CSI can apply to
many Markets, as indicated by Market CSI.

• A Market has many Market Plans. Plan is outside the displayed screenshot, but Plan is
also related to Branch Plans – of which there are many for each Branch.

• For each Industry (outside the displayed screenshot) Industry Risk is also associated with
Market Plans. Industry also is related to Industry Needs.

• All of the above are time-dependent, as indicated by Period. They all must be managed
closely by the bank over time.

As discussed in Figure 1, the bank had established the mandatory business rule that a Market –
to be of interest to the bank – must have one or many Needs that the bank could address. A
Need also may be held by many Markets as shown in Figure 2.

Page 3
Identification of Business Activities at the Bank
Figure 2 shows the decomposition of this many to many association at the top of the figure into
an intersecting entity Market Need at the bottom: this represents the Market Need Activity. This is
an important concept: the decomposition of many-to-many associations indicates (through the
resulting intersecting entity) the existence of business activities, processes or systems.

Figure 2: Identification of the Market Need Activity

The Strategic Model is a Common Communication Medium

There is an interesting anecdote that I would like to share with you; this arose during the 2-day
facilitated modeling session to define the bank’s strategic model. After the first two hours into the
facilitated session, when I had documented part of the strategic model on the electronic
whiteboard following discussion of their strategic plans, we stopped for coffee. We were in a
large auditorium (with tiered seating) in the bank’s head office. Over 50 of the bank’s senior
managers attended this 2-day session, along with their expert banking staff. At the break, the
coffee was served to all of us at the back of the auditorium, way up high. I was dying for a coffee
and was about to climb the stairs when one of the bank managers came down to the front to ask
me a question.

He pointed to a part of the strategic model on the whiteboard that was his area of responsibility in
the bank. He was very concerned about how other competitor banks, through the internet, could
attract his regional customers. I was able to answer his question by pointing to another part of the
bank that was also represented in the strategic model.

He had a further question, which I also answered from the strategic model. Soon we were in deep
conversation for 15 minutes. I was dying for a coffee, when I noticed out of the corner of my eye,
a group of bank staff by the coffee machine; they were pointing at the two of us way below in the
depths of the auditorium. They were laughing, which I thought was quite strange: in fact, it was a
little rude. And then it hit me why they were laughing …

Now let me tell you about the bank. The bank’s name was Kwangju Bank, in the city of Kwangju –
a 40 minute flight south-west of Seoul in South Korea. The banker was talking to me in Korean;
he knew no English. I was answering in English; I knew no Korean. This is what was apparently
so humorous to the bank’s staff at the coffee machine. Yet he and I understood each other
perfectly: because we were both using a picture of the bank, its strategic model!!! We could
clearly see what the other was referring to, as the strategic model was a picture of the data and
information used by the bank, together with clear representations of the business rules, the

Page 4
management controls, audit controls, security controls, reporting paths and governance controls.
And then I thought:

If he and I can understand each other using this common communication medium across
language barriers, there is indeed promise that management and IT will eventually
understand each other, as they also both speak a different language.

What was difficult in this enterprise architecture project was that the bankers had been discussing
their strategic plan in Korean, which I do not understand. Fortunately, the sponsoring bank
manager spoke both Korean and English. He stood by my side, translating from Korean to
English so I understood what they were saying. He translated my questions from English to
Korean and translated their answers back into English. This was not easy, but it worked. In fact, it
was the reason why I defined an initial strategic model on the previous day with the management
project team. I was concerned that I had to communicate the strategic modeling principles (that I
introduced in last month’s article) in business terms across this language barrier, I then used this
initial strategic model as the catalyst to start the two-day facilitated session with all of the bank
managers as discussed above.

This highlights the importance of the strategic model: it is a common communication medium for
all. We will see in the next topic that it later enabled the managers to evaluate the effectiveness of
some of the planning statements in their strategic plan, to manage various activities in the bank
through strategic alignment matrices derived from the strategic model.

Strategic Alignment of Bank to Strategic Model

The matrix in Figure 3 shows the Bank’s planning statements listed as goals and objectives down
the left as rows, with functional areas or business units of the bank listed across the top as
columns (called “Model Views” in Figure 3).

Based on the Zachman Framework, this matrix shows the alignment of business plans (in Col 6 –
Why) with organization units (in Col 4 – Who). Reading across a row it indicates – with a tick in
each column – all of the business units that are involved in that objective. This answers the
question: “who is involved in implementing that objective?” Reading down a column of Figure 3,
the matrix indicates – with a tick in each row – all objectives where a business unit is involved.
This answers the question: “why are they involved?”

This is a matrix that is used to achieve strategic alignment, to ensure that all planning statements
are properly managed for effective implementation of the business plan. This and other strategic
alignment matrices are an important deliverable of strategic modeling.

Page 5
Figure 3: Coordination of goals and objectives throughout the bank

We can see in Figure 4 the effect of these strategic alignment matrices. This is the result of a
matrix that aligns business plans in Col 6 (Why) with data in the strategic model in Col 1 (What),
that is needed to support the achievement of those plans. The bidirectional alignment in Figure 4
is achieved by a Planning Statement - Data matrix.

In the planning dictionary (shown in the left window of Figure 4) the mission statement lists all
data needed to support that statement as “data links”. Those entities that are shown dimmed in
the screenshot are outside the organization unit that is being viewed – Marketing – which is the
current model view. Additionally, other model views that represent organization units involved in
that statement are also listed.

Similarly the data dictionary window for Marketing (the right window of Figure 4) shows for Market
Need that the mission statement is one of the statement links (Stmnt Links). It also shows other
organization unit model views that share the data.

These bi-directional links are important to know. They are automatically managed using strategic
alignment matrices that are a deliverable of strategic modeling – as well as other matrices – for
effective strategic alignment.

Page 6
Figure 4: Planning statements are aligned with the data that support those plans

Derivation of Project Plans from Strategic Model

I will now discuss how the bank derived its project plans for rapid delivery into production of its
priority business activities as systems. The cluster report window in Figure 5 shows derivation of
the project plan for the Market Need Activity sub-project. This project plan has been derived
automatically from the strategic model by a modeling tool, using entity dependency analysis,
which I discussed in last month’s article.

The cluster in Figure 5 represents a sub-project, called Market Need Activity. The listed entities in
the cluster are all bold. This indicates that this is an independent, prerequisite sub-project that is
reusable. The project plan is shown by phase numbers (followed by a right bracket) preceding
each listed entity. It indicates the sub-project phase when the attributes for that entity will be
defined during logical data modeling. It is listed with each higher phase number indented one
position further to the right in Outline Format as follows:

MARKET NEED ACTIVITY (derived)

1)PERIOD
2)NEED
2)MARKET
1)CSI
3)MARKET NEED (MARKET NEED ACTIVITY)

This derived project plan in Outline Format shows that, to implement this sub-project, Market
Need (the End-Point entity) in Phase 3 is dependent on – reading up from the bottom: the
Customer Satisfaction Index, as CSI in Phase 1; as well al Market and Need, which are each in
Phase 2; and also Period in Phase 1.

Page 7
Figure 5: Derivation of project plan for the Market Need Activity sub-project

We will later see this project plan also as a Gantt Chart in Figure 8. Furthermore, all of these
entities are bold, which indicates that this is an independent, reusable activity – as discussed
next.

Figure 6: Market Need Activity is a common, shared, reusable activity

Page 8
The cluster report window in Figure 6 now shows that the Market Plan Activity is dependent on
Market Need Activity as a prerequisite reusable sub-project, as the latter sub-project entities are
all shown NOT BOLD.

This is an important principle of entity dependency analysis. By identifying Market Need Activity
as a prerequisite sub-project, it is automatically enforcing the business rule that a Market must
have at least one or many Market Needs. We see this more clearly in Figure 7, where the
required entities for the Market Plan Activity are shown in red, and are printed as bold. The
required entities for the Market Need Activity above are also shown as NOT BOLD.

Figure 7: Derivation of project map for Market Need Activity and Market Plan Activity

As discussed last month, this shows that the Market Plan Activity is dependent on Market Need
Activity as a prerequisite reusable sub-project. This is shown by the project map at the bottom of
Figure 7. We see that the Market Plan Activity is a Stage 2 sub-project. It is dependent on the
Market Need Activity, which is a prerequisite, reusable Stage 1 sub-project.

The Market Plan Activity sub-project, including the Market Need Activity as a prerequisite sub-
project, is shown now in Figure 8 as a Gantt Chart.

Figure 8: Market Plan Activity Gantt Chart

Page 9
The cluster in Figure 8 clearly indicates the phase dependencies for later logical data modeling
(Col 1 – What, Row 3 - Designer): to define the attribute detail of each entity. The duration of the
data modeling task for each entity is later derived based on rules of thumb according to the
anticipated entity complexity, described in Chapter 7 of my latest book: “Enterprise Architecture
for Integration: Rapid Delivery Methods and Technologies”, by Clive Finkelstein, Artech House,
Norwood MA (March 2006).

Refinement of Business Activities from Strategic Model

Figure 9 documents Market Need and Market Plan activities. Previously, the Market Need Activity
was carried out in one part of the bank, while the Market Plan Activity was carried out in a
different organization unit. The activity description for Market Plan Activity as documented in
Figure 9 shows that:

“This plan addresses the needs of each market, whether domestic or overseas, for banking
and financial products and services”.

Figure 9: Definition of the Market Need and Market Plan activities

However, in the strategic review session four weeks after the facilitated modeling session, the
bank managers realized that this coordination was not being done in practice. In fact, these two
parts of the bank never communicated with each other! As a result, market plans were introduced
without any awareness of the needs of the relevant markets. This explained the reason for some
disastrous market plans that had been implemented, but which were later found to be out of touch
with relevant market needs.

The managers immediately corrected this oversight in the first paragraph of Figure 10, which
firmly aligned the marketing plans with the identified market needs. But the second paragraph of
Figure 10 was even more dramatic.

The bank had originally initiated this project because they were very concerned that overseas
banks could use the Internet to steal their regional customers. In the second paragraph of Figure
10 they expressed their realization – following the development of the strategic model and its
subsequent analysis – that the bank indeed had more to gain from the Internet than the possibility
of losing some regional customers.

They could instead use the Internet themselves to acquire overseas customers from the overseas
banks, as indicated in the last sentence of Figure 10. With this recognition by management, the

Page 10
bank’s focus immediately changed from treating this as a defensive enterprise architecture
project, instead to an offensive project.

Figure 10: Corrected activity descriptions by management

This was a key strategic change of direction for the entire bank and resulted in a major revision of
its strategic plans. Subsequently, through this overseas market expansion the bank was able to
grow rapidly and bypass many of its country competitors.

Development of Project Maps for Rapid Delivery

Together with the project plan analysis and review discussed above, a summary project map was
developed as shown in Figure 11. This summarizes the detailed project maps shown in Figure 12
and also in Figure 13.

Figure 11: Summary Project map for rapid delivery of priority activities into production

In the strategic review session senior management examined the Summary project map in Figure
11, the Customer Management project map in Figure 12 and the Product Management project
map in Figure 13 to identify priority activities for early delivery.

The Customer Management project map in Figure 12 was identified as the highest priority area
by management. The Customer Management and Customer Risk Management sub-projects
were the focus for subsequent priority logical data modeling sub-projects.

Page 11
Figure 12: Project map of Customer Management business unit, for rapid delivery of
priority activities as systems, into production

The project map in Figure 12 indicates the staged sequence for each Customer Management
sub-project and related sub-projects, shown as smaller boxes within the larger business unit
boxes. The connecting arrows indicate the necessary order of implementation. Implementation
can be by developing new systems if necessary, or alternatively by interfacing to reuse existing
systems: which can be either automated or manual. Or it can be implemented by interfacing to
third party banking packages.

Figure 13: The Project Map of the Product Management business unit for rapid delivery of
priority activities as systems, into production

Page 12
The project map in Figure 13 is for the Product Management area of the bank. This was identified
as the next highest priority area by management. It indicates the staged sequence for each
Product Management sub-project and related sub-projects, shown as smaller boxes within the
larger business unit boxes. The connecting arrows indicate necessary order of implementation.
Again, this implementation can be by developing new systems if necessary, or alternatively by
interfacing to reuse existing systems: which can either be automated or manual. Or it can be
implemented by interfacing to third party banking packages.

This bank project is fully documented on the Internet. It is available to be downloaded as a PDF
EAPP Report for offline reference. Two documents are provided. The first is a News Release in
PDF of the project, downloaded from http://www.ies.aust.com/PDF-projects/kjb/kjb-news.pdf. The
second document is the original strategic information systems plan (SISP) report in English, to be
downloaded as an example of an EAPP report from http://www.ies.aust.com/PDF-projects/kjb/kjb-
sisp.pdf. It includes a cover page for each appendix, describing the content of the appendix and
how it is used. The appendix contents are confidential to the bank and so have not been placed
on the internet. The IES web site at http://www.ies.aust.com/ includes descriptions of many other
projects, accessible via the Projects link from any page.

Summary of Project Results for the Bank

1. The total elapsed time from start to finish of the complete strategic modeling project, with
all analysis, was four weeks – 20 days, for the development of the strategic model and
documentation of the EAPP.

2. The first priority business unit was the Customer Management sub-projects and related
sub-projects, shown in Figure 12. This was defined to attribute detail through logical data
modeling over a further 3 months.

3. The second business unit was the Product Management sub-projects and related sub-
projects, shown in Figure 13. This was defined to attribute detail through logical data
modeling also over 3 months.

4. These two business unit sub-projects then both proceeded into process modeling over a
further six month period.

5. This was later followed by progressive implementation in Java.

Today, with the availability of Web Services and SOA technologies, the bank likely would take a
different approach. They would bypass the process modeling in step 4 above: they would instead
use activity modeling and activity based costing, together with workflow modeling. They would
use modeling tools that support Business Process Modeling Notation (BPMN) to model these
workflows. They would then automatically generate executable XML-based Business Process
Execution Language (BPEL) code from the workflow models, for direct execution using BPEL
engines.

I cover these rapid delivery technologies in Part 3 of my book: “Enterprise Architecture for
Integration: Rapid Delivery Methods and Technologies”, by Clive Finkelstein, Artech House,
Norwood MA (March 2006). I will cover these technologies in a later monthly article.

Download Bank’s Enterprise Architecture Portfolio Plan Report

As discussed earlier, this project was for Kwangju Bank – in the city of Kwangju in South Korea.
The strategic information systems plan (SISP) of this project, as an example of an enterprise
architecture portfolio plan (EAPP) developed from the strategic model, is on the IES Web Site at
http://www.ies.aust.com/ies-projects/project_references.htm. The news release of the project can

Page 13
be downloaded in PDF from http://www.ies.aust.com/PDF-projects/kjb/kjb-news.pdf. The SISP
Report of this commercial bank project can be downloaded as an example of an EAPP Report in
PDF from http://www.ies.aust.com/PDF-projects/kjb/kjb-sisp.pdf. It includes a number of appendix
cover pages that describe the content of each detailed appendix in the report. However, you will
understand that for reasons of Bank Confidentiality, these appendices have not actually been
published to the Internet.

Clive Finkelstein
Clive Finkelstein is acknowledged worldwide as the "father" of
information engineering, and is Managing Director of Information
Engineering Services Pty Ltd in Australia. He has more than 45
years of experience in the computer industry. Author of many books
and papers, his latest book, Enterprise Architecture for Integration:
Rapid Delivery Methods and Technologies, brings together the
methods and technologies for rapid delivery of enterprise
architecture in 3-month increments. Read the book review at
http://www.ies.aust.com/ten/ten32.htm. Project references, project
steps and descriptions are available from http://www.ies.aust.com.
Click on the Projects link from any page. Clive may be contacted at
cfink@ies.aust.com.

Page 14