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.