+1. I'll also add that some consultant are set of predefined generic "ideal" procedure they try to use on every situation. I often hear customers complain that they want an advice that THEY can USE under their given circumstances to IMPLEMENT - not a set of predefined rules and procedures written in some books, articles, and manuals. There should be some predefined procedures, but a consultant should be able to adjust the procedures to make it implementable for a given situation. A $$$ project with over 1000 people involved with coding outsourced to overseas division is not going to done in the same way as a small pilot project involving less than 20 people in a same room. :-)
H.Ozawa --- In [email protected], Gervas Douglas <gervas.doug...@...> wrote: > > > <http://click.icptrack.com/icp/relay.php? r=54205795&msgid=672521&act=J1NT&c=334543&admin=0&destination=www.davi dlinthicum.com> > > > Most SOA Consultants Need a Lesson in SOA > <http://click.icptrack.com/icp/relay.php? r=54205795&msgid=672521&act=J1NT&c=334543&admin=0&destination=http%3A% 2F%2Fdavelinthicum.blogspot.com%2F2009%2F01%2Fmost-soa-consultants- need-lesson-in-soa.html> > > David S. Linthicum <mailto:da...@...> > www.davidlinthicum.com > <http://click.icptrack.com/icp/relay.php? r=54205795&msgid=672521&act=J1NT&c=334543&admin=0&destination=http%3A% 2F%2Fwww.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. Email Marketing > Software <http://www.icontact.com/a.pl/144186> >
