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
- [service-orientated-architecture] JP on The Relationship... Gervas Douglas
-
