Thought Leadership

Q&A with Billy Glennon:

Enterprise SOA and the Intelligent Finance Project

Written by Dirk Slama

Intelligent Finance (IF.com), the telnet bank of Halifax Bank of Scotland, is one of the UK's most successful banking businesses. The entire banking system was planned, designed, and built under the lead of VISION Consulting. With less than one year from initial plan to launch, VISION's challenge was to coordinate over 500 IT staff in 23 different vertical projects to deliver the new bank successfully. In this Interview, Billy Glennon (Group CEO of VISION Consulting) and Dirk Slama (co-author of "Enterprise SOA") discuss why, from a management point of view, the adoption of SOA (Service-Oriented Architecture) was critical to the success of the project.

Slama: Billy, thank you for taking the time for this interview. If I recall it correctly, the last time we met was during the launch of the Intelligent Finance bank in Edinburgh?

Glennon: Yes, I remember - that was a very special day for all of us (laughs). We had just gone through 12 months of extreme pressure and anxiety. Obviously we were all extremely relieved when the first day of operation went nearly without glitches, and the system scaled up easily to the huge load of on-line and telephone customers who opened accounts on that first day.

Slama: You were obviously under a lot of scrutiny?

Glennon: Yes, not only by the Management of Halifax and the financial press - the project made the pages of the Financial Times at least once a month for nearly a year (and on one or two occasions the front page) - but also from the local people. The project had an extreme visibility in Edinburgh. When you left the airport, the first thing you saw was a huge IF.com ad. Everybody in town was constantly talking about it. The millions spent in Edinburgh by people related to the project created an entirely new breed of restaurant in Edinburgh. I believe the Taxi budget alone totaled GBP 2 million. I remember being asked by a Taxi driver once if we had fixed a certain problem with the Mid-Tier. He had obviously overheard a conversation between some engineers earlier on that day. It seemed as if everybody in Edinburgh had taken a personal stake - and for us there was a whole set of concerns to be managed that we never had to manage before.

Slama: What was your initial reaction when Halifax presented you with the plans for this "mission impossible" project?

Glennon: Good question. How often does somebody come into your office, asking if you could build an entirely new bank with a revolutionary new concept for managing customer relationships and say, "By the way, we need your answer in 6 weeks?" My first reaction was to think, "Holy Sh….". This was obviously a once in a lifetime opportunity with all the risks that come attached with something like that. We knew that in the last couple of years we had developed a unique way for delivering projects in a short time, but this really was a moment that tested our conviction. We immediately started our research, and came to the conclusion that we could do it in 12 months. Eventually, Halifax negotiated us down to 9 months, and the rest is history (laughs).

Commitment-based Management

Slama: Billy, let's talk a little bit about your specific approach to management. What sets you apart from other consulting firms? And how did it help you in this project?

Glennon: Our understanding of management has its roots in philosophy. We try to observe aspects of human behavior often missed by consultants trained in economics, strategy, or organizational design and behavior. We are aiming to change the way organizations work at the levels of systems, projects, processes, whole enterprises, cultures, and cross-firm relations involving power and politics. This capability derives from a new understanding of management and an array of techniques for intervening in management at all levels. We see the basic unit of management as not the economic forecast or analysis but as the simple request a manager makes to a performer and then the personal promise the performer makes back to the manager. Getting these simple requests and promises made responsively to the business situation enables businesses to make radical financial and operational improvements.

Slama: You always make the point that enabling trust and commitment is another cornerstone of your approach.

Glennon: Very true. We are strongly leveraging linguistic strategies for forming commitments, which is a prerequisite for enabling a commitment-based organization. Effective management does not focus on clear pictures of the future and directives to achieve it, but on a general sense of direction and the manager's ability to make many requests and negotiate promises with the right people. The future cannot be seen, only created. We intervene to help managers stop trying to see or understand everything in advance. Instead we teach them to make the right kinds of requests and manage multiple promises necessary to create the change they seek.

Slama: Which helps to build a commitment-based organization?

Glennon: Exactly. A commercial enterprise is a network of on-going commitments. For those commitments to be made efficiently and flexibly, the organization has to be designed so that the conversations that lead to the commitments are on-going as well. Our mapping techniques show managers the underlying conversations necessary to produce the required actions quickly.

Slama: You are also using these linguistic strategies for managerial effectiveness between an organization and its customers?

Glennon:Yes. In our experience, all business processes in an organization can be supported or automated in terms of the transactional conversations that initiate processes, drive them, and bring them to completion. Ultimately there are no more than 13 conversational paths for any business transaction, and each step along the path consists of one or another special speech act: an offer or request, a promise, an assessment, or a declaration. These speech acts focus on producing change in the world, not just describing it. That's why they are so important to business.

Slama: What is the benefit of this approach?

Glennon: Firstly, this approach enables us to focus more on the commercial view of transactions than on data flows. Business is about getting things done. By mapping transactional conversations that get things done, everyone involved in developing a system from senior managers to staff and all IT people can speak one language about the system. Secondly, this approach helps us to keep things strategically simple: by mapping the Business Flow in a simple universal language for interaction, we can produce a simplicity that is stable even as a business changes its service or product mix. The same conversation flows can be readily applied in different domains and across domains.

Slama: So, how did all of this help you with the IF.com situation?

Glennon: We really have to look at this from two perspectives. First, given the speed to which we committed for project completion, we had to make sure that our internal conversations for action took place effectively and quickly. Second, since IF's vision was to change fundamentally the relationship between the bank and the customers, we wanted all the automated and supported interactions to use promises to build trust.

Slama: Let's start with the first aspect. What was so special?

Glennon: Well, after both Halifax and we decided to go with it, we had to mobilize a huge team over night. At the peak time, we had about 600 people working on the system development, interacting with hundreds of people on the business side. We had to worry about getting the right people with the right skills at the height of the dot com frenzy, and had to get them moving at speed. The team was the most diverse team I had ever worked with, including junior and senior technicians from 12 different nations, banking ops staff, senior bankers, and so forth. I believe we had about 20 different organizations involved in this project. We felt that we needed a very simple, stable structure in order to make this work. We had everyone focus on making clear and simple requests and promises.

Slama: What about platforms?

Glennon: Yes, that was another huge issue. We made the decision earlier on that there would be no value in re-implementing the core banking systems. Real value would be realized by creating a new way of how customers interact with the system. On the one hand, this meant that we could re-use the existing Halifax systems. On the other hand, there was a danger that we would get entangled with the process view implicitly embedded in these systems, which clashed with our new view to the world. And we felt that these existing systems didn't give us the flexibility we needed, in order to implement this strong vision.

Slama: So, what did you do?

Glennon: Well, this is where our decision to bet on a Service-Oriented Architecture (SOA) comes in. We had the management techniques in place, but we needed a technical platform that would give us simplicity on the one hand and flexibility on the other. The great thing about SOA's business-centric services is that you are really getting a shared communication mechanism that allows business analysts to talk with technicians in a language they all understand. Furthermore, there is a natural fit between the speech-act flow-map on the business side and the process implementations and services of the SOA on the IT side. This fit allows for very efficient mapping of business requirements onto the IT infrastructure.

Slama: What about flexibility?

Glennon: SOA allows for very easy "service orchestration", which can be used to combine multiple basic services into more complex business processes. We started by exposing the most important functionality of the existing backend systems as basic services. (We were really completing work started by the Halifax IT team.) Then we designed a more process-oriented service layer in front of these basic services, the famous "mid-tier". This tier really is a generic banking engine, which - in combination with the basic services - provides all services that are needed for implementing the different business processes in the system. The front-end channels - Internet portal and Call centre portal - can use these services like a child's construction kit, leveraging orchestration to realize even the most complex business processes. Also like a construction toy, it works because all parts of the system know how to communicate. They have a shared communications mechanism on the technical level. Simply wiring together the existing applications using EAI (Enterprise Application Integration) techniques would not have given us this level of flexibility.

Slama: And what about commitment and trust?

Glennon: Interesting! We have found that building trust and raising levels of commitment usually requires members from various constituencies of a team conversing effectively with each other, particularly business people and technicians. By giving them a common communication platform through the SOA, everybody was directly involved. We even established a project-wide SOA coordination board, which consisted of representatives from every team, both business and technology. The board was a key vehicle for establishing trust between the business and technology side. The trust that evolved among the members of the board had a direct effect on the speed of the project. Because the members of the board could use the same language, the business representatives could easily and quickly commit to precise functional requirements. Likewise, the technicians could commit to their timely implementation. The easy communication also enabled people on the board to see when they should take the lead. In my experience, when communication is not easy, people waste lots of time getting detailed stipulations and requirements before they take responsibility. Effective commitment-based communication cuts right through these delays. Once we had executed the first couple of iterations of the service design process, we could observe the high level of trust between the business and technology sides. They both committed without stipulations and conditions to a well defined set of service definitions. These were the basis for the implementation.

Slama: And this wouldn't have been possible with another approach, e.g. using the object-oriented design and specification process?

Glennon: You see, one of the key problems is that technical people like to think in terms of formal structures, flow diagrams, and so forth, while business people are usually less focused on these kinds of formal models. This puts a serious limitation on Object Orientation as a basis for communication between business and IT people. Moreover, the objects you find in an Object Orientation model are usually way too fine grained to be manageable, and too technology-oriented to be commercially understandable. The services in an SOA, in contrast, are at a level of granularity that gives sufficient flexibility without getting lost in the detail. Additionally, if you manage to differentiate between technical services and business-oriented services, you will quickly establish a common ground between business and technology.

SOA, Commitment, and Trust - The Customer Perspective

Slama: What about the second perspective, the relationship between the bank and the customers?

Glennon: Before we get directly to actual bank customers, it's important to understand that the combination of our conversation flow convention and the SOA approach is so powerful that it can be used to parse the legacy applications into parts that act as customers or performers making a promise, request, or some other speech act in one or another conversation flow. Leveraging SOA to model these speech acts - or to add new speech acts - was key to this process. Our approach really simplifies the overall design. We modeled it according to the requests customers make (or that their internal representatives would make) and the promises the business will make in response. Because there are finite possibilities for business/commercial transactions when looked at from this commitment-based perspective, everything becomes simpler. When bankers and bank-trained technicians looked at the the banking processes for Intelligent Finance, they saw hundreds of special cases of processes. However, looked at from the perspective of simple requests from a customer, there were really only three basic ones that could include all the others: "Open Relationship", "Provide Service", and "Fulfill Order". We were therefore able to drive all of the bank's processes and the supporting architecture off these three generic business processes: Three instead of three hundred. It was a lot simpler.

Slama: Can you give an example?

Glennon: Sure. For example, requesting an account statement is one class of requests. Canceling a credit card is another. From the point of view of the transactional conversation, all these requests follow the same pattern. Therefore, by implementing a generic request engine as a central service in the SOA, an enormously wide range of requests can be handled quickly and efficiently by the same automated process. And the customer gets the same experience, regardless of the request he or she has made. We could even use the same basic request engine, to implement very specific and unusual kinds of requests. Using SOA orchestration, we could draw on additional services such as a different backend system from what we started out using and do so with a seamless customer experience.

Slama: How exactly did this enable commitment and raise levels of trust between the bank and its customers?

Glennon: This design technique combining the commitment-based approach and SOA allowed us to focus hard on the three central conversations between the bank and the customer. With standard request and promise engines, we could spend time looking at such key questions as, "How do you open a conversation?" "How is the relationship opened?" "What kind of promise is made in this conversation?" Each of the three core conversations-"Open Relationship", "Provide Service", and "Fulfill Order"--needs to be managed in a special way to express the power of commitments. For example, we gave the customer who was opening an account a commitment that he or she would be given approval for the account within 6 minutes. The issue is reliable commitments, not just speed. It even goes beyond strict reliability to producing an environment of reliability. If we promise to answer a customer's request within 48 hours, and, while working on it, we find out that we won't be able to meet this deadline, we have to call the customer and explain why and when we will have the answer. That environment produces high levels of trust.

Slama: Still, it's hard to believe that a more technical concept like an SOA was instrumental in this.

Glennon: The SOA enabled us to model a speech act - such as a promise from the organization to the customer - as a first class entity in the system. If we couldn't have modeled such an entity as a Promise, it would have gotten lost in the system. The SOA approach gave us the technical means to do that modeling. In a classical EAI approach, we would have been focusing on functionality only, but not on managing the conditions for meeting a promise. So effectively, the combination of our conversation flow convention and the SOA approach helped us to grow commitment and trust between the bank and its customers. I believe that trust is one of the keys to the phenomenal success of Intelligent Finance.

Slama: Billy thanks again for the interview.

Glennon: This was fun. By the way, congratulations on your Enterprise SOA book! I particularly liked the case study discussing the architectural details of the IF.com project.

Slama: Thanks for the kind words on the book and for your input on the importance of SOA from a management point of view.

Glennon: At the end of the day you need it all, management, business, and technology, and SOA really helps bridging the gaps.