SOEA - Service Oriented Enterprise Architecture

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.

Link to book here
Auther(s):
Jane Carbone.
Published:
May 10, 2004
ISBN:
0131473794
Published by:
Prentice Hall PTR.

COMMENTS:
In the title I believe that the word “Toolkit” is somewhat misguiding of the actual content of the book. In my opinion she is actually defining a development method for EA – with some parallels to software development methods.
Which I think is GREAT, and shows great potential of tying the EA process together with the development process (and actually implementing the intended architecture).

What I find particularly interesting is (more…)

Link to article
Auther(s):
Olaf Zimmermann, Pal Krogdahl and Clive Gee
Published:
2 Jun 2004
ABSTRACT:
Tries to define a structured approach or analysis and design method is required to craft SOAs of quality. As none of the existing approaches met the authors requirements on recent SOA projects, they suggest combining elements from well-established practices such as OOAD, EA, and BPM, complementing them with innovative elements upon demand.

• “While the SOA approach strongly reinforces well-established, general software architecture principles such as information hiding, modularization, and separation of concerns, it also adds additional themes such as service choreography, service repositories, and the service bus middleware pattern.”

(more…)

Link to article
Auther(s):
Ali Arsanjani
Published:
09 Nov 2004
ABSTRACT:
Discusses the highlights of service-oriented modeling and architecture; the key activities that you need for the analysis and design required to build a Service-Oriented Architecture (SOA).

• SOA is not a product - it’s about bridging the gap between business and IT trough a set of business-aligned IT services using a set set of design principles, patterns and techniches.

(more…)

Auther(s):
Robert L. Glass, V. Ramesh, Iris Vessey
ABSTRACT:
Comparing the topics and methods of the three major subdivisions of the computing realm.

Robert L. Glass et. al. has looked at how, and what, the fields of IT (computer science (CS), software engineering (SE), and information systems (IS)) focus their research;

• what are the topics of interest,
• how is the problem approached,
• which methods are used, what,
• what is their frame of reference and
• what is the level of abstraction.

(more…)