SOEA - Service Oriented Enterprise Architecture

70 % of IT budgets are used on infrastructure – servers, OS, storage and networking. The problem with the IT infrastructure is that is difficult to change. Perhaps it is not the change of the infrastructure but the applications running on the infrastructure that will give the difficulties.

Gartner points out that in order to evolve/change the infrastructure an active long term effort is required. This effort is to be supported by strategic plan for the infrastructure.

Gartner refers to the famous article “Does IT Matter” by Nicholas Carr. It is Gartner opinion that going the SOA way will matter if done now, as the flexibility given by SOA will not be wide spread for the next 10 years. Depending on their definition of SOA in this context it is my opinion that SOA is much closer than the 10 years (I will return to this).

Gartner introduces the concept of “real-time infrastructure” – the ultimate destination:

• Shared across customers, business units and applications
• Dynamically driven by business policies and service level requirements
• Automatically configured and optimized
• Delivering agile, high-quality IT services at lower, business driven costs.

Gartner defines a maturity model of seven levels, where I am particular interested in – Gartner views the essential part at this maturity level as being; “Service Management”. This view entails the need to combine the disciplines of EA, SOA and utilizing the possible benefits using tools.

I was getting tired of looking at the old design of my Blog. I have found this which I think look real nice.. And this was also a god time to upgrade to WordPress 1.5

Besides working on my thesis I am also leading the development of mobile applications on Roskilde Festival.

Yesterday we launched our first version of our WAP-site (called Onmob.dk) and our SMS news service (which is free to use by the way :-). You can read more here…

One of the challenges of developing the WAP-site is the very wide variety of mobile terminals. We have developed a mechanism to convert the pictures into the right format and size – If just there where standards on this area!!
Since the devices themselves don’t provide information of their screen size we have to supply this information manually… so hopefully over time we support most devices.

Link to article
Auther(s):
David Sprott
Read:
15 March 2005
Comments:
SOA is not just a magical silver bullet – but then again wouldn’t that be to easy/boring?

David Sprott starts by emphasizing that SOA and Web Services are NOT identical! Exactly one of my great problems when discussing SOA – I 100% agree with David Sprott on this notion! This will be one of my next tasks to put on my blog; Definitions of the concept of SOA and the concepts around.

Back to the article…
When to use services is often a question asked. There is no easy answer to this question but often it is recommended not use services when integrating between to native compatible platforms. David Sprott is opting for; when you think SOA, services should be used to ensure the same possibilities for integration internal as external. He makes this point with reference to the “real world” where it is almost inconceivable not to have incompatible platforms.

Continuing on the “reality ride” he introduces “The Chernobyl Strategy” which in short is: The Vendor of your system has stopped the development and will in the future only provide basic support. The system is however fulfilling the business needs and wrapping it behind services can be a temporary solution. This of course requires a strategy in order to prevent the almost inevitable “meltdown” – hence the name “The Chernobyl Strategy”.

He brings up another classic question of whether SOA just isn’t a new word for Component Based Architecture. “The service oriented architecture is a classic component based architecture, but complemented with many different types of implementation and a service invocation layer.”
The question, I believe, is often raised by people who believes of SOA as just an implementation of Web Services – as so often before a matter of definitions, and a clear indication of the importance of aligning your definitions within your organization and business partners.

And then for the real interesting stuff! “A Framework for SOA”. Or at least it is for me as I am currently working on exactly the mapping of what I call “the products of the SOA process” into the Zachman Framework. The “Framework for SOA” is inspired by the Zachman Framework.
I am not going to discuss the mapping yet but after a quick glance at his Framework I can see wee have a lot of similarities – A good indication that we could be on to something!
Another subject on which we have reach the same conclusion is; a lot of the products of the SOA process are necessary tools for the purpose of IT Governance.

link to pdf
The text is a brochure and is of course “coloured” by this. But I do believe that they make some good points along the way.

• New technologies requires new methodologies to ensure successful implementation.
• There are two sides of SOA;

- Development and implementation
- It system planning and Governing

(more…)

Link to article
Auther(s):
David Trowbridge, Ward Cunningham, Matt Evans, Larry Brader, Microsoft Platform Architecture Guidance; Paul Slater, Wadeware.
Published:
June 2004
Comments:
I will only write a few general points from this article, as it isn’t that relevant for my thesis. The reason I don’t find it relevant, at least not at this point, is because it presents of a finer grained version of the Zahcman Framework.

I am currently working on identifying products of the SOA process and trying to map these into the Zachman Framework. To add further complexity to this equation will only add possible frustration…

However what is a more general concept is their mapping of patterns into the Framework. This is an interesting approach! Patterns are a solution to a given described problem based on a set of rules. By having mapped patterns into the framework it should be expected that a similar set of problems have been placed in the framework. So here could be some clues to what product of the SOA process should be placed where…

Link to article
Auther(s):
Phil Wainewright
Published:
Thursday, March 3, 2005
ABSTRACT:

From the Loosely Coupled weblog

Talks of the maturing of how SOA is conceived by the vendors in the industry - going from only seeing it as a technical issue but also looking at higher level issues – agreeing with me conception of SOA.

He talks of 5 layers in the SOA stack:

• Routers
  In short; The physical routing of messages. He only Talks of the ESB approach, but that is only one of approaches of implementing SOA, not looking at the “point to point” approach. But as he points out it is only the Base of SOA, though it is a very central decision if you are going to use an ESB or point to point – A decision that could be taken at EA level.
• Monitors
  I would very much like to read the mentioned report. No doubt however that monitoring of technical aspects of a running service, and perhaps even more important; compliance to defined architecture and policies.
  An interesting notion is that he applies some of this responsibility on the Router level and thereby automating some of the task of monitoring the running SOA.
• Registres
  My understanding of this level is, that it is an ”advanced logging mechanism”. Implying that it should be closely integrated with the Monitor layer.
• Governors
  His definition of this level could be pictured as the ”IT administration department of the SOA”. As he also points out this is an essential part of a running SOA – manage and update the rules of the SOA and making sure that the Monitoring and Registering level is reporting on an up to date rule set. Entering the world of rules also means entering the world of business as the rules should be based on the business. A tool at this level could be BPEL.
• Decisioneers
  This is his addition to what he sees as the normal definition of SOA. His description of this level looks very similar to a description of EA. But this is exactly why it is so interesting! SOA, if applied correctly, will have a great influence on how one should approach EA and SOA.

I agree with Phil on his perception of SOA. The specific 5 layers that he has defined I can’t comment at this time. However there is no doubt in my mind that the issues that he raises must be approached when working with SOA!

What I would like to se is the 5 levels to ”the next level ” and how these tasks can be solved in practise.

I am currently looking at the relations between SOA and EA and where the two interacts. Taking a short look at the 5 levels in the SOA stack they are all relevant to the EA – especially to ensure full empowerment and organizational support of the tasks of the 5 levels.