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

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.

CBDI has in their December journal continued the work on their SOA Maturity Model. Interestingly I made the same exercise 6 months ago during the writing of my master thesis, and I am happy to say that CBDI and I arrived at pretty much the same conclusion.

What the article illustrates is that SOA Maturity Models are emerging from many places – demonstrated in the post “SOA Maturity Model…Yes…Another One”.

Hopefully we will see some alignment between the SOA Maturity Models, but even if we do it is my conception that we don’t need a separate Maturity Model for SOA and EA. The challenge is to have one model that covers both EA and SOA. I elaborate on this in chapter 7.5 of my thesis.

EA and SOA shares the same goals, so why go separate ways. I recognize that a Maturity Model is not a roadmap – but is a result of a roadmap. Hence what we really need is to align EA and SOA, and by doing this we will also align the Maturity Models of EA and SOA.

Stating that Services are the central part of both SOA and SOEA will probably not offend anybody. But in my opinion, methods to identify Services are only slowly emerging. When talking about SOA the Services are often seen as a task that will require only a small effort – so small that we almost don’t bother talking about it. The level of detail, in which this task is described, is usually focused on whether to approach this Top-Down or Bottom-up. In practise you will probably use a mix of both, but should have a strong emphasis on the Top-Down – this is necessary in order to control the coherence between the Services.

But how do we actually identify our Services? This is now doubt a discipline normally mastered on the abstraction level of EA. In SOEA we need a method to identify Services in a way that supports the paradigm of SOA and utilizes the experience of EA. The important notion here is that we don’t start from scratch!

In the OASIS SOA Adoption Blueprints TC a first draft of a method to identify Services has just been released, titled: “Methodology for Service Architectures” (For those unfamiliar with this work I would like to strongly recommend this). If you are experienced working with SOA and EA you should however not expect any revolution – it is in fact a very simple method. But this is just where I see the strength of the method. The simple message is: when identifying your Services don’t start developing your solution! Keep on track, and identify the Services one level of abstraction at a time.