15 NOVEMBER, 2004

Business is the key for users – says BEA

Some definite changes in the role of IT can now not only be identified as 'good ideas’, but are also starting to be seen in practice. One such is that IT personal, and particularly those responsible for architecting future business solutions, really do need to have a good grip of the business issues. What is more, services now need to move centre-stage as a core part of the management process. These views, and more, emerged at a recent seminar – the Architect Summit - hosted by BEA. In this first instalment of a two-part interview Bill Smith, Pre Sales Director for BEA in the UK & Ireland and Chris Garrett, Principal Pre Sales Consultant for the UK & Ireland, talk through how governance groups are becoming an important part of the process in building and implementing a service-based environment, and the place of 'building blocks' in BEA’s view of the overall architecture of SOA.

MARTIN BANKS: So, did anything emerge from this summit?

BILL SMITH: Yes, it reinforced the beliefs we have around SOA and in particular, the discussions all seemed to drop back on to a small number of subjects – and primarily those discussions were business oriented rather than technical. The audience was primarily architects and IT managers, with a limited number of developers, and the big discussion point was how to get IT talking to the business more effectively and getting buy-in from the business as a whole to an SOA methodology. There was a lot of discussion from individuals looking to go down an SOA track. Most were looking for advice and direction on how to get traction with and the buy-in of the business side.

MB: You seem a bit surprised that people were looking from a business perspective.

BS: Wouldn’t say surprised, but it was interesting to see how that view was coming from the IT side. It was not a minority, it was very much the large majority.

MB: So you see IT now accepting that this is a capability they have to take on board?

BS: Absolutely. In fact, Pretty much every discussion touched on IT/business integration in some way.

MB: Were there any hints at a solution as to how the bridge between them is to be built?

BS: Absolutely. There were a couple of individuals there who are already going down the SOA route and their input was interesting, for it was pretty much grouped round the idea of a central 'SOA Group', some form of central governance body enforcing the governance of the project across the whole organisation.

CHRIS GARRETT: What seems to be happening is that companies are starting to fully understand it is all about process, business and governance. These are the core issues when putting together an SOA. The technicalities of achieving it come slightly later in the cycle. But when you start talking to a lot of large companies about the architecture they have, they do agree with this approach in theory. But in quite a few cases they are starting on a project basis, So they are not able to put teams together with a wider view and are having to work on a more project based approach. So they’ll start on one project, start to get some re-use from some of the services they have built, then move on to the next project. They’ll continue with the same governance, processes, and management, and will get to see more re-use as things progress, but it is not as if they are going in and saying 'this is what we’re doing for the whole enterprise, you must adhere to this’. It is more a case of 'let’s put these things in place as we move forward.’

MB: Is there any problem in such circumstances in defining what an SOA project consists of, given that the very nature of SOA is service-based and therefore very loosely coupled, which makes it hard to define clear boundaries of what is in a project and what isn’t?

CG: This is interesting. One thing that came up in the workshops is that there is a strong need for IT to work with business to tease out the commonalities between the different projects across different business units. Those commonalities are clearly the areas where the underlying formation of the SOA direction comes from.

BS: One thing that came from the sessions was the question, do you look from the bottom up – technology to business process, or top down, from the business process to the technology? It became very clear that the main view was looking from the business process, with this driving the services required. This which then dictates the type of technical infrastructure you need to use. The technical solution comes at a later stage. The first stage is getting the business processes defined and the governance processes in place and then building the services out from there.

MB: I understand the subject of building blocks formed a part of the summit. Tell me about your thoughts on building blocks and what they are. Does this map onto the idea of the Service Stack (see "Meeting SLAs is now the important goal" in the Solutions Architect archive).

CG: I did struggle with this when I first started looking at it, and the reason is that there are many people that have an architectural layered model – as we do – but the way we look at an architecture model is not in terms of services as in functionality but as in process. This is as in what is the best way to do something. Underpinning those process levels within an architecture stack will be functionality that has to deliver it. This is where we feel that the building blocks drop in.

We have defined four types of building block. We have Shared Business Services, which is a higher level view; Shared Applications and Infrastructure Services; Shared Data Services, which is all about having a canonical view of your data; and Events Services. So (to demonstrate how the blocks work together) we do this scenario. Think of a pallet going through a warehouse. It is a single pallet, but it also carries lots of goods. Now think of this in an RFID environment. This pallet is going to trigger a lot of events.

The idea of Events Services would be to take these low level events and turn them into a business event – for example what might be the shipping costs of a specific item that triggered one of those low level events. With a lot of embellishment of a low level event it can turn into a business event – tracking the costs of an individual item. Events Services would then use Shared Data Services to get the information needed, and behind that would be the integration with both shared services and existing applications such as CRM and stock control. Then finally, you would send that business event to Shared Business Services, which would be at a much higher level and could be made up as a composite of other business processes.

So there is a difference between architecture layers and the building blocks that underpin it, as there will not be a one-to-one relationship. It is like a matrix.

www.bea.com