This week is Oracle OpenWorld 2011. Yesterday afternoon I gave my session on incorporating Oracle Application Express within the Oracle SOA Suite. Because of the large amount of questions I got to publish my presentation online, here it is.

When looking at Oracle Application Express we learn that we can use it perfectly for generating User Interfaces on top of datasources. These sources don’t necessarily have to be inside the database. Since APEX 4.0 there are great possibilities to consume web services in a APEX environment, when we use these as our datasources (and even as our Business Logic layer) we can incorporate the power of APEX within the Oracle SOA Suite.

In the presentation I show two great examples on how you can use this in real live. Extending functionality of both Oracle E-Business Suite and Oracle CRM On Demand using the SOA Suite and Application Express. There are a lot more examples to think of.

When talking Service-Oriented Architecture, technology is quite often the thriver behind the discussion. Why is this? Isn’t focussing on services and process orchestration enough food for thought? In other words: does it matter what happens underground?

Okay,  not completely correctly formulated. Of course we need to know what happens underneath the processes and what the technology is all about. What I’m pointing out is the following: SOA solutions tend to be seen as a tech-driven, non-functional element in our infrastructure. Not as a business driven solution.

Besides this, a business case around any SOA project can be easier maintenance or something in that area, but it rarely is. This means that we cannot focus on technology benefits of SOA transitions, but only on the business value it will create. If it can’t be found, don’t do it.

Now we get to the point that is services transition: the transition from silo thinking (which is something completely different than, and cannot be confused with, application / system thinking) towards services. Service is, according to dictionary.com, an act of helpful activity. It’s as simple as that.

This is the largest transition for an organization to encounter. Creating an internal apparatus that offers the end client a one-stop shop. How they get their information doesn’t really matter. What happens underground neither.

When looking at SOA implementation from this point of view we can put the technologies we use, like the Oracle SOA Suite, in perspective. It is possible to go services oriented without the SOA Suite, it only helps us achieve our goals.

The last few weeks at my new employer I’ve been diving into something very interesting: Oracle Application Integration Architecture. This package based solution for application integration really is impressive. The thing is: not only integration between standard Oracle packages can benefit from this approach, but every service-oriented architecture project could, potentially, gain from the knowledge Oracle has put in it.

The Oracle Application Integration Architecture (in short Oracle AIA) package consist of two separate products that basically offers a method and framework for application integration. Any application integration. Robust integration. The Foundation Pack offers a wide variety of some of the things that are most challenging to implement into any SOA project; like error-handling, building standards and design patterns. The Process Integration Packs (PIP’s) are build upon the AIA Foundation Pack and offer complete end-to-end realization of business processes. Including the integration of the applications involved. This is, of course, brilliant.

But even if we’re not integrating standardized processes with standard applications like Siebel, PeopleSoft or the Oracle e-Business Suite (which implies that we have nothing to gain with the PIP’s), Oracle AIA can offer us something we can benefit from. The Foundation Pack.

The most time or effort within a SOA project is often not spend on defining the functionality we need for the business processes, but in defining everything surrounding our new SOA landscape. How do we control and manage errors (in other words; what happens if, at any point, the process stops running?). And, maybe the most important: how do we actually model and design our SOA landscape? All these essential questions are answered for us in the Oracle AIA Foundation Pack.

So, for both money saving and mistake handling (why should we invent the wheel ourselves if someone else has done it for us?) AIA can offer us something. And for 46k per processor, I really think there can be a Business Case. Especially when we take the credibility and support in account.

One of the most intriguing sessions this tuesday of Oracle OpenWorld 2010 was the one about ‘The role of SOA in Enterprise Architecture’. Service Oriented Architecture is, in my point of view, simply a technology that offers us the possibility to combine business processes and system integration, but one thing it’s not: Enterprise Architecture.

It’s fairly simple: Service Oriented Architecture and Enterprise Architecture are two completely different subjects. Of course, SOA can take a role in developing an Enterprise Architecture. And probably a very important one. I’m glad that Harish Gaur, director of fusion middleware product management at Oracle, agrees with me.

During the session Haris Gaur helped the attendees gain insight in where SOA is able to be mapped onto various elements of Enterprise Architecture. A very interesting model is produced by Gaur and his team showing the SOA on EA Mapping.

Combining Business Process Orchestration, business services, data services and infrastructure against the 4 basic elements of Enterprise Architecture: Business, Information, Application and Infrastructure Architectures.

This cannot be a discussion: Service Oriented Architecture and Enterprise Architecture are not the same thing. But they do work together like a charm.

Who wants to Live Forever? Great song. Not so great approach to Software Development though.

When we take a look at Software Development, you’ve probably noticed the situation that any app that has even been build, still is fully running today. At the beginning of the lifecycle of an application or system, we like to think how long the system might run. We develop an application that simply is designed to run for about four years or so, but the reality looks quite different: legacy applications that run for over ten years within an organization aren’t that weird or strange.

So, where’s the problem here? It’s simple: over the years we’ve learned a lot about user interaction, functionality and system integration. These wise lessons don’t apply to legacy systems and, if we keep on thinking ‘we already have this, why throw it away?’, nothing will change. And change, within every organization, is essential and adds most value. Business Processes get changed in order to support the system, instead of the other way around. And a lot of effort is put in maintenance of these systems.

Developing something that basically already exists is considered nonsense and pretty scary to most people. That we try to keep something running that should have been buried years ago doesn’t change anything about that emotion. So how can we change this?

Systems Integration, or Service Oriented Architectures might give us the solution over here. With these new insights, methods and technologies we just might be able to keep using the application that has been build ages ago and change it to meet the requirements we have today. Integrating systems and let user interaction play in a modern way, based on business processes, instead of standard functionality.

Although a solution can lay in SOA, I strongly believe that design is always cheaper than redesign. When we can design and develop a system from scratch, we can make choices that weren’t made in the original. Redesign, even with the capabilities of SOA, also means that we have to work around the boundaries the original legacy system gives us.

Besides that we still will have the large maintenance costs that come with (unsupported) legacy systems.

What do you think? Will we ever get rid of these legacy systems? Or are they just a given part of live?

Software Development is, these days, frequently about connections. Connections between different systems, applications, legacy systems and brand-new internet portals. You choice is yours to make. The days of small and standalone applications are numbered. The majority, again: as I believe, are small and accessible applications that combine data from different systems in order to create real information. This means, connecting the lines between the obvious and the, previously almost, obsolete.

Information rarely stands on it’s own these days. And it even isn’t always Business Intelligence anymore. When we are talking about adding value into new IT systems, most of the time it just means to create information using different sources of data. These sources even get a longer lifecycle because of these new connections.

When we are designing and developing connections between systems, or using different (maybe old) systems as the source of our information-cycle in a new application, we need to make sure we understand the meaning of the data we’re using. This meaning is easily translated when we take a look at the reason why we are using source systems. One of the largest reasons is that we don’t want data to occur twice (or more) in our complete application landscape.

Then why is it that, even applications that use data from different sources, data is stored even more in the past few years? Do we really need to interpret the data in so much way’s now? Or is it just a phase we are going trough?

In my eye’s, the real ‘application of the future’ doesn’t store any data itself anymore. It just acts like a conduit between applications and gives users just the information they need and let them interact in actions that are inter-applicational (is that a word? Hopefully you know what I mean). What are your thoughts on this? Is this possible?

Dat we Oracle Application Express bijzonder geschikt vinden om SaaS applicaties mee te ontwikkelen roep ik inmiddels al een hele tijd. Dat ik het ook totaal onzinnig vind om te roepen dat APEX geen plek heeft in een SOA omgeving doe ik bij deze eventjes. Service Oriented Architecture heeft per definitie niet zo bar veel te maken met User Interfaces, APEX wel. Hierdoor is de combinatie dan ook bijzonder aangenaam te maken. Oracle zelf biedt momenteel een heel scala aan mooie producten om deze combinatie mogelijk te maken. Door de integratie van APEX user interfaces en een SOA omgeving neer te zetten kunnen we een compleet integratiepad implementeren die onafhankelijk van elkaar opereert. Service Oriented Architecture maakt het voor ons ook mogelijk om SaaS applicaties te ontwikkelen die gebruik maakt van functionaliteit geboden door derden. Deze functionaliteit is inmiddels niet meer weg te denken. Hiermee doel ik niet op de ‘simpele’ mashups die we overal op het internet kunnen vinden, maar de meer complexere integratie welke onder andere gebruik maakt van authenticatie, maar ook de uitgebreide beveiligingsmogelijkheden die SOA omgevingen bieden. Voor het afhandelen van webservices in APEX is al genoeg geschreven, maar als we samenwerken met bijvoorbeeld een servicebus, kunnen we berichtenverkeer netjes laten afhandelen en zijn we niet afhankelijk van de beperkte mogelijkheden die APEX ons biedt. Ik zal een der dagen iets meer vertellen over het aanleggen van connecties en integratielagen tussen APEX en een SOA omgeving ten behoeve van SaaS applicaties.

Het gebeurd nog steeds iets te vaak: mensen benaderen APEX als een ‘mindere architectuur’. Doordat we niet expliciet op een applicatieserver draaien, of de database benaderen als een ietwat hip uitgevallen kaartenbak denken veel mensen dat Oracle Application Express niet geschikt zou zijn voor het grotere werk. En al helemaal niet thuis zou horen in een Service Oriented Architecture, SOA, omgeving. Absolute kolder natuurlijk, maarja, sommige mensen zijn gewoon een beetje stug en denken dat je alleen iets goeds kan ontwikkelen als je er teveel tijd in stopt. Na heel wat ervaring met APEX opgedaan te hebben kan ik je natuurlijk vertellen dat dit soort aannames nergens voor nodig zijn. Sterker nog, de Oracle Database is zo geweldig dat we alle functionaliteit gewoon al standaard in huis hebben. Waarom zouden we daar dan geen gebruik van maken?

Oracle biedt al jaren de XML Database aan, als onderdeel van haar database. Nu is in Oracle Database 11g de XML database bijzonder uitgebreid en nog een stuk beter geworden, dit houdt in dat met behulp van het DBMS_XDB package, XQuery, de ‘ORAWSV’ servlet en wat standaard DMBS configuraties alle functionaliteit in je APEX applicatie beschikbaar kan worden gesteld als webservice, native! Op dit punt zijn we al heel ver. Op het moment dat een organisatie meerdere complexe systemen met elkaar wil koppelen, zonder dat data of gegevens om meerdere locaties worden vastgelegd kan met dus heel goed gebruik maken van deze functionaliteit. Sterker nog, kan me voorstellen dat APEX en de Oracle database standaard worden uitgerust met deze uiterst handige functionaliteit. Voeg daar een fatsoenlijke service bus aan toe, wat procesmanagement tooling en we hebben de applicatie van de toekomst! Wat nou, hier heb je écht Java voor nodig. APEX is de bomb! (maar dát heb ik nu wel vaak genoeg gezegd.).