Part of the Tool Kit: SOA and Good Business Practices

Introduction

While Portals and Service Oriented Architecture have held a high profile in planning user facing technologies in recent years, in practice their implementation runs up against user uncertainty about what they provide. In part is due to the traditional approach of many company and government senior managers, and in part it reflects the fact that while Portals can simplify customer solution delivery, they don’t provide a uniquely different end-user experience. To gain a practitioners’ perspective on this, the following case study was undertaken with Kee Wong, CEO of e-CentricInnovations (http://www.e-centricinnovations.com.au), who is interviewed by Dr. Greg Adamson, co-Editor-in-Chief of the International Journal of Web Portals.

We are a consulting company and we also do systems integration. So for us the boundary between portals and SOA, and integration in general, is not hard defined. We could develop strategy involving a lot of thinking around a portal. Alternatively we could implement a portal technology solution in a particular business unit within a multinational company, or within government. Every time we do a portal implementation we have to think about the architecture: how to integrate the application that the user sees as a portal interface to back-end systems that may reside within an organisation or sometimes external to the organisation. So integration becomes important as well. We find that SOA becomes an acceptable way for people to build the integration layer, because it helps shield the application and the user from the changes that might occur in the back-end. By default SOA is a key part of designing a good portal solution, architecting it and then implementing it.

We do business in government, retail, manufacturing, supply chain, banking and finance. They are all the same in that a portal solution is about providing the right application to the audience you are giving information to, and then abstracting that information from systems. Some of those systems are transactional, others are non-transactional. The information could be a policy document that sits in a document management system, for example. It could be information that has been extracted from publicly available websites. It could be HR [human resources] information that is merged out of a policy document and a transaction system that relates to payroll information. It could combine superannuation system information from a superannuation provider and business-to-business connectivity with the company you are dealing with. It could go in any direction. There can be portals for HR, portals for supply chain, portals for executive dashboards, portals for sales information, portals for occupational health and safety, portals for supplier performance, portals for customer satisfaction, and so on.

Typically our customers are larger sized companies. We tend to work with customers who are in the Top 200 category, whether they are multinationals with a presence in Australia, or Australian multinationals, and also government, federal and state. We tend not to work with smaller companies than this, because of our origins. Before I started eCentricInnovation I used to run a division in IBM for enterprise integration, integrating front-end and back-end systems, so we were used to dealing with Fortune 500-type companies.