Anne, I agree with your point about focus. Focus on the right level for a given situation. Focus on the right services to be built/exposed, not about tyingMessage 1 of 117 , Dec 21 1:52 PMView SourceAnne,
I agree with your point about focus. Focus on the right level for a
given situation. Focus on the right services to be built/exposed, not
about tying applications together.
But I don't think that changes whether or not integration is a core
part of SOA. SO principles are about defining services and their
interfaces with the "outside" world. Again, I agree that integration
isn't *the* thing to focus upon, but it is an SOA thing, IMO.
--- In email@example.com, "Anne Thomas
Manes" <atmanes@...> wrote:
> If your focus is integration, then you're less likely to be thinking
> about reducing redundancy through application consolidation.
> Integration is driven by individual projects, i.e., taking lots of
> small steps, but not bothering with the "thinking big" aspect. If
> you combine SOA with a strong application portfolio management
> effort, then I don't think the difference is anything to be
> concerned about. The execution of specific projects tends to be
So information about governance is more important than information about service design and development? Hmmm. Not exactly, Rob, more accurately - notMessage 117 of 117 , Jan 3, 2009View Source"So information about governance is more important than information about service design and development? Hmmm." Not exactly, Rob, more accurately - not 'about' governance but about 'how' the governance regulates development process and enforces the good practices of the development. For example, if someone uses SOAUI for SOA service testing and declares that services have been tested, the SOA Governance has to have a policy saying - no, pal, you have not tested SOA service but only SOAP communication; your job is not done yet!.. Now, the manager has to enforce such policy and follow up with the developers (based on the policy) till proper testing complete.""Governance" is the latest fad word that was previously covered in large part by "management. " " - covered in the sense of enforcement, yes. However (IMO), it was up to individual manager what to enforce. As a result, the quality and architectural integrity was usually sacrificed for the sake of 'simplify', resource 'problems', 'minimal' risks and other managerial excuses for keeping the development under not technically qualified (in many cases) directions.As you see, when talking about SOA governance, I want to give Architects more power to influence proper solution implementations, I want Architects to allow producing the 'law' while keeping management in its regular role of managing/enforcing the laws.- Michael