News Stay informed about the latest enterprise technology news and product updates.

Enterprise Architecture in Banking

This article is a continuation in the series on enterprise architecture.

This article originally appeared on the BeyeNETWORK.

This month, I will continue the series of articles on enterprise architecture. In my first article, I introduced the basic concepts of enterprise architecture. Last month, I discussed the principles of strategic modeling for the rapid delivery of enterprise architecture. 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 is of 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 worldwide 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.

In my second article on strategic modeling, I discussed the importance of developing an enterprise architecture portfolio plan. This is used to manage development of a project map for the rapid delivery of priority business activities and processes into production in three-month increments. The EAPP is derived using entity 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 one 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. 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 and 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 two-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 subprojects, as discussed shortly.


Subset of Strategic Model for the Bank

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.

You will recognize the lines joining related boxes 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 is also related to industry needs.
  • All of these 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.  

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 two-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. More than 50 of the bank’s senior managers attended this two-day session, along with their expert banking staff. At the break, the coffee was served 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 still 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 southwest 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 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 previously.

This highlights the importance of the strategic model: it is a common communication medium for all. We will see in the next section 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 column 6 – why) with organization units (in column 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. 

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 column 6 (why) with data in the strategic model in column 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 bidirectional 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.

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 subproject. 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 subproject, called market need activity. The listed entities in the cluster are all bold. This indicates that this is an independent, prerequisite subproject that is reusable. The project plan is shown by phase numbers (followed by a right bracket) preceding each listed entity. It indicates the subproject 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)



                                         3)MARKET NEED (MARKET NEED ACTIVITY)

This derived project plan in outline format shows that to implement this subproject, 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 as market and need, which are each in phase 2, and also period in phase 1.

Figure 5: Derivation of project plan for the market need activity subproject.

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.

The cluster report window in Figure 6 now shows that the market plan activity is dependent on market need activity as a prerequisite reusable subproject, as the latter subproject entities are all shown NOT BOLD.

This is an important principle of entity dependency analysis. By identifying market need activity as a prerequisite subproject, 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 in bold. The required entities for the market need activity 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 subproject. This is shown by the project map at the bottom of Figure 7. We see that the market plan activity is a stage 2 subproject. It is dependent on the market need activity, which is a prerequisite, reusable stage 1 subproject.

The market plan activity subproject, including the market need activity as a prerequisite subproject, is shown now in Figure 8 as a Gantt chart.

Figure 8: Market plan activity Gantt chart.

The cluster in Figure 8 clearly indicates the phase dependencies for later logical data modeling (column 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”(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 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, 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 subprojects were the focus for subsequent priority logical data modeling subprojects.

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 subproject and related subprojects, 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.

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 subproject and related subprojects, 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. The second document is the original strategic information systems plan (SISP) report in English, to be downloaded as an example of an EAPP report. 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 thus they have not been placed on the Internet. The IES Web site 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 subprojects and related subprojects, shown in Figure 12. This was defined to attribute detail through logical data modeling over a further three months.
  3. The second business unit was the product management subprojects and related subprojects, shown in Figure 13. This was defined to attribute detail through logical data modeling also over three months.
  4. These two business unit subprojects 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 the aforementioned step 4: 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 (Artech House, Norwood MA, March 2006). I will cover these technologies in a later monthly article.  

Download the 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 theIES Web Site. The news release of the project can be downloaded in PDF from. The SISP Report of this commercial bank project can be downloaded as an example of an EAPP Report in 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 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 Project references, project steps and descriptions are available from Click on the  Projects link from any page. Clive may be contacted at [email protected].


Dig Deeper on Enterprise data architecture best practices