SOEA - Service Oriented Enterprise Architecture

As you might have noted my posting rate has somewhat diminished lately. The reason is that I have been invited to Blog on a new biweekly magazine and online media for IT professionals in Denmark called Version2.

My initial intention was to write on both blogs, but busy days seems to make this somewhat difficult – however the intention lives on.

I will however be writing on Version2, but as this is in Danish I believe the some of you might have some difficulties…

I got inspired from reading Steve Jones’ Blog-post titled: “The biggest lie in IT – Enterprise”, which in short says the there is no such thing as tool that will work across the entire enterprise.

I believe that this is spoken like a true pesimi… I mean architect
No seriously, he has a point. No product is going to solve your problems. However it might help solve your problems - if used right. The only thing that can make enterprise solutions work is YOU. And what you will probably find is that it is not the product that will be your biggest challenge – your biggest challenge is the organization.

Having a tool working across an entire enterprise requires more than the tool, it also requires that it is used in a controlled fashion. An endeavor that requires full organizational support (and power)!

The concept of SOI has become a commonly used concept – no surprise. SOA is a paradigm focusing on developing applications, and of course these applications must run on something.

What happens in most organizations is that the SOI is implemented as a part of a project, which is fine. But the real test is when the next project is to be implemented on the same SOI!

As the topic of this post is regarding the infrastructure I will focus on the technical aspects, of which some of the common difficulties a project #2 is likely to face are:

• Testing requires existing services being available for test-purposes
• Specifying the hardware requirements
• Handling concurrency
• Vendors support of standards is often marketecture and not reality
• Tweaking for performance is difficult
• Project #1 have made undocumented “shortcuts”
• Project #1 is not able to comply with the requirements of project #2
• More to come

Before talking about success in the public sector it is necessary to take a brief look at what success is within the public sector – a question with different answers depending on who you ask.

A manager within the public sector success is typically based on the size of his/hers budget and/or number of staff. As SOA and EA potentially promises to reduce both of these, SOA is really not that appealing to public manager. As it will only reduce next years budget and number of personal it is not an appealing career move.

However what is happening in many governments is that the public tasks are not protected by the traditional organizational boundaries – as might have been. This means that different agencies potentially can take over tasks from other agencies if they can perform the same task cheaper – which for a manager in the public sector is a god career move! And where does SOA then fit into all this? As SOA is an architecture with a high reuse potential, SOA is the perfect to create a competitive edge in order to acquire task from other agencies.

In Denmark this is not commonly seen – yet! But it is my prediction that with the strong focus the Danish government has on EA and SOA it is only a matter of time before we see Danish public agencies “snatching” tasks from each other. The winner is going to bee the one who is best prepared – bear in mind that Denmark is a very small country, and from a IT perspective it makes little sense having multiple agencies solve tasks which are similar..

As a previous employee at the Danish National IT and Telecom Agency working whit OIOXML I heard a lot of nagging about OIOXML being impossible to use in practice.

I am now on the “other side of the table” and assist customers in implementing OIOXML. So now I guess I should start nagging on my former colleagues… But NO. As I have always claimed: OIOXML is easy and fits perfectly with the ideas of SOA an EA (SOEA). Of course there are challenges, but it has newer been easy to develop enterprise-wide data definitions/models!

But if you don’t understand OIOXML NDR, SOA and EA (SOEA) it is understandable that it’s going to be extremely difficult to develop OIOXML schemas.

So, accusing OIOXML of being useless and impossible is not right. However I perfectly understand that people find it difficult to develop OIOXML as there is not a lot of material that puts OIOXML in perspective. Here are just a couple of suggestions on articles that I believe can help to create a better understanding of OIOXML:

• From Data modeling to message modeling
• OIOXML and SOA/EA (SOEA)
• Best practice on designing OIOXML
• When to use OIOXML, and when not to use OIOXML

Feel free to add further suggestions..

Just a little follow-up on the local a|EA Chapter in Denmark where I am now a member of the board, and looking at my follow board members I am sure that the Danish a|EA chapter is going to be a very interesting chapter – at least if you a EA-geak

For the people that know me there should be now doubt in their mind that I see ESB as a concept (an ESB) and not a product (the ESB). The reason I bring this up is that I have just read the article “Applying ESB” in the April edition of the CBDi Journal.

It is my conception that CBDi agrees with my view of an ESB, but I have a critique of their latest article where they start to try and specify what is, and what is not, a part of an ESB. In my world an ESB should be viewed as a paradigm which can be used in a SOA. How the ESB is to be perceived within the individual architectural context is part of making a successful SOEA.

The following table is just some of the aspects which should be considered when conceptualizing your ESB – what do you need, what is nice to have and what doesn’t matter?

Read the rest of this entry »

I keep hearing people talking about SOA as a strategic goal - or in other words the “to-be” of their EA-program. In my world this isn’t possible, SOA might be the means to reach a strategic goal, but must never be the goal itself!

SOA is not a “one size fits all” and it is important to acknowledge this and identify the right flavor of SOA for the given enterprise. However doing this requires a strategy on which to target “the right flavor of SOA”. SOA makes many promises but none of them comes for free…

So lets just emphasize: SOA must never be a strategic goal in it self!

I would like to make a little commercial for the Association of Enterprise Architects (a|EA) which is a global forum for Enterprise Architects with local chapters around the world. An initiative to make a Danish chapter was made by John Gøtze and Kristian Hjort-Madsen, of course I had to attend the first meeting.

It was indeed a good meeting with about 25 attendants covering a very broad spectrum of both public- and private sector. Furthermore I am now a member of the board, and I am looking forward to our next meeting in a|EA.

An Enterprise Service Bus (ESB) is not a product, but a concept which can be implemented. However, this of doesn’t mean that a lot of vendors is not selling product called ESB’s. That being said, I am applauding the development we are seeing of the products in the ESB-area! This is simply a prerequisite for the implementation of SOA.

Evaluating these products is however quite a challenge as there are quite complex systems, and furthermore the sales-pitches of the different vendors should make any enterprise architect suspicious. Therefore I was pleased to see the initiative of Network Computing where they are testing a series of ESB products (ends at March 16):

• BEA Systems AquaLogic Service Bus 2.1
• Cape Clear ESB 6.5
• Fiorano SOA Platform 2006 3.7
• IBM WebSphere Message Broker 6.0
• Software AG Enterprise Service Integrator (ESI) 7.2
• Oracle SOA Suite
• Sonic Software SOA Suite 6.1
• Tibco

This is really good reading, and I believe a good motivation for the different vendors to make their tools even better 