Thanks Annes. They have a standard set of domain business model with processes and tiered component model for each business sector. It probably works OK if the user accepts using it without too much modification, but with so many companies using IBM now, there won't be too much differences in the system if the companies uses it as it is. Maybe Carr was looking at this kind of situation when he said IT doesn't matter.
That said, it sure it good that to many companies, IT still does matter. :-) H.Ozawa --- In [email protected], Anne Thomas Manes <atma...@...> wrote: > > I believe that IBM uses a proprietary methodology to model services > during their consulting engagements. Components in the methodology > include domain-specific capability, process, and data models > (developed over the course of many engagements). > > Anne > > On Monday, May 25, 2009, htshozawa <htshoz...@...> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Since the name came up, just wondering but do IBM have concrete > > standard guidelines (worksheets and steps) on how to identify services and > > on choosing the granularity? > > > > H.Ozawa > > > > --- In [email protected], "jp_morgenthal" > > <jpmorgenthal@> wrote: > >> > >> Actually, I just let FB pull in my blog now, so this is also available on > >> my blog site www.jpmorgenthal.com/morgenthal > >> --- In [email protected], Gervas Douglas > >> <gervas.douglas@> wrote: > >> > > >> > The following can be found in JP's Facebook Notes (trust this is not > >> > construed as a violation of intimate privacy, JP :) > >> > > >> > <<A colleague recently sent me some IBM propaganda on SOA, BPM and EA. > >> > Discussing my opinion of the white paper with him sparked an idea for a > >> > blog entry about the my opinion on the relationship between these three > >> > methodologies. > >> > > >> > Okay, let?s dive into the meat of the issue. What, if any, is the > >> > relationship between SOA, BPM & EA? First, some quick definitions: > >> > > >> > *BPM *is a practice that focuses on identifying if a business process is > >> > operating within normal operating ranges. How can you tell that? First, > >> > you identify some key performance indicators (KPI) that you will use to > >> > measure your business process (this implies you actually understand your > >> > business), next you have to baseline your current business process; > >> > lastly, you modify one variable at a time to see the impact it has on > >> > the process. Since this last step can have financial impact for your > >> > business, you may want to consider using simulation to assist in this > >> > process. > >> > > >> > *SOA *is a practice that focuses on modeling the entities, and > >> > relationships between entities, that comprise the business as a set of > >> > services. This can be done on a small or large scale. Typically, the > >> > relationships in this model represent consumer/provider relationships. > >> > Doing SOA correctly implies you are taking a top-down approach. I?ve > >> > seen/read views that discuss the bottom-up approach to SOA and I don?t > >> > believe the results of that represent SOA. Perhaps it?s a component > >> > model, but not a services model. The value of SOA is that you are > >> > aligning IT with the business using this architecture methodology. > >> > > >> > Finally *EA *is the ?Big Kahuna? of architecture practices. It attempts > >> > to get the architect(s) to take a holistic approach to thinking about > >> > the organization approaches delivery and support of solutions on an > >> > enterprise scale. The goal of cataloging and modeling at this scale is > >> > that you can see ?the forest from the trees?. It?s very easy to think > >> > about solutions in your organization based purely upon need, but you > >> > will end up with a set of disparate and disconnected silos. Cataloging > >> > that need in an EA enables the organization to recognize consistent > >> > patterns and consolidate around them. Thus, operational costs are > >> > reduced, redundancy is avoided and time is spent solving the unique > >> > aspects of new problems rather than continually reinventing the same > >> > solutions over and over again. > >> > > >> > Now I will provide my opinion on the relationships between these > >> > methodologies: > >> > > >> > SOA & BPM: SOA & BPM are methodologies, not tools or technologies. It?s > >> > irrelevant if SOA suites can do BPMS or BPMS suites support SOA. There > >> > is no inherent relationship between these methodologies just because > >> > vendors discovered that that they can use Web Services as a means of > >> > execute a task within a business process. Web Services is not SOA, it is > >> > merely a standardized approach to accessing functionality on remote > >> > systems. > >> > > >> > However, a well-designed SOA can simplify BPM by enabling rapid business > >> > process modeling that only needs to go as deep as identifying the right > >> > service rather than having to identify the entire sub-task. SOA can also > >> > simplify BPM by denoting in the service the types of KPIs that the > >> > service maintains for itself. This requires full understanding that a > >> > service is a measurable unit and that metrics are a key component to > >> > development of the service contract. If you can?t me > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
