I performed a review on SOA Maturity Model for several organisations in my international company (each organisation has its own HR, payroll, finance and so on like an independent company). I have found that all SOA Maturity Models from vendors a) are different; b) promote related lines of products. This is OK for them but may be totally unsuitable for their consumers. So, 1) if you believe in SOA Maturity Model, build it for yourself by yourself; 2) if you can ( I could not), make it a driver of Business/IT initiative rather than a reflector of what you have and what you want to have.
As of legacy systems and already implemented functionality, some of them are fine, some are not and become the ballast for business efficiency. When I advice using top-down approach, it is, first of all, about analysis: you have to find what is suitable to become a service and which implementation creates coupling between implementation of business functions, i.e. has to be reviewed (for the sake of efficiency and flexibility). Business does not really care about internal IT integration but cares about flexibility - responsiveness to the required changes. An "unifying view of their data" for the business means only one thing - single/shared semantic model (based on the industry and corporate ontologies) of the data and single Master Data resource. With respect to this matter, IT has to provide whatever needed storage infrastructure and transformation/transition processes that guarantee the single Master Data resource while everybody is free to have its own sub-view on it within the single/shared semantic model. At least, SOA services have to use the data for such source only. I hope this can clarify what's what and why. - Michael ________________________________ From: A W <[email protected]> To: [email protected] Sent: Sunday, January 4, 2009 5:22:17 PM Subject: Re: [service-orientated-architecture] How to start SOA in Organization "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) " Practically, we have some of the business functionality already implemented in software. If we start from Top-Bottom approach, that is means we start from scratch. Means more money and more time, so it will be very costly initivatives. We have gathered the requirements, built the Applications or bought it off the shalf, and it is up and running since few years ago. What the business need is the integration and unifying view of their data. The cost for replcing it is very high and there is no doubt that no one can take such risk. This is why the 3 approaches is in place. It is your right to believe or disbelieve on the SOA maturity models or not. But I do believe that the vendors and the research labs in Universities have agreement about that. I want to provide some guidelines to the IT people, but as I siad it is difficult to start without external help. All the best Ashraf Galal On Sun, Jan 4, 2009 at 9:52 AM, Michael Poulin <m3pou...@yahoo. com> wrote: 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 <ashra...@gmail. com> To: service-orientated- architecture@ yahoogroups. com 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
