SOEA - Service Oriented Enterprise Architecture

New (supporting) blog on Version2

site admin — Wed, 29 Nov 2006 11:05:18 +0000

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…

Spoken like a true pesimi… I mean architect ;-)

site admin — Thu, 17 Aug 2006 13:20:19 +0000

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)!

Service Oriented Infrastructure (SOI)

site admin — Wed, 16 Aug 2006 10:52:33 +0000

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

SOA succes in public sector

site admin — Mon, 12 Jun 2006 19:05:10 +0000

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..

OIOXML

site admin — Tue, 16 May 2006 11:02:16 +0000

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..

Association of Enterprise Architects (a|EA) #2

site admin — Thu, 04 May 2006 16:32:00 +0000

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

“An ESB” or “the ESB”

site admin — Tue, 02 May 2006 09:35:20 +0000

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?

Communication	Service interaction
· Routing · Addressing · Protocols and standards (HTTP, HTTPS) · Publish / subscribe · Response / request · Fire & forget, events · Synchronous and asynchronous messaging	· Service interface definition (WSDL) · Substitution of service implementation · Service messaging models required for communication and integration · (SOAP, XML, or proprietary Enterprise · Application Integration models) · Service directory and discovery
Integration	Quality of service
· Database · Legacy and application adapters · Connectivity to enterprise application integration middleware · Service mapping · Protocol transformation · Data enrichment · Application server environments (J2EE and .Net) · Language interfaces for service invocation (Java, C/C++/C#)	· Transactions (atomic transactions, compensation, WS-Transaction) · Various assured delivery paradigms (WS-Reliable Messaging or support for Enterprise Application Integration middleware)
Security	Service level
· Authentication · Authorization · Non-repudiation · Confidentiality · Security standards (Kerberos, WS-Security)	· Performance · Throughput · Availability · Other continuous measures that might form the basis of contracts or · Agreements
Message processing	Management and autonomic
· Encoded logic · Content-based logic · Message and data transformations · Message / service aggregation and correlation · Validation · Intermediaries · Object identity mapping · Service / message aggregation · Store and forward	· Administration capability · Service provisioning and registration · Logging · Metering · Monitoring · Integration to systems management and administration tooling · Self-monitoring and self-management
Modelling	Infrastructure Intelligence
· Object modelling · Common business object models · Data format libraries · Public versus private models for business-to-business integration · Development and deployment tooling	· Business rules · Policy-driven behaviour, particularly for · service level, security and quality of service capabilities (WS-Policy) · Pattern recognitio

[Source: Patterns: Implementing an SOA using an Enterprise Service Bus]

After having completed the conceptual definition of your ESB you can start identifying if there are any products which will cover your needs, and you will probably find that no single product will. What will often happen is that you will build your ESB of several products.

Selecting how to implement your ESB is not an easy task, not only due to the complexity of the task, but also because you are essentially building the heart of your enterprise!

“Define your needs – select the product that fits”

SOA is NOT A GOAL in itself

site admin — Mon, 10 Apr 2006 13:13:55 +0000

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!

Association of Enterprise Architects

site admin — Tue, 28 Mar 2006 07:38:17 +0000

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.

Test of ESB’s

site admin — Thu, 09 Mar 2006 11:08:58 +0000

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):

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

CBDI follows up on SOA Maturity Model

site admin — Wed, 04 Jan 2006 15:55:30 +0000

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.

Going past the hype

site admin — Wed, 04 Jan 2006 09:37:15 +0000

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…

Identifying the Services

site admin — Wed, 30 Nov 2005 14:33:17 +0000

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.

Thesis completed!

site admin — Mon, 21 Nov 2005 15:28:09 +0000

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!

Pop Quiz – The game of SOA

site admin — Tue, 25 Oct 2005 14:34:04 +0000

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.

SOS – we are going down…

site admin — Wed, 28 Sep 2005 19:41:14 +0000

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…

Business is from Mars, Technology is from Venus

site admin — Tue, 06 Sep 2005 08:38:37 +0000

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

You don’t get the hype without effort!

site admin — Tue, 06 Sep 2005 08:02:26 +0000

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.

The hype of SOA #19

site admin — Sat, 27 Aug 2005 12:24:46 +0000

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

(Continued from this post)

The hype of SOA #18

site admin — Sat, 27 Aug 2005 12:23:44 +0000

Place independent
Physical location can be changed runtime.

(Continued from this post)

The hype of SOA #17

site admin — Sat, 27 Aug 2005 12:22:58 +0000

Platform independence.
SOA can work across multiple platform through standard interfaces.

(Continued from this post)

The hype of SOA #16

site admin — Sat, 27 Aug 2005 12:21:53 +0000

Cut down in development cost.
The development cost will initially be higher, but will when the SOA matures be lover.

(Continued from this post)

The hype of SOA #15

site admin — Sat, 27 Aug 2005 12:20:56 +0000

Flexibility to interchangeably change from one service provider to another.
Integration is not only an internal issue.

(Continued from this post)

The hype of SOA #14

site admin — Sat, 27 Aug 2005 12:20:03 +0000

Easy integration with both inside and outside partners – cutting expense.
The ability to seamlessly integrate systems across platform and silos is by some seen as what SOA is all about.

(Continued from this post)

The hype of SOA #13

site admin — Sat, 27 Aug 2005 12:19:01 +0000

Creating real-time/on demand systems
The concept of the; “On Demand Business” is a concept trademarked by IBM. It is a parallel to the previous “Supporting “short lifetime” products” and the same comments apply here.

(Continued from this post)