23 NOVEMBER, 2004

BEA’s critical domains

In part two of his interview with Bill Smith and Chris Garrett of BEA, which looked at the company’s recent Architect’s Summit, Martin Banks gets them talking about the six critical domains the company sees as being important transit points along the road to SOA implementations.

Chris Garrett: Within SOA we define six critical domains for success, the things you have to look at in the entirety of your enterprise. So we have building blocks at the lowest level architecture at the next level and they are part of these critical domains at the highest level. The six we see are organisation and governance, which is critical to success; business process strategies, so you are looking at the processes and whether they are properly defined; cost and benefit, because you have to drive through and make sure the cost is justified; there are the building block and the architectures as two more of the domains; and the final one is projects and applications, where you are looking at applications portfolios and the like.

So there are six key areas we work at with customers to describe and understand how far they are on the SOA journey. Architecture and building blocks are two of the more technical areas but there are also the other four which are more aligned with the management of the journey.

Bill Smith: We offer an online service for assessment of SOA readiness based on the model, and we got delegates at the Summit to fill in the details as they would online. This will allow them to benchmark themselves against their peers. It is available to anybody on the BEA website.

CG: What this has shown is that, while companies may have put a lot of effort into one or two areas such as building blocks and architecture, they have not done so well in others, such as organisation and governance. They get to see where they need to spend more time and effort.

Martin Banks: What are the main governance issues?

CG: One of the interesting ones is that it is essential to have regular meetings between the business and the implementation manager, so that the central SOA governance team doesn’t use governance to go into its own ivory tower. There is a danger of it spinning round the other way, so you have to carefully monitor the actual value you are getting back by regular meetings with the business, to ensure that what is being implemented is what the business wants, not something defined by the central governance department.

MB: Is this to avoid the problem of technology driving what the business is allowed to do?

BS: Yes. There was a lot of discussion around that and one of the key elements of a successful SOA project is that IT has to fit the business. SOA needs a measure of central control by its nature, but you have to ensure that it actually matches the requirements.