Finding order in chaos

Many financial institutions have had 30 years or more of increasing IT investment, across a wide range of business disciplines and through numerous technology evolution cycles. As a result, today’s core financial systems are often a mix of different applications, platforms, technologies and architectural models.

For instance, many firms will have back-office mainframe legacy applications, perhaps built on IBM’s IMS or CICS transaction processing systems. There may be local, UNIX-based applications running in departmental servers and Windows-based ones on the corporate desktops. Data stores may range from flat file systems such as VSAM, hierarchical stores using IMS-DB and relational databases like Oracle or DB2.

But if it all works, why fix it? Sure, software architects moan about the lack of clean interfaces and the disorganised state of the overall IT implementation, but does this really matter? The last thing businesses need right now are heavy investment projects simply to deliver what they have today but with more ‘architectural purity’.

In fact, there is far more to the concept of an enterprise architecture than ‘architectural purity’. This article looks at this area and the likely benefits to be obtained from a more structured approach to IT asset deployment.

The problem with ‘opportunistic’ architecture
Because of the historic pattern of new business demand, new technology development and IT response, many systems today don’t fit into any consistent, corporate architecture. There may well be some level of architecture, but this will have been developed on an opportunistic basis, evolving completely differently in the various corners of the business. This was not due to lack of IT care or attention. In many cases, IT responded to the latest business need in the best way it could – by choosing the most appropriate approach to individual problems. Part of the problem also stems from a massive degree of M&A activity within the financial services sector, smashing together different IT systems, complete with their own individual implementation decisions and approaches.

However, this feudalistic approach – where there are individual business disciplines and locations taking autonomous IT decisions without any overall corporate blueprint, – is a growing source of brittleness and inflexibility. There are four major issues that tend to arise, and that become more severe with time: lack of visibility, lack of control, hostility to change, and uncompetitive cost structure.

The first point refers to the fact that when multiple, disparate IT implementations are used, it can become extremely difficult to develop an end-to-end visibility of either an individual process or more particular overall business performance. Each system or application may have its own monitoring and management software, and may provide visibility of activities it deals with, but as soon as it becomes necessary to aggregate this with other activities outside of this system’s control, matters become extremely complex. From the customer perspective, this may represent itself as the inability of a customer service representative to quickly offer a corporate wide view of all the business services this individual is using – perhaps mortgage, current and deposit accounts, share-dealing service and insurance. As a result, the customer may feel more inclined to go to someone who can do this more effectively and efficiently.

From the business view, the visibility issue can make regulatory compliance an even bigger headache. Regulations such as the Risk-based Capital Directive and the MiFID require clear and accessible visibility of a range of criteria across the business as a whole.

In a way, lack of control follows on from the problem of visibility, because when systems are disparate and heterogeneous, it can be difficult to get a clear picture of what is happening and then to act appropriately. For example, suppose systems are running at or near peak utilisation when a high-priority surge of activity develops. In the opportunistically architected world, it is extremely difficult to realign resource utilisation, or indeed to understand the impact on other parts of the business even if this could be done. It also becomes very hard to implement corporate and business policies when all systems are organised so differently.

Lack of a consistent architecture has a major impact on the flexibility and adaptability of IT systems. Because there are many different components, each with their own internal structures, designs and interface mechanisms, delivering a new or modified business service becomes a major undertaking. Changes are not only complex to design, but require a range of different skills sets, which introduces its own problems due to the xenophobic nature of IT specialists. For example, mainframe and UNIX experts sometimes seem unable to communicate at all, given their radically different experience and technical outlook. Getting changes made that require both skills can turn into a major management challenge.

Another problem from the implementation viewpoint of the lack of a consistent architecture is that code often ends up being written multiple times. It is not uncommon to find every individual system or solution having its own ‘define customer’ routine, for example. This is because the lack of a consistent architectural model makes it difficult or impossible to reuse programmes between the different islands of automation.

This feeds into the last area of concern – the cost structure. The redundancy in unarchitected implementations means that any change may have to be made in many places, and also that any new services tend to be written from scratch, rather than benefiting from extensive reuse with its cost benefit implications.

How an enterprise architecture can help
Firstly, we need to understand what an enterprise architecture actually is. Is it some new product or piece of code? In fact, enterprise architecture is all about developing a consistent and relatively formal way of doing things. Products and code may be used as tools to fulfil the implementation of an enterprise architecture, but the architecture itself can be thought of as a set of definitions and rules. Think of a company’s business conduct guidelines, which set rules for all employees to follow when transacting company business. The purpose is to avoid any nasty surprises or unwanted business impacts. In a similar fashion, an enterprise architecture is a set of rules that IT staff have to embrace as they develop and deploy their solutions.

Typically, these rules will address important areas such as what interfaces have to be offered to other parts of the IT implementation, how data structures should be defined and which services should be made available externally. Some enterprise architectures may go as far as prescribing what programming languages and environments can be used, and how changes get approved. However, the most successful enterprise architectures nowadays are those with a lighter touch.

But what are, or should be, the effects of a good enterprise architecture? The answer is that it should address all of the issues discussed in the previous section. First, the question of visibility. An enterprise architecture will almost certainly define an information structure that represents a ‘picture’ of activity. This might include the type of operation being executed (trade, deposit, quote, etc.), the ID of the customer, a time-stamp and a data area for operation-specific information such as account numbers and transfer amounts. Each system would be required to provide an externally callable service that provided this information, enabling a consolidated picture of activity to be built up. In system terms, each product solution might be required to offer a monitoring agent that can operate in conjunction with an enterprise management framework, alerting the framework to any out-of-line situations occurring in the particular component or solution.

These interfaces and services provide the equivalent of a window into the particular system. Not only does this help with the visibility issue, but it addresses the control issue as well, as long as the window is accompanied by a set of externally available services to take a range of basic actions based on the view from the window. Take the example of security, or more specifically user authorisation. When a new employee starts, or someone changes roles, it may be necessary to alert each system as to the authorisation level of this individual. The architecture must make it possible for this to be done easily and quickly.

Perhaps one of the biggest areas of benefit from an enterprise architecture is in delivering increasing agility and flexibility to the IT implementation. Part of an enterprise architecture should specify the way different systems can interoperate with each other. In addition, key internal services to each component should be exposed so that other components can drive it. The result is that it becomes much easier, cheaper, quicker and less risky to make different parts of the IT operation work together. This reduces one of the major areas of complexity in developing and deploying new or modified solutions, and also promotes reuse, which in turn has a major impact on the IT cost structure. If changes can be accommodated with the minimum new coding, then costs fall and the quality of service delivery increases due to the reduced opportunity to inject new problems.

On the data front, consider the impact of having a consistent view of how data is structured and defined. Data represents enormous corporate value, but only if it can be turned into information. For example, sales records are an interesting record of company performance, but when combined with customer details they can yield exciting new opportunities in cross-selling, up-selling and new marketing opportunities. However, if these data sources are all in different structures and formats, it can be extremely difficult and costly to try to leverage the inherent value by bringing different data sources together. Having a consistent way to structure and interpret data makes this task much easier, and much cheaper, while also increasing the likelihood of such a project succeeding.

So, the idea of an enterprise architecture seems to promise a lot, but how can it be achieved? What is the ‘best’ approach?

Delivering an enterprise architecture – SOA
There are many different approaches to defining an enterprise architecture, but in the end the architecture will have no value unless it is implemented. One highly topical implementation model that fits very nicely with the enterprise architecture concept is that of service-oriented architecture (SOA).

SOA is all about trying to provide a way for an enterprise architecture to be put in place with minimal disruption to existing investments but with maximum return. One of the big stumbling blocks when the idea of enterprise architecture first emerged was the fact that at first sight it looks like a rewrite – big bucks to get what you have today, only implemented better. However, this is one of the main reasons why the SOA approach is gaining so much traction, because in an SOA the focus is on reuse.

There are two fundamental characteristics in the SOA model. The first is that IT resources are built into ‘business services’, and the second is that these business services can freely interoperate with each other without any need to be sensitive to technology, platform or location choice. The business services concept simply means that functionality is formed into components that actually represent some sort of business operation. As an example, think of the need to get a customer’s details such as the customer name, address, phone and e-mail details and transaction history. This would form a business service called ‘get customer details’. Forming this business service in an SOA context has two important features – firstly, it means that it becomes easier to understand from the outside what this particular system is doing, and secondly it becomes a callable routine that can be invoked from anywhere else because of the second SOA characteristic mentioned above, namely the ability to interoperate with this service. Redundancy can therefore be eliminated, with each programme that requires customer details able to simply invoke the ‘get customer details’ service.

This reuse is a key factor of SOAs. It may sound like the SOA approach requires everything to be rewritten into these new services, but this is absolutely not the case. It is true that SOA requires a standard, clean way of invoking each business service and of joining together the different components making up the service, but this can be achieved by dealing with the interface rather than the component itself. As an illustration, consider a universal plug adapter. When it is placed in the socket, the socket becomes available to any device with any (or most) variant of plug type. However, the ring-main behind the socket is unchanged. In a similar way, in an SOA existing technology choices such as platforms and application packages can be ‘wrapped’ with an adapter. Internally, the code is exactly what it used to be, but to other parts of the IT implementation it looks like a standard SOA component.

This SOA approach essentially turns all your IT assets into a reusable kit-bag of building blocks that can now be used to assemble new services, without requiring a rewrite. When a new requirement comes along, only brand new pieces of functionality need to be developed, with existing services and components forming the rest of the required functionality.

Not only is this an efficient way to architect enterprise resources, but because of the interoperability between components it also makes it easier to extend the enterprise architecture to deal with the control and visibility issues. The position is already much improved due to the use of business services that actually mean something in a business process context, and other tools can now take this further to provide effective solutions to these issues. For instance, once individual business operations can be clearly identified, regardless of the different IT systems that underpin the operation, it becomes much easier to have analytical software tools to analysis operational behaviour and either recommend improvements or perhaps more importantly monitor compliance to internal and external policy directives.

Delivering on the promise
Defining an enterprise architecture promises substantial benefits to companies throughout the financial services industry, whatever the size. It can improve levels of business decision-making and governance, reduce costs and create real business agility. However, these promises can only be delivered if the architecture is actually implemented and maintained. Just getting agreement on the details of the architecture is likely to be a long, hard struggle as different departments fight their own corners. Once agreement is reached, there is the problem of getting programmers to adhere to the architecture rather than doing their own thing. Then there is the issue of maintaining and updating the architecture – a successful architecture needs to be flexible and adaptive to change. These issues can all be overcome, but only with a common will throughout the entire company. Service-oriented architecture may offer a useful approach and toolset to deal with the technical implementation issues, making the challenge more manageable and less disruptive and costly, but in the final analysis the success or failure of an enterprise architecture will be dictated by the extent to which senior management supports and enforces the initiative.