Tips for your initial SOA project

I was asked for advice at a SOA project that starts soon based on Oracle middleware. This is what I came up with as my most critical things to consider at the start of a project. This list is by no means complete and you are welcome to add your top 5.

– It is all too easy to underestimate the efforts of creating a initial working prototype and the reference architecture and then run into large delays because things that seemed so easy just don’t work the way anticipated or the solution proves to be just too slow! So make sure you have the time for try and error until the reference architecture stabilizes and you have solutions for every critical aspect! If this is one of your first projects, don’t get into stress from the beginning due to delivery dates but take some weeks to get a solid reference implementation.

– It is amazing how some things on configuration side are much less intuitive and more complicated than anticipated. Examples for areas where you can spend days understanding the nitty gritty details are
– configuration to optimize performance
– asynch services
– timeouts
Thus it is advisable to have at least one very technical and experienced expert who has deep configuration skills in the team, either from the middleware vendor, from a system integrator or from your own team. Always strange things happen, especially in the beginning and you never know, when you are not very experienced, whether it is a programming mistake or a bug. Fast cycles of understanding, resolving, knowing how to search bugs and solutions in the documentation and fixing it is key.

– for skills in the team: Check you have this type of main skills: Architectural / design, technology and tool expertise.
Make sure you have advanced XML skills: XML Schema, WSDL, especially namespaces, XPath, BPEL. Everybody who is exposed to BPEL and XML is lost without deep understanding because of the untyped, declarative nature of XML things go wrong late after compilation and are hard to track down: “80% of the problems are namespace problems”

– Make performance tests on performance critical aspects early. XML is potentially large and can blow up memory and performance easily. XQuery and Database are means to deal with that. And, even way faster is good old STAX parsing. Again, it takes time to find the bottlenecks and feasible solutions.

– determine main architectural attributes such as the level of loose coupling and make sure everybody buys into them and you map designs to these attributes and guiding principles. This determines efforts and tools.

– don’t be too much in love with tools. Rather have less tools: The complexity rises with each tool and platform drastically and you might end kicking out tools that seemed fantastic but cause problems in the concert of collaborating tools. This is a hard earned lesson 😉

– On change management and project culture many peers have written profoundly, this is important but too broad for this short checklist.


You want to sell SOA? Speak COBOL!

If we are lucky, we “SOA Architects” are faced with a rather modern deployment of existing applications, based on platforms such as Java, .Net or Oracle Forms. Here, the upgrade to a Service Oriented Architecture is a natural and gradual one, programmers and architects of the existing systems are used to think in terms of components, which are close (or predecessors) to services. Thus, you can quite easily sell SOA to the stakeholders of this type of environment as a mere “upgrade” to the latest technology. For example, establishing an automated workflow by introducing BPEL on top of “servicized” EJBs will provide quick wins. On developer and architect level you have people who are thinking in terms of interfaces, have XML skills and an interest in learning the next new thing. It is this type of environment we see SOA maturing and succeeding.

Yet, where SOA gets really interesting, in broad enterprise application landscapes, things are most often different. The Mighty Host is at the center of everything. Some years ago I read an assessment that 80% of the business critical code in the world’s large enterprises and government ITs is still written in COBOL. I don’t think this number has drastically shrinked since!

To approach host / COBOL developers with some SOA slides easily makes you look like some kind of freaky alien who speaks in front of humans: They know what they are doing because they are doing it that way for many many years – and it works!

The only question remains whether you are seen as a harmless alien, someone they can just ignore because he has not enough influence to actually change something. Or whether you are a recognized as a potential threat to the way IT always has has worked here. Then fear is what you will have to deal with. Many people in this environment – developers, architects, even business people live in the culture of job controls and COBOL copy books where, if you need some data from an other system you will find an easy ad hoc way. We have to deal with it: People in this environment don’t want change and will have very good points in why everything is good as it is.

Technically, SOA and mainframes can come together, the implementation culture, language and the needed skills are worlds apart.

To address this it is important to understand the audience you talk to, the culture, the language – and you should be able to speak this language. Ideally, you show them that you can solve problems in their way too, for example by creating some job control based solution. This way gaining trust, reducing alienation and establish a real relationship between people who understand each others way of thinking.

Then you can start to think about how to sell loose coupling to people who embrace point to point connections…

Meet Thomas Erl, Dirk Krafzig and many more @SOA Symposium in Rotterdam

I am looking forward to the SOA Symposium! We will give a preview together with Thomas Erl to the upcoming book “Next Generation SOA and meet David Chappel and Dirk Krafzig. This symposium features the creme de la creme in today’s SOA world, I am also happy that a hero of the 90ies, Grady Booch is there too! I am curious what he has to say on SOA…

Our Magazine on SOA is out (links with German content)

One week ago our SOA Magazin “SOA Spezial: Ready For Change” has been published. This is a compendium of a series of SOA articles that our little cross company group – Clemens Utschig, Torsten Winterberg, Berthold Maier, Bernd Trops and myself have written over the last year. These articles have been published in the German JavaMagazin every month. They deal with topics such as SOA Project Categories, Loose Coupling, some more technical such as Transactions and some more business oriented such as Change Management towards SOA (from our “guest author” Natsuko Hara). All articles have now been gathered into one nice magazine that you can buy at Newspaper shops throughout Germany, Austria and Switzerland:

SOA Spezial

SOA Spezial








This link contains a (German) interview with us authors:

and here is what Torsten writes about the mag:

Torstens blog entry on the mag

Now, whenever I am at a train station or airport, I look for our nice mag and position it in front of all others 😉 (Just kidding)

We will bring some to Oracle Open World, where you can have a look.

Software AG buys IDS Scheer

While it is great to celebrate events such as Oracle SOA Suite 11, the actual impulse to kick start this blog was a shock: Software AG buys IDS Scheer – the company that creates the business process / Enterprise Architecture (EA) platform “ARIS”. ARIS is as well the basis for Oracle’s cool Business Process Management (BPM) offering “BPA Suite”, with its unique approach to align business process models and executable (BPEL) process in a closed loop.

In June 2006 BPA Suite was still a vision and I had memorable discussions with the responsible managers at Oracle Headquarters on Oracle’s plans for BPM platform. I was at a EDS project at that time that investigated ways to close the business / IT gap through model – code round tripping.

IDS Scheer was under discussion for a takeover for long time, I had IBM, Oracle, SAP on my list, now, surprise surprise, Software AG…

I follow Paul Harmon who said in his book “Business Process Change” that BPM tools will be mature and able to fully deliver to their promises by 2015. It will be very interesting to see what Oracle will do now and until then.

What is needed is a tool that allows to navigate from high level, abstract, not automated process models down to models of executable processes and, from there, allows to drill into deployed processes and statistics on their instances and their behavior. And from EA models that depict the system landscape down to the actual physical systems to get a “life” picture of your overall application landscape.

SCA and Loose Coupling

In Oracle SOA Suite 11 it is easy to put everything into a SCA Composit that makes a SOA solution – BPEL processes, integration logic, business rules, human interaction – you name it.

The question architects should consider is whether conceptually all these belong tightly bundled together.

The answer depends on the desired degree of loose coupling.

If you want to add a SOA-Layer on top of a fixed application it may be feasible to wire integration aspects in the new “Mediators” with business process logic in BPEL. This tightly coupled design may be fine when the integrated application (or a set of applications) will stay for the foreseeable future.

Yet, how would a design look like if you want to achieve loose coupling, where processes orchestrate Business Services whose implementation is easily exchangeable? Then the business aspects in processes and business rules should be isolated from integration logic that is close to end systems.

Then it becomes possible to exchange the underlying applications and the affected integration logic with no changes to the orchestrating process logic in your business related SCA Composites.

Such integration logic could translate the exchanged data into the aplication data dialect and knows their protocols. Following the separation of concern principle such logic is very different to the more business related aspects in highler level BPEL business processes and and should be deployed in distinct chunks. This means business aspects and low level technical aspects do not belong in the same SCA composite.

Following this distinction, for integration aspects you could create own SCA composites, one for each orchestrated Business Service. Or, if you have more demanding integration requirements, consinder creating fassades to end systems that are based on services developed in the “new” Oracle Service bus (OSB – ex BEA Aqualogic Service Bus).

OSB belongs now to Oracle SOA Suite, yet the integration into one holistic IDE and console that consolidates SCA, mediator, BPEL and OSB is one of the major things to look for in future releases of Oracle SOA Suite 😉

Fireworks for SOA Suite 11!

Oracle SOA Suite 11 is a major step for Oracle being a major platform to base a SOA on. I remember first talks on one integrated look and feel and deployment at Oracle HQ some three years ago.

There is an attribute of SOA Suite 11g I really like which is easily overlooked among the overwhelming wealth of new features: Although SCA adds yet another technology to the acronym zoo in modern middleware, it rather not increases complexity, but decreases it. Through SCA as a bundling technology it becomes easier to understand an assembly of the constituents of a composite such as a BPEL process, a human interaction, some rules and routing logic. In earlier versions those have been scattered over JDeveloper and we had to figure out through clicking around how they fit together. Now these puzzle pieces of a composite are graphically grouped in one view, so it becomes way easier to grasp what is actually going on and get started. This reduction of complexity continues during deployment and administration, you always look at one bundle, a SCA composite. This reduction of complexity promises to help adoption of SOA based on Oracle Fusion Middleware.