On 13/11/06, shashank d. jha <[EMAIL PROTECTED]> wrote: > On 11/12/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > On 10/11/06, shashank d. jha <[EMAIL PROTECTED]> wrote: > > > On 11/10/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > > > On 10/11/06, shashank d. jha <[EMAIL PROTECTED]> wrote: > > > > > On 11/9/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > > > > > On 08/11/06, shashank d. jha <[EMAIL PROTECTED]> wrote: > > > > > > > On 11/7/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > So you mean to suggest SOA has global scope? and It is more > > > > > > > > > of a > > > > > > > > > > > > > > > > > > > > > > > > > > > At one point document says > > > > > > > > > > > A service is a mechanism to enable access to one or > > > > > > > > > > more capabilities? > > > > > > > > > > > > > > > > > > > > > > Is service a mechanism or end? > > > > > > > > > > > > > > > > > > > > What is the difference? > > > > > > > > > > > > > > > > > > Difference is mechanism doesn't guarantees service. Whether > > > > > > > > > some one > > > > > > > > > is enabled to access the service is orthogonal to service's > > > > > > > > > existence. > > > > > > > > > > > > > > > > I'm confused by this, you've said that visibility, reachability > > > > > > > > et al > > > > > > > > are confusing and the "same" but now you appear to be arguing > > > > > > > > that > > > > > > > > reachibility and visibility are distinct. > > > > > > > > > > > > > > Hmm.. My opinion was regarding in general that concepts and > > > > > > > elements > > > > > > > have to be evolved at higher level than getting into nitty-gritty > > > > > > > of > > > > > > > the same. My opinion is that RM has not properly found out higher > > > > > > > elements properly. > > > > > > > > > > > > What is higher level than visibility or reachability? I struggle to > > > > > > think of more abstract concepts that mean that. > > > > > > > > > > Higher Level means first > > > > > 1. What is Service Oriented Architecture? > > > > > > > > Which is what the RM does... > > > > > > This is what I complained about. Its not clear. While it claims its > > > purpose is to align IT to business, it has left business concepts and > > > linkage between them undefined. > > > > No it didn't, it said that the _same_ terms and concepts apply at both > > levels. Therefore a service at a business level can use the same > > language and definition as that at a Software level. > > So you basically want business to align with IT? And OASIS RM is about that?
Yes I do, and no it isn't. The RM is about defining SOA. _Practice_ documents, such as TOGAF, Zachman and my book describe how to do the alignment. The RM is _not_ about the practice of IT/Business alignment, its about defining SOA. > > > > > > > > > > 2. Is it IT service? Then its purpose? > > > > > > > > Which is more detailed (less abstract) than the RM > > > > > > Plz elaborate. > > > > You've split the world into two camps and required translation and > > mapping. This is by definition less abstract as you've added in more > > concrete elements. > > > > > > > > > > 3. If it is to support BP/BS directly? (Means there is direct link > > > > > between the IT service and BP/BS and technically it should be > > > > > viable/feasible to traverse along them) or indirectly like everyother > > > > > technology tries to do. Ultimately an enterprise uses IT for it BP/BS > > > > > only. > > > > > > > > Again this is more detailed (less abstract) than the RM. > > > > > > I think you need to first clear the scope of SOA to discuss this. you > > > are not clear about scope of SOA. > > > > The Scope of the SOA RM is to define the terms and conditions of SOA, > > at what ever level (business/Software/Hardware/etc/etc/etc) > > > > Which bit of the scope isn't clear? > > IT has to support business? or Business has to support IT? Or they > have to be aligned? > Refer to my earlier question, IT has to be aligned to business or > business should be aligned with IT? Where is this alluded to in the scope? All of the elements you've said are out of scope. > > If Business Process Management concepts and standards develop > independent of SOA concepts and standards then who/what is supposed to > align them? Or you first intend to develop IT standards and then > envisage business to move around IT concepts? Or BPM to take advantage > of SOA? Out of Scope. > > > > > > > > > > > > > > > 4. Where are the terminologies around Business motivation, business > > > > > process, business service, IT architecture, pattern, components, > > > > > service? > > > > > > > > Not in there because they have nothing to do with the T&Cs for the RM. > > > > These are elements around HOW you do SOA, whereas the RM just says > > > > what "good" SOA looks like. > > > > > > > > > SOA looks like? means what? around what concepts? Earlier you > > > mentioned its about concepts, vocab that should be used in context of > > > SOA. you mean to suggest vocab should not include words around > > > business, business process, business service but around reachability > > > and visibility? > > > > Including a tiered approach of biz->IT would remove one of the key > > powers of the RM which is that it can be applied to both the business > > and IT. Concepts of reachability and visibility are essential to pure > > business services and other capabilities as they are essential at the > > IT level. Why differentiate between two identical concepts when > > visibility for business process is the same as visibility for a > > hardware appliance? > > Key concepts abstracted in SOA are Service, visibility, interaction, > effect etc.. Which are the bits that define the "S" and the "A" of SOA. > > > > > > > > Let us know the scope of SOA first. > > > > I really am struggling to understand what you are after here, the > > scope is defined on the cover and at the start of the RM, which bit of > > that don't you think defines the scope? > > 2.3 The Benefits of Service Oriented Architecture > 1. The main drivers for SOA-based architectures are to facilitate the > manageable growth of large scale enterprise systems, to facilitate > Internet-scale provisioning and use of services and to reduce costs in > organization to organization cooperation. > 2. The value of SOA is that it provides a simple scalable paradigm for > organizing large networks of systems that require interoperability to > realize the value inherent in the individual components. > > It seems very clearly intent of SOA as OASIS views it is for > management of IT systems. We had a long discussion about this. I'd prefered to have extended this to broader areas, where the RM is applicable, but we made a call that it would get messy if we extended the scope because some people would want to start lumping in Business Process et al if we included business. So my view on the RM is that it applies far beyond just IT and I read the word "systems" to include people systems not just IT. > > > > > > > > > > > > > > > OASIS RM directly starts talking about visibility or reachability!!! > > > > > of what? business motivation service? Business process, business > > > > > service, infrastructure component service? architecture service, > > > > > service publication service? or what? > > > > > > > > All of the above. If your motivation (considered as an abstract > > > > business service) is neither visible or reachable then it can be said > > > > to not exist from the perspective of the enterprise... etc etc. > > > > > > Service is not there always to be used directly by end user. Some > > > services may keep running without any user ever knowing about it. So a > > > service should be defined and described independent of end user. > > > > Which isn't what you said earlier, but putting that to one side for a > > moment this is exactly what the RM does, it provides a consistent way > > of describing service and consumer interactions no matter what the > > class of consumer or service (all services must have consumers). > > Not sure. As no doesn't addresses concepts around/required to identify > a service, partition a service, service data, relation between service > models, service interaction points, service metrics, default service > policy, service organization and categorization, service requirement, > customization and extensibility, No it doesn't. And it never was intended to, it would be great if you wanted to do this though. > > > > > > > > > > > > > > > > > > > > > > > > The service is the mechanims for provision, it provides the end > > > > > > > > and > > > > > > > > enables the real world effect to be delivered. I'm not sure > > > > > > > > what you > > > > > > > > are saying about the differences. > > > > > > > > > > > > > > I want to say is that service is different that the mechanism > > > > > > > that can > > > > > > > be used to access a service. > > > > > > > > > > > > How is it? From the perspective of a consumer (the only one that > > > > > > matters) they don't care about how elements are delivered, and there > > > > > > must be some mechanism which makes the delivery, otherwise a service > > > > > > is something that cannot be delivered.... which would be odd. > > > > > > > > > > Any IT is not supposed to be defined and described from its users > > > > > perspective. Lets first construct it. And then try to define it from > > > > > users perspective. It may be good idea to start first from consumers > > > > > perspective but then its just view not service itself? > > > > > > > > I don't get what you are saying here, the words on their own make > > > > sense, its just the sentences that I'm struggling with. > > > > > > I meant the thing that a service should be definable, describable and > > > exist independent of its end user. > > > > Is it possible for a service to exist independently of a consumer of > > some form? This would means it doesn't interact with anything, isn't > > observable and doesn't achieve anything. The only perspective that > > should matter when describing a service to the outside world should be > > the view that the outside world sees. The internal functionality is > > separate and internal, but that is only reflected in the contract that > > the service offers. > > "execution context" is a service? Its category? Why it is being > defined as different from "service" as in SOA? Execution context could be viewed as being provided by infrastructural services (e.g. middleware) but in itself it has no direct value in the producer/consumer interaction. So from the perspective of the consumer of the service the execution context doesn't matter. > > > > Now the RM does say that a contract is part of the overall service > > (producer) side and that it is independent of any individual consumer, > > is that what you meant? > > > > > > > > > > > > > > > Not always, not all services are supposed to be accessed by end > > > > > consumer. Some would be delivered by deployment platform to service > > > > > executing on it. > > > > > > > > The concept of "end" means nothing to a service, it has only > > > > consumers, why should it care if there are things beyond it? This is > > > > the point of the RM, making an arbitary distinction between "end" > > > > things being consumers and "internal" things doesn't actually make a > > > > difference from the perspective of defining an abstraction of > > > > consumers and producers. > > > > > > This I mentioned because you were only suggesting that service has to > > > be described from users perspective. Otherwise service doesn't have > > > any meaning. > > > > Given that the purpose of a service contract is to define how others > > interact with it I would say that it is best practice to describe it > > from their perspective rather than the internal view, this isn't > > mandated by the RM but is something I'd strongly advise. > > > > > > > > So abstraction of service is different form its users. > > > > a service contract is different from service execution if that is what you > > mean. > > A service contract is not defined for execution as well? u are > suggesting that? But then is "deployment" is a service contract"? I said that execution and contract are different, not that a contract doesn't apply to execution. > > Where are the concepts around service fulfillment? A service can not > always be defined as 100% successful or 100% failure!! Where in the RM does it say that it is? I'm really confused here as to where the RM implies that success of execution is a binary thing. > > > > > Else how do you align IT to business need? > > > > > > > > The RM isn't pixie dust, it doesn't do the alignment, it defines the > > > > terms and conditions. It doesn't do implementation, which is exactly > > > > what a "how" is about. > > > > > > If SOA is about alignment of IT along business, this must be reflected > > > in the RM. > > > > Why? Its goal isn't to define the implementation of SOA but the terms > > and conditions of SOA, the alignment is part of the _practice_ and > > therefore not in the reference model. > > I have mentioned the concepts required to set the same, earlier in the > same mail. Being blunt, you haven't. What you have said is the implementation elements that you'd like to see in a reference model, which isn't where they belong. > > And so you agree "Alignment of IT to business is not core of SOA"? I must be going blind, I can't see where I have said that, what I've said is that the _practice_ and implementation of SOA is about alignment. You really need to understand the difference between a reference model and practice guides. > > > > > > > Unless we define the terminologies around business as well, what > > > alignment are we talking about? forget about how? It doesn't helps to > > > elaborate one part and assume the other one. > > > > It elaborates both side, as I've said (several times) you can use the > > RM to define both the business side and the IT side. Business > > Process, like COBOL code, is an implementation detail that will apply > > in some, but not all cases, and hence isn't part of the broad concepts > > that the RM addresses. > > CORBA reference model didn't get away just by defining object model!!! > It defined ORB, Application Interface, Domain Interfaces, Common > Facilities and Object Services and showed their relations. > > Where are entities in SOA? Contract, consumer, producer, execution context etc etc etc > > > > > > > > "How" isn't in scope for the RM it defines "What". > > > > > > That is what my point of contention is. RM fails to define what properly. > > > > So far you've not convinced me, at all, of you views of what the RM > > doesn't define. You appear to want the RM to be not a reference model > > but a guidebook for implementation. > > I have mentioned earlier in this mail concepts around services missing. As above, you really haven't you've said you want practice guidelines in the SOA RM and a description of non-SOA related elements in the RM. Neither of these things should be in an SOA RM. > > > > > > > > > > > > > > > > > > > > > Because they are not aligned. And thats why need solution around > > > > > > > Zachman framework, or EA or now buzzzzz SOA. > > > > > > > > > > > > Zachman is _not_ a reference model, it is an architectural > > > > > > framework. > > > > > > It is a set of guidelines and approaches for the implementation of > > > > > > architecture, Zachman could _use_ the SOA RM if it so wished but > > > > > > Zachman (and TOGAF) are very different beasts for a reference model. > > > > > > What you appear to be asking for is a specialisation of Zachman for > > > > > > SOA, which was never the goal of the RM, but you should probably go > > > > > > and have a look at the Reference Architecture currently being > > > > > > developed. > > > > > > > > > > Zachman's scope if wider than scope of SOA. And I meant that RM is not > > > > > addressing enterprises IT concern. As a reference I pointed out so > > > > > many concerns needs to be considered as mentioned in Zachman's > > > > > framework to be able to come out with RM and than an architecture to > > > > > align IT to business. > > > > > > > > Eh? The RM isn't a competitor to Zachman, people who use Zachman (and > > > > frameworks like it) can use the RM to provide a more formal definition > > > > of SOA than the one that Zachman has and then use Zachman as the > > > > approach to their implementation. > > > > > > > > You are comparing apples with oranges to compare the RM and Zachman. > > > > > > I didn't mean to compare. I brought this point because soemwhere it > > > was mentioned that RM is more abstract and complete than Zachman > > > framework. > > > > The RM is more complete around the concept of SOA than Zachman, it is > > more abstract than Zachman in its totality. Hence the reason that you > > can use the RM in association with Zachman. > > RM doesn't defines the terminologies around services completely. > Including service configuration, decomposition etc. Which are to do with IMPLEMENTATION not with the definition of services. They have no place in a reference model. As a question: Explain how the configuration of a bespoke web service written in C++, the configuration of Oracle Applications services and the configuration of a call center work in the same way from an abstract perspective that actually means something. > > > > > > > > > > > > > > > > > > > > > > > > Why do you think that a reference model needs to be inconsistent > > > > > > > > between the business and IT levels of SOA (if its consistent > > > > > > > > there is > > > > > > > > no reason for there to be a mapping). > > > > > > > > > > > > > > I always meant that they have to be consistent. So we need to > > > > > > > take or > > > > > > > consider holistic view of an enterprise like Zachman framework > > > > > > > does. > > > > > > > This ensures consistency. but its too abstract and ideal and vast > > > > > > > to > > > > > > > be filled up completely. > > > > > > > > > > > > As above, they are different things. Zachman does not define in a > > > > > > consistent manner a single view of service that operates at all the > > > > > > different levels, its goal is to help in the practice of > > > > > > architecture. > > > > > > > > > > I think it does provide a consistent view of same service across > > > > > organizational and granularity level. > > > > > > > > It provides a mapping, not a consistent set of terms and a model that > > > > works at all those levels. > > > > > > Its not supposed to provide terminologies, as its not addressing those > > > concerns. And also terminologies varies from time to time, technology > > > to technology, enterprise to enterprise, vendor to vendor. Otherwise > > > its very consistent in its approach to EA. > > > > Which is one of the differences between it and the RM. The RM took on > > the challenge of defining the terminologies of SOA, Zachman looks at > > the practice. > > What terminologies? All the difficult concepts around services are > left un-answered. Zachman defined terminologies around business > process etc, and information model etc. at higher level of abstraction > then SOA does. Zachman is PRACTICE, this is not the goal of the RM. TOGAF does the same (but is open standards based) as Zachman and is also about practice. BOTH are able to take advantage of the RM as a common definition of SOA which would mean a TOGAF team and a Zachman team would be better able to exchange information and collaborate around SOA concepts while delivering IT/Biz alignment. > > > > > > > > > > > > > > > If you want a guideline on "how" to do SOA then.... read my book :) > > > > > > > > > > > > > > > > > > > > > > > What is the general opinion of people here? > > > > > > > > > > > > > > > > > > > > Mine is that the SOA RM is currently the best definition > > > > > > > > > > we have, if > > > > > > > > > > we need to make some of the language less confusing and > > > > > > > > > > have a bunch > > > > > > > > > > more communication papers then lets get to it. But I > > > > > > > > > > would disagree > > > > > > > > > > on the idea that the RM isn't abstract enough. > > > > > > > > > > > > > > > > > > I think we need to identify, conceptualize and then refine > > > > > > > > > components > > > > > > > > > of SOA around > > > > > > > > > > > > > > > > > > (Vision, Goal, Objective) and the term Means to refer > > > > > > > > > generally to any > > > > > > > > > of the 'action plan' concepts (Mission, Strategy, Tactic). > > > > > > > > > Organizational structures and Resources • Functional > > > > > > > > > breakdowns • Data > > > > > > > > > and information models • Strategy • Business Rules > > > > > > > > > Business processes - Abstract, public or global > > > > > > > > > Events, Activities, Message flow, group, task, > > > > > > > > > IT model, software architecture, pattern, components/objects, > > > > > > > > > deployment infrastructure etc. > > > > > > > > > > > > > > > > That is implementation and architecture, not a reference model. > > > > > > > > > > > > > > Mission/Strategy/Tactic business process? architecture/ patterns, > > > > > > > interaction, message flow. event flow?, components, IT model, > > > > > > > activities are implementation of what? > > > > > > > > > > > > They are implementations in themselves, they are concrete outputs > > > > > > defined for a specific task. A Mission statement is a CREATED > > > > > > element > > > > > > specifically for a given architecture, a business process is created > > > > > > for a specific business process... there is a big difference > > > > > > between > > > > > > the goals of these elements and the goals of a reference model. > > > > > > > > > > And what is goal of RM? to provide terminologies around SOA? and it is > > > > > excluding the words of concern. > > > > > > > > Could you reword the second sentence, the RM is addressing the areas > > > > of concern as laid out in the original terms of reference for the > > > > group. The RM is _not_ trying to create some "uber" standard to rival > > > > TOGAF, thus elements of implementation of SOA (like motivation, > > > > mapping, governance, security et al) are excluded. > > > > > > If SOA is about aligning IT to business, it has left the more > > > important half's concepts, vocab, terminologies etc. > > > > No it hasn't, as before. You can use the RM to define business > > services and business capabilities. What it doesn't cover is > > implementation details on _either_ side of the Biz/IT divide. > > > > > > > > > > > > > > > > > > Implementation doesn't have to mean sofware or hardware is created. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I happen to attend Mr Zachman's worksop recently. And I > > > > > > > > > believe EA or > > > > > > > > > buzzz word SOA needs to address enterprise and IT as a whole > > > > > > > > > to > > > > > > > > > address agility of software systems for being business agile. > > > > > > > > > > > > > > > > You see this is why I should read _all_ of an email before > > > > > > > > replying. > > > > > > > > I now understand your confusion. You are thinking that > > > > > > > > Architecture > > > > > > > > is a reference model, it isn't, it is an approach to delivery. > > > > > > > > A > > > > > > > > reference model provides the T&Cs for architectures, but > > > > > > > > architectures > > > > > > > > say what gets actually done. > > > > > > > > > > > > > > I am saying that an architecture should have a reference model. > > > > > > > And > > > > > > > reference model should show its major components and their > > > > > > > relations. > > > > > > > The RM by OASIS for SOA is not proper. There is not even a single > > > > > > > diagram to show RM. One diagram that shows relation of RM with > > > > > > > others. > > > > > > > This is where Business motivation etc are covered. This means BP, > > > > > > > BS, > > > > > > > motivation are not intrinsic to SOA. So has limited scope. > > > > > > > > > > > > Eh? There are lots of diagrams in the RM, if you mean there isn't a > > > > > > cut out and keep A0 diagram that will print out poster size then you > > > > > > are right, and feel free to create one. You are confusing > > > > > > implementation elements (i.e. how does this BP effect my service > > > > > > architecture) with a reference model which looks to define the > > > > > > abstract concepts of what a service represents. > > > > > > > > > > > > The RM is like a dictionary, it tells you the terms, it is then up > > > > > > to > > > > > > you the writer (architect) to create things out of those words. The > > > > > > dictionary will tell you if you spelt them correctly, if the > > > > > > sentence > > > > > > means anything, but it will not help you in the actual construction > > > > > > of > > > > > > a sentence. This is the difference between the RM and Zachman. > > > > > > > > > > > > > > > I suggest you to look into SOA diagram published by OMG in its > > > > > initiative to get standards for SOA to know what I meant. > > > > > > > > I've looked at it.... and that helps you at the abstract level? > > > > > > Yeah. It is without any ambiguity or understanding the concerns. The > > > picture tells the scope of SOA and mentions IT concepts/technologies > > > to achieve the same. > > Its intended purpose itself as pointed out by me several times, is not > alignment as mentioned in the RM itself. If its intention is just to > define service and its description, then it was not required. As all > the services modeled and implemented till now had service description, > contract execution context etc, albeit using different technology, > documenting, code, IDL etc. You appear to be implying that you can't do SOA with CORBA... a brave implication. > > And it leaves the same hole, as it clearly mentions that SOA is > software architecture. About managing IT systems. And so RM for BPM is > bound to be different (as it is out of scope of SOA) and so > inconsistency continues. Welcome to the real world, the universe is an NP complete problem, there will be no single element that removes all inconsistencies. Physics has been trying to pull gravity and quantum mechanics together for quite a while now. There will be further efforts that help, there will be future work, the RM is not the end of the road and the group welcomes contributions and extensions that use the RM and set out to solve other problems. The RM says "While service-orientation may be a popular concept found in a broad variety of applications, this reference model focuses on the field of software architecture. The concepts and relationships described may apply to other "service" environments; however, this specification makes no attempt to completely account for use outside of the software domain" This means that you can apply it to other areas (as I do with businesses) but that the group just focused on software (mainly to keep the group focused on core concepts). So the RM is 100% not limited to software only and 100% can be used to effectively define BPM environments and solutions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If SOA to succeed not another hype, it must first identify > > > > > > > > > and relate > > > > > > > > > concepts around business and relate them with IT. > > > > > > > > > > > > > > > > And for us to do that we must first define what SOA is. The > > > > > > > > SOA RM > > > > > > > > provides a strong abstraction which can be applied at both of > > > > > > > > those > > > > > > > > levels, the job of architects is then to provide a translation > > > > > > > > between > > > > > > > > two consistent models, rather than previous where there was a > > > > > > > > large > > > > > > > > disconnect between the business model and the IT model, the > > > > > > > > shearing > > > > > > > > between those two is what has in part led to the disconnect > > > > > > > > between > > > > > > > > business and IT that exists. > > > > > > > > > > > > > > Exactly. and definition of SOA by RM of OASIS is not even > > > > > > > including > > > > > > > word business in its definition. So disconnection still exists. > > > > > > > > > > > > The SOA RM _can_ be used at a business level (I have done this) so > > > > > > no > > > > > > disconnect exists. There was a long debate around whether it should > > > > > > cover just software or broaden, in the end the decision was to focus > > > > > > on software but ensure that the RM is applicable elsewhere, which > > > > > > IMO > > > > > > it is. A service can be a pure business element with zero > > > > > > technology > > > > > > and be 100% compliant with the RM. > > > > > > > > > > I can use CORBA, Jini, UML etc. around business concepts but that is > > > > > not their intended usage. Similarly SOA RM has not cared to explore > > > > > vocab or ideas that needs to be addressed by SOA. > > > > > > > > I can 100% use the SOA RM language in a business environment, I have > > > > done in fact and it worked (concepts of visibility matter in any > > > > consumer/producer interaction for instance, that is why people have > > > > marketing departments). > > > > > > Marketing is more important? Or service itself, its purpose, > > > description, availability, its scope, etc. > > > > The RM covers all elements of a service contract and description, but > > your argument was that visibility shouldn't be in there. If a service > > isn't visible then its pointless no matter how "good" it is, this > > applies at the IT level and at the business level. > > I always maintained that more important higher level concepts were > left. I have outlined few of them. You've listed things that are in Zachman (a practice framework) but never explained why these are in the RM. > > > > > > > Remember we are still defining SOA itself, its scope, terminologies.. > > > forget about its marketing. We market a product. But a product has to > > > be defined first, its scope, its concerns, its requirement, > > > terminologies. Marketing is secondary to product specification. > > > > No it isn't, marketing is an essential part of product specification, > > and indeed sometimes marketing is much more important than the > > specification itself. > > > > There are implementation details that are specific to a domain, these > > are not in the RM, however the critical success elements and what must > > be achieved is in the RM. > > RM is incomplete. for reasons mentioned in this mail. The RM is complete _for what it is_ it is not complete in terms of explaining the entire sum of human knowledge on IT/Biz alignment,IT delivery and BPR/BPM, neither is Zachman BTW. > > > > > > > > > > > > > > > > > > > > > > > > > > > What is strong in abstraction provided by it? Abstraction of > > > > > > > business > > > > > > > process? Abstraction of IT service? Abstraction of linkage between > > > > > > > two? Translation mechanism between two? > > > > > > > > > > > > Why translate processes into services or vice versa? Why not > > > > > > consider > > > > > > the enterprise as services that are implemented using business > > > > > > processes. The RM is not about the "HOW" of doing the work, it is > > > > > > about the terms. > > > > > > > > > > Enterprise is not a service. Because the laws that govern an > > > > > enterprise is not directly applicable to laws that govern IT services? > > > > > > > > Why can't IT be governed in the same way as the enterprise? > > > > > > It can be. Way could be for sure same. Provided enterprises are run in > > > the same manner for same purpose in the same way as software systems > > > are. And variables affecting enterprises can be captured as precisely > > > as IT systems's. If we can abstract the scope, strategy, mission, > > > laws of land, etc. could be captured as precise or closer to as we can > > > capture an IT systems scope, patterns, usage etc. > > > > I was thinking of the other way around. Why can't IT be governed like > > a business. But either way you seem to be saying that the business > > level can be viewed in the same way, which is the point of the RM. > > RM is about managing IT resources, as per OASIS RM. Nope, its about managing _systems_ which may or may not be IT, its also about the broader concepts of IT. > > > > > > > > > > > > > conceptually/logically its different. But we can always abstract like > > > > > that and then call it "abstract service" and then Business BP or > > > > > service is one realization of service and IT services are another > > > > > realization. > > > > > > > > > > Neither enterprises related terms are included, nor business related > > > > > terms nor motivation, nor governance related terms nor service is > > > > > defined properly. Neither linkage among various concepts are shown > > > > > properly. what else. > > > > > > > > Nor are they meant to be. You really seem to be expecting the RM to > > > > be a Zachman/TOGAF/IAF competitor, but that isn't its motivation, its > > > > to get agreement on a VERY simple thing... > > > > > > > > What is a service > > > > What is SOA > > > > > > > > And then enable the likes of Zachman/TOGAF/IAF/CBM etc to use that > > > > definition to make it simpler for themselves. > > > > > > No. RM should have defined scope, terminologies used within scope etc, > > > so that its not mis-understood and not ambigous. > > > > Your point appears to be that the RM should have created a clear > > separation between IT and business and then provided a way of mapping > > between them using SOA. The problem is that neither IT nor Business > > implementation are covered by the RM, we didn't cover how to build a > > service in IT, how to deploy it, how to management or any of those > > elements. This is the point, it doesn't do that on either side. > > > > Your argument appears to be that you think the RM should have had a > > different scope, but you haven't really said what that scope should > > be. Could you put in a paragraph exactly what you think the scope of > > the RM should have been? > > In this case, as per OASIS RM its IT infrastructure, IT systems, IT > vocabulary etc. Nope, as above. > > > > > > > > > > > > > > > > > > > > > > > When major abstractions are missing, what we are supposed to do > > > > > > > with > > > > > > > refined ones? > > > > > > > > > > > > It isn't missing, it was never intended to be in there, you are > > > > > > confusing practice with a reference model. > > > > > > > > > > What is a reference model? > > > > > > > > "A reference model is not directly tied to any standards, technologies > > > > or other concrete implementation details. It does seek to provide a > > > > common semantics that can be used unambiguously across and between > > > > different implementations. The relationship between the Reference > > > > Model and particular architectures, technologies and other aspects of > > > > SOA is illustrated in Figure 1." > > > > > > > > You did READ the RM didn't you? This is on the opening page. > > > > > > Yeah I did read. But the figure one says "SOA and its relation with > > > other". This means everything else in the diagram is external to SOA > > > right? SO RM is guided by those concepts identified. Not that they > > > fall within scope of SOA. > > > > Errr no its external to the REFERENCE MODEL not SOA, so the SOA RM is > > used to drive reference and implementation architectures (it isn't > > directly implementatable itself). > > This is why it is incomplete, very raw, scope is limited, as any > reference architecture derived from this RM is a description of a > subset of the reference model. A reference architecture doesn't have to derive just from one reference model, CORBA implementations for instance also incoprated things like the OSI networking model and others into the implementations. > > So I find your understanding of SOA RM and SOA little confusing. My understanding of the RM is from being on the group. The struggle here is simple (and I'm not going to reply again as we are now firmly in a death spiral) You like Zachman and think that the RM should be an SOA _practice_ specification focused on IT business alignment, and you want to see all of the implementation and practice elements covered in the RM. The RM however was never intended as a practice document, so will never deliver what you want. In terms of my understanding on SOA maybe this will help http://www.infoq.com/minibooks/enterprise-soa Cheers for the debate, and feel free to define a "reference model" that covers everything you want, I'd be happy to read it. But use some more flexible logic rather than the invariant kind you currently apply. > > -- > --------------- > regards, > shashank d. jha > e-mail [EMAIL PROTECTED] > > > > > Yahoo! Groups Links > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
