We are getting closer, Rob. "Architecture defines how things are related", Governance provides policies and regulations making those definitions The Rules, management enforces the the rules, development implements the rules. Thus, for development, it is Governance who 'defines' the rules, but it may be an ambiguous expression, I agree. Thank you, Rob, for catching this.
- Michael ________________________________ From: Rob Eamon <[email protected]> To: [email protected] Sent: Monday, January 5, 2009 2:49:13 AM Subject: [service-orientated-architecture] Re: Most SOA Consultants Need a Lesson in SOA "It is responsibility of the SOA Governance to define "how all of this stuff links" together, not vice verse." Architecture defines how things are related, not governance. Goverance provides the processes and policies that make sure projects and designs follow the architecture. I like this phrase from Linthicum: " SOA is something you do, not something you buy, but you also need to do it right." The challenge here is "right" varies quite a bit. -Rob --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <m3pou...@.. .> wrote: > > The description ""Third, there needs to be a predefined process. > While > many SOA consultants try to use older SDLC and enterprise architecture > processes, SOAs need a specific approach that addresses the unique > nature of these architectural patterns. > For instance, there is a traditional focus on > data, but the data needs to be properly bound to services. > Moreover, those services must be properly bound to > processes. > Plus you need to keep track > of all the interdependencies, and how all of this stuff links to SOA governance" > addresses several topics together. > > I do agree that SOA needs special design and development process, > it still can be called SDLC but its content is rather described in ITIL > v.3 than in the v.2. However, I disagree with the sequence of bounding and its > start point. > > As we somehow satiated, proper SOA vision starts in Business. > What Business is? It is not data, it is function using particular > meta-data. Data w/o business interpretation is nothing more than combinations > of 0 and 1. The data business interpretation comes from the definition of > the business functionality - services, functions, features. "traditional focus on data" is about single/common semantic data model and related access > preserving data integrity (i.e. semantics). > to the resources > that provide actual data values for given meta-data. These may be > database, warehouses, legacy systems, data feeds and data access services > on the top. Processes are the forms of the service implementation; they do not > exist outside of the services (the latter are not necessary automated). Hire > level of the business service can require collaboration of the lower level > business services where collaboration is expressed via process and > sub-processes. A massive mistake among IT designers when they deal > with business activity modelling is in that they ask question 'how' > about the process while the first questions have to be 'why' and 'what'. Only > those question lead to understanding of the real business value of the process > as a service function while details of implementation follow the question > 'how'. Thus, the services should not be bound to the processes but higher > services have to be detailed by lower level services via the processes. > > Yes, "you need to keep track > of all the interdependencies" and > keep them as flexible as possible. However, expression "how all of this stuff links to SOA governance" puts everything up-side-down again. It is > responsibility of the SOA Governance to define "how all of this stuff links" together, not vice verse. It is not a free-flight > that has to be put into an order, it is very regulated and strict mechanism, > which can flight like a plane, not like a fly. > > - Michael > > > > > ____________ _________ _________ __ > From: A W <ashra...@.. .> > To: service-orientated- architecture@ yahoogroups. com > Sent: Sunday, January 4, 2009 6:53:14 PM > Subject: Re: [service-orientated -architecture] Most SOA Consultants Need a Lesson in SOA > > > "Third, there needs to be a predefined > process. > While many SOA consultants try to use older SDLC and > enterprise architecture processes, SOAs need a specific approach that > addresses the unique nature of these architectural patterns. > For > instance, there is a traditional focus on data, but the data needs to > be properly bound to services. > Moreover, those services must be > properly bound to processes. > Plus you need to keep track of all the > interdependencies, and how all of this stuff links to SOA governance" > > This is one of the best sentence I have ever read. > > The following is our big challenge in our world: "If your architecture does not seem to be > providing that degree of agility, then you're going to have to loop > back to the beginning to see where you went wrong. Typically, per my > previous point, not enough planning was done and perhaps the wrong > technology solution was employed. In any event, you need to bite the > bullet, spend the money and fix it, or you'll find that your SOA > actually takes you backward." > > We usually measure such agility using metrics. > Metrics is depending on the our understanding and there is such standards to these metrics because it differ from solution to another. > If we can, as I think, try to standardize such metrics to some extent, then we can set some guideline to such agility. > But to measure it we need to define it. > Nick Malik defines it as "Agility is our ability to respond to change gracefully and with few > flaws. If we, as IT, build processes and solutions that don't > take change into account, the cost of avoiding agility will vastly > exceed the cost of embracing it." > > If we can achieve such standardization we will decrease the level of miss-understanding between us. > > All the best > > Ashraf Galal > > > On Sat, Jan 3, 2009 at 9:27 AM, Gervas Douglas <gervas.douglas@ gmail.com> wrote: > > Most > SOA Consultants Need a Lesson in SOA > David S. > Linthicum > www.davidlinthicum. com > > Many people in the planning stages for SOA do > not get the proper advice and guidance as to how to proceed, or even > what a SOA actually is. Thus, the larger tragedy is that many of these > projects will hit the wall, and do so with an impact that will reflect > poorly on the notion of SOA, when it's not really a SOA issue at all. > > First, be wary if consulting organizations > point out their experience in the world of SOA by putting up past > projects as proof of their experience. Most, if not all, of these past > projects are really JBOWS (just a bunch of Web services) and have no > underlying mechanisms to provide agility, which is the core benefit of > SOA. > > The problem is that many of the people > looking to hire SOA consultants don't understand the difference between > JBOWS and a true SOA, and accept JBOWS as "experience. " In reality, > it's an indication that the consultants don't understand the core value > of SOA, and thus could send you off in all sorts of dangerous and > costly directions. So, make sure to hire consultants who understand > that SOA is really about configuration, agility, and changeability, and > not just about service enablement. It's very easy to expose services; > turning those services into solutions is another level of > sophistication. > > Second, many consultants are a bit too chummy > with vendors. Thus, you'll find that they implement the same vendors > and technology each and every time. This should be a huge red flag > since SOA problem domains are all very different, and technology > solutions that work best for the solution are never, ever, from the > same vendor, over and over again. However, when you sell hammers, > everything looks like a nail. The path of least resistance is what you > know, not what you should do. > > Those tasked with managing SOA consultants > need to state clearly that you are looking for the right solution, not > the one they know, or what may be part of an existing partnership. > Indeed, consulting organizations with many preexisting vendor > partnerships should be quickly overlooked. You need guys and gals in > there who are agnostic when it comes to technology, and are willing to > leverage the best-of-breed to address your issues. > > Third, there needs to be a predefined > process. While many SOA consultants try to use older SDLC and > enterprise architecture processes, SOAs need a specific approach that > addresses the unique nature of these architectural patterns. For > instance, there is a traditional focus on data, but the data needs to > be properly bound to services. Moreover, those services must be > properly bound to processes. Plus you need to keep track of all the > interdependencies, and how all of this stuff links to SOA governance, > SOA security, and event management and monitoring. > > Many consultants attempt to oversimplify the > process, rapidly moving through or even foregoing the planning steps. > Their main focus is the selection of the technology, or, in some cases, > they attempt to force fit a problem with a predetermined technology > solution. This can never be good. > > The fact of the matter is that SOA is a > complex distributed system, and thus complex to plan, design, build, > and test. The time spent in planning will later pay huge dividends. > There should be a very rigorous process/methodology defined that, at a > minimum, provides you with a semantic-level, service-level, and a > process-level understanding of the problem domain, not to mention the > governance model and security strategies. Trust me, you can get SOA > right the first time, but with more planning and sweat than you expect. > > Finally, there is the lack of understanding > about ongoing SOA operations and links with traditional enterprise > architecture. You just can't build a SOA; you have to live with your > SOA, ongoing. That means understanding how the solution exists > currently, and how to align it with business as it changes. If your > consultant has done his or her job, you should have an architecture > where the volatility has been abstracted into a configurable domain. > Thus, it's a matter of changing things at the configuration layer to > adjust to the changing nature of the business. Therein is the value of > SOA. > > If your architecture does not seem to be > providing that degree of agility, then you're going to have to loop > back to the beginning to see where you went wrong. Typically, per my > previous point, not enough planning was done and perhaps the wrong > technology solution was employed. In any event, you need to bite the > bullet, spend the money and fix it, or you'll find that your SOA > actually takes you backward. > > The issues here are not a case of bad > intentions. I think everyone honestly wants to do their best. It's a > lack of understanding and perhaps talent in some instances. Those who > do best with SOA have a wide range of skills, a good understanding of > architecture and the value of SOA, and all of the good work that needs > to occur to make it work for the client. However, I don't see many out > there who fit that bill, and the amount of bad advice is becoming a > huge issue. Unfortunately, many won't figure this out until it's too > late. > > SOA is something you do, not something you > buy, but you also need to do it right. > > > > > This message was sent from David Linthicum to xxxxx. It was > sent from: David Linthicum, 11654 Plaza America Drive, #103, Reston, VA > 20190. You can modify/update your subscription via the link below. >
