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.doug...@...> 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 measure it, it?s not a
> service!
>
> EA, SOA & BPM: SOA and BPM are views within the enterprise architecture.
> They don?t replace the need for EA and they cover only a small subject
> of EA?s requirements.>>
>
> Gervas
>
