1. Why are people pursuing SOA, isn’t it dead?
2. What is the relationship of SOA Governance to SOA itself?
3. What is SOA Governance?
4. How does it differ from Management?
5. How does SOA differ from Integration?

While being able to think and speak clearly about these topics may not win you as many brownie points as it would during the time when this was a “hot topic” for Enterprise IT, it will help you understand why SOA and SOA Governance continue to be significant issues for the Enterprise despite the ups and downs of market hype cycles.>>

--- In service-orientated-architecture@yahoogroups.com, "Gervas"
<gervas.douglas@...> wrote:
>
> You might find this Q&A on the subject of interest:
http://tech.groups.yahoo.com/group/n-gaa/message/1130
>
> What do you think of its relevance to SOA?

More specifically do you think it could usefully be used to break down data
silos?

Gervas

>
> Gervas
>

You might find this Q&A on the subject of interest:
http://tech.groups.yahoo.com/group/n-gaa/message/1130

What do you think of its relevance to SOA?

Gervas

The book "SOA Governance achieving and sustaining business and it
agility" by Willim Brown, Robert Laird, Clive Gee and Tilak Mitra. IBM press
Is deserve the time to read too. It has nothing to say about IBM
products at all.
It just about the process.
All the best

Ashraf Galal
Gervas Douglas wrote:
>
> *You can read the following article in full at:
>
> http://www.infoq.com/articles/poulin-wonderland-soa-governance
>
> Gervas*
>
> <<One man, Harry W., once said "/Alice// does not fall down the hole.
> She sees the white //rabbit, is intrigued, and willingly follows him
> down the deep rabbit hole/." Yes, the secret of Wonderland is about
> the meaning of the words: Harry has insisted that Alice ‘/willingly
> follow[s]’/ into the Rabbit Hole while Alice has certainly “/found
> herself falling down
>
<http://www.amazon.co.uk/Alice-Wonderland-Pop-up-Lewis-Carroll/dp/0689837593/ref\
=sr_l_l?ie=UTF8&s=books&qid=1252961769&sr=8-l>/”.
> The same happens with SOA Governance – like in the Rabbit Hole, one
> thinks about governance but talks about management and another one
> does the exact opposite...
>
> We used to think that management includes governance. This is correct
> understanding: Oxford and Merriam-Webster dictionaries as well as
> English Synonym Dictionary <http://dico.isc.cnrs.fr/dico/en/search>
> include 'governance' as a remote synonym to 'management'. However, the
> opposite is not true -governance is not management. Governance is
> about policies and controlling riles while management is about policy
> execution and controls. Management needs governance because without
> governance it does not know what and how to run, execute or preserve.
>
> I am aware of at least 3 books written about SOA Governance and at
> least 8 articles published only in infoQ
> <http://www.infoq.com/governance> on this topic in the last two years.
> Nonetheless, I have found that in absolute majority of publications
> about SOA Governance it is directly associated with policy enforcement
> or with a straightforward management. To date, only OASIS SOA
> Reference Architecture (RA), Public Review Draft 1
> <http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra-pr-01.pdf>
> recognises the effect of the 'rabbit hole' and clearly separates
> governance of service-oriented environment from its management
> <http://www.infoq.com/news/2008/08/poulin-governance>.>>
>
>

<<OASIS SOA technical Committee has published the second Public Review Draft of SOA Reference Architecture now under the refined title 'Public Review of Reference Architecture Foundation for SOA v1.0'

This review has a lot of updates and new content with regard to the first Public Review Draft published last year. This Draft has a 'Navigating the SOA Standards Landscape Around Architecture' in its background - the collaboration agreement on SOA standard efforts between OASIS, OMG and The Open Group.

Also, this Draft contains several outstanding statements that are very important to the understanding of modern state of service-oriented architecture and service orientation at large. For example, the Abstract says: "Our focus in this architecture is on an approach to integrating business with the information technology needed to support it."

This statement is supported by OASIS conclusion that "Service Oriented Architecture (SOA) is an architectural paradigm that has gained significant attention within the information technology (IT) and business communities. The SOA ecosystem described in this document occupies the boundary between business and IT. It is neither wholly IT nor wholly business, but is of both worlds. Neither business nor IT completely own, govern and manage this SOA ecosystem. Both sets of concerns must be accommodated for the SOA ecosystem to fulfill its purposes."

You are all welcome to Modern SOA!>>

You can read this at: http://www.ebizq.net/blogs/service_oriented/2009/11/new_soa_standard_public_review_draft.php

Gervas

<<One man, Harry W., once said "Alice does not fall down the hole. She sees the white rabbit, is intrigued, and willingly follows him down the deep rabbit hole." Yes, the secret of Wonderland is about the meaning of the words: Harry has insisted that Alice ‘willingly follow[s]’ into the Rabbit Hole while Alice has certainly “found herself falling down”. The same happens with SOA Governance – like in the Rabbit Hole, one thinks about governance but talks about management and another one does the exact opposite...

We used to think that management includes governance. This is correct understanding: Oxford and Merriam-Webster dictionaries as well as English Synonym Dictionary include 'governance' as a remote synonym to 'management'. However, the opposite is not true -governance is not management. Governance is about policies and controlling riles while management is about policy execution and controls. Management needs governance because without governance it does not know what and how to run, execute or preserve.

I am aware of at least 3 books written about SOA Governance and at least 8 articles published only in infoQ on this topic in the last two years. Nonetheless, I have found that in absolute majority of publications about SOA Governance it is directly associated with policy enforcement or with a straightforward management. To date, only OASIS SOA Reference Architecture (RA), Public Review Draft 1 recognises the effect of the 'rabbit hole' and clearly separates governance of service-oriented environment from its management.>>

Governance is different than management.
Governance is not charged with implementing the SOA.
Governance provides oversight to see that SOA is accomplished in a
manner that satisfies the principles and policies required to
successfully and continually sustain the SOA environment.
There are different kind of governances in an enterprise starting with
Enterprise governance, then IT governance then SOA governance that
extends IT governance.
The best definition of SOA that incorporate the definition of SOA
governance is from OASIS, SOA reference model one
(www.oasis-open.org/home/index.php)
Although the management and governance overlapped with each other, but I
think it is better to distinguish between SOA implementation or
management than SOA governance.

All the best

Ashraf Galal

rschmelzer wrote:
>
>
>     The Four Stages of SOA Governance
>
>
>         Document ID: ZAPFLASH-20091112 | Document Type: ZapFlash
>         By: /Jason Bloomberg/ | Posted: /Nov. 12, 2009/
>
>
> For several years now, ZapThink has spoken about SOA Governance "in
> the narrow" vs. SOA governance "in the broad." SOA governance in the
> narrow refers to governance of the SOA initiative, and focuses
> primarily on the Service lifecycle. When vendors try to sell you SOA
> governance gear, they're typically talking about SOA governance in the
> narrow. SOA governance in the broad, in contrast, refers to IT
> governance in the SOA context. In other words, how will SOA help with
> IT governance (and by extension, corporate governance) once your SOA
> initiative is up and running?
>
> In both our Licensed ZapThink Architect Boot Camp
> <http://t.ymlp38.com/hqjmazaebbaxauybhalaemss/click.php> as well as
> our newer SOA and Cloud Governance Course
> <http://t.ymlp38.com/hqjjataebbarauybhafaemss/click.php>, we also
> point out how governance typically involves human
> communication-centric activities like architecture reviews, human
> management, and people deciding to comply with policies. We point out
> this human context for governance to contrast it to the technology
> context that inevitably becomes the focus of SOA governance in the
> narrow. There is an important technology-centric SOA governance story
> to be told, of course, as long as it's placed into the greater
> governance context.
>
> One question we haven't yet addressed in depth, however, is how these
> two contrasts -- narrow vs. broad, human vs. technology -- fit
> together. Taking a closer look, there's an important trend taking
> shape, as organizations mature their approach to SOA governance, and
> with it, the overall SOA effort. Following this trend to its natural
> conclusion highlights some important facts about SOA, and can help
> organizations understand where they want to end up as their SOA
> initiative reaches its highest levels of maturity.
>
> *Introducing the SOA Governance Grid*
> Whenever faced with to orthogonal contrasts, the obvious thing to do
> is put them in a grid. Let's see what we can learn from such a diagram:
>
> *The ZapThink SOA Governance Grid*
>
> First, let's take a look at what each square contains, starting with
> the lower left corner and moving clockwise, because as we'll see,
> that's the sequence that corresponds best to increasing levels of SOA
> maturity.
>
>    1. Human-centric SOA governance in the narrow
>
>       As organizations first look at SOA and the governance challenge
>       it presents, they must decide how they want to handle various
>       governance issues. They must set up a SOA governance board or
>       other committee to make broad SOA policy decisions. We also
>       recommend setting up a SOA Center of Excellence to coordinate
>       such policies across the whole enterprise. These policy
>       decisions initially focus on how to address business
>       requirements, how to assemble and coordinate the SOA team, and
>       what the team will need to do as they ramp up the SOA effort.
>       The output of such SOA governance activities tend to be written
>       documents and plenty of conversations and meetings.
>
>       The tools architects use for this stage are primarily
>       communication-centric, namely word processors and portals and
>       the like. But this stage is also when the repository comes into
>       play as a place to put many such design time artifacts, and also
>       where architects configure design time workflows for the SOA
>       team. Technology, however, plays only a supporting role in this
>       stage.
>
>    2. Technology-centric SOA governance in the narrow
>
>       As the SOA effort ramps up, the focus naturally shifts to
>       technology. Governance activities center on the
>       registry/repository and the rest of the SOA governance gear.
>       Architects roll up their sleeves and hammer out
>       technology-centric policies, preferably in an XML format that
>       the gear can understand. Representing certain policies as
>       metadata enables automated communication and enforcement of
>       those policies, and also makes it more straightforward to change
>       those policies over time.
>
>       This stage is also when run time SOA governance begins. Certain
>       policies must be enforced at run time, either within the
>       underlying runtime environment, in the management tool, or in
>       the security infrastructure. At this point the SOA registry
>       becomes a central governance tool, because it provides a single
>       discovery point for run time policies. Tool-based
>       interoperability also rises to the fore, as WS-I compliance, as
>       well as compliance with the Governance Interoperability
>       Framework
>       <http://t.ymlp38.com/hqjbazaebbaxauybhataemss/click.php> or the
>       CentraSite Community
>       <http://t.ymlp38.com/hqjhalaebbapauybhavaemss/click.php> become
>       essential governance policies.
>
>    3. Technology-centric SOA governance in the broad
>
>       The SOA implementation is up and running. There are a number of
>       Services in production, and their lifecycle is fully governed
>       through hard work and proper architectural planning. Taking the
>       SOA approach to responding to new business requirements is
>       becoming the norm. So, when new requirements mean new policies,
>       it's possible to represent some of them as metadata as well,
>       even though the policies aren't specific to SOA. Such policies
>       are still technology-centric, for example, security policies or
>       data governance policies or the like. Fortunately, the SOA
>       governance infrastructure is up to the task of managing,
>       communicating, and coordinating the enforcement of such
>       policies. By leveraging SOA, it's possible to centralize policy
>       creation and communication, even for policies that aren't
>       SOA-specific.
>
>       Sometimes, in fact, new governance requirements can best be met
>       with new Services. For example, a new regulatory requirement
>       might lead to a new message auditing policy. Why not build a
>       Service to take care of that? This example highlights what we
>       mean by SOA governance in the broad. SOA is in place, so when a
>       new governance requirement comes over the wall, we naturally
>       leverage SOA to meet that requirement.
>
>    4. Human-centric SOA governance in the broad
>
>       This final stage is the most thought-provoking of all, because
>       it represents the highest maturity level. How can SOA help with
>       the human activities that form the larger picture of governance
>       in the organization? Clearly, XML representations of technical
>       policies aren't the answer here. Rather, it's how implementing
>       SOA helps expand the governance role architecture plays in the
>       organization. It's a core best practice that architecture should
>       drive IT governance. When the organization has adopted SOA, then
>       SOA helps to inform best practices for IT governance overall.
>
>       The impact of SOA on Enterprise Architecture (EA) is also quite
>       significant. Now that EAs increasingly realize that SOA is a
>       style of EA, EA governance is becoming increasingly
>       Service-oriented in form as well. It is at this stage that part
>       of the SOA governance value proposition benefits the business
>       directly, by formalizing how the enterprise represents
>       capabilities consistent with the priorities of the organization.
>
> *The ZapThink Take*
> The big win to moving to the fourth stage is in how leveraging SOA
> approaches to formalize EA governance impacts the organization's
> business agility requirement. In some ways business agility is like
> any other business requirement, in that proper business analysis can
> delineate the requirement to the point that the technology team can
> deliver it, the quality team can test for it, and the infrastructure
> can enforce it. But as we've written before
> <http://t.ymlp38.com/hqjwaiaebbaxauybhacaemss/click.php>, as an
> emergent property of the implementation, business agility is a
> different sort of requirement from more traditional business
> requirements in a fundamental way.
>
> A critical part of achieving this business agility over time is to
> break down the business agility requirement into a set of policies,
> and then establish, communicate, and enforce those policies -- in
> other words, provide business agility governance. Only now, we're not
> talking about technology at all. We're talking about transforming how
> the organization leverages resources in a more agile manner by
> formalizing its approach to governance by following SOA best practices
> at the EA level. Organizations must understand the role SOA governance
> plays in achieving this long-term strategic vision for the enterprise.
>
>

The Four Stages of SOA Governance

Document ID: ZAPFLASH-20091112 | Document Type: ZapFlash
By: Jason Bloomberg | Posted: Nov. 12, 2009

For several years now, ZapThink has spoken about SOA Governance "in the narrow" vs. SOA governance "in the broad." SOA governance in the narrow refers to governance of the SOA initiative, and focuses primarily on the Service lifecycle. When vendors try to sell you SOA governance gear, they're typically talking about SOA governance in the narrow. SOA governance in the broad, in contrast, refers to IT governance in the SOA context. In other words, how will SOA help with IT governance (and by extension, corporate governance) once your SOA initiative is up and running?

In both our Licensed ZapThink Architect Boot Camp as well as our newer SOA and Cloud Governance Course, we also point out how governance typically involves human communication-centric activities like architecture reviews, human management, and people deciding to comply with policies. We point out this human context for governance to contrast it to the technology context that inevitably becomes the focus of SOA governance in the narrow. There is an important technology-centric SOA governance story to be told, of course, as long as it's placed into the greater governance context.

One question we haven't yet addressed in depth, however, is how these two contrasts -- narrow vs. broad, human vs. technology -- fit together. Taking a closer look, there's an important trend taking shape, as organizations mature their approach to SOA governance, and with it, the overall SOA effort. Following this trend to its natural conclusion highlights some important facts about SOA, and can help organizations understand where they want to end up as their SOA initiative reaches its highest levels of maturity.

Introducing the SOA Governance Grid
Whenever faced with to orthogonal contrasts, the obvious thing to do is put them in a grid. Let's see what we can learn from such a diagram:

The ZapThink SOA Governance Grid

First, let's take a look at what each square contains, starting with the lower left corner and moving clockwise, because as we'll see, that's the sequence that corresponds best to increasing levels of SOA maturity.

1. Human-centric SOA governance in the narrow

   As organizations first look at SOA and the governance challenge it presents, they must decide how they want to handle various governance issues. They must set up a SOA governance board or other committee to make broad SOA policy decisions. We also recommend setting up a SOA Center of Excellence to coordinate such policies across the whole enterprise. These policy decisions initially focus on how to address business requirements, how to assemble and coordinate the SOA team, and what the team will need to do as they ramp up the SOA effort. The output of such SOA governance activities tend to be written documents and plenty of conversations and meetings.

   The tools architects use for this stage are primarily communication-centric, namely word processors and portals and the like. But this stage is also when the repository comes into play as a place to put many such design time artifacts, and also where architects configure design time workflows for the SOA team. Technology, however, plays only a supporting role in this stage.

2. Technology-centric SOA governance in the narrow

   As the SOA effort ramps up, the focus naturally shifts to technology. Governance activities center on the registry/repository and the rest of the SOA governance gear. Architects roll up their sleeves and hammer out technology-centric policies, preferably in an XML format that the gear can understand. Representing certain policies as metadata enables automated communication and enforcement of those policies, and also makes it more straightforward to change those policies over time.

   This stage is also when run time SOA governance begins. Certain policies must be enforced at run time, either within the underlying runtime environment, in the management tool, or in the security infrastructure. At this point the SOA registry becomes a central governance tool, because it provides a single discovery point for run time policies. Tool-based interoperability also rises to the fore, as WS-I compliance, as well as compliance with the Governance Interoperability Framework or the CentraSite Community become essential governance policies.

3. Technology-centric SOA governance in the broad

   The SOA implementation is up and running. There are a number of Services in production, and their lifecycle is fully governed through hard work and proper architectural planning. Taking the SOA approach to responding to new business requirements is becoming the norm. So, when new requirements mean new policies, it's possible to represent some of them as metadata as well, even though the policies aren't specific to SOA. Such policies are still technology-centric, for example, security policies or data governance policies or the like. Fortunately, the SOA governance infrastructure is up to the task of managing, communicating, and coordinating the enforcement of such policies. By leveraging SOA, it's possible to centralize policy creation and communication, even for policies that aren't SOA-specific.

   Sometimes, in fact, new governance requirements can best be met with new Services. For example, a new regulatory requirement might lead to a new message auditing policy. Why not build a Service to take care of that? This example highlights what we mean by SOA governance in the broad. SOA is in place, so when a new governance requirement comes over the wall, we naturally leverage SOA to meet that requirement.

4. Human-centric SOA governance in the broad

   This final stage is the most thought-provoking of all, because it represents the highest maturity level. How can SOA help with the human activities that form the larger picture of governance in the organization? Clearly, XML representations of technical policies aren't the answer here. Rather, it's how implementing SOA helps expand the governance role architecture plays in the organization. It's a core best practice that architecture should drive IT governance. When the organization has adopted SOA, then SOA helps to inform best practices for IT governance overall.

   The impact of SOA on Enterprise Architecture (EA) is also quite significant. Now that EAs increasingly realize that SOA is a style of EA, EA governance is becoming increasingly Service-oriented in form as well. It is at this stage that part of the SOA governance value proposition benefits the business directly, by formalizing how the enterprise represents capabilities consistent with the priorities of the organization.

The ZapThink Take
The big win to moving to the fourth stage is in how leveraging SOA approaches to formalize EA governance impacts the organization's business agility requirement. In some ways business agility is like any other business requirement, in that proper business analysis can delineate the requirement to the point that the technology team can deliver it, the quality team can test for it, and the infrastructure can enforce it. But as we've written before, as an emergent property of the implementation, business agility is a different sort of requirement from more traditional business requirements in a fundamental way.

A critical part of achieving this business agility over time is to break down the business agility requirement into a set of policies, and then establish, communicate, and enforce those policies -- in other words, provide business agility governance. Only now, we're not talking about technology at all. We're talking about transforming how the organization leverages resources in a more agile manner by formalizing its approach to governance by following SOA best practices at the EA level. Organizations must understand the role SOA governance plays in achieving this long-term strategic vision for the enterprise.

http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper

---- Begin Extract -----
Today, HTTP and TCP are the protocols of the web.  TCP is the generic,
reliable transport protocol, providing guaranteed delivery, duplicate
suppression, in-order delivery, flow control, congestion avoidance and
other transport features.  HTTP is the application level protocol
providing basic request/response semantics. While we believe that
there may be opportunities to improve latency at the transport layer,
our initial investigations have focussed on the application layer,
HTTP.

Unfortunately, HTTP was not particularly designed for latency.
Furthermore, the web pages transmitted today are significantly
different from web pages 10 years ago such and demand improvements to
HTTP that could not have been anticipated when HTTP was developed. The
following are some of the features of HTTP that inhibit optimal
performance:

     * Single request per connection. Because HTTP can only fetch one
resource at a time (HTTP pipelining helps, but still enforces only a
FIFO queue), a server delay of 500 ms prevents reuse of the TCP
channel for additional requests.  Browsers work around this problem by
using multiple connections.  Since 2008, most browsers have finally
moved from 2 connections per domain to 6.
     * Exclusively client-initiated requests. In HTTP, only the client
can initiate a request. Even if the server knows the client needs a
resource, it has no mechanism to inform the client and must instead
wait to receive a request for the resource from the client.
     * Uncompressed request and response headers. Request headers today
vary in size from ~200 bytes to over 2KB.  As applications use more
cookies and user agents expand features, typical header sizes of
700-800 bytes is common. For modems or ADSL connections, in which the
uplink bandwidth is fairly low, this latency can be significant.
Reducing the data in headers could directly improve the serialization
latency to send requests.
     * Redundant headers. In addition, several headers are repeatedly
sent across requests on the same channel. However, headers such as the
User-Agent, Host, and Accept* are generally static and do not need to
be resent.
     * Optional data compression. HTTP uses optional compression
encodings for data. Content should always be sent in a compressed
format.
---- End Extract ----

Now it still says its using the HTTP methods so I'd guess its still
"REST" compliant, the main differences being that with the server
pushing information to the client it might break some of those
"stateless" pieces.

Its good to see people taking the latency problem seriously and
looking for a fix.

Steve

Where you start from is important, says Steve Jones, a CTO at consultancy CapGemini in the U.K. Out-of-the-gate understanding of the roles of services and process steps is part of that. Jones suggests starting with a SOA-oriented approach. But the tenor of that approach is key. If it is utterly technology-centric, the BPM-SOA project is likely to stumble. Jones encourages a SOA approach that is grounded in business understanding.

''SOA for us is a business thing,'' said Jones. ''It is a way of modeling the business, thinking about the business and understanding the business.''

On one level, there are similarities to BPM and SOA approaches.

''If you think about an organization at its highest level, whether you are looking at high-level BPM models or at a services methodology, you actually end up with the same bundles.''

A business-oriented approach to SOA can help BPM, suggested Jones.

''Using SOA as we do—as an architecture and business modeling approach—helps bridge the gap between traditional business process modeling and technology delivery,'' he said.

Where it becomes most interesting is where there are "steps." This is where BPM that has little SOA underpinning can go astray. When a process is seen as something contained in a service, better outcomes ensue.

Said Jones, ''Where SOA becomes really required is where BPM has a number of steps. We would say that it is the service that is always the 'grown' in the relationship. It contains the processes - the capabilities that need to be delivered.''

It is BPM's job to build process steps; it is the service model's job to access them, he indicated.

In short, in Jones' view: ''SOA makes really, really good BPM. But BPM bakes really bad SOA.''>>

You can find this article at: http://searchsoa.techtarget.com/news/article/0,289142,sid26_gci1374106,00.html#

Gervas

I can provide you with my dissertation that I wrote it 2007, if you want.
The purpose was to clarifying the concept and compare the two
architectural styles WS-* and REST and it accompanied with  a prototype
that you can follow it and implement it to tie the architectural concept
to the implementation techniques.
I do believe it is a very simple architectural concept and easier to
grasp and understand better than any other architectures.
All the best

Ashraf Galal

Michael Poulin wrote:
>
> Sweta,
>
> it involves neither programming nor 'just apps' but architecture and
> training takes several years...
>
> - Michael
>
> ------------------------------------------------------------------------
> *From:* sweta.dave <sweta.dave@...>
> *To:* service-orientated-architecture@yahoogroups.com
> *Sent:* Sat, November 7, 2009 6:16:45 PM
> *Subject:* [service-orientated-architecture] help me
>
>
>
> hi
> i m new to SOA.Can anybody tell me what it is.It is worth to get
> trained in SOA to grab job .
>
> It involves any programming or just apps.
>
> thanks
>
>
>