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.

Since the release of the (first) Oracle Exadata Database Machine in 2009 and the soon followed acquisition of Sun Microsystems in 2010 Oracle is in the Hardware business. Not a bad position to stand in. But sales are not as promised and one of the large complaints about the Exadata (Database) and ExaLogic (Middleware) machines an often heard complaint is that the machines are simply ‘too big’. And it’s probably true. An Exadata machine can hold an extremely large Data Warehouse, but will it effectively run your database applications with economics in mind? But we have to take into account that the Exadata machine offers great flexibility and extra features we would love to see on other database machines.

So now, just a week before Oracle OpenWorld 2011, the answer is here. Oracle now offers us the Oracle Database Appliance. (Sounds as if we’re dealing with fancy kitchen machines, doesn’t it?) It’s a full grown machine that offers flexibility and some of the neat features the Exadata machine offers us. Only, this time it’s smaller. The flexibility mainly lies in the fact that Oracle offers an increasable licensing model with it.

When you purchase the Database Appliance, you can start off as small as 2 cores licensed. And, as your applications grow, either in size or complexity, you can mature toward a full grown 24 processor core machine. Without changing the underlying hardware configurations. So it really can be seen as an investment.

The Oracle Database Appliance in itself (not even looking at the flexibility of the license structure) is quite impressive. Two Oracle Enterprise Linux based Database Servers in one package. Each based on two Intel-Xeon 6-core CPU’s (hence the license model going from 2 times 1 core to 2 times 12 cores) and a stunning 96 Gigabytes of memory. Besides this, the machine contains 12TB (triple-mirrored, so effectively 4TB) of hot-swappable disks of database storage. Plus, the now essential SSD’s for Database redo-log’s and HDD’s for the server OS.

This all sounds pretty good to me. A system that offers a lot, but still can ‘grow’ together with the needs that you have for your database systems. Of course, this is without mentioning the costs of the machine itself. But all in all it looks positive. It just might be what Oracle needs in the Hardware business.

Here is a video of the official release of The Oracle Database Appliance.

We’ve talked about it here before; Agile Software is not the same thing as Agile Software Development. Of course, one of the hottest topics possible these days in Agile Software Development. Recently we even learned that Agile Software Development has become the mainstream development method. But this is not why we develop. It’s just the means to an end.

When looking at Business Agility, or to be more precise Business Software Agility it has nothing to do with scrum or other development methods. It’s about the ability to change, during production and on the long run. This is where new insights (like SOA, BPM, the Cloud, etcetera) come into place.

Looking at the principles of Lean and Agile, it learns us that we should look at value and worth instead of costs. Single processes instead of bulk. Flexibility and change are key words in every lean environment. When we take a look at the principles of Service Oriented Architecture, it has the exact same goals. Software built on those principles offer organizations a framework that can change, easily.

But software build with SOA-tooling and –related technologies is not per se Agile. This is a misunderstanding. And something methodologies like Scrum will not automatically create Agile Business Software. The software has to be designed in a way that it still offers flexibility and therefore is able to change. In other words: when an Service Oriented Architecture is lousy build, despite of the amount of new technology in it, it will not be Agile. Even when the process of coming there is agile.

This does not mean that Agile Software Development is a bad thing. On the contrary, it is one of the most important parts of delivering software that the business actually needs. But we still have to focus on the outcome, not the process coming there.

For coming Oracle OpenWorld, from 2 till 6 October this year, my paper on Oracle Application Express within the Oracle SOA Suite was selected. Two hot Oracle-topics combined into a one hour power session on how to work effectively with two technologies that somewhat collide with each other. But it isn’t such a strange topic, I’ve been talking about it for quite a while now.

When taking an abstract look at Oracle APEX, we see a technology that uses the Oracle Database to generate user interfaces on top of data in a fast manner. It doesn’t really care what the source of the data is. Tables in the database itself, or web services. Using this ‘clean’ look on the technology it is quite possible to combine the powerful features of APEX with the essentials for Service Oriented Architecture embedded in the Oracle SOA Suite.

There are three basic approaches to this. First is using APEX merely as a way to show content that is offered by a web service. Second is building APEX applications on top of the Oracle Database as if we where using Oracle ADF’s Business Components. Simply build screens on top of a database. Use SOA components for everything else. Third is a wider approach, combining method one and two into something completely different. A completely clean web application build using Oracle Application Express that calls and receives answers from web services and BPEL processes.

It is as simple as that. (There is some more to it, but I will tell you about that during oow11…)

Are there any specific parts that you would like to hear about during this session? Some difficulties you want us to tackle? Tell me in the comments! It’s time to build up an awesome session!

A common mistake that, as turns out, really needs to be disrupted: introduction of new technologies will not, I repeat, will not create Business / IT Alignment. Implementation of any new technology driven solution will, in fact, only create a larger gap between two worlds that shouldn’t be disconnected in the first place. For Business and IT Alignment there is only one remedy: communication.

When we take a deeper look into the reasons why we still tend to look at Business and IT as two completely separated worlds, we learn that it simply is a small gap introduced by common misunderstandings. Nothing technology can solve. In fact, this might be the cause of the misery.

It’s commonly mistaken that modern technologies such as BPM implementations and service oriented implementations create business IT alignment. But they won’t. They can assist in creating an environment where there’s larger common ground and help communicate about the wishes and needs organizations actually will help further. But that’s it. We still need to do the hard work.

A while ago I overheard a conversation between two very experienced software architects. They discussed a business case for a SOA implementation. It was Business / IT Alignment. Despite of their experience in the field, they didn’t recognize the pit they where falling into. But that’s not that bad. As long as the problem owner knows this. (If there is one in unaligned business and IT)

But, without being silly, how can technology implementations help us align business and IT processes? It’s easy: some new technologies will offer us a way to communicate. This all started a long while ago with analysis and design techniques and methods. Take ERD’s, UML, IDEF0. But also User Experience Design, Structured Design, SADT. And architecture visions like TOGAF. All developed to make sure end users, product owners, problem owners, developers, designers and everyone else understood each other.

This didn’t exactly happen. There are some things to blame, like development teams not working on the design and never getting in touch with end users. But Business and IT Alignment simply didn’t happen. But now things, can, be a little bit different.

Different approaches to software development, like the largely popular agile software development method Scrum and models that can actually be executed, like the new BPMN 2.0 specification, just might make the difference. Less translation, less interpretation, more communication and more cooperation. 

Sounds like a solution.

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.

In 2009 Oracle acquired a company called GoldenGate. GoldenGate offered software for real time data integration. The Oracle GoldenGate product is often mistaken for an ETL tool, but this is not what it is. But where can the value for Oracle GoldenGate be found?

When we look at the possibilities of real time data integration, the business case can be quite simple. Replication of an online database. But there are lots more implementations of Oracle GoldenGate that can be of interest. Here we can think about replicating databases for high availability, zero downtime configurations, live reporting, business intelligence replication or integration within a SOA environment.

Oracle GoldenGate uses the Database transition logs to determine what data is affected. This is a completely different approach than other replication software, that most of the time simply mirrors database. This technology is also the foundation why we can do real time data integration. Less data (e.q. only the transactions made) means less time transmitting. Sounds simple enough right?

Oracle GoldenGate can apply this technology not only on Oracle Databases, but also on IBM DB2, Microsoft SQL Server, MySQL, Sybase ASE, Teradata, SQL/MP, SQL/MP, TimesTen and Enscribe. With this pretty complete offering, a lot of solutions are possible. What to think about mirroring an Oracle database to a MySQL instance to create a relatively cheap backup? Or a heterogeneous environment consisting of mainframes, SQL Servers, DB2’s and Sybase into one Oracle Database for consolidation?

In the Oracle GoldenGate 11g Implementer’s guide by John P. Jeffries we see a various way of implementation possibilities for GoldenGate. Jeffries shows some examples of GoldenGate architecture, like one-to-one for disaster recovery and bi-directional data integration on active systems.

When talking about high availability, we Oracle people immediately think Real Application Clusters, RAC. I hope. Fortunately, Oracle GoldenGate can be completely integrated with Oracle RAC. This means that we actually create a high-availability scheme, based on standard Oracle RAC, using the possibilities that GoldenGate offers us.

Especially when we’re talking large amounts of data, in complex database and data integration environments, Oracle GoldenGate can offer us huge advantages. It certainly is worth the effort of investigating and it’s a pity not everyone in the Oracle world is familiar with the technology.

You can find the Oracle GoldenGate 11g Implementer’s Guide here.

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.

A week ago I received a new Oracle APEX book from Packt Publishing with the question to review it and tell the world about the book. The Oracle APEX 4.0 Cookbook is just released and written by Marcel van der Plas and Michel van Zoest, both (ex-)colleagues of me. Because of their extended insight knowledge of Oracle Application Express and projects done with the tool I do think they are the right couple of people to write this book.

The book has become a very interesting distillation of APEX best-practices and adds real value to any Oracle Application Express project. Both for beginners as well as experienced developers. I think this isn’t something you can do easily, but the boys did it.

The book gives inside knowledge to the reader broken down in the form of recipes. And it truly are bites on a platter (hapklare brokken, for the Dutch among us). And it works. The recipes are simple, jet effective, pieces of information. It basically works as an off-line wiki: no more extensive and hard to understand theoretical articles, but small and understanding portions. Finger Food.

This approach is very effective. We no longer need to google our answers and browse tons of articles before we find a solution, but it is served to us. It has cost me, and other developers with me, years of trial and error before we got the knowledge that is combined in this book.

But now the book itself.

The Oracle APEX 4.0 Cookbook covers both the basics as the ‘real thing’. It is set up as a ‘how to’ step by step guide that takes us into the world of Application Express. Beginning with the basic build of an application. For the sake of it, I will not go into that further.

The book gets really interesting in the second part. This is where the years of experience of the authors kicks in. Finally a simple book that tells us what to do, the good way. Themes and Templates get dissected so we actually can understand them and tweak them the way we want to. The chapter about Extending APEX works around examples using JavaScript, AJAX and JavaScript Libraries and it’s put up in a way so we can easily understand what the writer is doing and not only copy the example, but actually (for example) extend APEX with our won JavaScript Library.

In my personal opinion, chapter 10, ‘APEX Environment’, is the most interesting part and discusses an aspect of APEX implementation that is too often undermined. The APEX architecture. Both the development architecture (subscriptions, debugging and version control) and the production architecture (three tier infrastructure, Apache proxy and APEX Listener). This chapter tells us how an APEX application is best developed and deployed.

The Oracle APEX 4.0 Cookbook is available at Packt Publishing.

Agile. Within the Software Development business we look at the principle mostly as a way to deliver functional solutions to the business. Agile Software Development. But rarely we look at the solution itself to be agile. Is this the right way to look at our business? Isn’t the solution itself the highest goal? (Which, in my opinion, is the most important principle of the agile manifesto).

When we look at the solution itself offering agility to the business, we can say that it’s a focus that only arrived to us a few months ago. Sure, in the past we have seen IT solution offering agility to the business, but that was just a coincidence, not a goal. New technologies like Business Process Modeling and, especially, Service-Oriented Architecture, not give us the opportunity to model an IT environment where the business can truly adapt change. Hence, the Business Agility emerges.

Like all IT strategies, Business Agility can be reached when looking at three elements. The first is technology (yes, this is a tech blog) which has to be chosen for the ability to support change with few changes in the technology itself. When technology isn’t able to rapidly adapt new business rules, new business processes or business users, agility within the business will never be achieved.

The second element we need to focus on is policy. Without a clear focus on delivering changes to the organization the business will not achieve agility. This is the part where Agile Software Development comes into play. But it’s not the only policy we need in order to make our business itself agile. We also need to incorporate Agile principles into the entire Enterprise Architecture stack. Not a simple and quick transition, but something that needs to ‘grow’ and ‘mature’ within the organization for a long period of time. The adaptation of Agile within the business processes (using methods like Lean Six Sigma) is one of the essential parts. As references show us, this is mostly a change of mind.

The third element is design. Even if an organization has the ‘state of mind’ to adopt agility within and the technology offers the possibilities to actually implement it in the organization, if the design isn’t focused on Agility, it will never happen. “Agility by Design”. Definitely something to think about and I will write about it soon.

Although we have traveled far since the old waterfall methods of software development, an agile approach to software barely stops at the way we organize our projects. True Business Agility isn’t gained if we don’t look at the outcome and possibilities a solution offers us when implemented.