Introducing Oracle Middleware into your environment

This article is intended for organisations that have just recently made a decision to adopt the  Oracle Fusion Middleware stack. It can be a very exciting and nerve-wracking time. You have probably done a lot of research on the technology and have a good idea where each particular product/module will fit into your environment. You are also likely to have some projects in the pipeline on which you are planning to utilise the products. The question is: how do you take full advantage of the products to achieve the best possible outcome and fast forward though the unnecessary hurdles.

Having chosen Oracle Fusion Middleware, you most likely understand of the benefits using the ‘Service Oriented Architecture’ approach.  The main principles of SOA are to promote reusability, consistency, governance and business agility. Even if you do not have a particular project and deliverables in mind, you still should think about how to ensure you follow SOA principles.

It is important to understand the distinction between Service Oriented Architecture and Oracle Fusion Middleware product set. Service Oriented Architecture is a philosophy/methodology, a collection of best practices and approaches to software development.  Oracle Fusion Middleware products enable you to follow/implement a Service Oriented Architecture. It is your responsibility to ensure the best strategy for your organisation to build a SOA and utilise the products to their full potential.

Where do you start?  Let’s explore a few areas where  you might  start…

Many experts and analysts strongly promote the importance of organisations developing (or adopting) a Reference Architecture before embarking on a particular project development.  A Reference Architecture is a collection of documents and code samples that outlines standards, recommendations, approaches and examples for achieving various outcomes.  The purpose of the Reference Architectures is to achieve common approaches and standards thoughout the organisation. The advantages of adopting and enforcing compliance to a Reference Architecture is obvious to many large organisation with multiple internal and external IT/development groups, applications and lines of businesses involved in IT projects. It is however, equally important for smaller organisations to have a Reference Architecture, as external consultants and/or partners may be involved in projects and you need to establish standards and governance.

Your Reference Architecture should be comprehensive to cover various areas of your business, and it is up to you to define these areas. Common areas seen in Reference Architectures are process, service definition, security, monitoring and management, content management, portals and user interfaces, data models, build/release management, and so on… You probably already have some rules, documentation, and knowledge in place for some or even all of these areas. You could also look for existing Reference Architectures designed for your industry, like TMF for telecommunications, or cross-industry ones like TOGAF or Zachman. You should never start from scratch. These concepts are not new and there is no point reinventing the wheel.

A Reference Architecture would normally consist of layers:

1. The Theoretical Layer, which gives high level architectural guidance or patterns (e.g.  follow SOA principles, build for reuse, manage your assets, separate security policy from the codebase, etc.)
2. The Descriptive Layer, which gives more detail about each pattern, but is still agnostic of the implementation technology (e.g.  use canonical data models, expose services as web services, use policy-based security enforcement system, etc.)
3. The Prescriptive Layer, which tells you exactly what tools and methods to use to implement various patterns (e.g. to create a service use Oracle Service Bus, to create canonical data models use XSDs, store your canonical data model in MDS, user SOAP 1.2 web services, use WS-Security or SAML for all services, etc.)
4. The Reference Layer, which provides fully worked examples for each pattern (e.g. a working example of a service that looks up a price for a product from E-Business Suite, implemented in Oracle Services Bus, using security policies from OWSM, a canonical data model that defines customer, product, etc.)

Even the best defined Reference Architecture would be of little value if it is not being followed. This leads us to governance.

IT governance, like any type of governance, is very hard to quantify when you are considering ROI. But the importance of it is unquestionable if you want to be a true SOA practitioner. You need to have Enterprise Architect(s), or someone who acts as an enterprise architect in your organisation, to ensure compliance, monitor reuse, and carry out reviews, approvals and other general governance. Architects have to ensure that no project is able to go live unless it is compliant with your Reference Architecture principles (or there is a really good reason why it is not). Among other things, they develop processes, manage assets and their relationships, ensure reuse, analyse impact of proposed changes and record usage. Very often, architects uses tools to manage the information needed to successfully govern a SOA environment. Oracle Service Registry and Oracle Enterprise Repository are two such tools.

The other aspect to keep in mind is that as with any change you should expect and plan for resistance. It is human nature to fall back to what is comfortable and familiar. SOA will probably become comfortable in the long run, but familiarity will take time. Proper training and time for learning, acceptance and organizational change must be allocated.

Following our previous statement about not reinventing a wheel, it would be advisable to find mentors to help you through the initial steps of adopting SOA in your organisation. Here are just a few ideas of getting proper help you need:

1. Hire someone who has done it before successfully,
2. Follow online resources, blogs, articles, etc.,
3. Attend conferences, user groups, related event organised by Oracle or partner (many of them are free), and
4. Establish a good working relationship with your Oracle account manager who could quickly pull in the needed resources.

And last but not least, remember that with flexibility comes complexity. If you are new to Oracle Fusion Middleware products, we recommend adopting a three-step approach:

• The first time, just try to get things to work any way you can, don’t worry about anything else, just make it do what you want it to do. For example, using SOA Suite connect to E-Business Suite through Integrated SOA Gateway, pull out some data and display it on a webpage using ADF. The first time you do a SOA project, you should consider it a throwaway project.  The purpose of this attempt is to get familiar with the tools, nothing more.
• Now that you know some of the terminology and have some familiarity with the tools, read some best practices material about how to design a SOA application.  Now have a second go at it. This time try to follow the best practices, develop a canonical data layer, perhaps you will make different design decision, improve your approach the best way you can.  The purpose is to learn about how to design a SOA application, when to use each tool in your toolkit.
• The third time, do some more reading and start thinking about issues like team development, monitoring, management, security and performance.  The purpose of this attempt is to understand how these cross cutting concerns affect your SOA design and development practices.

The reason we recommend this approach is that we have found it is generally too hard for a person to learn and put in to practice all of these new concepts  at the same time that they are learning the new technology. Give yourself time, play with the tools and enjoy the ride.