With all respect to Anne and Eric ( they know, I do very respect them), the end of the spiral is in the standard, i.e. collective agreed opinion.
I am very sorry, I, probably was lacker than you - I worked for the company where the Business started SOA initiative (while in IT we had to struggle to overcome the ownership mentality of the development managers). One of the mission of this Forum, I guess, is to formulate the position and proactively promote it among those who do not know abbot it yet. I am talking about business-oriented SOA and Business that does not know it works in service-orientation at its top (IT usually sees the bottom of business hierarchy, unfortunately) I do not believe in SOA Maturity Model outside of the EA (for EA needs), especially, if the Model does not include Business enterprise model, its goals and needs. Yes, "IT is different than the business", at least, because it may have its own interests and agenda than the business it is supposed to work with/for (recall many 'cutting edge' technologies that did not proof its applicability to particular tasks but were promoted within IT). I disagree with expression "IT is suppose to build a business solutions"; to me it has to be like this: "Business and IT are suppose to build business solutions"; solution built in IT w/o Business (i.e. being limited by arbitrary requirements only) is usually questionable to the Business. We can fine a lot of IT systems in many organisations created exclusively for technology purposes, and this is not good, at all. For example, this is why I am saying - start with business SOA, define business services and some processes (if needed), define business domain scope for the services top-to-bottom, and only then get into domain driven design in IT; use Domain Service-Oriented Modelling as a ruler for IT initiatives, not other way around (in majority of cases. Sometimes, IT might have wonderful business ideas but it is seldom, unfortunately) - Michael ________________________________ From: A W <[email protected]> To: [email protected] Sent: Sunday, January 4, 2009 2:15:56 PM Subject: Re: [service-orientated-architecture] How to start SOA in Organization ( they know, I do very respect them) I think Eric newcomer, or Ann can provide us with a definition to close up this endless spiral. In addition, SOA is an intuitive, and someone has to take the intuitive. I did not see or hear about business who starts the initiative. Please take a look to SOA maturity model. Again, why do you try to imply the IT is different than the business. IT is suppose to build a business solutions not to build a systems for themselves. The IT systems is about business not about technology. All the best Ashraf Galal On Sat, Jan 3, 2009 at 1:05 PM, Michael Poulin <m3pou...@yahoo. com> wrote: I am afraid, it is an endless spiral... When I look at the standardized SOA definition (vs. home- or vendor-made) , I see no Web Services at all. I believe that 'they' may not start "unifying view of customer, from the IT point of view" because it must be started from the Business point of view. In SOA concept and modelling, the approach is only Top-Bottom; in SOA implementaiton - the Bottom-Up gets added and they meet in the middle (actually, they are getting synchronized all the time and synchronization is achieved in the middle). SOA implementation is focused on building services (applications with interfaces) that can be be maximally easily changed as in the parts as in the compositions. Well defined interfaces is a good practice but not the target. A well defined interface in not only the one, which is clear in each of its element, but which is the same clear in all ways and mechanisms of its possible changes (if needed) with all possible consequences of such changes. For SOA service, it is not necessary to use the same interface in different execution context; only the service has to be the same. This also means that we may not expect the same behavior/result of the service in all execution contexts (even at the technical level) because contexts' policies, regulations, platforms, co-located apps and so on affect the service execution. You see, Web Service or any other interface is just an interface, it does not provide for service orientation by itself. As I said, I agree that "Web services are clearly the most promising technology for distributed computing and systems integration" but Web Services and/or integration itself is not enough to claim SOA. - Michael ________________________________ From: A W <ashra...@gmail. com> To: service-orientated- architecture@ yahoogroups. com Sent: Saturday, January 3, 2009 3:09:52 PM Subject: Re: [service-orientated -architecture] How to start SOA in Organization If you look to any SOA definition you will find that it is based on web services technology, in most cases. When they start to think about a unifying view of customer, from the IT point of view, they will find that they must involve the business with them. Remeber that there are top-bottom approach (your openion), Bottom-up and a mix between them. Because SOA is focused on building applications using components with well defined interfaces. In addition, in SOA approach, the designer is not building a program, a functional unit for one purpose/use only, rather, they are building a service that has a well-defined interface and that can potentially be used in multiple business contexts. All the best Ashraf Galal On Sat, Jan 3, 2009 at 5:33 AM, Michael Poulin <m3pou...@yahoo. com> wrote: "Web services are clearly the most promising technology for distributed computing and systems integration" - is absolutely true but... have very little to do with service orientation, i.e. with SOA. Web Services are standard-based interfaces, nothing more. SOA starts from Business, not from IT. - Michael ________________________________ From: A W <ashra...@gmail. com> To: service-orientated- architecture@ yahoogroups. com Sent: Saturday, January 3, 2009 2:54:10 AM Subject: Re: [service-orientated -architecture] How to start SOA in Organization Web services are clearly the most promising technology for distributed computing and systems integration. But, there are many reasons that go beyond technology. You have to build a framework for thinking about web services adoption in your organization that can bring some of the benefits of the technology without exposing you to unnecessary risk and expense. I think you need a help from external consultant. Don't try to step down the SOA road without such help. Specially, in your industry since in Teleco , the major problem is that business is the technology and the technology is the business. It is time to adopt web services in the organizations now but do not invest in technology in the beginning. Technology is not the problem. You don't need to have an organization wide SOA rollout, and you don't have to re engineer legacy systems that work well. However, you need to build the web services skill set in your company, because the technologies hold great promise for solving some of the tough(not all of course) problems facing IT. The technologies that are available in the market, either vendor or open source products, have achieved capabilities, scalability, ..etc., and ready to be used. I think a lot of projects in the teleco industry can benefit from application of web services, specially the network convergence. I think you will find customer data found in wirline, wireless and cabel. Try to build a unified view of your customer. You will learn too much. All the best Ashraf Galal On Fri, Jan 2, 2009 at 3:03 AM, Fakhar Imran <fakharimran77@ yahoo.com> wrote: Dear all, This is Fakhar from Pakistan, I am working for local Telecom company. I've been assigned to work on the in-house Application Development for our business requirements and I was thinking about presenting SOA for design and implementation for new Software Development. Right now our SW development is not very mature and my fellows are not aware of benifits of SOA (that also includes me :-)). I was wondering how to convince for this grand shift as we are right now using .NET and client-server model . Thanks, Fakhar Imran
