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.
3 thoughts on “The Relationship Between SOA, BPM & EA”
"I’ve seen/read views that discuss the bottom-up approach to SOA and I don’t believe the results of that represent SOA. "
That statement is wrong, as like any other architecture practice SOA is also based on certain principles, one of them is reusability. From an enterprise point of view reusability is applied to all assets on which the organization invested money, time and effort, not just SOA service interface and operations or assets build as part SOA initiatives.
In order to apply the reusability principle properly, we should consider service enablement of “AS IS” applications and IT assets. Interface oriented computing is not all a new concept and it was there for years. However web service and XML made it easier to expose interfaces as SERVICE so SOA picked up momentum. Interface of most of the applications and IT assets can be converted to enterprise services by composing them together within right enterprise context and bottom up approach is the path for such service enablement.
However, most organization is too dynamic and a single SOA enablement approach may not provide them LOW TCO and High ROI, so a mixed approach “TOP DOWN, BOTTOM UP AND MEET IN THE MIDDLE” will be the best!!!!
First, the term "wrong" in your assessment is uncalled for given that there's no factual science behind either of our opinions to provide concrete resolution.
Second, I don't know how long you've been at this, but I've been evaluating this SOA thing from all angles since 2003. Your "meet in the middle" approach is straight from the SOA vendor catalog and was designed to be the least offensive to a buying audience since this beast went scattergun in 2005. I, on the other hand, don't have to have those sensitivities because I'm not selling an SOA product set.
After all my research, and it is comprehensive, SOA is still most useful in the alignment of IT and Business, which can only occur with a top-down approach. The bottom-up approach can leverage great SCA and OO approaches that drive really good reusable software design. Service-enablement of AS-IS architecture is not SOA if it is not aligned with services models generated out of a top-down design; it is software component design, which is in no way a slander.
Not everything has to be SOA, unless you're more concerned with your resume than appropriate systems designs. The ability to design systems using resuable software component methodologies is a valuable commodity even if it doesn't carry the false moniker imposed by a "management by magazine" industry (as David Linthicum likes to call it).
So, to respond to your "meet me in the middle approach" is it more important to have the moniker SOA or more important to focus on good software design? Bottom-up will designs take a turd and chocolate cover it. Sometimes, that's the best we can do and it can help us incrementally swap out the turd for a polished piece of gold, but at the end of the day, you still have the same business alignment you started with unless it is driven by a top-down design.
Interesting post, because understanding of relationships between elements (i.e. BPM, SOA, and EA) of a system is the way to understand these elements. A few comments – see [url=http://improving-bpm-systems.blogspot.com/2009/05/tech-evangelist-blog-relationship.html]http://improving-bpm-systems.blogspot.com/2009/05/tech-evangelist-blog-relationship.html[/url]