SOEA - Service Oriented Enterprise Architecture

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.

I have previously made a few posts about the hypes of SOA – e.g. what SOA will magically bring you. Joe McKendrick hits the issue spot on; SOA dos not give you anything for free, but if you know your primary objective of “going SOA”, these goals are obtainable. Joe McKendrick gives in his post ten examples of projects following this trail of thought! This is how to do it…

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.

I turned in my thesis on November the 1’st, and when to the exam November the 16’Th. And I am happy to say that the result was an A+!!!

I will follow up on this shortly as I need to thank a lot of people. But as I have promised a lot of people that I will now make my thesis available here on my blog!

So don’t hesitate to download it here, and please feel free to comment!

I have been playing a bit with the definition of SOA, and instead of trying to define SOA I have defined when SOA is reached:

SOA is reached when the IT organization has all the architectural support, governance support, and tooling required to manage IT as a business. Business processes are constantly being optimized. The agile business is realized, and the monitoring is automated. Optimisation is the main focus and new technologies, that can improve the return on investment (ROI), can be implemented quick and seamlessly.

I believe that this little game had a quite interesting result! But as I am due to hand in my master thesis on Tuesday, you will have to wait a bit for the follow-up.

Working in the world of IT are you of cause very familiar with the extensive use of acronyms. And you have might also have experienced naming a concept or project something that made up an acronym so unfortunate that you had to change the name.

Making Service Oriented Systems, or in short SOS… (Try and google “Service Oriented Systems” )

I was chatting with a CIO the other day and asked him, “In retrospect, do you think you were involved enough in the early stages of your ERP implementation?”

He answered, “In retrospect - no - I wasn’t involved enough. Had I known the size of it I would have definitely gotten more involved.”

I followed up with, “Are you aware that an enterprise SOA roll-out will be significantly larger than your ERP implementation?”

He started laughing; he thought I was joking. My face didn’t change. He quit laughing. “Jeff, are you serious?”

“Yes, I’m very serious. SOA is a complete overhaul impacting how systems are analyzed, designed, built, integrated and managed. And not just some systems - all systems including packaged applications like ERP.”

I simple love this quote by Jeff Schneider. It really says it all; if you don’t approach SOA respect your ship will go down…

I simply have to quote Dave Welsh for this one:

Business is from Mars, Technology is from Venus.

I believe it says it all. It will be a continual struggle to get these two worlds to come together. It is not impossible, but I think we need a good broker

EA was an effort to do this from the business perspective, and SOA was an effort to do it with a more technical approach. Will the solution the be SOA - A + EA = SOEA

All the sales pitches I have listed here on my blog won’t come by them selves they require hard work. However I believe if you approach SOA with respect it is possible to get the promised benefits. The key lies in not seeing SOA as a “stand alone” project, but to integrate SOA closely into to your EA program – Stated by Gurpreet S. Pall on his presentation on the TechEd in Malaysia 2004: “If you don’t do EA, you can’t do SOA.”

But what still remains to be answered is how to integrate EA and SOA! SOA will fundamentally change how to approach IT within the enterprise; hence also change how you approach EA.

If you have stumbled upon other sales pitches than the ones I have pointed out please feel free to comment.

Making IT Governance easier.
Easing central overview of the IT Enterprise

(Continued from this post)

Place independent
Physical location can be changed runtime.

(Continued from this post)