Tag Archives: Architecture

Why you don’t want to become an Oracle SOA developer

My answer on Quora to a Java developer looking to become an Oracle SOA developer:

You don’t want to become an Oracle SOA developer, for two reasons: SOA and Oracle.

First, Service-Oriented Architecture has over-promised and under-delivered for a decade. The only reason SOA is still around is that many big enterprises has invested millions of dollars and are unwilling to admit that SOA was a mistake. It takes skilled architects, care and attention to realize the benefits SOA promised, and most organizations didn’t have that.

Second, Oracle is focusing on their cloud products, and the future of on-premise SOA is uncertain. All new features are rolled out in cloud services first and then, maybe, eventually, in the on-premise products.

Instead, learn micro service architecture and the associated technologies. Modern application landscapes are too complex for centralized SOA architectures, but micro services can be rolled out and integrated with the speed modern organizations need.

If you want to stay close to the old Oracle SOA world, look at Integration Cloud Service and Process Cloud Service. That’s where exciting development is happening in the Oracle world.

Link to Quora: Path to becoming an Oracle SOA developer. Already hava Java OCA. Whats next?

You’re Not Here to Write Code

Too many programmers think that their job is to write code. It isn’t.

The job of the programmer is to help the business solve a problem using appropriate technology for the task at hand. The programmer knows (or should know) the available tools and will hopefully select the right one for the task.

Unfortunately, too many programmers suffer from framework-phobia and don’t trust any code they have not written themselves. That takes more time, causes more bugs and will be harder to maintain down the line. Use good frameworks and solve problems!

use_the_framework

Technical Debt

As a system grows, it accumulates technical debt – improvements and cleanup that your really ought to get around to doing. However, no-one ever budgets time for this kind of refactoring and cleanup.

The consequence is that any major change opens a Pandora’s box of interrelated problems. I’m involved in a project where we thought we could simply make a minor change to all 2768 tables, but due various historical design decisions over the year and their complex interdependencies, the simple solution only works for 514 of them.

Complexity increases exponentially – the cost of cleaning up after 2 years is 4 times the cost of cleaning up after 1 year. If you don’t plan regular code maintenance, you are pushing an ever-growing snowball of cost in front of you.

ADF Architecture Made Simple: Small, Medium, Large

There are lots of ways of building ADF applications, so there is a very large number of possible architectures. I’ve found that three good architectures are:

  • Simple
  • Modular
  • Enterprise

In a simple architecture, you build the entire application in one workspace. Business components go into a model project in the workspace, and task flows and pages go into a view/controller project. This approach works well for small applications that will be built by one or two developers.

If your application is larger than 5-10 bounded task flows and/or more than two people need to work on it, a modular architecture is a good approach. In this approach, you place common elements (templates, visual identity, entity objects and view objects for value lists) in a common application workspace and then use the output of that workspace in a number of subsystem workspaces. The subsystems then each contain a specific subset of the total application functionality (view objects, task flows and page fragments), and all the subsystems are collected into one Master application workspace.

ADF Modular Architecture

If your organization is going to be building many ADF applications, it makes sense to extend the modular architecture to the enterprise architecture. In this approach, you keep enterprise common objects (base-level templates, visual identity, possibly entity objects and view objects for global entities) in an enterprise common workspace and then use the output from this workspace in a number of application common workspaces. These application common workspaces add features that are specific to each application (entity objects and value lists specific to the application). Each application is then built like in the modular architecture with a number of subsystems that are collected into one or more master application workspaces.

ADF Enterprise Architecture

Note that the enterprise architecture allows you to build several master applications and even use the same subsystem in two different applications.