SOA for Business Technology – Case Study

 

Introduction

The Case Study elaborates on the business drivers, challenges, and results of a project where service-orientation was applied to reshape an organization and the way it was set up (organizational, operational, IT). As it was driven by top-level management, it is an example of applying an SOA within a Business Technology environment.

The study illuminates how to apply the service concept especially in the architectural set-up of an organization, and how to link it to the more commonly used IT-service concept.

The Case Study is structured as follows:

  1. Background and Environment
  2. Business Drivers
  3. Challenges
  4. Approach
  5. Use of ArchiMate® Models
  6. Business Services
  7. Strategic Benefits and Goals
  8. Results Achieved

The Case Study first elaborates on the background and environment and the drivers of the project. Then it discusses the challenges and prerequisites of the project in order to be effective and go into more depth on the approach and main deliverables. Finally, it points out the main results and benefits achieved in this case. It provides a useful reference for the often-heard challenges to align IT development with business development. For each subject area, we first share some general thoughts and then focus on the specifics for this Case Study.

Background and Environment

The organizational silo and division into different units of management is a common theme across many global enterprises. In the organization in this Case Study, the IT departments and with them the IT resources and IT knowledge have through time been separated from the rest of the organization. Along with this, IT was mainly seen as a generic cost center to the business units of the organization. The goal here was synergy and cost efficiency in the IT facilitation. However, the past years have shown that an autonomous IT department, managed separately from the commercial and operational departments of an organization, does not work. Management expectations are hardly ever met despite the efforts put into new methods, techniques, and organizational models within the IT departments. The many mergers and takeovers of the past years have not made it easier for IT departments to meet management expectations. On the other hand, it may be questioned whether management expectations related to IT performance are realistic. Too often organizations require and expect flexibility in their facilities to support business developments without defining any degrees of freedom or leading principles related to the dynamics in business development itself. Hence it would be a miracle if any management expectation would be met as business development and IT development are not aligned in the sense that they are looked at jointly. It shows that IT support cannot be structured and developed in a way that really facilitates business development if the organization as a whole is not structured for change.

One way or another we see that responsible management does not feel it is in the driver’s seat when it comes to deciding on business developments and allocating the right IT assets to facilitate these.

In this case we see a common situation for companies that have grown and globalized in the past years. We look at a business unit within a large Dutch based international bank where IT and operations are located in a separate generic cost center in the Netherlands. The business unit is active in all time zones where local entities are established based on takeovers, mergers, and greenfield set-ups.

IT support for the Netherlands entity of the business unit is provided out of the central Netherlands IT department. The operational support, however, is provided out of the business unit itself. The business unit is the only one within the bank where off-shore local operations and IT facilities are set up. The nature of the set-up on the different locations depends on the origin of the location (e.g., takeover, merger, or greenfield).

Business Drivers

In a world that becomes smaller, the competition gets bigger. In order to accomplish client retention or trying to create new business there is a strong client focus together with an internal focus on cost-effectiveness, quality of service, and agility. As technology plays an ever-increasing role in organizations, it is important that the related assets are set up and managed properly. In order to understand the environment in which organizations operate and compete they need a clear view on market drivers, their own strategic drivers, technological changes, and related operating models.

An enterprise is about a group of stakeholders that want to reach a certain goal. In order to do so they need to set up an organization that will facilitate this. This organization will consists of people performing activities, supported by facilities like money, housing, machines, working procedures, and technology. This shows that IT facilities, although often essential for an organization, are no more or less than facilitators in reaching the goals of the organization.

The general goal of the business unit management in this Case Study was to keep up with the demand of globally operating clients. At the same time, service should be of the right quality level and delivered at competitive costs. Given the IT-intensive character of this industry, it was clear that in order to do so a total review and re-alignment of IT facilities and related operations was needed.

Challenges

Too often there is a gap between commercial ambitions and delivery capabilities within an organization. The important issue here is that there is no interconnection anymore between those responsible for expressing commercial ambition and those held responsible for meeting them (e.g., IT and operational facilities are located in an independent business unit with its own P&L responsibility, acting as a cost center to the commercial business units).

Where delivery capabilities are often one-to-one connected to and restricted by IT facilitation, it is often the IT department that is seen as the cause for not meeting the organization’s goals. But on the other hand, how and why can commercial ambitions be stated that cannot be met? A primary cause here is that there is no end-to-end responsibility to deliver. It is not realistic to expect flexibility in IT facilitation towards business developments if no characteristics whatsoever are recognized for the flexibility of the organization itself (e.g., areas of change, financial boundaries).

In order to manage that an organization meets its goals, accountabilities and responsibilities should be assigned in a consistent, top-down way. Together with these come related goal-based KPIs and facilities (based on the business case). These should drive the choices on facilities to be actually made available in the different parts of the organization. IT in this sense should be seen and treated as an enabler.

In this Case Study the business unit management was very much aware of the above and was prepared to challenge the current central set-up of the IT departments. But at the same time it was recognized that goals and responsibilities together with clear KPIs should be defined in order to allow the IT and operational set-up to align with them.

Approach

“Cheaper, faster, better IT facilitation” are often-heard words that reflect the urge to be competitive but lack any changing power if not translated into achievable goals. This means that the people expressing this, or sometimes just demanding it, should not only provide predefined ambitions and boundaries, they should take responsibility and set up a roadmap to create the necessary changes and stay in charge by taking decisions and refine the goals along the way.

It is not about allocating budget as a way to express the relative importance of a change. It is about recognizing the changes that provide value for money and seeing to it that they get realized. It is about aligning enterprise mission, vision, and goals to enterprise capabilities.

Service-orientation in this perspective is a way of thinking that is closely related to value chain thinking. In that sense it is a way of thinking that should be easy to adopt in organizations focusing on effectiveness and efficiency.

It supports separation of concerns by using a disjunctive yet complete and consistent representation of a system based on autonomous components. It can be applied in (separate) parts and different levels of an architecture. However, it should never be used without the notion and application of other viewpoints in order to be effective, the most important one being the orchestration viewpoint.

Today’s organizations are also thinking SOA where they are searching for cloud-related support. However, often it is no more than looking at the existing IT landscape and seeking for replacement or using additional cloud next to the existing IT landscape.

Modeling Approach

In this case the CEO expressed his ambitions in words like “cheaper, faster, and better”, emphasizing the importance of the right IT support. But it was recognized at the same time that it would need fundamental changes throughout the organization that could never be recognized and implemented successfully if not supported by top-level management. This meant a full strategy definition stage was performed at CxO level, where a realistic, consistent, and mutually accepted mission and strategy were set up. Based on that, a business model was drawn up to cover the goals and restrictions on the different aspects (e.g., commercial and operational). This new business model was then validated with local senior management on a global level. First this was meant to create awareness of the ambitions, but at the same time to make local management co-responsible.

For the architectural models a service-oriented approach was chosen in order to create a fresh and more analytical view on the organization. From an IT perspective the general ambition was to have one solution for each business service recognized, based on a “best of breed” principle. The ArchiMate language was used for modeling as it supports a three-layer model of the architecture (business, information, and technology). In order to create insight in the actual coverage of the IT landscape, an initial mapping would be made of the current solutions on the business services.

In order to define consistent and independent change projects, a roadmap was to be set up in line with commercial priorities. Each project here should implement not only the related IT changes but all related organizational changes in the area of commerce, personnel support, operational and administrative set up, financial, and legal structure.

Use of ArchiMate® Models

ArchiMate modeling allows direct connection of IT facilities, such as infrastructure and software, to business services. This creates insight into the IT structure and costs related to these services. By doing so it creates a management tool for IT allocation and set up. This will help to set expectations on IT performance and costs based on consistent and understood criteria by responsible management. By taking away the “how” from the “what”, it enables organizations to focus on business value and not on the underlying IT implementation.

Use of a service-oriented approach also allows organizations to integrate and leverage cloud resources which are inherently service-based. “Cloud-thinking” is not a quantum leap in itself but just an extra means for optimal allocation of IT facilities to support the delivery of business services. With the SOA way of thinking, certain parts of the business can be recognized that are “fit for cloud” together with the related KPIs and restrictions. It also allows you to link agility needs in business development with requirements on IT agility.

A point of discussion in this Case Study was whether software solutions were available in the market that would map to the business services so that “best of breed” would really be applicable. And indeed in recent decades software vendors have created more and more end-to-end solutions covering the entire value chain of organizations. However, new initiatives in the market did indicate that it was recognized by both demanding parties and vendors that package solutions should match with a more service-oriented architecture. The BIAN initiative is a good example of this in the banking industry (see the reference Open Group White Paper: Integrating the TOGAF® Standard with the BIAN Service Landscape).

Business Services

Business Services Model

Business Services Model

In an SOA approach it is essential to structure the business based on the services it provides. This means before starting to set up business services you should look at the client services, being the core services to be delivered to their (potential) clients. In a layered service model the client services are at the very top level above the business services.

Next to business services that are more or less directly related to the client services there will be more generic business services that should be recognized and looked at. One of them is the business service covering the facilitation (e.g., housing, IT) covering for operational availability, maintenance, and development. Another one is the business service that covers performance management, which is about managing the organization in line with their goals. This should be done based on clear and predefined KPIs that are understood by both management and supporting departments. Defining KPIs for the organization as a whole helps to align IT facilities with business goals.

Further, it is essential to recognize and define business services in a strict way, based on functional capabilities that should be in place (the “what”) in order to deliver the client services. This means a business service model breaks down the organization into units of responsibility in contradiction to a process model which breaks down an organization into units of work (the “how”). Although the two models are separate, they are directly related and should be set up jointly (see later).

Business Services Orchestration

Business Services Orchestration

Setting up a top down SOA is not an academic exercise in itself. The main goal is to support decision-making in the organizational set-up. It is not about right or wrong. It is about creating insight into the different aspects of an organization towards its participants (whether in the management or operational area). This means that any representation should of course be complete and consistent and in line with reality, but at the same time it must be recognized by the people within the organization.

Most of us will recognize that people prefer to talk about activities than about responsibilities, where the former is merely the consequence of the latter. It is obvious, however, that in order to set up an SOA we have to describe an organization in terms of services. So one way or the other we should combine services and processes in our SOA. While recognizing services we will also have to model the way these services are combined (at the different levels) and provide insight into the process of delivering the client services. First to prove we are complete in our services, secondly to create detailed insight into what a service covers, and finally to reveal interaction patterns relevant for recognizing non-functional requirements.

In this case the IT department had already drawn up a business service model. Although it was recognized and accepted within the organization, it only described the 0-level, still combined a service and a process view, and was not fully complete and consistent. However, to safeguard acceptance, this model was used as the starting point for the service model. In close connection with the people involved it was reshaped on some points to really reflect a service representation of the organization. Because at the same time a business process model was drawn up, which in general is closer to day-to-day business, the service model was accepted as such.

Business Services Layering

Business Services Layering

In this case we did a very detailed exercise where, on the highest level, for each client service, a business process was recognized. Each business process was described by the sequence of the different business services involved. Going into the different levels of the service model in the end for each business (sub)service, a process was described telling how the service was provided using other sub-services.

Combining the set up of business service and a business process model also facilitates decisions on the level of detail.

Paradigm Shift

Business Services Paradigm Shift

As described above, we ended up with a very detailed model combining the process and the service concept, that was still recognized by the organization. By doing so, we also created a detailed multi-level service model of the business that could be used as the base for drawing up the application service layer.

Strategic Benefits and Goals

The strategic benefits and goals are shown in the following two tables.

Generic

Matching Requirement

Increased ROI

One functionality, one solution

Reduced IT burden

Lower overall IT TCO, single point of maintenance

Increased organizational agility

T2M for new clients, inst types, markets

Strategic Benefits

Generic

Matching Requirement

Increased federation

Clear separation of responsibilities

Increased intrinsic interoperability

Better changeability of IT architecture

Increased vendor diversity options

T2M for new clients, inst types, markets

Increased business/technology alignment

One functionality, one solution, best of breed

Strategic Goals

Results Achieved

The results achieved so far are:

  • Business Architecture community in place with key role in all developments.
  • Every change in business needs runs through the Business Architecture model to decide on IT changes needed.
  • Business confronted with its own expectations, limitations, and inconsistencies, allowing IT to take the role of facilitator rather than obstructer.
  • Business was allowed to manage issues, based on real business considerations, and without losing sight of the overall picture (e.g., on location of operations and IT sourcing).
  • Business Architecture department has set up and maintains a glossary, used as the single source for communication between, and documentation within, the different departments (business, development, operations, maintenance, IT).
  • Dedicated IT organization for the business unit.
  • Reallocation of IT platforms and operations into a more centralized set-up.
  • Some shared applications (on a bank level) replaced by dedicated solutions based on specific business unit needs (e.g., quality of service, availability).